HPE SimpliVity 380 for VDI の動作方法: 厳しい負荷テスト

お客様は VDI を希望していました。 SimpliVity + VDI Citrix Virtual Desktop の組み合わせを実際に検討しました。 事業者の皆様、市役所職員の皆様等が対象です。 移行の第 XNUMX 波だけでも XNUMX 人のユーザーがいるため、負荷テストを強く主張しました。 VDI は速度が低下し始めたり、静かに横になったりすることがありますが、これはチャネルの問題が原因で常に起こるわけではありません。 私たちは VDI 専用の非常に強力なテスト パッケージを購入し、ディスクとプロセッサに負担がかかるまでインフラストラクチャをロードしました。

したがって、高度な VDI テストにはペットボトルと LoginVSI ソフトウェアが必要になります。 300 ユーザー分のライセンスを用意しています。 次に、サーバーあたりのユーザー密度を最大化するタスクに適したパッケージの HPE SimpliVity 380 ハードウェアを採用し、適切なオーバーサブスクリプションを備えた仮想マシンを分割し、Win10 にオフィス ソフトウェアをインストールしてテストを開始しました。

行こう！

システム

380 つの HPE SimpliVity 10 GenXNUMX ノード (サーバー)。 それぞれの：

• インテル Xeon プラチナ 2 8170c 26Ghz x 2.1。
• RAM: 768GB、12 x 64GB LRDIMM DDR4 2666MHz。
• プライマリディスクコントローラー: HPE Smart アレイ P816i-a SR Gen10。
• ハードドライブ: 9 x 1.92 TB SATA 6Gb/s SSD (RAID6 7+2 構成、つまり、これは HPE SimpliVity の用語では中モデル)。
• ネットワーク カード: 4 x 1Gb Eth (ユーザー データ)、2 x 10Gb Eth (SimpliVity および vMotion バックエンド)。
• 各ノードに重複排除/圧縮用の特別な組み込み FPGA カードを搭載。

これらのノードは、外部スイッチを使用せずに 10Gb イーサネット相互接続を介して直接接続されており、これは SimpliVity バックエンドとして使用され、NFS 経由で仮想マシン データを転送するために使用されます。 クラスター内の仮想マシンのデータは、常に XNUMX つのノード間でミラーリングされます。

ノードは、vCenter によって管理される Vmware vSphere クラスターに結合されます。

テストのために、ドメイン コントローラーと Citrix 接続ブローカーが展開されました。 ドメイン コントローラー、ブローカー、および vCenter は別のクラスターに配置されます。


テスト インフラストラクチャとして、300 の仮想デスクトップが専用 – フル コピー構成で展開されました。つまり、各デスクトップは仮想マシンの元のイメージの完全なコピーであり、ユーザーが行ったすべての変更が保存されます。

各仮想マシンには 2vCPU と 4GB RAM が搭載されています。

テストに必要な次のソフトウェアが仮想マシンにインストールされました。

• Windows 10 (64 ビット)、バージョン 1809。
• Adobe Reader XI。
• Citrix 仮想配信エージェント 1811.1。
• ドロ PDF 1.82。
• Java 7 アップデート 13。
• マイクロソフトオフィスプロフェッショナルプラス2016。

ノード間 - 同期レプリケーション。 クラスター内の各データ ブロックには 1 つのコピーがあります。 つまり、各ノード上に完全なデータ セットが存在します。 XNUMX つ以上のノードからなるクラスターでは、ブロックのコピーが XNUMX つの異なる場所に存在します。 新しい VM を作成すると、クラスター ノードの XNUMX つに追加のコピーが作成されます。 XNUMX つのノードに障害が発生すると、そのノード上で以前に実行されていたすべての VM が、レプリカのある他のノード上で自動的に再起動されます。 ノードに長時間障害が発生すると、冗長性の段階的な復元が開始され、クラスターは N+XNUMX 冗長性に戻ります。

データのバランシングとストレージは、SimpliVity 自体のソフトウェア ストレージ レベルで行われます。

仮想マシンは仮想化クラスタを実行し、ソフトウェア ストレージ上にも仮想マシンを配置します。 デスク自体は標準テンプレートに従って取得されました。つまり、投資家と業務担当者のデスクがテストに来ました (これらは XNUMX つの異なるテンプレートです)。

テスト

テストには、LoginVSI 4.1 ソフトウェア テスト スイートが使用されました。 LoginVSI 複合体は、コントロール サーバーとテスト接続用の 12 台のマシンで構成され、別の物理ホストに展開されました。


テストは XNUMX つのモードで実行されました。

