回答:
ログとデータドライブには、ドライブを共有するときに（少なくとも理論的には）互いに競合するさまざまなデータアクセスパターンがあります。
ログ書き込み
ログアクセスは、非常に多数の小さな順次書き込みで構成されます。やや単純化すると、DBログは、ディスク上の特定の場所にデータ項目を書き込むための命令のリストを含むリングバッファです。アクセスパターンは、完了を保証する必要がある多数の小さな順次書き込みで構成されているため、ディスクに書き込まれます。
理想的には、ログは静かな（つまり、他の何かと共有されていない）RAID-1またはRAID-10ボリュームにあるべきです。論理的に、プロセスをメインDBMSがログエントリを書き込み、ログを消費してデータディスクに変更を書き込む1つ以上のログリーダースレッドとしてプロセスを表示できます（実際には、プロセスはデータ書き込みが書き込まれるように最適化されます可能な場合はすぐに）。ログディスクに他のトラフィックがある場合、ヘッドはこれらの他のアクセスによって移動され、順次ログ書き込みはランダムログ書き込みになります。これらは非常に遅いため、ビジーなログディスクはシステム全体のボトルネックとして機能するホットスポットを作成する可能性があります。
データ書き込み
（更新）トランザクションが有効でコミットに適格であるためには、ログ書き込みをディスク（安定したメディアと呼ばれる）にコミットする必要があります。これは、書き込み中のログエントリとしてこれを論理的に表示し、非同期プロセスによってディスクにデータページを書き込むための命令として使用できます。実際には、ログエントリの作成時にディスクページの書き込みが実際に準備およびバッファリングされますが、トランザクションをコミットするためにすぐに書き込む必要はありません。バッファがレイジー・ライター・プロセスによって安定したメディア（ディスク）に書き込まれたディスク（このアウトを指し示すためのポールランダルのおかげ）がこのTechnetの記事のもう少し詳細に説明します。
これは非常にランダムなアクセスパターンであるため、同じ物理ディスクをログと共有すると、システムパフォーマンスに人為的なボトルネックが生じる可能性があります。トランザクションがコミットするには、ログエントリを書き込む必要があるため、ランダムシークによりこのプロセスの速度が低下します（ランダムI / OはシーケンシャルログI / Oよりもはるかに遅い）ため、ログはシーケンシャルからランダムアクセスデバイスに変わります。これにより、ビジーなシステムで深刻なパフォーマンスのボトルネックが発生するため、回避する必要があります。一時領域をログボリュームと共有する場合も同様です。
キャッシングの役割
SANコントローラーには大きなRAMキャッシュがある傾向があり、ランダムアクセストラフィックをある程度吸収できます。ただし、トランザクションの整合性のために、DBMSからのディスク書き込みが完了することが保証されていることが望ましいです。コントローラーがライトバックキャッシュを使用するように設定されている場合、ダーティブロックはキャッシュされ、I / O呼び出しは完了としてホストに報告されます。
これにより、物理ディスクに送信される多くのI / Oをキャッシュが吸収できるため、多くの競合の問題を解決できます。また、RAID-5のパリティの読み取りと書き込みを最適化できるため、RAID-5ボリュームのパフォーマンスへの影響が小さくなります。
これらは「SANに対処させよう」という考え方を推進する特性です。ただし、このビューにはいくつかの制限があります。
ライトバックキャッシングには、データを失う可能性のある障害モードがまだあり、コントローラーはDBMSにアクセスし、実際にはブロックがディスクに書き込まれたが実際には失われていないと言いました。このため、トランザクションアプリケーションにライトバックキャッシングを使用したくない場合があります。特に、データ整合性の問題がビジネスに深刻な影響を及ぼす可能性のあるミッションクリティカルなデータや財務データを保持するものです。
SQL Server（特に）は、呼び出しが戻る前にフラグ（FUAまたはForced Update Accessと呼ばれる）がディスクへの物理的な書き込みを強制するモードでI / Oを使用します。マイクロソフトには認定プログラムがあり、多くのSANベンダーがこれらのセマンティクスを尊重するハードウェアを製造しています（要件をここにまとめています）。この場合、ディスクの書き込みを最適化するキャッシュ量はありません。つまり、ビジーな共有ボリュームにある場合、ログトラフィックはスラッシングします。
アプリケーションが大量のディスクトラフィックを生成すると、そのワーキングセットがキャッシュをオーバーランする可能性があり、これにより書き込み競合の問題が発生します。
SANが他のアプリケーション（特に同じディスクボリューム上）と共有されている場合、他のアプリケーションからのトラフィックがログのボトルネックを生成する可能性があります。
一部のアプリケーション（データウェアハウスなど）は、SAN上で非常に反社会的なものとなる大きな一時的な負荷スパイクを生成します。
大規模なSANでも、個別のログボリュームを使用することをお勧めします。使用頻度の低いアプリケーションのレイアウトを気にせずに済ますことができます。非常に大規模なアプリケーションでは、複数のSANコントローラーの恩恵を受けることもあります。オラクルは、大規模な構成の一部に複数のコントローラーが関係する一連のデータウェアハウスレイアウトのケーススタディを公開しています。
所属する場所でパフォーマンスの責任を負う
ボリュームが大きいものやパフォーマンスが問題になる可能性のある場所では、SANチームにアプリケーションのパフォーマンスの責任を負わせます。構成に関する推奨事項を無視する場合は、管理者がこれを認識しており、システムパフォーマンスの責任が適切な場所にあることを確認してください。特に、I / O待機、ページラッチ待機、または許容可能なアプリケーションI / O SLAなどの主要なDBパフォーマンス統計に関する許容可能なガイドラインを確立します。
複数のチームにまたがるパフォーマンスの責任を負うことは、他のチームに指を向けて投資をするインセンティブを生み出すことに注意してください。これは、既知の管理アンチパターンであり、解決されずに数か月または数年にわたって引きずられる問題の公式です。理想的には、アプリケーション、データベース、およびSAN構成の変更を指定する権限を持つアーキテクトが1人いるはずです。
また、負荷のかかったシステムのベンチマークを行います。手配できれば、中古のサーバーと直接接続アレイをEbayで非常に安く購入できます。このようなボックスを1つまたは2つのディスクアレイでセットアップした場合、物理ディスク構成でフリギングし、パフォーマンスへの影響を測定できます。
例として、大規模なSAN（IBM Shark）で実行されているアプリケーションと、U320アレイを直接接続した2ソケットボックスを比較しました。この場合、ebayから購入した3,000ポンド相当のハードウェアは、ほぼ同等のCPUとメモリ構成を持つホスト上で、2倍の100万ポンドのハイエンドSANを凌perしました。
この特定の事件から、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つの独立したアレイまで）に分散され、ネットワークインターフェイスの総数（モデルに応じてEqlアレイごとに2〜4）およびIOを分散します。できるだけ多くのコントローラーにまたがって。Equallogic管理ソフトウェアは、ボリューム/アレイのパフォーマンスを経時的に監視し、メンバーアレイ全体のブロックの分散を動的に最適化します。一般に、何をしているのかわからない場合は、すべてのアレイを単一のプールに入れ、RAID 10で高速ディスク（SAS 10k \ 15k）を構成し、RAID 50で中速を構成するようにしてくださいまたは5を使用して、最適化プロセスが実際の高性能ドライブを実際に選択するようにします。
おおよその概算では、ドライブの種類とRAIDの種類に応じて、PSアレイごとに2500〜5000のIOPが得られます。十分な合計IOPを提供する場合、すべてのボリュームを単一のプールにまとめても、自動化された管理プロセスは最終的に良好なパフォーマンスを提供するはずです。
ただし、ログ、データベース、一時ストア、OSドライブなどが実際に互いに分離されていることを保証したい場合は、いくつかのことを行うことができます。まず、特定のボリュームが常にそのRAIDタイプのアレイにのみ保存されることを保証するボリュームのRAIDプリファレンスを定義できます（ボリュームが属するプールに存在する場合）。次に、特定の階層に必要なさまざまなグレードのパフォーマンスを提供するアレイのみを含む階層型ストレージプールを定義し、ボリュームを適切なプールに分散できます。このアプローチに伴う健全性の警告は、実際に全体的なパフォーマンスを向上させるために多くのアレイが必要になることです-重要なボリュームのパフォーマンスを保証するよりも重要ではないかもしれません選択。Oracle DB向けのデルのリファレンスアーキテクチャは、データ、投票ディスク、およびOCR用に2つのRAID 10アレイを持つ1つのプールと、フラッシュリカバリエリア用に単一のRAID 5アレイを持つ別のプールを使用します。
Equallogicを使用するすべての時点で、使用可能なネットワークインターフェース、ディスクスピンドル、およびコントローラーに関して、パーティションの強制に関する決定がボリュームのパフォーマンスを向上させるかどうかを自問する必要があります。それに答えられない場合は、最小数のプールを選択して詳細を処理するか、Equallogicの専門家に実際の設計を依頼してください。アレイが1つしかない場合、ボリュームの分離に関してできることは何もありません。
いい質問です！
まず、この問題に関するブレント・オザールの「Steel Cage BlogMatch」の議論をご覧ください。
当社では、ほとんどのサーバーについて、データとログを同じSANドライブに配置し、SANチームに任せて、すべてが正常に機能することを確認しています。
特に大容量サーバーの場合、これは最善の戦略ではないと考え始めています。根本的な問題は、SANチームが必要なスペースに十分な数のドライブをまとめること以上のことを実際に行っていることを確認する方法がないことです。私たちの側や何かからのSANドライブに対してIOベンチマークを実行するのではなく、「仕事をしている」（パフォーマンスとスペースを調整する）だけであると仮定します。
私の他の考えは、データとログが必要とするアクセスの種類が異なるということです。私が最近読んだ記事では、2つの異なるドライブタイプを実際に非常に異なる方法で最適化する方法について説明していました（シーケンシャル書き込みの最適化、ランダム読み取りの最適化など） ）
要するに、はい、SQL Serverデータファイル、ログファイル、およびTempDBデータとログファイル用に別々のボリュームを作成します。
Equallogicで質問にタグを付けたので、ソリューションを設計する前に、無料の 『Dellリファレンスアーキテクチャガイド：Dell™EqualLogic™PS5000シリーズストレージアレイを使用したMicrosoft®SQLServer®の導入』をお読みください。多くの場合、特定の構成に関するガイダンスは、一般的なアドバイスとは大きく異なる場合があります。
パフォーマンスに関してはBradC（+1）に同意します。一般に、優れたSANには、予想以上に多くのraw I / Oがあります。
BACKUPをライブシステムから分離することは、まだ良い考えです（明らかですが、これを見るたびに£1があれば...）
また、tempdbをログファイルから遠ざけることをお勧めします。Logs、Data、Tempに「異なるバケット」（専門用語）が必要になったときにSANの目があなたに目を向けますファンシーなパフォーマンスグラフを見せてもらいましょう！
SANの担当者が適切に設定していることをダブル/ダブルチェックするだけです。RAID 10が必要な場合は、RAID 5にはパフォーマンスの低下はないと言っていても、それを主張します（私はそうしました）。
（「ファイルベース」操作の場合、RAID 5は問題ありません。集中的な書き込みの場合、書き込みバッファーがいっぱいになるとすぐにねじ込みます！）
ここでも用語のすべての混合に注意してください。
一般的に、そして非常に基本的な：
同じスレッドで複数のボリュームを持つことができますが、このスレッドで説明した高度な最適化を行う際に覚えておくべきことです。
重要なのは、他のいくつかの人が言及したことです（忘れないでください）。データ/ログ/バックアップを別々のボリュームではなく、異なるドライブスピンドルに分離します。
編集：上記のHelvickは、Equallogic SANについて-素晴らしい答えをくれました！