理解しておく必要があるのは、SAN とは何かということです。
SAN は、ファイバー チャネル ネットワークを介して相互接続された 1 つまたは複数のストレージ アレイです。ホストには、そのネットワークと通信するためのホスト バス アダプタ (HBA) と呼ばれる特別なネットワーク カードがあります。ネットワーク プロトコルはストレージ トラフィック用に調整されているため、高性能で低遅延のトラフィックに適しています。
あなたが話しているアレイは...そうですね、その能力は大きく異なります。EMC SAN でさえ、ストレージ アレイとしてのさまざまな EMC 製品である可能性があります。その主な目的は、ストレージ パフォーマンスを統合することです。
各サーバーにそれぞれ 10 個のスピンドルがある場合よりも、10 個のサーバーで 100 個のスピンドルを共有すると、より優れたピーク パフォーマンスが得られます。つまり、ストレージ アレイが基本的に行っているのは、100 個のスピンドルのチャンクを論理ユニットに分割し、それらをホストに戻して、各ホストの平均パフォーマンスがほぼ同じになるようにすることですが、ピーク時のサイズは 10 倍になります。(または、より現実的に言えば、50 スピンドルを使用することもできます。これは、ピークの 5 倍のコストが得られるため、平均が低くなる代わりにコストが半分になるためです)。
現在 - ファイル グループ。私が理解しているように（大量のSQLを知っているのではなく、ストレージエンジニアであること）。ファイル グループを使用すると、特に基盤となるストレージへのデータの配置を管理できます。
これはちょっとくすぐったいポイントです - それは依存するからです。通常、ストレージ アレイは、データの配置とスループットを合理化するために、独自の非常に巧妙な処理を行っています。非常に積極的なキャッシングのようなもの - 通常のホストで取得するよりもはるかに多く - つまり、多くのランダム アクセス ワークロードが「ディスク速度」ではなく「RAM 速度」になります。通常よりも多くのスピンドルにストライピングされている可能性があります。
私が知る限り、これは基本的にファイルグループが達成しようとしているものです-手動でファイルをディスクに配置し、SQLにそれらのディスクへの並列IOを処理させます。ストレージ アレイは既にこれを行っており、せいぜい管理者にとって不必要な頭痛の種になり、最悪の場合、実際にはアレイ側の最適化が悪化します。
さまざまなコンテンツ タイプを分離したい場合もありますが、SAN から割り当てられた別の LUN を介して分離することをお勧めします。これにより、あるデータベースから別のフィルを作成してスペースを使い果たすことができなくなりますが、スナップショットやクローンを作成する際の柔軟性も多少向上します。
私が提案すること：
- データベースの予想される IO プロファイルについて、ストレージ担当者に相談してください。(IO は SAN で高価なものであり、通常、データベースは「通常の」アプリケーションよりも多く使用します)
- 各インスタンスを異なる LUN セットに配置し、DB とログと tempdb を分離します。
- VMware 内では、同じデータストアに「論理」ディスクが存在する場合があります。パフォーマンスが重要な場合は、SAN LUN を介してホストに直接渡すことをお勧めします。
そして、過度に心配する必要はありません。特定の問題に気付いた場合は、状況を改善するために個々の LUN を再調整/移動できるはずです。