ベンチマーク モード - 300 人のナレッジ ワーカーと 300 人のストレージ ワーカーの負荷ケース。

標準モード - 荷重ケース 300 パワーワーカー。

Power ワーカーが動作し、負荷の多様性を高めるために、追加の Power Library ファイルのライブラリが LoginVSI コンプレックスに追加されました。 結果の再現性を確保するために、すべてのテストベンチ設定はデフォルトのままにしました。

ナレッジ ワーカー テストとパワー ワーカー テストは、仮想ワークステーションで作業するユーザーの実際のワークロードをシミュレートします。

ストレージ ワーカー テストは、データ ストレージ システムをテストするために特別に作成されました。実際のワークロードとは程遠く、主にユーザーがさまざまなサイズの多数のファイルを操作する必要があります。

テスト中、ユーザーは 48 秒ごとに約 10 ユーザーの割合で XNUMX 分間ワークステーションにログインします。

結果

LoginVSI テストの主な結果は、ユーザーが起動したさまざまなタスクの実行時間からコンパイルされた VSImax メトリクスです。 例: メモ帳でファイルを開く時間、7-Zip でファイルを圧縮する時間など。

メトリクス計算の詳細な説明は、公式ドキュメントで参照できます。 リンク.

つまり、LoginVSI は、オフィス スイートでのユーザー アクション、PDF の読み取りなどをシミュレートする一般的な負荷パターンを繰り返し、さまざまな遅延を測定します。 「すべてが遅くなり、作業が不可能になる」という重大なレベルの遅延があり、それ以前は最大ユーザー数に達していないと考えられます。 応答時間がこの「すべてが遅い」状態よりも 1 ミリ秒速い場合、システムは正常に動作していると見なされ、さらにユーザーを追加できます。

主な指標は次のとおりです。

指標

行った活動

詳細な 説明

ロードされたコンポーネント

N.S.L.D.

テキスト開始時間
ファイルの重さは 1 KB

メモ帳が開き、
プールからコピーされたランダムな 1 KB ドキュメントを開きます
資源

CPUとI/O

NFO

対話開始時間
メモ帳のウィンドウ

VSI メモ帳ファイルを開く [Ctrl+O]

CPU、RAM、I/O

 

ZHC*

高圧縮の Zip ファイルを作成します

ローカル圧縮
ランダムな 5MB .pst ファイルのコピー元
リソースプール

CPUとI/O

ZLC*

弱く圧縮された Zip ファイルを作成します。

ローカル圧縮
ランダムな 5MB .pst ファイルのコピー元
リソースプール

I / O

 

CPU

大きな計算をする
ランダムなデータ配列

大きな配列の作成
入出力タイマ（I/Oタイマ）で使用するランダムデータ

CPU

テストを実行すると、システムに負荷をかけずにジョブが実行される速度を示す基本的な VSIbase メトリックが最初に計算されます。 これに基づいて、VSImax しきい値が決定されます。これは、VSIbase + 1ms に等しくなります。

システム パフォーマンスに関する結論は、システムの速度を決定する VSIbase と、システムが大幅な低下なしに処理できる最大ユーザー数を決定する VSImax しきい値の XNUMX つのメトリックに基づいて行われます。

300 ナレッジ ワーカーのベンチマーク

ナレッジ ワーカーは、さまざまな小さなピークでメモリ、プロセッサ、および IO を定期的にロードするユーザーです。 このソフトウェアは、要求の厳しいオフィス ユーザーが常に何か (PDF、Java、オフィス スイート、写真の表示、7-Zip) をつついているかのように、そのワークロードをエミュレートします。 ユーザーを 300 から XNUMX まで追加すると、各ユーザーの遅延が徐々に増加します。

VSImax 統計データ:

VSIbase = 986ms、VSI しきい値に到達しませんでした。

SimpliVity モニタリングからのストレージ システム負荷統計:


このタイプの負荷では、システムは実質的にパフォーマンスを低下させることなく、負荷の増加に耐えることができます。 ユーザーのタスクを完了するのにかかる時間は順調に増加し、システムの応答時間はテスト中に変化せず、書き込みで最大 3 ミリ秒、読み取りで最大 1 ミリ秒です。

結論： 300 人のナレッジ ユーザーが現在のクラスターで問題なく作業しており、相互に干渉せず、pCPU/vCPU のオーバーサブスクリプションは 1 ～ 6 に達しています。負荷が増加するにつれて、全体的な遅延は均等に増加しますが、規定の制限には達していません。

300 ストレージ ワーカーのベンチマーク

これらは、それぞれ 30 対 70 の割合で常に書き込みと読み取りを行うユーザーです。 このテストは実験目的で行われました。 VSImax 統計データ:


