QSAN XCubeSAN ストレージ システムでの SSD キャッシュの実装

SSD の使用に基づいてパフォーマンスを向上させるテクノロジーが発明され、ストレージ システムで広く使用されてきました。 まず第一に、ストレージ スペースとして SSD を使用することです。これは 100% 効果的ですが、高価です。 したがって、タイリングおよびキャッシュ技術が使用され、SSD は最も一般的な (「ホット」) データにのみ使用されます。 階層化は、「ホット」データを長期 (数日から数週間) 使用するシナリオに適しています。 対照的に、キャッシュは短期間 (数分から数時間) の使用に適しています。 これらのオプションは両方ともストレージ システムに実装されています QSAN XCubeSAN。 この記事では、XNUMX 番目のアルゴリズムの実装について見ていきます。 SSDキャッシュ.

SSD キャッシュ テクノロジの本質は、ハード ドライブとコントローラの RAM の間の中間キャッシュとして SSD を使用することです。 もちろん、SSD のパフォーマンスはコントローラー自体のキャッシュのパフォーマンスよりも低くなりますが、その容量は桁違いに高くなります。 したがって、速度と量の間である程度の妥協点が得られます。

読み取りに SSD キャッシュを使用する場合の適応:

• 書き込み操作よりも読み取り操作が優先されます (データベースや Web アプリケーションで最も一般的です)。
• ハードドライブアレイのパフォーマンスという形でのボトルネックの存在。
• 必要なデータの量は SSD キャッシュのサイズよりも少ないです。

読み取り+書き込み SSD キャッシュを使用する場合の指示は、操作の性質 (混合タイプ (ファイル サーバーなど)) を除いて同じです。

ほとんどのストレージ ベンダーは、自社の製品で読み取り専用の SSD キャッシュを使用しています。 根本的な違い QSAN キャッシュを書き込みにも使用する機能を提供します。 QSAN ストレージ システムで SSD キャッシュ機能をアクティブにするには、別のライセンス (電子的に提供) を購入する必要があります。

XCubeSAN の SSD キャッシュは、個別の SSD キャッシュ プールの形式で物理的に実装されます。 システム内には最大 XNUMX つまで存在できます。 もちろん、各プールは独自の SSD セットを使用します。 そして、すでに仮想ディスクのプロパティで、キャッシュプールを使用するかどうか、およびどのキャッシュプールを使用するかを決定します。 ボリュームのキャッシュ使用の有効化と無効化は、I/O を停止することなくオンラインで実行できます。 SSD をプールにホット アドしたり、そこから削除したりすることもできます。 SSD プール キャッシュを作成するときは、読み取り専用または読み取り + 書き込みのどのモードで動作するかを選択する必要があります。 その物理的な組織はこれに依存します。 複数のキャッシュ プールが存在する可能性があるため、それらの機能は異なる場合があります (つまり、システムは読み取りキャッシュ プールと読み取り+書き込みキャッシュ プールの両方を同時に持つことができます)。

読み取り専用キャッシュ プールが使用される場合、1 ～ 8 台の SSD で構成できます。 ディスクは NRAID+ 構造に結合されるため、同じ容量および同じベンダーである必要はありません。 プール内のすべての SSD は共有されます。 システムは、最大のパフォーマンスを達成するために、すべての SSD 間で受信リクエストを個別に並列化しようとします。 SSD の XNUMX つが故障しても、悪いことは起こりません。結局のところ、キャッシュにはハード ドライブのアレイに保存されているデータのコピーしか含まれていません。 利用可能な SSD キャッシュの量が減少するだけです (または、XNUMX つのドライブの元の SSD キャッシュを使用している場合はゼロになります)。

キャッシュが読み取り + 書き込み操作に使用される場合、コンテンツはドライブのペアにミラーリングされる (NRAID 1+ 構造が使用される) ため、プール内の SSD の数は 1 の倍数である必要があります。 キャッシュにはまだハードドライブに書き込まれていないデータが含まれている可能性があるため、キャッシュを複製する必要があります。 この場合、キャッシュ プールから SSD に障害が発生すると、情報が失われます。 NRAID XNUMX+ の場合、SSD に障害が発生すると、キャッシュが読み取り専用状態に転送され、未書き込みのデータがハード ドライブ アレイにダンプされます。 障害のある SSD を交換すると、キャッシュは元の動作モードに戻ります。 ちなみに、セキュリティを強化するために、読み取り + 書き込みキャッシュに専用のホット スペアを割り当てることができます。

XCubeSAN で SSD キャッシュ機能を使用する場合、ストレージ コントローラーのメモリ量に関して多くの要件があります。システム メモリが多いほど、使用できるキャッシュ プールも大きくなります。

SSD キャッシュをオン/オフにするオプションのみを提供するほとんどのストレージ システム メーカーとは異なり、QSAN はより多くのオプションを提供します。 特に、負荷の性質に応じてキャッシュ動作モードを選択できます。 対応するサービス (データベース、ファイル システム、Web サービス) に最も近い操作を行う XNUMX つのプリセット テンプレートがあります。 さらに、管理者は必要なパラメータ値を設定することで独自のプロファイルを作成できます。

• ブロック サイズ (キャッシュ ブロック サイズ) – 1/2/4 MB
• ブロックをキャッシュにコピーするためにブロックを読み取るリクエストの数 (Populate-on-Read しきい値) – 1..4
• ブロックをキャッシュにコピーするためにブロックを書き込むリクエストの数 (Populate-on-Write しきい値) – 0..4

プロファイルはその場で変更できますが、もちろん、キャッシュの内容がリセットされ、新しい「ウォーミングアップ」が行われます。

SSD キャッシュの動作原理を考慮すると、SSD キャッシュを使用する際の主な動作を強調できます。

