2

SAN のパフォーマンス、特に EMC VNX SAN について質問があります。同時に実行されている多数のブレード サーバーにまたがる多数のプロセスがあります。通常、プロセスの数は約 200 です。各プロセスは、ストレージから 2 つの小さなファイル (1 つは 3KB、もう 1 つは 30KB) をロードします。数百万 (20) のファイルを処理する必要があります。プロセスは、VMWare 上の Windows Server で実行されています。これが最初にセットアップされた方法は、VMWare の単一の 15 TB ドライブにバンドルされた SAN 上の 1 TB LUN であり、1 つの Windows インスタンスからすべてのプロセスへのネットワーク共有として共有されました。プロセスが同時に実行され、パフォーマンスは最悪です。基本的に、200 の同時要求が Windows 共有を介して同時に SAN によって処理されており、SAN はそれをうまく処理していません。パフォーマンスを向上させるための提案を探しています。

4

1 に答える 1

4

すべてのパフォーマンスに関する質問には、ある程度の「依存」があります。

SAN へのアクセスについて話している場合、解明すべき一連の潜在的なボトルネックがあります。ただし、最初に、実際の問題が何であるかを理解する必要があります。

  • スループットに問題がありますか? たとえば、持続的な転送やレイテンシーはありますか?
  • 予測キャッシュが機能しないため、処理が最も困難なワークロードの 1 つであるランダム読み取り IO を見ているようです。

だから最初から始めてください：

  • 基盤となるストレージはどのようなものを使用していますか?

    大容量の SATA を購入して RAID-6 を構成するという罠に陥っていませんか? 多くの場所でこれを行っているのを見てきました。これは、パフォーマンスの合計を実際に計算せずに、安価なテラバイトのように見えるためです。SATA ドライブは、1 秒あたり約 75 IO 操作で速度が低下し始めます。大容量のドライブ (たとえば 3 TB) を使用している場合、1 テラバイトあたり 25 IOP になります。大まかな目安として、FC/SAS の場合はドライブあたり 200、SSD の場合は 1500 です。

  • 階層化していますか？ストレージの階層化は、さまざまな速度のディスクから「サンドイッチ」を作成する巧妙なトリックです。これは通常、ファイルシステムのごく一部のみが「ホット」であるため、通常は機能します。したがって、ホット部分を高速ディスクに配置し、コールド部分を低速ディスクに配置すると、平均的なパフォーマンスが向上します。これは、ランダム IO またはコールド読み取りアクセスでは機能しません。また、ディスク全体の転送では機能しません。その 10% (または任意の割合) だけが「高速」になり、それ以外はすべて低速に移行する必要があるためです。

  • アレイレベルの競合は何ですか? SAN のポイントは、ほとんどのワークロードを反映するため、各ユーザーのピークが高く、平均が低くなるようにパフォーマンスを集約することです。(ドキュメントで作業しているときは、それを取得するためにパフォーマンスのバーストが必要ですが、再度保存するまではほとんどパフォーマンスがありません)。

  • アレイにどのようにアクセスしていますか? 通常、SAN はファイバー チャネル ネットワークを使用してアクセスされます。「実際の」ネットワークとは技術的な違いがたくさんありますが、それらは問題ではありませんが、競合と帯域幅は依然として重要です. 特に ESX では、ストレージ IO のニーズを過小評価する傾向があることがわかりました。(HBA の 1 つのペアを使用する複数の VM は、ESX サーバーで競合が発生することを意味します)。

  • どのような種類のワークロードを処理していますか? ストレージ アレイのその他の重要な利点の 1 つは、キャッシュ メカニズムです。通常、非常に大きなキャッシュと、一時的な局所性やシーケンシャルまたはセミシーケンシャル IO などのワークロード パターンを利用するための巧妙なアルゴリズムがいくつかあります。RAID-6 のひどい書き込みペナルティにもかかわらず、書き込み操作はソフトな時間制約 (キャッシュでキューに入れることができる) の下にありますが、読み取り操作はハードな時間制約 (読み取りはできません) の下にあるため、アレイの書き込み負荷の処理はより簡単です。ブロックがフェッチされるまで完了します)。これは、真のランダム読み取りの場合、基本的にまったくキャッシュできないことを意味し、最悪の場合のパフォーマンスが得られることを意味します。

  • 問題は間違いなくあなたのアレイですか？15 TB が提示された単一の VM があり、その VM が IO を処理しているようです。そこがボトルネックです。VM は ESX サーバーに対していくつの IOP を生成していますか? また、競合はどのようなものですか? ネットワーキングはどのようなものですか？同じ ESX サーバーを使用していて、競合の原因となる可能性がある他の VM はいくつありますか? パススルー LUN ですか、それとも VMDK を使用した VMFS データストアですか?

そのため、潜在的な問題が多数あり、単一のソースにロールバックするのは困難です。私がお伝えできるのは、優れた IO パフォーマンスを得るための一般的な推奨事項です。

  • 高速ディスク (高価ですが、IO が必要な場合はそれにお金を費やす必要があります)。
  • ストレージへの最短パス (回避できる可能性がある場合は、VM を中間に配置しないでください。CIFS 共有の場合は、NAS ヘッドが最適な方法である可能性があります)。
  • ワークロードをキャッシュ可能にするようにしてください。言うは易く行うは難しです。しかし、何百万ものファイルがある場合、予測可能なフェッチ パターンがあれば、配列はプリフェッチを開始し、はるかに高速になります。ファイルを大きな「チャンク」にアーカイブし始めると、パフォーマンスが向上することに気付くかもしれません (アレイ/クライアントがチャンク全体をフェッチし、次のクライアントで利用できるようになるため)。

基本的に、特に低速ディスクでの「多数の小さなランダム IO 操作」は、最適化のための巧妙なトリックが機能しないため、実際にはストレージにとって最悪のケースです。

于 2014-11-08T08:37:22.453 に答える