VSIbase = 1673、240 ユーザーで VSI しきい値に到達しました。

SimpliVity モニタリングからのストレージ システム負荷統計:

このタイプの負荷は、基本的にストレージ システムのストレス テストです。 これが実行されると、各ユーザーはさまざまなサイズの多数のランダムなファイルをディスクに書き込みます。 この場合、一部のユーザーで特定の負荷しきい値を超えると、ファイルの書き込みタスクを完了するのにかかる時間が増加することがわかります。 同時に、ホストのストレージ システム、プロセッサ、メモリの負荷は大きく変化しないため、遅延の原因を正確に判断することは現時点では不可能です。

このような負荷は合成的で非現実的であるため、このテストを使用したシステム パフォーマンスに関する結論は、他のシステムのテスト結果と比較してのみ行うことができます。 しかし、全体的にはテストはうまくいきました。 210 セッションまではすべてうまくいきましたが、その後、奇妙な応答が始まり、Login VSI 以外は追跡されませんでした。

300 人の電力労働者

これらは、CPU、メモリ、高 IO を好むユーザーです。 これらの「パワー ユーザー」は、新しいソフトウェアのインストールや大規模なアーカイブの解凍など、長時間にわたる複雑なタスクを定期的に実行します。 VSImax 統計データ:


VSIbase = 970、VSI しきい値に到達しませんでした。

SimpliVity モニタリングからのストレージ システム負荷統計:


テスト中に、システム ノードの XNUMX つでプロセッサ負荷のしきい値に達しましたが、これはその動作に重大な影響を及ぼしませんでした。

この場合、システムはパフォーマンスを大幅に低下させることなく、負荷の増加に耐えることができます。 ユーザーのタスクを完了するのにかかる時間は順調に増加し、システムの応答時間はテスト中に変化せず、書き込みで最大 3 ミリ秒、読み取りで最大 1 ミリ秒です。

お客様にとって定期的なテストでは十分ではなかったため、私たちはさらに踏み込み、VM の特性 (オーバーサブスクリプションとディスク サイズの増加を評価するための vCPU の数) を増やし、追加の負荷を追加しました。

追加のテストを実施する際には、次のスタンド構成が使用されました。
300 台の仮想デスクトップが 4vCPU、4GB RAM、80GB HDD 構成で導入されました。

テスト マシンの XNUMX 台の構成:


マシンは、「専用 - フル コピー」オプションでデプロイされます。

300 人のナレッジ ワーカーのベンチマーク (オーバーサブスクリプション 12)

VSImax 統計データ:


VSIbase = 921 ミリ秒、VSI しきい値に到達しませんでした。

SimpliVity モニタリングからのストレージ システム負荷統計:


得られる結果は、以前の VM 構成のテストと同様です。

300 のオーバーサブスクリプションを持つ 12 人のパワー ワーカー

VSImax 統計データ:


VSIbase = 933、VSI しきい値に到達しませんでした。

SimpliVity モニタリングからのストレージ システム負荷統計:


このテスト中に、プロセッサーの負荷しきい値にも到達しましたが、これはパフォーマンスに大きな影響を与えませんでした。

得られる結果は、前の構成のテストと同様です。

負荷を 10 時間実行するとどうなるでしょうか?

次に、「蓄積効果」があるかどうかを確認し、10 時間連続でテストを実行してみましょう。

このセクションの長期テストと説明は、トラスに長時間負荷がかかった状態で問題が発生するかどうかを確認することを目的としている必要があります。

300 ナレッジ ワーカーのベンチマーク + 10 時間

さらに、300 人のナレッジ ワーカーの負荷ケースがテストされ、続いて 10 時間のユーザー作業が行われました。

VSImax 統計データ:


VSIbase = 919 ミリ秒、VSI しきい値に到達しませんでした。

VSImax 詳細な統計データ:


グラフは、テスト全体を通じてパフォーマンスの低下が観察されないことを示しています。

SimpliVity モニタリングからのストレージ システム負荷統計:


ストレージ システムのパフォーマンスはテスト全体を通じて同じままです。

合成負荷を追加した追加テスト

お客様は、ディスクにワイルドロードを追加するように要求しました。 これを行うために、ユーザーの各仮想マシンのストレージ システムにタスクが追加され、ユーザーがシステムにログインしたときにディスクに合成負荷が実行されます。 負荷は fio ユーティリティによって提供され、IOPS の数によってディスクの負荷を制限できます。 各マシンで、22 IOPS 70%/30% ランダム読み取り/書き込みの量の追加負荷を開始するタスクが開始されました。

300 ナレッジ ワーカー ベンチマーク + ユーザーあたり 22 IOPS

