Cloud Connectorのスケールおよびサイズの考慮事項
Citrix DaaS（旧称Citrix Virtual Apps and Desktopsサービス）のサイジングとスケーラビリティを評価する場合、すべてのコンポーネントを考慮する必要があります。特定の要件に応じて、Cloud Connectorと顧客管理StoreFrontの構成を調査し、テストします。マシンのサイズを縮小すると、システムのパフォーマンスに悪影響を与える可能性があります。ここでは、テスト済みの最大容量の詳細と、Cloud Connectorのマシン構成に関するベストプラクティスの推奨事項を提供します。
概要
この概要のすべての結果は、詳細セクションに記載されたとおりに構成されたテスト環境での結果に基づきます。異なるシステム構成では、異なる結果になる可能性があります。
テストの主な結果：
- Citrix DaaSのサイジングとスケーラビリティ
- 5,000未満のワークステーションVDAをホストするサイトには、4基の仮想CPUの3つのCloud Connectorセットを推奨します。
- これはN+1高可用性構成です。
- 1,000台の仮想マシンをプロビジョニングするには平均140分かかります。
- 5,000未満のワークステーションVDAをホストするサイトには、4基の仮想CPUの3つのCloud Connectorセットを推奨します。
- Citrix Virtual Desktops Essentials
- Azure Standard_A2_v2仮想マシンでホストされる2台のCloud Connectorは、1,000台のWindows 10仮想マシンに推奨されます。
- AzureでホストされているWindows 10仮想マシンで1,000セッションの開始に要する時間は20分未満です。
- テストでは、ユーザーがStoreFrontにログオンしてからデフォルトの設定で機能するVDIデスクトップを受信するまでに約44秒かかります。
- Azureで1,000台のWindows 10仮想マシンをプロビジョニングするには平均8時間かかります。
- Citrix CloudはCloud Connectorサービスを管理し、顧客はマシンを管理します。
- Citrix Virtual Desktops Essentialsのセッション起動テストはNetScalerアプライアンスを使用しました。他のすべてのセッション起動テストでは、StoreFrontに直接接続しています。
テスト方法
負荷を追加し、環境コンポーネントのパフォーマンスを測定するためのテストが実施されました。コンポーネントの監視では、パフォーマンスデータと手順のタイミング（ログオン時間、マシン作成時間など）のデータを収集しました。必要な場合は、VDAとセッションをシミュレートするために、独自のCitrixシミュレーションツールが使用されました。これらのツールは、実際のセッションやVDAをホストするために必要なリソースがなくても、従来のVDAやセッションと同様にCitrixコンポーネントを使用できるように設計されています。以下のテストが実施されました：
- セッションログオンストーム：ログオンが集中する期間をシミュレートするテスト
- VDA登録ストーム：VDAの登録が集中する期間をシミュレートするテスト。たとえば、アップグレードサイクル後または停止から回復した後などです。
- Machine Creation Servicesのプロビジョニング：イメージのコピー、Active Directoryアカウントの作成、マシンの作成などのタスクを実行する時間を測定するテスト。
これらのテストから収集したデータを使用して、Cloud Connectorのサイジングの推奨事項を作成しました。テスト実行の詳細は次のとおりです。
セッションログオンストームテスト
セッションは、顧客管理StoreFrontサーバーで開始されます。1,000セッション、5,000セッション、20,000セッションのテストが各環境で実行されました。StoreFrontのログオン、リソースの列挙、ICAファイルの取得、アクティブなデスクトップ時間が収集されました。アクティブなデスクトップ時間は、ICAファイルの起動からリソースが完全に読み込まれて使用可能になるまでの時間です。
テストシナリオによっては、ユーザー数の多いテストを容易にするために、シミュレーションツールが使用されました。シミュレーションツールを使用すると、5,000または20,000の実セッションを実行するために必要な数より少ないハードウェアでテストできます。これらのシミュレートされたセッションは、通常のStoreFrontログオン、リソースの列挙、ICAファイルの取得を行いますが、アクティブなデスクトップは起動しません。代わりに、シミュレーションツールは、セッションが開始されたことをICAスタックに報告します。ブローカーエージェントからBroker Serviceへのすべての通信は、実際のセッションの通信と一貫性があります。パフォーマンス測定値は、Cloud Connectorから収集されます。
環境がセッションの起動にどのように応答したかを判断するため、テスト期間中、25セッションの同時起動が維持されました。したがって、この測定では、テスト期間を通して負荷がかけられたシステムの結果を示します。
VDA登録ストームテスト
VDA登録ストームでは、サイト回復をシミュレートするために、数百または数千のVDAが一度に登録されます。大量のVDA登録は、週の初めのシナリオで、通常2週間ごとアップグレードサイクル後に、または顧客管理マシンとCitrix管理サービスとの間の停止からシステムが回復した場合に行われます。5000のVDAを使用してテストが実施され、各テスト中にパフォーマンスデータを収集することによってCloud Connectorが監視されました。データには、PerfMonカウンター（CPU、メモリ、ディスク使用率）とVDA登録時間が含まれています。
Machine Creation Servicesのプロビジョニングテスト
プロビジョニングテストは、さまざまな数のカタログを作成することによって実行されました。多様なタスク（イメージのコピー、ADアカウントの作成、マシンの作成）の時間が測定され、パフォーマンスが評価されました。Azureでのカタログサイズの増加もテストされました。Azureおよび顧客管理の両方のハイパーバイザーで1,000台のマシンのプロビジョニングテストが実施されました。Azureでのテストは、Windows 10がCitrix Virtual Desktops Essentialsで唯一サポートされているOSであるため、Windows 10仮想マシンに限定しました。顧客管理ハイパーバイザーは、Windows 10およびWindows 2012 R2でテストされました。
テスト環境
テスト環境の構成には、Citrix Cloud Connector、Citrix DaaS、およびCitrix Virtual Apps and Desktopsコンポーネントが含まれています。ここでは、使用したマシンとオペレーティングシステムの仕様が提供されているため、構成とテスト結果を現在使用している構成および要件と比較することができます。
使用したツール
内部テストツールが、テスト対象のマシンからパフォーマンスデータと測定値を収集し、セッションを起動させました。この独自のツールは、Citrix Virtual Apps and Desktops環境でのユーザーセッションの起動を調整し、応答時間データとパフォーマンス測定値を一元的に収集します。つまり、このテストツールはテストを管理し、結果を収集します。
テスト構成 – Citrix Virtual Apps and Desktopsの構成
以下は、Citrix Virtual Apps and Desktopsのテストで使用されるマシンおよびOS仕様の一覧です。
-
Cloud Connector：
- シナリオ1： Windows 2012 R2 x 2、vCPU x 2、4GBのメモリ
- シナリオ2： Windows 2012 R2 x 2、vCPU x 2、4GBのメモリ
- StoreFront（顧客管理）： Windows 2012 R2 x 1、vCPU x 8、8GBのメモリ
- ハイパーバイザー： VMware vSphere ESXi 6.0 Update 1 x 8、HP ProLiant BL 460c Gen9、Intel E5-2620 CPU x 2、256GBのメモリ
- ハイパーバイザストレージ： NetApp 3250での2TBのNFS共有
- VDA： Windows 2012 R2およびWindows 10 32ビット版ビルド1607
テスト構成 – Citrix Virtual Desktops Essentials
セッションは100台のWindows 2012 R2クライアントのランチャーマシンから開始されました。また、AzureでホストされているWindows Active Directoryに対して認証されました。ローミングプロファイルは、AzureのWindowsファイルサーバーに格納されていました。
- VDA： Windows 10 64ビット版ビルト1607 x 1,000、vCPU x 2、7GBのメモリ（Standard_D2_v2インスタンス）
- クライアント： Windows 2012 R2サーバー x 100、vCPU x 8、8GBのメモリ
- ドメインコントローラー： Windows 2012 R2 x 2、vCPU x 4、14GBのメモリ（Standard_D3_v2インスタンス）
- ファイルサーバー： Windows 2012 R2 x 1、DS11インスタンス
- NetScaler VPX： NetScaler 11.0 x 1、Standard_D3_v2インスタンス（Platinumライセンス x 1,000）
-
Cloud Connector：
- シナリオ1： Windows 2012 R2 x 2、vCPU x 2、4GBのメモリ（Standard_A2_v2インスタンス）
- シナリオ2： Windows 2012 R2 x 2、vCPU x 4、7GBのメモリ（Standard_A3インスタンス）
- StoreFront（顧客管理）： Windows 2012 R2 x 1、DSv2インスタンス
顧客管理マシンに関する考慮事項
顧客管理マシンは、顧客のオフィス、データセンター、またはクラウドアカウント（AzureやAWSなど）に配置することができます。シトリックスの定義では、顧客管理マシンは完全に顧客が制御しています。顧客管理マシンには、Cloud Connector、StoreFrontサーバー、RDSサーバー、VDIマシン、リモートPCアクセスマシン（テスト中は管理対象外）が含まれます。簡潔に表現するために、このレポートの中では、RDSサーバー、VDIマシン、リモートPCアクセスマシンをVDAと呼びます。
StoreFrontサーバー
Citrix DaaSのテストでは、顧客管理StoreFrontサーバーとして8vCPU、8GBのメモリのマシンを使用しました。Citrix Virtual Desktops Essentialsのテストでは、顧客管理StoreFrontサーバー用にAzure Standard_DS2_v2（2vCPU、7GBのメモリ）を使用しました。StoreFrontサーバーのサイズを適切に環境に対応させるには、「StoreFrontの展開計画」を参照してください。
Cloud Connector
1つのシナリオでは2vCPUおよび4GBのメモリを搭載した仮想マシン、別のシナリオでは4vCPUおよび4GBのメモリを搭載した仮想マシン上でホストされている顧客管理Cloud Connectorをテストしました。Azureでは、Standard_A2_v2（vCPU x 2、4GBのメモリ）およびStandard_A3（vCPU x 4、7GBのメモリ）インスタンスでCloud Connectorをテストしました。
テストでは、Cloud Connectorは（負荷分散されていない）高可用性セットに展開されています。このドキュメントでは、2つのCloud Connectorのテスト環境を取り上げていますが、N+1の3つのCloud Connectorセットの使用をお勧めします。このレポートの残りの部分では、Cloud Connectorに焦点を当て、最適なパフォーマンスを得るためにCloud Connectorのサイズを設定する方法について説明します。
テスト結果
VDA登録ストーム
VDA登録ストームテストは、Cloud Connectorのサイジングと環境の安定性の関係を示すデータを提供します。環境の安定性では、顧客管理の場所とCitrix管理のサービスとの間のネットワークが停止した状況をテストします。通常、2週間に1回、Delivery Controllerとサイトデータベースがアップグレードされるときに、VDA登録ストームが発生する可能性があります。
Cloud ConnectorのCPUサイズ比較：2vCPUと4vCPU
- 平均使用率は似ていますが、テスト中に2vCPUマシンのCPUには負荷がかかり、VDAの登録解除が発生することがあります。
- 約5,000のVDAが登録されたサイトでは、安定性のために4vCPUのCloud Connectorを使用することをお勧めします。
- 2,500のVDAをホストするサイトでは、2vCPUのCloud Connectorをお勧めします。
- Cloud Connectorは高可用性セットであり、負荷分散はしません。
- 5,000のVDAをホストするサイトに2vCPUのCloud Connectorを推奨しない理由の1つは、マシン割り当てがランダムであるためです。Cloud Connectorは負荷分散されていないため、それぞれのCloud Connectorに到達する負荷の大きさを予測することはできません。1台のマシンに60％以上の負荷がかかることもあります。
| VDAの数 | 必要なCloud Connector |
|---|---|
| 2,500超 | それぞれ2vCPUが搭載された2台の仮想マシン+1 |
| 5,000超 | それぞれ4vCPUが搭載された2台の仮想マシン+1 |
Cloud ConnectorのHAペアにおけるVDA登録ストームのタイミングの比較
| Cloud Connectorのサイズ | VDA数 | 登録時間 |
|---|---|---|
| 2vCPU | 5000 | 11:03 |
| 4vCPU | 5000 | 5:46 |
- 4vCPUを搭載したCloud Connectorは、テスト中、より安定していました。
- Cloud Connectorに4vCPUが搭載されている場合、VDAの登録速度が向上しました。
- 2vCPUのCloud Connectorを使用したテストでは、VDAの再登録が発生しました。
- 登録がタイムアウトするか、VDA通信のハートビートが遅れると、再登録が行われることがあります。
5,000のVDAの登録ストーム中Cloud Connector上のコンポーネントによるメモリ使用率
- このグラフは、登録ストームテスト中のCitrixコンポーネントとMicrosoft LSASS（Local Security Authority Subsystem Service）によるメモリ使用率の詳細を表示しています。
- Cloud ConnectorのLSASSプロセスは、登録とセッションの起動の両方で重要な役割を果たします。Citrix Cloudサービスによって作成されたすべてのActive Directory認証は、Cloud Connector経由で顧客管理のActive Directoryにプロキシ接続されます。
- メモリ使用率はVDA登録期間中にピークに達し、すべてのVDAが正常に登録されると減少します。
- 4GBのメモリを搭載したCloud Connectorでは、メモリ使用率が高くなります。
セッションの起動（Citrix Virtual Desktops Essentials）
Citrix Virtual Desktops Essentialsプラットフォームを使用して、1,000セッションの起動テストが実施されました。異なるサイズのCloud Connectorインスタンスを比較しており、Standard_A2_v2（vCPU x 2、4GBのメモリ）およびStandard_A3（vCPU x 4、7GBのメモリ）インスタンスをテストしました。
セッション起動テスト中のCitrix管理StoreFrontにおけるConnectorのCPU使用率
- テスト中、CPUの競合はあまりありません。Standard_A2_v2インスタンスのサイズは、負荷の高いセッションの起動テスト中に1,000台のマシンのVDI展開を処理するのに十分なサイズでした。
- Standard_A3インスタンスはこのサイトのサイズに対して過剰と見なされたため、以降はStandard_A2_v2の詳細を使用します。
- より大きなVDIサイトでは、Standard_A3の使用が必要となることがあります。
1,000セッション起動時におけるA2v2 Cloud Connector上の上位コンポーネントによるCPU使用率
Cloud Connector上で実行されているほかのプロセスは、十分な測定値が登録されないため表示されません。
- Citrix Remote Broker Provider（XaXdCloudProxy）は、顧客管理VDAマシンとCitrix管理サービス（Delivery Controller）間の通信を処理します。
- Cloud Connector上のLSASSは、すべてのActive Directory認証を処理します。Citrix Cloudサービスによって作成された認証は、Cloud Connector経由で顧客管理のActive Directoryにプロキシ接続されます。
- このグラフは、テスト中により多くの負荷がかかった単一のCloud Connectorの使用状況を示しています。テストの追加のCloud Connectorは、CPU使用率が低かったため、グラフには含まれていません。
Cloud Connectorのインスタンスごとのメモリ使用率比較
- Standard_A2_v2（4GBメモリ）で利用可能なメモリが少ないため、Standard_A2_v2仮想マシンのメモリ使用率が高いことがわかります。
- 高いメモリ使用率は、Azureの1,000台のマシンの電源状態を維持するために必要なCitrix Remote HCL Server（RemoteHCLServer）プロセスによるものです。
- Azure APIのレート制限により、状態を定期的に照会することはできません。
- テスト後に実装されたCitrix Remote HCL Server（RemoteHCLServer）の変更により、Delivery Controllerはコンピューターの状態をAzureに直接通信できます。
- この変更により、メモリの使用率が大幅に削減され、Standard_A2_v2インスタンスは問題なく1,000 VDAサイトを管理できます。
セッションの起動時間
Standard_A2_v2とStandard_A3の比較
| A3 | A2v2 | |
|---|---|---|
| 認証 | 561ミリ秒 | 575ミリ秒 |
| 列挙 | 1,132ミリ秒 | 1,054ミリ秒 |
| ログイン合計時間 | 1,693ミリ秒 | 1,629ミリ秒 |
| ICAファイルの取得 | 3,464ミリ秒 | 3,659ミリ秒 |
| OSログオンの完了 | 38.83秒 | 41.91秒 |
| 起動合計時間 | 42.3秒 | 45.6秒 |
時間は、すべてのテスト実行時間の平均値です。Azureの顧客管理StoreFrontサーバー： Standard_DS2_v2（vCPU x 2、メモリ7GB）
- テスト中にクライアントマシンとNetScalerの間に約30ミリ秒の遅延が発生しました。
- 環境にストレスがかかっているときにCloud ConnectorでStandard_A3インスタンスを使用すると、セッションの起動が平均3〜4秒の短縮されます。
- Standard_A3仮想マシンは、Standard_A2_v2の2倍のCPUコアを搭載しています
- テスト中、Standard_A2_v2インスタンスでメモリ使用率が高くなります。
- 高いメモリ使用率は、Azure ARM展開のCloud ConnectorからRemoteHCLServer通信を削除することで解決できました。
Windows 10の1,000セッションのセッションログオン時間
- テスト前にすべてのマシンの電源をオンにしました。
- テストの手順では、約8分の間に1,000セッションを開始しました。
- Standard_D2_v2インスタンスのWindows 10 64ビットVDAでデスクトップをアクティブ化する平均時間は、約37.67秒でした。
- グラフには、ICAファイルの取得からアクティブな使用可能なデスクトップが表示されるまでの、テスト中の個別のログオン時間が表示されています。
- 緑色および黄色の領域はそれぞれ1つおよび2つの標準偏差を示します。
- セッション開始時間は一貫していますが、いくつかの異常値があります。ネットワーク状態の瞬間的な変化は、異常値につながり、以下の機能に影響を与えることがあります：
- Cloud Connector経由でプロキシ接続されるNetScaler上のSecure Ticket Authority（STA）チケット交換。
- WAN経由のHDX接続の確立。
- Azureストレージ。テストでは標準ストレージを使用しました。
セッションの起動のシミュレーション
セッションの起動のシミュレーションテストでは、Cloud Connector、Delivery Controller、サイト構成データベースにストレスがかけられます。多数の同時ログオンを処理し、持続的な負荷状態のセッションを維持するためのコンポーネントの機能をテストします。セッション数は5,000および20,000がテストされました。このドキュメントでは、20,000セッションのテストを取り上げています。起動速度とコンポーネント の動作は2つのテスト間でほぼ同じです。20,000セッションのテストはより長く実行され、時間の経過とともにCitrix DaaSの使用状況を総合的に観察することができます。25セッションは、同時に可能な限り高速で起動しました。可能な限り高速にセッションを起動するための設定では、テスト中のシステムで環境が接続に応答する速度を指定できます。
セッションの起動テストにおけるCloud ConnectorのHAセットのCPU使用率
- グラフでは、20,000セッションを起動する場合のCloud ConnectorのCPU使用率を比較しています。
- ストレスと負荷テストのために2つのCloud Connectorが展開されています。
注：
高可用性のためには、各リソースの場所に2つ以上のCloud Connectorが必要であり、3つのCloud ConnectorのN+1展開をお勧めします。
- テスト中にCPUの競合は確認されませんでした。
20,000セッションの起動テストにおけるコンポーネントごとのCloud ConnectorのCPU使用率
- LSASS（Local Security Authority Subsystem Service）は、セッションのログオン時にStoreFrontを使用してCPUを消費します。
- Citrix管理サービスからのすべての認証は、Cloud Connectorを通過して顧客管理Active Directoryと通信する必要があります。
20,000セッションの起動時におけるコンポーネントごとのメモリ使用率
- セッションの起動中は、メモリ負荷が低くなります。
- ほとんどのコンポーネントによるメモリ使用率は、最大値と平均値がほぼ等しいことが確認されており、テストを通じて変化しません。
StoreFrontを使用したセッション起動の観察
| アクション | 時間 |
|---|---|
| 認証 | 261ミリ秒 |
| 列挙 | 1,075ミリ秒 |
| ログイン合計時間 | 1,336ミリ秒 |
| ICAファイルの取得 | 2,132ミリ秒 |
Machine Creation Servicesのプロビジョニング
Citrix Virtual Desktops Essentials MCSによるAzure Resource Managerのテスト
Machine Creation Servicesを使用すると、Azureで仮想デスクトップ（VDA）を作成および削除できます。最初に、Windows 10 VHDを作成し、VHDをAzureにアップロードします。イメージはVHDから作成されます。Citrix Virtual Desktops Essentialsでは、イメージから仮想マシンを作成できます。
| マシン数 | イメージのコピー | ADアカウントの作成 | マシンの作成 |
|---|---|---|---|
| 10 | 30分 | 1分 | 7分 |
| 100 | 30分 | 7分 | 50分 |
| 250 | 40分 | 8分 | 2時間 |
| 500 | 55分 | 15分 | 4時間 |
| 1000 | 65分 | 30分 | 8時間 |
時間はいくつかのテストの実行に基づくおおよそのものであり、変動することがあります。
- さまざまなマシン数を使用してマシン作成プロセスをテストし、以下の完了に必要な時間を測定しました：
- イメージのコピー
- マシンアカウントの作成
- マシンのプロビジョニング
- イメージのコピーを各ストレージアカウントに複製する必要があるため、時間は直線的に増加しません。複製は並行して行われるため、タスクが増えるとスピードが低下します
- ストレージアカウントごとのマシン数は40台に制限されています。この制限では、1,000台の仮想マシン環境で25のストレージアカウントが必要です。
- リソースの場所あたりのマシン数は760台に制限されています。
- Active Directoryアカウントの作成では、Cloud Connector経由でプロキシ接続する必要があり、タスクの完了に必要な時間が長くなります。Active Directoryアカウントは毎分約33の割合で作成されます。
- テストにはStandard_A2_v2 Cloud Connectorを使用しました。リソースのボトルネックは確認されませんでした。
Citrix DaaS MCSテスト
MCSプロビジョニングテストは、VMware ESXi 6.0ハイパーバイザーで実行されました。クラスターには8つのvSphereホストがあり、共有ストレージはNetApp共有上のNFSです。
| OS | マシン数 | イメージのコピー | ADアカウントの作成 | マシンの作成 |
|---|---|---|---|---|
| WIN 2012 R2 | 100 | 4分 | 3分 | 4分 |
| WIN 2012 R2 | 1,000 | 5分 | 30分 | 100分 |
| Win 10 32ビット | 100 | 4分 | 3分 | 4分 |
時間は複数のテストの実行に基づくおおよそのものであり、変動することがあります。これらの実行によるテストデータは、表中で平均化されています。
- マシン作成プロセスに必要な時間は、XenAppおよびXenDesktop 7.xのバージョンに必要な時間と同様です。主な違いは、Active Directoryアカウントの作成です。クラウド環境では、アカウント作成はCloud Connector経由でプロキシ接続する必要があります。Active Directoryアカウントはクラウド環境で毎分約33の割合で作成されます。
- Cloud Connectorで4vCPU、4GBのメモリを搭載した2台の仮想マシンを使用してテストを実施しました。テスト中にリソースの競合は確認されませんでした。