Skip to main content

2026 年 9 月 1 日

Horizon Cloud on Microsoft Azure 環境の高可用性の特性

このドキュメント ページでは、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 設計では、次の要素を使用します。

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

  • ペアリングされた仮想マシン
  • 仮想マシン ペアごとの 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 に展開された外部ゲートウェイ構成の展開シナリオで展開されたゲートウェイ コネクタ仮想マシンの場合、単一のゲートウェイ コネクタ仮想マシンが展開されます。ゲートウェイ コネクタがダウンした場合、制御プレーンは Horizon Cloud オペレーション チームにアラートを送信します。チームは API 呼び出しを使用してゲートウェイ コネクタの状態に対処できます。

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

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

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

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

このバックエンド ハードウェアの分離により、両方の仮想マシンで同時にダウンタイムが発生する可能性を最小限に抑えることができます。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 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 分かかります。

このページは役に立ちましたか?

このトピックについてフィードバックを送信

このトピックは役に立ちましたか?

個人情報や機密情報は入力しないでください。

リンクを生成しています…