Azure VMware ソリューションアーキテクチャおよびデプロイガイド

このドキュメントの目的は、Citrix Virtual Apps and Desktops (CVAD) を Azure VMware ソリューション (AVS) にデプロイしようとしている企業にアーキテクチャガイダンスを提供することです。このガイドでは、以下のトピックについて説明します。

このドキュメントでは、Citrix Virtual Apps and DesktopsのワークロードをAVSに移行するための一般的なガイダンスとベストプラクティスを提供します。

アーキテクチャ

このアーキテクチャは、Citrix Virtual Apps and Desktopsサービス (Citrix DaaS)、Microsoft Azure、および Azure VMware ソリューション (AVS) で構成されています。

Citrix Virtual Apps and Desktopsサービス

Citrix Virtual Apps and Desktopsサービスは、Windows、Linux、Web、またはSaaSアプリケーションとデスクトップをあらゆるデバイスに安全に配信します。安全なデスクトップとアプリケーションの提供は、今日のモダンなデジタルワークスペースを強化します。Citrix Virtual Apps and Desktopsは、高度な管理とスケーラビリティを提供します。Citrix、あらゆるネットワーク上でリッチなマルチメディア体験を提供でき、ユニバーサルデバイスサポートを備えたセルフサービスアプリケーションを提供します。Citrix、ラップトップ、タブレット、スマートフォン、PC、Macなど、さまざまなモバイルエンドポイントをサポートしています。

ハイブリッドクラウドソリューションとして利用できるCitrix DaaSでは、エンタープライズクラウド戦略に最適なワークロード展開オプションを選択できます。Citrix DaaSをAzureに導入すると、IT部門はパブリッククラウドの伸縮自在な規模でインフラストラクチャサービスを柔軟に提供できます。この伸縮自在性により、現在の投資をオンプレミス環境から Azure に簡単に拡張および統合できます。

テストワークロードの制御と管理には、Citrix Cloud 仮想アプリケーションおよびデスクトップサービスを使用しました。数字は特に、シトリックスのサーバーOS仮想配信エージェント（VDA）を実行する単一の仮想マシンインスタンスのスケーラビリティとパフォーマンスに焦点を当てています。

Microsoft Azure と Azure VMware ソリューション

Microsoft Azure は、Microsoft が管理するデータセンター全体にアプリケーションを迅速にデプロイできる、信頼性が高く柔軟なクラウドプラットフォームです。Azure Cloud Services で Citrix DaaS ワークロードをプロビジョニングすることで、企業は内部インフラストラクチャにかかる費用を回避できます。代わりに、ユーザーワークロード用のコンピューティング、ネットワーク、およびストレージリソースを Microsoft に任せることができます。

AVS には以下の制限があります。

AVS上のCitrix スの価値 — 選択の幅と移行のしやすさ、親しみやすさ

Azure VMware Solution は、専用のベアメタル Azure サーバ上に構築された vSphere クラスタを含む、マネージド型の VMware ソフトウェア定義データセンター (SDDC) です。最小導入は 3 ノード (ホスト) で、SDDC クラスタあたり最大 16 ノードです。SDDC のすべてのデプロイには、管理用の vCenter サーバ、Azure ベースのストレージを備えた vSAN、vSphere ホスト、ネットワーク用の NSX-T が含まれます。SDDC は、サービスの料金に含まれる内部の Express Route 接続を介して Azure テナントに接続されます。インフラストラクチャとソフトウェアはMicrosoft が管理し、SDDC で実行されるワークロードはお客様が管理します。

AVSは完全なVMwareデプロイメントであるため、オンプレミスのVMwareデータセンターと同じスキルとプロセスを使用してAVSデプロイを管理できます。Azure VMware ソリューション (AVS) の使用には次の利点があります。

Azure VMware ソリューション (AVS) を使用して、オンプレミスデータセンターの vSphere でプロビジョニングするのと同じように、Citrix VDA ワークロードをプロビジョニングします。

アーキテクチャとビルドのガイダンス

