このドキュメント ページでは、Horizon Cloud on Microsoft Azure 環境の高可用性の特性について説明します。

v2204 サービス リリース以降、新しい環境はデフォルトで高可用性 (HA) が構成された状態でデプロイされます。

v2204 リリースより前に存在していたポッドがあり、そのポッドで高可用性が現在有効になっていない場合は、Microsoft Azure の Horizon Cloud ポッドで高可用性を有効にするの手順を使用して有効にできます。ポッドの詳細ページでは、そのポッドに対して高可用性が有効であるかが示されます。

簡単な紹介

Horizon Cloud on Microsoft Azure 環境の高可用性の特性は、環境の標準操作を次のシナリオでも引き続き機能させることを目的としています。

  • 1 台のポッド マネージャ仮想マシンがダウンした場合、または問題が発生した場合、そのポッド マネージャに向けられたトラフィックは、手動による介入なしに、他のポッド マネージャ仮想マシンに自動的にルーティングされる。
  • ゲートウェイ構成で、1 台の Unified Access Gateway 仮想マシンがダウンした場合、または問題が発生した場合、その Unified Access Gateway 仮想マシンに向けられたトラフィックは、手動による介入なしに、他の Unified Access Gateway 仮想マシンにルーティングされる。

設計の要素

Horizon Cloud on Microsoft Azure 環境の HA 設計では、次の要素を使用します。

これらの要素により、ペアリングされた仮想マシンの 1 台に問題や障害が発生した場合に、回復性とフェイルオーバーが発揮されます。

  • ペアリングされた仮想マシン
  • 仮想マシン ペアごとの Microsoft Azure の可用性セット
  • 各ペアの仮想マシンを接続する Microsoft Azure ロード バランサ
  • Azure Database for PostgreSQL の Microsoft で管理されたサービス

これらの設計要素を環境で使用する方法の詳細については、このドキュメント ページの以降のセクションを参照してください。

ペアリングされた仮想マシン

Horizon Cloud on Microsoft Azure デプロイヤは、デフォルトで以下をデプロイします。

  • Horizon Cloud on Microsoft Azure 環境ごとに 2 台のポッド マネージャ仮想マシン
  • デプロイされたゲートウェイ構成ごとに 2 台の Unified Access Gateway 仮想マシン。
注： 独自の VNet にデプロイされた外部ゲートウェイ構成のデプロイ シナリオでデプロイされたゲートウェイ コネクタ仮想マシンの場合、単一のゲートウェイ コネクタ仮想マシンがデプロイされます。ゲートウェイ コネクタがダウンした場合、制御プレーンはアラートを VMware Horizon Cloud オペレーション チームに送信します。チームは、API 呼び出しを使用してゲートウェイ コネクタの状態に対処できます。

仮想マシン ペアごとの Microsoft Azure の可用性セット

各仮想マシン ペアは、Microsoft Azure の可用性セット（仮想マシン ペアごとの可用性セット）に関連付けられます。

可用性セットを使用することで、ペアの仮想マシンは、それぞれ同じ Microsoft Azure データセンター内の別個の物理ハードウェアにデプロイされます。

Microsoft Azure の可用性セットの設計により、ペアリングされた仮想マシンは、その Microsoft Azure データセンター内の個別の物理ハードウェアに常駐するように強制されます。

このバックエンド ハードウェアの分離により、2 台の仮想マシンがともに同時にダウンタイムを生じる可能性を最小限に抑えることができます。Microsoft Azure データセンター全体がダウンした場合にのみ、ペアの両方の仮想マシンがともに影響を受けます。

各ペアの仮想マシンを接続する Microsoft Azure ロード バランサ

ペアリングされた仮想マシンセクションに記載されているように、Horizon Cloud on Microsoft Azure 環境にはポッド マネージャ仮想マシンのペアがあり、デプロイされた各ゲートウェイ構成には Unified Access Gateway 仮想マシンのペアがあります。

デプロイヤは、仮想マシンのペアごとに Microsoft Azure ロード バランサをデプロイします。

ポッド マネージャ仮想マシン - ロード バランサ

デプロイヤは、ポッドのデプロイ中にこの Azure ロード バランサをデプロイします。このロード バランサは、デプロイヤによって構成された健全性プローブとルールに従って、ポッド マネージャ仮想マシンへのトラフィックをルーティングします。

  • ポッド マネージャ仮想マシンは、このロード バランサのバックエンド プールに追加されます。
  • 1 台のポッド マネージャ仮想マシンが、ポッドでプロビジョニングされたデスクトップおよびアプリケーションへのエンド ユーザー クライアント接続を容易にする上でアクティブな役割を担います。
  • ロード バランサは、バックエンド プール内のマネージャ仮想マシンの定義済みルールと健全性プローブに基づいて、アクティブな役割を担うポッド マネージャを決定します。
  • その決定に基づいて、ロード バランサはフェイルオーバーが発生するまで、すべての接続要求トラフィックをアクティブな役割を担うポッド マネージャ仮想マシンにシームレスにルーティングします。
  • その後、他のポッド マネージャ仮想マシンが、デスクトップおよびアプリケーションへのクライアント接続を容易にする上でアクティブな役割を担います。その時点で、ロード バランサは接続要求をその仮想マシンにルーティングします。
  • このフェイルオーバーが発生すると、どのポッド マネージャ仮想マシンがアクティブな役割に変更されたかを知らせる通知が、コンソールに送信されます。

