検索
連載

第4回：ハードウェアかOSか、それが問題だ――ハードウェアRAIDを監視する：障害発生時の金科玉条

障害発生時にPDに必要なハードウェア関連情報の収集方法を解説する本稿。今回は、ハードウェアRAIDの監視について解説する。

[秋田英行（日本アイ・ビー・エム），ITmedia] PC用表示 関連情報
Share
Tweet
LINE
Hatena

ハードウェアRAIDを監視する

　トラブルの原因がハードウェアにあるのか、それともOSにあるのか見分けがつかないケースを想定し、そのような状況で何を手がかりにPDを進めれば良いのかを前回は解説した。今回は、前回解説できなかったハードウェアRAIDの監視について触れておこう。はじめに記しておくが、Linuxにはカーネルの機能としてソフトウェアRAIDが実装されている。これを利用してRAIDを構築しているケースもあると思うが、サーバ環境で信頼性を求める場合には利用を控えることをお勧めする。なぜなら、わたしがかかわっているビジネス環境でまともに機能しているケースは少ないからだ。まともに機能している例はない、といっても過言ではない。ソフトウェアRAIDを採用したケースでは、主に次のような問題を引き起こす場合がある。

  • Arrayメンバー交換後のリシンク*中にアプリケーションI/Oエラーが発生する
  • OS領域（/、MBR*含む）をArray構成とした場合、リシンク中のOSダウンによってOS領域やMBRが破壊される
  • バッテリーバックアップがないため、OSダウン時にArrayの不整合やデータ破壊が発生する

　もちろん、これらの再現性は使用環境によって左右されるが、ソフトウェアRAIDならではの問題であるため現時点では回避のしようがなく、特に負荷が高くなった状態では前記のような問題が起こりやすい。このため、安定性重視のビジネス環境ではハードウェアRAIDを採用するのが常識となっている。なお、リシンク中のI/OエラーはハードウェアRAIDでも起こり得るが、ハードウェアRAIDのコントローラーは保守を考慮し、リシンク状態でも最低限のI/O保証がされているのが通常である。逆に言うと、リシンク状態でI/Oエラーを返してしまうようなRAIDコントローラーは採用すべきでない。

ハードウェアRAIDの管理/監視ツール

　ハードウェアRAIDはベースボードやRAIDカード、外部ストレージ装置などに搭載されているRAIDコントローラーによってRAID Arrayを制御し管理している。ハードウェアRAIDを監視するには、RAIDコントローラーのデバイスドライバから通知されるメッセージを利用するほか、専用の管理ツールも利用できる。Linuxで利用できるRAIDコントローラーは多く存在するが、例えばIBM eServer xSeriesで採用されているServeRAIDコントローラーでは、タイプに応じた管理マネジャーや管理コマンドが用意されている。このようなツールを利用してハードウェアRAIDを管理/監視するのである。

　ServeRAIDコントローラー向けの管理マネジャーとしては、表1のようなServeRAIDマネジャーと呼ばれるGUIツールが用意されている。ServeRAIDマネジャーではRAIDコントローラーや論理ドライブ、ディスクなどの状態が目視できるようになっており、監視以外にも設定や保守がGUIを通して行える（図1）。

表1
表1　ServeRAIDマネジャー対応表
図1
図1　ServeRAIDマネジャーGUI

　また、各ServeRAIDごとに、コマンドユーティリティも用意されており、ServeRAIDマネジャーがなくともコマンドラインからRAIDコントローラーの状態を確認できる。これらコマンドユーティリティは、それぞれのServeRAIDサポートCDに同梱されている（表2）。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

表2　ServeRAIDコマンドユーティリティ対応表

ハードウェアRAIDの障害例

　例えば、ipssendによって実行例1のような情報が得られた場合、次のような判断が行える。

　まず「Status of logical drive」が「Critical（CRT）」となっているため、障害が発生していることが分かる。次に「Target on SCSI ID 1」の「State」が「De

funct disk drive（DDD）」となっていることから、SCSI IDが1のHDDに障害があることが分かるのである。

