Unixサーバーのパーティショニングとファイルシステムのレイアウト
インターネット上でのUnixサーバーのパーティション分割については、相反する情報がたくさんあるので、続行する方法についてアドバイスが必要です。
これまでのところ、私がテスト環境で使用しているサーバーでは、パーティション分割については特に気にせず、単一のモノリシック/とスワップパーティションを構成しました。このパーティショニングスキームは、私たちの運用サーバーにとっては良い考えのようには思えません。私は良い出発点 here を見つけましたが、詳細については非常にあいまいなようです。
基本的に、基本的な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は、完全な_/_で状況を引き起こし、問題の診断を困難にしました。より具体的な状況をいくつか見てみましょう。
ログを格納するパーティションがいっぱいになるとどうなりますか？監査/レポートデータを失い、攻撃者がそのデータを非表示にするために使用されることがありますアクティビティ。ログインイベントを記録できない場合、システムが新しいユーザーを認証しない場合があります。
_/var_がいっぱいになるとRPMベースのシステムで何が起こりますか？パッケージマネージャーはパッケージをインストールまたは更新しません設定によっては、警告なしに失敗する場合があります。
特にユーザーがパーティションに書き込むことができる場合は、パーティションをいっぱいにするのは簡単です。面白くするには、このコマンドを実行して、かなり大きなファイル_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はいくつかの特別な処理（通常はより高いセキュリティ環境）を実行できます。パーティションに配置することで、このリソース検出のパフォーマンスが向上します。
より冗長にして、mount(8)を引用すると、これはまさに上記で使用したオプションと同じです。
noexecマウントされたファイルシステム上のバイナリの直接実行を許可しません。 （最近まで、とにかく/lib/ld*.so/mnt/binaryのようなコマンドを使用してバイナリを実行することが可能でした。このトリックはLinux 2.4.25/2.6.0以降失敗します。）
nodevファイルシステムの文字を解釈したり、特殊デバイスをブロックしたりしません。
nosuidset-user-identifierまたはset-group-identifierビットを有効にしないでください。 （これは安全に見えますが、実際にはsuidperl（1）がインストールされている場合はかなり安全ではありません。）
セキュリティの観点から、これらはファイルシステム自体に保護をかけることができるため、知っておくと非常に良いオプションです。安全性の高い環境では、noexecオプションを_/home_に追加することもできます。ログファイルの分析など、標準ユーザーがデータを処理するためのシェルスクリプトを書くことが難しくなりますが、特権を昇格させるバイナリを実行することもできなくなります。
また、rootユーザーのデフォルトのホームディレクトリは_/root_であることに注意してください。つまり、これは_/_ファイルシステムにあり、_/home_ではnotです。
正確に各パーティションに与える量は、システムのワークロードによって大きく異なります。私が管理した典型的なサーバーは、人との対話をほとんど必要としないため、_/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つの大きなモノリシックコンテナーとして使用する自宅のPCに慣れているDOS/Windowsユーザーに最適です（C:\）にデータをダンプします。ファイルシステムのスペースが不足することを心配する必要はありません。ディスクの容量を超えないようにし、すべてが（少なくとも理論的には）正常であることを確認してください。
ただし、単一ファイルシステムスキームにはいくつかの欠点があります-最もよく引用される欠点は、ルートシステムがいっぱいになると（ブートを拒否するほど）、Unixシステムは非常に悪い反応を示し、すべてが/（ルート）1つの厄介なプログラムまたはユーザーがシステム全体を停止できます。
単一の大きなファイルシステムでも、システムクラッシュとそれに続くファイルシステムの破損が発生すると、完全に失われる傾向があります。
上記の問題に加えて、組織の強い感覚が、Unixサーバーに通常複数のファイルシステムがある理由です。
Unixファイルシステムをどのように分割しますか？
うまくいけば、複数のファイルシステムを持つことが理にかなっていると確信できます。ここでの問題は、システムを論理的なチャンクにどのように分割するか、そしてそれぞれがどのくらいのスペースを取得するかをどのように決定するかです。
答えは、オペレーティングシステムがどこに配置するかを理解していることです。その理解の出発点はhierのmanページです。ほとんどのUnixシステムには（ man hier Linuxシステムから 、および man hier BSDシステムから ）、そしてそれに加えて、コードがインストールしようとしていることに関するローカルの知識（= /// =）がが実行しようとしていることは、正しいパーティションレイアウトを作成するのに役立ちます。
ここでは、一般的なパーティション分割スキームについて説明しますが、このスキームは、特定のニーズを満たすために常に変更する必要があります。
一般的な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.
ソフトウェアraidがなく、ディスクドライブが小さかった時代からのように、ファイルシステムを分割する習慣は、それらのいくつかを使用する必要があったため、これを行う唯一の方法は、ファイルシステムを分割することでした。別のドライブに別のディレクトリを配置します。もう1つの歴史的な理由は、パーティションを簡単にマウント解除し、dumpバックアップ用にそれを作成できるようにするためでした。これは、ルートでは実行できませんでした。このツールは最近の人気がほとんどなくなっており、代わりにルート上でもLVMスナップショットで使用できます。
これを行う理由は、ほとんどありません。これを行う唯一の理由は、たとえば、/tmpディスク全体をいっぱいにすることから。
この理由は、一般的なシェルアクセスのユーザーへの提供が途中でなくなったため、最近ではほとんど関係がなく、最近のサーバーはWebサーバーやメールサーバーなどの専用サービスを実行しています。ランダムなユーザーが任意のコマンドを実行できるわけではないので、一般に、ユーザーがファイルシステムをいっぱいにしようとしていることを心配する必要はありません（そうした場合でも、それを停止するためのディスククォータがありました）。
どのRAIDレベルを使用するかについては、RAIDの主な目的はデータを保護することではなく（それがバックアップの目的です）、稼働時間を維持することです。 /tmp raid0の場合、サーバーは引き続きダウンし、ディスクの1つに障害が発生した場合はサーバーを修復する必要があります。 raid1の代わりにraid10を使用して、パフォーマンスを向上させることもできます。
ファイルシステムを分割しない非常に良い理由は、割り当てが間違っていると、他の場所に十分な空き領域があるにもかかわらず、ファイルシステムの一部がいっぱいになる可能性があるためです。 LVMを使用して未割り当てのスペースを残さない限り、これを修正することは困難です。
ディスク領域が不足すると、パーティション情報の多くが生成されました。その結果、多くの場合、比較的小さなパーティションが表示されます。必要なパーティションサイズは、サーバーの使用状況によって異なります。最も変数は、/tmp、/var、home、/opt、/srvの傾向があります。 /usrは、適度で安定したサイズになる傾向があります。 /のスペースには、他のパーティションの一部またはすべてとそれらのスペース要件を含めることができます。サイジングは、実際にシステムを実行していることに依存しています。
swapを増やしてtmpfsに/tmpをマウントします。次に、/tmpはswapをバッキングストアとして使用しますが、メモリは可能な限り使用します。 /tmpのサイズは非常に大きく見えますが、クリーンアップされていない中止されたアップロードを処理します。
MySQLファイルを/srvに移動することを検討します。これは、ディスク階層の比較的新しいレベルです。
最終的な要件がわからない場合は、LVMを使用し、パーティションをいっぱいに拡張することを検討してください。
アーキテクチャによっては、再起動するたびにクリアされるため、/ tmpを実際に使用したくない場合があります。サイトでアップロードの最終的な処理を扱っている場合は、これを（php.iniを介して）別の場所に変更することをお勧めします。ここで、任意のマウントポイントにすることができます。
前述のとおり、LVMを使用し、必要に応じて増分することを強くお勧めします。
MySQLデータ専用のパーティションも強くお勧めします（/ var/lib/mysqlにマウントすることもできます）。