長い間、私はエントリーレベルのアレイのテストに出くわしませんでした。ストリーミング負荷のある単一のコントローラーを介して最大1.5 Gb / sを渡すことができました。 NetApp E2700はこのタスクに対処しました。 6月に、 Unboxing NetApp E2700をホストしました。 これで、このストレージシステムのテスト結果を共有できます。 以下に、負荷テストの結果と、NetApp Eシリーズ2700アレイの結果的な定量的パフォーマンスインジケータ（IOps、スループット、遅延）を示します。
ディスクアレイの構成は次のとおりです。
アレイをサーバーに接続するスキーム：
テストサーバーの構成：
テスト方法
負荷ジェネレーターとして、Linuxで最も「真の」ベンチマークとしてFIOベンチマークを使用します。 次の種類の負荷の下で、平均速度（帯域幅、Mb / s）および平均遅延（レイテンシ、ミリ秒）のデータを取得したい：
- 256 kb、512 Kb、および1024 Kbのブロックでの100％連続読み取り。
- 256 kb、512 Kb、および1024 Kbのブロックでの100％順次記録。
- 256 kb、512 Kb、および1024 Kbのブロックでの混合シーケンシャル読み取り/書き込み（50/50）。
- 4 kb、8 Kb、および16 Kbのブロックでの100％ランダム読み取り。
- 4 kb、8 Kb、および16 Kbのブロックでの100％ランダム記録。
- 混合ランダム読み取り/書き込み（50/50）、256 kb、512 Kb、および1024 Kbのブロック。
この場合、アレイから2つのLUNを使用します。それぞれ1 TBのサイズで、サーバーレベルでRAWデバイスとして使用可能なsdbとsdcです。
私のテストの重要なポイントは、アレイがサポートするさまざまなRAIDレベルのパフォーマンスを比較することです。 したがって、DDP、RAID6、RAID10で作成されたLUNに交互に負荷を適用します。 そして、24個すべてのディスクに基づいてダイナミックディスクプールとボリュームグループを作成します。
悪名高い「Linuxメモリキャッシュ」の動作アルゴリズムに結果が依存しないようにするために、ブロックデバイスを使用します。その上にファイルシステムを編成することはありません。 もちろん、これはストリーミングアプリケーションの最も標準的な構成ではありませんが、アレイが正確に何を可能にするかを理解することは重要です。 ただし、FIOロードパターンでdirect = 1およびbuffered = 0パラメーターを使用する場合、EXT4レベルでファイルを操作（書き込み）すると、bandwithブロックデバイスでもほぼ同じ結果が表示されます。 同時に、ファイルシステムを使用する場合のレイテンシインジケーターは、rawデバイスを使用する場合よりも15〜20％高くなります。
FIOの負荷パターンは次のように構成されます。
[グローバル]
説明= seq-reads
ioengine = libaio
bs =上記を参照
ダイレクト= 1
バッファリング= 0
rw = [書き込み、読み取り、rw、randwrite、randread、randrw]
ランタイム= 900
糸
[sdb]
ファイル名= / dev / sdc
iodepth =参照 下
[sdc]
ファイル名= / dev / sdb
iodepth =参照 下
私が正しく理解していれば、man by fio、iodepthパラメーターは、同時にディスクで動作する独立したスレッドの数を決定します。 したがって、構成では、X * 2（4、8、16）に等しいスレッド数を取得します。
その結果、テストスイートは次のようになりました。
メソッドを見つけ出し、パターンを決定し、負荷を与えました。 管理者の作業を容易にするために、2つのパラメーター（bsとiodepth）の値が変更される個別のファイルの形式でFIOパターンのセットをカットできます。 その後、2つのサイクル（2つのパラメーターの値を変更）で必要なインジケーターを別のファイルに保存してすべてのパターンを実行するスクリプトを作成できます。
はい、私はいくつかのポイントをほとんど忘れていました。 アレイレベルで、次のようにキャッシュ設定を構成しました。
- ストリーミング録音の場合、読み取りキャッシュをオフにしました。
- ストリーミング読み取りの場合、書き込みキャッシュをそれぞれオフにし、動的読み取りプリフェッチアルゴリズムを使用しませんでした。
- 読み取り操作と書き込み操作が混在している場合、キャッシュは完全にアクティブ化されます。
Linuxレベルでは、通常のI / Oスケジューラーをストリーミング操作のnoopおよびランダム操作の締切に変更しました。 さらに、HBAレベルでトラフィックのバランスを正しくとるために、NetAppのマルチパスドライバーMPP / RDACをインストールしました。 彼の仕事の結果は嬉しい驚きでした。HBAポート間のデータの流れはほぼ50 x 50でバランスが取れていました。これはQlogicや通常のlinux multipathdでは見たことがありません。
SANTricityには、いくつかの調整パラメーターがあります（たとえば、ボリュームレベルでのデータキャッシュの管理について上記で説明しました）。 別の潜在的に興味深いパラメータは、ボリュームレベルで設定および変更できるセグメントサイズです。 セグメントサイズは、コントローラーが1つのディスクに書き込むブロックです（セグメント内のデータは512バイトのブロックで書き込まれます）。 DDPを使用する場合、プールで作成されるすべてのボリュームのこのパラメーターのサイズは同じ（128k）であり、変更できません。
VolumeGroupに基づいて作成されたボリュームの場合、ボリューム（FileSystem、Database、Multimedia）に対して事前に構成されたロードテンプレートを選択できます。 さらに、SegmentSizeのサイズを32 Kb〜512 Kbの範囲で自分で選択できます。
一般に、組み込みのボリュームI / O特性タイプの場合、セグメントサイズのサイズはそれほど多様ではありません。
- パターンの場合ファイルシステム= 128 Kb;
- パターンデータベースの場合= 128 Kb;
- マルチメディアのパターンの場合= 256 Kb。
ボリュームの作成時にデフォルト（ファイルシステム）パターンを変更しなかったため、DDPと通常のVolumeGroupで作成されたボリュームのセグメントサイズが同じになります。
もちろん、セグメントサイズのサイズをいじって、書き込み操作のパフォーマンスにどのように影響するかを理解しました（たとえば）。 結果は非常に標準的です：
- 最小サイズのSS = 32 Kbでは、小さなブロックサイズの操作でより高いパフォーマンスが得られます。
- 最大サイズのSS = 1024 Kbでは、大きなブロックサイズの操作でより高いパフォーマンスが得られます。
- FIOが動作するSSサイズとブロックサイズを合わせると、結果はさらに良くなります。
- 1つの「しかし」があります。 大きなブロックでレコーディングをストリーミングし、SS = 1024 Kbの場合、サイズがSS = 128 Kbまたは256 Kbの場合よりレイテンシ値が高くなることに気付きました。
合計すると、このパラメーターの有用性は明らかであり、多くのランダムな操作があると仮定する場合、32 Kbに設定することは理にかなっています（もちろん、DDPを使用しない限り）。 ストリーミング操作の場合、SS値を最大に設定する理由はありません。 私はデータ転送速度の基本的な増加を観察しませんでした。また、レイテンシインジケータはアプリケーションにとって重要になる可能性があります。
結果（評価と結果の比較）
DDPテスト結果
RAID6テスト結果
RAID10テスト結果
結果の評価
- 私がすぐに気づいた最初のポイントは、パターンの0％読み取りキャッシュの使用率です（書き込みキャッシュが完全にオフになっている場合でも）。 接続先を理解することはできませんでしたが、読み取り操作の結果は書き込み操作に比べて大幅に低下しました。 おそらく、これは、読み取りキャッシュを2つのコントローラー間でミラー化する必要があるため、テストアレイの単一コントローラー構成によるものです。
- 2番目のポイントは、ランダム操作の割合がかなり低いことです。 これは、（上で書いたように）セグメントサイズのサイズがデフォルトで128 Kbに使用されていたという事実によって説明されます。 ブロックサイズが小さい場合、このSSサイズは適切ではありません。 検証のために、SS = 32 KbでRAID6およびRAID10のボリュームにランダムロードを実行しました。 結果ははるかに興味深いものでした。 ただし、DDPの場合、SSのサイズを変更できないため、DDPのランダムな負荷は禁忌です。
- DDP、RAID6、およびRAID10のパフォーマンスをSS = 128 Kbのサイズと比較すると、次のパターンを追跡できます。
- 一般に、ブロックの3つの異なる論理表現の間に大きな違いはありません。
- RAID10はより安定しているため、負荷を混合して保持し、同時に最高のレイテンシを実現しますが、RAID6とDDPの書き込み速度と読み取り速度は低下します。
- ブロックサイズが増加するランダム操作でのRAID6とDDPは、最高のレイテンシとIOpsを示します。 ほとんどの場合、これはSSのサイズが原因です（上記を参照）。 ただし、RAID10はそのような効果を示しませんでした。
- 上記で書いたように、DDPのランダムなロードは、いずれの場合でも、32 KB未満のブロックサイズでは禁忌です。
結論
長い間、私はエントリーレベルのアレイのテストに出くわしませんでした。ストリーミング負荷のある単一のコントローラーを介して最大1.5 Gb / sを渡すことができました。 デュアルコントローラー構成では、最大3 Gb / sを処理できると想定できます。 そして、これは最大24 Gb / sのデータストリームです。
もちろん、私たちが使用するテストは総合的なものです。 しかし、示されている結果は非常に良好です。 予想どおり、配列はランダム操作中に混合負荷を弱く保持しますが、奇跡はありません:-)。
使いやすさと、エントリーレベルのアレイの特定の負荷パターンの設定を最適化する可能性の観点から、E2700は最高の性能を発揮しています。 SANTricityには、明確でかなりシンプルなインターフェイスがあり、最小限のグリッチとブレーキがあります。 しばしば明確ではない値の不必要な設定はありません（IBM DS 4500の制御インターフェースを思い出します-それは何かでした）。 一般に、すべてが堅固な「4」です。