Unixサーバーのパーティション分割とファイルシステムのレイアウト

インターネット上でのUnixサーバーのパーティショニングに関する矛盾した情報がたくさんあるので、先に進む方法についてのアドバイスが必要です。

これまでのところ、私たちのテスト環境のサーバーでは、パーティション分割についてはあまり気にしませんでした。単一のモノリシックパーティションと/スワップパーティションを構成しました。このパーティショニングスキームは、運用サーバーにとって良いアイデアとは思えません。ここで良い出発点を見つけましたが、詳細については非常にあいまいです。

基本的に、基本的なLAMPスタック（Apache、PHP、およびMySQL）を実行するサーバーがあります。ファイルのアップロードを処理する必要があります（最大2GB）。システムには2TB RAID 1アレイがあります。

私は設定する予定です：

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

これは正気ですか、それとも私は物事を複雑にしすぎていますか？

パーティションをレイアウトする際に注意すべきことの1つは、障害モードです。通常、その質問は「パーティションxがいっぱいになるとどうなりますか」という形式です。最愛のvoretaq7は、/診断が困難な問題を完全に引き起こす状況をもたらしました。もっと具体的な状況を見てみましょう。

ログを保存しているパーティションがいっぱいになったらどうなりますか？ 監査/レポートデータを失い、攻撃者がアクティビティを隠すために使用することがあります。場合によっては、ログインイベントを記録できない場合、システムは新しいユーザーを認証しません。

RPMベースのシステム/varがいっぱいになるとどうなりますか？ パッケージマネージャーはパッケージをインストールまたは更新せず、構成によってはサイレントに失敗する場合があります。

パーティションをいっぱいにするのは簡単です、特にユーザーがそこに書き込むことができる場合。楽しみのために、このコマンドを実行して、非常に大きなファイルを作成できる速さを確認してくださいcat /dev/zero > zerofile。

パーティションをいっぱいにするだけでなく、異なるマウントポイントに場所を配置する場合、マウントオプションをカスタマイズすることもできます。

が/dev/マウントされていない場合はどうなりnoexecますか？ ためには/dev、典型的にはOSによって維持されると仮定のみが頻繁であった（時にはまだ）皮悪意のあるプログラムに使用されるデバイスを含むています。終了noexecすると、そこに保存されているバイナリを起動できます。

これらのすべての理由から、多くの強化ガイドでは、実行する最初の手順の1つとしてパーティション化について説明します。実際、新しいサーバーを構築する場合、ディスクをパーティション分割する方法は、最初に決定しなければならないこととほぼ同じであり、多くの場合、後で変更するのが最も困難です。Center for Internet Securityと呼ばれるグループが存在し、読みやすい構成ガイドを提供しています。特定のオペレーティングシステムのガイドを見つけて、詳細がわかる場合があります。

RedHat Enterprise Linux 6を見ると、推奨されるパーティションスキームは次のとおりです。

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

これらのすべての変更の背後にある原則は、それらが互いに影響を与えないようにすること、および/または特定のパーティションで実行できることを制限することです。/tmpたとえば、オプションを取り上げます。つまり、そこにはデバイスノードを作成できず、そこからプログラムを実行できず、set-uidビットは何にも設定できないということです。その性質上、/tmpほぼ常に世界で書き込み可能であり、多くの場合、メモリにのみ存在する特殊なタイプのファイルシステムです。これは、攻撃者がそれを簡単なステージングポイントとして使用して悪意のあるコードをドロップおよび実行し、システムをクラッシュ（または単に再起動）してすべての証拠を消去することを意味します。の機能はその機能を/tmp必要としないため、機能を簡単に無効にしてその状況を防ぐことができます。

ログ保存場所、/var/logおよび/var/log/auditリソースの枯渇からそれらをバッファヘルプをオフに刻まれています。さらに、auditdは、ログストレージがいっぱいになり始めたときに、いくつかの特別な処理を実行できます（通常、より高いセキュリティ環境で）。パーティションに配置することにより、このリソース検出のパフォーマンスが向上します。

