EMC VNX5400のI / Oパフォーマンスに対するキャッシュレベルの影響の評価

はじめに

キャッシュメカニズムがEMC VNXe3200ストレージシステムのジュニアモデル（エントリレベル）のパフォーマンスに与える影響についての記事をテストし、書いた後、手は定期的にかゆみを起こし、古いVNX2アレイでも同じことをしました。 最近、そのような機会が現れました。 VNX5400でテストを実行できました。 VNX5400を直接テストすることに加えて、EMC ExtremCacheソリューション（eMLCチップ上のPCI-E SSDカードEMC XtremSF700 +ソフトウェアEMC XtremSW）をテストすることが判明しました。 ただし、EMC ExtremCacheについては、次の記事があります。 それまでの間、VNX2アレイについてお話しましょう。



EMC ²は、2013年秋にミッドレンジレベルのストレージシステムの製品ラインを更新しました。 私の意見では、第2世代のVNXアレイ（VNX2）は、第1世代のVNX（VNX1）で行われたミスに関するよくできた作業のように見えました。 ベンダーは、ミッドレンジラインの基本的かつ革新的なアップデートとしてそれらを発表しました。 ただし、市場に登場してから1年以上たった今でも、VNX2の関連性は失われていません。 アレイ自体の特性や機能については説明しません。公式ドキュメントのData SheetとSpec Sheetへのリンクのみを提供します。

スタンドとテストの説明

テストと結果

1.キャッシュコントローラーの動作テスト（SP-ストレージプロセッサー）VNX5400 file 2Gb

このテストは2 GBファイル（NTFSのテストLUNのサイズは10 Gb）で実施されたため、SPキャッシュに完全に収まり、その結果、すべての入力/出力はストレージコントローラーのRAMから処理されます。 つまり、条件付きで、小さな「ホット」データ領域がアレイに現れました。 同時に、アレイのFastCacheがオフになりました。

その結果、アレイに組み込まれたUnisphere Analyzerで次のグラフを取得しました。







同時に、SPキャッシュは次のように埋められました（キャッシュは読み取りと書き込みの両方で機能します）。







つまり、テストの開始後数分以内に、テストファイルのすべての2GbがCacheにアップロードされました。



IOMETERの結果による平均IOPSの入力/出力ストリーム数への依存性のグラフ：







IOMETERの結果によるI / Oストリームの数に対するI / O応答時間の平均値の依存関係のグラフ：







一般に、データベースの平均応答時間は10ミリ秒までが快適であると受け入れられていることを思い出してください。 グラフによると、192のIOストリームがあり、これはかなり大きな値であるため、VNXe3200での同様のテストよりも平均応答時間がわずかに短くなりました（8ミリ秒でした）。 絶対的な意味では、違いは重要ではありませんが、それでもIOPSの数に大きなギャップがある理由の1つです。 VNXe3200は、同様のテストで192のIOスレッドで平均約23800 IOPSでした。 応答時間とIOPSの割合の差を計算すると、あちこちで約20〜25％が得られます。

2.キャッシュコントローラーの動作テスト（SP-ストレージプロセッサー）VNX5400 file 15Gb

テストは15GBファイル（NTFSを使用したLUN-20Gb）で実行されました。 FastCacheはまだオフです。 VNX5400のSPのRAMのサイズは16 Gbです。 ただし、アレイのログに依存している場合、キャッシングに使用される実際のRAMはVNX5400で約4Gbです。 他のすべては明らかに、最も基本的なOSコントローラーおよびその他の非常に幅広いストレージ機能（階層化、シンプロビジョニング、スナップショット、クローン、レプリケーション、高速キャッシュなど）の動作を保証するために使用されます。







したがって、15 Gbの高負荷（ホット）データはSPキャッシュに収まりません。 一般的に、これはまさにUnisphere Analizerのチャートに表示されるものです。 すべての15 Gbの完全にランダムな入力/出力は、コントローラーによって完全にキャッシュすることはできません。そのため、このテストでは物理スピンドルがパフォーマンスの大部分を提供します。 直接駆動します。







同時に、SP Cacheは効率的ではありませんが、引き続き機能します。







IOMETERの結果による平均IOPSの入力/出力ストリーム数への依存性のグラフ：







IOMETERの結果によるI / Oストリームの数に対するI / O応答時間の平均値の依存関係のグラフ：