このセクションでは、AVS 環境のアーキテクチャの概要を説明し、高レベルのガイダンスを提供します。ここでは、AVS SDDC内でCitrix環境を構築し、オンプレミスのデータセンターをCitrix Cloudに接続する方法を示します。

アーキテクチャ図

以下の図は、AVS SDDCにCitrix VDAホストがあるAVS環境のアーキテクチャを示しています。このアーキテクチャでは、オンプレミスデータセンターへの ExpressRoute 接続を使用します。

AVS エクスプレスルートアーキテクチャ

図:Azure VMware ソリューションエクスプレスルートアーキテクチャ

オンプレミスのデータセンターで ExpressRoute 接続を利用できない場合は、サイト間 VPN と仮想 WAN を使用して AVS SDDC に接続します。下の図は、サイト間 VPN アーキテクチャを示しています。

AVS S2S VPN アーキテクチャ

図:Azure VMware サイト間 VPN アーキテクチャ

Citrix Virtual Apps and DesktopsサービスはAVSをサポートしています。Azure VMware ソリューションは、Azure インフラストラクチャによって作成された vSphere クラスタを含むクラウドインフラストラクチャを提供します。オンプレミス環境でvSphereを使用するのと同じ方法で、Citrix DaaSとAVSを使用してVDAワークロードをプロビジョニングします。

AVS 向けCitrix ビルドガイダンス

Azure での AVS ソリューションの詳細なデプロイについては、 こちらをご覧ください。このセクションには、移行を正常に行うための大まかな手順とその他の情報が含まれています。

デプロイは以下のステップで構成されます。

  1. ホストクォータのリクエスト:

  2. Microsoft.AVS リソースプロバイダーを登録します。

  3. ネットワークチェックリスト

  4. Azure VMware ソリューションプライベートクラウドの作成:

  5. Azure VMware ソリューションプライベートクラウドへのアクセス:

  6. オンプレミスのデータセンターを Azure に接続

  7. Azure VMware ソリューション環境の検証:

  8. AVS VMがインターネットにアクセスできるようにします。

  9. Citrix インフラストラクチャ VM の導入:

ベストプラクティスに関する推奨事項

AVS SDDC を構築する際には、以下のベストプラクティスと推奨事項が提供されます。

スケーラビリティテスト

3ノードクラスターの容量を決定するために、各AVSノードにCitrix 共有デスクトップホストをロードし、2つのワークロードを実行しました。テストに使用した 2 つのワークロードを以下に示します。

デュアル vCPU ナレッジワーカープロファイルは、ユーザー密度の下限を提供します。軽量なシングル vCPU タスクワーカープロファイルは、ユーザー密度の上限を提供します。これら 2 つの限界は、ユーザー密度の期待される範囲です。

Login VSIは、エンドユーザーコンピューティングおよびアプリケーション市場向けのベンチマークおよび負荷テストにおける業界標準です。Login VSI のワークロードは、Citrix、Microsoft、VMware が提供する VDI およびサーバベースのコンピューティングソリューション専用に開発されています。Login VSI を使用すると、デスクトップとアプリケーションのパフォーマンスを最大化しながら、最小限のコストで本番環境の規模を適正化できます。このテスト環境では、Login VSI バージョン 4.1.40 を使用して、VMware 3 ノードクラスタに対してシミュレートされたタスクワーカーセッションとナレッジワーカーセッションを作成しました。ログインエンタープライズの詳細については、次を参照してください。 https://www.loginvsi.com

セッションを正常に完了したユーザーの数は、実際の状況下での重要なパフォーマンス指標となります。この値は VSImax セッションカウントと呼ばれ、比較分析に使用されます。テストの開始時には、システム上の1人のユーザーのみのベースライン値が取得されます。ログインVSIワークロードは、ユーザー応答時間がベースライン値を大幅に上回ったことを観察して、VSImaxセッション数を計算します。

ラボ環境のセットアップ

