BMC 筆記：IPMI

在前一篇中，我們提到 BMC 是伺服器主機板上的獨立控制器，負責監控各種狀態，並可在主系統關機時進行管理。然而，BMC 並非單獨運作；它之所以能與外部系統管理軟體（如 IPMItool、OpenManage、iDRAC、iLO）互通，是因為它遵循了標準化的管理協定。

我們接下來會講到兩種協議—— IPMI 與 Redfish (待續)。

IPMI (Intelligent Platform Management Interface) 是由 Intel、Dell、HP、NEC 等公司在 1998 年共同制定的伺服器管理標準。

外部管理者可以透過它與 BMC 溝通，執行電源控制、感測器監控、事件記錄、遠端開關機、韌體更新等任務。

這張圖片來自 intel，我想是目前最能說明 IPMI 與 BMC 的架構圖。

在找能說明 IPMI 的架構圖的同時，我也發現一個對 IPMI 實作有著詳細記錄的文章 (雖然是 2013 年的文章，可能跟 IPMI 2.0 有些出入)，貼上來以供參考：https://benjr.tw/11240

另外，我們也經常會在這個領域聽到「OEM」一詞，這是指「各伺服器或主機板製造商在標準 IPMI 規範之外，自訂擴充的命令、事件、或感測器定義」。

像是特殊的電源資訊、風扇模式切換……簡單來說就是 IPMI 的擴充包。

儘管隨著時間與科技進步，IPMI 進行多次更新

安全性不足
IPMI 在 2014 年升級到了 IPMI 2.0，做了諸如：提升加密通訊為 RMCP+、變更預設密碼:、限制網路存取、隔離公用網路……等措施，但還是存在Cipher 0 (CVE-2013-4786)、未驗證韌體簽章、加密模式太弱等問題
資料格式：二進制，不易與現代系統 (ex：Web) 整合
擴充性：難以支援現代硬體資訊模型或 RESTful API
開發維護成本高：多為命令列導向，介面不友善

先一句話說一下 redfish：目標是取代 IPMI 的通訊協定。

在說 redfish 之前，我想先用簡單的比較表來說明為什麼要定 refish 來取代 IPMI。

	IPMI	Redfish
通訊協定層	基於 UDP (RMCP / RMCP+)，封包小但延遲不穩	基於 HTTP/HTTPS (RESTful)，延遲穩定、可並行
傳輸延遲 (Latency)	約 10–100 ms 依實作與網段而定	約 5–20 ms HTTP Keep-Alive 與快取可優化
資料吞吐量 (Throughput)	單次封包容量受限（約數百 bytes）	可一次傳輸大量 JSON 資料（數 KB~MB）
命令處理模式	Command-Response	支援批次請求、多層結構查詢
Parallelism	單線性 (多命令需序列執行)	支援多連線與非同步請求
資料格式	二進位封包，難以快取與壓縮	JSON，可壓縮、易被快取
CPU Loading	低 (封包解析簡單)	稍高 (HTTP + JSON parsing)
傳輸效率	對小量監控資料效率佳	支援批量查詢、效率更佳
安全性	弱密碼 / 無加密	TLS + 權限控制
維護	Intel 主導 (已停更)	DMTF 與 OCP 社群持續發展

簡單來說，考量維護、與現代系統的兼容難易度、安全性等因素，新的協議誕生了。

雖然 redfish 從 2015 年出現至今已經十年，但韌體更新上(尤其是以前的韌體)沒這麼方便，所以目前多數企業伺服器仍支援 IPMI + Redfish 雙協定並存，以兼容舊系統。

通常，舊版管理軟體仍使用 IPMI，新版系統與自動化工具（如 Ansible、OpenBMC、OOB 管理平台）則全面採用 Redfish。

下一篇我們接著說 redfish。

程式。語言。筆記