[検証と続行] をクリックした後、指定した値がシステムによって検証されます。すべてが検証されると、ウィザードに確認のための情報の概要が表示されます。次にデプロイ プロセスを開始します。

手順

  1. [検証と続行] をクリックします。
    次のような指定した値がシステムによって検証されます。
    • これから作成されるサブネットのために指定したアドレス範囲が有効で、サブスクリプション内で選択したリージョンの他のアドレスと重複していないか。
    • サブスクリプションのクォータに、ポッドを構築するための十分な仮想マシン (VM) とコアがあるか。
    • アップロードされた証明書ファイルは正しい PEM 形式か。
    • 既存の管理サブネットを使用することを選択した場合、そのサブネットで Microsoft.SQL サービス エンドポイントが有効になっていますか。
    重要: 2019 年 9 月のサービス リリース以降、ポッドの Microsoft Azure PostgreSQL データベースの使用をサポートするために、新しいポッドのデプロイでは管理サブネットで Microsoft.SQL サービス エンドポイントが有効になっている必要があります。次のスクリーンショットのような選択したサブネットをリストする検証エラーが表示される場合は、ウィザードで選択した既存の管理サブネットに Microsoft.SQL サービス エンドポイントが構成されていないことを意味します。この時点で、Microsoft Azure ポータルにログインし、サブネット上で Microsoft.SQL サービス エンドポイントを有効にできます。その後、ウィザードを再送信してポッドをデプロイできます。エンドポイントを有効にする方法の詳細については、 ポッドのデプロイの前に、Microsoft Azure の VNet で Horizon Cloud ポッドに必要なサブネットを作成するを参照してください。
    管理サブネットで Microsoft.SQL サービス エンドポイントが有効になっていない場合にエラー メッセージを表示するポッド デプロイ ウィザードの検証エラー ウィンドウのスクリーンショット。

    すべてが検証されると、[サマリ] ページが表示されます。

    ネットワーク アドレスの重複に関するエラー メッセージが表示される場合は、サブスクリプションに同じ値を使用している既存のサブネットがあるかどうかを確認します。

  2. ウィザードの最終手順で、概要情報を確認して、[送信] をクリックします。
    Microsoft Azure 環境へのポッドのデプロイを開始します。
    Horizon Cloud on Microsoft Azure:[ポッドの構築:保留中] ステージのスクリーンショット。

結果

最初のポッドのデプロイに最大で 1 時間ほどかかる場合があります。ポッドが正常にデプロイされるまで、進捗状況のアイコンがコンソールの [はじめに] 画面に表示されます。進捗状況を確認するときに、ブラウザ画面の更新が必要になる場合があります。ブラウザ ベースのユーザー インターフェイスは、約 30 分後にタイムアウトして、ログインし直すよう要求することができます。

重要: 通常、ポッドの保留中のステージは最大 10 分間続きます。ただし、Microsoft Azure China クラウドにポッドをデプロイする場合、デプロイのプロセス全体が完了するまでに最大で 7 時間かかることがあります。このプロセスは地理的なネットワークの問題の影響を受け、バイナリがクラウドの制御プレーンからダウンロードされるときにダウンロードの速度が低下することがあります。

20 分後にポッドが 保留中 から ダウンロード中 の状態に変化せず、またデプロイ先が Microsoft Azure China ではない場合、システムはポッドを自動的に エラー 状態に設定します。また、ポッドをクラウド サービスに接続できないため、Microsoft Azure 環境のネットワーク接続状態を確認するように促すメッセージが表示されます。

デプロイされたジャンプ ボックス仮想マシンがクラウド サービスから必要なバイナリをダウンロードできず、ポッドが エラー 状態と表示される場合、環境のネットワーク構成に問題がある可能性があります。たとえば、VNet の設定済み DNS が内部名または外部名を解決していない、必要なアウトバウンド ポートが開いていない、またはファイアウォールによってブロックされている可能性があります。時には、Microsoft Azure コマンド ライン インターフェイスのソフトウェアをダウンロードするために使用される packages.microsoft.com サイトへの接続が一時的に失われている場合があります。いくつかのテストを実行し、ポッドの要件に対して環境ネットワークが適切に構成されているかどうかを検証することができます。ポッドのデプロイまたは初めてのドメイン バインドで問題が発生した場合のトラブルシューティングを参照してください。

