設計上の決定:単一サーバーのスケーラビリティ

概要

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

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

警告!

この記事では、SSS を見積もるためのガイダンスが含まれています。ガイダンスは高レベルであり、お客様固有の状況や環境に特有のものではありません。Citrix Virtual Apps and DesktopsのSSSを深く理解する唯一の方法は、Login VSIなどのスケーラビリティまたは負荷テストツールを使用することです。Citrix では、このガイダンスと以下の簡単なルールを使用してSSSを迅速に見積もることを推奨しています。ただし、Citrix では、特にハードウェアを購入したり財務上の決定を下したりする前に、Login VSIまたは任意の負荷テストツールを使用して結果を検証することをお勧めします。

スケーラビリティ要因

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

ワークロード

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

ハードウェア

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

活動比率

SSS で見過ごされがちな側面の 1 つに、アクティビティの比率、つまりユーザーが作業している頻度とアイドル状態の頻度が挙げられます。スケーラビリティテストツールの多くは保守的なアプローチを採用しており、80% といったかなり高いアクティビティ率を使用する場合があります (つまり、ユーザーは実質的に 80% の時間をアクティブまたは作業していて、20% の時間はアイドル状態です)。しかし、実際の世界では、活動比率は40〜60%に近いことがよく見られます。また、このようなアイドル時間の増加は、SSSや、Citrix Virtual Apps and Desktops環境をサポートするために購入する必要があるハードウェアの量に大きな影響を与える可能性があります。

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

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

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

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

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

Citrix Virtual Apps and Desktops SSSを迅速に測定または見積もりたい場合は、このガイダンスが効果的です。これと同じくらい簡単です。 サーバの物理コアの数に 5 または 10 を掛けると、SSS になります。サポートできるCitrix Virtual Desktops仮想マシンの数をお探しの場合は、5という「マジックマルチプライヤー」を使用してください。1つのハードウェアで何人のCitrix Virtual Appsユーザーを実行できるかを把握しようとすると、10人になります。実際の例をいくつか見てみて、これが実際にどのように適用されるかを見てみましょう。

例1:Citrix Virtual Desktops

標準の Office アプリケーションといくつかのカスタムアプリケーションで Windows 10 を実行しているとしましょう。これで、ワークロード/イメージを考慮すると、2 vCPU/4 GB RAM の VM 仕様が最適であることが判明しました。36 個の物理コア(2 x 18)と 768 GB の RAM を搭載したCisco製ブレードの購入を検討しています。そして、どんな密度が期待できるのか理解したいですよね。Citrix 仮想デスクトップの 5 つのルールを使用してみましょう:

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

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

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

Citrix Virtual Apps 経由で Windows Server 上で 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)。Citrix Virtual Appsの 10 のルールを使用する:

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

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

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

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

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

参照ドキュメント

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

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

ログイン VSI ロードテスト

設計上の決定:単一サーバーのスケーラビリティ