障害発生時の金科玉条：第3回：ハードウェアかOSか、それが問題だ――障害の原因を求めて (2/3)

システム管理プロセッサを活用する

　ハードウェア関連のエラーの場合、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によるアウトオブバウンド構成