ポッドのデプロイ プロセス全体を通して、[はじめに] ページの [キャパシティ] セクションには、プロセスの現在のステージ(保留中、ダウンロード中、構築中、接続中など)が示されます。


Horizon Cloud on Microsoft Azure:[ポッドの構成:接続中] ステージにあるポッドを示す [はじめに] 画面のスクリーンショット。

次の表は、ポッドを構築するステージについての、およその期間の例をいくつか示しています。

重要: デプロイの進行状況で発生する実際の期間は、その時点で存在するネットワーク遅延によって異なります。
ステージ 期間の例
保留中 10 分
ダウンロード中 10 分
構成中 15 分
接続中 10 分

ポッドが正常にデプロイされた場合:

  • Horizon Cloud が、対応する Horizon Cloud 顧客アカウント レコードで識別されるアカウント所有者に通知 E メールを送信します。この E メールには、ポッドのオンボーディングが完了したことが記載されています。
  • [はじめに] 画面に緑色のチェックマークが表示されます。

Horizon Cloud on Microsoft Azure:最初のポッドが完全に追加されたことを示す [はじめに] ページの行

この時点では、Active Directory ドメインがポッドにまだ登録されていないため、[管理] メニューで [ポッドを削除] オプションを使用できます。何らかの理由でデプロイ プロセスが失敗する場合、または使用した値が好ましくないため Active Directory ドメインを登録する前に再びやり直したい場合、[管理] > [ポッドを削除] の順にクリックしてデプロイされたアーティファクトを削除することができます。ポッドが正常に削除されたことが画面に示されたら、[管理] > [ポッドを追加] の順に再度クリックしてプロセスを再開することができます。次のスクリーンショットは、[管理] > [ポッドを削除] オプションの場所を示しています。


Horizon Cloud on Microsoft Azure:テナント環境で Microsoft Azure への最初のポッドの準備ができた後の、[はじめに] ページの [管理] ドロップダウン メニューの [ポッドを削除] オプションの場所を示すスクリーンショット。
ネットワーク遅延のため、この時点でポッドを削除することを選ぶと、すべてポッド関連のアーティファクトが完全に Microsoft Azure 環境から削除される前に、[はじめに] ページでポッドが完全に削除されたことが示される可能性があります。新しいポッドを削除した後、ポッドのデプロイ ウィザードを再び実行する前に、次の手順を行います。
  1. Horizon Cloud ユーザー インターフェイスからログアウトします。
  2. Microsoft Azure ポータルにログインします。
  3. 作成した VNet に移動します。
  4. デプロイヤを使用してポッドのサブネットを自動作成した場合は、ポッドにより作成されたサブネットがないこと、およびそのポッドのサブネットに対して指定したアドレス範囲が VNet のアドレス空間から削除されていることを確認してください。
次に、 Horizon Cloud にログインし直して、ポッドのデプロイ ウィザードを再び実行します。

次のタスク

[はじめに] 画面の [全般的なセットアップ] を展開し、Active Directory ドメインの登録に必要な作業を完了します。次に必要な作業は Active Directory の登録です。ドメインを登録し、ドメイン グループのスーパー管理者ロールを設定すると、システムではすべてのコンソールにアクセスできるようになります。続いて、コンソールでこのポッドの管理を続行します。『Horizon Cloud 管理ガイド』のはじめにを参照してください。Active Directory ドメインを登録したら、[はじめに] ウィザードに従って、次に完了するタスクを確認します。

