Microsoft SQL Serverインストール用の物理ストレージの構成
ストレージにSAN=を使用するMicrosoft SQL Serverインストールを構成しています。SANストレージの場合：
- 少数のSSDディスク
- 多数の10Kディスク
私のSANはストレージの階層化をサポートしています。
私はSSDディスクの使用方法について垣間見ています。頭に浮かぶオプションは次のとおりです。
オプション1：SSDと10Kディスクで階層型ストレージを作成し、自動階層化を使用して、アクセス頻度の高いデータをSSDに移動します。次に、そのストレージプールをいくつかの異なるドライブに分割します。
オプション2：キー（I/O集中型）データをSSDに配置し、その他すべてを10Kディスクにスローします。
質問
すべてがSSDに常駐できるように、十分なSSDがありません。では、SSDストレージにとって最も重要なパフォーマンスは何でしょうか？ tempdbs？ LDFファイル？ MDFファイル？私のデータベースは、読み取りよりも書き込みが集中しています（違いがある場合）。
第二に、ドライブを設定する際に従うべきベストプラクティスはありますか？
tempdbごとに個別のドライブを用意する必要がありますか？ LDFファイル？ MDFファイル？
master、modelなどのシステムデータベースは、専用のドライブまたはC: ドライブ？
サーバーディスクのアクティビティ
ちなみに、これは既存のデータベースサーバーのディスクアクティビティのスクリーンショットです。 tempdbsが最も読み取り/書き込みが多いようで、次にMDFファイルが続きます。驚いたことに、LDFファイルはI/Oが最も少ないようです。
任意のアドバイスをいただければ幸いです。
まず第一に、SQL Serverのストレージに関する推奨事項については、SANベンダーのドキュメントを参照してください。これは実際にベンダーがこの一般的な分析の多くを実行してくれれば幸いです。
ドキュメントでホスティングデータベースについて言及していない場合は、階層型ストレージを選択する前に、さらに掘り下げてください。 SAN=で階層間のデータ移行がどのように行われるかを理解します。どのくらいの頻度で発生するかを確認します。時間枠（多くの場合24時間）でのアクティブセクターの状態を追跡するスケジュールされたジョブを実行するものに注意してください期間ですが、これは多くの場合設定可能です。このシナリオでは、データを移行するときになると、そのデータは操作中にアクセスが遅くなることがよくあります。このプロセスがデータベースのアクティビティが少ない（つまり、データベースをバックアップしているときにこれを実行しないでください）。1日中アクティブなデータベースがある場合、これが階層化されている場合は階層化ストレージを使用しないことをお勧めします。はSANで機能します。このタイプの分析を実行する場合に階層間でデータを移行する際のもう1つの問題は、多くの場合、データアクセスパターンが変化し、1日中一貫していないことです。これにより、データをより高速な階層に配置して、本来はすべきではないたとえば、Index Maintenance ovを実行するとernight SANは、そのデータにホットのフラグを付け、上位層に移行する場合があります。次の移行分析ウィンドウでこれらのインデックスにアクセスできない場合、アイドルデータのI/Oを浪費しています。データベースの使用パターンによっては、データがより高速の層に移行されてアイドル状態になるだけで、これが頻繁に発生する可能性があります。
もう一度、ベンダーのドキュメントを見てください。ハードウェアに必要な推奨アプローチの概要を明確に示していただければ幸いです。また、Brent Ozarの SQL ServerのSANストレージのベストプラクティス を読んでください。これは、いくつかのベストプラクティスについてより深く掘り下げており、一読の価値があります。
まあ、一般的に：
- LDFはレイテンシに敏感ですが線形です。 A SANライトバックキャッシュ（またはBBUとローカルレイドコントローラーとライトバック）は、待ち時間を処理するのに十分であり、スループットは適切なHDDで処理できます。
- Tempdbは、レイテンシとスループットに影響されます。一般的に、私はこれらをSAN=に配置しません-ゼロの意味をします。ローカルのM.2 NVMディスクを使用します。必要に応じて、PCIe Raiserカードをそれらのために取得します。ポイントはそれです。 TempDBは再起動のたびに再生成されるため、マシンがフェイルオーバーしても「失われる」ことはありません。まともなM.2 SSDには、それらの帯域幅のTONがあります（128gファイバーを使用しない限り）。データをどのように処理するかによっては、tempdbは非常に静かなライブになる場合があります。
残りの部分では、賢明な場合はストレージ階層化を使用します。または、複数のファイルグループを使用し、ホットファイルをSSDに配置します（テーブルによる場合）（パーティショニングを使用すると不格好になります）。多くはデータに依存しますが、階層化が最適なソリューションである場合もあります（使いやすさの観点からも）。
さて、私は最初に明白なことを言うでしょう。両方のシナリオをテストし、階層型SSDアーキテクチャと専用SSDアーキテクチャのパフォーマンスの違いを確認してください。
次に、SSDストレージが限られている場合に、主要なデータをSSDにすることの欠点について考えます。 SSDスペースはどのように制限されていますか？現在の「主要データ」の増加に基づいてスペースが不足すると予想されるのはいつですか。 SSDのスペースが不足した場合はどうしますか？冗長性を提供するために一部のSSDストレージを無駄にする可能性があります。すべての潜在的な頭痛をパフォーマンスの違いと比較してください。
一般に、SSDはランダムアクセス操作に適しています。ランダムリードを取得する最大のメリット。アプリケーションが書き込み集中型で大量の書き込みを大量に実行している場合（LDFに負荷があまりないため可能です）、高速回転ディスクと比較してSSDのパフォーマンスは最小限に向上する可能性がありますが、アプリケーションが多くのランダムな書き込みは、それは別の話かもしれません。したがって、本番ワークロードをテストする必要があります。