Citrix VDAホストは、3ノードクラスタ上のAVS環境で構築されました。各クラスタノードは、18コアのインテルXeonゴールド6140 2.30 GHz CPUと512 GiB RAMを搭載したDell PowerEdge R640サーバでした。Citrix Cloud ConnectorとログインVSIランチャーはAzure仮想ネットワークにインストールされました。ランチャー上のCitrix Workspaceクライアントは、内部のExpressRoute接続を介してVDAホストに接続していました。ラボセットアップの図を以下に示します。

ログイン VSI AVS ラボ環境

図:ログイン VSI AVS ラボ環境

すべてのテストランでは、Citrix ポリシー、Windows Server 2019、Office 2016、および Windows Defender のデフォルトのインストール設定が使用されました。

方法論

すべてのテストでは、Windows Server 2019とCitrix Server OS VDAバージョン2106のホスト型共有デスクトップモデルが使用されました。まず、最も効率的な vCPU とメモリ構成を特定するために、シングルサーバースケーラビリティ (SSS) に注目しました。SSSの結果を使用して、3ノードクラスタ上のユーザーを最大化するための最適な構成を選択しました。システム上のユーザー数を最大化するための最善の方法を決定した後、Login VSI を使用して可能な限り最大の負荷を生成しました。

これらのテストは、3 ノードクラスタで想定されるおおよそのユーザー数を特定するのに役立ちます。結果はさまざまで、作業負荷に大きく影響されます。ご自身でワークロードをテストし、そのワークロードに最適な構成を選択することを強くお勧めします。

スケーラビリティテスト結果

このセクションでは、ラボ環境内でAVSで実行されるスケーラビリティテストについて説明します。LoginVSIを使用して、一般的な3つのVDAホスト構成の予想ユーザー数を調べました。タスクワーカープロファイルの結果は次のとおりです。

構成 vsiMax ユーザー コアあたりのユーザー数
4 vCPU 16 GiB RAM 18 4.5
8 vCPU 16 GiB RAM 30 3.75
8 vCPU 24 GiB RAM 34 4.25

表:vsiMax シングルサーバースケーラビリティの結果

SSS テストの結果によると、コンピューティングリソースの最も効率的な使用は 4vCPU x 16 GiB の RAM 構成でした。この情報を使用して、3 ノードクラスタをロードするための VM 密度を決定しました。200個のvCPUを使用して50台の4vCPU VDAホストを構築しました。次に、クラスターの負荷テストを実行して、この構成のクラスターのスケーラビリティを判断しました。負荷テストの結果を以下の表に示します。

構成 タスクワーカー ナレッジワーカー
シングルサーバ (4xCPU 16 GiB RAM) 18 13
3ノードクラスタ上に50台の仮想マシン（Citrix VDA） 602 378

表:16 GiB RAM を搭載したサーバー 2019 4vCPU のプロファイルタイプ別の VSI 最大スコア

ブログ「5 と 10 のルール」では、オンプレミスデータセンターの SSS ガイダンスを提供しています。4vCPUの結果は、物理コアあたり約10人のCVADセッションユーザーという彼の推奨と一致しています。4つのvCPUでは、Citrix セッションホストごとに2つの物理コア（4つのハイパースレッドコア）を使用していました。10というルールを適用すると、VMあたり約20人のユーザーが得られ、vsiMaxが18の場合はブログに記載されているマージンの範囲内です。AVSはオンプレミスのデータセンターで想定しているのと同じVMwareノードを使用しているため、これらの結果は予想どおりです。

以前のスケーラビリティテストによると、同じホスト上で複数のVMが並行して実行されている場合、1つのVMが必ずしも直線的に拡張されるとは限りません。タスクワーカーでは、900人（18×50）のユーザーに近づくと予想していましたが、vsiMaxは602人を獲得しました。ナレッジワーカーでは、約650（13 x 50）に達すると予想していましたが、最も多く観察されたのは378でした。

注:実行中のすべてのセッションを起動してログオンできました。しかし、ユーザーエクスペリエンスは大幅に低下し、vsiMaxの推奨ユーザー数はセッション数の約3分の2でした。

