RAIDの実現方法
RAIDを実現する方法はRAIDコントローラカードを用いるものと、ディスクアレイユニットを用いるもの、そして専用ハードウェアを利用せず、OSの機能を利用するものに分けられる。
RAIDコントロールカードやマザーボードに搭載されたRAIDチップを利用する場合、あるいはOSの機能を利用してRAIDを構築する場合には、カートリッジを使わずにディスクドライブをケース内に収納して使うこともあるだろう。この場合、障害が発生したディスクドライブを交換するためにコンピュータの電源を切らなければならない。ダウンタイムが発生しても許される用途であれば問題はないが、そうでなければホットスワップできる環境を作る必要がある。
ディスクアレイユニットやRAID 5/6対応NASはホットスワップ可能なカートリッジ式になっているのでこの点を気にする必要はない。
障害発生時に起こりうるトラブル
RAIDを導入すると、ストレージの耐障害性が向上する。しかし、これで安心してはならない。RAID機器やRAIDを実現するソフトウェアごとに、障害発生時の対応手順はマチマチだからだ。そのため、利用しているRAID環境に合わせ、障害発生時の対応手順を決めておかなければならない。災害対策のために防災訓練を行なったり、対応マニュアルを作ったりするのと同様の備えが必要なのだ。
ここでは障害発生時に想定されるトラブルと対策を解説する。
障害の発生に気づかない
ディスクドライブに障害が発生すると耐障害性が低下し、RAID 5などではディスクアクセス速度も低下する。いち早く障害を検知して対策を講じなければならない。
前述のとおり、RAID機器やソフトウェアによって障害発生を通知する方法はさまざまだ。メールなど、ネットワークを介してほかのコンピュータに障害報告を送信する場合は、通知する相手が適切でなければならない。一方、ネットワーク経由では通知できず、ブザーとLEDで障害を通知するものはサーバ設置場所を定期的に巡回する必要がある。
対応できる人員がいない
システム管理とは無関係な部署で独自に運用するサーバなどでは、障害に対応できる人員が少ないことがある。唯一のサーバ管理者が出張中だったりすると悲惨なことになる。万一に備え、電話での指示で作業を行なえるようなマニュアルを整備しておきたい。
障害を起こしたドライブの特定
カートリッジを用いる製品であれば、LEDなどで障害を起こしているディスクドライブをすぐに特定できる。だが、サーバの内部にベアドライブを固定して運用している場合は、エラーログを元に交換するディスクを特定しなければならない。ログに表記されるドライブの名前が物理的にどのディスクドライブに対応するのかを事前に確認しておく必要がある。
故障していないドライブと故障しているドライブを間違えて交換してしまうと、最悪の場合データを全損してしまう可能性もある。こうしたトラブルに陥らないよう、十分注意したい。また、すでに運用しているシステムでトラブルが発生し、物理的なドライブの対応がわからない場合は、ディスクドライブのベンダーが提供しているディスクユーティリティなどを使ってシリアル番号などをチェックするとよいだろう。
RAIDコントローラの故障への備え
RAIDを構成するディスクドライブではなく、RAIDユニットやRAIDコントローラカードが故障する可能性もある。こうしたコントローラ側の故障は、重大なデータ消失につながることがある。RAIDはハードウェアに対する仕様を定義していない。そのため、RAIDユニットやRAIDコントローラが変わると構築済みのRAIDアレイの内容が読めなくなると考えたほうがよい。こうしたことから、同一のRAIDコントローラの予備を用意(コールドスタンバイ)しておくと安心だ。
意外な落とし穴
突発的な障害に対応するときには、多かれ少なかれ誰でも慌てるものだ。事前に対応手順を確認していなければなおさらだ。このような場合、思わぬミスが発覚してトラブルになりやすい。
たとえば、ディスクカートリッジのロックを外す鍵が見つからないとか、見つかったがたくさんあって鍵合わせが面倒だというケースが考えられる(写真4)。キーホルダーなどを活用して、鍵とカートリッジの対応がすぐにわかるようにしておこう(写真5)。また、鍵の保管場所をハッキリさせておくことも重要だ。機材の設置場所のセキュリティが確保できていることが条件となるが、テープなどで鍵をサーバやディスクアレイユニットの筐体に留めておくという方法もある。
また、交換用のカートリッジとディスクドライブを事前に用意しておくのを忘ないでほしい。メーカーから取り寄せるには時間がかかる恐れがあるし、同一のディスクドライブが製造中止になっていて調達できない可能性もある。異なるドライブに交換できる仕様の製品もあるが、障害が発生して交換したら動かなかったというのでは目も当てられない。
(次ページ、「リビルド中のパフォーマンス低下」に続く)
この連載の記事
-
第8回
サーバー・ストレージ
メールサーバからメールが送信されない -
第7回
サーバー・ストレージ
DHCPサーバからIPアドレスが発行されない -
第5回
サーバー・ストレージ
ファイルサーバのファイルが操作できない -
第4回
サーバー・ストレージ
ファイルサーバの文字化けの解消方法は? -
第3回
ネットワーク
ハードディスクのクラッシュに備えよう -
第2回
サーバー・ストレージ
まずはリモートでトラブルの原因を切り分けよう -
第1回
サーバー・ストレージ
管理者の心構えはできていますか? -
ネットワーク
サーバトラブル解決のセオリー<目次> - この連載の一覧へ