Posted inリナックス

LinuxにおけるIPMIとipmitool：リモート電源制御、ハードウェアアラート、システム復旧

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

リモートサーバー管理：選択肢の比較

こんな状況を想像してみてください。深夜2時、データセンターの物理サーバーが応答しなくなった。SSHはタイムアウト。pingも死んでいる。カーネルパニックなのか、ハードウェア障害なのか、それともネットワークスタックが凍結しただけなのか、まったく見当がつかない。アウトオブバンド管理がなければ、データセンタースタッフへの電話か、夜中に車で駆けつけるかしか選択肢はない。

3年間にわたって10台以上のLinux VPSとベアメタルインスタンスを管理してきた経験から、サーバーを本番環境に投入する前に必ずアウトオブバンドアクセスをテストするようにしています。最初にそのステップを省いたとき、データセンターの技術者が物理的なリセットボタンを押すのを4時間待つ羽目になりました。二度とあんな思いはしたくありません。

物理層でサーバーをリモート管理するための主なアプローチは3つあります。違いを理解しておくことで、間違った選択を避けられます。

IPMI — オープンスタンダード

IPMI（Intelligent Platform Management Interface）は、ほとんどのサーバーグレードのマザーボードに組み込まれたハードウェアレベルの仕様です。専用のBMC（Baseboard Management Controller）チップ上で動作します。このチップはメインシステムが完全にオフの状態でも電源が供給される小型の組み込みコンピュータです。IPMIはメインCPU、OS、ネットワークスタックとは独立して動作します。

ipmitoolは、IPMIインターフェース向けの主要なLinuxコマンドラインクライアントです。ローカル（ローカルBMCとの通信）とリモート（ネットワーク経由でBMCに接続）の両方に対応しています。

ベンダー独自ソリューション — iDRAC、iLO、その他

DellのiDRAC、HPのiLO、SupermicroのIPMI Web UI、LenovoのXClarityはいずれもIPMIの上に構築されています。Webダッシュボード、仮想メディアのマウント、ブラウザベースのKVMセッション、モバイルアプリなどの機能が追加されています。iDRACの仮想コンソールはインタラクティブなデバッグに非常に役立ちます。ただし、各ベンダーのインターフェースはそれぞれ異なり、高度な機能の多くは有償ライセンスが必要です。iDRAC Enterpriseはサーバー1台あたり追加で150〜300ドルかかります。

重要なポイント：これらはすべて内部でIPMIを使用しています。ipmitoolはDell、HP、Supermicroをはじめとするほとんどのサーバーブランドで動作し、ハードウェアベンダーに関わらず一貫したCLIを提供します。

KVM-over-IPとシリアルコンソールスイッチ

専用のKVM-over-IPデバイス（RaritanやAtenなど）は、サーバーのVGA/USBポートとネットワークの間に設置します。物理モニターの出力を確認し、キーボード入力をリモートで送信できます。BMCを持たないデスクトップクラスのハードウェアに適した選択肢です。デメリットは、1台あたり500〜2000ドル以上のコストがかかり、ラックごとに1台必要で、ハードウェアセンサーデータやイベントログは取得できないことです。

IPMIの長所と短所 — 正直な評価

IPMIが真に輝く場面

  • OS非依存の動作：BMCは独自のファームウェアで動作します。Linuxカーネルパニック？ネットワークドライバのクラッシュ？システムが完全にオフ？それでもIPMIは応答します。これが最大のメリットです。
  • ハードウェアセンサーへのアクセス：CPU温度、ファン回転数、電圧レール、消費電力をリアルタイムで読み取れます。OS上にエージェントをインストールする必要はありません。
  • システムイベントログ（SEL）：BMCはハードウェアイベントを記録します。メモリECCエラー、CPUのサーマルスロットリング、電源ユニットの障害などが、再起動やOSの再インストールでも消えない専用の不揮発性ログに記録されます。
  • Serial Over LAN（SOL）：物理シリアルコンソールをIPMI経由でリダイレクトします。BIOSアクセス、ブートローダーとの対話、カーネル起動メッセージをすべてリモートで確認できます。
  • ベンダー中立なCLI：1つのツール、1つの構文で、複数のハードウェアベンダーに対応します。

IPMIの弱点

  • セキュリティの歴史に問題あり：IPMI 2.0には既知の脆弱性があります。暗号スイート0は認証なしの接続を許可します。RAKP交換は管理ポートに到達できる誰にでもパスワードハッシュを漏洩させます。どちらも修正可能ですが、前提を置かず意図的な設定が必要です。
  • 古いWebインターフェース：IPMIのWeb UI（特に古いSupermicroボード）は2005年代のJavaアプレットを彷彿とさせます。CLIの方がはるかに信頼性が高いです。
  • ネットワーク設定の手間：IPMIには専用の管理ネットワークまたはVLANが必要で、ジャンプホストからのアクセスのみを許可するファイアウォールルールが求められます。インターネットに直接公開するのは、二度と犯したくない過ちです。
  • 追加設定なしでは仮想メディアが使えない：OSの再インストールのためにISOをリモートマウントするには、ベンダーツールまたは専用のKVMアクセスが必要です。