スケーラビリティ分析

このセクションでは、テスト実行が行われた時点の VMware パフォーマンスグラフを提供します。参考として、Windows サーバ仮想マシンとクラスタノードの両方を示します。LVS-SVR-25は50台のWindowsサーバを表し、ESX17-R16はクラスタノードを表します。パフォーマンスのボトルネックとなる最も一般的な4つの領域、CPU、メモリ、ディスク、ネットワークを確認します。

CPU

CPUグラフには、Windowsサーバ仮想マシンとクラスタノードの両方で使用可能なキャパシティに基づく平均CPU使用率が表示されます。単一サーバーのピークは 85% を下回り、ノードのピークは約 97% です。ただし、これらのグラフは両方とも、VMwareコンソールでは確認できなかった最大CPU使用率ではなく、平均CPU使用率を示しています。

単一サーバの CPU 使用率

図:単一サーバの CPU 使用率

クラスタノードの CPU 使用率

図:クラスタノードの CPU 使用率

VSI Maxのパフォーマンス指標のうち2つを見ると、何が起きていたかをより正確に把握できます。Zip Low Compression (ZLC) とZip High Compression (ZHC) のインジケータは、CPU 負荷の高いアクションに関連付けられています。タスクワーカーのプロファイルでは、操作がベースラインである約 1 秒から、ほぼ最大 13 秒に及ぶことがわかります。その遅延の大部分は、最大6秒だった600人のユーザーマークを過ぎると倍増します。ユーザー数が 380 を超えると、ナレッジワーカープロファイルでも同様の遅延が増加します。この動作により、CPU が実際にフルキャパシティに達しているという結論に至ります。通常、このタイプのワークロードのボトルネックはプロセッサです。

タスクワーカー Zip 圧縮パフォーマンス

図:タスクワーカーの Zip 圧縮パフォーマンス

ナレッジワーカー Zip 圧縮パフォーマンス

図:ナレッジワーカー Zip 圧縮パフォーマンス

メモリ

単一サーバーとクラスターノードの両方のメモリ使用率は予想どおりです。どちらも使用可能なメモリの約 75%-80% を消費しており、これがスケーラビリティのスイートスポットです。ここには予想外の発見はありません。

単一サーバーのメモリ使用率

図:単一サーバーのメモリ使用率

クラスタノードのメモリ使用率

図:クラスタノードのメモリ使用率

ディスク

メモリ使用率と同様に、ディスク使用率は予想どおりです。単一サーバーのディスク遅延は最大1ミリ秒ですが、クラスターノードのピークは5ミリ秒で、どちらも予想されるパフォーマンスパラメータの範囲内です。

単一サーバーのディスク使用率

図:単一サーバーのディスク使用率

クラスタノードのディスク使用率

図:クラスタノードのディスク使用率

ネットワーク

ネットワークトラフィックは最後に確認すべき指標です。1 台のサーバが約 2000 Kbps のトラフィックのテスト中にピークを示し、クラスタノードでは 100,000 Kbps 未満のピークを示します。

単一サーバーのネットワーク使用率

図:単一サーバーのネットワーク使用率

クラスタノードネットワーク使用率

図:クラスタノードのネットワーク使用率

プロジェクトの開始時には、AVS と Azure 間の内部の ExpressRoute (ER) 接続に関する懸念がありました。具体的には、チームは Azure のクライアントが AVS SDDC への ER 接続を使用すると、回線が過負荷になる可能性があることを懸念していました。Azure Monitor を使用して、850 ユーザーという最も負荷の高い状況で、1 秒あたりのパケット数 (PPS) とビット/秒 (BPS) を確認しました。

負荷テストで観察した結果は心強いものです。850 人のユーザーは、50 Mbps 未満のスループットで 1 秒あたり約 17,240 パケットを生成していました。標準的な ExpressRoute 接続は約 100,000 PPS と 1 Gbps のスループットを処理するため、ER 接続は約 4000 人のユーザーを快適にサポートできるはずです。

