Citrix Virtual Apps and Desktops の単一サーバーの拡張性

概要

この記事では、単一の物理ホストでサポートできるユーザーまたは仮想マシン (VM) の数を見積もるための推奨事項とガイダンスを提供します。これは、通常、Citrix Virtual Apps and Desktops の「単一サーバースケーラビリティ」(SSS)と呼ばれます。Citrix Virtual Apps(CVA)またはセッション仮想化のコンテキストでは、一般に「ユーザー密度」とも呼ばれます。このアイデアは、Citrix Hypervisor ハイパーバイザーなどの主要なハイパーバイザーを実行している単一のハードウェア上で実行できるユーザーまたはVMの数を確認することです。

この記事では、Citrix Virtual Apps and Desktops(CVAD)SSSに影響を与えるいくつかの変数または要因について説明します。特定の環境の SSS を迅速に見積もるための推奨事項と簡単なガイドラインを提供します。私たちは、実際のシナリオを使用して、いくつかのサイジングの例を提供することによって結論付けます。

警告!この記事では、SSS を見積もるためのガイダンスが含まれています。ガイダンスは高いレベルであり、必ずしもお客様固有の状況や環境に固有のものではないことに注意してください。CVAD SSS を真に理解する唯一の方法は、Login VSI などのスケーラビリティまたは負荷テストツールを利用することです。SSSをすばやく見積もるために、このガイダンスとこれらの簡単なルールを使用することをお勧めします。ただし、特にハードウェアを購入したり、財務上の意思決定を行う前に、Login VSIまたは任意の負荷テストツールを使用して結果を検証することをお勧めします。

スケーラビリティ要因

SSSに影響を与える多くの因子、パラメータ、または変数があります。これは決して網羅的なリストではありませんが、SSSに影響を与える主な要因のいくつかを以下に示します。ウイルス対策および監視エージェント、グラフィックスエンコーディング、Spectre や L1 ターミナル障害などの最近のセキュリティ脆弱性など、パフォーマンスとスケーラビリティに影響を与える要因は他にもたくさんありますが、以下に詳述する要因は CVAD SSS に最も大きな影響を与えます。それでは、簡単な式を使用してCVAD SSSをすばやく推定する方法を見てみましょう。

ワークロード

パフォーマンスとスケーラビリティに影響する主な要因の 1 つは、ワークロード自体です。ワークロードによっては、タスクワーカーが CVA サーバー上で単純なデータ入力タスクを実行する場合があります。その他のワークロードには、開発者がコードをコンパイルしたり、Citrix Virtual Desktops(CVD)を使用して3Dモデルを操作するエンジニアが関与する場合があります。これらは一般に、それぞれ「軽量」および「重い」ワークロードと呼ばれます。この記事の後半で説明するように、この種のワークロードの分散は SSS に劇的な影響を与える可能性があります。

ハードウェア

ワークロードが実行される物理ハードウェアは、SSS に直接影響します。言うまでもないかもしれませんが、28コアと1 TBのRAMを搭載した新しいサーバーでは、同様のワークロードを実行する12コアと256 GBのRAMしかない古いハードウェアよりも多くのユーザーをサポートできます。あとで見るとおり、CPUはCVAD SSSで特に重要な役割を果たします。

活動比率

SSS の見落としがちな側面の 1 つは、アクティビティ比率またはユーザーがアイドル状態に対して作業している頻度です。多くのスケーラビリティテストツールは保守的なアプローチを採用しており、80%(つまり、ユーザーのアクティブまたは作業時間の 80%、アイドル状態の 20%)など、かなり高いアクティビティ率を利用することがあります。しかし、実際の世界では、活動比率は40〜60%に近いことがよく見られます。また、この追加のアイドル時間は、SSSとCVAD環境をサポートするために購入する必要があるハードウェアの数に劇的な影響を与えます。

CPU オーバーサブスクリプション比率

ほとんどの CVAD ワークロードは CPU に制約されます。つまり、リソース消費の最終的なポイントはシステムで使用可能な物理コアの数に直接関係します。また、ユーザーは 100% アクティブでない場合があり、インテルハイパースレッディングなどのツールを利用できます(ハイパーバイザCPUスケジューラの効率はますます高まっていることは言うまでもありません)。多くの場合、CPUなどのリソースを「オーバーコミット」したり、オーバーサブスクライブすることができます。また、CPUをオーバーサブスクライブする比率は、SSSにも影響する可能性があります(慎重に行わなければ正または負の方法で)。Citrixは、CVAのSSSでは、2対1のCPUオーバーサブスクリプション比がしばしば最適であることがわかりました。たとえば、物理サーバにデュアルソケット 20 コアチップ (つまり「2 x 20」) が装備されている場合、合計 40 の物理コアを使用できます。ハイパースレッディングを有効にすると、80の仮想コアまたは論理コアを使用できます。物理コアの数 (40) に 2:1 の比率を適用することで、SSS のサイズ設定または見積り時に 80 コアを使用することが効果的に推奨されます。この概念をさらに詳しく説明するために、この記事の最後にさらに例を示します。

マイクロプロセッサのアーキテクチャと機能

