レベル: 初級 秋田 英行, 日本アイ・ビー・エム
2007年 4月 20日 I/O関連のトラブルやカーネルパニックなどの原因にハードウェアがかかわっているのは多々あることです。しかし、実際にそのような状況に直面した場合、どのように原因を探れば良いのでしょうか。今回から2回に分けて、PDに必要なハードウェア関連情報の収集方法について解説していきましょう。
ハードウェアかOSか、原因はどこにある？
いままでに直面した問題の中で、その原因がハードウェアにあるのか、それともOSにあるのかと頭を抱えたことはないでしょうか。
例えば、「新しく用意したUSBデバイスが正しく認識されない」とか、「RAID Arrayにディスクを追加するとパフォーマンスが落ちる」、「メモリ構成を変えたら不安定になった」、「システムの稼働中にNMI*によってリブートされた」、「外部ストレージが正しく認識されない」、「外部ストレージ領域でI/Oエラーが発生する」など、ハードウェアが原因と思われる現象に遭遇した人も少なくないはずです。このようなケースに直面し、OS側からのアプローチを行ったが何も見いだせず、ただ時間が経過していくだけのいわゆる「ハマッた」状況に陥った方もいるかと思います。
そこで、今回はトラブルの原因がハードウェアにあるのか、それともOSにあるのか見分けがつかないケースを想定し、そのような状況で何を手がかりにPDを進めれば良いのか、幾つか述べていきましょう。
ハードウェアとOSの境界線
まず、このようなケースは最も厄介で、PDが難しいということをはじめに言っておきます。例えば、再現性の確認などはハードウェアを考慮した組み合わせで検証を進めなければなりません。BIOS、ファームウェア、デバイスドライバ、カーネルなどのすべてに対し、それぞれのバージョンによる組み合わせを考慮する必要があるということです。そのため、問題点を絞り込むまでに多大な時間を要してしまいます。
通常、ハードウェアにも疑いを向けるケースではパーツを手当たり次第に交換して様子を見る、といった対応が思い浮かぶでしょう。この場合、NIC、RAIDカード、ディスクといった末端のデバイスだけではなく、メモリ、CPUなどのコアなパーツ、さらに、ときにはベースボード*も交換の対象となることがあります。しかし、単に現象を見ただけでパーツ交換を行うのであれば「経験」や「勘」に頼るだけとなってしまい、そこで現象が収まらなければ再度別のパーツを交換することになります。やってみて吉と出るか凶と出るか、といったところですが、得てして吉と出る方が少ないため、結局時間が掛かることとなってしまいます。
トラブルの原因はバージョンレベルの不整合
ハードウェアかOSかといったケースでは、その原因の多くはBIOS、ファームウェア、デバイス本体、デバイスドライバ、カーネルなど、ハードウェアの構成要素における不具合や、それぞれが前提とするバージョンレベルに不整合があることなどに起因します。例えば、ファームウェアの不具合はデバイスドライバの挙動に影響し、当該のデバイスにアクセスしたタイミングで想定された動作が行われなくなります。また、バージョンの不整合といったものも存在します。一般にデバイスドライバには、対応するファームウェアやカーネルのバージョンが前提条件として定めてあり、その前提条件が保たれていない場合、動作に支障が発生します。特に、ベンダー提供のデバイスドライバなどではそのような前提条件が定められていることがあります。通常この前提条件は添付のreadmeファイルなどに明記されているため、注意を怠らなければこのようなことは起こらないはずですが、前提条件不足で問題になるケースは意外に少なくありません。デバイス関連のエラーやそれによって引き起こされる問題が発生した際には、まずこの前提条件を調査することを怠ってはなりません。
デバイス操作の仕組み
基本的ではありますが、図1はOSがデバイスを操作する仕組みを示したものです。
まず、簡単に言えばBIOS/ファームウェアはハードウェア側で動き、デバイスドライバはOS側で動きます。デバイスドライバとBIOS/ファームウェアとのアクセスは、ハードウェアとOSがそれぞれ持つアドレステーブルを利用します。OSが持つアドレステーブルは各デバイスに割り当てられており、デバイスドライバは割り当てられたテーブルを通じて対応したファームウェアと通信をします。それに応じてファームウェアがハードウェアを制御することで、デバイスは動作することになります。
図1. カーネルがデバイスを操作する仕組み
つまり、ハードウェアかOSかという境界線は、BIOS/ファームウェアとデバイスドライバの間にあり、それを境にPDすることになります。問題が起きた場合これらを切り分けるポイントとしては、OS側からだけのアプローチではなく、同時にハードウェア側からもアプローチすることに尽きるのです。ハードウェア側からのアプローチにはハードウェアの持っている機能を利用するため、PDの際はハードウェア管理の領域にも足を踏み入れることになります。
システム管理プロセッサを活用する
ハードウェア関連のエラーの場合、OSが稼働している状態であればエラーメッセージがデバイスドライバ経由でOSに送信され、syslogdによって/var/log/messagesにログが残されます。また、ハードウェア障害が発生した場合、ハードウェア自体がハードウェア内にエラーログを残す場合もあります。ただし、記録されたハードウェアエラーログは、一般的にはBIOSから確認できるものの、単にイベント名が残るだけで詳細はなく、これだけではハードウェアのどこに不具合があったのかは知るよしもありません。加えて、OSが停止してしまうようなハードウェア障害の場合、エラーメッセージがsyslogdに通知される以前にシステムダウンしてしまうケースが多いため、このような場合では何が起こったのか判断する手段がないも同然となってしまいます。
こういった不測の事態に対応するため、最近のサーバ製品にはハードウェアを監視する仕組みが組み込まれています。この仕組みはシステム管理プロセッサ*などと呼ばれており、ハードウェアとしてベースボード上に実装されています。IA系*に搭載されるシステム管理プロセッサには、大きく分けるとBMC*とISMP*の2種類があります。
これらのシステム管理プロセッサは、CPUとは独立した専用プロセッサによってハードウェアの状態を常時監視し、記録しています。例えCPU障害によってシステムがダウンしたとしても、電源供給さえあれば黙々と監視を続けているのです。そのため、ハードウェアで問題が起きた場合、OSのログが残っていなくともシステム管理プロセッサにアクセスすることで原因を明らかにできるのです。
BMC/ISMPによるシステム監視
BMCやISMPの監視対象としては、ファン、電源電圧、SCSI HDD、温度、CPU、メモリがあり、これらで発生したエラーやワーニングといったイベントが記録されます。また、製品によってはCPU、メモリ、ファンのPFA*などもこの対象となります。ただし、残念ながらPCI-Xバスに接続されたRAIDカードやNICといった末端のデバイスはこの対象ではありません。
BMCでハンドリングされたイベントは、BIOSメニューやLAN、シリアルポート経由で確認できます。例えば、BMCが搭載されているシステムであればBIOSのメニュー内に「BMC System Event Log」といった項目が用意され、そこから図2のようなログを確認できるはずです。この例では、「Entry Details」内に「Power supply AC lost」とあるため、電源に異常が発生したということが分かります。
図2. BMCによって記録されたイベントの例
BMCがハードウェアを監視し、そのステータスをメッセージ化して管理する仕組みはIPMI*によって定義されています（コラム参照）。IPMIはメッセージイベントを送受信するためのインタフェースであり、IPMIの仕様に基づいたアクセスを行うことによってLANやシリアルポートを経由したメッセージ出力が可能です。そのため、BMCが搭載されているシステムではオンボードのLANポートやシリアルポートを利用してリモート管理が行えます。ただし、リモート管理を行うには管理用のシステム上にIPMIアクセスが可能な管理ソフトが必要です。このような管理システムとBMC搭載システム（監視対象システム）の管理ポート間を接続して管理を行う構成はBMCの特徴の1つであり、アウトオブバウンド*構成と呼ばれています（図3a）。
なお、管理ソフトがIPMIに対応してない場合には、管理対象システムに専用のデバイスドライバや管理エージェントをインストールして管理を行う構成となります。この場合のリモート管理には、当然管理対象システムのOSが稼働していることが条件となります（図3b）。OSの稼働に依存せずリモート管理を行うには、IPMIに対応した管理ソフトウェアか、別途システム管理プロセッサを搭載したアダプタカードを搭載する必要があるということです。
一方、ISMPではハンドリングしたイベントがメッセージ化されないため、BIOSメニューでイベントログを見ても分かりづらいかもしれません。さらに、IPMIのようなインタフェース実装がないため、ISMP単体ではリモート監視が行えずローカルシステムのみで管理する構成になります（インバウンド構成）。ただし、別途システム管理プロセッサを搭載したアダプタカードを追加すればISMPでもリモート管理は可能です（図3c）。
図3 BMCによるアウトオブバウンド構成
拡大図
コラム：システム管理インタフェース「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が使用されます。
リモート管理ソフトウェアによるハードウェアエラーの監視
それでは、リモート管理ソフトウェアによってハードウェアエラーを監視する例をIBM eServer xSeriesとIBM Directorを使って見てみましょう。
IBM eServer xSeriesにはBMCが搭載されており、無償で同梱されているIBM Directorという管理ソフトによってリモート監視が行えます。また、専用のシステム管理アダプタであるRSA II*を搭載している場合は、BMCとRSA II間で通信が行われ、BMCで感知されたエラーはIBM DirectorにRSA IIの管理ポート経由でイベントログとして通知されます。RSA IIを搭載していない場合は、BMCの管理ポートを利用することで同様にエラーをIBM Directorに通知できます。もちろんこれらの構成では、OSの稼働状況に依存せずにハードウェア監視を行えます。さらに、OS上で動作するエージェントと呼ばれるソフトウェアを通じてCPUやメモリ、ディスク使用率などの情報取得やプロセス管理などを行うこともできます。この場合、エージェントとBMC間はインバウンドで通信を行っています。
このように、IBM DirectorではBMCからIPMIによって通知されるメッセージを直接もしくはエージェント経由で受け取り、リモートからハードウェアを一元管理できるのです。PDにおけるハードウェア側からのアプローチでは、このような仕組みも利用することになります。
さて、IBM Directorの機能全般やその詳細な話は今回のテーマとは離れるため割愛しますが、IPMIによってどのようなハードウェアエラーを検知できるのか、どうPDに利用できるのか、といったことを幾つか解説していきましょう。
ファン障害
図4はファン障害に関するエラー通知の例です。画像では確認しづらいかもしれませんが、このイベントログでは、以下のような時系列でファンに関するエラーを確認できます。
図4. ファン障害の発生例
 | |
