web-dev-qa-db-ja.com

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

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

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

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

linuxunixpartition
15
paulgreg

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

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

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

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

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

[〜＃〜] lvm [〜＃〜] を使用すると、再起動することなく、将来の気分を変えてパーティションを調整するのがはるかに簡単になります。優れたバックアップを簡単に作成できます。

17
Zoredache

私は常にこれらのパーティションを作成し、昨年の時点では常に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なのか？他の場所での回答で述べたが、ここで言及するのを忘れたように、後で気が変わってパーティションを拡張するのが非常に簡単になります。これは私のお尻をすでに救っています。

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

8
Eddie

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

  1. 同じサイズの物理ドライブを少なくとも2台取り付けます。この例では、500GB SATAドライブを想定していますが、原則は他のサイズのドライブでも問題なく機能します。

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

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

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

  3. /dev/md0と/dev/sda1からSWRAID1セット/dev/sdb1を作成します。対応するパーティションから追加のSWRAID1セット/dev/md1および/dev/md2を構築します。

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

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

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

  7. さまざまなOSパーティション用にvg_system内に適切なLVMボリュームを作成します。少なくとも、数GBのswap、/var、および10GB程度の/が必要です。 [〜＃〜]ノート[〜＃〜]：vg_system！後で\varのサイズを大きくしたい場合、または/optなどを追加したい場合は、その追加スペースが必要になります。

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

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

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

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

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

この戦略の欠点はほとんどありません。少し複雑だと思いますが、RAID 1のおかげで書き込みのパフォーマンスが低下します。しかし、私はここ数年、これらの原則に従ってワークステーションとスタンドアロンサーバーを構築してきましたが、私の経験では、やがて私が欲しかったのに、これらの線に沿って機械を作らないでください。

-スティーブ

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

7
hakamadare

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

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

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

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

/ bootパーティションでは、100 Mbを超えることはなく、スペースの問題が発生することもありません（最終的に古いカーネルをクリーンアップします）。それは本当に非常に小さい場合があります。

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

2
dagorym

何年もの間、私が使用したすべてのコンピューターはデュアルブートシステムであり、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 ...私は通常気にしません）を再インストールする手間を省きました。ディストリビューションパッケージのもの）。

2
agnul

そこでハードウェアRAIDを使用しないと仮定すると、Linuxでは常にRAIDの上にLVMを使用します。単一ディスク構成でも。その理由は、（LVMグループを拡張することによって）ストレージスペースを追加するか、冗長性オプションを変更する（たとえば、「奇妙な」単一ディスクraid1構成をミラーリングされたものまたはRAID10に変換するなど）オプションがあるためです。

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

  • / boot用に最大100MBのRAID1
  • ディスクの残りの部分のRAID1上のLVM

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

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

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

要するに、理由がない限り、すべてにLVMを使用します。そうすることで、変更するオプションを利用できます。

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

1
Lester Cheung

ほとんどのマシンでは、

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

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

1
Glen Solsberry
  • / boot-128 MB

ボリュームグループ-rootvg

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

ボリュームグループ-datavg

  • / home-残り

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

0
setatakahashi