エクスプレスルートの 1 秒あたりのパケット数

図:1 秒あたりのエクスプレスルートパケット数

ExpressRoute ビット/秒

図:ExpressRoute ビット/秒

拡張性に関する推奨事項

分析の結果、私たちのテストではCPUの処理能力がボトルネックだったことが分かりました。検討した他の3つの指標（メモリ、ディスク、ネットワーク）はすべて許容範囲内でした。通常、CPUの処理能力はスケーラビリティの制限要因です。ノードあたり72コアの3ノードシステムでは、合計216個のコアが使用できました。ハイパーバイザーとインフラストラクチャ VM のコンピューティングキャパシティをいくらか確保すれば、約 200 個の vCPU をワークロードに使用できます。

これらのテスト結果に基づくと、AVSでのデプロイを計画する際に従うべき経験則は、軽いワークロードの場合はvCPUあたり3.5ユーザー、重いワークロードの場合はvCPUあたり約2ユーザーです。

これらは管理されたラボで生成された球場番号です。これらは、テストした 2 つのワークロードプロファイルで 3 ノードクラスタで想定されるユーザー数の概算にすぎません。ご自身でワークロードをテストし、そのデータを使用してワークロードに最適な構成を決定することを強くお勧めします。

移行ガイダンス

最初のステップは、シトリックスのインフラストラクチャをCitrix Cloud に移行することです。次のステップは、VMwareワークロードをAVSに移行することです。オンプレミスのデータセンターと AVS SDDC の間で VMware ワークロードを移動するには、VMware の HCX アプライアンスを使用することをお勧めします。

Citrix インフラストラクチ

VMwareからAzureへの移行の詳細な手順については、 こちらをご覧ください。このリンクは、Azure VMware ソリューションではなく Azure インフラストラクチャに移行することを前提としています。Citrix インフラストラクチャをAVSに移行する場合、移行計画に含めるべき主な手順は次のとおりです。

Citrix ワークロードの移行

オンプレミスのデータセンターとクラウドホスト型の VMware 実装間でワークロードを移行するには、VMware の移行ツール HCX を使用するのが最善の方法です。HCXのコア機能は、VMware vSphere環境間で仮想ワークロードを透過的に移行することです。

注:オンプレミスのデータセンターと AVS デプロイメント間の ExpressRoute 接続を含め、HCX の要件は厳格です。 要件の全リストはこちらをご覧ください。

HCX には、オンプレミスのデータセンターに 1 つずつ、AVS SDDC に 1 つずつ、複数のアプライアンスペアが必要です。

Citrix ワークロードの移行計画

