REST APIでも操作できるイマドキの物理サーバー
はじめに
最近（といってももはやここ10年弱くらい）の物理サーバーがREST APIで操作できるようなっているのご存知でしたか？メーカー側も世の中のトレンドにあわせて便利に使ってもらえるように製品開発を進めているわけです。なのでサーバーの電源オン・オフなどの操作も昔からあるIPMIやSSH経由のSM-CLP(SMASH)だけでなく、CurlコマンドやPostmanで実行したりPythonなどで通常のWeb APIを扱うのと同じ感覚でスクリプトを書いたりもできたりします。
今後数回の投稿でサーバーのリモート管理の話を情報共有していこうかなと思います。
投稿一覧
第1回: BMC(Basebord Management Controller)全般について(本投稿です)
第2回: サーバー管理用REST API (DMTF Redfish)の基本的な使い方と、Redfishを使うときに便利なPostmanの変数・スクリプトの使い方
第3回: PostmanとREST API(Redfish)を使ったサーバーの具体的な操作やスキーマの見方など
第4回（予定）: ファームウェア更新やBIOS設定変更、イベントやテレメトリーなど
クラウド全盛のいまどき、オンプレのサーバーを利用したり管理する機会のある人もだいぶ限られているのかなとは思いますが😅、ふ〜んって感じで読み流してもらえると良いかなと。
リモート監視管理機能ってなに？
ノートPCやデスクトップPCなどと違ってサーバーは管理者や利用者が直接実機を触ることはまずありません。大量のサーバーを運用できる電力供給や空調や警備体制が整ったデータセンターに設置することが多いでしょうが、簡単に立ち寄れない遠隔地（例えば最近お話ししたお客様では北海沖合の石油採掘リグでご利用とのことでした）で運用したりすることもあります。
また、大量にあるサーバーそれぞれにモニターやキーボードやマウスが接続されているわけでもありません。
ということでXeonクラスのCPUを積むようなサーバーはだいたいリモート監視管理機能が付いています。このリモート監視管理機能は業界では一般的にBMC (Baseboard Management Controller)と呼びますが、大手メーカーのブランド化している製品名でいうとHPE iLOやDell iDRAC、Lenovo XClarityとかがあります。その他の多くのメーカーでは単にBMCと呼ぶことが多いです。
サーバーを操作するというと実機に触るよりはこのリモート監視管理機能(BMC)を操作することになるので、実際にはそれぞれの製品の顔であり、使い勝手などユーザー体験を大きく左右するものと言えます。
リモート監視管理機能のざっくりした仕掛け
マザーボード上のどこにある？
このBMCですが、だいたいArmのSOCがマザーボードに載っていて周囲にDRAMやSPI Flashが接続されており、BMCに直結しているイーサネットのポートが付いていて、電源ケーブルがサーバに刺さってさえいれば待機電源で動作します。
GIGABYTEの商品紹介資料が公開されていたので載せておきます。ASPEED AST2600というのがBMCのSOCで、BMC直結のLANポートが製品背面画像中央のMLANというやつです。製品の実装によってはOSが利用するLANと共有できるものもあり、ブロック図を見るとこのGigabyteのマザーボードもそうなっていますが、この辺はまた機会を改めて解説します。
引用元GIGABYTEへのリンク
引用元GIGABYTEへのリンク
BMCのSOCってどんな感じ？
参考までにBMC SOCのブロック図もASPEED AST2500のものが公開されていました。電源制御用のIPMB/I2Cやファン回転数監視・管理用の接続、ビデオコントローラーやキーボード・マウス・メディア接続用のUSBや外部接続用のイーサネットMAC、SPIメモリコントローラーやDRAM接続、デバッグ用のUARTなどBMC用途に必要な機能があらかじめ実装されているのがわかるかと思います。
出典元へのリンク
BMC上ではLinuxやRTOSが動作する
そして、BMCのSOC上ではLinuxやRTOS(Real Time OS)が稼働していて、Webサーバー（ブラウザで動作するGUIやREST APIを提供する）やSNMPなどその他各種サービスが動作しています。メーカー従業員によるデバッグ用途以外ではシェルログインはできないようになっています。
以下の画像は某BMC製品のデバッグコンソールでネットワーク設定を確認している様子です。ターミナルエミュレーターの窓枠にCOM4とシリアル接続していることが表示されていること以外は、ifconfigコマンドでネットワーク設定を確認するのって少し古めのLinuxとっぽい感じだな〜という以外は特に違いがないと思います。
なお、ターミナルエミュレータをつないだままBMCをリセットすると通常のLinuxと同じ起動シーケンスのコンソール出力を眺めることができたりします。
BMCは各サーバーメーカーが自分でゼロから実装するというよりは、できあいのサーバBMC向けファームウェアスタックを購入し自社の各製品に合わせてカスタマイズしている場合がほとんどです。
できあいのBMCファームウェアスタックとしては以下のようなものがあります。
- 最大手AMI (American Megatrends Inc)社のMegaRac SP-X
- Insyde社のSupervyse
- Vertiv社のAvocent Core Insight
- OSSベースのOpenBMC
業界にいる者の感覚としては、最大手のAMI MegaRAC SP-Xのシェアが圧倒的に高いと思います。大手メーカーのBMCではUIを完全に入れ替えて自社ブランド化してユーザーからは一切AMIベースだということがわからなくなっているものもあれば、ODMなどではAMIがデフォルトで積んでいるUIをそのまま流用している場合が多く、どのODMメーカーのBMCを見ても同じUIデザインで画面上の企業ロゴが違うだけだったりします。
また、今後はOSSベースのOpenBMCの普及が進むと思います。実際AMIやAvocent Core Insightも既にOpenBMCに対応済です。ただし、エンドユーザーが直接OpenBMCを意識して利用するようになるにはまだ時間がかかると思います。
OpenBMCはOSSで公開されているのでエンドユーザーがGitHubから直接ダウンロードしてきてビルドすることもできますが2022年現在、一般ユーザーがそういう使い方をするには機能的にも、サーバーメーカーの対応という点でもまだまだ未成熟な部分が多く実用的ではないと思います。
ちなみに2022年現在、大手メーカーの製品ではまだベンダのBMCをOpenBMCで書き換える方法を提供していないケースがほとんどだと思いますが、業界で最も普及しているAPEED社のSOCを使用しているマザーボードであれば、SOCに直接書き込む同社のSOCFLASHツールを入手できれば上書きできてしまうケースもあると思います。
このSOCFLASHツールはAPEED社の登録アカウントがある人（基本的にOEM/ODMの開発担当者）以外はダウンロードできませんが、ネットを検索するとサポートサイトで配布しているODMメーカーや共有している人がいたりすると思います。
また、SOCFLASHは強制的にSCOを上書きできてしまうので危険だというだけでなく、SOCFLASHが利用するAHBブリッジは脆弱性だという扱いにもなったので、デフォルトではその書き込み経路を閉じてしまい、保守員以外は設定変更して書き込み可能状態にできないような設定にしているメーカーも多いと思います。
なので、SOCFLASHツールを手に入れたから必ず書き込めるというわけではない点、ご留意ください。
デバッグモードについて
デバッグモードというのは要するにシェルログインです。セキュリティ上、各社ともデバッグモードには正規の保守員以外は入れないようにしています。
ODMの実装によくあるパターンはマザーボード上のディップスイッチを変更したりIPMIのrawコマンドでhexのオプションを投げたりして、UART経由のシリアル接続のモードをデバッグモードに変更し、さらにデバッグコンソール上でユーザーのパスワード認証を実施するというものです。2段構えというか物理的にシリアル接続が必要という点も保護に含めれば全部で3段構えですね。正規の保守員以外がデバッグモードに入るのはかなり大変ではありますが、ディップスイッチやIPMIコマンドやユーザーとパスワードがわかってしまえば使い回しできてしまいます。
ちなみにディップスイッチは下記の画像のようなものですが、実際にはすごく小さいので老眼になってきた自分には操作対象を確認するのが結構つらかったりして、スマホのカメラで画面に映しながら拡大して確認したりします。。。
大手メーカーだと上記の3段階に加えて、デバッグ接続をしようとするデバイスをクライアント証明書（コンピューター証明書）で認証したり、デバッグログインするユーザーもクライアント証明書（ユーザー証明書）で認証していたりして、さらにハードルがあがっています。ここまでくると不正にデバッグコンソールに入るのは現実的にはほぼ不可能だと思います。
実際リモート監視管理機能(BMC)で何をするの？
サーバーのCPUとは独立したArmのSOCでLinuxが動作しているので、OSに依存せずにリモートで電源オンオフなどの操作をしたり、障害でOSが起動しないような場合でもトラブルシューティングができたりします。
システムにどんなオプションパーツ（NICなど）が搭載されているか確認できたり、交換が必要な故障部品が確認できたり、エラーなどの各種ログも確認・取得できます。運用中の各部品の温度など予兆監視に役立つ情報も確認・取得できます。
また、BMC自身やBIOS、CPLDなどプラットフォームファームウェアの更新もできます。一部の大手メーカーの製品だとNICやRAIDなど各種オプションカード類のファームウェアの更新もできます。
ほかには、実際のサーバーにモニターを接続しているかのごとく画面操作ができるリモートKVM（Keyboard, Video, Mouse）を使ってBIOSの設定を確認・変更したり、クライアント上やSMB/NFS/WebDAVなどのファイル共有にあるisoイメージをマウントできるリモートメディア機能を使ってOSをインストールしたりできます。
下記の画像は、HTML5リモートKVM（Keyboard, Video, Mouse）とリモートメディア機能の画面例です。
GUIだけでなくCLIも利用でき、スクリプトで処理を自動化したりもできます。画面操作もキャラクターデバイスの端末操作に限られますが、SOL(Serial Over LAN)がbashなどクライアント側のシェル上で利用できたりします。
このCLI、以前はIPMIやSM-CLP(SMASH)などサーバー業界内のみでの業界標準のプロトコルが主流でしたが、業界ではRedfish (サーバー業界標準のREST API）への移行がかなり進みつつあります。まぁ、CLIに限った話ではなくBMC自身のWebUIもRedfishクライアントになっています。
下記はIPMIプロトコルでサーバーの電源状態などを確認するコマンドとその結果です。(IPアドレスやパスワードは非表示にしています)
~# ipmitool -I lanplus -H $bmc_ip_address -U test -E chassis status
System Power : on
Power Overload : false
Power Interlock : inactive
Main Power Fault : false
Power Control Fault : false
Power Restore Policy : previous
Last Power Event :
Chassis Intrusion : inactive
Front-Panel Lockout : inactive
Drive Fault : false
Cooling/Fan Fault : false
Sleep Button Disable : not allowed
Diag Button Disable : allowed
Reset Button Disable : not allowed
Power Button Disable : allowed
Sleep Button Disabled: false
Diag Button Disabled : true
Reset Button Disabled: false
Power Button Disabled: false
~#
下記は同じ電源ステータスをPostmanを使ってRedfish (REST API)で調べた結果です。{{baseUrl}}/redfish/v1/Chassis/System.Embedded.1というエンドポイントに対してGETリクエストするとPowerStatusを含めサーバーの状態に関するいろんな情報が返ってきます。
まとめ
とりあえず今回はこんなところで。
次回の投稿では実際のサーバーのREST APIをPostmanの便利な使い方とあわせて紹介します。
Discussion