いつも私を困惑させているのは、ストレージのベスト プラクティスです。ファイル システムは、ペタバイトやエクサバイトのサイズに対応できることを自慢しています。しかし、1 つのボリュームを数テラバイト以上に拡張することをいとわないシステム管理者は多くありません。その主な理由は、ドライブが故障した場合にアレイを再構築するのにかかる時間の長さだということはわかっています。1 つの LUN 内のドライブの数が多いほど、この時間は長くなり、再構築中に別のドライブを失うリスクが高まります。
次に、使用上の理由があります。管理者は、プロジェクトに割り当てる必要があると思われるスペースの量に基づいて LUN を切り出します。LUN を 1 つの大きなアレイにして、クォータを使用する方が現実的に思えます。これですべての要件 (iSCSI) が満たされるわけではないことは理解していますが、多くの NAS システム (NFS) がこの方法で管理されているのを目にしています。また、基盤となるボリュームは必要に応じて簡単に拡大/縮小できることも理解していますが、ボリュームを操作してデータ損失の可能性を考慮するよりも、クォータを使用する方が「リスク」が少ないのではないでしょうか。
私が見逃している他の理由があるかもしれませんので、教えてください。ファイルシステムがこれほど大きくなることは期待できないのでしょうか? 再構築時間を短縮するために、ハードウェアが高速化するのを待っているのでしょうか?
答え1
スピンドルの分離は、1 つの大きなボリュームを持たないための十分な理由です。Exchange、SQL Server、およびその他のランダムなもの (ESXi ゲストなど) を単一の NFS デバイスから実行している場合は、スピンドルの分離が必要になります。Exchange データとロングは、SQL データベースとログと同様に、互いに別のスピンドルに配置する必要があります。
答え2
ドライブの再構築は、ファイル システムではなく、ドライブ自体に依存します。2TB ドライブを使用した場合、再構築にかなりの時間が必要になります。
再構築は RAID 5 の問題です。現在、多くのコントローラが RAID 6 をサポートしていますが、RAID 10 を作成する方がはるかに良いでしょう (最高のパフォーマンスが必要な場合)。LUN のエクスポートは SAN の仕事であり、ファイル システムのエクスポートは NAS の仕事です。
どちらにも長所と短所があります (Google で検索すると、大量の論文が見つかります)。独立した LUN (またはファイル システム) を多数作成すると、スナップショット バックアップの利点があります。
答え3
個人的には、真のエンタープライズ トラフィック (Oracle、MSSQL、Production ESX) を iSCSI または NFS 経由で実行することは絶対にありません。一般的なパフォーマンスと障害発生時の両方で FC はよく知っていて信頼しています。もちろん、これは大規模な LUN を作成して分割することはできないことを意味し、かなりの複雑さと作業が発生しますが、システムの可用性とエンド ユーザー エクスペリエンスの数値は期待していたよりも優れており、一貫性があります。
実際の回答については、あなたの投稿は非常に NetApp/ファイラー指向のようです。そのため、最後の段落を書きました。しかし、あなた自身が理由を述べています。ディスク インターフェイスはディスク容量を大幅に下回っています。つまり、再構築に非常に時間がかかる可能性があります。特に、既存のトラフィックの再構築中に適切なパフォーマンスを確認したい場合はそうです。ディスクは常に故障しており、管理者の作業を楽にするために再構築中に複数のプラットフォームのパフォーマンスに影響を与えるという考えは、確かに短命な方法でしょう。また、純粋にプラットフォーム セキュリティの観点から、システムをパーティション分割する必要がある場合があり、そのシナリオでは「大きな LUN」アプローチは機能しない可能性があります (もちろんハードウェアに基づきます)。
結局のところ、エンタープライズ SAN は本質的にビジネスまたはミッションクリティカルであり、コスト、管理の容易さ、さらには究極のパフォーマンスよりも可用性と一貫性が求められます。