さてさて、これまで述べてきたような知識をもとにして、いよいよ実際の 配置について述べることにしましょう。以下の方法は私が 3 台の古い SCSI ディスクを使って、いろいろな可能性を試しながら作り出してきたものです。
この文書の最後に、システム設計の助けになる表を用意してあります。 以下ではこの表について説明しています。
必要な機能を決め、別々のパーティションに分けるファイルシステムのリスト を作ります。それを必要とされる速度の順に並べ、それぞれのパーティション に割り当てる容量を決めます。付録 A の表が役に立つでしょう。この表には 論理ディレクトリが順にならべてあり、マウントポイントに関するメモや別の OS に使う領域を書き込む部分が確保してあります。この表は速度順には並ん でいません。代わりに必要とされる速度を 'o' の数で示してあります。
RAID を利用するのでしたら、どのディスクを使って、どのパーティションを RAID 化するかを決めておきましょう。 RAID には色々な種類があり、様々な 速度/信頼性が選択できることを意識しておいて下さい。
話を簡単にするために、同じ SCSI ディスクがいくつかある場合を考えましょ う。 RAID は使わないものとします。
次にパーティションをディスクに割り当てていきます。これから述べるアルゴ リズムのポイントは、並列性を最大限確保してバスの容量をめいっぱい使うようにすることです。例として、 ドライブ A B C に対してパーティション 987654321 を割り当てることを考え ます。 9 が最も高速性が要求されるパーティションです。一つめのドライブ から出発してパーティションのラインを「くねらせて」いきます。こんな感じ です。
A : 9 4 3
B : 8 5 2
C : 7 6 1
これで「高速性の要求量の総和」が、どのドライブでも同じくらいになります。
付録につけた表はマッピングの作業を軽減するために作成したものです。持っ
ているドライブの速度の特性と、それぞれのディレクトリを適当な列に記入し
てください。ディレクトリやパーティション、ドライブは何回か入れ替えたく
なるでしょうから、表はその分用意しておきましょう。満足の行く割り当てが
できたら、リストをパーティション番号の順に並び替え、付録 C の表に記入
してください。インストールに際し、 fdisk
や cfdisk
などを実行してパー
ティション分けを行うときに、この最後の表を参考にすると良いでしょう。
上の手続きの後、通常いくつかのパーティションは入れ替える必要があります。 大きさを合わせたり、速度、信頼性、その他ファイルシステム特有の問題など を解決するためです。しかしそれでもここで与えた方法はドライブとパーティ ションを最適に設定するための良い出発点になります(と筆者は信じています) 。
何が必要とされるかについてを色々と考えてきたわけですが、本当のところは 実際にシステムを運用してみないと解らないでしょう。実際に運用を始めたの ち、パーティションの切り直しが必要とされるような時期がいつかはやって来 ると思っていたほうが良いでしょう。
例えば上で用いた 3 台のドライブのうちの一つが他に比べて非常に遅いような場合には、最適な配置は以下のようになるでしょう。
A : 9 6 5
B : 8 7 4
C : 3 2 1
総合的なスピードが似たようなドライブでも、ファイルのサイズやアクセスの 頻度などによって相性の良い悪いがあるものです。たとえばバイナリの置かれ ているディレクトリはコマンドキューが機能するようなアクセスの速いドライ ブに向いていますし、ライブラリのディレクトリには転送速度の高速なドライ ブが良いでしょう。後者に対しては IDE のディスクが高いコストパフォーマ ンスを示す場合もあるでしょう。
タスクを実行するときに、ドライブ利用の競合が起こらないように
しましょう。たとえば /usr/local/bin
にアクセスした直後に
/usr/local/lib
のファイルが必要になるような場合、これらのディ
レクトリを別々のドライブに置いておけば、シークや読み込み、キャッシュな
どの並列化、高速化が期待できるでしょう。並列動作が期待できる場合には、
先に述べたような最適化がなされている場合よりも優れた性能が得られるこ
とは充分ありえます。よく行われるタスクでどのパーティションが同時に使わ
れるかを考え、それらを別々のディスクに置くようにしましょう。
いまの内容をもう少し詳しく述べましょう。以下にタスク状況の解析例 をいくつか示します。
エディタやワードプロセッサ、スプレッドシート などが典型的な例です。 CPU の負荷もディスクの負荷もそれほど高くありません。 しかし、大量のユーザを抱えているサーバなどを管理している場合には、 これらのソフトのオートセーブ機能についてしっかり認識しておきましょう。 この機能はホームディレクトリに余分なトラフックを生じることになります。 ユーザのホームディレクトリをいくつかのドライブに分散させておけば 負荷の集中を減らすことができます。
ニュースリーダもホームディレクトリへのオートセーブを
行なうので、サービスプロバイダならばホームディレクトリやニューススプー
ル、 .overview
ファイルなどを別々のドライブに分ける方が良いでしょ
う。
データベースアプリケーションはドライブの容量と速度を両方とも必要と します。詳細はもちろんアプリケーションによります。ディスクの必要量に 注意しながらドキュメントを読んでおくことです。性能や信頼性を高めるためには RAID を導入するのも良いでしょう。
メールの送受信にはホームディレクトリと到着用/発信用のスプールが使われる ことになります。可能ならばホームディレクトリとスプールは別のドライブに 分けておくべきでしょう。メールサーバ(メールハブ)では、 到着用と発信用のスプールも別のドライブに分けると良いかもしれません。
たくさんのディレクトリが必要になります。コンパイラのバイナリやライブラリ、
インクルードファイル、さらにはソースやプロジェクトファイルなどなど。
許す限り別々のドライブに分けておきましょう。
小さなシステムでは /usr/src
とプロジェクトファイルをホームディ
レクトリと
一緒のドライブに入れてしまっても良いかもしれません。
WWW は人気が増す一方ですね。多くのブラウザではローカルなキャッシュを用 いており、これらはかなりの大きさになることがあります。ローカルキャッシュ は以前に読んだことのあるページを再ロードしたり、直前のページに戻ったり するときに用いられますので、この領域の速度はとても重要です。容量は(う まく設定されているプロキシサーバを経由している場合なら)ユーザ一人当り 数 MB 程度あれば充分でしょう。
Linux の配布パッケージや有名所の ftp サイトの内容を集めたような CD-ROM がたまってくると、手持ちのディスクにどんどんインストールしたくなるかも しれません。しかしそうすると残りの使える部分が少なくなってしまい、あっ という間に手におえなくなるでしょう。特に会社ではその場しのぎのいいかげ んなことはできませんしね。そこでここでは、システムを作るときに気をつ けておくと良い点に関して少々コメントを加えました。この節に関するコメン トは特に歓迎します。
簡単です。試すだけならハードディスクも要りません。ブートフロッピー だけあれば、あなたの持っているハードウェアで Linux を動かしてみる ことができます。もし使っているハードウェアが特殊で標準のカーネルが動かない場合でも、適用できるブートディスクが用意されているはずです。少なくともシステムに特化したカーネル構築までの環境は整っているはずですから。
OS について学ぶには Linux は最適です。関連文書が山ほどありますし、 ソースも見ることができます。ドライブ一台に 50 MB ほどの容量があれば シェルを起動し、頻用されるコマンドやユーティリティを入れておくには 充分でしょう。
趣味として Linux を扱ったり、学習をさらに進めるためには、もう少し多くの コマンドやユーティリティが必要になるかもしれません。しかしドライブは相 変わらず一台、 500 MB ほどあれば OK です。ソースやドキュメントも充分入れ ておけるはずです。
プログラム開発や、趣味の利用でも真面目になってくるともう少し容量が必要 になります。この頃になるときっとメールやニュースを利用するようになって いるでしょうから、そのためのスプール領域が大量に必要になります。各種の タスクに別々のドライブを割り当てることが有効になります。この段階ではきっ ともう複数のドライブを利用するようになるでしょう。ドライブの必要量を計 算するのは難しいですが、 2〜4 GB あれば良いのではないかと思います。小規 模なサーバでもこれだけあれば大丈夫でしょう。
サーバと言ってもメールサーバからサービスプロバイダまで様々です。メイン のシステムには 2 GB あれば良いでしょう。その後、サービスに応じて容量や ドライブを足して行きます。コストが主な制限になってくるでしょうが、「サー ビス」プロバイダであり続けるためにはディスクを追加できるように資金には 余裕を持っておくことです。そうしていないところも多いようですが。
大きなタスクをいくつも走らせるようになると、大きな容量のドライブが必要 になり、それぞれ専用のエリアを作らなければならなくなります。可能ならば ドライブは別々に分けましょう。この文書の付録には小さな部門用のサーバ (ユーザ 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 は欲しいところです。しかしネット ワーク接続の問題がいずれにしても最重要でしょう。
WWW は多くの人々にとってインターネットを利用するきっかけとなりました。 また、この 2 つを同じものとみなしている人も「多くの人々」の中には多い ようですね。やはりネットワークによる影響が大ですが、ドライブの動作も (特に Web ページのキャッシュに関して)影響します。キャッシュ領域は独 立した速いドライブに置いておくと有利です。キャッシュ機能込みの代理サー バをインストールするとさらに良いでしょう。このようにすれば、それぞれの ユーザの WWW 要求をまとめられるので、キャッシュ領域のサイズも小さくで きますし、ネットワークのバンド幅も節約できます。
キャッシュ付きの代理サーバには高速なドライブ(アレイ)が必要になります。 RAID 0 を利用できれば理想的です(信頼性はさほど必要ありませんから)。 大きな方が良いですが、 2 GB もあれば大抵は大丈夫でしょう。キャッシュを 保持する期間を長くするとたくさんの領域が必要になりますが、キャッシュへ のヒット率も向上します。しかしあまり長くしすぎるのも良くありません。できれば URL ごとに調整できると良いですね。さらに情報を求める人は、サーバのドキュ メントなどを調べて下さい。 Harvest や Squid などが有名です。 Netscape から出ているものもあるようです。
メールはほとんどすべてのホストで扱われています。しかし大きなメールサー
バはメール配信機能に特化している場合が多いです。メール配送は負荷の大き
なタスクであり、大きなサーバではドライブもネットも速いのに速度が低下す
ることもあります。 Linux の世界では vger.rutgers.edu
にある大きな
サーバがよく知られている例です。
ニュースサーバでは情報が分散しているため、他のマシンからフィードするこ とによってスプールを再構成することができるのに対して、メールサーバは他 とデータを共有しません。したがって安全性が非常に重要となります。大きな サーバを運用している場合は、信頼性を高めるために RAID の導入を考えるべ きでしょう。容量は運用しているメーリングリストの数と購読している読者に より大きく変わります。
ニュースは必要な領域が大きいですが、どの程度になるかは購読している ニュースグループに大きく依存します。 nyx ではほとんど全てのグループ を購読しており、 17 GB 程度を消費しています。 もっとも大きくなるのは明らかに alt.binary.* 以下のグループです。 もしこのグループを購読しなければ 12 GB 程度で良いサービスを提供できます。 しかし小規模なところには 2 GB 程度で「サービスプロバイダ」と称して いるところもあるようです。この程度では expire が非常に早くなって しまうでしょう。こういうところは「サービス」の名に値しないと 言うのが筆者の意見です。
ネットで利用できるサービスは非常に多くの種類がありますが、その多くは WWW の影に隠れています。しかし archie や gopher、 wais と言ったサービスはまだまだ現役かつ有益なツールです。もし手元で大きなサー バを立ち上げるつもりでしたら、これらのサービスについても考えるべきでしょ う。必要な容量を決定するのは難しく、人気と要求頻度に依存します。よいサー ビスを提供するには当然コストが必要で、ディスク容量はその一つに過ぎませ ん。
可能なもの全てを別々のパーティションに分けてしまうことに伴う危険性につ いては、ボリューム管理の節において簡単に紹介しました。しかしこの点はよ り強調しておくべきだというアドバイスが多かったので、もう一度言います: 一度設定したパーティションは使い切ったらそれで終わりで、増やすことはで きません。他のパーティションがいくら余っていてもです。
特にニューススプール(/var/spool/news
)は爆発的に増えることが
あるので注意が必要です。 quota を利用したマルチユーザのマシンでは、
/tmp
や /var/tmp
にも目を配り、ここにファイルを隠す
ユーザがいないかどうかも気をつけましょう(特に .gif
や .jpeg
といったもの)。
実際のところドライブがひとつしかないようなシステムではパーティション分
割はあまり役に立ちません。メリットは df
を使ってファイルサイズのモニタ
が簡単にできること、物理的なセクタ配置を行えることくらいでしょうか。致
命的なのはディスクの並列利用ができないことです。
無料で使えるようなボリューム管理システムが出てくれば、この節の最初で述 べた問題は解決しますが、これはもう少し先のことになりそうです。いろいろ な機能に特化したファイルシステムが出てくれば( 1 ドライブのシステムにお いても)、パーティション分割は有効になるでしょう。
今述べた落とし穴を避ける方法として以下のようなものがあります。スワップ
や /tmp
、 /var/tmp
のように比較的サイズが分かってい
るようなディレクトリに
だけそれぞれパーティションをあてがい、他のものは残ったパーティションに
シンボリックリンクを使って割り振る方法です。
例を示しましょう。遅いディスクと速いディスクがあり、この中に一揃いのシ
ステムを詰め込むことを考えます。スワップと /tmp
は速いディス
クに置き、/home
と /root
は遅いディスクへ置きます。
この作業の後に残ったディレクトリを仮に /a/slow
、
/a/fast
、 /b/slow
、 /b/fast
としましょう。
そして各ドライブの残ったパーティションに対してこれらのディレクトリを割
り振ることを考えます。
/a
と /b
をそれぞれのドライブにあてがってしまうと、
サブディレクトリに
同じ性能が与えられてしまいます。 4 つのディレクトリをそれぞれ別のパー
ティションに分けると、今度は容量に対する柔軟性が失われてしてしまいます。
より良い解法はこれら 4 つのディレクトリをそれぞれ適したドライブのディ レクトリに対するシンボリックリンクとすることです。
具体的には以下のようにします。ここで /mnt/fastdisk
に速いディ
スクの残りパーティションを、 /mnt/slowdisk
に遅いデスクの残り
パーティションをマウントしているものと考えてください。
/a/fast は /mnt/fastdisk/a/fast または /mnt/fastdisk/a.fast へリンク /a/slow は /mnt/slowdisk/a/slow または /mnt/slowdisk/a.slow へリンク /b/fast は /mnt/fastdisk/b/fast または /mnt/fastdisk/b.fast へリンク /b/slow は /mnt/slowdisk/b/slow または /mnt/slowdisk/b.slow へリンク
こうすればスピードが必要なディレクトリは速いディレクトリへおくことがで き、しかもパーティションを 4 つに分割する必要もなくなります。リンク先 として右側のような表現を利用すればファイルシステムの無駄な階層化を防ぐ ことができ、ディレクトリ構造が見やすくなるでしょう。
この方法の欠点はごちゃごちゃしすぎているため、初期段階での計画やセットアッ プには向かないことです。またシステムのインストール前に全てのマウントポ イントとパーティションを決めておかなければならないことも問題かもしれま せん。