ハードウェア上級 #7 ファームウェア・BMC・ライフサイクル — サーバーの中のもう 1 台のコンピュータ
電源ケーブルさえ挿さっていれば、サーバー本体が切れていてもその中で動き続けるコンピュータが 1 台あります。BMC (Baseboard Management Controller) です。6 編 まで視線をデータセンターの電力と冷却へ広げてきたので、最終編は再びサーバーの中へ戻ります。今回は BMC とファームウェアスタック、故障予測のシグナル、そしてハードウェアが入ってきてから出ていくまでのライフサイクルを整理し、シリーズ全体を締めくくります。
BMC: 電源が切れていても生きているコンピュータ #
BMC はサーバーのマザーボード上に載っている小さな独立したコンピュータです。自前のプロセッサ (たいてい ARM 系) と自前のメモリ、自前の OS (多くは組み込み Linux)、自前のネットワークポートを持ちます。メイン CPU とは完全に別個に動作するため、OS がパニックで止まっても、ブートできなくても、さらには電源ボタンでサーバーを落としておいても、BMC は生きて応答します。電源ケーブルが供給するスタンバイ電力だけで動くコンピュータだからです。
この独立性こそが BMC の存在理由です。運用するサーバーが 1 台ならモニターとキーボードを持っていけば済みますが、別の都市のデータセンターに数百台あるなら、「故障したサーバーを直しに入る経路」が OS の外側に別途必要です。ベンダーごとに名前が違います。Dell は iDRAC、HPE は iLO、Supermicro は単に IPMI または BMC と呼びますが、やることは同じです。
BMC ができること #
- リモートコンソール: ブート画面から BIOS 設定画面まで、モニターを直接つないだのと同じ画面をブラウザで見ます。OS が死んで SSH がつながらないとき、最後に残る接続経路です。
- 電源制御: リモートで電源を入れ、切り、強制リセットをかけます。カーネルが完全に固まったサーバーを蘇らせる唯一の手段です。
- センサー読み取り: 温度、ファン速度、電圧、電源ユニットの状態を OS と無関係に収集します。5 編 の電力測定と 6 編の温度管理が実際に読む値の出どころは、大半が BMC です。
- 仮想メディア: 手元の PC の ISO ファイルを、サーバーに USB ドライブのようにリモートでマウントします。OS 再インストールのためにデータセンターへ行く必要がなくなります。
センサーはコマンド 1 行で確認できます。
CPU1 Temp | 54.000 | degrees C | ok
System Temp | 31.000 | degrees C | ok
FAN1 | 6800.000 | RPM | ok
12V | 12.190 | Volts | ok
PS1 Status | 0x01 | discrete | okIPMI と Redfish #
BMC と対話するプロトコルは 2 世代が共存しています。
IPMI (Intelligent Platform Management Interface) は 1998 年に登場したレガシー標準です。ipmitool コマンドで電源制御、センサー照会、イベントログの閲覧を行います。ほぼすべてのサーバーが対応しているため現場ではいまも広く使われていますが、バイナリプロトコルで扱いにくく、設計が古いためセキュリティ脆弱性が積み重なってきました。
Redfish はその後継として作られた REST ベースの標準です。HTTPS 上で JSON を使って対話するため、curl と jq だけで自動化できます。
curl -sk -u admin:PASSWORD https://bmc.example.com/redfish/v1/Systems/1 | jq '.PowerState'
"On"数百台のファームウェアバージョンを収集したり、電源を一括制御したりする作業なら、Redfish の方が圧倒的に扱いやすいです。新しく自動化を作るなら Redfish を基本に据え、IPMI は古い機器の互換用としてだけ残すのが現在の方向です。
ファームウェアスタックの地図 #
サーバー 1 台には、ファームウェアが思った以上にたくさん入っています。
| ファームウェア | 場所 | やること |
|---|---|---|
| BIOS/UEFI | マザーボード | ハードウェア初期化、ブートローダー呼び出し、メモリ・電力設定 |
| BMC ファームウェア | BMC チップ | 上で見たリモート管理機能の全部 |
| NIC ファームウェア | ネットワークカード | パケット処理、オフロード機能 |
| SSD ファームウェア | 各ドライブ | ウェアレベリング、ガベージコレクション、キャッシュポリシー |
| RAID カードファームウェア | RAID コントローラ | アレイ管理、キャッシュとバッテリーの制御 |
このうちどれか 1 つのバグが、OS では説明のつかない症状を作ります。特定ファームウェアバージョンの SSD が、累積稼働時間が一定値を超えると丸ごと死ぬ事故、NIC ファームウェアのバグで特定パターンのパケットを受けたカードが止まる事故は、実際に繰り返されてきた類型です。OS とアプリケーションをいくら覗き込んでも原因が出てこないとき、1 層下に容疑者がまだいるという事実を覚えておく必要があります。
問題は、アップデートが先送りされやすいことです。再起動が必要な場合が多く、失敗すればブート不能になりうるという恐れがあり、すぐ目に見える利得がないからです。そこでうまく運用している組織は、ファームウェアを個別ファイルではなく 検証済みのまとまり 単位で管理します。ベンダーが互換性を検証して配布するバンドルバージョンを四半期に 1 回程度の周期で決め、1〜2 台のカナリアサーバーに先に適用して一定期間観察したうえで、再起動がどのみち必要なカーネルアップデートや定期点検のスケジュールに載せて順次展開します。「問題が起きたらそのとき上げる」というやり方は、問題が起きた時点で数年分の変更を一度に飛び越えることになり、かえって危険です。
故障は予告してやって来ます #
ハードウェアはある日突然死ぬように見えますが、先にシグナルを送ってくることが多いです。見る場所は 3 つです。
SMART はドライブが自分で記録する健康指標です。再割り当てセクタ数、回復不能エラー、NVMe なら残り寿命のパーセントを見ます。特に再割り当てセクタが 0 から動き始めたディスクは統計的に故障確率が大きく跳ね上がるため、死ぬ前に交換を計画できます。
ECC エラーカウンタ はメモリのシグナルです。ECC メモリは 1 ビットの誤りを静かに訂正しますが、Linux はその訂正回数を EDAC サブシステムで集計します。
grep . /sys/devices/system/edac/mc/mc*/ce_count
/sys/devices/system/edac/mc/mc0/ce_count:0
/sys/devices/system/edac/mc/mc1/ce_count:142訂正可能エラー (CE) はただちに障害ではありませんが、特定の DIMM でカウントが着実に増えていくなら、そのモジュールが訂正不能エラー (UE) に発展してシステムを止める前に差し替えを促すシグナルです。
BMC のセンサーイベントログ (SEL) は、OS が記録できない出来事を収めます。電源ユニットの片方が瞬間的に死んで復活した記録、温度しきい値の超過、ファン停止が時系列で残ります。サーバーが突然落ちたのに OS ログに何もないなら、答えはたいてい ipmitool sel list にあります。
BMC セキュリティ: もっとも強力な扉はもっとも危険な扉 #
BMC は OS の下で電源とコンソールを握っているコンピュータなので、侵害されればそのサーバーのすべてを明け渡すのと同じです。ところが BMC ファームウェアは古い組み込みソフトウェアで脆弱性が頻発し、アップデートは本体よりさらに先送りされがちです。そこで原則が 2 つあります。
第 1 に、BMC ポートは管理ネットワークに分離します。サービストラフィックが流れるネットワークと物理的に、または VLAN で隔離された別ネットワークにだけ接続し、インターネットから絶対に届かないようにします。検索エンジンに露出した BMC ログイン画面は、いまも数万台単位で見つかります。
第 2 に、デフォルトアカウントを必ず変更します。admin/admin のような工場出荷アカウントはリストが公開されています。最近の機器は出荷時に個体ごとのランダムなパスワードを付与する方向へ変わりましたが、数年前の機器なら自分で確認する必要があります。
ハードウェアのライフサイクル: 入ってきてから出ていくまで #
サーバーはふつう 3〜5 年の保証期間 とともに入ってきます。保証が生きている間は部品の故障はベンダーの問題ですが、満了後は部品の調達も修理費用もすべて自分の問題になります。だから保証満了の時点が、交換検討の自然な基準線になります。
ただし交換の判断は「まだ動いているのになぜ捨てるのか」という直観としばしばぶつかります。ここで 5 編の電力の話が戻ってきます。CPU の電力対性能は世代ごとに改善されてきたため、5 年前のサーバー数台がやっていた仕事を、新しいサーバー 1 台がより少ない電力で処理できる場合が多いです。電気料金とラックスペースの費用、旧型機器の障害対応にかかる人件費まで合算すると、問題なく動いているサーバーを交換する方が総費用で勝つ時点が来ます。交換の判断は減価償却の帳簿ではなく、この総費用の計算の上で行うものです。
最後は廃棄です。サーバーは捨てても ディスクはデータを持って出ていきます。ファイル削除やフォーマットはデータを消さないため、廃棄手順にディスクの処理が明記されていなければなりません。全体上書き、SSD なら暗号鍵を破棄する方式のセキュア消去 (Secure Erase)、規定が厳しい環境なら物理破砕までの段階があり、どの段階でも処理記録を残すところまでが手順です。セキュリティ事故の事例には、中古で売られたディスクから顧客データが復元された類型が絶えずあります。
まとめ: シリーズを閉じながら #
7 つの編を 1 行ずつ振り返るとこうなります。
- 1 編 は CPU マイクロアーキテクチャを開き、サイクルがコアの中のどこで漏れるのかを perf で読みました。
- 2 編 は eBPF でカーネルを再コンパイルせずにカーネル内部を観測する道を扱いました。
- 3 編 はメモリをさらに深く掘り下げ、ページの先の動作を追いました。
- 4 編 は ZFS がデータ完全性をファイルシステムのレベルで引き受ける設計を見ました。
- 5 編 は視線をサーバーの外へ向け、電気がサーバーまで届く経路と電力のコストをたどりました。
- 6 編 はその電気が熱になって出ていく経路、冷却とラック単位の考え方を扱いました。
- そして 7 編は、サーバーの中のもう 1 台のコンピュータと、ハードウェアの生涯全体を整理しました。
ハードウェア基礎 は部品と指標の概念をつかむシリーズで、ハードウェア中級 はその概念で実際のサーバーを診断するシリーズでした。上級はそこから 2 つの方向へさらに進み、カーネルの下のマイクロアーキテクチャとデータセンターの上の設備までを 1 つの視野に収めました。いまや「サーバーが遅い」という一言の前で、命令パイプラインから冷却水の配管までを同じ地図の上に置いて考えられます。その地図が、このシリーズが残そうとしたもののすべてです。