初期テストでは、fio が仮想マシンに重大な CPU オーバーヘッドを課すことが判明しました。 これにより、ホストの CPU が急速に過負荷になり、システム全体の動作に大きな影響を及ぼしました。

ホスト CPU 負荷:




同時に、ストレージ システムの遅延も当然増加しました。


ユーザーが 240 人になったあたりで、コンピューティング能力の不足が深刻になりました。


得られた結果により、CPU への負担が少ないテストを実施することが決定されました。

230 オフィス ワーカーのベンチマーク + ユーザーあたり 22 IOPS

CPU の負荷を軽減するために、Office ワーカーの負荷タイプが選択され、22 IOPS の合成負荷も各セッションに追加されました。

最大 CPU 負荷を超えないように、テストは 230 セッションに制限されました。

テストはユーザーを 10 時間実行させて実行され、最大負荷に近い状態での長時間動作時のシステムの安定性を確認しました。

VSImax 統計データ:


VSIbase = 918 ミリ秒、VSI しきい値に到達しませんでした。

VSImax 詳細な統計データ:


グラフは、テスト全体を通じてパフォーマンスの低下が観察されないことを示しています。

CPU 負荷統計:




このテストの実行時、ホストの CPU の負荷はほぼ最大になりました。

SimpliVity モニタリングからのストレージ システム負荷統計:


ストレージ システムのパフォーマンスはテスト全体を通じて同じままです。

テスト中のストレージ システムの負荷は、6/500 比率で約 60 IOPS (読み取り 40 IOPS、書き込み 3 IOPS) で、これはワークステーションあたり約 900 IOPS になります。

応答時間は平均して書き込みで 3 ミリ秒、読み取りで最大 1 ミリ秒でした。

合計

HPE SimpliVity インフラストラクチャ上で実際の負荷をシミュレーションすると、SimpliVity ノードのペア上で少なくとも 300 台のフル クローン マシンの仮想デスクトップをサポートできるシステムの能力を確認する結果が得られました。 同時に、ストレージ システムの応答時間はテスト全体を通じて最適なレベルに維持されました。

私たちは、実装前の長いテストとソリューションの比較のアプローチに非常に感銘を受けました。 ご希望に応じて、ワークロードのパフォーマンスをテストすることもできます。 他のハイパーコンバージド ソリューションも含まれます。 前述の顧客は現在、別のソリューションのテストを並行して終了しています。 現在のインフラストラクチャは、各職場にある一連の PC、ドメイン、およびソフトウェアにすぎません。 もちろん、テストなしで VDI に移行するのは非常に困難です。 具体的には、実際のユーザーを VDI ファームに移行しない限り、VDI ファームの実際の機能を理解することは困難です。 これらのテストを使用すると、一般ユーザーの関与を必要とせずに、特定のシステムの実際の機能を迅速に評価できます。 ここからこの研究が生まれました。

100 番目に重要なアプローチは、お客様が適切なスケーリングに直ちに取り組むことです。 ここでは、追加のサーバーを購入してファームを追加できます。たとえば、300 ユーザーの場合、すべてがユーザー価格で予測可能です。 たとえば、さらに XNUMX 人のユーザーを追加する必要がある場合、インフラストラクチャ全体のアップグレードを再検討するのではなく、すでに定義された構成で XNUMX 台のサーバーが必要であることがわかります。

HPE SimpliVity フェデレーションの可能性は興味深いものです。 ビジネスは地理的に離れているため、離れたオフィスに独自の個別の VDI ハードウェアをインストールするのが合理的です。 SimpliVity フェデレーションでは、各仮想マシンはスケジュールに従ってレプリケートされ、チャネルに負荷をかけることなく、地理的に離れたクラスター間で非常に迅速にレプリケートできます。これは、非常に優れたレベルの組み込みバックアップです。 サイト間で VM をレプリケートする場合、チャネルの使用は可能な限り最小限に抑えられ、これにより、単一のコントロール センターと多数の分散ストレージ サイトが存在する中で、非常に興味深い DR アーキテクチャを構築することが可能になります。

連盟

これらすべてを組み合わせることで、財務面を詳細に評価し、VDI のコストを会社の成長計画に重ね合わせて、ソリューションがどれだけ早く成果を上げ、どのように機能するかを理解することが可能になります。 なぜなら、どの VDI も最終的には多くのリソースを節約できるソリューションですが、同時に、使用後 5 ～ 7 年以内に変更するコスト効率の高い機会がない可能性が高いからです。

通常、コメント以外の質問がある場合は、電子メールで私に連絡してください。 [メール保護].

出所： habr.com