より詳細に、かつquoteにするためにmount(8)、これはまさに上記で使用されたオプションです：

noexecマウントされたファイルシステム上でバイナリの直接実行を許可しません。（最近まで、/ lib / ld * .so / mnt / binaryなどのコマンドを使用してバイナリを実行できました。このトリックはLinux 2.4.25 / 2.6.0以降で失敗します。）

nodev ファイルシステム上の文字を解釈したり、特殊デバイスをブロックしたりしません。

nosuid set-user-identifierまたはset-group-identifierビットを有効にしないでください。（これは安全に思えますが、実際にはsuidperl（1）がインストールされている場合はかなり安全ではありません。）

セキュリティの観点から、これらはファイルシステム自体に保護をかけることができるので、知っておくべき非常に良いオプションです。安全性の高い環境では、noexecオプションをに追加することもできます/home。標準ユーザーがデータを処理するためのシェルスクリプト（ログファイルの分析など）を書くことを難しくしますが、特権を昇格させるバイナリを実行することも防ぎます。

また、rootユーザーのデフォルトのホームディレクトリはであることに注意してください/root。この手段はになり/、ファイルシステムではありませんで/home。

各パーティションに与える正確な量は、システムのワークロードによって大きく異なります。私が管理している典型的なサーバーでは、人との対話が必要になることはめったにないため、/homeパーティションをそれほど大きくする必要はありません。/var頻繁に作成および削除される一時データを保存する傾向があるため、同じことが当てはまります。ただし、Webサーバーは通常/var/www、プレイグラウンドとして使用します。つまり、別のパーティションにも配置する/var/必要があるか、大きくする必要があります。

過去に、以下をベースラインとして推奨しました。

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

これらは、システムの目的、および環境の動作に応じて確認および調整する必要があります。また、LVMを使用し、ディスク全体を割り当てることをお勧めします。これにより、必要な場合にパーティションを簡単に拡張または追加できます。

基礎となるRAIDアレイを無視します（RAIDアレイレベルの詳細と使用時期については、この質問を参照してください）。あなたが尋ねているコアな質問に集中しましょう：
「Unixサーバーのファイルシステムをどのようにレイアウトすればよいですか？」

1つの巨大な/パーティションの何が問題になっていますか？

あなたはあなたの質問で述べたように、Linuxディストリビューション（Ubuntuのような特に「デスクトップ」のディストリビューション）の多くは、非常に単純なファイルシステムのレイアウトを使用します/と[swap]。

このスキームにはシンプルさという利点があります。つまり、「ハードドライブ」を1つの大きなモノリシックコンテナー（C:\）として自宅のPCに慣れているDOS / Windowsユーザーに最適で、心配する必要はありません。ファイルシステムのスペース不足について-ディスクの容量を超えないようにして、すべてが（少なくとも理論的には）正常であることを確認してください。

ただし、単一ファイルシステムスキームにはいくつかの欠点があります-最もよく挙げられる欠点は、ルートファイルシステムがいっぱいになると（ブートを拒否するまで）、すべてが書き込みを行う場合/（ルート） 1つのわがままなプログラムまたはユーザーがシステム全体を停止できます。
また、単一の大規模なファイルシステムは、システムのクラッシュとそれに続くファイルシステムの破損が発生した場合、完全に失われる傾向があります。

上記の問題に加えて強い組織意識が、Unixサーバーが通常複数のファイルシステムを持っている理由です。

Unixファイルシステムをどのように分割しますか？