本番環境投入前に推奨するIPMI設定

ネットワーク分離は必須

IPMIは専用の管理ネットワークで運用してください。最低限、ジャンプホストからのアクセスのみを許可するファイアウォールルールを設けた専用VLANに配置します。ほとんどのサーバーでは、BIOS経由またはコマンドで IPMI NICのIPを設定します：

# IPMI NICをスタティックIPに設定（サーバー上でローカルに実行）
ipmitool lan set 1 ipsrc static
ipmitool lan set 1 ipaddr 10.0.1.50
ipmitool lan set 1 netmask 255.255.255.0
ipmitool lan set 1 defgw ipaddr 10.0.1.1

# 設定を確認する
ipmitool lan print 1

デフォルト認証情報の変更と暗号スイート0の無効化

デフォルトの認証情報（admin/adminやADMIN/ADMINなど）は各ベンダーのマニュアルに記載されています。初日に変更してください。次に、認証なしのアクセスを許可する暗号スイート0を無効化します：

# 全暗号スイートの権限をX（無効）に設定して暗号スイート0を無効化する
ipmitool lan set 1 cipher_privs XXXXXXXXXXXXXXX

# 管理者パスワードを変更する
ipmitool user set password 2 'YourStrongPassword123!'

# 現在のユーザーを一覧表示してアカウントを監査する
ipmitool user list 1

ジャンプホストからの接続テスト

緊急時にIPMIを頼りにする前に、管理マシンから実際に動作することを確認してください：

# 基本的な接続テスト — 「Chassis Power is on」が返されるはず
ipmitool -H 10.0.1.50 -U admin -P 'YourPassword' chassis power status

# 暗号ネゴシエーションエラーが出る場合は、暗号スイート3を指定する
ipmitool -H 10.0.1.50 -U admin -P 'YourPassword' -C 3 chassis power status

サーバー自体とは別のマシンからテストし、必要になる前に実施してください。ローカルでのテストは、実際の障害時に使用するネットワークパスの検証にはなりません。これは本当に重要なことです。

実装ガイド：ipmitoolの日常的な使い方

ipmitoolのインストール

# Debian / Ubuntu
apt install ipmitool

# RHEL / AlmaLinux / Rocky
dnf install ipmitool

# ローカルアクセス用のIPMIカーネルモジュールを読み込む
modprobe ipmi_devintf
modprobe ipmi_si

# ローカルBMCにアクセスできることを確認する
ipmitool bmc info

電源管理 — 主要なユースケース

深夜2時にipmitoolを使う理由のほとんどは電源制御です：

# 現在の電源状態を確認する
ipmitool -H 10.0.1.50 -U admin -P 'pass' chassis power status

# グレースフルシャットダウン（電源ボタンを押すのと同様にACPIシグナルを送る）
ipmitool -H 10.0.1.50 -U admin -P 'pass' chassis power soft

# ハード電源オフ（電源ケーブルを抜くのと同等）
ipmitool -H 10.0.1.50 -U admin -P 'pass' chassis power off

# 電源オン
ipmitool -H 10.0.1.50 -U admin -P 'pass' chassis power on

# ハードリセット（オフにしてからオン）
ipmitool -H 10.0.1.50 -U admin -P 'pass' chassis power reset

# 遅延付き電源サイクル（リセットより穏やか）
ipmitool -H 10.0.1.50 -U admin -P 'pass' chassis power cycle

スクリプト内では、power resetは最終手段として扱ってください。まずpower softを試し、ハードサイクルにエスカレートする前に少なくとも30秒待ちましょう。

ハードウェアセンサーとアラートの読み取り

ここがIPMIの真価が発揮される場面です。OSレベルのエージェント不要で、CPU温度、ファン回転数、電圧レールをリアルタイムで確認できます：

# 全センサーの読み取り値を表示する（温度、電圧、ファン回転数）
ipmitool -H 10.0.1.50 -U admin -P 'pass' sensor

# 温度センサーのみにフィルタリングする
ipmitool -H 10.0.1.50 -U admin -P 'pass' sensor | grep -i temp

# 警告または危険状態のセンサーをフィルタリングする
ipmitool -H 10.0.1.50 -U admin -P 'pass' sensor | grep -v 'ok\|na\|ns'

# 出力例：
# CPU Temp        | 45.000     | degrees C  | ok    | 0.000 | 0.000 | 0.000 | 85.000 | 90.000 | 95.000
# Fan1A           | 3600.000   | RPM        | ok    | 300.000 | ...
# 12V             | 12.126     | Volts      | ok    | 10.200 | ...

# スクリプトや解析向けの構造化出力
ipmitool -H 10.0.1.50 -U admin -P 'pass' sdr type Temperature
ipmitool -H 10.0.1.50 -U admin -P 'pass' sdr type Fan

システムイベントログ — ハードウェアのブラックボックス

SELは予期しないダウンタイムの後に最初に確認するものです。ファームウェアレベルでタイムスタンプ付きのハードウェアイベントを記録し、OSのログとは独立しています：

# システムイベントログの全内容を表示する
ipmitool -H 10.0.1.50 -U admin -P 'pass' sel list