ポッド マネージャ仮想マシンのデプロイ済み Azure ロード バランサは、IP アドレスを持ち、[新規ポッド] ウィザードに [仮想マシン サブネット - プライマリ]（プライマリ テナント サブネットとも呼ばれます）というラベルが付けられた仮想マシンの NIC に接続されます。

ポッド マネージャ仮想マシンのロード バランサは、エンドユーザーのクライアント接続要求とポッド マネージャ仮想マシンの間に配置されます。

ポッドにゲートウェイ構成が設定されている場合、Unified Access Gateway インスタンスからのトラフィックはこのポッド マネージャ仮想マシンの Microsoft Azure ロード バランサにルーティングされ、Azure ロード バランサはそのトラフィックをアクティブなポッド マネージャ仮想マシンにルーティングします。

ポッドにゲートウェイ構成がなく、直接接続用にポッドを構成している場合、エンドユーザーのクライアント接続はポッド マネージャ仮想マシンの Microsoft Azure ロード バランサに移動し、そのトラフィックはロード バランサによってアクティブなポッド マネージャ仮想マシンにルーティングされます。

ゲートウェイ構成 - ロード バランサ

デプロイヤは、ゲートウェイ構成のデプロイ中にこの Azure ロード バランサをデプロイします。このロード バランサは、デプロイヤによって構成された健全性プローブとルールに従って、トラフィックを環境の Unified Access Gateway 仮想マシンにルーティングします。

  • Unified Access Gateway 仮想マシンは、このロード バランサのバックエンド プールに追加されます。
  • エンドユーザーのクライアント トラフィックでは、各 Unified Access Gateway 仮想マシンにアクティブなロールがあります。Unified Access Gateway 仮想マシンはそれぞれ、Horizon Cloud Service on Microsoft Azure サービス制限 ページで説明する制限まで、ポッドの同時接続セッションを管理します。
  • ロード バランサは、仮想マシンの定義されたルールと健全性プローブに基づいて、バックエンド プール内の Unified Access Gateway 仮想マシンが健全な状態で接続要求を受け取ることができるかを判断します。
  • ロード バランサは、その決定に基づいて、健全性プローブを満たす仮想マシンに接続要求トラフィックをシームレスにルーティングします。
  • バックエンド プールの仮想マシンに問題があるか、ダウンしている場合、ロード バランサは新しい接続要求を健全な仮想マシンにルーティングします。
  • 問題が発生している、またはダウンしている仮想マシンへの既存の接続は切断されます。ユーザーはクライアント セッションを手動で再接続する必要があり、ロード バランサはそれらを健全な Unified Access Gateway 仮想マシンに接続します。
  • 健全でない仮想マシンが健全な状態に戻り、ロード バランサのルールと健全性プローブを満たすと、ロード バランサはその仮想マシンへの新しい接続要求を許可します。

ゲートウェイ構成のロード バランサは、エンドユーザーのクライアント接続要求と構成の Unified Access Gateway 仮想マシンの間に配置されます。

外部ゲートウェイ構成の場合、デプロイされた Azure ロード バランサは、IP アドレスを持ち、デプロイヤ ウィザードに [DMZ サブネット] というラベルが付けられた仮想マシンの NIC に接続されます。ウィザードを使用して独自の VNet に外部ゲートウェイ構成をデプロイする場合、ウィザードはこのサブネットに [フロントエンド サブネット] というラベルを付けます。

内部ゲートウェイ構成の場合、デプロイされた Azure ロード バランサは、（デプロイヤ ウィザードで [仮想マシン サブネット - プライマリ] というラベルが付いた）ポッドのプライマリ テナント サブネット上の IP アドレスを持つ仮想マシンの NIC に接続されます。

環境の Azure Database for PostgreSQL の Microsoft で管理されたサービス

この環境では、Azure Database for PostgreSQL の Microsoft で管理されたサービスと、その 単一サーバ デプロイ オプション を使用します。

この Microsoft で管理されたサービスを使用すると、ポッド操作に必要なデータを一元化し、マネージャ仮想マシン間でデータ レプリケーションを使用する必要がなくなります。現在のリリースでは、デプロイヤは次の構成を使用します。

  • PostgreSQL バージョン 11
  • メモリ最適化
  • コンピューティング世代：Gen 5
  • vCore 数：2
  • ストレージ：10 GB
  • 自動拡張：いいえ
  • バックアップ ストレージ：ローカル冗長

メモリ最適化の構成の詳細については、Microsoft のドキュメントを参照してください。

このリリース レベルで作成または更新されたポッドの Microsoft Azure サブスクリプションにおけるコストの影響

このリリースで高可用性をサポートするために必要な要素は、Azure Database for PostgreSQL の使用および仮想マシン ペアの実行のために、Microsoft Azure サブスクリプションのコストに影響します。この記事の作成時点では、Azure ロード バランサまたは可用性セットの使用のコストは発生しません。

現在のリリースで使用される、前述の Microsoft Azure Database for PostgreSQL 構成の価格見積もりについては、https://azure.microsoft.com/en-us/pricing/details/postgresql/server/を参照してください。

関連リソース グループ

ポッド マネージャの HA 関連リソースは、ポッド マネージャ仮想マシンと同じリソース グループに存在します。

ゲートウェイ構成の HA 関連リソースは、そのゲートウェイ構成の Unified Access Gateway 仮想マシンと同じゲートウェイ構成のリソース グループに存在します。

ポッド マネージャのリソース グループは、環境での Microsoft Azure Database for PostgreSQL の Microsoft で管理されたサービスの使用も反映します。

Microsoft Azure ポータルにログインしてそれらのリソース グループに移動すると、サブスクリプションのリソースの詳細を表示できます。

ポッドのリソース グループを識別することの詳細については、Horizon Cloud on Microsoft Azure デプロイ用に作成されたリソース グループを参照してください。

Microsoft Azure の Horizon Cloud ポッドでの高可用性の有効化

高可用性が有効になっていないポッドの場合は、次の手順に従って高可用性を有効にできます。

このページは、高可用性がまだ有効になっていない 1 つ以上のポッドを持つ管理者のみを対象としています。

v2204 サービス リリース以降、新しい Horizon Cloud on Microsoft Azure 展開はデフォルトですでに高可用性が構成された状態でデプロイされます。ポッドで高可用性がすでに構成されている場合、このページの手順は適用されません。

ポッドの詳細ページに高可用性が有効でないことが示されている場合は、ポッドを編集して高可用性を有効にすることができます。このプロセスでは、2 番目のポッド マネージャ仮想マシンがポッドのリソース グループにデプロイされ、その仮想マシンがポッドの Microsoft Azure ロード バランサと可用性セットで構成されます。

重要： 高可用性のためにポッドを有効にすることは、1 回限りのアクションです。高可用性のためにポッドを有効にすると、後で構成を元に戻して、ポッドでこの機能を無効にすることはできません。

[ポッドの編集] ワークフローの手順を実行して更新を確認すると、サービスはポッドの Microsoft Azure サブスクリプションで 2 番目のポッド マネージャ仮想マシンをインスタンス化し、その仮想マシンと既存の Azure ロード バランサ、Azure PostgreSQL データベース、およびその他の必要なポッド関連タスクとの間に適切な接続を行います。全体のプロセスが完了するまで約 30 分かかることがあります。

前提条件

Horizon Universal Console を使用してワークフローの手順を実行する前に、次の基準を満たしていることを確認します。

  • 高可用性を有効にするには、ポッドのソフトウェアがマニフェスト バージョン 1600 以降である必要があります。ポッドのマニフェスト バージョンを確認するには、[キャパシティ] ページからポッドの詳細ページに移動します。
  • サブスクリプションに、追加のポッド マネージャ仮想マシンの作成に対応できる、十分な割り当てとコアがあることを確認します。
  • ポッドが 1600 より前のマニフェスト バージョンから更新された場合、ポッドの高可用性を有効にする前に、以下を確認する必要があります。
    • ポッドの更新プロセスがそのポッドで完了していること。
    • エージェントが、ポッドのイメージ仮想マシン、ファーム RDSH 仮想マシン、およびデスクトップ割り当て仮想マシンのすべてで、更新されたポッドで実行しているマニフェストと互換性のあるエージェント リリース レベルに更新されていること。ポッドの更新とエージェントの更新の関係については、Horizon Cloud ポッドの更新：エージェントの互換性とサポートを継続するための手順を参照してください。

手順

  1. [キャパシティ] ページからポッドの詳細ページに移動します。
  2. [編集] をクリックします。
  3. [高可用性] セクションで、[有効] トグルをオンに切り替えます。
  4. [保存して終了] をクリックします。
  5. 本当に更新してよいか確認します。

結果

ポッドの詳細ページで、クラスタのステータスに [保留中] の状態が表示されます。構成アクティビティが完了すると、クラスタのステータスに [準備完了] の状態が表示されます。全体のプロセスが完了するまで約 30 分かかります。