![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
前回の記事では、Linux 2.4 Software RAIDの機能を紹介し、リニア、RAID-0、およびRAID-1ボリュームの 設定方法を説明しました。今回の記事では、実稼動環境での可用性を高める目的でRAID-1を使用する際に、理解しておくべき事柄について説明します。上記の目的でRAID-1を使用する場合は、RAID-1をテスト・サーバーで使用したり 自宅で使用したりする場合よりは、より多くの理解がを必要です。とりわけ、ディスクに障害が発生した時にRAID-1が保護できるのは何かという事と、その場合どのようにしてRAIDボリュームをダウンさせずに稼動させ続けるかについて、正確な理解が必要です。今回の記事では、これらのトピックについて説明します。まずRAID-1、4、および5で実現できる事と実現できない事について説明します。最後に障害を起こしたRAID-1ドライブの交換の本番さながらのシミュレーションを説明します。ドライブの交換については、可能であれば実際にやってみてください（この解説を ガイドとして）。このシミュレーションを実際に行ってみると、実環境でRAID-1ドライブの障害を処理 するために必要な経験を、すべて手にすることができます。
RAIDが持つ耐障害性機能は、自然発生的なドライブ全体の障害が及ぼす負の衝撃から、ユーザーを保護するように設計されています。これは有用なものです。しかしRAIDは信頼性の問題すべてに対する完璧な解決策 ではありません。実稼働環境に、RAID (1、4、5) を用いて耐障害性を向上させようとする場合は、RAIDで実現可能な事と実現できない事を事前に正確に理解しておくことが極めて重要です。RAIDを用いて環境を整備しようとする場合、RAIDで実現できない事を行おうとしてはなりません。まず、RAID 1、4、5について、流布している”神話”を払い除けることから始めましょう。
重要なデータをすべてRAID 1/4/5ボリュームに入れておけば、恒常的なバックアップは行わなくても良い、と多くの人は考えています。これはまったくの誤りです。その理由は以下に述べます。RAID 1/4/5は、偶発のドライブ障害に起因する予定外のダウン時間 については、防御してくれます。しかし、RAID 1/4/5は、悪意を持って行われるデータ破壊 については、全く無防備です。RAIDボリュームのルートとして "cd /; rm -rf *" と入力すると、きわめて重要な膨大な量のデータがほんの数秒で失われてしまいます。結果として、10台ものドライブを持つRAID-5の構成は何の価値もない存在になってしまいます。さらに、RAIDはサーバーが盗難にあって持ち去られた場合や ビルに火災が発生した場合には、何の手助けもしてくれません。また、バックアップ・ストラテジーをインプリメントしていない場合にも、ユーザーには当然保存された過去のデータはありません。オフィス内のだれかが、重要なファイルのいくつかを削除してしまった場合にも、それらを回復する手段はないのです。これだけ述べただけで、ほとんどのケースにおいて、バックアップ・ストラテジーを計画し、インプリメントする必要があることが十分お分かりになったと思います。しかも、計画しインプリメントするのはRAID 1、4、または5への取り組みを 考慮する前 であることが必要です。
別の誤りは、Software RAIDを低品質のハードウェアで構成されている システム上にインプリメントすることです。この場合、重要な処理を行わせるサーバーも一緒に使用するのであれば、予算の範囲で無理なく入手できる高品質のハードウェアを購入することは、道理にかなっています。ユーザーのシステムが不安定であったり不当に非活動状態に置かれている場合は、RAIDでは解決できない問題が生じます。同じような内容ですが、RAIDは電源異常の場合には 明らかに使用可能時間を延ばすことはできません。サーバーで比較的重要度の高い業務を実行する場合は、サーバーに無停電電源装置 (UPS) がインストールされていることを確認してください。
次はファイル・システムの問題点を取り上げましょう。ファイル・システムは、Software RAIDボリュームの「最上部」にあります。このことは、Software RAIDを使用する際は、ファイル・システムの問題 から逃れることはできないことを意味します。ファイル・システムの問題とは、たとえば、ジャーナル処理されていないファイル・システムまたは非常に特異なファイル・システム を使用する場合に、長くかつ潜在的に問題を含むfsckが発生するなどです。このため、Software RAIDはext2ファイル・システムの信頼性を これ以上高めようとはしません。これが、Linuxコミュニティーでは、作業の中にJFSおよびXFSに加えてReiserFSが含まれていることが大切である理由です。Software RAIDと、信頼性の高いジャーナル処理ファイル・システムとは、組み合わせとしてはすばらしいものです。
前節の説明でRAIDについての明確な理解を持っていただけたでしょうか。RAID-1、4、または5をインプリメントする際は、ユーザーがこのテクノロジーを、使用可能時間 を増加させる手段として理解することがきわめて 重要に なります。ユーザーがこれらのRAIDレベルのどれか1つをインプリメントする場合、非常に特殊な状態に対しては、自分で防御手段を講ずることになります。特殊な状態とは、自然発生的な、ドライブ全体（単一のドライブでも複数の ドライブでも）にわたる障害の発生です。この状態が発生すると、ユーザーが障害を起こしたドライブを新しいドライブ に置き換える処理を行う間、Software RAIDは、システムが実行中の作業を継続できるようにしてくれます。すなわち、RAID 1、4、または5をインプリメントすれば、ドライブ全体にわたる障害に起因する、長時間の予期しないダウン時間が 発生するリスクを小さくすることができるのです。長時間のダウン時間の代わりに、予定された短時間のダウン時間があればよいのです。つまり、障害ドライブを置き換えるためのダウン時間だけで済むのです。これは以下のことを明確に示すものです。すなわち、可用性の高いシステムを持つことに高い優先度がない場合は、Software RAIDをインプリメントするべきではありません。ただし、Software RAIDを主としてファイル入出力のパフォーマンス向上のため に使用したい場合は話は別です。
賢明なシステム管理者はSoftware RAIDを特定の用途に使用します。つまり、すでに高い信頼性を持っているサーバーの信頼性をさらに高める ために使用するのです。賢明なシステム管理者であれば、以下のような基本的事項については、すでに完了させていることと思います。企業の組織を災害から保護するために、定期的なバックアップ計画をインプリメントしました。サーバーをUPS (無停電電源装置) に接続し、UPSにソフトウェアの立ち上げと実行をモニターさせるようにしました。これにより、サーバーは大規模の電源異常の際にも安全にシャットダウンする ことができます。ファイル・システムの信頼性とパフォーマンスを向上させるためには、ReiserFSのようなジャーナル処理ファイル・システムを使用する場合もあります。サーバーには適切な非活動状態が与えられ、かつサーバーが高品質のハードウェア で構成されていて、さらに、セキュリティーの諸問題には十分な配慮が払われています。さて、今こそSoftware RAID-1、4または5をインプリメント することを考慮すべき時です。Software RAID-1、4または5を インプリメントすれば、サーバーはドライブ全体に及ぶ障害から保護され、これによりサーバーの使用可能時間は数パーセント向上する可能性があります。Software RAIDを使用すると、サーバーには保護層がさらに追加されたことになり、すでに整っているサーバーの保護体制をさらに強固なものにします。
RAIDの持っている機能と持っていない機能についてこれまで説明しました。今必要なのは、先のことを適切に予期し、そのための正しい行動をとることです。このセクションでは、ディスクの障害をシミュレートするプロセスと、次にRAIDボリュームを低下モードから抜け出させるプロセスのあらましを 説明します。テスト・マシンにRAID-1ボリュームをセットアップし、説明に従ってください。このシミュレーションは、楽しむこともできます。今少しでも面白いと思えばそれだけ、実際にドライブに障害が起きた場合には冷静さを保つことができ、何をなすべきかを正確に知ることができるのです。
まず最初にRAID-1ボリュームのセットアップを行います。どのようにするのかを思い出すためには、（前回の記事） を参照してください。このテストを実行するには、1台のハード・ディスクの電源プラグを抜いた状態でも、Linuxシステムをブート できるように、RAID-1ボリュームをセットアップすることが極めて重要です。というのも、このやり方が、ドライブの障害をシミュレートする際に行うことだからです。
ボリュームのセットアップが終了し、/proc/mdstat をカタログすると、コード・サンプルのように表示されます。
ここではdevfsを使用していることに注意してください。これは、上で示したように極端に長い装置名が使われているからです。実際にRAID-1ディスクには /dev/hda5および /dev/hde1を使用します。この場合Software RAIDのカーネル・コードはドライブを同期化するので、ドライブはお互いに相互の正確なミラーとなります。RAID-1ボリュームがこの状態に到達すれば、先へ進んでボリューム上にファイル・システムを作成し、そのファイル・システムを 適切な場所に装着することができます。ファイル・システムにいくつかのファイルをコピーし、次に、/etc/fstabをセットアップして、ボリューム (/dev/md0) をシステムのブート時に 装着できるようにします。ここに示すのはfstabに追加した行です。ユーザーがこれを行う場合は少し異なるものになるかもしれません。
/dev/md0/mnt/raid1reiserfsdefaults0 0 |
さて、ドライブの障害をシミュレートするための大部分の準備が終わりました。しかしまだ準備は完全ではありません。まず、/proc/mdstat を再度カタログし、ボリュームのディスクがすべて同期化されるまで待機します。同期化されると、/proc/mdstat は、コード・サンプルのように表示されます。
再同期化が完了し、シミュレーションの準備が整いました。先へ進みましょう。マシンをシャットダウンし、電源をオフにします。次に、マシンをオープンして立ち上げ、RAID-1アレイを形成するハード・ディスクの中の1台のプラグをはずします。もちろんのことですが、Linuxのルート区画を入れてあるディスクのプラグは、外さないでください。Linuxは、後で再度ブートする必要があるからです。これでハード・ディスクのプラグが外れました。マシンのバックアップを始めましょう。ログインを行った後で、/dev/md0が装着されていること、およびこのディスクが使用可能であることを確認してください。/proc/mdstatをカタログすると、主な変更が表示されます。
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid5]
read_ahead 1024 sectors
md0 : active raid1 ide/host0/bus0/target0/lun0/part5[0]
4610496 blocks [2/1] [U_]
unused devices: <none>
|
これで、/dev/md0ボリュームが低下モードで実行されていることが分かります。前に、ドライブ /dev/hdeのプラグを外してあるので、カーネルがブートし、アレイを自動開始しようとしても /dev/hde1は検知されませんでした。幸いにも、カーネルは /dev/hda5を検知したので、/dev/md0は低下モードで始動することができました。表示されているように、/dev/hde1区画は /proc/mdstatの中にはリストされておらず、RAIDディスクの1つに「ダウン」 ("[UU]" ではなく "[U_]") の マークが付けられています。/dev/md0がまだ実行中なので、Software RAID-1は行うべき作業として、データを使用可能にします。
今まさに、シミュレートされたドライブ障害を体験しているところです。このドライブが、現在は電源が切断されており、それはシステムの実行中に実際に障害が 起こったためであるとすれば、この状態こそが発生させたかった状態なのです。RAID-1ボリュームは低下モードで実行され、これにより、そのボリュームは冗長度がまったくないとはいえ、なお使用可能な状態です。都合の良い時間に、システムをシャットダウンし、障害の発生したドライブを置き換え、システムを再度立ち上げてください。RAID-1ボリュームは、この時点でもなお低下モードで実行されています。
マシンに新規のドライブを入れた後では、新しいディスク上に適切なサイズの RAID自動検出 ("FD") 区画を生成する必要があります。Linuxがディスクの 区画テーブルを再読み取りできるようにするためには、リブートをもう1度 行う必要があります。新規の区画がシステムに利用可能になると、低下モードのRAID-1アレイを 復元する準備が整います。この場合は、いくらかの冗長度は許されています。
もちろん、今はシミュレーションを実行しているだけです。RAIDアレイにもう一度 区画を1つ加えるには、2つの方法のどちらかを行いますが、これはユーザーがどのようなシナリオを準備しておくかにより異なります。第1の方法は、ユーザーはマシンをシャットダウンし、ドライブのプラグを接続し、ブートしてオンにし、古い区画をアレイに戻すもので、第2の方法は、マシンをシャットダウンし、ドライブのプラグを接続し、ブートして立ち上げ、ドライブの内容を消去し、アレイ（もちろん、適正なサイズのもの。少なくとも置き換えの対象の区画と 同じサイズのもの）を追加するために、新規 RAID自動検出 ("FD") 区画を作成し、さらに、この最新の区画をアレイに追加するものです。2番目の選択は、実際のドライブの障害時に起こる事態に近いものですが、最初の選択は、ディスク・コントローラーの障害またはケーブル状態不良の 場合などをシミュレートしています。この場合は、ミラー・ドライブの どちらか1つは一時的に選択不可になり、その結果 /dev/md0が低下モードで実行され、障害から回復した後には区画の1つをボリュームに再度加える必要が生じます。どちらのシミュレーションを選択して実行する場合でも、「修復」は同じように行われます。新規の区画が作動可能になった後は、手作業でその区画を /dev/md0ボリュームに再度加える必要があります。
区画をアレイに再度戻す前は、カーネルのブート・メッセージを表示するよい機会です。"dmesg | more" と入力すると、カーネルのブート・メッセージを表示できます。このコード・サンプル と同じような 一連のテキストが表示されます。
この機会にこれらのメッセージを詳しく読んで見ましょう。これらのメッセージを読むことにより、カーネルが /dev/md0を自動開始する プロセスを理解できるし、Linux Software RAIDの内部で行われている 作業についての価値ある洞察も得られるのです。上に挙げたカーネルの出力を読むと、カーネルは /dev/hda5および /dev/hde1は見つけましたが、hde1はhda5と同期していないことが分かります。カーネルは、/dev/md0を低下モードで始動させ、この時に /dev/hda5を使用しましたが、/dev/hde1はまったく使用していません。さて、オリジナルの（または、新規に作成した）区画をボリュームに追加しましょう。以下にその方法を説明します。
まず、置換用の区画が新しい装置名を持っている場合は、その新しい情報が反映されるように /etc/raidtabを更新してください。次に、新しい区画を以下のコマンドを使用してボリュームに追加し、/dev/hde1を区画の追加先デバイスのデバイス名と置き換えます。
# raidhotadd /dev/md0 /dev/hde1 |
再構成が開始されると、ハード・ディスクのライトが点燈します。先へ進み、/proc/mdstat をカタログし、 現在進行中のRAID-1の再構成の状況を検査します。
数分のうちにRAID-1ボリュームは、正常な状態に戻ります。
御覧なさい。これでドライブのシミュレートした障害から正常に回復し、実稼働環境でRAID-1を開始する準備ができました。今こそ、お手製の「RAID-1終了証」シールを額に貼り付け、両手を振り回してオフィス中を駆け回り、同僚たちと喜びを分かち合うこともできます。でもこれは、それほど大したことではないのかもしれません。ではまた次回に。
- Daniel氏のRAIDについてのシリーズの 第1回 をお読みください。この中では、Linux 2.4のSoftware RAIDの機能が紹介されており、またリニアRAID-0およびRAID-1ボリュームのセットアップ方法も示されています。
- raidtools-0.90の更新版については、
people.redhat.com にアクセスしてください。
- The Linux Kernel Archivesのrecent kernel の項を調べてください。
-
latest version of raidtools を読んでください。
-
more tips on Software Raid solutions for Linux を調べてください。
ニューメキシコ州のアルバカーキーに住む Daniel Robbins は、Gentoo プロジェクトのチーフ・アーキテクトであり、かつ Gentoo Technologies, Inc. の CEO であり、かつ Linux Advanced Multimedia Project (LAMP) のよき助言者です。彼は、マクミラン・ブックCaldera OpenLinux Unleashed、SuSE Linux Unleashed、およびSamba Unleashed の著者です。Daniel は、小学校 2 年生のころから曲がりなりにもコンピューターにのめり込み、当時彼は、危険性を潜めたパック・マンのほか、Logo プログラム言語にも初めて出会いました。これで、彼がなぜ、それ以来 SONY Electronic Publishing/Psygnosis のリード・グラフィック・アーティストを務めているかが分かるでしょう。Daniel は、奥さんの Mary（今度の春に出産の予定です）と一緒に時間を過ごすのが楽しいそうです。彼の電子メール・アドレスはdrobbins@gentoo.org です。
