第 1 世代 Horizon Cloud テナントのポッド フリートに少なくとも 1 つのポッドがある状態になり、Active Directory ドメイン登録の手順が完了した後、[キャパシティ] ページには、ポッド フリートにポッドを追加するためのメニュー オプションが表示されます。この特定のワークフローは、Horizon Cloud ポッドに適用されます。これらのポッドは、Horizon Cloud ポッド マネージャ テクノロジーをベースとしており、これは Microsoft Azure サブスクリプションでのみ実行され、VMware SDDC を必要としません。
さまざまなポッド タイプのフリートにポッドを追加する方法の概要については、第 1 世代テナント - 第 1 世代 Horizon Universal Console の [キャパシティ] の概要と、Horizon Cloud のポッド フリートへのポッドの追加を参照してください。
ウィザードには、複数の手順があります。手順で情報を指定した後に、[次へ] をクリックして次の手順に進みます。
前提条件
ポッド デプロイ ウィザードを開始する前に必要な項目を用意しておくことを確認します。ウィザードで指定する必要がある項目は、ポッドの構成オプションによって異なります。第 1 世代テナント - 第 1 世代のポッド デプロイ ウィザードを実行するための前提条件のリストを参照してください。
追加のポッドに使用する構成で必須となる項目に加えて、追加のポッドをデプロイする前に、クラウド接続された最初のポッドが完全にデプロイされ、Active Directory ドメイン バインドおよびドメイン参加の手順が完了している必要があります。顧客アカウント レコード内のクラウド接続されたすべてのポッドは同じ Active Directory 情報を共有し、クラウド接続されたそれぞれのポッドはすべてのクラウド構成の Active Directory ドメインとの接続状態を維持している必要があります。詳細については、第 1 世代のテナント - Horizon Cloud 制御プレーン テナントで最初に必要な Active Directory ドメイン登録の実行を参照してください。
テナントが Universal Broker で構成され、ブローカ設定で 2 要素認証が有効になっている場合は、2 要素認証設定を持ち、同じ 2 要素認証タイプを使用する外部 Unified Access Gateway が必要です。
手順
- コンソールで、 に移動し、 をクリックして、ポッド デプロイ ウィザードを起動します。
ウィザードの最初の手順が開きます。
- このウィザードの手順では、ネットワーク情報に加えて、ポッドの名前などの詳細を指定します。
オプション 説明 [サイト] Microsoft Azure のポッドに Universal Broker を使用するようにテナント環境が構成されていて、追加のポッドをデプロイしているときは、ウィザードに [サイト] が表示されます。ポッドをサイトに関連付けます。既存のサイトの選択、デフォルトのサイト の使用、新しいサイト名の指定のいずれかが可能です。[キャパシティ] 画面の [サイト] タブには、環境内ですでに構成されているサイトが一覧表示されます。 [ポッド名] このポッドにわかりやすい名前を入力します。管理コンソールでは、他のポッドと区別するために、この名前が使用されます。 注： この名前は、 Horizon Cloud 顧客アカウントの既存のポッドにおいて一意である必要があります。名前は、[キャパシティ] ページに記載されているポッドの名前と一致してはいけません。[場所] 既存の市区町村名を選択するか、[追加] をクリックして新しい市区町村名を指定します。 システムは市区町村名に基づいてポッドをグループ化し、コンソールの [ダッシュボード] ページの [Horizon のグローバルな占有量] マップに表示します。
[追加] をクリックして、市区町村の名前を入力します。システムは自動的にバックエンドの地理参照テーブルにある、入力した文字に一致する世界の市区町村名表示するので、そのリストから市区町村を選択できます。
注： システムのオートコンプリート リストから市区町村を選択する必要があります。現在、既知の問題により、ロケーション名はローカライズされていません。[Microsoft Azure リージョン] ポッドを展開する実際の地理的な Microsoft Azure リージョンを選択します。利用可能なリージョンは、以前に選択した Microsoft Azure 環境によって決まります。 リージョンを選択するときは、このポッドからサービスを利用するエンド ユーザーとの近接性を考慮します。エンド ユーザーがより近接している場合、遅延は少なくなります。
重要： 一部の Microsoft Azure リージョンでは、GPU が有効な仮想マシンはサポートされません。GPU 対応のデスクトップまたはリモート アプリケーションでポッドを使用する場合は、使用する NV シリーズ、NVv4 シリーズ、NCv2 シリーズの仮想マシン タイプが、ポッド用に選択した Microsoft Azure のリージョンで提供されていることと、この Horizon Cloud リリースでサポートされていることを確認します。詳細については、 https://azure.microsoft.com/ja-jp/regions/services/ にある Microsoft のドキュメントを参照してください。[説明] オプション：このポッドの説明を入力します。 [Azure リソース タグ] オプション：Azure リソース グループに適用するカスタム タグを作成します。Azure リソース タグはリソース グループにのみ適用され、グループ内のリソースには継承されません。
最初のタグを作成するには、[名前] と [値] のフィールドに情報を入力します。追加のタグを作成するには、[[+]] をクリックし、既存のフィールドの下に表示される [名前] と [値] のフィールドに情報を入力します。
- 最大 10 個のタグを作成できます。
- タグの名前は 512 文字に制限され、タグの値は 256 文字に制限されます。ストレージ アカウントの場合、タグの名前は 128 文字に制限され、タグの値は 256 文字に制限されます。
- タグの名前には次の文字を含めることはできません。
< > % & \ ? /
- タグ名に大文字と小文字を区別しない文字列（「azure」、「windows」、「microsoft」）を
含めることはできません。
- タグ名とタグ値には、ASCII 文字のみを含めることができます。標準の 128 文字 ASCII セット（拡張 ASCII または拡張 ASCII 文字とも呼ばれる）以外の空白および文字は使用できません。
[仮想ネットワーク] リストから仮想ネットワークを選択します。 [Microsoft Azure リージョン] フィールドで選択されたリージョンに存在する仮想ネットワーク (VNet) のみがここに表示されます。Microsoft Azure サブスクリプションで、そのリージョンで使用する VNet をすでに作成している必要があります。
[既存のサブネットを使用] ポッドのサブネット要件を満たすよう事前にサブネットを作成済みの場合は、このトグルを有効にします。このトグルを [はい] に設定すると、サブネットを指定するためのウィザード フィールドは、ドロップダウン選択メニューに変わります。 重要： このウィザードは、必要なサブネットの 1 つとして既存のサブネットを使用すること、またはその他の必要なサブネットに対して CIDR アドレスを入力することをサポートしません。このトグルを [はい] に設定している場合は、ポッドの必要なサブネットをすべて既存のサブネットから選択する必要があります。[管理サブネット] [管理サブネット (CIDR)]
[既存のサブネットを使用] を有効にすると、このメニューに、[仮想ネットワーク] に選択した VNet 上で使用可能なサブネットが一覧表示されます。ポッドの管理サブネットに使用する既存のサブネットを選択します。 重要：- サブネットのサービス エンドポイントとして構成された Microsoft.SQL サービスがあるサブネットを選択します。このサービス エンドポイントは、管理サブネットを介した、ポッド マネージャ仮想マシンとポッドの Azure Postgres データベースとの間で必要となる通信をサポートします。
接続されているその他のリソースがない空のサブネットを選択します。サブネットが空でない場合、デプロイ中またはポッドの操作中に予期しない結果が発生する可能性があります。
[既存のサブネットを使用] がオフになっている場合、サブネットのアドレス範囲を CIDR 表記（192.168.8.0/27 など）で入力して、ポッドと Unified Access Gateway インスタンスが接続するサブネットをデプロイヤが作成するようにします。管理サブネットの場合、少なくとも /27 の CIDR が必要です。
注意： 既存のサブネットを使用するウィザード オプションを選択しない場合、そのサブネットが Microsoft Azure 環境に存在していない必要があります。既に存在している場合は、ウィザードの次の手順に進もうとするとエラーが発生します。[仮想マシン サブネット - プライマリ] [仮想マシン サブネット (CIDR) - プライマリ]
このフィールドは、ポッドがエンドユーザーのデスクトップとアプリケーションを提供するためにプロビジョニングする仮想マシンに使用するサブネットに関連します。このような仮想マシンには、ゴールド イメージ仮想マシン、ファームの RDSH 対応仮想マシン、VDI デスクトップ仮想マシンなどが該当します。 [既存のサブネットを使用] を有効にすると、このメニューに、[仮想ネットワーク] に選択した VNet 上で使用可能なサブネットが一覧表示されます。これらの仮想マシンに使用する既存のサブネットを選択します。
重要： 接続されているその他のリソースがない空のサブネットを選択します。サブネットが空でない場合、デプロイ中またはポッドの操作中に予期しない結果が発生する可能性があります。[既存のサブネットを使用] がオフになっている場合、サブネットのアドレス範囲を CIDR 表記（192.168.12.0/22 など）で入力して、ポッドのデプロイ時にこのこのサブネットをデプロイヤが作成するようにします。デスクトップ サブネットの場合、少なくとも /27 の CIDR が必要であり、/22 の CIDR を推奨します。
重要： ファームの RDSH 対応仮想マシンと VDI デスクトップ仮想マシンをエンド ユーザーに提供できるように、このポッドでプロビジョニングする予定の仮想マシンの台数に十分対応できる範囲を入力します。このデスクトップのサブネットは、ポッドをデプロイした後には拡張できません。注意： 既存のサブネットを使用するウィザード オプションを選択しない場合、そのサブネットが Microsoft Azure 環境に存在していない必要があります。既に存在している場合は、ウィザードの次の手順に進もうとするとエラーが発生します。[NTP サーバ] 時刻を同期するために使用する NTP サーバのリストをカンマで区切って入力します。 ここで入力する NTP サーバは、パブリック NTP サーバ、または時刻同期を指定するために設定する独自の NTP サーバです。ここで指定した NTP サーバは、使用するポッドのために [仮想ネットワーク] フィールドで選択した仮想ネットワークからアクセスできる必要があります。このフィールドでは、各 NTP サーバを IP アドレスまたはドメイン名のいずれかで指定できます。このフィールドに IP アドレスの代わりにドメイン名を入力する場合、仮想ネットワークに対して構成された DNS が指定された名前を解決できることを確認する必要があります。
パブリック NTP サーバのドメイン名の例は、
time.windows.com、us.pool.ntp.org、time.google.comです。[プロキシを使用] アウトバウンド インターネット接続用のプロキシが必要な場合は、このトグルを有効にして、表示される関連フィールドに入力します。 ポッド デプロイヤは、ソフトウェアを Microsoft Azure クラウド環境に安全にダウンロードし、Horizon Cloud クラウド制御プレーンに接続するために、インターネットへのアウトバウンド アクセスを必要とします。ポッドでプロキシ設定を使用するには、トグルを有効にした後、次の情報を提供する必要があります。
- [プロキシ]（必須）：プロキシ サーバのホスト名または IP アドレスを入力します。
- [ポート]（必須）：プロキシ サーバの設定で指定されているポート番号を入力します。
プロキシ サーバ設定で認証のためのユーザー名とパスワードが必要な場合は、次の認証情報も入力します。
- [次へ] をクリックして、次の手順に進みます。
以下のスクリーンショットは、次の手順が最初に表示された場合の例です。一部のコントロールは、外部 Unified Access Gateway ゲートウェイ構成に別のサブスクリプションを使用するために、最初のウィザード手順で選択した場合にのみ表示されます。
結果
ポッドのデプロイに最大で 1 時間ほどかかる場合があります。ポッドが正常にデプロイされるまで、そのポッドの進捗状況のアイコンが表示されます。更新の進捗状況を確認するときに、ブラウザ画面の更新が必要になる場合があります。
次のタスク
- ポッドの外部ゲートウェイに 2 要素認証が構成され、ゲートウェイの Unified Access Gateway インスタンスがデプロイされているのと同じ VNet トポロジ内で 2 要素認証サーバにアクセスできない場合は、外部ゲートウェイのロード バランサの IP アドレスからの通信を許可するようにその 2 要素認証サーバを構成します。
このシナリオでは、ゲートウェイ展開と同じ VNet トポロジ内で 2 要素認証サーバにアクセスできないため、Unified Access Gateway インスタンスは、そのロード バランサ アドレスを使用してそのサーバとの接続を試みます。その通信トラフィックを許可するには、その外部ゲートウェイのリソース グループにあるロード バランサ リソースの IP アドレスが、確実に 2 要素認証サーバの構成でクライアントまたは登録されたエージェントとして指定されているようにします。この通信を許可する方法の詳細については、お使いの 2 要素認証サーバのドキュメントを参照してください。
- 同じ VNet トポロジ内で 2 要素認証サーバにアクセスできる場合は、Microsoft Azure でのデプロイの Unified Access Gateway インスタンス用に作成された適切な NIC からの通信を許可するように 2 要素認証サーバを構成します。
ネットワーク管理者が、展開に使用される Azure VNet トポロジとそのサブネットに対する 2 要素認証サーバのネットワーク可視性を決定します。2 要素認証サーバは、ネットワーク管理者が 2 要素認証サーバにネットワークの可視性を与えたサブネットに対応する Unified Access Gateway インスタンスの NIC の IP アドレスからの通信を許可する必要があります。
Microsoft Azure のゲートウェイのリソース グループには、そのサブネットに対応する 4 つの NIC があり、そのうち 2 つが 2 個の Unified Access Gateway インスタンスに対して現在アクティブです。もう 2 つはアイドル状態で、ポッドとそのゲートウェイが更新を完了した後にアクティブになります。
実行中のポッド操作のため、および各ポッドの更新後のために、ゲートウェイと 2 要素認証サーバ間の通信トラフィックをサポートするには、これらの 4 つの NIC の IP アドレスがそのサーバ構成でクライアントまたは登録されたエージェントとして指定されていることを確認します。この通信を許可する方法の詳細については、お使いの 2 要素認証サーバのドキュメントを参照してください。
- 外部 Unified Access Gateway 構成を設定する場合、デプロイ ウィザードに入力した FQDN を、ポッドの Microsoft Azure パブリック ロード バランサの自動生成された FQDN にマッピングします。
- 内部 Unified Access Gateway 構成の場合、デプロイ ウィザードに入力した FQDN を、ポッドの Microsoft Azure 内部ロード バランサのプライベート IP アドレスにマッピングします。
ポッド詳細ページで必要なロード バランサ情報を確認する手順については、DNS サーバでマッピングする Horizon Cloud ポッドのゲートウェイのロード バランサ情報の取得方法 を参照してください。
