Redfish

3 秒看懂

Redfish 是由 DMTF（分散式管理任務組）制定的、基於 RESTful API 和 JSON 的現代化伺服器與資料中心硬體帶外管理標準。它是 IPMI 協議的繼承者，旨在為 AI 伺服器、異構計算叢集等複雜基礎設施提供統一、安全、可程式設計的管理介面。

3 分鐘產業解釋

在 AI 訓練/推論叢集中，數以千計的 GPU 伺服器、高速網路和儲存裝置構成了龐大的硬體資源池。運維人員需要一種標準化、自動化的方式來監控狀態（如 GPU 溫度、功耗）、執行韌體更新、控制電源和配置網路，而無需登入到作業系統或連線物理線纜。這就是“帶外管理”——通過獨立於主業務網路的專用管理介面進行。

Redfish 的核心價值在於標準化。它取代了老舊、不安全的 IPMI，定義了一套統一的、人類可讀的 API 介面和資料模型。這意味著，無論是戴爾、惠普、聯想還是超微的伺服器，其電源管理、感測器資料查詢等功能都可以用同一套程式碼來控制。對於建置大規模、自動化、混合品牌的 AI 算力中心而言，Redfish 極大地降低了整合複雜度和運維成本，是 AI 基礎設施實現“軟體定義”的關鍵管理基石。

15 分鐘專家深入

Redfish 的意義遠不止於替換 IPMI。它代表了資料中心硬體管理從“基於命令的、不安全的專有協議”向“基於資源的、安全的標準化服務”的範式轉變。

1. 標準化的粒度與生態：Redfish 定義了非常豐富的“資源模式”，例如 Chassis（機箱）、ComputerSystem（計算系統）、Manager（管理控制器）等。每個模式下都有詳細的屬性（如溫度、功耗、序列號）和操作（如重置、啟動）。廠商可以在此基礎上擴充套件，但核心介面保持一致。這催生了一個包括硬體廠商、ISV（獨立軟體開發商）、開源專案（如 OpenBMC 內建 Redfish）在內的生態系統。
2. 自動化與可觀測性的基石：在 AI 訓練任務中，如果某塊 GPU 因過熱而降頻，Redfish API 能夠被上層編排系統（如 Kubernetes、Slurm）或監控系統（如 Prometheus）即時探測到，從而觸發自動故障隔離或告警。它提供的結構化 JSON 資料，比 IPMI 的原始十六進位制資料更易於整合到現代可觀測性棧（日誌、指標、追蹤）中。
3. 對 AI 時代的適應性：現代 AI 伺服器常包含定製化元件（如液冷 CDU、多路 GPU 模組）。Redfish 允許廠商通過 OEM 擴充套件 方式，為這些特定元件定義管理介面，同時保持主架構的相容性。這使得管理架構能靈活適配快速迭代的 AI 硬體創新。

一個關鍵的技術範式是 RESTful 設計：將每個物理或邏輯元件抽象為一個資源（通過 URI 標識，如 /redfish/v1/Systems/1），通過標準的 HTTP 方法（GET、POST、PATCH、DELETE）來查詢和操作，資料格式為自描述的 JSON。

[ 客戶端 (運維工具/指令碼/監控系統) ]
        |
        | HTTPS (Port 443)
        v
[ Redfish Service (在BMC/iDRAC/iLO上) ]
        |
        |--- 管理 -> [ CPU, GPU, Memory, Fans, PSU, NIC ... ]
        |--- 韌體更新
        |--- 虛擬KVM/媒體掛載 (通常通過獨立但關聯的服務實現)

技術原理（最深）

Redfish 的架構基於 資源模型（Resource Model） 、RESTful API 、安全通訊 和 事件服務 四大支柱。

1. 核心資源模型 DMTF 以 JSON Schema 的形式定義了一套層次化的資源模型。這是一個虛擬的、邏輯化的“管理樹”：

