Linuxサーバー用にいくつのパーティションを作成する必要がありますか？

Linuxサーバーでは、パーティションは非常に重要です。たとえば、大きなハードドライブにアップグレードする場合など、柔軟性が高いためです。

しかし、Linuxボックスを構築する場合、いくつのパーティションを作成する必要がありますか？各パーティションにどのサイズを設定する必要がありますか？

最後になりましたが、別のディスク（/ home、おそらく高速ドライブの/ varなど）にどのパーティションを配置する必要があり、同じドライブでどのパーティションを共有できますか？

適切なパーティション構造を計画することは、「サーバー」をどのように使用するかを実際に知ることに大きく依存します。提供される実際のサービスを使用しないランダムなアドバイスは、特に有用ではありません。

たとえば、mysqlに使用されるdebianベースのボックスの場合、/、/ var、および/ var / lib / mysqlに個別のパーティションが必要になる場合があります。

多くの共有ストレージを備えたファイルサーバーになるのでしょうか？/、/ home、および/ srvパーティションが必要になる場合があります。

squidのみを実行するボックスの場合、/のパーティションと、squidスプール用の高速ディスク上の1つのパーティションが必要になる場合があります。

パーティションを計画しているとき、Filesystem Hierarchy Standardをよく理解し、選択したディストリビューションが標準から逸脱しているかどうか/どのように逸脱しているかが非常に役立ちます。

LVMを使用すると、再起動することなく、将来の気分の変更やパーティションの調整がはるかに簡単になります。また、スナップショットを作成する機能により、適切なバックアップを簡単に作成できます。

私は常にこれらのパーティションを作成し、昨年の時点では常にLVM上で作成しています。

/       - a few Gig
/usr    - 24 Gig and mostly empty
/var    - 4 Gig works for me, YMMV
/home   - depends on how many users you will have

最も重要なことの1つは、/varこれが別のパーティションである場合、それがいっぱいになったときに、ルートパーティションをクラッシュさせないことです。私はこれをやったことがありません/usrが、読み取り専用でマウントできるように別のものを作成します。

私は時々これらのパーティションを作成します：

/boot   - even 1 Gig is way more than enough

その理由は、RAIDまたはLVMパーティションから起動できるとは限らないということです。したがって、/boot単純なext3パーティションで、/より高度なものにすることができます。

多数の大きなファイルがある場合は、これらの大きなファイル用に特定のパーティションを作成して、ファイルシステムを調整して大きなファイルを効率的に保存できるようにすることがあります。一部の人々は、サーバーからNFSを提供する場合、NFS共有用に個別のパーティションを作成するか、NFS共有ごとに個別のパーティションを作成します。これはあなたのニーズに依存します。

なぜLVMなのか？他の回答で述べたように、ここで言及するのを忘れたので、後で気が変わってパーティションを拡張するのが簡単になります。これは私の尻をすでに保存しました。

これらは一般的なガイドラインです。もちろん、サーバーに特別なニーズがある場合は、それを考慮して、これらのニーズを反映したパーティションを作成することを期待しています。

しばらく続くマシンを構築していて、再構築するのが不便で、かなり柔軟である必要があると仮定すると、次のようなスキームを好むかもしれません。

1. 同じサイズの少なくとも2つの物理ドライブをインストールします。この例では、500GB SATAドライブを想定していますが、他のサイズのドライブでも原理はうまく機能します。

2. 次のように各ドライブをパーティション分割します。

   /dev/sda1   500MB
   /dev/sda2   100GB
   /dev/sda3   the rest
   

   目標は、前もって500MBの小さなパーティション、OSとアプリケーション用の中央にかなり大きなパーティション、追加データ用のドライブの大部分を後部に配置することです。

3. 、SW RAID 1セットを構築し/dev/md0、から/dev/sda1と/dev/sdb1。追加のSW RAID 1セット/dev/md1を/dev/md2、対応するパーティションから構築します。

4. /dev/md0ext3としてフォーマットします。これはになります/boot。

5. LVM物理ボリュームとしてフォーマット/dev/md1し/dev/md2ます。

6. vg_systemを含むLVMボリュームグループを作成します/dev/md1。

7. vg_systemさまざまなOSパーティション用に適切なLVMボリュームを作成します。非常に少なくとも、あなたが欲しいよswap、/var夫婦GBの、および/10ギガバイトのかそこら。 注：すべてを割り当てないでvg_systemください！後でのサイズを大きくする\varか、またはその他を追加する /opt場合は、追加のスペースが必要になります。

8. vg_dataを含むLVMボリュームグループを作成します/dev/md2。

9. vg_data必要に応じて内部にLVMボリュームを作成します。少なくとも、かなりのサイズが必要になります。/homeたとえば、メールスプール、データベース、Webルート、またはOSの一部ではないその他のデータ用に追加のボリュームが必要になる場合があります。繰り返しますがvg_data、上記と同様の理由で、すべてを割り当てないでください。

この戦略の利点は次のとおりです。

• ハードウェア障害に耐性があります。どちらのドライブもシステム障害を引き起こすことなく故障する可能性があり、ホットスワップコントローラに投資すれば、ダウンタイムなしで回復できます。

