CD 上の Linux および FreeBSD ディストリビューションを知っている私は、、、など/usrの各ディレクトリに独自のパーティションを割り当てるように育ちました。神聖なルールの 1 つは、それがいっぱいにならないように保護する必要があるということでした。/var/opt/
/tmp最近、または が/varルート パーティション上にあるシステムや、/optまたはの下など、使用可能な領域全体を 1 つのアプリケーションが占有しているためにシステムが失敗するシステムを頻繁に見かけます/tmp。
では、なぜ多くの管理者は、より洗練されたパーティション分割アプローチではなく、1 つのパーティションだけを使用するのでしょうか。過去 10 年間で何かを見逃したのでしょうか。
答え1
多くの環境では、シンプルなパーティション分割がデフォルトになっています。多くのクラウドで人気の OS イメージ、インストーラーのデフォルトのパーティション スキームにより、1 つのディスクを見つけるための自動化が簡素化されます。問題なく動作し、ディスクはオンラインで非常に大きなサイズに拡張できることが多く、cloud-init によってファイル システムが拡張されます。
面倒なことになるまで。時々、/ が完全にいっぱいになったためにインスタンスが失敗するという問題が Server Fault に持ち込まれます。ログ ファイルの消去などの通常の処理の後、/ のサイズを縮小して再発を防ぐ方法を知りたいと思うことになります。難しいのは、再パーティション化は実際にはオンラインでは実行できないこと、ファイル システムを縮小するには必ずアンマウントしてレスキュー環境を起動する必要があること、そして Linux XFS は縮小できないことです。
私の理想的な Linux ストレージ設定は、ブートと OS 用の小さなディスクと、アプリケーション ストレージ用の別のディスクです。すべて LVM で、将来のニーズに備えて VG に空き領域を残します。たとえば、データベース サーバーでは、/dev/sda1 からブートしますが、/var/lib/pgsql/ のデータは PV /dev/sdb 上の別の VG に保存されます。このようなスキームにより、データと OS を個別に復元でき、新しい VM インスタンスを作成しながら同じデータ ボリュームを移動するなどの巧妙なトリックが可能になります。状態があまりなく、したがってストレージ要件が単純な単純なアプリケーション インスタンスにはおそらく複雑すぎるでしょう。しかし、それでも可能です。
答え2
私もあなたが言及した傾向に気づきましたが、回答は主観的なものになります。
以前は物理ディスクを備えた物理マシンを使用していましたが、変更を加えるのは難しく、ダウンタイムが必要でした。現在では、論理ボリューム マネージャーと仮想マシンのおかげで、ディスクを拡張するのは非常に簡単です。
- サーバー システムで使用されるすべてのファイル システムはライブ拡張をサポートしています。
- RAID 構成は接続されたシステムに対して透過的であり、ストレージ上に配置されます。
- 仮想マシンには、簡単に拡張できる仮想ディスクがあります。
- ストレージ システムに接続された物理サーバーでは、基本的に仮想ディスクが提供されます。
そのため、多くの管理者は、よりシンプルな（または単純化された）セットアップ、つまり単一パーティション システム（または 2 つのパーティション、データのみが分離されている）を選択し、空き容量が少ないことを通知する監視ツールに依存しています。空き容量は簡単に拡張できます。
答え3
理由の 1 つは、パーティションを再フォーマットしなくても OS バージョンを簡単にアップグレードできるようになったことです。
私は今でも /home 専用のパーティションを作成していますが、おそらくもう特別な理由はないでしょう。
答え4
「シンプルに保つ」というのは、かなり一般的な設計原則です。今日の VM は、数年前の物理サーバーとは異なり、簡単に拡張できます。