/redfish/v1 (服務根)
  |-- /Chassis/1 (機箱，可能是刀片或獨立伺服器)
  |    |-- /Thermal (散熱子系統：溫度感測器、風扇)
  |    |-- /Power (電源子系統：PSU狀態、功耗歷史)
  |    |-- /Drives/1 (硬碟)
  |    ...
  |-- /Systems/1 (計算系統：CPU、記憶體、啟動設定)
  |    |-- /Processors/1 (處理器)
  |    |-- /Memory/1 (記憶體條)
  |    |-- /EthernetInterfaces/1 (網路介面)
  |    |-- /LogServices/1 (日誌服務，如系統事件日誌SEL)
  |    ...
  |-- /Managers/1 (管理控制器自身，即BMC)
       |-- /NetworkProtocol (管理網路設定)
       |-- /AccountService (使用者帳戶管理)
       |-- /UpdateService (韌體更新服務)
       |-- /SessionService (會話服務)

• 關鍵引數：資源屬性使用明確的資料型別定義。例如，溫度感測器的 ReadingCelsius 是數字型別，Status.State 是列舉型別（如 Enabled, Disabled）。
• OEM 擴充套件：廠商可以在標準資源下通過 Oem 屬性新增私有資料，或註冊全新的 @odata.type（如 #NvidiaGpu.v1_0_0.NvidiaGpu）來管理特定硬體。

2. RESTful API 互動

• 發現：客戶端從眾所周知的根路徑 /redfish/v1/ 開始，通過響應中的連結（@odata.id）遍歷整個管理樹。
• 查詢：使用 GET 請求獲取資源狀態。例如，獲取機箱1的溫度：GET /redfish/v1/Chassis/1/Thermal。響應包含所有溫度感測器和風扇的詳細狀態。
• 操作：使用 POST 執行動作，PATCH 修改配置。例如，設定 BIOS 啟動模式：PATCH /redfish/v1/Systems/1/Bios，請求體為 {"Attributes": {"BootMode": "Uefi"}}。

3. 安全機制

• 傳輸加密：強制要求 TLS (HTTPS)。
• 認證與授權：支援多種認證方式，最常見的是 HTTP Basic Auth（使用者名稱/密碼）和 Session 認證（建立會話後使用會話金鑰）。權限通過預定義的角色（如 Administrator, ReadOnly）精細控制。
• 安全審計：通過 SessionService 和 LogServices 記錄所有管理操作。

4. 事件訂閱服務 客戶端可以訂閱感興趣的事件（如溫度閾值告警、電源故障）。當事件發生時，Redfish 服務會向預先配置的 事件目的地（URL） 傳送 POST 請求，內含事件詳細資訊。這是實現主動式、即時監控的關鍵。

技術演進史

• 前身：IPMI：誕生於1998年，基於二進位制協議，使用不安全的 UDP 通訊，資料結構不透明，難以整合和自動化，安全隱患大。
• Redfish v1.0 釋出 (2015)：DMTF 釋出首版規範，確立了 RESTful/JSON 的核心設計理念。初期採納緩慢，主要受限於廠商實現度和對 IPMI 的路徑依賴。
• 生態成熟與擴充套件 (2017-2020)：隨著 OCP（開放計算專案）等組織推動，主要伺服器廠商（Dell, HPE, Lenovo, Inspur, Supermicro）全線產品支援 Redfish。規範不斷完善，加入了儲存、網路、 composition（組合編排）等高階功能。
• 成為事實標準 (2021至今)：在雲端原生和 AI 計算時代，自動化管理成為剛需。Redfish 因其標準化、可程式設計和安全的特性，已成為資料中心硬體管理的 事實標準。IPMI 功能被保留用於向後相容，但新特性開發已全面轉向 Redfish。

技術路線對比（量化表）

特性維度	IPMI	SNMP	Redfish
設計理念	命令驅動，平台特定	網路裝置監控為中心	資源/模型驅動，面向基礎設施管理
資料格式	二進位制	MIB定義的ASN.1	JSON，人類可讀，自描述
傳輸協議	UDP (常用埠623)，安全性差	UDP (161/162)，明文（v1/v2c）或安全（v3）	HTTPS，強制加密
介面風格	專有命令集	GET/SET (MIB樹)	RESTful (標準HTTP方法)
擴充套件性	差，廠商命令私有	好，但MIB定義不統一	極好，有標準化的OEM擴充套件機制
安全模型	弱（基於密碼）	中等（v3可選加密認證）	強（HTTPS+精細RBAC）
現代整合難度	高，需要專用解析庫	中等，工具鏈成熟但非原生Web	低，原生支援HTTP/JSON，與雲端原生工具無縫整合
主要用途	傳統伺服器KVM、電源控制、感測器	網路裝置、伺服器粗粒度狀態監控	資料中心全棧硬體管理（計算、儲存、網路、機房）

