SAN：オペレーティングシステムと仮想マシンのデータ用に別々のLUNを用意する方が良いですか？
仮想マシンのバッキングストアとして使用されるiSCSI SANがあります。Xenを使用し、VMのブロックデバイスとしてLUNを直接提示します（したがって、ファイルを含むファイルシステムはありません） VMwareがVMFSデータストアを使用する場合と同様に、VMごとに）。
オペレーティングシステムと各VMのデータ用に別々のLUNをプロビジョニングする方がよいかどうか疑問に思っています（たとえば、Linuxをインストールするための小さなlunとメールボックスを保持するための大きなlun、Linux用に1つ、Webサーバーデータ用に1つ、など...）またはVMごとに1つの大きなLUN。
前者を見ると、「スワップパーティション用にもう1つのLUNを使用しないのはなぜですか」と尋ねることができ、各LUNに「パーティション」が1つだけになるまで続けます。
これらのLUNはすべてSANのまったく同じRAIDボリュームからのものであるため、ディスク速度やRAIDレベルを区別する意味がないことに注意してください。
現時点では、RAIDレベルやディスク速度を変える予定はないかもしれません。しかし、将来的には、メールボックスが複数TBに増えたり、大きなビデオファイルのアーカイブを開始したりする場合、または何を持っているのか、必要になる場合があります。
SANの側面を無視すると、これは、パーティションを備えた1台のハードドライブ（単一のパーティション化されたLUN）、または2台の個別のハードドライブ（2台のLUN）を持っているのと同じです。
SANの場合、ディスクを個別のLUNとして提供するのにほとんど費用がかからないので、それらを個別にします。データをOSから独立させておくと、次のような楽しいことができます。
- RAID /ディスク速度/キャッシュレベルを分離する-現在、一部の大容量ディスクは低速のRPMモデルでしか提供されていないため、大容量のストレージが必要な場合は分割する必要があります
- 必要に応じて、複数のSAN間でデータをより簡単に分割できます
- 新しい仮想マシンにインストールし、準備ができたらデータLUNを新しいサーバーに再マッピングするだけで、OSをアップグレード/修復します。長いコピープロセスはなく、ダウンタイムもほとんどありません。
- おそらくより高速なSANスナップショットを使用する場合
欠点：
- 管理オーバーヘッド、VMごとに複数のLUNを管理する必要がある
- 一部のSANには、非常に多くのLUNのライセンスしかないため、ライセンスが低いSANで不足する可能性があります。