基盤となるチップとメモリー・アーキテクチャは、SSSでも重要な役割を果たすことができます。また、インテルは最近、基盤となるマイクロプロセッサー・アーキテクチャーの設計を大幅に改良しました。BroadwellやHaswellなどの古いチップでは、インテルはリングベースのアーキテクチャを使用してプロセッサを接続しました。しかし、コア数が増加するにつれて、アクセスレイテンシーが増加し、コアあたりの帯域幅が減少するため、インテルはチップを 2 つの半分に分割し、2 番目のリングを追加して距離を短縮することで、これを軽減します。そして、この目に見えない分割は、最適な結果を得るためにCVAD SSSに組み込む必要がありました。これは、過去に「NUMA」または不均一メモリアクセスと呼ばれていました。また、主要なガイダンスは、CVA VM のサイズを可能な限り大きくし、NUMA ノード、サブ NUMA クラスタ、またはリングを交差させないようにすることでした。CVA VM のサイズが大きすぎて、それらが NUMA ノードまたはリングにまたがっている場合、非ローカルリソースにアクセスして NUMA の「スラッシング」が発生し、SSS が減少します。今日に早送りし、インテルはリングベースのアーキテクチャからメッシュベースのアーキテクチャに移行しました。Skylakeで導入されたこの新しいメッシュアーキテクチャには、チップを分割したり、コアを分割したり、リングを追加したりする必要がある場所と同じ制限はありません。これにより、特にCVAサーバのサイズ設定方法が変わります。そのため、購入するハードウェアで使用されているチップと、基盤となるマイクロプロセッサアーキテクチャの設計と構築方法を理解することが重要です

マジック・マルチプライヤ

CVAD SSS を迅速に測定または見積りたい場合は、このガイダンスが効果的です。これと同じくらい簡単です。 サーバの物理コアの数に 5 または 10 を掛けると、SSS になります。サポートできる CVD VM の数を探している場合は、5 の「マジック乗数」を使用します。1つのハードウェア上で実行できるCVAユーザーの数を理解しようとする場合は、10を使用します。実際の例をいくつか見てみて、これが実際にどのように適用されるかを見てみましょう。

例1:Citrix Virtual Desktops

標準の Office アプリケーションといくつかのカスタムアプリケーションで Windows 10 を実行しているとしましょう。ワークロード/イメージを考慮すると、2 vCPU/4 GB RAM VM 仕様が最適に機能することが確認されました。36の物理コア(2x18)と768GBのRAMを搭載したCisco製ブレードを購入することを検討しています。そして、あなたはあなたが期待できる密度の種類を理解したいと思います。CVDに5のルールを利用しましょう:

5 × 36 = ホストあたり180 VM

注: Citrix専用のVDIおよびRDSHベースのワークロードは、99.9%の時間でCPUにバインドされます。メモリ、ディスクストレージ、ネットワークストレージではなく、CPU がスケーラビリティのボトルネックになっています。これらの乗算器は、CPUが主な要因となっているため、CPUとは別に他の領域を省略します。ハイパースレッディング、クロック速度、仮想コアはすべて重要ですが、サーバー上の物理コアの数よりも重要ではありません。5 と 10 のルールを利用する場合、混乱を避けるために最初のサイズ変更を行うために、他のすべての数字を無視することをお勧めします。

例2:Citrix Virtual Apps(古いハードウェア)

たとえば、CVA経由でWindows Server 2012 R2上でSAPなどのアプリケーションを実行しているとしましょう。24 の物理コア (2x12) と 256 GB の RAM を備えた、古いバージョンの HP ブレードを転用しています。インテルのウェブサイトで、基盤となるチップがリングバッファアーキテクチャを採用しており、各ソケットは効果的に6つのコアを持つ 2 つの NUMA ノードに分割されていることを調査しました。したがって、6 vCPU/24 GB RAM VM 仕様は、線形スケーラビリティを最大化し、NUMA スラッシングを最小限に抑えるために最適なようです。2対1のCPUオーバーサブスクリプション率を使用して、48個の論理コアをすべて利用し、各ホストに8つのXenAppサーバーを展開します(48/6 = 8)。CVAの10のルールを利用する:

10 × 24 = ホストあたり240ユーザー

例3:Citrix Virtual Apps(新しいハードウェア)

CVA経由でWindows Server 2016で人気のある医療アプリケーションを実行していると仮定しましょう。32の物理コア(2x16)と256 GBのRAMを搭載したDell のブレードを購入することを検討しています。Intelのウェブサイトで、基盤となるチップはメッシュアーキテクチャを採用しており、VMフットプリントを可能な限り減らすためのビジネス指令があることを調査しました。16 vCPU/48 GB RAM VM 仕様を決定します。2対1のCPUオーバーサブスクリプション率を使用して、64個の論理コアをすべて利用し、各ホストに4つのXenAppサーバーを展開します(64/16 = 4)。CVAの10のルールを利用する:

10 × 32 = ホストあたり 320 ユーザー

前述のように、サーバ内の物理コアの数ではなく、スケーラビリティに影響する変数やパラメータが数多く存在することを認識しています。また、CVAD ワークロードが CPU に制約されない場合もあるので、サイジングの際には特別な注意が必要です。さらに、CPUクロックスピード、ログオンストームなどの他の要因も重要であり、さらにサイジングの練習を複雑にします。しかし、長年のフィールド経験と数百の展開を通じて、物理コアの数ほど重要ではないことがわかりました。特定のワークロードと固有の環境に対する正確なSSSを理解したい場合は、Login VSIなどのツールを使用して、結果を適切にテストおよび/または検証することを強くお勧めします。

参照ドキュメント

Intel Xeon プロセッサー・スケーラブル・ファミリーの技術概要

ウイルス対策のベストプラクティス

ログイン VSI ロードテスト