HPE SimpliVity 380 for VDIの機能：厳しい負荷テスト

顧客はVDIを望んでいました。 SimpliVity + VDI Citrix Virtual Desktopの束を非常によく見ました。 すべてのオペレーター、都市のオフィスワーカーなど。 移行の最初の段階では5,000人のユーザーしかいないため、ストレステストを主張しました。 VDIはスローダウンし始め、落ち着いて横たわることができます。これは、チャネルの問題が原因で常に発生するとは限りません。 VDI専用の非常に強力なテストパッケージを購入し、インフラストラクチャがディスクとプロセッサに落ちるまでロードしました。



そのため、洗練されたVDIテストには、ペットボトルのLoginVSIソフトウェアが必要です。 300ユーザーのライセンスがあります。 次に、1台のサーバーで最大ユーザー密度のタスクに適した梱包でHPE SimpliVity 380ハードウェアを取り出し、適切なオーバーサブスクリプションで仮想マシンをカットし、Win10にオフィスソフトウェアを配置してテストを開始しました。



行こう！

システム

2つのノード（サーバー）HPE SimpliVity 380 Gen10。 それぞれについて：

• 2 x Intel Xeon Platinum 8170 26c 2.1Ghz
• 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カード。

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



ノードは、vCenterを実行するVmware vSphereクラスターにクラスター化されます。



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





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



各仮想マシンには2vCPUと4GB RAMがあります：











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

• Windows 10（64ビット）、バージョン1809。
• Adobe Reader XI。
• Citrix Virtual Delivery Agent 1811.1。
• ドロPDF 1.82。
• Java 7アップデート13。
• Microsoft Office Professional Plus 2016。

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



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



仮想マシンは仮想化クラスターを起動し、ソフトウェアストレージでホストします。 デスクトップ自体は、標準テンプレートに従って撮影されました。投資家と実務家のテーブルは、テストのために運転しました（これらは2つの異なるテンプレートです）。

テスト中

テストには、LoginVSI 4.1ソフトウェアのテストコンプレックスが使用されました。 管理サーバーの一部としてのLoginVSI複合システムとテスト接続用の12台のマシンは、個別の物理ホストに展開されました。





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



ベンチマークモード-300人のナレッジワーカーと300人のストレージワーカーのロードオプション。



標準モードは、300人のPower Workerロードオプションです。



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



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



ストレージワーカーテストは、ストレージシステムをテストするために特別に作成されたもので、実際のワークロードからはほど遠く、ほとんどの場合、さまざまなサイズの多数のファイルを使用したユーザーの作業に基づいています。



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

結果

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



メトリックの計算の詳細な説明は、 リンクの公式ドキュメントに記載されています。



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



基本的な指標は次のとおりです。

メートル法	実行されたアクション	詳細 説明	ローダブルコンポーネント
NSLD	テキストの開封時間 1,500キロバイトのファイル	メモ帳が起動し、 1,500キロバイトのランダムなドキュメントを開き、プールからコピーします 資源の	CPUおよびI / O
NFO	ダイアログを開く時間 メモ帳ウィンドウ	VSI-Notepadファイルを開く[Ctrl + O]	CPU、RAM、およびI / O
ZHC *	強力な圧縮Zipファイル作成時間	ローカル圧縮 5MBのランダムな.pstファイルサイズ。 リソースプール	CPUおよびI / O
ZLC *	低圧縮Zipファイル作成時間	ローカル圧縮 5MBのランダムな.pstファイルサイズ。 リソースプール	I / O
CPU	大規模な計算 ランダムデータ配列	大きな配列を作成する I / Oタイマーで使用されるランダムデータ（I / Oタイマー）	CPU

テスト中に、基本的なVSIbaseメトリックが最初に計算されます。これは、システムに負荷がかからないタスクの速度を示します。 それに基づいて、VSImax + 1000msに等しいVSImaxしきい値が決定されます。



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

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

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



VSImax統計データ：



VSIbase = 986ms、VSI Thresholdに達しませんでした。



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





このタイプの負荷を使用すると、システムはパフォーマンスの低下をほとんどまたはまったく伴わずに負荷の増加に耐えることができます。 ユーザータスクの実行時間はスムーズに伸び、テスト中にシステムの応答時間は変化せず、書き込みで最大3ミリ秒、読み取りで最大1ミリ秒です。



結論：ユーザーの300の知識は現在のクラスターで問題なく機能し、互いに干渉せず、pCPU / vCPU 1〜6のオーバーサブスクリプションに達します。

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

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





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



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



実際、このタイプの負荷は、ストレージシステムのストレステストです。 実行されると、各ユーザーは異なるサイズの多くのランダムファイルをディスクに書き込みます。 この場合、特定の負荷しきい値を超えると、一部のユーザーがファイル記録タスクを完了するのに必要な時間を増やすことがわかります。 同時に、ストレージシステム、プロセッサ、およびホストメモリの負荷は大きく変化しないため、現在、遅延が何に関連しているかを正確に判断することはできません。



このテストを使用したシステムパフォーマンスに関する結論は、他のシステムでのテスト結果と比較する場合にのみ作成できます。このような負荷は合成的で非現実的であるためです。 ただし、一般に、テストはうまくいきました。 最大210セッションまで、すべてが順調に進み、その後、理解できない応答が開始されました。これは、Login VSI以外では追跡されませんでした。

300人のパワーワーカー

これらは、プロセッサ、メモリ、高IOを愛するユーザーです。 これらの「上級ユーザー」は、新しいソフトウェアのインストールや大きなアーカイブの解凍など、長いピークのある複雑なタスクを定期的に実行します。 VSImax統計データ：





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



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





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











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



顧客向けの通常のテストでは十分ではなかったため、VMの特性（オーバーサブスクリプションとディスクサイズの増加を評価するためのvCPUの数）を増やし、負荷を追加しました。



追加のテストでは、次のスタンド構成が使用されました。

4vCPU、4GB RAM、80GB HDDの構成で300台の仮想デスクトップを展開しました。



テストマシンの1つの構成：





マシンは、専用-フルコピーオプションで展開されます。

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負荷：









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





約240人のユーザーにとって、計算能力の不足が重要になっています。





その結果、CPUに負担をかけないテストを実施することが決定されました。

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

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



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



このテストは、最大負荷に近い長時間の動作中にシステムの安定性を確認するために、ユーザーのその後の作業で10時間にわたって開始されました。



VSImax統計データ：





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



VSImax詳細統計データ：





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



CPU統計：









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



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





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



テスト中のストレージシステムの負荷は、60/40比で約6,500 IOPS（読み取りで3,900 IOPS、書き込みで2,600 IOPS）であり、ワークステーションあたり約28 IOPSです。



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

まとめ

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



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



2番目の重要なアプローチ-顧客はすぐに正しいスケーリングを決めました。 ここでは、サーバーを購入してファームを追加できます。たとえば、100ユーザーの場合、すべてはユーザーの価格で予測可能です。 たとえば、300人のユーザーを追加する必要がある場合、すでに定義された構成で2つのサーバーが必要であることがわかり、インフラストラクチャ全体をアップグレードする可能性を確認しません。



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



連盟



これらすべてにより、財務面を非常に詳細に評価し、VDIのコストを会社の成長計画に課し、ソリューションがどれだけ早く成果を上げ、どのように機能するかを理解することができます。 なぜなら、VDIは最終的に大量のリソースを節約するソリューションであるが、同時に、ほとんどの場合、使用後5〜7年以内に変更する費用対効果の高い機会がないためです。



一般に、コメント以外の質問がある場合は、mk @ croc.ru宛にメールをください。