まず自分の置かれている立場と、何がしたいのかということから始めましょう。 家庭のシステムは既にあるハードウェアにインストールされることが多いでしょう。 新しく Linux ユーザになった人は、その既存のハードウェアから 最高のパフォーマンスを引き出したいと思うでしょう。 逆にインターネットプロバイダのように、 特定の目的のために新たなシステムをセットアップする場合は、 目的に応じて購入するハードウェアを決定する必要があります。 この文書では、この両極をカバーしたいと思っています。
様々な目的に応じて、
ファイルシステムのドライブへの配置も異なってくるでしょう。
例えばマルチユーザで使う大きなマシンなどでは
/home を独立したディスクに分離するのが良いでしょう。
一般に性能を上げるには、 できるだけたくさんのものを別々のディスクに分散させるのが有利です。 しかし一つの SCSI バスに繋ぐことのできるデバイスの数は限られていますし、 コストの問題も絡んでくるでしょう。 またパーティションやディスクの数が増えるにつれて 管理が面倒になるという点も重要です。
最近の安価なハードウェアを使えば、それほどお金をかけなくても 自宅に大きなシステムを構築することができるでしょう。 有名なサイトの一年前のサーバマシンと張りあえるくらいものも それほど難しくないはずです。 多くの人が古くて余ったディスクからサーバを構築する一方 (この HOWTO が生まれるきっかけもこれでした)、 20 GB 分のディスクを買いそろえることができる人も また少なくはないでしょう。
でもサイズの見積もりが必要な人もまだいるでしょうから、 以下にいくつかの目安を挙げておきます。
Linux はシンプルにできていて、試すだけならハードディスクも必要ありません。 ブートフロッピーさえあれば、あなたの持っているハードウェアで Linux を動かしてみることができます。 もし使っているハードウェアが特殊で標準のカーネルが動かない場合でも、 対応したブートディスクが用意されているはずです。 最悪の場合でも、お使いのシステムに適応したカーネルが構築できるまでの環境は 整っているはずです。
OS について学ぶには Linux は最適です。関連文書が山ほどありますし、 ソースを見ることもできます。 ドライブ一台に 50 MB ほどの容量があれば、シェルを起動し、 良く使われるコマンドやユーティリティを入れておくには充分でしょう。
趣味として Linux を扱ったり、学習をさらに進めるためには、 もう少し多くのコマンドやユーティリティが必要になるかもしれません。 しかしドライブは相変わらず一台、 500 MB ほどあれば OK です。 ソースやドキュメントも充分入れておけるはずです。
プログラム開発や、趣味でも本格的な利用となると、 もう少し容量が必要になります。 この頃になるときっとメールやニュースを利用するようになっているでしょうから、 そのためのスプール領域が大量に必要になります。 各種のタスクに別々のドライブを割り当てることが有効になります。 この段階ではきっと複数のドライブを利用するようになるでしょう。 ドライブの必要量を計算するのは難しいですが、 2〜4 GB あれば良いのではないかと思います。 小規模ならサーバでもこれだけあれば大丈夫でしょう。
サーバと言ってもメールサーバからサービスプロバイダまで様々です。 メインのシステムには 2 GB あれば良いでしょう。 その後、サービスに応じて容量やドライブを足して行きます。 コストが主な制限になってくるでしょうが、 「サービス」プロバイダであり続けるためには、 ディスクを追加できるように資金には余裕を持っておくことです (そうしていないところも多いようですが)。
本格的に利用されるマシンは皆そうですが、 サーバも基本的には割り当てられたリソースを 一杯一杯になるまで使いきってしまうものです。 そしてサーバの場合は、 CPU よりも IO によって律速される場合が多いです。
有線でも無線でも、ネットワークの技術はどんどん安価になってきていますから、 これからの時代にはホームユーザーがネットにつないだサーバは、 すぐに多かれ少なかれ「つなぎっぱなし」になってしまうでしょう。
大きなタスクをいくつも走らせるようになると、 大きな容量のドライブが必要になり、 それぞれ専用のエリアを作らなければならなくなります。 可能ならばドライブは別々に分けましょう。 この文書の付録には小さな部門用のサーバ (ユーザ 10〜100 人) の セットアップの詳細も付けておきました。 ここではハイエンドのサーバについての知識を述べておきます。 一般的には RAID を積極的に用いるべきです。 速度や信頼性の面だけでなく、ディスクの追加が多少楽になるからです。 ここで述べる内容は、今までに述べたことを補うものであると思って下さい。
人気のあるサーバサイトというのはすぐに生まれるものではなく、
時間とともに成長し、
その過程でディスク容量やネットのバンド幅がだんだん必要になっていくものです。
このようなサーバを運用している場合、
それぞれのタスクで管理しているデータを丸ごと一つの SCSI ドライブ
(またはドライブアレイ) にあてがっておくのも良い考えです。
こうしておけばコンピュータ本体が故障した場合に
データを移動することができるからです。
ただしドライブをコンピュータ間で移動するのはそれほど単純なことではなく、
うまく動かない可能性があることも注意しておいてください。
特に IDE の場合は問題の発生率が高くなるかもしれません。
ドライブアレイのデータを正しく再構成する際にも注意が必要です。
fstab ファイルやそれぞれのドライブの SCSI ID を紙に書いて
保存しておくと良いでしょう。
まずドライブが何台必要かを見積もりましょう。 2 台以上ならば
RAID を使うことを強くお勧めします。 RAID を利用しない場合は、
ハッシュ的なアルゴリズムを使うなどして、
ユーザをそれぞれのドライブに振り分ける必要があります。
例えばユーザ名の最初の 2 文字などを使うと良いかもしれません。
jbloggs というユーザなら、ホームディレクトリは
/u/j/b/jbloggs となります。
ここで /u/j は実際のドライブへのシンボリックリンクで、
各ドライブへの負荷を分散させるように定めます。
サーバ機能でも良く利用される基本的なものです。良いサーバというものは、 良好なメンテナンスがされており、ドキュメントが整備されていて、更新が速く、 そして世界のどこにあろうが非常に有名になるものです。良い例としては、 大きなサーバである ftp.funet.fi などが挙げられるでしょう。
このとき問題になるのは CPU ではなく、通常はネットワークのバンド幅です。 容量を見積もるのは難しく、 どの程度の規模にするかやサービスに対する姿勢によるところが大です。例えば ftp.cdrom.com の巨大なアーカイブは、 *BSD マシンに 50 GB のディスクを付けたものです。 メモリも専用の FTP サーバには重要で、 巨大なサーバでは 256 MB は欲しいところです。 もう少し小さなサーバなら 64 MB の RAM でも充分仕事をしてくれるでしょう。 しかしネットワーク接続の問題がいずれにしても最重要でしょう。
WWW は多くの人々にとってインターネットを利用するきっかけとなりました。 また、この 2 つを同じものとみなしている人も この「多くの人々」の中にはいるようですね。 やはりネットワークによる影響が大ですが、ドライブの動作も (特に Web ページのキャッシュに関して) 影響します。 キャッシュ領域は独立した速いドライブに置いておくと有利です。 キャッシュ機能込みのプロキシサーバをインストールするとさらに良いでしょう。 このようにすれば、それぞれのユーザの WWW 要求をまとめられるので、 キャッシュ領域のサイズも小さくできますし、 ネットワークのバンド幅も節約できます。
キャッシュ付きのプロキシサーバには高速なドライブ (アレイ) が必要になります。
RAID 0 を利用できれば理想的です (信頼性はさほど必要ありませんから)。
大きな方が良いですが、 2 GB もあれば大抵は大丈夫でしょう。
キャッシュを保持する期間を長くするとたくさんの領域が必要になりますが、
キャッシュへのヒット率も向上します。
しかしあまり長くしすぎるのも良くありません。
できれば URL ごとに調整できると良いですね。さらに情報を求める人は、
サーバのドキュメントなどを調べてください。 Harvest や
Squid
などが有名です。
Netscape
から出ているものもあるようです。
メールはほとんどすべてのホストで扱われています。
しかし大きなメールサーバはメール配信機能に特化している場合が多いです。
メール配送は負荷の大きなタスクであり、
大きなサーバではドライブとネット両方が高速でもなお速度が遅い、
ということもよくあります。
Linux の世界では vger.rutgers.edu
にある大きなサーバがよく知られている例です。
ニュースサーバでは情報が分散しているため、
他のマシンからフィードすることによって
スプールを再構成することができるのに対して、
メールサーバは他とデータを共有しません。
したがって安全性が非常に重要となります。
大きなサーバを運用している場合は、
信頼性を高めるために RAID の導入を考えるべきでしょう。
容量は運用しているメーリングリストの数と
購読している読者によって大きく変わります。
巨大なメールサーバーでは、 IO が性能のボトルネックになってしまうことが
あります。このため、巨大なシリコンディスクを SCSI につないで、
そこにメール関係のファイルを、一時ファイルも含めて置いている人も
いるようです。安全性を追求するため、
これらにはバッテリーバックアップが用いられており、
また udf のようなファイルシステムが好まれています。
このファイルシステムは常にメタデータをディスクにフラッシュするからです。
これは性能を落としますが、非常に高速なディスクを用いることで
調整されています。
最近では、メールサーバから
POP を使ってローカルマシンにメールを移動して来るやり方に代わって、
メールアーカイブを一ヶ所に集中させておき、
IMAP で閲覧する手法が取られるようになってきています。
これはすなわち、メールはもはや「スプール」されるのではなく、
ひたすら大きくなりつづけることを意味します。
したがって膨大なディスク領域が必要になります。
さらに、ありとあらゆる通信に添付ファイルが頻用 (濫用) されるようになりました。
小さなワープロ文書ですら 1 MB を越えることが珍しくありません。
ディスクは気前良く用意し、残りの容量に目を光らせましょう。
ニュースは必要な領域が大きいですが、 どの程度になるかは購読しているニュースグループに大きく依存します。 nyx ではほとんど全てのグループを購読しており、 17 GB 程度を消費しています。 もっとも大きくなるのは明らかに alt.binary.* 以下のグループです。 もしこのグループを購読しなければ 12 GB 程度で良いサービスを提供できます。 小規模なところには 2 GB 程度で 「サービスプロバイダ」と称しているところもあるようですが、 この程度では expire が非常に早くなってしまうでしょう。 こういうところは「サービス」の名に値しないと言うのが筆者の意見です。 ニュースのフルフィードは毎日数 GB のトラフィックを意味します。 またこの値は大きくなり続けています。
ネットで利用できるサービスは非常に多くの種類がありますが、 その多くは WWW の影に隠れています。 しかし archie や gopher, wais と言ったサービスはまだまだ現役かつ有益なツールです。 もし手元で大きなサーバを立ち上げるつもりでしたら、 これらのサービスについても考えるべきでしょう。 必要な容量を決定するのは難しく、人気と要求頻度に依存します。 よいサービスを提供するには当然コストが必要で、 ディスク容量はその一つに過ぎません。
こんにち商用サーバに満足いく機能を発揮させるためには、 大容量のディスクを多数用いる必要があります。 用いる要素部品が増えるほど平均故障時間 (mean time between failure: MTBF) は急激に短くなりますから、 データを守るために RAID を用いることを考えるべきだと思います。 また巨大な一台のディスクの代わりに、 やや小さい容量のドライブを複数用いることも考慮の価値があります。 より詳しい情報は High Availability (HA) プロジェクトを見てみましょう。
High Availability HOWTO や、関連 web ページ に、詳しい情報があります。
可能なもの全てを別々のパーティションに分けてしまうことに伴う危険性については、 ボリューム管理の節において簡単に紹介しました。 しかしこの点はより強調しておくべきだというアドバイスが多かったので、 もう一度言います: 一度設定したパーティションは使い切ったらそれで終わりで、 増やすことはできません。他のパーティションがいくら余っていてもです。
特にニューススプール (/var/spool/news) は
爆発的に増えることがあるので注意が必要です。
quota を利用したマルチユーザのマシンでは、
/tmp や /var/tmp にも目を配り、
ここにファイルを隠すユーザがいないかどうかも気をつけましょう
(特に .gif や .jpeg で終わる名前のファイルなど :-)。
実際のところドライブがひとつしかないようなシステムでは
パーティション分割はあまり役に立ちません。
メリットは df を使ってファイルサイズのモニタが簡単にできること、
物理的なセクタ配置を行えることくらいでしょうか。
致命的なのはディスクの並列利用ができないことです。
フリーで使えるようなボリューム管理システムが出てくれば
この節の最初で述べた問題は解決しますが、
これはもう少し先のことになりそうです。
いろいろな機能に特化したファイルシステムが出てくれば、
1 ドライブのシステムにおいてもパーティション分割は有効になるでしょう。