指定したゲートウェイのタイプに応じて、DNS サーバに適切な CNAME レコードを設定する必要があります。
  • パブリック IP アドレスが有効な外部ゲートウェイの場合は、デプロイ ウィザードで入力した FQDN を、ゲートウェイの Microsoft Azure ロード バランサ リソースの自動生成されたパブリック FQDN にマッピングします。DNS サーバ レコードは、Microsoft Azure ロード バランサの自動生成されたパブリック FQDN とエンド ユーザーが使用する FQDN をマッピングします。これは、アップロードされた証明書で使用されます。次のコード行は、例を示します。Active Directory ドメインを登録した後、コンソールのポッドの詳細ページから使用する ID を見つけます。外部ゲートウェイが専用の VNet にデプロイされていた場合は、[デプロイ ID] フィールドに表示されている ID を使用します。
    ourApps.ourOrg.example.com   vwm-hcs-ID-uag.region.cloudapp.azure.com
  • 内部ゲートウェイまたはパブリック IP アドレスがない外部ゲートウェイの場合は、デプロイ ウィザードで入力した FQDN を、ゲートウェイの Microsoft Azure ロード バランサ リソースのプライベート IP アドレスにマッピングします。DNS サーバ レコードは、Microsoft Azure ロード バランサの IP アドレスとエンド ユーザーが使用する FQDN をマッピングします。これは、アップロードされた証明書で使用されます。次のコード行は、例を示します。
    ourApps.ourOrg.example.com   Azure-load-balancer-private-IP

外部および内部ゲートウェイ構成の両方に同じ FQDN を使用する場合は、ポッドのデプロイ後に、受信するエンドユーザー クライアントのトラフィックを、ゲートウェイのリソース グループ内の適切なロード バランサ リソースにルーティングするための設定を行う必要があります。目標は、インターネットからのクライアント トラフィックが外部ゲートウェイの Microsoft Azure パブリック ロード バランサにルーティングされ、イントラネットからのクライアント トラフィックが内部ゲートウェイの Microsoft Azure 内部ロード バランサにルーティングされるようにルーティングを設定することです。両方のゲートウェイで同じ FQDN を使用する場合、スプリット DNS(スプリット Domain Name System)を構成して、エンド ユーザー クライアントの DNS クエリのオリジン ネットワークに応じて、外部ゲートウェイまたは内部ゲートウェイのいずれかにゲートウェイ アドレスを解決します。

ポッド詳細ページでロード バランサ情報を見つける手順については Horizon Cloud 管理ガイド を参照してください。

ポッドのゲートウェイ構成に RADIUS 2 要素認証を指定した場合は、次のタスクを実行する必要があります。
  • RADIUS 設定を使用して外部ゲートウェイを構成し、ポッドで使用される VNet と同じ VNet 内で、または外部ゲートウェイを専用の VNet に展開した場合は、ピアリングされた VNet トポロジ内でその RADIUS サーバにアクセスできない場合、その RADIUS サーバが、外部ゲートウェイのロード バランサの IP アドレスからのクライアント接続を許可するように構成します。外部ゲートウェイ構成では、Unified Access Gateway インスタンスは、そのロード バランサのアドレスを使用して、RADIUS サーバとの通信を試みます。接続を許可するには、その外部ゲートウェイのリソース グループにあるロード バランサ リソースの IP アドレスが、確実に RADIUS サーバ構成でクライアントとして指定されているようにします。
  • 内部ゲートウェイを構成した場合や、外部ゲートウェイを構成してポッドで使用される VNet と同じ VNet 内で RADIUS サーバにアクセスできる場合は、RADIUS サーバと通信する必要がある、Microsoft Azure でのゲートウェイのリソース グループで作成された適切な NIC からの接続を許可するように RADIUS サーバを構成します。ネットワーク管理者が、ポッドの Azure 仮想ネットワークおよびサブネットに対する RADIUS サーバのネットワーク可視性を決定します。RADIUS サーバは、ネットワーク管理者によって RADIUS サーバへのネットワーク可視性が付与されたサブネットに対応するゲートウェイ NIC の IP アドレスからの、クライアント接続を許可する必要があります。Microsoft Azure のゲートウェイのリソース グループには、そのサブネットに対応する 4 つの NIC があり、そのうち 2 つが 2 個の Unified Access Gateway インスタンスに対して現在アクティブです。もう 2 つはアイドル状態で、ポッドが更新を完了した後にアクティブになります。実行中のポッド操作のため、および各ポッドの更新後のために、ゲートウェイと RADIUS サーバ間の接続をサポートするには、これらの 4 つの NIC の IP アドレスが RADIUS サーバ構成でクライアントとして指定されていることを確認します。

これらの IP アドレスを取得する方法については、Horizon Cloud 管理ガイド の「必要な Horizon Cloud ポッド ゲートウェイ情報で RADIUS システムを更新する」トピックを参照してください。