グラフによると、すでに24ストリームでの応答時間は約14ミリ秒です。 快適ゾーンを超えました。 また、ディスクのピークパフォーマンスの見積もりがあまりにも見落としていたことに驚き、それを整理するために「行きました」。 その結果、テスト中にパフォーマンス層のすべてのプライベートRGの負荷が同じではないことがわかりました。 つまり パフォーマンス上の理由から、テストファイルはパフォーマンス層の3つのRGすべてに均等に分散されていません。 グラフでは、このように見えます（ドライブ5、6、および7はExtreme Perfomance TierのSSDです）。







つまり、15個すべてのスピンドルが「フル」テストに関与しているわけではありません。 VNX2アレイ上のFastVPプールでの同様の効果をスムーズにするために、異なる容量（SSD、SAS、NL_SAS）のディスク間だけでなく、同じティア内のプライベートRG間でも「ホット」および「コールド」データを再配布できるテクノロジーがあります。 プライベートRG間でのデータの再配布は、階層間のデータの移行と同様に、スケジュールと同時に行われます。 アレイインターフェイスでは、これは[階層化]タブのプールプロパティで確認できます。 特に、私の場合、テスト直後は次のように見えました。







アレイがアイドル状態のとき、ウィンドウは次のようになりました。







もう1つの興味深い画像は、SPキャッシュを充填するグラフとテスト済みLUNの全体的なパフォーマンスを重ね合わせることで確認できます。







グラフは、かなり不快な状況であっても、SP Cacheにより「追加の」IOPSを獲得できることを示しています。

3. VNX5400ファイル15GbでFastCacheをテストする

アレイでFastCacheを有効にした後（Raid1の2つの100Gb SSD）、15Gb（NTFSのLUN-20Gb）の同じファイルでテストを実行しました。 EMC ²アレイのFastCacheは、SP Cacheとアレイディスク自体の間に組み込まれているSSDディスクに基づく追加レベルのキャッシュです。 15Gb（または条件付きで「ホット」なデータ領域）のファイルは100Gb FastCacheに完全に収まる必要があります。これにより、前のテストの結果が改善されます。

Unisphere Analizerから次のグラフを取得しました（IOPSで）。







FastCacheは次のように入力されます（％）。







Read Hits / s-FastCacheから解決された読み取り操作。

Read Misses / s-FastCacheでデータが見つからず、アレイディスクから要求された操作。







書き込みヒット/秒-ディスクへの「古い」データの予備ダンプを必要としないFastCacheでの書き込み操作（キャッシュ場所の予備クリア）、またはキャッシュに書き込まれたがまだディスクに転送されていないデータを要求した操作。

書き込みミス/ s-FastCacheで解決されなかった書き込み操作、またはキャッシュスペースの強制（緊急）解放が必要な書き込み操作。







また、SP Cacheはアイドル状態にならず、入出力の一部を解決しました。







サーバー側では、IOMTRは次のように見えました。

IOMETERの結果による平均IOPSの入力/出力ストリーム数への依存性のグラフ：







IOMETERの結果によるI / Oストリームの数に対するI / O応答時間の平均値の依存関係のグラフ：







最新のグラフは、FastCacheの「ホット」エリアをロードした後、応答時間がさらに減少し、入力/出力フローが増加するにつれてのみ増加し始めることを示しています。 同時に、グラフは、100のIOストリームの値をはるかに超えて10ミリ秒の上限を「突破」します。

4. VNX5400ファイル150GbでFastCacheをテストする

次のテストは150Gbファイルで実行されました（NTFS 200GbでのテストLUN）。 つまり このテストの「ホット」データ領域は、アレイのFastCacheサイズを約1.5倍超えました。 以下の結果が得られました。

Unisphere Analizerのグラフ（IOPS）。







FastCacheにデータを入力していましたが、かなりゆっくりでした。 75分のテストが終了するまでに、約20％がいっぱいになりました（150Gbのテストファイルのうち約20Gb）。







FastCacheでの読み取り操作のヒットではなく、ヒットのチャート。







FastCacheでの書き込み操作のチャートのヒット/秒およびミス/秒。







SPキャッシュもアイドル状態ではありませんでした。







サーバー側とIOMETRから見た様子。

IOMETERの結果による平均IOPSの入力/出力ストリーム数への依存性のグラフ：







IOMETERの結果によるI / Oストリームの数に対するI / O応答時間の平均値の依存関係のグラフ：







グラフは、IOPS値がFastCacheなしで15Gbファイルをテストしたときよりもわずかに高いことを示しています。 したがって、この不快な状況では、FastCacheが構成から追加のIOPSを圧縮するのに役立つと結論付けることができます。 しかし実際には、すべてがそうではないことが判明しました。



