このブログはCitrix Cloud SuccessチームのCloud Guidepost: Citrix Virtual Apps and Desktops Service on Azure (Part 3) – Environment Implementationの日本語翻訳に加筆修正したものです。
コスタリカに旅行したことがある人なら、飛行機がセントラルバレーに着陸する前に分厚い雲を通り抜けなければならないことはご存知でしょう。あの雲はいつもあそこにあるのです。Citrix Cloud Successでも、「雲（クラウド）」が実に多く登場しますが、このシリーズの3番目（最後）の記事では、Microsoft Azure Cloudと組み合わせてCitrix Virtual Apps and Desktops Serviceを実際に実装する手順について説明します。
説明を進める前に、まだお読みになっていない場合は、このブログシリーズのパート1とパート2をぜひお読みになることをお勧めします。
- サンプルのアーキテクチャ図
大規模な展開では特に、環境をモデル化した図を作成することは非常に重要です。これによって、展開に必要な主なコンポーネントを検討することができます。必要なコンポーネントを計画したり、コンポーネントの可用性を高めるために活用できるAzureの機能を検討する場合、実にクリエイティブな作業が可能であるということを覚えておいてください。したがって、次の例は、これを実行する唯一の方法というわけではなく、数多くある方法の1つに過ぎません。
- Azureディスクの構成
Azure VMディスクに関しては、すべてのサーバーでManaged Disksを使用することを強くお勧めします。私の例では、すべてのサーバーでManaged Disksを使用しています。このようにすることで、ストレージアカウントの管理に関する複雑な作業はすべてMicrosoftが担当するため、この作業を行う必要がなくなります。Citirix環境向けのManaged Disksのサポートに関する詳細については、こちらの優れたブログの記事を参照してください。
- Azure 仮想ネットワーク(VNET)とサブネット
この特定の環境では、1つのVNETと3つのサブネットを作成しました。外部の世界を指すEDGEサブネット、内部サーバーネットワークであるCOREサブネット、管理トラフィック専用のMGMTネットワークです。各サブネットでは、必要なトラフィックのみが許可されるように、セキュリティグループが構成されている必要があります。必要に応じて、ネットワークインターフェイス(vNic)ベースでセキュリティグループを提供することもできます。
- リソースグループ
リソースグループの計画は企業ごとに大きく異なる可能性がある作業であるため、独自の基準に従ってリソースグループを分離する方法を決定することができます。これらを計画するときには、検討すべき制限があるということだけを覚えておいてください。一般的な方法としては、ライフサイクルが類似するリソースを同じリソースグループにまとめます。私の例では、5つのリソースグループを作成しました。インフラストラクチャサーバー用に1つ、ネットワーク用に1つ、マスターイメージ用に1つ、VDA用に1つ、NetScalerのリソース用に1つです。
- 可用性セット
高可用性は、Azureでワークロードを計画する際の主要なトピックの1つです。サンプルでは、AzureがVMを複数の障害ドメインや更新ドメインに配置する可用性セットを作成しました。これが意味することは、この可用性セットに含まれるVMは、同一データセンター内の同一の電源やネットワークスイッチを共有しないということです。一方で、可用性ゾーン（まだサポートは一部のリージョンに限定されている）もあります。この場合、VMを作成するときに、リージョン内でVMを配置するゾーン（データセンター）をAzureに対して指定します。通常、リージョンごとに最低3つのゾーンを指定します。私の例では、NetScaler、ドメインコントローラー、クラウドコネクター、ファイルサーバー、およびStoreFrontサーバー用に独立した可用性セットを作成しました。
注意：可用性セットと可用性ゾーンを組み合わせることはできません。VMを作成した時点で定義する必要があります。
- アクセスレイヤーの構成
NetScalerは高可用性ペアとして展開されています。すべてのコンポーネントを作成して手動でこれを実現することも、こちらのARMテンプレートを使用して、HAペアと必要なコンポーネントを自動的に作成した上で、HAを自動構成することもできます。手動で作業を行う場合は、次の点に注意してください。
- ネットワークインターフェイス(vNic)の構成は重要です。それぞれのNetScalerで使用する各IPがvNicレベルで定義されていることを確認する必要があります。NetScaler UIの内部IP構成は、Azure vNicレベルでIPを定義するまでは何も意味していないことに注意してください。
- 設計上、2つのAzure VM間でIPアドレスを「フローティング」させることはできません。複数のNetScalerが同じIPアドレスを共有しないように、HA Independent Network Configuration（INC）を活用する必要があります。
- 最終的には同じURLで、IPアドレス（各NetScalerが使用するためVIPですが、Azure内でVIPをフローティングにすることはできません）の異なる2つのNetScaler Gateway vServerを作成します。
- VIPは内部IPであり、パブリックではありません。
- セカンダリノードのVIPは、フェイルオーバーイベントが発生するまで、応答しません。
- 2番目のvServerを作成するときには、NetScalerでユーザーが作成できるようにするために、CAPSを使用します。
- NetScalerの前にAzure External Load Balancerを配置します。このLoad Balancerは、外部ユーザーがアクセスするためのパブリックIPアドレスを保持します。
- SSL証明書を両方のNetScaler Gateway vServerにアタッチする必要がありますが、Azure Load Balancerにはその必要はありません。
- パブリックDNS Aレコードは、Load BalancerのパブリックIPアドレスを指している必要があります。
上記の方法が唯一の方法ではないことに注意してください。この記事を参考にして、AzureにNetScaler HAペアを展開する方法の詳細を確認してください。
StoreFrontについては、Azure Internal Load Balancerの背後にサーバーのペアを展開し、専用の可用性セットを活用しています。StoreFrontサーバーにはSSL証明書をアタッチしていません。この構成は非常に単純であり、特に注意事項はありません。
- コントロールレイヤーの構成
Cloud Connectorは可用性セット内でペアとして展開されていますが、これらについて何らかの種類の負荷分散を設定する必要はありません。ご存知のように、シトリックスではCloud Connectorを常に利用できるようにするために、コネクターの更新時でもサービスが利用できるように、最低2つを展開する必要があります（当然ですが、シトリックスが2つのCloud Connectorを同時に更新することはありません）。
注意：Cloud Connectorは送信ポート443経由でCitrix Cloudに接続します。Network Security Groupの構成を計画および実装するときには、これに留意してください。
- リソースレイヤーの構成
私の例では、専用のVDAを1つだけ使用していますが、確実にマスターイメージを作成し、それを使用してMachine Creation Services経由でVDIを展開できます。繰り返しますが、AzureサブスクリプションでCitrix Cloudに提供する必要があるアクセスレベルを計画することが重要です。このブログシリーズのパート2では、1つのセクションを割いてこれについて説明しています。
私の例のCitrix Profile Managementとフォルダーリダイレクトのストレージに関しては、記憶域スペースダイレクト（S2D）を使用しています。こちらのARMテンプレートを使用して、サーバーの作成やドメインへのサーバーの参加から、クラスターの設定まで、すべてを展開することができます。私の例では、この作業を手動で行うことにしました。その際に判明した注意点を以下に示します。
- インストールを開始する前に、ネットワーク探索およびファイルとプリンターの共有が有効になっていることを確認します。
- DNSサーバーはクラスターに対してローカルである必要があるため、DNSサーバーには、クラスターが正しく機能するために必要なDNSレコードを作成するためのアクセス許可が必要です。
- クラスターを作成すると、クラスターノードコンピューターアカウントが格納された同じOUで、Active Directory（AD）にCNO（クラスター名オブジェクト）が作成されます。これは、AD内のWindowsクラスターのCore識別子です。クラスターを完全に破棄する必要がある場合を除き、ADからCNOを削除しないでください。
- AD内の「コンピューター」以外のOUにコンピューターを配置する場合（これは最も多いケースです）、コンピューターアカウントを保持するOU内の「コンピューターオブジェクトの作成」アクセス許可をCNOに付与する必要があります。これは、クラスターの役割を作成するときに、VCOを作成するために必要です。
- 仮想コンピューターオブジェクト（VCO）は、CNOが存在しているOUに作成されます。このVCOは、クラスター内でSOFSの役割を作成するときに作成されます。
- クラスタークォーラム用に使用されるクラウド監視を作成します。
- サーバーに新しいディスクを追加する場合は、S2Dが自動的にサーバーをプールします（通常のプールが1つだけである場合）。この後、実行する必要があるのはボリュームを拡張することのみです。
- より大きい本稼働環境にスケーリングする前に、ストレージの要件を適切に計画します。新しいノードを追加すると、ボリュームの再作成が必要になる場合があります。
S2Dクラスターを構成した後、Citrix Profile Managementと、GPO経由のフォルダーリダイレクトを構成しています。S2D共有を活用するために追加の構成は必要ありません。
さあ、これでこの3部構成の旅も終わりです。このシリーズが、Microsoft Azureと組み合わせてCitrix Apps and Desktop Serviceを実装する際の一助になれば幸いです。クラウドの道標シリーズの次のブログを楽しみにしていてください。