手持ちのデバイスを最大限利用するにはどうすればよいかを判断するには、 どんな技術が現在利用可能で、 それらはどのようなものなのかを知る必要があります。 いつものことながら速度や信頼性、能力、柔軟さ、使い易さ、複雑さなどなど、 一長一短があります。
以下に記述されている技術を組み合わせる方法も数多くあり、 性能や信頼性を向上させることができます。 ただし複雑になるという代価も当然生じますが。
この方法は、複数のディスクを並列に使うことによって アクセス時間やデータ転送速度を向上させ、 ディスクシステムの信頼性と速度とを高めようというものです。 チェックサムやミラーリングが信頼性向上の手法として用いられています。 大きなサーバでは有効な方法ですが、 シングルユーザのシステムには過剰な機能でしょう。 既にたくさんのディスクがあるような場合には考慮しても良いかもしれません。 他の文書や FAQ なども見てください。
Linux で RAID を実現するには、 カーネルの md モジュールを使ってソフト的に行なう方法、 Linux でサポートされているコントローラ (PCI-to-SCSI) を使って ハードウェア的に行なう方法、 SCSI-to-SCSI のコントローラを使う方法の三つがあります。 ハード的な方法のほうが高速ですし、 おそらく安全でもあるでしょう。しかしお金もかかります。
Linux で利用できるハードウェア RAID に関するまとめは Linux Consulting で見ることができます。
SCSI-to-SCSI のコントローラは、 通常一つのキャビネットにドライブと一緒に収められており、 コントローラのもう片方の SCSI バスでコンピュータに繋ぐようになっています。 つまりキャビネット全体が一つの大きく高速な SCSI ドライブとして見え、 特別な RAID ドライバは必要としないのです。 欠点としては、キャビネットとコントローラを繋ぐ SCSI バスがボトルネックになることが挙げられます。
巨大なディスクファームを作る人たちにとっての大きな問題は、
/dev ディレクトリに置かれる SCSI ドライブのエントリには
制限があるということです。
このような場合 SCSI-to-SCSI を使えばエントリをあまり消費しないですみます。
通常はフロントパネルから、 あるいはオンボードのシリアルインターフェースに接続した端末から 設定が行えるようになっています。
このようなシステムを作っているメーカとしては CMD や Syred などがあります。 web ページにいくつかのシステムに関する説明があります。
PCI-to-SCSI コントローラは、名前からもわかる通り高速な PCI バスを使うので、 SCSI-to-SCSI のようなボトルネックに悩まされずにすみます。 これらのコントローラには特殊なドライバが必要ですが、 RAID の設定をネットワーク越しに行うような手段もあるので、 管理は単純化できます。
Linux でサポートされている PCI-to-SCSI ホストアダプタの製品ラインアップは、 現在はまだあまりたくさんはありません。
もっとも歴史があり、またもっともラインアップの充実したコントローラは DPT から入手できます。 SmartCache I/III/IV と SmartRAID I/III/IV コントローラのファミリがあります。 これらのコントローラは、 標準カーネルの EATA-DMA ドライバでサポートされています。 DPT のホームページ にも有益な情報があります。製品の情報だけでなく、 RAID や SCSI に関する一般的な解説も読むことができます。
DPT コントローラ用ドライバ (EATA* ドライバ) の著者が書いたページには SCSI と DPT に関するより詳細な情報があります。
DPT のコントローラは最速というわけではありませんが、 長く使われており、その信頼性は証明済みです。
DPT コントローラのメンテナンスツールは、現在のところ DOS/Win でしか動作しません。 したがって小さな DOS/Win のパーティションを作って、 いくつかソフトを入れておく必要があります。 またこの RAID システムを管理するには、 システムを Windows でブートしなければならないわけです。
ごく最近追加されたコントローラのシリーズで、情報は ICP-Vortex にあります。五つの独立したチャンネルをもち、 i960 チップを用いた非常に高速なハードウェアになっています。 Linux のドライバはメーカ自身によって書かれており、 もちろん Linux をサポートすることも表明されています。
ICP-Vortex は Linux 用のメンテナンスソフトウェアを供給しており、 RAID システムの設定や管理に他の OS で再起動する必要はありません。 したがってダウンタイムが少なくて済みます。
つい最近追加されたもので、現在ベータ版の初期段階です。 詳細な情報やドライバは Dandelion Digital's Linux DAC960 Page. から入手してください。
これもごくごく最近追加されたもので、現在 Smart-2 用のドライバはベータリリースの段階です。
IBM は彼らの ドライバ を GPL で公開しています。
普通のディスクとコントローラを使ってソフトウェアで RAID を実現する手法は 多くの OS で可能です。価格コストは低く、 raw ディスク I/O を非常に高速にすることができます。 これは CPU にかかる負荷が極めて大きいので、 導入しようとしているマシンの制限が I/O ではなく CPU にある場合は、 後述するハードウェア的な PCI-to-RAID コントローラを利用するのが良いでしょう。
ソフトウェア RAID とハードウェア RAID との 導入コスト、性能、そして特に信頼性に関する比較は、 非常に古くから続いている話題です。 Linux の信頼性に関しては、現在では非常に優れているとされています。
Linux における現在の ソフトウェア RAID プロジェクトは
md (multiple devices) です。
これは RAID 以外の機能もたくさん備えているので、
後ほどより詳しく紹介します。
RAID には何段階かのレベルがあり、それぞれ異なった機能を持っています。 ここではこれらの内容について簡単に説明します。 Software RAID HOWTO にはもっとずっと詳細な情報があります。 RAID に興味を持たれた方は参考にしてください。
RAID 0 や 1 を他のレベルと組み合わせて使うこともできます。 様々な組み合わせが可能なはずですが、私が見たことがあるのは 2〜3 種類です。 これらは上に紹介した RAID の各レベルよりもずっと複雑なシステムになります。
RAID 0/1 はストライピングと二重化を組み合わせたもので、 非常に速い転送速度とシーク速度、およびデータ冗長性が得られます。 欠点は消費するディスク容量が大きいという点と、 先程触れたようにシステムが複雑になってしまうという点です。
RAID 1/5 の組み合わせは冗長度確保における RAID 5 の優位性と シーク速度における RAID 1 の優位性を組み合わせたものです。 冗長性は RAID 0/1 に比べて改善されますが、 それでもディスク消費はそれなりになります。 このようなシステムは通常 6 台以上のドライブから構成されます。 複数のコントローラや SCSI チャンネルが利用される場合もあるでしょう。
ボリューム管理 (volume management) は パーティションやディスクの容量が固定されていることによる制限を (他に使えるファイル領域がある場合に) なくしてしまうものです。 新しいディスクをシステムに追加すれば、 このドライブの領域をファイルシステムの好きな部分に追加できるのです。 また壊れかけているディスクからデータを別のドライブに移して、 災害を避けたりすることもできます。
Veritas によって開発されたシステムが logical ボリューム管理システムの デファクトスタンダードになっているようです。
現在のところでは、 Linux にはボリューム管理の分野は欠けています。
仮想パーティションシステム (Virtual Partition System) プロジェクトである VPS は、 IBM の AIX システムにあるボリューム管理機能を再実装しようというものです。 しかし残念ながらこのプロジェクトは現在停止しています。
別のプロジェクトとしては Logical Volume Manager というものもあります。 HP のプロジェクトに似たものです。
md カーネルパッチ
Linux Multi Disk (md) はブロックレベルの機能を数多く提供します。 開発の水準は方式によって異なります。
RAID 0 (ストライピング) と concatination (連結) とは非常に安定しており、 製品クォリティと言えます。 RAID 4 と RAID 5 もかなり成熟しています。
いくつかのレベルを組み合せることも可能で、 例えばストライピング (RAID 0) させたドライブ 2 台からなる組を二つ用意して、 それらを互いにミラーさせる (RAID 1) こともできます。 RAID 0 の速度と RAID 1 の信頼性とを組み合せることができるわけです。
RAID に加えて、 md システムではブロックレベルの
ボリューム管理システムを提供しています (アルファレベルですが)。
これはブロックレベルで行われるので、
任意のファイルシステムと組み合わせることができます。
FAT と Wine でさえも利用が可能です。
どのドライブを組み合せればすべてのドライブを並列動作させることができるか、
充分に考えてください。
報酬は性能の向上と故障率の低下と言う形で戻ってくるはずです。
より詳しくは md に付属の文書を読んでください。
...といいたいところですが、残念ながらこの文書は古く、
一部誤っている部分があり、また md の 0.35 版の時代の
古い設定方法についてしか触れていません。
新しいシステムはこの設定方法が非常に異なっており、
そろそろ 1.0 版が出るはずですがドキュメントはまだ不十分です。
こちらを試してみたい場合は、
linux-raid メーリングリストを追う必要があるでしょう。
ドキュメント整備も進行中で、 Software RAID HOWTO も作業中です。
patch for online growth of <tt/ext2fs/ も、昔からありました。
ヒント: うまく動かない場合は、 persistent-block フラグを
セットし忘れていないか確認して下さい。
今のところ最上のドキュメントはソースコードです。
ディスクを圧縮するか、それともファイルを圧縮するのかは、 ファイルを壊してしまう危険性を中心的な争点として、 現在でも活発に議論されている内容です。 新しいものが好きなシステム管理者にはいくつかの選択肢があります。 カーネルモジュール、外部ライブラリへのパッチなど色々な手法が存在しますが、 それらの大部分には書き込み不可といったような各種の制限がまだ残っています。 開発は急ピッチで進められており、 この文書が出るころには間違いなくより高機能なものが出ているでしょう。 常に言えることですが最新版をチェックするようにしてください。 ここにはいくつかのポインタのみを示します。
e2compr は ext2fs に圧縮機能拡張を行うパッケージです。
まだテスト段階で、したがって主に興味を持っているのは
カーネルハッカー達ですが、近いうちに安定し、
広く用いられるようになるでしょう。
詳しい情報は
e2compr homepage
を見てください。
速度も安定性も良好である、というレポートをもらっています。
アクセスコントロールリスト (Access Control List: ACL) は
ユーザによるファイルアクセスをユーザーベースでより細かく管理するものです。
従来用いられてきた所有者・グループ・その他
(ディレクトリリストに出る drwxr-xr-x)
を置き代えることを目的としています。
まだ Linux では利用できませんが、
ext2fs にはすでに開発の足掛りが用意されているので、
カーネル 2.3 では使えるようになるのではないでしょうか。
cachefs
これはハードディスクの一部分を CD-ROM などの遅いメディアのキャッシュとして利用しようというものです。 SunOS で使えますが、 Linux ではまだです。
これは書きこみ時コピーのシステムで、 書きこみデータはもとのソースが置かれていたのとは別のシステムに送られます。 一方で、この書きこみデータは通常のファイル空間にあるように見えるのです。 したがってこのファイル空間はオリジナルのデータを継承することになり、 かつ透過的な書き込みバッファはユーザごとに別々にすることが可能です。
いろいろな応用が考えられます。
SunOS はこの機能を持っており、 Linux でも開発中です。
Inheriting File System (ifs) という古いプロジェクトもありましたが、
これは停止してしまいました。
現在のプロジェクトは md システムの一部となるもので、
ブロックレベルでの透過性を提供しています。
したがってどんなファイルシステムにも適用できます。
Transluent ファイルシステムについての ためになるページ が Sun によって公開されています。
ここで示すトリックは、かつてドライブが遅くて容量も小さかった頃、 そしてファイルの大きさを見てからファイルの実際の配置を決めるような ファイルシステムがもてはやされていた頃、にはとても重要なものでした。 しかし速度が非常に向上し、ドライブやコントローラでのキャッシュが 大きく賢くなった現在ではそれほどの意味はなくなってきています。
しかし今日においても多少の性能向上の余地は残されています。 そして世界制覇が近づいた今日でさえも、 これを早期に達成するにはわれわれは持ち得る全ての技を 使わなければならないのです ！
この手法の意味を理解するためには、現在では失われてしまった知識 「セクタの位置によってディスクの性質がどのように変わるのか」 を理解する必要があります。 ディスクの回転中心から離れたトラックではデータの転送速度は速くなります。 また中間のトラックを起点／終点とするシークは、内側から外側、 外側から内側へのシークよりも速いでしょう。
ほとんどのドライブは一定の角速度で回っており、 また各トラックにおけるデータの線密度はだいたい一定になっています。 これはすなわち、外側のトラックでは内側のトラックに比べて ずっと速い転送が行われるということです。 したがって大きなライブラリなどを置くのに適しています。
最近のディスクでは論理ジオメトリマップを使っているものもあります。 これは実際の物理的なマップ (ドライブそのもののマップ) とは異なっているため、 「真ん中辺の」トラックの見当をつけるのが少々難しくなるかもしれません。
ほとんどの場合トラック 0 は最も外側のトラックであり、 多くの人々がこの仮定を用いています。 しかし、この事には何の保証もないことも心に留めておく必要があります。
セクタの転送速度は遅くなります。 またシークの起点／終点になる場合、シーク動作は遅くなります。
この部分は高い性能を必要としない領域に割り当てると良いでしょう。 たとえば DOS やルートファイルシステム、プリントスプールなどです。
セクタの転送速度は一般に内側より速く、またシーク動作も速いです。
この特性はスワップや /tmp、/var/tmp など、
頻繁に転送要求が来るような領域に適しています。
セクタの転送速度は最も速いですが、 シークタイムは内側と同じように遅くなっています。
ライブラリなどの大きなファイルが置かれる領域を ここに割り当てると良いでしょう。
頻繁にアクセスされるセクタをディスクの中ほどに置けば、
シークの際のヘッドの平均移動距離を下げ、
シークタイムを減らすことができます。
このようにするには fdisk や
cfdisk を実行してパーティションを真ん中あたりに作ったり、
あるいは dd コマンドを使って
ディスク容量の半分ほどの大きさのファイルを作り、
その後に頻繁に使われるファイルを作成する、といった方法があります。
後者の方法では作業後にダミーファイルを消しておきます。
いずれも空のディスクを使い始めるときの方法です。
後者の方法はニューススプールに使うと良いでしょう。 データファイルが置かれる前に、 ディレクトリ構造を中ほどのトラックに置くのです。この作業によって、 多少ですがフラグメンテーションが減る効果も期待できます。
このちょっとしたおまじないは、普通のファイルシステムでも RAID システムでも使えます。 RAID では、真ん中当たりのセクタを計算するのが (不可能とまでは言いませんが) ちょっと難しいかもしれません。 最新の RAID のマニュアルを見てみてください。
この作業によって向上する速度はドライブによって異なりますが、 でも多くの場合 50 パーセント程度の向上が見込めます。
ディスクヘッドの機械的機構 (head disk assembly: HDA) の同じものが、 異なるインターフェース (IDE や SCSI など) で共用されることは良くあります。 したがって機械的な値はだいたい同じになります。 今日ではこの機械的な部分が速度的な限界を決めていますが、 たゆまぬ開発努力によって着々と物事は進歩しています。 さて、ここには二つの主要なパラメータがあります。 それぞれミリ秒 (ms) 単位で記述されます。
ヘッド移動の機構がステッパーモータからボイスコイルに変更されて以降は、 性能の向上は頭打ちになりました。開発のエネルギーは、 現在では事実上回転速度の向上に注力されています。 これによる二次的な効果として、転送速度の向上も期待できます。
以下に典型的な値を挙げておきます。
Drive type
Access time (ms) | Fast Typical Old
---------------------------------------------
Track-to-track <1 2 8
Average seek 10 15 30
End-to-end 10 30 70
非常にハイエンドなドライブでも、 アクセス時間においては平均的なドライブとたいした差がないことがわかります。 ただしステッパーモーターを用いた古いドライブでは、非常に値は悪いです。
Rotational speed (RPM) | 3600 | 4500 | 4800 | 5400 | 7200 | 10000
-------------------------------------------------------------------
Latency (ms) | 17 | 13 | 12.5 | 11.1 | 8.3 | 6.0
待ち時間 (latency) は指定されたセクタに到達するのに必要な時間ですから、 式は非常に簡単で、
latency (ms) = 60000 / speed (RPM)
明らかにこの結果からも、開発努力に対する効果が小さいことがわかります。 しかしここでまるっきり無視した点として、電力消費や熱、 ノイズなどの問題があることも忘れてはなりません。
OS をレイヤー構造として設計することの利点の一つは、
要素の組み合せ方法をいろいろ選べるということです。
例えば CD-ROM を cashefs でキャッシュし、
そのキャッシュは 2 つのドライブから構成し、
さらにこの casfefs ボリュームを translulcent とし、
他のマシンに NFS で公開するようなこともできます。
RAID も何層にも組み合わせることができます。
非常にシークを高速にし、かつ 3 台のディスクが故障しても
継続動作できるようなシステムを作ることも可能です。
組み合わせは無限ですが、想像力の限界か、
あるいは (より重要な要素である) 金銭的な限界によって制限されるでしょう。
選択可能な組み合せは無限ですが、 しかしまずは特殊な機能は使わないで、簡単な設定からはじめましょう。 そして何が必要なのか、 最大の性能が必要とされるのはどの部分かを感じとってください。 ボトルネックになっているのはアクセス時間なのか転送速度なのか、 などをです。次に各コンポーネントを段階的に試してみましょう。 組み合わせの自由度は極めて大きいです。 経験を積んで様々なコンポーネントを 簡単に組み合わせることができるようになりましょう。
RAID を用いるのは通常は良い考えですが、 このテクニックを完全に理解しておくこと、 しっかりしたバックアップをとっておくことを忘れないように。