SQLファイルをSANに配置する

Question

最近私は、ネットワークとシステムのチームと、さまざまなSAN LUNにSQLファイルを置くことについて話し合いました。彼らは、SANのEMC管理プロセスのために、SQLファイル（データ/ログ/ロブ/インデックス/バックアップ、特にTログ）を異なるスピンドルの別々のドライブに配置する時間と労力を無駄にしていると考えました。ですから、このディスカッションについてのあなたのアイデアやビジョンを参加させて説明してください。

Answer 1

これについては、SAN管理者に同意する傾向があります。現在、ほとんどのSANはRAID-10またはそれに類するテクノロジを実行しており、多くのドライブにまたがって非常に高いIOPSを処理しています。 SQL Serverのデータとログのスピンドルを物理的に分離することは、ドライブの数が少なく、IOPSの機能が低いローカルストレージの時代にまで戻ります。

Answer 2

そう - その場合にのみ、目的をスケーリングするために、別々のLUNであなたのSQLデータを置く間違いなく価値があります。間違いなくLUNを複数のファイルシステムに分割しないでください。私はそれを破壊の道に見ました。

異なる物理スピンドルに異なるボリュームを配置する - これは多くの要因によって異なります。

OLTPまたはOLAP（トランザクションまたは分析）とは何ですか？ ストレージアレイとは何ですか？それは従来のRAID（LUNはRAIDグループにありますか）または仮想化されたプロビジョニング（「エクステント」プール上のLUN、raidgroupのエクステント（例VNX、VMAX、Unity））ですか？ シンプロビジョニングを使用していますか？ どのように規模を拡大しようとしていますか？

現在のストレージデバイスにどの程度の負荷をかけているのかを測定します。主なものは、IOPSだけでなくIOブロックサイズも測定します。 IOPSだけでは意味がないので、ボリュームの配置を決定するためにIO操作のサイズを知りたいとします。伝統的または仮想化されたテクノロジーをどのように使用しているかを判断します。究極のパフォーマンス指標としてレイテンシを使用します。

これは、あなたのストレージスタッフとの会話を開始するはずです。