• キャッシュにないデータを読み取る。
• キャッシュにデータが存在する場合はデータを読み取ります。
• 読み取りキャッシュを使用する場合のデータの書き込み。
• 読み取り+書き込みキャッシュを使用する場合のデータの書き込み。

キャッシュにないデータの読み取り

1. ホストからのリクエストがコントローラーに到着します。
2. 要求されたものは SSD キャッシュにないため、ハードドライブから読み取られます。
3. 読み取られたデータはホストに送信されます。 同時に、これらのブロックが「ホット」であるかどうかのチェックが行われます。
4. 「はい」の場合、それらは今後使用するために SSD キャッシュにコピーされます。

キャッシュにデータが存在する場合はデータを読み取ります

1. ホストからのリクエストがコントローラーに到着します。
2. 要求されたデータは SSD キャッシュ内にあるため、そこから読み取られます。
3. 読み取られたデータはホストに送信されます。

リードキャッシュ使用時のデータの書き込み

1. ホストからの書き込み要求がコントローラーに到着します。
2. データはハードドライブに書き込まれます。
3. 記録が成功したことを示す応答がホストに返されます。
4. 同時に、ブロックが「ホット」であるかどうかがチェックされます (Populate-on-Write Threshold パラメーターが比較されます)。 「はい」の場合、後で使用するために SSD キャッシュにコピーされます。

読み取り+書き込みキャッシュを使用する場合のデータの書き込み

1. ホストからの書き込み要求がコントローラーに到着します。
2. データは SSD キャッシュに書き込まれます。
3. 記録が成功したことを示す応答がホストに返されます。
4. SSD キャッシュのデータはバックグラウンドでハード ドライブに書き込まれます。

チェックインアクション

テストスタンド

2 台のサーバー (CPU: 2 x Xeon E5-2620v3 2.4Hz / RAM: 32GB) は、ファイバー チャネル 16G 経由で 5224 つのポートによって XCubeSAN XS16D ストレージ システム (XNUMXGB RAM/コントローラー) に直接接続されています。

データ アレイとして 16 台の Seagate Constellation ES、ST500NM0001、500GB、SAS 6Gb/s を RAID5 (15+1) で組み合わせ、キャッシュとして 8 台の HGST Ultrastar SSD800MH.B、HUSMH8010BSS200、100GB、SAS 12Gb/s を使用しました。

2 つのボリューム (サーバーごとに XNUMX つ) が作成されました。

テスト 1. 1 ～ 8 台の SSD からの読み取り専用 SSD キャッシュ

SSDキャッシュ

• I/O タイプ: カスタマイズ
• キャッシュブロックサイズ: 4MB
• 読み取り時の設定しきい値: 1
• 書き込み時の設定しきい値: 0

I/Oパターン

• ツール: IOmeter V1.1.0
• 労働者：1
• 未処理 (キューの深さ): 128
• アクセス仕様: 4KB、100% 読み取り、100% ランダム

理論的には、キャッシュ プール内の SSD の数が多いほど、パフォーマンスが向上します。 実際に、これは確認されています。 ボリューム数が少ない SSD の数が大幅に増加するだけでは、爆発的な効果は得られません。

テスト 2. 2 ～ 8 台の SSD を使用した読み取り + 書き込みモードの SSD キャッシュ

SSDキャッシュ

• I/O タイプ: カスタマイズ
• キャッシュブロックサイズ: 4MB
• 読み取り時の設定しきい値: 1
• 書き込み時の設定しきい値: 1

I/Oパターン

• ツール: IOmeter V1.1.0
• 労働者：1
• 未処理 (キューの深さ): 128
• アクセス仕様: 4KB、100%書き込み、100%ランダム

結果は同じで、SSD の数が増えると爆発的なパフォーマンスの向上と拡張が可能になります。

どちらのテストでも、作業データの量は合計キャッシュ サイズよりも少なくなりました。 したがって、時間の経過とともに、すべてのブロックがキャッシュにコピーされました。 そして実際、この作業は SSD を使用してすでに実行されており、ハードドライブにはほとんど影響を与えませんでした。 これらのテストの目的は、キャッシュをウォームアップし、SSD の数に応じてパフォーマンスをスケーリングすることの有効性を明確に実証することでした。

ここで、地球に戻って、データ量がキャッシュ サイズよりも大きい場合の、より現実的な状況を確認してみましょう。 適度な時間内にテストに合格するために (ボリューム サイズが大きくなると、キャッシュの「ウォームアップ」期間が大幅に長くなります)、ボリューム サイズを 120 GB に制限します。

テスト 3. データベース エミュレーション

SSDキャッシュ

• I/O タイプ: データベース
• キャッシュブロックサイズ: 1MB
• 読み取り時の設定しきい値: 2
• 書き込み時の設定しきい値: 1

I/Oパターン

• ツール: IOmeter V1.1.0
• 労働者：1
• 未処理 (キューの深さ): 128
• アクセス仕様: 8KB、67% 読み取り、100% ランダム

評決

もちろん、明らかな結論は、SSD キャッシュを使用するとストレージ システムのパフォーマンスが向上するという優れた効率性です。 に適用されます QSAN XCubeSAN このステートメントは完全に当​​てはまります。SSD キャッシュ機能は完全に実装されています。 これは、読み取りおよび読み取り + 書き込みモードのサポート、あらゆる使用シナリオに対応する柔軟な設定、およびシステム全体の全体的なパフォーマンスに関係します。 したがって、非常にリーズナブルなコスト (ライセンス価格は 1 ～ 2 台の SSD のコストに匹敵します) で、全体的なパフォーマンスを大幅に向上させることができます。

出所： habr.com