# 出力例：
# 1 | 07/14/2026 | 03:22:11 | Memory | Correctable ECC | Asserted
# 2 | 07/14/2026 | 03:22:15 | Power Supply | Failure detected | Asserted
# 3 | 07/14/2026 | 03:22:16 | System Boot | Initiated by hard reset | Asserted

# 最近のイベントのみ表示する（最後の10件）
ipmitool -H 10.0.1.50 -U admin -P 'pass' sel list last 10

# 確認後にSELをクリアする（インシデント後のベストプラクティス）
ipmitool -H 10.0.1.50 -U admin -P 'pass' sel clear

# SEL情報を取得する — 総エントリ数と空き容量
ipmitool -H 10.0.1.50 -U admin -P 'pass' sel info

訂正可能なECCエラーは、RAMがビットフリップを自力で修正していることを意味します。少数であれば正常です。週を追うごとに増加している場合は、メモリ交換のスケジュールを立ててください。訂正不能なECCエラーが出たら、今日中に対処してください。

Serial Over LAN — モニターなしのコンソールアクセス

SOLは物理シリアルポートをIPMI経由でリダイレクトします。物理マシンに触れることなく、BIOS出力、ブートローダーメッセージ、起動時のカーネル出力を確認できます：

# まず、シリアルコンソールを使用するようサーバーのgrubを設定する
# /etc/default/grub を編集する：
# GRUB_CMDLINE_LINUX="console=tty0 console=ttyS1,115200n8"
# GRUB_TERMINAL="serial console"
# GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=1 --word=8 --parity=no --stop=1"

# grub設定を適用する
grub2-mkconfig -o /boot/grub2/grub.cfg   # RHELベース
update-grub                               # Debianベース

# SOLセッションを開始する（終了するには ~ + . を押す）
ipmitool -H 10.0.1.50 -U admin -P 'pass' sol activate

# 固まったSOLセッションを非アクティブにする
ipmitool -H 10.0.1.50 -U admin -P 'pass' sol deactivate

他の手段がすべて失敗したときの復旧ワークフロー

サーバーが応答しなくなったときの実際のチェックリストです：

  1. IPMIで電源状態を確認する — マシンは実際にオンになっているか？
  2. 障害発生時刻前後のハードウェアイベントをSELで確認する。
  3. 温度スパイク、ファン障害、電圧異常のセンサーデータを確認する。
  4. SOLを有効にして出力があるか確認する（カーネルパニックメッセージ、ファイルシステムエラー、ブートローダーの停止）。
  5. システムが本当にハングしている場合：chassis power softを実行し、60秒待ってからchassis power onを実行する。
  6. ソフトシャットダウンが機能しない場合：chassis power reset — ハードリセット。
#!/bin/bash
# クイック復旧スクリプト
IPMI_HOST="10.0.1.50"
IPMI_USER="admin"
IPMI_PASS="yourpassword"
IPMI_OPTS="-H $IPMI_HOST -U $IPMI_USER -P $IPMI_PASS"

echo "=== 電源状態 ==="
ipmitool $IPMI_OPTS chassis power status

echo "=== 最近のSELイベント ==="
ipmitool $IPMI_OPTS sel list last 20

echo "=== 危険なセンサー読み取り値 ==="
ipmitool $IPMI_OPTS sensor | grep -v 'ok\|na\|ns\|nr'

echo "=== ソフトシャットダウンを開始します ==="
ipmitool $IPMI_OPTS chassis power soft
echo "60秒待機中..."
sleep 60

echo "=== 電源をオンにします ==="
ipmitool $IPMI_OPTS chassis power on

実体験から得た重要なヒント

  • サーバーごとにIPMI認証情報をパスワードマネージャーに記録しておく。必ず忘れます。BMCの認証情報をリセットするには物理アクセスが必要なことが多いです。
  • IPMIアラートを設定する：ほとんどのBMCはハードウェアイベント発生時にSNMPトラップまたはメールアラートを送信できます。設定しておけば、熱によるシャットダウンが起きる前にファン障害を検知できます。
  • サーバーインベントリにIPMI IPを記録しておく。SSHが使えない状況でIPMIアドレスもわからないというのは、インシデント対応中に最悪の組み合わせです。
  • ファームウェアの更新は重要：BMCファームウェアの更新にはセキュリティ脆弱性の修正が含まれることが多いです。定期的にベンダーのサポートサイトを確認し、メンテナンスウィンドウ中に更新してください。
  • 実際の状況に近い条件でテストする：サーバーを起動し、テスト環境でecho c > /proc/sysrq-triggerを使って意図的にハングさせ、IPMIだけで復旧できることを確認してください。完全な復旧パスをテストするまでは、動作すると思い込まないでください。

複数の企業でこのパターンを繰り返し見てきました。IPMIは今日やりたくないセットアップの手間に見えるから後回しにされます。そして障害が発生し、30秒の電源サイクルで済んだはずのことのために、誰かがデータセンタースタッフと4時間調整する羽目になります。2時間のセットアップと4時間のダウンタイム。一度経験すれば、この計算の答えはすぐにわかります。

Share:
Tags: