ISCSI上のSQL Serverディスク設計SAN
ログファイルとデータファイルを分離してOSからディスクを分離する標準的な方法（tempdb、バックアップ、スワップファイルも）このロジックは、ドライブがすべてSANベースでLUNS特定のディスクまたはRAIDセットが切り分けられていない-これらは、SAN上のx台のドライブの一部であり、LUNは単なるスペース割り当てです。
ログとデータドライブには異なるドライブアクセスパターンがあり、ドライブを共有している場合は（少なくとも理論上は）互いに競合しています。
ログ書き込み
ログアクセスは、非常に多数の小さな順次書き込みで構成されます。やや単純化すると、DBログは、ディスク上の特定の場所にデータ項目を書き出すための命令のリストを含むリングバッファーです。アクセスパターンは、完了が保証されている必要がある多数の小さな順次書き込みで構成されているため、ディスクに書き込まれます。
理想的には、ログは静かな（つまり、他のものと共有されていない）RAID-1またはRAID-10ボリューム上にある必要があります。論理的には、プロセスをメインDBMSがログエントリを書き出す1つ以上のログリーダースレッドとしてログを消費し、変更をデータディスクに書き出すと見ることができます（実際には、プロセスはデータ書き込みが書き込まれるように最適化されています）可能な場合はすぐに出てください）。ログディスクに他のトラフィックがある場合、ヘッドはこれらの他のアクセスによって移動され、順次ログ書き込みはランダムログ書き込みになります。これらははるかに遅いため、ビジー状態のログディスクは、システム全体のボトルネックとして機能するホットスポットを作成する可能性があります。
データ書き込み
（更新）トランザクションが有効でコミットできるようにするには、ログ書き込みをディスク（ステーブルメディアと呼ばれる）にコミットする必要があります。論理的には、これが書き込まれているログエントリとして論理的に表示され、非同期プロセスによってデータページをディスクに書き込むための指示として使用されます。実際には、ディスクページの書き込みはログエントリの作成時に実際に準備およびバッファリングされますが、トランザクションをコミットするためにすぐに書き込む必要はありません。ディスクバッファーは、レイジーライタープロセスによって安定したメディア（ディスク）に書き出されます（これを指摘してくれたPaul Randalに感謝します） このTechnet記事 でもう少し詳しく説明しています。
これは非常にランダムなアクセスパターンであるため、同じ物理ディスクをログと共有すると、システムパフォーマンスに人為的なボトルネックが生じる可能性があります。トランザクションをコミットするにはログエントリを書き込む必要があるため、ランダムシークを行うと、このプロセスの速度が低下します（ランダムI/OはmuchシーケンシャルログI/Oよりも遅い）は、ログをシーケンシャルからランダムアクセスデバイスに変換します。これは、ビジーなシステムで深刻なパフォーマンスのボトルネックを作成するため、回避する必要があります。ログボリュームと一時領域を共有する場合も同様です。
キャッシングの役割
SANコントローラーは大きなRAMキャッシュを持つ傾向があり、ランダムアクセストラフィックをある程度吸収できます。ただし、トランザクションの整合性を確保するには、DBMSからのディスク書き込みが完了することが保証されていることが望まれます。コントローラーがライトバックキャッシュを使用するように設定されている場合、ダーティブロックがキャッシュされ、I/O呼び出しが完了したことがホストに報告されます。
これにより、キャッシュが物理ディスクに送信される大量のI/Oを吸収できるため、多くの競合問題が解消されます。また、RAID-5のパリティの読み取りと書き込みを最適化できるため、RAID-5ボリュームのパフォーマンスへの影響が少なくなります。
これらは、「SANに対処する」という考え方を推進する特性ですが、このビューにはいくつかの制限があります。
ライトバックキャッシュにはまだデータが失われる可能性のある障害モードがあり、コントローラーはDBMSにアクセスして、ブロックが実際にはディスクに書き込まれていないと言っています。このため、トランザクションアプリケーション、特にデータの整合性の問題がビジネスに深刻な影響を与える可能性があるミッションクリティカルなデータや財務データを保持するものには、ライトバックキャッシングを使用したくない場合があります。
SQL Server（特に）は、呼び出しが戻る前に、フラグ（FUAまたは強制更新アクセスと呼ばれる）がディスクへの物理書き込みを強制するモードでI/Oを使用します。 Microsoftには 認証プログラム があり、多くのSANベンダーがこれらのセマンティクスを尊重するハードウェアを製造しています（要件の要約 こちら ）。この場合、キャッシュの量はディスクの書き込みを最適化しません。つまり、ログトラフィックは次の場合にスラッシュします使用中の共有ボリューム上にあります。
アプリケーションが大量のディスクトラフィックを生成する場合、そのワーキングセットがキャッシュをオーバーランする可能性があり、これも書き込み競合の問題の原因になります。
SANが他のアプリケーション（特に同じディスクボリューム上）と共有されている場合、他のアプリケーションからのトラフィックがログのボトルネックを生成する可能性があります。
一部のアプリケーション（データウェアハウスなど）は、大きな一時的な負荷スパイクを生成し、SANでそれらを非常に反社会的なものにします。
大規模なSANでも、個別のログボリュームを使用することをお勧めします。使用頻度の少ないアプリケーションのレイアウトを気にしないで済むかもしれません。非常に大規模なアプリケーションでは、複数のSANコントローラーを利用することもできます。オラクルは一連のデータウェアハウスレイアウトケーススタディを公開しています。
それが属するパフォーマンスに責任を負う
ボリュームが大きい場合やパフォーマンスが問題になる可能性がある場合は、SANチームにアプリケーションのパフォーマンスの責任を持たせます。構成に関する推奨事項を無視する場合は、管理者がこれを認識しており、システムパフォーマンスの責任が適切な場所にあることを確認してください。特に、I/O待機、ページラッチ待機、または許容可能なアプリケーションI/O SLAなど、主要なDBパフォーマンス統計の許容可能なガイドラインを確立します。
複数のチームにまたがるパフォーマンスの責任を負うことは、指先を指名し、その代金を他のチームに渡すインセンティブを生み出すことに注意してください。これは、既知の管理アンチパターンであり、解決されずに数か月または数年続く問題の公式です。理想的には、アプリケーション、データベース、およびSAN構成の変更を指定する権限を持つ単一の設計者が存在する必要があります。
また、負荷がかかった状態でシステムをベンチマークします。あなたがそれを手配することができるなら、中古サーバーと直接接続アレイはEbayでかなり安く購入することができます。このようなボックスを1つまたは2つのディスクアレイでセットアップする場合、物理ディスク構成を操作して、パフォーマンスへの影響を測定できます。
例として、大きなSAN（IBM Shark）で実行されているアプリケーションと、直接接続U320アレイを備えた2ソケットボックスとの比較を行いました。この場合、ebayから購入した3,000ポンド相当のハードウェアは、ほぼ同等のCPUおよびメモリ構成のホストで、100万ポンドのハイエンドSANよりも2倍優れています。
この特定の事件から、このようなものを横に置くことは、SAN管理者を正直に保つための非常に良い方法であると主張されるかもしれません。
Equallogicタグとリクエストのコンテンツが、Equallogic SANについて悩んでいることを意味していると思います。以下は特にEquallogicに関するものであり、他のSAN=タイプには適用されません。
Equallogicアレイでは、ボリュームに使用される特定のディスクを、たとえばEMC Clariionアレイの場合ほど正確に指定することはできないため、アプローチは少し異なる必要があります。
Equallogicアーキテクチャは非常に自動化され、動的です。その基本的なビルディングブロックは、他のSANで見られるようなアレイ内のRAIDパック\グループではなく、アレイユニットです。各アレイは完全にRAID 5、6、10、または50用に構成されていますが、これはアレイごとにRAIDグループが1つしかないことを意味するものではなく、そのレベルでそれらを決定または操作することはできません。アレイをストレージプールに入れ、プールはストレージグループに属します。ストレージグループには、そのグループ内のすべてのボリュームのiSCSI検出ターゲットとして使用するcluster\virtual ip-addressがあります。EQLグループ管理ソフトウェアとホストMPIOスタックは、実際に最も適切なポートにルーティングするために必要なIPレベルの再制限を処理しますデータのブロックを要求するときの個々の配列ですが、これは制御する能力がほとんどないかまったくありません。
ストレージボリュームは、各プールの合計空き容量から割り当てられます。プール内のすべてのボリュームは、ネットワークを分散するために、そのプール内のすべてのアレイ（最大4つの個別のアレイまで）に分散されますIOネットワークインターフェイスの総数（2-4 Eql配列ごとに、モデルに応じて）およびIO可能な限り多くのコントローラにわたって。Equallogic管理ソフトウェアは、ボリューム\アレイのパフォーマンスを経時的に監視し、メンバー配列全体のブロックの分散を動的に最適化します。一般的に何をしているのかが分からない場合は、すべてのアレイを1つのプールに入れて、それを実行させ、高速ディスク（SAS 10k\15k）をRAID 10で構成し、中速をRAID 50または5で構成するようにしてください。最適化プロセスが実際に実際の高性能ドライブを選択することを保証するため。実際に最適な状態になるまでに数日（7日以上）かかる場合がありますが、一般に、ボリュームをすぐに分散するので、バランスの取れた分散に非常に速く到達するはずです。可能な限り多くのアレイを超えて（ここでもt o 4）それらが最初に作成されたとき。
おおよその概算では、ドライブの種類とRAIDの種類に応じて、PSアレイごとに2500〜5000 IOPの範囲になります。十分な合計IOPを提供すると、すべてのボリュームを単一のプールに単純にまとめたとしても、自動化された管理プロセスにより、最終的には良好なパフォーマンスが得られます。
ただし、ログ、データベース、一時ストア、OSドライブなどが実際に互いに分離されていることを保証したい場合は、いくつかのことができます。最初に、特定のボリュームが常にそのRAIDタイプのアレイにのみ保存されることを保証するボリュームのRAID設定を定義できます（ボリュームが属するプールに存在する場合）。次に、特定の階層に必要なさまざまなグレードのパフォーマンスを提供するアレイのみを含む階層化ストレージプールを定義し、ボリュームを適切なプールに分散できます。このアプローチに付随する正常性の警告は、実際に全体的なパフォーマンスを向上させるには、通常、多くのアレイが必要になるということです。これは、重要なボリュームでのパフォーマンスを保証するよりも重要ではないかもしれませんが、それでも多くの場合、依然として最良です。選択。デルのOracle DBのリファレンスアーキテクチャは、データ、投票ディスク、OCR用に2つのRAID 10アレイを備えた1つのプールと、フラッシュリカバリ領域用に1つのRAID 5アレイを備えた別のプールを使用します。
Equallogicのすべての時点で、強制パーティショニングに関して行う決定が、使用可能なネットワークインターフェイス、ディスクスピンドル、およびコントローラーの観点から、ボリュームの全体的なパフォーマンスを向上させるかどうかを自問する必要があります。これに答えられない場合は、最小数のプールを選択して、詳細を処理するか、Equallogicスペシャリストに実際の設計を依頼してください。アレイが1つしかない場合、ボリュームの分離に関して実行できることは何もありません。
私たちは、DBを単一のSAN=ボックスに保存しますが、別々のデータ、ログ、およびバックアップLUNを使用し、それぞれが異なるディスクグループにあり、速度によって階層化されています-RAID 10 15Krpm LUNにログがあり、RAID 1 10/15krpm LUNとRAID 5 7.2krpm LUNへのバックアップまた、同じSAN上の異なるコントローラーを介してログとデータを提供します。
すばらしい質問です。
最初に、この問題に関するBrent Ozarの "Steel Cage BlogMatch" の議論を見てください。
弊社では、ほとんどのサーバーについて、データとログを同じSANドライブに配置し、SANチームに任せて、すべてが正しく機能することを確認しています。
これは、特に大容量サーバーの場合、これが最良の戦略ではないと考え始めています。根本的な問題は、SANチームが実際に必要なスペースのために十分なドライブをまとめること以外に何もしていないことを確認する方法がないということです。 IOベンチマークをSANドライブに対して私たちの側から実行したり、何かを実行したりするのではなく、単に「仕事をしている」と想定します（パフォーマンスだけでなくスペースも調整しています） ）、おそらく少し素朴です。
私の他の考えは、データとログで必要なアクセスの種類が異なるということです。私が最近読んだ記事で、2つの異なるドライブタイプを実際に非常に異なる方法で最適化する方法について話していました（1つはシーケンシャルライトの最適化が必要で、もう1つはランダムリードの最適化が必要であると思います） 。）
つまり、SQL Serverデータファイル、ログファイル、およびTempDBデータとログファイル用に個別のボリュームを作成します。
質問にEquallogicでタグ付けしたので、ソリューションを設計する前に、無料の Dellリファレンスアーキテクチャガイド：Microsoft®SQLServer®とDell™EqualLogic™PS5000シリーズストレージアレイの導入 （登録が必要です）をお読みください。多くの場合、特定の構成に関するガイダンスは、一般的なアドバイスとは大幅に異なる場合があります。
パフォーマンスに関しては、BradC（+1）に同意します。一般に、優れたSANは、使用することが予想されるよりも多くのraw I/Oを持っています。
バックアップをライブシステムから分離することは依然として良い考えです（もちろん、私は知っていますが、これを見るたびに1ポンドあれば...）
また、tempdbをログファイルから遠ざけることをお勧めします。 SAN Logs、Data、Tempの「異なるバケット」（専門用語）が欲しがるようになり始めたとき、あなたに目を向ける人のテントですが、それらを伝えると、異なるものを測定できますデータの量IO各エリアに行き、それらにあなたのファンシーなパフォーマンスグラフを見せてもらいます！
SAN=男があなたのためにそれを正しく設定していることをダブル/ダブルチェックします。RAID10が必要な場合は、RAID 5にパフォーマンスがないと言い続けても、それを主張します（私はしました）。ペナルティ。
（「ファイルベース」操作の場合、RAID 5は問題ありません。集中的な書き込みの場合、書き込みバッファがいっぱいになるとすぐに、ねじ込まれます！）
ここでもすべての用語の混合に注意してください。
一般的に、そして非常に基本的な：
- アレイ= RAID設定（RAID5など）のディスクのプール
- ボリューム= SAN LUNでホストに提示されるアレイの一部
同じアレイ上に複数のボリュームを含めることができますが、このスレッドで説明されている高度な最適化を実行しているときは、覚えておく必要があります。
重要なのは、他のいくつかの人が言及していることです（忘れないでください）。データ/ログ/バックアップを、別々のボリュームだけでなく、異なるドライブスピンドルに分離します。
編集：上記のHelvickは、Equallogic SANについて-すばらしい回答を提供しました！