專為 IT 管理員打造

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

COM-HPC PMI 實現(xiàn) IPMI 和 Redfish

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

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

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

Redfish 互操作性標準

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

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

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

用于 COM-HPC 實現(xiàn)的 Redfish 架構

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

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

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

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

不同的實施方案

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

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

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

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

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

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

審核編輯：郭婷