仮想化では、複数のマウントポイントを使用することは依然として意味がありますか？

2013年、新しいLinuxイメージに複数のマウントポイントを配置するのは理にかなっていますか？

マウントポイントのサイズを大きくするために必要な再起動を避けたいと思います。また、単一のマウントのスペースを監視することを好みます。サーバー全体のドライブ使用量が70％を超えており、個々のマウントポイントを処理していることを知りたいです。

確かに便利です。暴走プロセスによってログがいっぱいになり、/でディスクがいっぱいになるのは望ましくありません。また、LVMのようなものを使用している場合は、ボリュームのオンライン拡張を行うことができます。

多くのVMでは、とにかくIOを分離する必要があります。おそらく、データベースを別々のスピンドルに配置する必要があり、それを実現する唯一の方法は、データベースの場所に個別のマウントポイントを設定することです。データベースを別にすれば、元の設計よりも大きくなった場合、将来的にはよりきめ細かい柔軟性が得られます。

したがって、要するに、はい、2013年にこれを行う理由はまだあります。

最近では、あまり多くの個別のマウントを使用しませんが、おそらくいくつかの重要なマウントがシステム管理に役立ちます。

わずか2または3、特に。サイズが異なるものを使用します。これは、使用しているものによって異なります。/（比較的安定している）と/ var（変化している）とだけ言います。OSとディスクジオメトリによっては、/ bootも必要になる場合があります。/ tmpは、インストーラーによってセットアップされたtmpfsマウントである可能性があります。

変化するボリューム（大部分は/ varですが、/ var / logや/ var / lib / mysqlなどだけでも構いません）は、通常、心配して拡張を計画する必要があるものです。そのため、可能であれば、lvmなどを使用してサイズ変更を簡単にします。

はい、監視、セキュリティ、およびメンテナンスの要件のために、仮想マシンとマウントポイントで複数のパーティションを使用しています。

私は、単一または限定的なマウントポイント仮想マシンのファンではありません（使い捨てのマシンでない限り）。VMは物理サーバーと同じように扱います。Linux Filesystem Hierarchy Standardの一部とパーティションを一致させることは、実行可能ファイル、データパーティション、一時ストレージ、およびログストレージの論理的な分離という点で依然として意味があります。これにより、システムの修復も容易になります。これは、テンプレートから派生した仮想マシンおよびサーバーで特に当てはまります。

（ちなみに、仮想マシン上のLVMも好きではありません... より良く計画してください!!）

私のシステムでは、次のことをしようとしています。

• / 通常は小さく、あまり成長しません。
• /boot サイズは予測可能であり、成長はカーネル更新の頻度によって制御されます。
• /tmpアプリケーションと環境に依存しますが、適切なサイズにすることができます。個別に監視すると、異常な動作を測定し、システムの残りの部分を保護するのに役立ちます。
• /usr 予測可能、実行可能ファイルなどを含む必要があります
• /var増加しますが、データチャーンの量は少なくなります。個別に測定できるのは嬉しいことです。
• 成長パーティション。この場合、それ/dataはですが、これがデータベースシステムである場合、/var/lib/mysqlまたは/var/lib/pgsql... である可能性があります/dev/sdb。異なるブロックデバイスであることに注意してください。これは単にこの仮想マシン上の別のVMDKであるため、実際のOSパーティションを含むVMDKとは独立してサイズ変更できます。

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              12G  2.5G  8.8G  23% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             291M  131M  145M  48% /boot
/dev/sda7             2.0G   68M  1.9G   4% /tmp
/dev/sda3             9.9G  3.5G  5.9G  38% /usr
/dev/sda6             6.0G  892M  4.8G  16% /var
/dev/sdb1             360G  271G   90G  76% /data

これらのパーティションのいくつかを分離すると、傾向を特定し、異常な動作を検出するのがはるかに簡単になります。たとえば、4GBのコアダンプ、/var枯渇するプロセス/tmp、

正常

異常な。突然の上昇は/var、1つの大きな/パーティションが使用されているかどうかを簡単に検出できなかったでしょう。

最近、セキュリティが強化されたVMテンプレートに、ファイルシステムのマウントパラメーターと属性（nodev、nosuid、noexec、noatime、nobarrier）のカクテルを適用する必要がありました。一部のパーティションには、グローバルに適用できない特定の設定が必要だったため、パーティション化はこのための絶対的な要件でした。別のデータポイント。

確かに、複数のマウントポイントには、仮想サーバーであろうとなかろうと、利点があります。

しかし、仮想化では、おそらく仮想マシンテンプレートも使用しますか？また、Nagios（with NConf？）などの監視システムもテンプレートをサポートしていますか？もしそうなら、このメンタルマウントポイントの戦いを一度だけ行う必要があります。

トピックに戻る。

：私は私のシステムをこのように分割するために使用/、/home、/usr、/var、/tmp（そしておそらくデータのためのいくつかの他のマウントポイント）、それはやり過ぎだったと面倒。最近では/、おそらくを単独で使用した単純なOSイメージが/var私に適した方法です。次に、仮想サーバーがデータ用により多くのストレージを必要とする場合、さらに別のディスクイメージを提供し、必要な場所にマウントします。

ファイルサーバーの場合、/homeボリュームを独自のパーティション/ディスクにマウントし、マウントするnoexecときにオプションを使用する傾向があります。パラノイア。ただし、ユーザーがホームフォルダー内からファイルを実行できないようにします。

同様に、私は/bootボリュームをすべてのドライブにまたがるRAID 1ミラーに配置する傾向がありますが、繰り返しますが、私が従う古い慣習では、まだマイナス面は見られません