移行ワークフローのユーザー インターフェイスを開始する前に、IT チームと協力して、第 1 世代のデプロイが配置されているのと同じ Microsoft Azure 環境で Horizon Edge デプロイの要件が満たされていることを確認する必要があります。

セルフサービスの移行は、移行元の第 1 世代のポッドに使用されるものと同じ Microsoft Azure サブスクリプション、VNet、およびサブネットを使用して、次世代のデプロイを作成するように設計されています。

この設計は、移行元の第 1 世代のポッドで使用されているのと同じ Microsoft Azure サブスクリプションとネットワーク環境が、ファイアウォールを介した特定のエンドポイント URL およびポートへの接続の許可、サービス プリンシパルのロール内の特定の権限、Horizon Edge Gateway の AKS クラスタの内部ネットワーク範囲など、次世代の要件に対応する必要があることを意味します。

  • エンドポイント URL とポートの情報については、Horizon Cloud Service - next-gen のドキュメントの次のページを参照してください。
  • 各イメージが複製され、next-gen に移行されます。そのため、ファミリ内のイメージあたりの vCPU の量が 2 倍である必要があります。

    たとえば、2 つの vCPU コアを持つ Standard_DS2_v2 のイメージを移行するには、移行中に 2 つの追加の vCPU コアが必要です。そのため、Azure サブスクリプションには、対応するリージョンの Standard DSv2 ファミリの vCPU コアが少なくとも 4 つ必要です。ただし、イメージは 20 のバッチで移行されるため、この超過割り当てはイメージあたりの vCPU コア数の 20 倍を超える必要はありません。つまり、イメージ vCPU の 20 倍の割り当てだけではなく、既存の割り当てに加えてイメージ vCPU の 20 倍の超過割り当てが必要になります。

  • 移行中に、United Access Gateway の展開用の証明書を指定し、証明書の共通名または FQDN が UAG 展開に指定された FQDN と一致する必要があります。
  • デスクトップへの内部アクセスのルーティングの調整が必要になる場合があります。
  • 他の IT 関連要件をお読みください。

再利用される項目と必要な新規項目の概要

既存の第 1 世代のデプロイから使用

移行プロセスでは、次の同じ第 1 世代のデプロイ エンティティが次世代のデプロイにも使用されます。

  • Microsoft Azure サブスクリプション ID、ディレクトリ ID、サービス プリンシパル アプリケーション ID およびシークレット キー。
  • VNet
  • 管理サブネット、テナント サブネット、DMZ サブネット
    重要: ポッドの管理サブネット CIDR が /27 の場合、移行プロセスはその管理サブネットを次世代の Horizon Edge Gateway に再利用できません。Horizon Edge Gateway には、/26 の管理サブネット CIDR が必要です。

    ポッドの管理サブネット CIDR が /27 の場合は、ポッドの同じ VNet に /26 以上の新しい管理サブネットを作成する必要があります。次に、移行ユーザー インターフェイスで、システムが Horizon Edge の管理サブネットに使用する新しいサブネットを選択します。

    この新しい管理サブネットを作成する場合は、新しく作成された管理サブネットのネットワーク接続が、次を含むポッドの既存の管理サブネットのネットワーク接続と同等であることを確認する必要があります。

    • その新しいサブネットは、ポッドの既存の管理サブネットと同じ VNet にあります。
    • 新しいサブネットでは、サービス エンドポイントとして Microsoft.Sql サービスを有効にする必要があります(要件の既存のサブネットの使用に関するこの第 1 世代のドキュメント ページを参照)。
    • DNS は、第 1 世代ポッドの既存の管理サブネット用に構成されているため、新しいサブネットに対して正しく構成され、アクセス可能であることを確認する必要があります。
    • 第 1 世代ポッドと同じ Active Directory ドメイン コントローラへの新しいサブネットからの通信をファイアウォールまたは NSG が許可し、第 1 世代ポッドの既存の管理サブネットと同等の接続を確保する必要があります。システムが移行のビルド前フェーズで新しいサブネット上に次世代リソースを作成する場合、これらのリソースは Active Directory ドメイン コントローラと通信できる必要があります。

    また、新しい管理サブネットは、NAT ゲートウェイまたはユーザー定義ルート、Horizon Edge の必要な仮想 IP アドレス範囲との競合、およびその他の要件など、このページで説明されているのと同じ要件を満たす必要があります。