ワークロードの移行を計画するための大まかな手順は次のとおりです。これらの手順の詳細については、VMware のサイトを参照してください。

  1. 移行するワークロードのインベントリを生成します。これには以下が含まれます。

    1. Citrix VDAホスト、Citrix PVSサーバー、およびそのデータベース。

    2. ユーザーおよびアプリケーションデータをホストするファイルサーバー。

    3. ネットワークとパフォーマンスの要件を理解してください。

  2. 移行できないワークロードのインベントリを生成します。

    1. メインフレームなどの非x86プラットフォーム上のワークロード。

    2. 移行中のCitrix アプリケーションとの統合と依存関係を理解してください。

  3. IP アドレスの戦略を立てる:

    1. 理想的には、Citrix ワークロードは既存のIPアドレスを保持し、Network Extensionアプライアンスを使用してクラウドに移行できます。

    2. IPアドレスを維持できないワークロードには、移行のためのIP移行計画が必要です。これには、サブネット全体がクラウドに移行していないサブネット上のすべてのワークロードが含まれます。

  4. すべてのトラフィックフローを理解する:

    1. Citrix サーバーからオンプレミスデータセンターへの下りトラフィックは課金されます。システムとそのデータを移行します。

    2. どのシステムをまとめて移行すべきかを把握してください。たとえば、PVSとそのSQLデータベース、または基本イメージを共有するすべてのCitrix サーバーなどです。

    3. 追加のレプリケーショントラフィックとネットワーク拡張トラフィックを考慮してください。

  5. オンプレミスデータセンターとAVSクラスター間の移行パスにあるすべてのオンプレミスネットワークデバイスを含むトポロジー図を生成します。

    1. ネットワークデバイスの監視を設定します。帯域幅が減少したり、遅延が大幅に増加したりする状況に注意してください。

    2. 移行トラフィックのボトルネックに注意してください。この監視は、使用率の高いサーバをホットモードまたはウォームモードで移動する場合に特に重要です。使用率の高いサーバーには、PVSサーバーまたはSQLデータベースサーバーが含まれます。

    3. HCX では、サイト間で 100 Mbps 以上の接続が必要です。

  6. ワークロードで使用されるすべての外部ストレージデバイスを把握してください。

    1. 外部ストレージデバイスに依存するアプリケーションをすべて特定します。

    2. ライセンシングにドングルなどの物理的な外部デバイスに依存するアプリケーションを特定します。

  7. ワークロードの使用率レベルを確認し、ワークロードの使用率が最も低い時間帯に移行を計画します。この方法では、ユーザーへの影響が軽減されます。

  8. 次のことを念頭に置いて、移行ウェーブを計画してください。

    1. 基本イメージを共有するCitrix ワークロードなど、相互に依存するアプリケーションのグループを互いにできるだけ近づけてください。

    2. 大規模で複雑なアプリケーションを独自のウェーブに分離します。

    3. 移行中はネットワークトラフィックが増加します。

    4. ネットワークトラフィックを減らすため、ワークロードを25～50台のサーバに抑えます。

    5. ソースとデスティネーションのストレージ IOPS を監視します。

Citrix ワークロード移行プロセス

HCXを導入して移行を計画したら、次のステップはCitrix ワークロードの移行です。このプロセスの詳細については、 こちらをご覧ください。

  1. HCX アプライアンスに十分なリソース (CPU とメモリ) があることを確認します。HCX アプライアンスがどの分散リソーススケジューラ (DRS) オートメーションにも含まれていないことを確認します。

  2. すべての HCX アプライアンスの High HA 再起動ポリシーを設定します。

  3. WAN インターコネクトアプライアンスは、専用の IPsec トンネルを介してワークロードを複製します。

  4. ネットワーク拡張アプライアンスは、専用の IPsec トンネルを介してレイヤー 2 ネットワーク拡張を提供します。

  5. 拡張ネットワークは、移行が完了するまで SDDC 内で分離されます。

  6. 拡張ネットワークは解体され、SDDC を介して通常のルーティングが復元されます。

移行プロセスには次の 3 種類があります。

Citrix 環境を移行するには、次の順序を使用してください。

  1. PVS および MCS イメージ (データ移行によるファイルとフォルダ) の移行。

  2. HCX一括移行を使用してPVSサーバーとデータベースを移行します。

  3. 新しいAVS VMを使用して、マシンカタログとデリバリーグループを再作成します。

  4. クラウド内のサーバーを再起動してオンラインにします。

  5. 移行後のカットオーバーにより、オンプレミスリソースが廃止されます。

ベストプラクティスに関する推奨事項

Azure に移行する際には、移行の計画に役立つ次のベストプラクティスと推奨事項が提供されます。

結論

オンプレミスのCitrix デプロイメントをMicrosoft AzureのAzure VMwareソリューションに移行するための大まかなガイダンスを提供しました。ガイダンス全体および「参考資料」セクション内の URL リンクには、移行の詳細な手順が記載されています。企業ですでにVMware vSphereを実行している場合は、AVSへの移行が最も簡単な移行方法です。企業がオンプレミスで別の仮想化ソリューションを実行している場合でも、VMware HCX アプライアンスと AVS を使用すれば Azure へのスムーズな移行が可能になります。

参照ドキュメント