　また、この「State」フィールドが「Rebuild（RBL）」となっている場合は、Arrayがリシンク状態となっている。保守の際に多く見受けられるが、I/Oのパフォーマンス低下はこの状態に起因している場合があるため確認を行う。

　そのほかのServeRAIDコマンドユーティリティであるhrconf、aaccli、arcconfはコマンド名こそ違うものの出力するステータスはipssendと同等のため、ServeRAIDのタイプが違っていても管理方法はほぼ同一である。

　このように、ハードウェアRAIDにおいて問題が起こった場合でも、RAIDコントローラーに対応したツールが用意されていれば状態を確認できるのである。また、デバイスドライバについても、RAIDコントローラーの制御状況やエラーなどが詳細にメッセージ出力されるように実装されていれば、ログを通じてRAIDの詳細な情報を確認できる。しかし、Array内の状態をまめにメッセージ出力してくれるドライバは少ない。RAIDコントローラーの採用には、このようなツールの存在を確認しておくことも重要なのである。

まとめ

　前回から2回にわたってOSとハードウェアの関係に注目し、PDに利用できるハードウェア機能に関して記させていただいた。なぜなら、ときにOS側からの視点だけでは進められない問題というのが発生するからだ。例えば、httpdやJava、Samba、NFSなどの挙動に関する現象であれば、OSを含めたソフトウェア的な要因が原因だろう、と想像がつく。しかし、I/O関連のエラーや遅延、システムフリーズ、パニックといった現象では、ハードウェア的な要因が潜んでいるケースも多々あり、Linuxのログだけではその影すら映らないことがあるのが現実である。

　今回述べた機能は特定のハードウェアに特化したものであるが、どのハードウェアでも独自の管理機能を持っているはずだ。もし、ハードウェアかOSか見分けがつかない問題に遭遇しても、OSとハードウェアの双方からアプローチすることを忘れずにPDに挑めば必ず活路は開けるということを述べて締めくくろう。

　次回はPD toolsと題して、LinuxでPDに利用できるツールの紹介と、それらを利用してカーネルによるプロセスの制御状態を把握し、PDを行う方法について述べていく。

コラム：システム管理インタフェース「IPMI」

　IPMIはハードウェア管理を容易にするために作られたオープンなインタフェースである。その仕様は1998年にDell、HP、インテル、NECらによって策定が開始され、同年にバージョン1.0が発表された。

　バージョン1.0以降ではサーバプラットフォームの管理機能に比重が置かれ、バージョン1.5ではリモート管理機能やシステムエラーの自動通知機能、最新のバージョン2.0ではSOL（Serial Over LAN）機能やセキュリティ機能強化、VLANサポートなどが追加されている。実装に関しては現在バージョン1.5が多く用いられているが、IPMIの標準化とアップデートが進むにつれて実装レベルも上がることであろう。

　IPMIのハードウェア実装では、ベースボードに搭載されているデバイスに対してはBMCとそのデバイスや搭載されたセンサーが直接通信することで監視を行う。さらに、ベースボード直下ではないデバイス、例えば接続されているRAIDカードやシステム管理アダプタなどが取得したデバイス状況についても、IPMB（Intelligent Platform Management Bus）と呼ばれる管理ハードウェア用の内部バス経由でIPMI通信を行うことで監視できる。

　また、取得されたSDR（Sensor Data Record、センサー情報）やSEL（System Event Log、イベントログ）、FRU（Field Replaceble Unit、保守交換可能ユニットの情報）などのステータスはNVストアと呼ばれる不揮発メモリに保持されるが、外部からLANやシリアルポート経由でこれらのステータスを取得する際もIMPIが使用される。


*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

このページで出てきた専門用語

リシンク

RAIDを構成するHDDを交換した際などに、交換したHDD内にデータを書き戻してRAIDを交換前の状態まで復元する作業

MBR

Master Boot Record。HDD先頭セクタことブートローダーが格納されているほか、??パーティーションテーブルなどが書き込まれている


本記事は、オープンソースマガジン2006年1月号「Linux PD−問題判別脳力養成道場」を再構成したものです。


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る