「昔は」、OS ドライブ (Windows の場合) とデータ ドライブを常に分離していました。Linux の世界では、私はあまり詳しくありませんが、ベスト プラクティス構成ではさらに多くのボリュームを定義して使用することが賢明であると認識しています。
サーバー ストレージが SAN (ディスク リソースが多数の個別のオペレーティング システムとアプリケーションによって共有される場所) 上に配置される可能性が高くなったため、OS パーティションとデータ パーティションをボリューム レベルで分離することが本当に重要になるのでしょうか。
あなたの考えは？
答え1
OS とデータをストレージ上で分離しておく主な理由は 3 つあります。
- 空間ErikAが指摘しているように、OSボリュームの容量が不足するのは絶対に避けたいものです。さまざまな問題が発生する可能性があります。この2つの拡張方法を分離する
- I/O アクセス要件OS ボリュームで使用される I/O の種類は、通常、データ ボリュームで使用される種類とは大きく異なります。I/O の種類を分けておくことは、多くの点で非常に良い考えです。
- ストレージのポータビリティサーバー OS をアップグレードするときには、OS ボリュームを削除してすべてのデータを保持できます。または、SAN または VM 環境では、データ ボリュームを新しくインストールしたサーバーに移動するだけで、アップグレードにかかる時間を節約できます。
また、一部のオペレーティング システム (Windows もその 1 つです) では、OS ボリュームのサイズ変更があまり歓迎されません。つまり、サーバーをフォーマットするときに、通常、OS ボリュームの有効期間中に必要なだけのボリュームを割り当てる必要があります。これとは対照的に、データ ボリュームはサーバーの有効期間中に何度もサイズ変更でき、頻繁にサイズ変更されます。OS とデータ ボリューム自体が同じ実際のストレージに格納されている完全に仮想化された環境でも、OS ボリュームのサイズを変更できないことは大きな障害になる可能性があります。Windows 2008+ では、現在、C:\ ドライブに 30 GB が推奨されていますが、これは Server 2003 で使用していた 10 GB とは大きく異なります。これは、2003 から 2008 への変換を行う多くの Windows 管理者にとって、問題となるでしょう。
答え2
はい、間違いなく OS とデータを分離します。共有パーティションでは、パーティションがいっぱいになって OS にパッチを適用できなくなったり、パーティションを拡張できなくなったり (さまざまな理由により) するといったことが何度も起きています。
私の意見では、2 つのパーティションを管理するオーバーヘッドは、提供される分離に対して支払うべき小さな代償です。
あなたが言及した SAN ベースのシステムに関しては、OS パーティションがデータでいっぱいになることから保護されるわけではありません。完全に仮想化されたストレージでは、OS とデータが別々のスピンドルに存在することをそれほど心配する必要はありません。
答え3
システムで何をしているかによって異なると思います。OS を再インストールする必要がある場合は、すべてのデータを別のパーティションに置くことで手間を省くことができます。それ以外の場合は、もう必要性を感じません。私の意見です。
答え4
歴史的に Linux (正確には Unix) のパーティション分割の推奨事項は、その起源が (ネットワーク化された) メインフレーム サーバー OS だったことに一部起因しており、これは (当時の) ハードウェアの相対的な信頼性の低さに影響されたのではないかと思います。たとえば、ログと一時データは、それらのストレージ領域がかなり消耗するため通常は分離されていましたが、失われてもそれほど問題にはなりませんでした。
デスクトップ システムを構築する場合は、データ/非データ/スワップの分割をお勧めします。深刻な負荷がかかることが予想されるサーバーを構築するのでない限り、/usr/local と /var/tmp を分けるようなことは、スペース割り当ての頭痛の種になります。