• 将来性があり、拡張可能です。数年後に2TBドライブを購入すると、それらをマシンに平手打ちし、別のSW RAIDセットにして、LVM物理ボリュームとしてフォーマットし、より多くのスペースを必要とするボリュームグループ（おそらくlv_data）に追加できます。pvmove古いドライブから新しいドライブにデータを移行するために使用 します。さらに、主要なOSの更新による痛みを大幅に軽減できます。メジャーアップグレードのためにOSを再インストールする必要がある場合（Red Hat :(）、ホームディレクトリ（およびメールスプールなど）を保存している間vg_data）

この戦略の欠点はほとんどありません。私はそれが少し複雑だと思うし、あなたはRAID 1のために書き込みのパフォーマンスに打撃を与えます。しかし、私はここ数年、これらの原則に従ってワークステーションとスタンドアロンサーバーを構築してきましたこれらのラインに沿ってマシンを構築しないでください。

-スティーブ

PS新しいマシンを迅速かつ簡単にプロビジョニングするためのインフラストラクチャが整っている場合、このようなシステムは過剰になります。RAIDセットとLVMをいじるのではなく、何か変更が必要な場合はマシンを再構築するだけです。

何年もの間、私が使用したすべてのコンピューターはデュアルブートシステムであり、Linux側ではこのスキーマにかなりこだわっていました（ここではパーソナルワークステーションについて話していますが、サーバーはありません。

/     - main thing
/boot - not that relevant, since cylinder being < 1024 and 
        exotic filesystems are no longer an issue
/home - handy if you upgrade your laptop with each new distro :-)

最後のアップグレードでは、最初からインストールを行い、/パーティションを一掃しました。そのため、私はそこに入れたすべてのものを再インストールする手間を省いて、別のパーティション/optまたは/usr/localパーティションが良かったと思いました（Java、Eclipse ...通常、ディストリビューションパッケージのものは気にしません）。

Eddieが言及したパーティションに加えて、通常はさらに2つのパーティションを作成します

/ tmp-同じ理由で、別の/ varパーティションを作成しました（これまでに一時スペースがいっぱいになりました）。私は通常1〜2GBで行きます

/ usr / local-これにより、個別にインストールされたすべてのソフトウェアを吹き飛ばすことなく、必要に応じて/ usrをアップグレードおよびクリーニングできます。ここでのサイズは、インストールする外部ソフトウェアの量によって異なります。私は通常、約10 GBを使用しますが、最近はそれが少し小さいことがわかりました。

私は常に/ homeを最後にし、残りのディスクをそれで満たします。

/ bootパーティションでは、100 Mbより大きくしたことはなく、スペースの問題が発生することもありません（最終的には古いカーネルを削除します）。本当に非常に小さくすることができます。

また、スワップパーティションも忘れないでください。

ほとんどのマシンでは、

100MB /boot
1GB * NUMBER_OF_USERS /home
10GB /var/log
10GB /var
REST /

場合によっては、これを切り替える必要がありますが、ユーザーがサーバー上で1 GBを超える領域を取得しないことについて、私は非常に固執しています。さらに必要な場合は、/ tmpを使用できますが、cronを介して毎晩削除されることを理解しています。

そこでハードウェアRAIDを使用しないと仮定すると、Linuxでは常にRAIDの上でLVMを使用します。単一ディスク構成の場合でも。理由は、LVMグループを拡張することでストレージスペースを追加したり、冗長オプションを変更したりすることです（「奇妙な」単一ディスクraid1構成をミラーリングに変更するか、多少の手間をかけたRAID10に変更するなど）。

あなたの質問に答えるために、私は通常、汎用サーバーについてこれに似たものを持っています。2つのディスク（たとえば1RUのDell）から開始し、両方とも次のようにパーティション分割されます。

• / boot用に〜100MB RAID1
• ディスクの残りのためのRAID1上のLVM

次に、すべてのボリュームをLVMボリュームとして作成します：* / * / var * / tmp * / home * / opt

管理するのが面倒なので、あまり多くのファイルシステムを作成しないようにします。ディスクが不足している場合、多くのファイルシステムに空き領域がありますが、作業を行うのに十分ではありません。

別のファイルシステムにある/ homeと/ tmpは常に良いアイデアです。一般的に、/ optにたくさんのものを入れる予定がない限り、/ optを分離しません。（同じソフトウェアスタックを必要とするサーバーが多数ある場合は、NFSが/ optのより良いオプションになる可能性があります）

要するに、そうしない理由がない限り、すべてにLVMを使用してください。そのように変更するオプションがあります。

また、ログが/ varをいっぱいにしないようにログサーバーを使用してください！

• / boot-128MB

ボリュームグループ-rootvg

• / var-5GB（メールサーバーとして使用されるかどうかによります。コアファイルをキャッチするためにサイズを変更することもできます）
• / tmp-2GB
• / opt-10GB（ディストリビューションに付属していないソフトウェアに使用）
• /-6GB-最小

ボリュームグループ-datavg

• / home-残り

ソフトウェア用に別の/ usrを作成できますが、私の場合、ボックスは再インストールされるため、独自のパーティションを取得する必要はありません。