PM2:12:56 ファンに関する問題があるというアラート通知が入る
PM2:14:15 ファンのセンサー値が「致命的ではないが、注意が必要なレベル」を超える
PM2:14:18 ファンのセンサー値が「致命的なレベル」を超える
PM2:14:22 ファンのセンサー値が「復旧不可能なレベル」を超える
|
|
ここで、ファンのセンサー値はCPUファンの回転数を示しており、最終的にファン停止状態となっています。この場合、放置すればCPUが温度上昇によって熱暴走してしまうため、通常は温度センサーが温度の上昇を感知し、システムが自身を停止する動作を行います。この際、LinuxカーネルはNMIハンドラによってカーネルパニックを発生させますが、Linuxのログにはファン障害や温度異常を確認できるメッセージなどは記録されません。つまり、Linuxのログだけを頼りにしていたのでは何が問題となったのか解明できないのです。
電圧障害
図5は電圧障害に関するエラー通知です。なお、若干画面の表示形式が変わっていますが、表示設定を変更しているだけでインタフェースとしては同じになります。
この例では、14:54:30から14:54:52にかけて電圧に関するエラーが発生していることが確認できます。図5では14:54:38に発生した電圧エラーについてその詳細を表示させています。それによると、「SENSORLABEL」が「CPU1 VCore」であることから、CPU1の電源電圧に致命的な問題が発生していることが分かります。
図5. 電圧障害の発生例
拡大図
電圧に関する問題としては、システム中の電源モジュール異常がまず思い浮かびますが、まれに電源供給元環境の問題が原因で発生する場合もあります。例えば、配電盤からの電圧不足やタコ足配線による電圧の減衰などもその要因となります。
このとき、「電圧不足によってシステムが起動しない」というのであれば現象は明確で分かりやすいのですが、「電圧不足のためCPUがスペックどおりの周波数で動作しない」といった現象も起こり得ます。この場合、発現する現象としては「想定されているパフォーマンスが出ない」といったものになります。このような場合も、Linuxは電圧異常に関するメッセージをログに残さないため原因を解明しづらいのです。
これらはハードウェアエラー検知に関する例の一部ではありますが「OSだけでは問題の原因が判断できない場合、ハードウェア側からもアプローチを行うことでPDが容易になる」ということを理解していただけると思います。
OS上でのログの記録／確認
IBM Directorでは、監視対象システムにIBM Directorエージェントを導入することで、OS上でハードウェアログを記録するSystem Healthという機能が利用できます。これは特定の機種でのみサポートされる機能なのですが、SNMPトラップ*をログに記録したり、/var/log/messagesにハードウェアエラーイベントを記録できます。これによってOS上からもハードウェアエラーログを確認することが可能となります。また、BMCやIPMIでハンドリングしたエラーをログに記録することもできるのです。リスト1、2、3はSystem Healthによって記録された電源障害、RAID障害、ファン障害といったログの一例です。
リスト1 電源障害発生時のログ
Jul 22 12:52:05 x345-linux Director Agent: PowerSupply device identified as
PowerSupply 1 reports critical state with possible loss of redundancy.
|
リスト2 RAID障害発生時のログ
Jul 22 13:50:10 x345-linux Director Agent: ServeRAID: Logical drive is critical:
controller 1, logical drive 1
Jul 22 13:50:15 x345-linux Director Agent: ServeRAID: Defunct drive - I/O
subsystem error: controller 1, channel 1, SCSI ID 0 (FRU Part # 06P5778)
|
リスト3 ファン障害発生時のログ
Jul 22 13:59:41 x345-linux Director Agent: Fan Sensor 8 fell below threshold of
664 RPM. The current value is 0 RPM
|
リスト1の電源障害に関するメッセージでは、パワーサプライ（電源装置）1に障害が発生し、電源の冗長性が失われた状態になっている*ことが分かります。
リスト2のRAID障害に関するメッセージでは、RAID中の論理ドライブ1*にエラーが発生し、コントローラー1、チャネル1、SCSI ID 0*、パーツナンバー06P5778のデバイスで障害が発生したことが分かります。
リスト3のファン障害に関するメッセージでは、ファン回転数がしきい値664RPMを下回る0RPM、つまりファン停止状態となったためメッセージが通知されたことが分かります。
次回は
次回は、今回の内容の延長として、ハードウェアRAIDの監視について触れます。ここでもPDに役立つハードウェア機能を紹介する予定です。
このページで出てきた専門用語
-
PD
- Problem Determinationの略。直訳すれば、「問題を確定する」となる。問題切り分けをし、問題部分を特定する、つまり問題判別することをPDと呼びます。
-
NMI
- Non Maskable Interruptの略。致命的なハードウェア異常が発生した場合に発生する処理のこと。
-
ベースボード
- マザーボードとも呼ばれます。
-
システム管理プロセッサ
- サービスプロセッサとも呼ばれます。
-
IA系
- Intel Architecture系の略。主にIntelまたはその互換CPUを載せたマシンのことを指します。
-
BMC
- Baseboard Management Controllerの略。
-
ISMP
- Integrated System Management Processorの略。
-
PFA
- Predictive Failure Analysisの略。障害予知機能の監視状況を総合的に判断し、24時間から48時間以内に障害が発生する可能性が高いことを通知します。
-
IPMI
- Intelligent Platform Management Initiativeの略。
-
アウトオブバウンド
- Out of Band。監視／管理情報をほかの一般的な通信とは異なる経路でやり取りする方法。
-
RSA II
- IBM eServer xSeries向けのシステム管理アダプタ。これを追加することでBMCによる監視対象に加えてリモートから電源オン/オフやSNMP対応、Webベースの管理コンソールなど、管理できる項目をシステム監視だけでなく運用まで拡張できます。この場合、RSA IIとBMCは補助IPMBと呼ばれる専用バスを通して連携されるため、管理コンソールを統一して監視／管理が行えます。
-
SNMPトラップ
- ネットワーク上で発生した障害などのイベントを通知するメッセージ。
-
パワーサプライ（電源装置）1に障害が発生し、電源の冗長性が失われた状態になっています
- サーバ製品では電源障害に備えるため、複数電源を搭載しているものがあります。この例では、2基備えていた電源のうちの1つが故障したという意味です。
-
RAID中の論理ドイブ
- RAIDによって仮想的に作られたドライブの1つ目。
-
コントローラ1、チャネル1、SCSI ID 0
- それぞれSCSI接続された機器に付加される識別子。
参考文献
著者について | | | 秋田英行（日本アイ・ビー・エム） |
記事の評価
| 
