Cloud Connectorのサイズおよびスケールの考慮事項
Citrix DaaS(旧称Citrix Virtual Apps and Desktopsサービス)のサイジングとスケーラビリティを評価する場合、すべてのコンポーネントを考慮する必要があります。特定の要件に応じて、Citrix Cloud ConnectorとStoreFrontの構成を調査し、テストします。サイジングとスケーラビリティのためのリソースが不十分だと、お使いの環境のパフォーマンスに悪影響を及ぼします。
注:
これらの推奨事項は、Citrix DaaSおよびCitrix DaaS Standard for Azureに適用されます。
この記事では、テスト済みの最大容量の詳細と、Cloud Connectorのマシン構成に関するベストプラクティスの推奨事項について説明します。テストは、StoreFrontおよびローカルホストキャッシュ(LHC)が構成された環境で実施されました。
説明内容は、各リソースの場所にVDIワークロードまたはRDSワークロードのいずれかが含まれる環境に適用されます。VDIワークロードとRDSワークロードが一緒に含まれるリソースの場所については、Citrixコンサルティングサービスにお問い合わせください。
Cloud Connectorは、次の方法でワークロードをCitrix DaaSにリンクします:
- VDAとCitrix DaaS間の通信用プロキシの提供
- Citrix DaaSとお使いのActive Directory(AD)およびハイパーバイザー間の通信用プロキシの提供
- StoreFrontサーバーを含む環境では、Cloud Connectorは、クラウドの停止時に一時的なセッションブローカーとして機能し、ユーザーにリソースへの継続的なアクセスを提供
特定のニーズを満たすために、Cloud Connectorを適切なサイズと構成にすることが重要です。
Cloud Connectorの各セットは、リソースの場所(ゾーンとも呼ばれます)に割り当てられます。リソースの場所は、どのリソースがそのCloud Connectorのセットと通信するかを指定する論理的な分離です。Active Directory(AD)と通信するには、ドメインごとに少なくとも1つのリソースの場所が必要です。
各マシンカタログとホスティング接続は、リソースの場所に割り当てられます。
複数のリソースの場所を使用する環境では、マシンカタログとVDAをリソースの場所に割り当て、停止中に接続を仲介するLHCの機能を最適化します。リソースの場所の作成と管理について詳しくは、「 Citrix Cloudへの接続」を参照してください。最適なパフォーマンスを得るには、VDA、Active Directoryサーバー、およびハイパーバイザーへの低遅延接続でCloud Connectorを構成します。
推奨されるプロセッサとストレージ
今回のテストと同様のパフォーマンスを得るには、SHA拡張機能に対応している最新のプロセッサを使用してください。SHA拡張機能により、CPUの暗号化負荷が軽減されます。推奨されるプロセッサは次のとおりです:
- Advanced Micro Devices(AMD)Zen以降のプロセッサ
- Intel Ice Lake以降のプロセッサ
推奨されているプロセッサは効率的に実行されます。古いプロセッサを使用することもできますが、CPU負荷が高くなる可能性があります。これに対応するために、仮想CPUの数を増やすことをお勧めします。
この記事で説明されているテストは、AMD EPYCプロセッサおよびIntel Cascade Lakeプロセッサを使用して行われました。
Cloud Connectorでは、クラウドとの通信中に暗号化の負荷が高くなります。SHA拡張機能対応のプロセッサを使用するCloud Connectorでは、CPUの負荷が低くなります。これは、Windows Local Security Authority Subsystem Service(LSASS)によるCPU使用率の低下によって示されています。
特に、LHCを使用する環境では、1秒あたりのI/O操作数(IOPS)が十分な最新のストレージを使用することをCitrixではお勧めします。ソリッドステートドライブ(SSD)が推奨されますが、プレミアムクラウドストレージ階層は必要ありません。Cloud Connectorがデータベースの小さなコピーを実行することを想定しているLHCの場合は、より高いIOPSが必要です。このデータベースは、サイト構成の変更にともなって定期的に更新され、Citrix Cloudの停止時にリソースの場所に仲介機能を提供します。
推奨されるローカルホストキャッシュのコンピューティング構成
ローカルホストキャッシュ(LCH)は、Cloud ConnectorがCitrix Cloudと通信できなくなった場合でも、環境での接続仲介操作を続行できることによって、高可用性を提供します。
Cloud Connectorは、インストール時に自動的にインストールされるMicrosoft SQL Express Server LocalDBを実行します。Cloud ConnectorのCPU構成、特にSQL Express Server LocalDBで使用可能なコアの数が、LHCのパフォーマンスに直接影響します。SQL Server Express Server LocalDBで使用可能なCPUコアの数は、メモリ割り当てよりも大きな影響をLHCのパフォーマンスに与えます。このCPUオーバーヘッドは、Citrix DaaSとの通信ができず、LHCブローカーがアクティブなLHCモードの場合にのみ確認されます。LHCを使用するすべての環境では、ソケットごとに4つのコアと、CitrixではCloud Connectorごとに最低4つのCPUコアを使用することをお勧めします。SQL Express Server LocalDBのコンピューティングリソースの構成については、「SQL Serverのエディションごとの処理能力の上限」を参照してください。
SQL Express Server LocalDBで使用可能なコンピューティングリソースが正しく構成されていない場合、構成の同期時間が長くなり、停止中のパフォーマンスが低下する可能性があります。一部の仮想化環境では、処理能力はCPUコアの数ではなく、論理プロセッサの数に依存します。
テスト結果の要約
この概要のすべての結果は、詳細セクションに記載されたとおりに構成されたテスト環境での結果に基づきます。ここに表示されている結果は、単一のリソースの場所に関するものです。異なるシステム構成では、異なる結果になる可能性があります。
この図は、テストされた構成の概要をグラフィカルに示しています。
この表は、リソースの場所のサイズを決定するためのクイックガイドを提供します。1つのリソースの場所における最大値は10,000です。リソースの場所の制限については、「制限」を参照してください。
注:
制限を超えると、停止中に接続やパフォーマンスの問題が発生する可能性があります。したがって、未登録のVDAが発生する可能性があるため、推奨される制限を超えないようにする必要があります。
結果はCitrixの内部テストに基づいています。記載されている構成は、高レートセッション起動テストや登録ストームなど、さまざまなワークロードでテストされました。
Medium | 大 | 最大 | |
---|---|---|---|
VDA | 1000 VDIまたは250 RDS | 5,000 VDIまたは500 RDS | 10,000 VDIまたは1000 RDS |
ホスト接続 | 20 | 40 | 40 |
コネクタ用CPU | 仮想CPU×4 | 仮想CPU×4 | 仮想CPU×8 |
コネクタ用メモリ | 6GB | 8GB | 10GB |
テスト方法
負荷を追加し、環境コンポーネントのパフォーマンスを測定するためのテストが実施されました。コンポーネントの監視では、パフォーマンスデータと手順のタイミング(ログオン時間、登録時間など)のデータを収集しました。必要な場合は、VDAとセッションをシミュレートするために、独自のCitrixシミュレーションツールが使用されました。これらのツールは、実際のセッションやVDAをホストするために必要なリソースがなくても、従来のVDAやセッションと同様にCitrixコンポーネントを使用できるように設計されています。Citrix StoreFrontを使用するテストは、クラウドブローカリングモードとLHCモードの両方で実施されました。
この記事のCloud Connectorのサイジングの推奨事項は、これらのテストから収集されたデータに基づいています。
実施されたテストは次のとおりです:
- セッションログオン/起動ストーム: ログオンが集中する期間をシミュレートするテスト。
- VDA登録ストーム: VDAの登録が集中する期間をシミュレートするテスト。たとえば、アップグレードサイクルの後、またはクラウドブローカリングモードとローカルホストキャッシュモード間の移行。
- VDA電源操作ストーム: 大量のVDA電源操作をシミュレートするテスト。
テストシナリオと条件
これらのテストは、LHCが構成された環境で実施されました。LHCの使用について詳しくは、「ローカルホストキャッシュ」を参照してください。LHCには、オンプレミスのStoreFrontサーバーが必要です。StoreFrontについて詳しくは、StoreFront製品のドキュメントを参照してください。
StoreFront構成の推奨事項:
- 1つのStoreFrontサーバーまたはサーバーグループで複数のリソースの場所がある場合は、StoreFrontストアの高度なヘルスチェックオプションを有効にします。「ローカルホストキャッシュ」の、「StoreFrontの要件」を参照してください。
- セッション起動レートを高くするには、StoreFrontサーバーグループを使用します。StoreFront製品ドキュメントの、「サーバーグループの構成」を参照してください。
テスト条件:
- CPUとメモリの要件は、ベースOSとCitrixサービスのみです。サードパーティのアプリやサービスには、追加のリソースが必要になる場合があります。
- VDAは、Citrix Virtual Delivery Agentを実行している仮想マシンまたは物理マシンです。
- テストされたすべてのVDAは、Citrix DaaSを使用して電力管理されました。
- 1000~10,000のVDIサーバーと250~1000のRDSサーバーのワークロードと、1000~20,000のセッションがテストされました。
- リソースの場所ごとに、最大20,000 RDSセッションまでテストを実施しました。
- テストは、通常の運用中と停止中の両方で、1つのCloud Connectorを使用して実行されました。可用性を高めるため、Cloud Connectorを2つ以上使用することをお勧めします。停止モードの場合、VDAの登録とブローカーには1つのコネクタのみが使用されます。
- Intel Cascade Lakeプロセッサで構成されたCloud Connectorでテストを実施しました。
- セッションは、単一のCitrix StoreFrontサーバーを介して開始されました。
- LHC停止セッションは、マシンが再登録された後に実行されるテストを開始します。
RDSセッション数は推奨値であり、上限ではありません。ご使用の環境下でのRDSセッション上限をテストしてください。
注:
セッション数と起動レートは、RDSにとってVDAの数よりも重要です。
中規模のワークロード
これらのワークロードに対して、4つのvCPUと6 GBのメモリでテストを実施しました。
テストのワークロード | サイトの状態 | VDA登録時間 | 登録CPUとメモリ使用状況 | 起動テストの長さ | セッション起動CPUとメモリ使用状況 | 起動レート |
---|---|---|---|---|---|---|
1,000 VDI | オンライン | 5分 | CPU最大 = 36%、CPU平均 = 33%、メモリ最大 = 5.3 GB | 2分 | CPU最大 = 29%、CPU平均 = 27%、メモリ最大 = 3.7 GB | 毎分500 |
1,000 VDI | 停止 | 4分 | CPU最大 = 11%、CPU平均 = 10%、メモリ最大 = 4.5 GB | 2分 | CPU最大 = 42%、CPU平均 = 28%、メモリ最大 = 4.0 GB | 毎分500 |
250 RDS、5000セッション | オンライン | 3分 | CPU最大 = 14%、CPU平均 = 4%、メモリ最大 = 3.5 GB | 9分 | CPU最大 = 46%、CPU平均 = 21%、メモリ最大 = 3.7 GB | 毎分555 |
250 RDS、5000セッション | 停止 | 3分 | CPU最大 = 15%、CPU平均 = 5%、メモリ最大 = 3.7 | 9分 | CPU最大 = 51%、CPU平均 = 32%、メモリ最大 = 4.2 GB | 毎分555 |
大規模なワークロード
これらのワークロードに対して、4つのvCPUと8 GBのメモリでテストを実施しました。
テストのワークロード | サイトの状態 | VDA登録時間 | 登録CPUとメモリ使用状況 | 起動テストの長さ | セッション起動CPUとメモリ使用状況 | 起動レート |
---|---|---|---|---|---|---|
5,000 VDI | オンライン | 3〜4分 | CPU最大 = 45%、CPU平均 = 25%、メモリ最大 = 7.0 GB | 5分 | CPU最大 = 75%、CPU平均 = 55%、メモリ最大 = 7.0 GB | 毎分1,000 |
5,000 VDI | 停止 | 4〜6分 | CPU最大 = 15%、CPU平均 = 5%、メモリ最大 = 7.5 GB | 5分 | CPU最大 = 45%、CPU平均 = 40%、メモリ最大 = 7.5 GB | 毎分1,000 |
500 RDS、10,000セッション | オンライン | 3分 | CPU最大 = 45%、CPU平均 = 25%、メモリ最大 = 7.0 GB | 10分 | CPU最大 = 75%、CPU平均 = 55%、メモリ最大 = 7.0 GB | 毎分1,000 |
500 RDS、10,000セッション | 停止 | 3分 | CPU最大 = 15%、CPU平均 = 5%、メモリ最大 = 7.5 | 10分 | CPU最大 = 45%、CPU平均 = 40%、メモリ最大 = 7.5 GB | 毎分1,000 |
最大ワークロード
これらのワークロードに対して、8つのvCPUと10 GBのメモリでテストを実施しました。
テストのワークロード | サイトの状態 | VDA登録時間 | 登録CPUとメモリ使用状況 | 起動テストの長さ | セッション起動CPUとメモリ使用状況 | 起動レート |
---|---|---|---|---|---|---|
10,000 VDI | オンライン | 3〜4分 | CPU最大 = 85%、CPU平均 = 10%、メモリ最大 = 8.5 GB | 7分 | CPU最大 = 66%、CPU平均 = 28%、メモリ最大 = 7.0 GB | 毎分1,400 |
10,000 VDI | 停止 | 4~5 minutes | CPU最大 = 90%、CPU平均 = 17%、メモリ最大 = 8.2 GB | 5分 | CPU最大 = 90%、CPU平均 = 45%、メモリ最大 = 8.5 GB | 毎分2,000 |
1,000 RDS、20,000セッション | オンライン | 1〜2分 | CPU最大 = 60%、CPU平均 = 20%、メモリ最大 = 8.6 GB | 17分 | CPU最大 = 66%、CPU平均 = 25%、メモリ最大 = 6.8 GB | 毎分1,200 |
1,000 RDS、20,000セッション | 停止 | 3〜4分 | CPU最大 = 22%、CPU平均 = 10%、メモリ最大 = 8.5 | 21分 | CPU最大 = 90%、CPU平均 = 50%、メモリ最大 = 7.5 GB | 毎分1,000 |
注:
ここに示すワークロードは、1つのリソースの場所で推奨される最大値です。これ以上のサイズのワークロードをサポートするには、リソースの場所を追加します。
構成同期リソース使用量
構成の同期プロセスにより、Cloud ConnectorがCitrix DaaSで最新の状態に保たれます。更新プログラムは自動的にCloud Connectorに送信され、停止が発生した際にはCloud Connectorがいつでもブローカリングを引き継げる状態になっています。構成の同期により、LHCデータベースであるSQL Express Server LocalDBが更新されます。プロセスはデータを一時データベースにインポートし、インポートされるとそのデータベースに切り替えます。これにより、引き継ぎ可能なLHCデータベースが常に存在することが保証されます。
データが一時データベースにインポートされている間、CPU、メモリ、およびディスクの使用率が一時的に増加します。
テスト結果:
- データのインポート時間: 7〜10分
-
CPU使用率:
- 最大 = 25%
- 平均 = 15%
-
メモリ使用率:
- 最大 = 9GB
- 約2 GBから3 GBの増加
-
ディスク使用率:
- 4 MB/sのディスク読み取りスパイク
- 18 MB/sのディスク書き込みスパイク
- 構成ファイルのダウンロードおよび書き込み中に、70 MB/sのxmlディスク書き込みスパイク
- インポート完了時に、4 MB/sのディスク読み取りスパイク
-
LHCデータベースのサイズ:
- 400〜500 MBのデータベースファイル
- 200〜300 MBのログデータベース
テスト条件:
- 8つの仮想CPU AMD EPYCでテストを実施
- インポートされたサイト構成データベースは、サイト全体で合計80,000 VDAおよび300,000ユーザー(100,000ユーザーの3シフト)の環境用
- データのインポート時間は、10,000 VDIのリソースの場所でテスト
リソース使用に関する補足的な注意事項:
- インポート中に、完全なサイト構成データがダウンロードされます。このダウンロードは、サイトのサイズによってはメモリスパイクを引き起こす可能性があります。
- テストされたサイトでは、データベースとデータベースログファイルの合計で約800 MBを使用しました。構成の同期中に、これらのファイルは、最大合計サイズ約1,600 MBで複製されます。Cloud Connectorに複製ファイル用の十分なディスクスペースがあることを確認してください。ディスクがいっぱいになると、構成の同期プロセスは失敗します。