SAN統合後、MSSQL I / Oパフォーマンスが低下しましたか？
最近、すべてのDell EquallogicSANを同じグループに統合しました。以前は、各SANは独自のグループに属していました。これらはすべてRAID6の15kRPM SASドライブで構成されているため、ストレージを階層化する必要はありません。基本的にすべて同じであるため、新しい統合グループ。
その過程で、パフォーマンスが向上すると信じているため、iSCSIではなくVMDKストレージを使用するようにすべてのVMを変更しました。
MS SQL 2005サーバー（現時点ではメインのSQLボックス）のディスクI/Oパフォーマンスは、これらの操作を実行する前よりも一貫して悪化していると言われていますが、それがどのようになるかはわかりません。 ..そのディスク（C-OS、D-MDF、E-LDF）は、以前よりもはるかに多くの読み取りヘッドにまたがっており、VMDKストレージはiSCSIよりもパフォーマンスが高いと理解しています。
では、何が得られるのでしょうか？これは、Solarwinds Database PerformanceAnalyzerの「合計I/O待機時間」のグラフです。 
これらのEQLアレイを単一のプールに結合する際に最初に覚えておくべきことは、各ボリュームのワークロードが他のボリュームのパフォーマンスに影響を与える可能性があるということです。 SQLデータベースは、現在はより多くの物理スピンドルに存在していますが、同じスピンドルを共有している他のワークロードが原因で、より多くのリソース競合が発生している可能性があります。
頭に浮かぶ2番目の主要な要素はストレージネットワークです。メンバーが別々のプールまたはグループにある場合、iSCSIネットワークトラフィックのほとんどすべてがI/Oからホストへ/から送信されます。ただし、単一のグループとプールにメンバーがいる場合は、グループ内のトラフィック（主に、ページの移動）を考慮する必要があります。ページの移動により、メンバー間でも使用中の容量が維持され、ワークロードが比較的低いメンバーと「ホット」データのバランスが取られます。さらに詳細な情報については、 Equallogic Load Balancers に関するホワイトペーパーを確認してください。
このトラフィックの増加は、スイッチが Dellストレージ互換性マトリックス （p.19を参照）で説明されている基準を満たしていない場合、スイッチの能力を簡単に超える可能性があります。
また、VMwareおよびEquallogicの ベストプラクティス ホワイトペーパーを読んで、構成が問題の原因ではないことを確認することもできます。
いくつかの質問：
アレイのいずれかに有効な保証がありますか？もしそうなら、これは本当にあなたがサポートからインプットを得るべきものです-支援するために利用可能なたくさんのパフォーマンスに精通したリソース。
残念ながら、どのアレイにも有効な保証はありません。
SAN本社を設置してグループを監視していますか？そうでない場合は...設置して構成します（保証があり、取得できると仮定します）。これにより、多くの重要な洞察が得られます。潜在的な根本原因を理解するために必要なストレージパフォーマンスメトリック。
私はSAN HQを持っていますが、...これを特定するために私がその中で何を見るべきかについて詳しく説明していただけますか？
確認するのに最も簡単な場所は「実験的分析」です。これは、「推定最大IOPS」と比較したワークロードのグラフを提供します。これは、グループ全体および個々のメンバーについて表示できます。ハードウェアセクションで個々のスピンドルIOPSとキューの深さを確認することもできますが、これらの数値だけでスピンドルが過負荷であるかどうかを判断するのは難しい場合があります。
- 現在、同じプールにいくつのメンバー/アレイがありますか？
現在、同じプールに5つのアレイがあります
プールに3人以下のメンバーを入れて、それらを2つのプールに分割することを検討することを強くお勧めします。ボリュームは、容量を別のメンバーにリバランスしている最中でない場合にのみ3つのメンバーに分散されます（これは、スナップショットが使用中のスペースを絶えず変更するボリュームで頻繁に発生します）。物事を最大3メンバーに削減すると、メンバー間で可能な限り同等の使用容量を取得した後、ボリュームスライス全体がメンバー間で再調整されることによる多くの「チャーン」が無限の追跡で停止します。
そのすべての情報の外で...自分で物事の根底に到達できない場合は、デルでサポートチケットを支払うだけで、誰かがあなたと一緒に環境内のすべてをウォークスルーして原因を特定することを検討できます。
VMDKとブロックレベルiSCSIのパフォーマンスの違いは、ワークロードの種類によって異なり、アプリごとに大きく異なる場合があります。両方のタイプのストレージアクセスプロトコルでいくつかのアプリを実行するようなテストを実行して、その動作を確認することを強くお勧めします。 VMDKはアプリとストレージの間の追加レイヤーであるため、仮想ドライブを制御するホストの負荷が高い場合は速度が低下する可能性があります。
ディスクを共有すると、おそらく「キャッシュ時間」が短縮されます。
2つのアプリケーション「A」と「B」があると想像してください。
アプリケーション「A」には、40GiBしかない小さなデータベースがあり、1GiB /日をロードし、ほとんどのクエリは先週のデータを使用します。 20GiBのRAMディスクキャッシュ専用）サーバーでは、おそらく20日近くのデータがディスクキャッシュにあり、ほとんどの読み取りでディスクヘッドが移動することさえありません。
反対側のアプリケーション「B」は2000GiBのミディアムアーカイブで、毎日20GiBのデータをロードし、ほとんどのクエリはすべてを順番に読み取ります。これはアーカイブであり、ほとんどの場合、インデックス作成が困難なテキストクエリを実行し、アプリケーションユーザーにとってはとにかく1日以内に順次読み取りが行われます。多くのアーカイブは、より迅速な対応を必要としない聴覚者によってのみ使用されます。
同じ64GiBキャッシュを使用して、同じストレージ上のこれら2つのサーバーのディスクに参加すると、アプリケーション「A」と「B」は1日あたり21GiBのデータを移動します。その後、キャッシュは最大3日間のデータを保持します。マージの前に、アプリケーション「A」はほとんどのクエリをRAMで実行していましたが、現在、ほとんどのクエリでphisicallディスクの読み取りが必要です。マージ前は、アプリケーション「B」はディスクアクセスでアプリケーション「A」からの同時実行性がほとんどありませんでしたが、現在は多くの同時実行性があります。
アイデアはありますか？
RAM速度はランダムアクセスの場合、15kディスクよりも4kから400万倍速いため、ディスクキャッシュのセグメント化はパフォーマンスにとって非常に重要です。ディスクはデータを取得するためにヘッドを移動する必要がありますRAMはそうではありません。15kRPMディスクはお金の無駄です。ランダムアクセス用の通常のSATAドライブの約2倍の速度であり、SATAドライブの2倍以上のコストがかかります。
VMDKについて
私のサーバーは大きすぎて、過去にVMWare上の大きなVM（700GiB RAMなど））で問題が発生しました。また、深刻なパフォーマンスの問題と原因不明のクラッシュが発生しました。そのため、KVMに移行しました。 。当時、私は仮想化サーバーのマネージャーではなかったため、VMWareの何が問題だったのかはわかりません。しかし、KVMに移動して、仮想化サーバーのマネージャーになりました。これ以上の問題はありません。
物理デバイス（SCSI転送）にいくつかのVMイメージがあり、いくつかのイメージが.imgイメージファイル（固定サイズのVMDKに似ています）としてあります。インターネット上の人々は、SCSI転送ははるかに高速であると言いましたが、私の使用パターンではパフォーマンスは同じです。違いがあれば、私には見えないほど小さいです。唯一のことは、新しい仮想マシンを作成するときに、ホストオペレーティングシステムのディスクアクセスをキャッシュしないようにKVMに指示する必要があるということです。VMWareに同様のオプションがあるかどうかはわかりません。
あなたへの私の推測
1.ストレージ戦略を変更する
内部ディスクでストレージを交換します。 24個の内部SATAディスクにより、大規模なRAID 10が可能になり、ほとんどのストレージよりもはるかに安価で高速になります。また、副次的な利点があります。コストを削減するために、これらのサーバーに余剰のディスクスペースがあり、クロスバックアップおよびメンテナンスタスクで使用できます。
ただし、この余分なスペースをユーザーに公開しないでください。自分自身に保管してください。そうでなければ、バックアップを作成するのは地獄になります。
それらが設計されているもののためにストレージを使用します：
- 一元化されたバックアップ。
- どちらかが大きすぎて内部ディスクに収まらないデータベース/アーカイブ。
- 使用パターンがディスクキャッシュによって加速されず、パフォーマンスに必要なディスクヘッドの数が内部ディスクまたは専用ストレージに収まらないデータベース/アーカイブ。
そして...ディスクキャッシュの多いストレージを購入することすらしません。代わりに、ストレージを使用するサーバーのRAMを増やすことにお金をかけます。
2.可能であれば、RAMをストレージキャッシュから実際のサーバーに移動します
統合後のストレージに同じ量のキャッシュRAMがあると仮定すると、十分なRAMがある可能性があります。RAMストレージキャッシュからRAMチップに互換性がある場合、これでうまくいくかもしれません。
3.ミッションクリティカルなデータベースへのRAID6はありません
RAID 5と6は、データベースのパフォーマンスにとって最悪です。 RAID 10に移動します。RAID10は、独立して読み取ることができる各セクターの2つの独立したコピーがあるため、読み取り速度が2倍になります。
4.データベースログを専用の内部ドライブに移動します
私はpostgresを使用していますが、先行書き込みログを専用ディスクに移動すると、大きな違いが生じます。重要なのは、最新のデータベースサーバーのほとんどは、データベースデータ領域自体に情報を書き込む前に、ログに情報を書き込むということです。通常、ログは循環バッファであり、書き込みはすべてシーケンシャルです。専用の物理ディスクがある場合、ヘッドは常に書き込みの場所にあり、低回転ドライブであってもシーク時間はほとんどありません。私がインターネットで読んだように、Mysqlはまったく同じデザインを使用しています。