上下游

上游（依賴方）：

• 硬體層：BMC（基板管理控制器） 是 Redfish 服務的執行主體，其上的韌體（如 OpenBMC、各大廠商私有韌體）實現了 Redfish 服務端。
• 晶片層：BMC 晶片（如 ASPEED AST2600）提供硬體基礎。

Redfish 本身位置：管理韌體/軟體介面層。它向上層暴露標準化的管理能力。

下游（使用方/消費者）：

• 基礎設施管理軟體：叢集管理平台（如 OpenStack Ironic）、資料中心基礎設施管理（DCIM）軟體。
• 自動化編排工具：Ansible（有 community.general.redfish 模組）、Terraform（通過第三方 provider）、Puppet。
• 監控與可觀測性系統：Prometheus（通過 Redfish exporter）、Zabbix。
• 雲端管理平台與 Hypervisor：VMware vCenter、公有雲端內部管理平面。
• AI 訓練平台：如 Kubernetes（通過自定義裝置外掛或 Operator）整合硬體狀態，用於智慧任務排程和故障恢復。

關鍵指標

評估 Redfish 實現質量與成熟度的核心指標：

1. 功能完備性：支援的 DMTF 標準模式和動作數量，特別是對 GPU、液冷等 AI 專用元件的 OEM 擴充套件支援。
2. API 效能：單次請求響應時間，併發處理能力。這影響大規模叢集的巡檢效率。
3. 安全合規性：是否支援最新的 TLS 版本，密碼策略強度，審計日誌的完整性。
4. 可靠性：服務本身的高可用性設計，不會因管理操作影響生產負載。
5. 生態相容性：與主流開源工具（OpenBMC, Prometheus）和商業管理軟體的整合測試報告。

供需與市場資料

• 供給側：全球主要伺服器 ODM/OEM 廠商已 全系列標配 Redfish 支援。[行業估算] 目前新出廠的面向資料中心和 AI 的伺服器，其 BMC 韌體 100% 實現了 Redfish v1.x 核心功能。支援深度取決於產品線和價格。
• 需求側：雲端服務商（CSP）、大型網際網路公司、AI 研究機構是 最主要的驅動者和高階使用者。他們對自動化、標準化的要求極高。傳統企業市場正在從 IPMI 向 Redfish 遷移。
• 市場滲透：[行業估算] 在全球超大規模資料中心和公有雲端基礎設施中，Redfish 的滲透率已超過 90%，成為事實標準。在中大型企業中，滲透率正在快速提升，但仍有大量裝置依賴 IPMI。具體市場價值未單獨揭露，但其作為伺服器韌體和BMC晶片的必選功能，價值已包含在硬體成本中。

代表公司與資本對映

核心硬體/韌體供應商（直接實現者）：

• 伺服器 OEM：戴爾科技 (DELL)、慧與 (HPE)、聯想 (0992.HK)、超微 (SMCI)、浪潮資訊 (000977.SZ)、華為。他們的管理晶片（iDRAC, iLO, XClarity 等）均內建 Redfish。
• BMC 晶片與韌體：信驊科技 (ASPEED Technology, 5274.TWO) 是全球領先的 BMC 晶片廠商，其晶片和參考設計是 Redfish 實現的基石。IBM、英特爾 (INTC) 也有相關 IP。
• 開源關鍵節點：OpenBMC 專案（由 Facebook (Meta) 主導發起，Google、IBM、微軟 (MSFT) 等參與貢獻）是最重要的開源 Red BMC/Redfish 實現，被眾多雲端廠商用於定製化硬體管理。

中游（管理軟體與整合商）：

• DCIM/叢集管理軟體商：如 Vertiv (VRT)、施耐德電氣 (SU.PA)、Panduit 等在其軟體中整合 Redfish 以管理裝置。
• 自動化與監控工具：紅帽 (RHAT, IBM旗下) 的 Ansible、Hashicorp (HCP) 的 Terraform 等通過社群或商業外掛支援 Redfish。

投資邏輯

