パフォーマンスを上げる点から見た場合、データを複数のディスクに「ストライプ」 して分散できます。 つまりブロック 1 は物理ボリューム A に、ブロック 2 は物理ボリューム B に、 ブロック 3 は再び物理ボリューム A に、というようにです。2 つ以上のディスクにも ストライプできます。
この処置をとることで、ディスクのバンド幅が広がるとともに、「スピンドル」が もっと必要になることを意味しています。スピンドルについては後程詳しく説明します。
訳註：スピンドル(spindle)は、ハードディスクを構成する部品の 1 つで、 情報を記録する部品である「プラッター」という磁気媒体を回転させている軸を指 します。つまり「スピンドル」が多ければ多いほど、それだけ平行してディスクに 読み書きができ、全体のパフォーマンスが上ることになります。
パフォーマンスをあげるだけでなく、あるデータを複数ディスク上にコピーして持たす こともできます。これをミラーリングと呼びます。現状の LVM はそもそもこの機能を サポートしていませんが、結果的に実現することが可能です。
ディスクのパフォーマンスに影響を与える要因は、少なくとも 3 つあります。 最も顕著に影響がでるものは、ディスク上のデータを連続して読み書きする速度 です。 SCSI や IDE バス 1 本上に 1 つだけディスクがあり、そこで大きなファイル を読み書きする時には、これはパフォーマンスを低下させる要因となります。
ディスクが利用できる帯域幅は限られています。1 本の SCSI バスに 7 つのディス クを繋げれば、恐らくディスク自体に書き込む速度がバスの速度を越えてしまうで しょう。 お金さえあれば、このボトルネックを根本的に解決できます。
遅延が発生します。よく言われているように、遅延は以前から厄介な問題です。 なお悪いことに、お金を注ぎ込んでも遅延を減らすことができません！ 近頃のディ スクはおおよそ 7 ms の遅延が生じます。SCSI の遅延も、25 ms 程度発生して いました。
FIXME: 最近の値が必要！
これは何を意味するのでしょうか？ 遅延を合算すると、標準で 30 ms 程度の遅延 が発生することになるでしょう。ということは、1 秒当たりわずか 33 回だけしか ディスクに対する操作ができないということになります。 秒当たりに多量の問い合わせしたいのに、キャシュも十分でないとなると、それは 不運としか言いようがありません。
並列に動く複数のディスクか「スピンドル」があれば、同時に複数の命令を実行でき ます。これは遅延の問題を回避する有効な手段です。大規模な news サーバーのよう な用途では、ストライピングか入出力をスムーズに行う別の手段なしには動作すら しません。
これがストライピングの動作です。バスを最大限に使えれば、連続した読み書きも もっと速くなるかもしれません。
ストライピングだけを行うと、「ビット単位」で破壊が起こる危険が出てきます。 ディスクが駄目になると、論理ボリュームの内容がおしゃかになってしまいます。 データを連続して置いてあれば、ファイルシステムの一部だけで済ませられます。
究極の手段は、ミラーリングした上でのストライピングです。
FIXME: LVM と md を使って、ミラーリングした上でストライピングしてみる
訳註：md は、ソフトウエア RAID のデバイスです。 Multi-Disk-HOWTO の日本語訳を参考にしてください。
ストライプ構成の設定は、論理ボリュームの作成時に lvcreate を使って済ませます。 関連するパラメタは 2 つあります。-i でいくつの物理ボリュームに分散させるのか を指定します。実はストライピングはビット単位ではなく、ブロック単位で行われ ます。-I でキロバイト単位で増減の単位を指定をします。注意点は、指定するのが 2 の累乗単位で、 最大 128 KB であることです。
例です。
# lvcreate -n stripedlv -i 2 -I 64 mygroup -L 20M
lvcreate -- rounding 20480 KB to stripe boundary size 24576 KB / 6 PE
lvcreate -- doing automatic backup of "mygroup"
lvcreate -- logical volume "/dev/mygroup/stripedlv" successfully created
同じディスクの 2 つのパーティション上でストライプすると、パフォーマンスが上る どころかおそらく逆効果になってしまうでしょう。- くれぐれもそうしないように してください。1 本の IDE バスに 2 つのディスクを接続してあってもやはり同じ ことが言えます。- 私が知っている IDE より進化していなければ。
FIXME: これは今でも正しいのか？
古めのマザーボードには、2 本の IDE バスがあるかもしれませんが、2 本目は 使い物にならない場合が多く、実質は低速な CD-ROM ドライブを動かすのに使われ ることになってしまいます。ツールを使ってベンチマークを取ることが可能で、 最も気になるツールは「Bonnie」です。ReiserFS の開発者たちは、 Bonnie++ をリリース していて、これでパフォーマンスのデータを計ってもいいかもしれません。
ハイエンドなインテル x86 サーバーの多くには、ハードウェア RAID コントローラ がついています。その内の大部分には、少なくとも 2 つの独立した SCSI チャネル があります。幸いなことに LVM でそれ程苦労せずに利用できます。管理者は RAID コントローラ自身の機能を使って論理ドライブの構成を決めてから、Linux で RAID コントローラを通してディスクを認識させなければいけません。たとえば SCSI チャネル A 上の 2 つのディスクでストライプを行い、そのミラーを SCSI チャネル B 上の 2 つのディスク にしたとします。これは典型的な RAID 0/1 の構成で、 パフォーマンスとデータの安全性を最大限引出します。この構成のマシンで Linux をブートすると、RAID コントローラ上にある 1 つのディスク上にだけ、データ領域 があるように「見えます」。これこそが、 4 つのディスクで構成した RAID 0/1 の 論理ドライブなのです。 つまり LVM から見る限り、マシンはあたかもディスクを 1 つだけ備えていて、1 つ のディスクを扱うように使用できます。ディスクの 1 つが壊れても、LVM はそれを 知るよしもありません。管理者がディスクを交換しても(ホットスワップ機構を使って、 稼働中に)、LVM はそれを検知しないだけでなく、コントローラはミラーされている データを再同期させて、すべて元通りにします。 ここでたいていの方はちょっと考えてから、「RAID コントローラを LVM と併用する と何がいいのだろう？」という疑問が湧きます。 簡潔に説明すると、次のような答えになります。RAID コントローラの元で論理 ドライブを決定してしまうと、そのドライブに対して後でディスクを追加することは できなくなります。空きをどのくらい取るかの計算を間違ってしまったり、単にもう 少し空きが必要になった場合にも、新しいディスクがいくつであれ、既存のストライプ 構成には追加できません。つまりそのコントローラの元で、新しい RAID のストライプ 構成を作成しなければいけません。そこで LVM を使っていれば、ただ LVM の論理ボリュームを拡張すればいいだけなので、RAID コントローラの元で新旧 のストライプ構成をスムーズに拡張できます。
FIXME: このテーマに追加することはあるか？
Linux 2.4 にはとても素晴らしい RAID がきちんと使える状態でついてきます。 Linux 2.2 にはデフォルトで Alan Cox 氏がリリースした初期バージョンの RAID 機能がついていますが、出来があまりよくありません。2.2 がまだこの初期のリリース を採用している訳は、カーネルの開発者が Linux の安定版でユーザランドのアップ デートをともなう変更を望まなかったためです。
Red Hat や Mandrake、SuSE をはじめとするディストリビュータの大部分は、素晴ら しい出来になると思われるバージョン 0.90 に置き換えることを決めました。
ここではバージョン 0.90 だけをを扱うことにします。
FIXME: ここに更に書いてください。