專為 IT 管理員打造

對于分布式系統的運營商來說，COM-HPC PMI 的主要優勢在于系統維護和健康管理、異常檢測以及在系統發生故障時繼續系統訪問，從而使他們能夠啟動恢復措施而無需調用服務技術人員。

COM-HPC PMI 實現 IPMI 和 Redfish

COM-HPC PMI 的命名可能有點令人困惑，因為它可能暗示它只是 IPMI 指令集的改編，通常在可通過網絡連接訪問的離散集成板管理控制器 （BMC） 上實現、串行接口和/或 LPC/eSPI。事實上，這個新的平臺管理界面也實現了 Redfish，使其比最初出現的更全面和靈活。

Redfish 標準由分布式管理任務組 （DMTF） 管理，可用作 IPMI-over-LAN 的替代或補充，并提供統一的 RESTful 編程接口，非常適合遠程維護邊緣服務器和網關。它也被稱為 REST API 或 RESTful API，其中 REST 代表具象狀態傳輸。該名稱表示從應用程序的當前狀態到下一個狀態的轉換的轉移。

最終，它是一種使用 https 請求訪問和利用數據的 Web 服務和分布式系統的架構。所需要的只是一個帶有 RESTful 插件和 URL 的瀏覽器來啟動服務。這種架構的主要優點包括廣泛使用 http/https 標準進行數據傳輸，這將 Redfish 與其他服務（如 SOAP）區分開來。此外，有效負載元數據開銷較小，因為不需要創建基于 XML 的計算密集型消息。

Redfish 互操作性標準

DMTF 將這種工程范例用于 Redfish 互操作性標準（可用開源），以簡單、安全地管理融合和混合 IT 以及軟件定義數據中心 （SDDC）。Redfish 是人類和機器可讀的，其有效負載以基于 JavaScript 的數據交換格式 JSON 設計。通用模式定義語言用作協議 （OData v4）。這種基礎組合使 Redfish 成為超媒體 API。因此，它通過統一的接口支持各種實現，允許檢測資源及其管理以及事件和任務。一世

主數據通常包括制造商名稱和序列號；例如，事務數據包括當前處理器溫度或板或模塊的功耗。任何 Redfish 服務的起點都是設備 URL，然后是 URI（統一資源標識符）/redfish/v1。通常，Redfish——就像 IMPI——在目標系統中的離散 BMC 上實現。這可以是載板的 BMC 或 COM-HPC 模塊的模塊管理控制器 （MMC）。在 COM-HPC 中，然后從所謂的收集服務系統、機箱和管理器請求信息。

從系統中檢索邏輯系統數據，例如有關模塊制造商、集成處理器、狀態和啟動順序的信息。物理信息由機箱管理。例如，這包括當前溫度或功耗值和限制。最后，Managers 用于訪問有關操作系統控制臺、物理安裝的管理硬件和系統管理子系統（即 BMC 和/或 MMC）的管理功能的信息。ii

用于 COM-HPC 實現的 Redfish 架構

但是，Redfish 將協議的定義與數據模型（模式）分開。因此，Redfish 協議基本上是靜態的，對用戶來說是好的。另一方面，Redfish 程序員可以獨立修改數據模型中定義的每個資源。這使得 Redfish 具有高度的靈活性和面向未來的能力，因為可以在必要時添加資源或更新現有資源的數據模型以滿足新的需求。

權衡是 Redfish 的實現從未標準化。相應規范中的協議版本和支持的功能都不是固定的。這就是為什么有一個 Redfish 互操作性概念，用于在單個語句中傳達 Redfish 互操作性配置文件中規定的實施要求。這樣的配置文件定義了特定實現應該滿足的 Redfish 協議要求，以及它應該支持的 Redfish 模式的子集。

PICMG 現在已經為 COM-HPC 實現定義了一個精確的 Redfish 互操作性配置文件模式。現在，每個實施的保留和管理庫存的方式都是相同的，這可以確保長期投資，即使對于定制開發的管理控制臺也是如此。數百個“應該”和“應該”規范幾乎涵蓋了監控和管理分布式系統所需的所有功能。最終，這一切都是為了確保即使系統處于帶外狀態，服務仍然可用——即，不再通過正確系統運行期間提供的標準路由訪問。

PICMG 進一步規定了通信通道的物理架構，用于管理 COM-HPC 客戶端和服務器模塊及其載板。規范規定載板上應提供 Redfish 接口。還有一個選項可以通過模塊本身的 MMC 提供 Redfish。但是，這需要 MMC 的以太網連接。還必須遵守 COM-HPC 的 Redfish 互操作性配置文件。

不同的實施方案

因此，基于 IPMI 和 Redfish 的 COM-HPC 平臺管理接口規范可以在模塊和載體上以及在任何變體組合上實現：具有管理接口的載板可以托管具有和不具有管理接口的模塊。帶有管理接口的模塊可以在有或沒有BMC的載板上運行。最終，這確保了在首選配置中的最大選擇自由度和整個 COM-HPC 生態系統的完全互操作性。唯一的區別是邊帶和帶外管理選項當然不一樣。

開發人員現在可以決定是否需要具有 COM-HPC PMI 的模塊，或者是否足以通過載板上的 BMC 實現 COM-HPC PMI。后一個選項還允許他們在那里控制 BMC 固件及其功能。通常，在載體上實施是成本較低的方法。首先，最常見的實現可能是在載板上實現 COM-HPC PMI 的解決方案。

在 COM-HPC 系統中實現 Redfish 的資源可在https://github.com/PICMG/com-hpc-redfish獲得。在這里，開發人員可以找到 Redfish 接口的各種 JASON 模型——從帶有一個或四個帶有完全管理和 MMC 的 COM-HPC 模塊的托管載板，到帶有托管載板的最簡單形式和一個沒有 COM-HPC IPMI 的簡單非托管模塊執行。用戶可以使用網絡瀏覽器在本地系統上下載和評估模型。但是，需要事先安裝 RESTful 插件。

說明：帶有 Redfish 的 COM-HPC PMI 使用流行的 https 標準進行通信。對管理員的一個很好的副作用：在大多數情況下，不需要額外的防火墻規則，因為通信是通過標準 TCP 端口 443 進行的。

說明： 后跟 redfish/v1 的 URL 是 Redfish 服務系統、機箱和管理器的起點。三

說明： Redfish 和 IPMI 實現的復雜程度各不相同。總的來說，在載板上實現是推薦的方法。

審核編輯：郭婷