まず、このテストでは、「パフォーマンス層」のすべてのプライベートRAIDグループ（Raid5 4 + 1）がより均等にロードされました。







次に、150Gbファイルで追加のテストを行うことにしましたが、FastCacheはオフになりました。 IOMETRのグラフは次のとおりです（最初は信じていなかったため、テストを2回実施しました）。



IOMETERの結果による平均IOPSの入力/出力ストリーム数への依存性のグラフ：







IOMETERの結果によるI / Oストリームの数に対するI / O応答時間の平均値の依存関係のグラフ：







つまり、ホットデータの量がFastCacheのサイズを超え、ランダムリクエストの割合が高い状況では、FastCacheの入力に時間がかかります。 このような状況では、FastCacheは、わずかではありますが、応答時間に追加の遅延をもたらします。 この状況では、プール内のSSDディスクで追加のExtreme Performance Tierを使用することを提案できます。 この場合、ホットデータの一部はその上に「落ち着き」、FastCacheを介して処理されません。 したがって、FastCacheを介して処理されるホットデータの量は減少し、より快適な範囲になります。 根拠がないように、別のテストを実施しました。

5. VNX5400ファイル80GbでFastCacheをテストする

このテストは、サイズが80Gb（NTFS 100GbのテストLUN）のファイルで実行されました。これは、テスト対象のアレイのFastCacheボリュームに十分近いサイズです。 つまり、「ホット」データ領域は非常に大きかったが、それでもFastCacheに完全に適合した。

Unisphere Analizerのグラフ（IOPS）。







FastCacheは、150Gbファイルよりもアクティブにいっぱいになりました。







SP Cacheは、入力/出力の一部も解決しました。







サーバー側とIOMETRから見ると、すべてが150Gbファイルよりもずっとバラ色に見えました。

IOMETERの結果による平均IOPSの入力/出力ストリーム数への依存性のグラフ：







IOMETERの結果によるI / Oストリームの数に対するI / O応答時間の平均値の依存関係のグラフ：







約24のIOストリームから（テストの開始から約15分）、データがますますFastCacheに取り込まれ始めました。 したがって、テストの全体的なパフォーマンスも向上し始めましたが、IOストリームの増加に伴う応答時間は、150Gbファイルを使用したテストほど増加しませんでした。

ディスクプールに関する小さな余談

結論

テストに基づいて、次のことが言えます。 奇妙に聞こえるかもしれませんが、FastCacheは常に良いとは限りません。 不適切に設計されたシステムでは、劣化の方向を含むパフォーマンスに影響を与える可能性があります。 設計段階で見逃さないように、デモアレイで実際の負荷のコピーまたは一部を駆動することをお勧めします。 ベンダーからデモ配列をリクエストできます。 これが不可能な場合は、同じベンダーが計算で使用することを提案しているホット/ウォーム/コールドデータ比率から続行する必要があります（統計データおよびその他の考慮事項に基づく）。 私の意見では、デモアレイを使用した最初のオプションの方が適しています。 一般に、適切に設計されたアレイでは、VNX2の追加レベルのキャッシュ（FastCache）により、パフォーマンスがかなり向上します。



VNX5400のパフォーマンスは、少なくとも小規模で同等の構成（ディスクの数、FastCacheサイズ）でVNXe3200のパフォーマンスを大きく超えることはありません。 これはおそらく、若いアレイが今年2014年にのみリリースされたという事実によるものです。 同じ結論がVNX5200にも適用できます。VNX5200では、SP（コントローラー）はVNX5400と変わりません（交換のサービス部品番号は同じです）。 VNX5200には、ディスクの最大数の制限（125個対250個。VNX5400の場合）、FastCacheの最大サイズ（VNX5400の場合は600Gb対1000Gb）の制限のみがあり、サーバーを接続するためのポートを持つ追加の拡張カード用のスロットが1つ少なくなっています。



実行されるすべてのテストは、実際のワークロードとは関係のない「合成」です。 ただし、私の意見では、このようなモデリングは、特定の状況におけるストレージシステムの動作の一般的な傾向を理解するのに役立ちます。

PSのように

ストリーミングロード用のストレージが必要な場合（Nr：大きなビデオストリームの記録と処理）、ここではキャッシュは役に立ちません。 オーバーフローが発生し、データストレージシステムのスピンドル（ディスク）の数がこの状況で決定するときが来るでしょう。

トランザクションの負荷が非常に高い場合。 数千または数万のユーザー向けの大規模なOLTPデータベースまたはVDIの場合、おそらく従来のストレージと階層化ではなく、オールフラッシュアレイが必要になります。