注意:
  • 既存のサブネットの使用に関するこの第 1 世代のドキュメント ページで説明されているように、ポッドの管理サブネットでは、サービス エンドポイントとして Microsoft.Sql サービスが有効になっている必要があります。このエンドポイントは次世代の要件でもあるため、エンドポイントがポッドの管理サブネットで構成されていることを確認します。
  • 第 1 世代のポッドのサブネットの IP アドレス範囲が、次世代の Horizon Edge で必要とされる仮想 IP アドレス範囲と競合したり、重複したりしないことを確認します。移行における除外と特別なケースのシナリオで述べたように、これらの範囲と競合または重複するサブネットを持つポッドのセルフサービスの移行は、現時点ではサポートされていません。
次世代の Horizon Edge のデプロイの追加要件
Horizon Edge のデプロイは、少なくとも 1 つの Horizon Edge Gateway と 2 つの Unified Access Gateway インスタンスで構成されます。
  • 既存の第 1 世代のデプロイ用にすでに配置されている必要がある Azure リソース プロバイダに加えてサブスクリプションに登録する必要がある追加の Azure リソース プロバイダ:Microsoft.ContainerService
  • サービス プリンシパルのロールに必要な追加の権限:第 1 世代のデプロイのサービス プリンシパルがカスタム ロールを使用している場合は、カスタム ロールに次世代の Horizon Edge のデプロイに必要な権限が含まれていることを確認します。ロールの構成済み権限をHorizon Cloud Service next-gen の必要なカスタム ロール権限と比較します。
  • Microsoft Azure ユーザー割り当ての管理対象 ID。この ID は、セルフサービスの移行の前に、第 1 世代ポッドの Microsoft Azure サブスクリプションで作成する必要があります。Horizon Edge には、この項目が必要です。このページの次のセクションユーザーが割り当てた管理対象 IDを参照してください。
  • サブスクリプション内の 4 台の Standard_D2s_v3 仮想マシン(Horizon Edge Gateway マシン用)および 2 台の Standard_F8s_v2 仮想マシン(Unified Access Gateway マシン用)の追加キャパシティ(割り当て)
  • Horizon Edge Gateway の AKS クラスタの送信接続用の NAT ゲートウェイまたはユーザー定義ルートのいずれか。この項目は、セルフサービスの移行の前に、第 1 世代ポッドの Microsoft Azure サブスクリプションで作成する必要があります。移行ワークフローのユーザー インターフェイスでは、NAT ゲートウェイまたはユーザー定義ルートのいずれかのクラスタ送信タイプを選択する必要があります。
    • AKS クラスタの送信タイプに NAT ゲートウェイを使用する場合は、第 1 世代ポッドの管理サブネットで NAT ゲートウェイを構成します。Microsoft Azure のドキュメントに従って、NAT ゲートウェイを作成するには、パブリック IP アドレスまたはパブリック IP プリフィックス、またはその両方が必要です。
    • AKS クラスタの送信タイプにユーザー定義ルートを使用する場合は、管理サブネットでルート テーブルを構成します。VirtualAppliance タイプまたは VirtualNetwork Gateway タイプのネクスト ホップを指すようにデフォルト ルート 0.0.0.0/0 を設定します。
  • セルフサービスの移行により、Horizon Edge の Unified Access Gateway インスタンスに接続されたロード バランサ用に追加のパブリック IP アドレスを作成できるパブリック IP アドレスのキャパシティ。

ユーザーが割り当てた管理対象 ID - 次世代の Horizon Edge 用

移行ワークフローのユーザー インターフェイスを開始する前に、ユーザーまたはユーザーの IT チームは、デプロイされた Horizon Cloud ポッド マネージャ インスタンスが存在する Microsoft Azure サブスクリプションに、ユーザーが割り当てた管理対象 ID を持っている必要があります。

ユーザーまたは IT チームは、Azure ポータルを使用してこの ID を作成および構成できます。Microsoft Azure のドキュメントで、ユーザーが割り当てた管理対象 ID の作成セクションを参照してください。

ユーザーが割り当てた管理対象 ID は、次の特性で構成する必要があります。

  • VNet(ポッド マネージャ インスタンスが現在配置されている VNet)のリソース グループの範囲内の Network Contributor ロール。

  • Microsoft Azure サブスクリプション(ポッド マネージャ インスタンスが現在配置されているサブスクリプション)の範囲内の Managed Identity Operator ロール。

