この記事では、シングルポッド ブローカから Universal Broker への移行をスケジューリングして完了する前に、Horizon Cloud テナント環境が満たす必要がある要件について説明します。また、Universal Broker の新しい接続 FQDN をサポートするための計画および準備の手順についても説明します。

移行後に Universal Broker によって仲介されるマルチクラウド割り当ての移行プロセスと継続的な運用をサポートするには、テナント環境が次の要件を満たしていることを確認します。

Horizon Cloud ポッド(ネイティブ Microsoft Azure のポッド)の要件

ネイティブ Microsoft Azure クラウド(Horizon Cloud ポッドとも呼ばれる)にデプロイされたポッドが次の要件を満たしていることを確認します。

  • テナント環境に Horizon Cloud ポッドが少なくとも 1 つデプロイされます。
  • すべてのポッドは、ポッド マニフェスト 2298.0 以降で実行されています。特定のユースケースでは、次の要件も適用されます。
    • Horizon Cloud テナントと Workspace ONE Access の間に既存の統合がある場合は、すべてのポッドがマニフェスト 2474.0 以降で実行されている必要があります。ブローカの移行が完了した後、Universal Broker による Horizon Cloud 環境 - テナントを Workspace ONE Access および Intelligent Hub サービスと統合するの説明に従って、Universal Broker の使用に合わせて統合を更新する必要があります。
    • ブローカの移行後にタスク キャンセル機能または削除保護機能を使用する場合は、すべてのポッドがマニフェスト 2474.0 以降で実行されている必要があります。ポッドがマニフェスト 2474.0 より前のバージョンで実行されている場合、これらの機能はサポートされません。
    重要: Microsoft Azure 内のすべてのポッドがオンラインで、健全な準備完了の状態であることを確認します。移行プロセスを完了するために、 Universal Broker サービスはポッドとの通信を行い、ポッドでいくつかの構成手順を実行する必要があります。オフラインまたは使用できないポッドがある場合は、移行をスケジューリングできません。移行をスケジュールリングしても、いずれかのポッドが後でオフラインになるか、移行の進行中に使用できなくなると、 Universal Broker のセットアップは失敗します。
  • 移行と同時にポッドのアップグレードがスケジューリングされることはありません。
  • 各ポッドには、少なくとも 1 つの内部または外部の Unified Access Gateway インスタンスがあります。
    注: ポッドに内部 Unified Access Gateway インスタンスだけが含まれる場合、 Universal Broker は [ブローカ] ページの [ネットワーク範囲] タブで定義されたネットワーク ポリシーを上書きし、IP アドレスに関係なく、すべてのユーザーをその Unified Access Gateway インスタンスにルーティングします。
    • Unified Access Gateway インスタンスは 3.8 以降のバージョンにする必要があります。
    • Unified Access Gateway インスタンスは、1 つ以上のポッドとペアリングする必要があります。
    • すべてのポッドにまたがるすべての Unified Access Gateway インスタンスが準備完了状態である必要があります。
    重要: 移行後に Universal Broker で 2 要素認証を使用する場合は、適切な RADIUS 認証サービスを使用して、ポッドに少なくとも 1 つの外部 Unified Access Gateway インスタンスが構成されている必要があります。同じ RADIUS 認証サービスを使用するには、参加しているすべてのポッドにまたがるすべての外部 Unified Access Gateway インスタンスを構成する必要があります。

Universal Broker をサポートするための DNS、ポート、およびプロトコル要件

次の要件を確認します。

Universal Broker をサポートするための FQDN 要件

シングル ポッド ブローカを使用する場合、エンド ユーザーは各ポッドの完全修飾ドメイン名 (FQDN) に個別に接続して、そのポッドからの割り当てにアクセスします。

Universal Broker への移行後、ユーザーは Universal Broker クラウド サービスの 1 つの FQDN に接続することで、環境内の任意のサイトの任意のポッドから任意の割り当てにアクセスできます。Universal Broker は、要求を処理できる最も適切なポッドの個々の FQDN に各ユーザー要求をルーティングします。

シングル ポッド ブローカから Universal Broker への移行をスケジューリングして完了する の説明に従って、Universal Broker 構成設定で Universal Broker FQDN を指定します。有効なサブドメインを VMware が提供する標準ドメインの前に付けることで FQDN を作成するか、完全にカスタムの FQDN を構成することができます。

注: カスタム FQDN を構成する場合は、この FQDN が自分の会社または組織を表すことに注意してください。カスタム FQDN で指定されたドメイン名の所有者であり、そのドメインを検証する証明書を提供でき、カスタム FQDN を使用するための適切な承認を持っていることを確認してください。 Universal Broker のカスタム FQDN は、ポッド内のすべての Unified Access Gateway インスタンスの FQDN とは異なる一意の値でなければなりません。

ブローカ移行の計画と準備

ブローカの移行にはネットワークと割り当てのワークフローへの重要な変更が含まれるため、新しいワークフローに向けて環境とユーザーを準備するために必要なアクションを実行するようにしてください。移行の使用事例に基づく適切な準備と変更管理手順については、次のプランニング ガイドを参照してください。

移行の使用事例 計画と準備の手順
環境が単一のポッドで構成されており、そのポッドの既存の FQDN を Universal Broker の FQDN として使用する
  1. 移行のスケジュールリング プロセスの構成段階で、ポッドの既存の FQDN を Universal Broker サービスのカスタム FQDN として指定します。
  2. エンドユーザーの割り当てワークロードへの影響を最小限に抑える日時で移行をスケジューリングします。
  3. 予定された移行に備え、エンド ユーザーに通知して準備します。移行時間が近づくにつれて、作業を保存し、アクティブな接続セッションからログアウトします。
  4. 移行の直前に、新しい IP アドレスと FQDN をポッドに割り当てます。
  5. 移行が完了したら、ポッドの以前の FQDN(現在は Universal Broker の FQDN)を使用して接続セッションを再開できることをエンド ユーザーに通知します。
環境が複数のポッドで構成されており、そのポッドの新しい FQDN を Universal Broker の FQDN として構成する
  1. 移行プロセスの前、移行中、および移行後に実行する必要がある手順を含めるには、手順を更新します。
  2. 移行のスケジュールリング プロセスの構成段階で、Universal Broker サービスの新しい FQDN を構成します。
  3. エンドユーザーの割り当てワークロードへの影響を最小限に抑える日時で移行をスケジューリングします。ポッドのデプロイの規模に応じて、ユーザー トレーニングとクライアント ソフトウェアの再構成に十分な時間を確保します。
  4. 予定された移行に備え、エンド ユーザーに通知して準備します。移行時間が近づくにつれて、作業を保存し、アクティブな接続セッションからログアウトします。
  5. 移行中または移行直後に、ユーザーのクライアント システムの Horizon Client を再構成して、個々のポッドの FQDN ではなく、新しい Universal Broker FQDN に接続します。
  6. 新しいブローカ接続 FQDN を使用する必要があり、その結果、環境内のすべてのポッドへのユニバーサル アクセスを取得できることをエンド ユーザーに通知します。