したがって、複数のファイルシステムを使用するのが理にかなっていると確信していることを願っています。ここでの質問は、システムをどのように論理的なチャンクに分割するか、そしてそれぞれがどのくらいのスペースを取得するかをどのように決定するかです。
答えは、オペレーティングシステムがどこに配置するかを知って理解することです。その理解の出発点はhierマニュアルページです。ほとんどのUNIXシステムは、（付属してman hierLinuxシステムからの、およびman hierBSDシステムから）、そのプラスのコード何のあなたの地元の知識、あなたがインストールしているが、正気のパーティションレイアウトを作成する際にご案内しますするつもりです。

ここでは一般的なパーティションスキームについて説明しますが、このスキームは特定のニーズに合わせて常に変更する必要があります。

一般的なUnixパーティションスキーム

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

特別なファイルシステム

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

そのようなファイルシステムを切り分ける慣習は、ソフトウェアレイドがなく、ディスクドライブが小さかった時代からのものであるため、それらのいくつかを使用する必要があったため、それを行う唯一の方法はファイルシステムを分解することでした異なるドライブに異なるディレクトリを配置します。もう1つの歴史的な理由は、パーティションを簡単にマウント解除dumpしてバックアップできるようにするためで、これはルートではできませんでした。このツールは最近ではあまり好まれなくなっており、代わりにルート上でもLVMスナップショットで使用できます。

これを行う理由はほとんどありません。これを行う唯一の理由は、たとえば、/tmpディスク全体がいっぱいにならないようにする場合です。

この理由は、一般的なシェルアクセスをユーザーに提供する方法が間近に迫っており、最近ではサーバーがWebサーバーやメールサーバーなどの専用サービスを実行しているためです。任意のコマンドを実行できるランダムなユーザーはいないので、一般に、それらがファイルシステムをいっぱいにしようとすることを心配する必要はありません（そして、それをやめたとしても、それを停止するためのディスククォータがありました）。

どのRAIDレベルを使用するかについては、RAIDの主な目的はデータを保護することではなく（バックアップの目的）、稼働時間を維持することであることに注意する必要があります。あなたが入れた場合は/tmpRAID0に、そしてあなたのサーバーは、まだダウンして行くだろうと、あなたは、ディスクの1つが失敗した場合、修理にそれを行かなければならないと思います。また、raid1の代わりにraid10を使用して、パフォーマンスを向上させることもできます。

ファイルシステムを分割しない非常に正当な理由は、割り当てを間違えた場合、他の場所に十分な空きスペースがあるにもかかわらず、ファイルシステムの一部がいっぱいになることです。LVMを使用して未割り当てのスペースを残さない限り、これを修正するのは難しい場合があります。

ディスク領域が不足したときに、多くのパーティション情報が生成されました。その結果、多くの場合、比較的小さなパーティションが表示されます。必要なパーティションサイズは、サーバーの使用状況によって異なります。ほとんどの変数はになる傾向があり/tmp、/var、home、/opt、と/srv。 /usr合理的で安定したサイズになる傾向があります。のスペースに/は、他のパーティションの一部またはすべてとそのスペース要件を含めることができます。サイズ設定は、システムの実行内容に大きく依存します。

を増やしswapてマウント/tmpしtmpfsます。/tmp次に、スワップをバッキングストアとして使用しますが、使用可能なメモリを使用します。サイズは/tmp非常に大きく見えますが、クリーンアップされていないアップロードの中止を処理します。

MySQLファイルをに移動することを検討します/srv。これは、ディスク階層の比較的新しいレベルです。

最終的な要件がわからない場合は、LVMを使用して、いっぱいになるようにパーティションを拡張することを検討してください。

アーキテクチャによっては、再起動するたびにクリアされるため、実際には/ tmpを使用したくない場合があります。サイトが最終的にアップロードの処理を処理する場合、これを別の場所に変更する（php.iniを介して）ことが考えられます。任意のマウントポイントにすることができます。

前述のとおり、LVMを使用し、必要に応じて増分することを強くお勧めします。

また、MySQLデータ専用のパーティションを強くお勧めします（/ var / lib / mysqlの下にマウントすることもできます）。