この管理対象 ID が必要な理由は、移行ワークフローでシステムが Horizon Edge をデプロイするためです。次世代アーキテクチャでは、Horizon Edge を使用します。Horizon Edge は設計上、Azure Kubernetes Service (AKS) クラスタを使用します。Azure 環境設計によると、AKS クラスタには Azure リソースにアクセスするための ID が必要です。したがって、移行ワークフローで次世代アーキテクチャで使用される Horizon Edge をデプロイするには、この ID が必要です。

次世代の Horizon Edge に必要な仮想 IP アドレス範囲の予約

移行ワークフローのユーザー インターフェイスでは、[サービス CIDR][ポッド CIDR] という名前のフィールドに 2 つの CIDR を入力する必要があります。

これらは、Horizon Edge Gateway の使用のために予約する必要がある仮想 IP アドレス範囲です。

  • これら 2 つの CIDR([サービス CIDR] の場合は /27、[ポッド CIDR] の場合は /21)用に IPAM(IP アドレス管理)の IP アドレス空間を予約する必要があります。
  • この範囲でサブネットを作成する必要はありません。

これらの仮想 IP アドレス範囲は、Horizon Edge Gateway の AKS クラスタ内に存在します。設計上、Kubernetes はクラスタを使用して仮想ネットワークを作成し、その内部で実行されるコンテナをホストします。

これらの仮想ネットワークは実際には管理ネットワーク上にありませんが、管理ネットワーク(管理サブネット)に接続します。

その結果、これらの CIDR は、AKS クラスタの外部で実行されるサービスからこれらの AKS クラスタ内部ネットワークへのルーティングに影響するため、ネットワーク内の他のネットワークと重複することはできません。たとえば、VDI デスクトップの Horizon Agent は、この AKS クラスタで実行されているサービスにデータを送信する必要があります。

また、これらの CIDR は重複したり、互いに衝突したりしないでください。

重要: Azure のドキュメントに従って、これらの CIDR は次の範囲を使用しないようにしてください。
  • 169.254.0.0/16
  • 172.30.0.0./16
  • 172.31.0.0/16
  • 192.0.2.0/24
サービス CIDR
Horizon Edge の AKS クラスタのサービス CIDR に使用する IP アドレス範囲を決定します。この仮想 IP アドレス範囲のアドレスは、AKS クラスタ内で実行されているサービスに割り当てられます。/27 以上の範囲が必要です。

IP アドレス管理の IP アドレス空間を予約します。前述のように、これは仮想 IP アドレス範囲であり、この範囲のサブネットを作成する必要はありません。

AKS クラスタの仮想ネットワークは管理ネットワークに接続するため、この CIDR 範囲の IP アドレスがそのネットワークで他のマシンまたは項目によって使用されていないことを確認する必要があります。

この CIDR 範囲が、ネットワーク内の他の主要な IP アドレス(DNS サーバ IP アドレス、Active Directory サーバ IP アドレス、管理サブネットに接続されている第 1 世代のデプロイの Unified Access Gateway インスタンスで使用されている IP アドレスなど)と競合しないことを確認してください。

ポッド CIDR
Horizon Edge の AKS クラスタのポッド CIDR に使用する IP アドレス範囲を決定します。この仮想 IP アドレス範囲のアドレスは、AKS クラスタ内で実行されているサービスに割り当てられます。/21 以上の範囲が必要です。

AKS クラスタのノード数に関連しているため、/21 の範囲サイズが必要です。各クラスタ ノードには、この範囲から 256 の IP アドレスが事前に割り当てられます。

IP アドレス管理の IP アドレス空間を予約します。前述のように、これは仮想 IP アドレス範囲であり、この範囲のサブネットを作成する必要はありません。

AKS クラスタの仮想ネットワークは管理ネットワークに接続するため、この CIDR 範囲の IP アドレスがそのネットワークで他のマシンまたは項目によって使用されていないことを確認する必要があります。

この CIDR 範囲が、ネットワーク内の他の主要な IP アドレス(DNS サーバ IP アドレス、Active Directory サーバ IP アドレス、管理サブネットに接続されている第 1 世代のデプロイの Unified Access Gateway インスタンスで使用されている IP アドレスなど)と競合しないことを確認してください。