1. 確定性賣鏟人：Redfish 是 AI 算力基礎設施不可或缺的“管理神經系統”。隨著全球 AI 伺服器出貨量激增，對支援 Redfish 的高階 BMC 晶片和韌體的需求同步增長，直接利好 信驊科技 (ASPEED) 等核心供應商。
2. 軟體定義資料中心價值重估：Redfish 實現了硬體管理的“可程式設計化”，使得上層自動化軟體、智慧運維（AIOps）能夠深度感知和控制物理世界。投資邏輯從“賣硬體”延伸至“賣管理軟體和服務”。關注那些能夠提供基於 Redfish 的智慧化運維解決方案的軟體公司。
3. 標準化降低產業成本，加速創新：Redfish 統一了管理介面，降低了伺服器採購的鎖定風險，使得像 超微 (SMCI) 這樣的組裝廠商能更靈活地整合不同元件。這促進了硬體市場的競爭和創新，長期看有利於降低整體算力成本。
4. 安全合規的溢價：隨著網路攻擊加劇，能夠提供基於 Redfish 的安全加固管理方案（如零信任架構下的硬體管理）的廠商將獲得溢價。

常見誤讀糾偏

• 誤讀1：Redfish 只是另一種硬體監控協議，類似於IPMI的升級版。 糾偏：這是最根本的誤讀。Redfish 是管理架構和標準，而非簡單的監控協議。它不僅包括監控（讀），更核心的是控制（寫） 和配置（改），例如遠端安裝作業系統、更改 BIOS 設定、進行韌體升級、組合硬體資源（Compose）等。它旨在管理整個“計算單元”的生命週期，而不僅僅是看幾個感測器讀數。

• 誤讀2：Redfish 可以完全取代作業系統內的驅動和管理工具。 糾偏：不能。Redfish 是帶外管理，操作在作業系統層之下，與作業系統並行且獨立。它通過 BMC 控制器的專用網口訪問。作業系統內部的效能監控（如 GPU 核心頻率、視訊記憶體佔用）、驅動配置、應用層日誌等，需要由 作業系統內部的代理（Agent） 或基於 IPMI/SMBIOS 的更底層介面來收集和管理。Redfish 與這些帶內管理工具是互補關係，共同構成完整的硬體可觀測性檢視。

學習路徑

1. 入門：訪問 DMTF Redfish 官網，閱讀《Redfish 簡介》白皮書和《使用者指南》。
2. 動手實踐：
   • 在支援 Redfish 的物理伺服器或模擬器（如 DMTF 提供的 Redfish Mockup，或廠商提供的虛擬 BMC）上，使用 curl 命令列工具親自發送 GET/POST 請求，直觀感受 API 互動。
   • 使用圖形化工具，如 Redfishtool（Python命令列工具）或 Postman。
3. 深入規範：研讀 DSP0266 (Redfish Specification) 和 DSP2046 (Redfish Data Model)。重點理解資源模型、操作請求和安全模型。
4. 整合開發：嘗試編寫簡單的指令碼（Python），利用 redfish 庫來批次獲取叢集節點的健康狀態。學習如何將 Redfish 資料匯入 Prometheus/Grafana。
5. 生態與擴充套件：研究 OpenBMC 專案，瞭解 Redfish 在韌體層的實現。關注廠商的 OEM 擴充套件文件。

一句話總結

Redfish 是定義 AI 時代資料中心硬體“語言”的 RESTful JSON 標準，它將伺服器、儲存、網路裝置的管理從封閉的二進位制黑箱，轉變為開放、安全、可程式設計的 Web 服務，是實現超大規模算力中心自動化運維的基石。

延伸閱讀與來源

1. 官方標準：DMTF Redfish 規範與模式 - dmtf.org/standards/redfish。最權威的技術文件。
2. 開源實現：OpenBMC - github.com/openbmc/openbmc。瞭解 Redfish 如何在真實 BMC 韌體中實現。
3. 廠商實踐：各伺服器廠商（如 Dell iDRAC 文件， HPE iLO 文件）的 Redfish API 參考指南是瞭解實際可用特性的寶貴資料。
4. 行業分析：各主要半導體及伺服器行業分析報告中對“資料中心管理技術”、“BMC 晶片”部分的論述。[例如，可參考行業研究機構如 Gartner， IDC 關於資料中心基礎設施管理的技術趨勢報告]。
5. 社群與工具：redfish-tools GitHub 倉庫（DMTF官方）提供各種開發和測試工具。