このブログはCitrix Cloud SuccessチームのCloud Guidepost: Citrix Virtual Apps and Desktops Service on Azure (Part 2)の日本語翻訳に加筆修正したものです。
SalesforceのCEO兼会長であるMarc Benioff氏はかつて「クラウドはすべての人のものです。クラウドはデモクラシーなのです」と述べていました。私はこの言葉が完全に正しいと強く信じていますが、私たちITの専門家は、従来のオンプレミス的な考え方を拡張して、クラウドテクノロジーを取り入れたり、学んだりすることを苦手としているのもまた事実です。
Citrix Apps and Desktops ServiceとMicrosoft Azureの組み合わせについて理解を深め、導入作業を支援するための方法として、このブログシリーズのその2では、お客様独自の環境を実装する際に、検討や計画が必要となる具体的なAzureコンポーネントのいくつかについて説明します。
作業を進める前に、弊社のエンタープライズアーキテクトであるKevin Nardoneによる、こちらの記事やこちらの記事をお読みになることをお勧めします。これらの記事では、Microsoft Azureでシトリックスのワークロードを展開する際に役立つすばらしいヒントやコツが紹介されています。既にこれらの記事を読まれた方もいらっしゃるでしょうか。答えが「はい」なら、これ以上の説明は不要なので、さっそくこのトピックの説明に入りましょう。
Azure環境の計画
1 — Azureのサブスクリプション
サブスクリプションは、Microsoftの1つまたは複数のクラウドプラットフォームやサービスを利用するための、Microsoftとの契約であり、ユーザーごとのライセンスまたはクラウドベースのリソースの使用量に基づいて料金が発生します。Azureのサブスクリプションには、特に、さまざまなワークロードを組み合わせた非常に大規模な環境を展開する場合には、管理が難しくなる制限値があります。これは、シトリックスのワークロードを展開する際には問題になる可能性があります。最終的に、Microsoftに連絡してvCPU、VM、ストレージの制限値を大きくすることが必要になる可能性があるためです。できる限り、シトリックスのワークロード専用のサブスクリプションを利用することを検討してください。
Azureのサブスクリプションの制限値の詳細については、こちらを参照してください。
2 — Azureのネットワーク
ネットワークはAzureの基本的なコンポーネントであるため、オンプレミスネットワークとのオーバーラップ、不適切なDNS構成、不適切なセキュリティグループなどの問題を回避するためにネットワークの分離を適切に計画してください。
Azureに環境を展開するお客様のお手伝いをした経験によれば、単一の仮想ネットワーク(VNET)を複数のサブネットに分離して利用し、各サブネット用に異なるDNSサーバーを使用するという傾向があることに気が付きました。これはお客様の問題を簡単に解決する方法のように見えますが、Citrix VDAを展開するときには問題が発生します。MCSは、その設計上、仮想ネットワークレベルで定義されたDNS構成を使用するからです。このため、それぞれのVDAについて、ネットワークインターフェイスレベルでDNS設定を変更する必要があります。これは、マシンカタログのマシン数が数百台になると管理不能になります。したがって、このアプローチは本稼働ではない、非常に小規模な展開でのみ実行可能ですが、それ以外では推奨しません。
シトリックスのワークロードを複数のネットワーク空間に分割し、そのネットワークオプションを個別に管理する必要がある場合は、専用のAzure 仮想ネットワークの作成、Azure 仮想ネットワークピアリングを使用して「本稼働用」仮想ネットワークに接続することを検討します。Microsoftの公式の定義によると、仮想ネットワークピアリングとは、2つのAzure仮想ネットワークをシームレスに接続できるようにする機能です。ピアリングされると、これらは接続用に1つの仮想ネットワークとして表示されます。ピアリングされた仮想ネットワーク内での仮想ネットワーク間のトラフィックは、Microsoftバックボーンインフラストラクチャ経由でルーティングされます。これは、同一物理ネットワーク内での仮想マシン間のトラフィックが、プライベートIPアドレス経由でのみルーティングされることと似ています。Azure 仮想ネットワークピアリングの詳細については、こちらを参照してください。
もう1つの重要な検討すべき点は、仮想ネットワークはレイヤー3のオーバーレイであり、そのため、レイヤー2のセマンティクスをサポートしないということです。
3 — Azureリソースグループ
リソースグループは、Azure Resource Managerがリソースをまとめてグループ化するために適用する単なる識別子です。経験則としては、類似するライフサイクルを共有するリソースを同じリソースグループに追加します。これに従うと、インフラストラクチャコンポーネントを保持するリソースグループ、ネットワーク、シトリックスのインフラストラクチャコンポーネント、VDA用の別のリソースグループの作成を検討することができます。
設計上およびAzureの制限のため、Apps and Desktop Serviceは単一のリソースグループに最大240のVMを配置します。つまり、マシンカタログのマシン数が240を超える場合は、複数のリソースグループに分散されます。さらに、スコープを限定したサービスプリンシパル（次に説明します）を使用しており、Citrix VDAのリソースグループを事前に作成する必要がある場合は、これらをマシンカタログの作成プロセスで利用する前に、完全に空にする必要があります。
リソースグループを拡張する必要がある場合は、Kevin Nardoneが彼のブログの記事でこのトピックを展開する見事な説明をしています。
4 — Apps and Desktops ServiceからAzureへのホスト接続の作成
Machine Creation Services（MCS）はApps and Desktops Serviceの重要なコンポーネントであり、1つのマスターイメージを活用して数百（または数千）ものVMを作成できるようにします。MCSを利用し、Azureでマシンをプロビジョニングするために、Citrix Cloudにお客様のAzureサブスクリプションへのアクセスを許可する必要があります。それには、Azureテナントアカウント内で関連するAzureリソースへのアクセス許可が割り当てられたアプリケーションサービスアカウント（Azure Active Directoryの「アプリの登録」）を使用します。この「アプリの登録」を構成するには、2つのオプションがあります。
- Citrix Cloudで自動的に作成する：Citrix Cloud/Studioは、アプリケーションサービスアカウントの作成をサポートしています。Citrix Studioユーザーが十分なアクセス許可が設定されたAzure Active Directoryアカウントを持っている場合、Studioでは、AzureテナントのAzure Active Directoryでサービスアカウントを生成するための資格情報の入力を求められます。その結果、「シトリックスが管理する」モデルが導入されることになり、サービスアカウントにはAzureサブスクリプションレベルで「共同作成者」のアクセス許可が付与され、このサービスプリンシパルにはAzure内のすべてのリソースへのアクセス許可が自動的に付与されます。
- Azure内で手動で作成する： 状況によっては、Citrix Cloudに対してサブスクリプションレベルのアクセス許可を提供することに、お客様が不都合を感じることもあるため、スコープを限定したサービスプリンシパルの利用が必要になる可能性もあります。このアプローチを選択した場合、Azureポータルでアプリケーションの登録を手動で作成し、特定のAzureリソースグループ、ネットワーク、ストレージアカウントに対する必要なアクセス許可を割り当て、Citrix Cloud内で手動でホスト接続を作成する必要があります。スコープを限定したサービスプリンシパルの作成方法に関する詳しいチュートリアルについては、シトリックスのサポート記事を参照してください。日本語のブログはこちらです。
5 — Azure StorageアカウントとManaged Disks
Azure Managed Disksによって、ストレージアカウントに関する複雑な作業がすべて解消され、IOPS制限、低速なイメージのコピー、追加のアクセス許可の割り当てなどを心配する必要がなくなります。このオプションを使ってシトリックスのワークロードを、展開しようとしているAzureリージョンで利用できる場合は、展開の選択肢としてManaged Disksを検討してください。
このトピックでは詳しく説明しませんが、弊社のシニアソフトウェアエンジニアの1人であるKarl Gibsonによるこちらの詳しいブログの記事をぜひ確認してください。
6 — AD Domain Services
Active Directoryは、Citrix環境が機能するために不可欠なコンポーネントであり、環境でのユーザーの認証、マシンのドメインへの参加、グループポリシーの適用など、多くの（実に多くの）機能を提供します。そのため、Cloud Connector、VDA、Master Image、その他のメンバーサーバーをADドメインに参加させるために、Azure環境には少なくとも数台のドメインコントローラーを用意する必要があります。
さらに、オンプレミスのADをAzureに拡張しようとしている場合は、VPNまたはExpressRouteを導入してオンプレミス環境をAzure環境に接続する必要があります。これによって、Azureでドメインコントローラーを稼働させて、オンプレミスのAD環境に参加させることができます。
最後に、Azure ADについてよくわからないという場合は、従来のAD環境とは非常に異なる点があるため、残念ながら現時点ではCitrix環境用の選択肢として適切とは言えません。そうは言うものの、Azureのサービスオプションとしてのドメインコントローラーである、Azure AD Domain Servicesを利用するという選択肢があります。これを利用する方法についての詳細は、弊社プリンシパルアーキテクトであるLeo Singletonのこちらの記事をご覧ください。
重要ポイント
Azure環境でのシトリックスの推奨事項の一覧の締めくくりとして、次のポイントを覚えておいてください。
- マシンカタログを作成するときには、Azureでマスターイメージが停止済み/割り当て解除の状態になっていることを確認します。
- StudioでAzureのマシンカタログを作成する際に発生する問題の大半は、サブスクリプションの制限、またはスコープを限定したサービスプリンシパルを利用する際の誤ったアクセス許可の割り当てに関連しているため、この2つには十分に注意してください。
- Azure VMは、「オンデマンド」プロビジョニングと呼ばれる処理によってプロビジョニングされるため、マシンカタログの作成後でも、AzureでVMが存在していない場合があります。これは通常の動作なので、混乱しないでください。この仕組みをさらに深く理解するには、こちらの記事をお読みください。
- Azureの物理CPUと仮想vCPUの比率は1:1であるため、基になるハイパーバイザーでオーバーサブスクリプションとなる状況がないことを意味します（A0インスタンスを除く）。また、VMはNUMAアライメントに従っており、このことはマルチユーザーサーバーのワークロードのサイズを設定する際に特に重要です。
- 現時点では、Azure File Sharesを利用してユーザープロファイルを格納したり、フォルダーをリダイレクトしたりすることはできません。UPMプロファイルの高可用性を実現するには、代わりにMicrosoftの記憶域スペースダイレクトを利用することを検討してください。
Marc Benioff氏は、「クラウドはあらゆる規模の企業にサービスを提供します」とも述べています。場所、方法、時に関係なく、機会があれば、クラウドを導入し、Citrix Apps and Desktops Serviceも導入することをお勧めします。環境を展開する際のヒントとコツを紹介している、このAzureシリーズの最後のブログ記事もぜひお読みください。