專為 IT 管理員打造

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

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

COM-HPC PMI 的命名可能有點(diǎn)令人困惑，因?yàn)樗赡馨凳舅皇?IPMI 指令集的改編，通常在可通過網(wǎng)絡(luò)連接訪問的離散集成板管理控制器 （BMC） 上實(shí)現(xiàn)、串行接口和/或 LPC/eSPI。事實(shí)上，這個(gè)新的平臺(tái)管理界面也實(shí)現(xiàn)了 Redfish，使其比最初出現(xiàn)的更全面和靈活。

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

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

Redfish 互操作性標(biāo)準(zhǔn)

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

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

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

用于 COM-HPC 實(shí)現(xiàn)的 Redfish 架構(gòu)

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

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

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

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

不同的實(shí)施方案

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

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

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

說明：帶有 Redfish 的 COM-HPC PMI 使用流行的 https 標(biāo)準(zhǔn)進(jìn)行通信。對(duì)管理員的一個(gè)很好的副作用：在大多數(shù)情況下，不需要額外的防火墻規(guī)則，因?yàn)橥ㄐ攀峭ㄟ^標(biāo)準(zhǔn) TCP 端口 443 進(jìn)行的。

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

說明： Redfish 和 IPMI 實(shí)現(xiàn)的復(fù)雜程度各不相同?？偟膩碚f，在載板上實(shí)現(xiàn)是推薦的方法。

審核編輯：郭婷