ハードウェア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）。

拡大図

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

ハードウェアRAIDの障害例

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

                
# ipssend
  ：
  ：
----------------------------------------------------------------------
Logical drive information
----------------------------------------------------------------------
Logical drive number 1
 Status of logical drive    : Critical(CRT)    ←障害が発生
RAID level                  : 1
 Size (in MB)               : 34715
 Write cache status         : Write back(WB)
 Number of chunks           : 2
 Stripe-unit size           : 8 KB
 Access blocked             : No
 Part of Array              : A

Array A stripe order (Channel/SCSI ID) : 2,0 2,1
----------------------------------------------------------------------
Physical device information
----------------------------------------------------------------------
   Channel #1:
    Initiator at SCSI ID 7
   Channel #2:
    Initiator at SCSI ID 7
    Target on SCSI ID 0
      Device is a Hard disk
      SCSI ID                   : 0
      PFA (Yes/No)              : No
      State                     : Online(ONL)
      Size (in MB)/(in sectors) :34715/71096368
      Device ID                 :IBM-ESXSST336753B8553HX0N8RK
      FRU part number           :32P0736
    Target on SCSI ID 1
      Device is a Hard disk
      SCSI ID                   : 1
      PFA (Yes/No)              : No
      State                     : Defunct disk drive(DDD)    ←障害が発生
      Size (in MB)/(in sectors) :34715/71096368
      Device ID                 :IBM-ESXSDTN036C3S29CE3W2ZJPD
      FRU part number           :32P0729
  ：
  ：

まず「Status of logical drive」が「Critical(CRT)」となっているため、障害が発生していることが分かります。次に「Target on SCSI ID 1」の「State」が「Defunct 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が使用されるのです。

上に戻る

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

リシンク

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

MBR

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

参考文献

• IBM Systems
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ハードウェアRAIDを監視する
• まとめ
• コラム：システム管理インタフェース「IPMI」
• このページで出てきた専門用語
• 参考文献
• 著者について
• コメント