このブログは、2017年9月にCitrix本社のマイクロソフトソリューションエンジニアリング部門のOle Larsenが執筆したブログ「Provisioning XenDesktop on Azure Just Got a Lot Faster」を日本語訳したものです。
XenAppおよびXenDesktopのAzure Resource Managerのサポートは継続的に改良されており、現在、仮想マシンのオンデマンドプロビジョニングが実装され、ストレージコストの削減、マシンカタログの作成と電源操作の大幅な高速化が可能になりました。
改良のポイント
- より速いマシンカタログプロビジョニング
- 大幅に高速な電源操作
- Citrix Studioでより応答性の高い電源状態の表示
- プールされたマシンのストレージコストの削減
- カタログを削除するときのパフォーマンスの向上
オンデマンドプロビジョニング
以前は、Azureでのプロビジョニングは、従来のXenDesktopと同じ方式でした。この場合、カタログ作成時にVDAのインストールされた仮想マシンが作成されていました。 作成後は、マシンが「存在する」とみなされるため、マシンの起動および停止が可能になります。 これは確かにAzureで実現できる方法ですが、以下の3点を考えてみると、Azureのクラウドに最適化された方法でないことが理解できます。
1点目はAzureマシンの作成です。マシンを作成した後は、マシンは実行中の状態となります。これは、Azureではマシンが作成されたということはすぐに何かの用途で必要だとみなされるためです。しかし、XenDesktopのカタログにおいては、マシンは初期状態では停止しています。ですので、カタログへのマシン作成後に各マシンを停止します。これはAzure環境では不要な動作です。
2点目は、Azure Portalで停止したマシンの状態についてです。電源状態は「停止済み(割り当て解除)」として報告されます。 この状態ではAzureコンピュート要素に対して課金はされません。これはつまり、マシンが存在していないとみなされるからです。XenApp/XenDesktopがマシンをAzureに割り当てた直後に停止すると、サブスクリプションに対する料金が発生しないように、Azureはそのマシンを割り当て解除してくれます。Azure Portalでのそのマシンの状態は、ディスクやNICがどのように構成されているかなどの記録がほとんどとなります。
3点目は、「停止済み(割り当て解除)」のVDAを開始した際に、Azure Portal上での電源状態が一瞬「作成中」と表示されるところです。つまり、既存のマシンの起動に要する時間は、新しいマシンの作成とほぼ同じです。
このことを考慮すると、カタログを作成したときにマシンを作成したとしても、実際には使用されずにすぐに解除されるため、あまり意味がないといえます。 加えて、必要がないときはマシンを停止するだけでなく、削除もできるということになります。以降のセクションでは、これが電源管理のパフォーマンスの改善とストレージコストの削減にどのように寄与するのかを検討します。
クラウドの背景にある考え方の一つは、需要に応じてリソースをスケールアップしたりダウンさせたりするところにあります。XenApp/XenDesktopはより動的なクラウドにおける一般的なリソース使用の考え方にあわせて一步踏み出したことになります。
オペレーティングシステム(OS)ディスクのリセット
マシンを起動する仕組みを見る前に、プールされたXenDesktopマシンと専用のXenDesktopマシンの違いを確認する必要があります。 プールされたマシンは常にリセットされ、マスターイメージを完全にコピーしたOSディスクから起動され、専用のマシンは最後に使用されたディスクおよびディスクの内容と同じものから起動されます。
OSディスクをリセットするには、新しいディスクを使用してマシンを再作成します。 つまり、既存のマシンと古いOSディスクは削除され、マシンはマスターイメージの新しいコピーで再作成されます。 従来のXenDesktopワークフローでは、マシンを起動する直前にOSディスクのリセットが要求されていました。Azureの環境のおいては、マシンが不要になったタイミングで削除できます。また、マシンが必要なタイミングで、マスターイメージから簡単に再作成できます。このアプローチの利点は次のとおりです。
- 削除する必要がある既存のマシンが存在しないため、マシンの起動が早くなります。
- マシンが削除され再作成されている間に、電源状態は正しく表示されるようになります。
- Azure Portalからマシンを起動することはできません。 以前は、Azure Portalから起動した場合、プールされたマシンのディスクがリセットされる前の正しくない状態から起動してしまいました。 現在の実装では、Azure Portalではマシンが実行されていないと表示されないので、間違ったOSディスクで誤って起動することはありません。
パフォーマンスベンチマーク
Azureのロケーションや時間帯などの多くの要因がパフォーマンスに影響します。 パフォーマンス特性はいつでも変わる可能性がありますが、次の表はCitrix Cloudの最新バージョンのXenDesktopのパフォーマンスが向上した典型例です。
1000台のプールされたマシンの時間[時間:分] | 前のバージョン | 現在 |
---|---|---|
カタログを作成する | 8:30 | 2:30 |
すべてのマシンを起動する | 2:30 | 1:00 |
すべてのマシンを停止する | 2:00 | 1:00 |
カタログイメージを更新する | 1:30 | 1:00 |
カタログの削除(マシンが停止しました) | 6:30 | 1:00 |
プールされたマシンのストレージ節約
プールされたマシンのOSディスクは、シャットダウン後にマシンを起動しても再利用されないにも関わらず、不要になったディスクのストレージ費用が発生していました。 以前は、マシン自体が削除されず、OSディスクを切り離すことができないため、マシンを使用していないときにOSディスクを削除できませんでした。オンデマンドプロビジョニングにより、マシンが削除されて使用されていないときにOSディスクを削除できるようになりました。 これにより、勤務時間外など、日常的にマシンをシャットダウンするお客様にとって、大幅なコスト削減を実現できます。
マシンの電源状態とAzureリソースの表示
新しいオンデマンドプロビジョニングモデルは従来といくつかの相違点があります。
- Citrix Studioでマシンが「オフ」と表示されている場合、そのマシンはAzureには存在しません。つまり、サブスクリプションで仮想マシンを表示するときにAzure Portalに表示されません。 ネットワークインターフェースとIDディスクは常に存在します。
- プールされたマシンの場合、OSディスクはマシンが存在するときにのみ存在します。
- マシンが専用マシンの場合、OSディスクは、マシンの電源をオンにして初めて作成され、マシンが削除されるまでストレージに残ります。
- マシンが稼働しているときはいつでも、Azure Portalに表示されます。
- 既存のカタログおよび既存の手動で作成されたカタログ内のマシンは、オンデマンドプロビジョニングの対象ではなく、稼動していなくてもAzure Portalに表示されます。 既存のカタログのマシンをオンデマンドプロビジョニング対応のマシンに自動的に変換できるように将来的に計画しています。
Azure コアクォータの管理
Azureのリソースはサブスクリプションクォータの対象となり、ネットワークインターフェースとコアクォータが主な該当例です。 長いプロビジョニングプロセスを開始する前に、サブスクリプションに十分なネットワークインターフェースがあり、利用可能なコアを計算していることを確認します。 その他のクォータと条件もありますが、ここでは対象外とします。
N個のマシンでカタログを作成している場合、またはN個のマシンを既存のカタログに追加しているとします。 N台の新しいマシンをプロビジョニングする前に、XenDesktopはサブスクリプションがN個の追加のネットワークインターフェースとN倍の “1台のマシンあたりのコア数”の容量を持つことを確認します。 ネットワークインターフェースはプロビジョニングの過程で割り当てられますが、コアは必要なときにオンデマンドでマシンが作成されるためです。
一部またはすべてのマシンの電源がオフになっている間、コアは異なるワークロードで使用される可能性があるため、プロビジョニングされたマシンの起動時に使用できるコア数が不十分な場合があります。 コアのクォータとネットワークインターフェースのクォータが適切に設定されていれば、一般的にこれは起こりませんが、念の為マシンを起動するときに十分なコアが使用できることを確認してください。
制限事項
- カタログを削除する時にマシンを残すことは現在サポートされていません。
- Personal vDiskはサポートされていません。