專(zhuān)為 IT 管理員打造

對(duì)于分布式系統(tǒng)的操作員來(lái)說(shuō)，COM-HPC PMI 的主要好處涉及系統(tǒng)維護(hù)和健康管理、異常檢測(cè)以及在系統(tǒng)發(fā)生故障時(shí)繼續(xù)系統(tǒng)訪問(wèn)，從而允許他們啟動(dòng)恢復(fù)措施而無(wú)需調(diào)用服務(wù)技術(shù)人員。

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

COM-HPC PMI 的命名可能有點(diǎn)混亂，因?yàn)樗赡馨凳舅皇?IPMI 指令集的改編，通常在可通過(guò)網(wǎng)絡(luò)連接訪問(wèn)的離散集成板管理控制器 （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)。它也被稱(chēng)為 REST API 或 RESTful API，其中 REST 代表具象狀態(tài)傳輸。該名稱(chēng)表示從應(yīng)用程序的當(dāng)前狀態(tài)到下一個(gè)狀態(tài)的轉(zhuǎn)換的轉(zhuǎn)移。

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

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

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

主數(shù)據(jù)通常包括制造商名稱(chēng)和序列號(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 用于訪問(wèn)有關(guān)操作系統(tǒng)控制臺(tái)、物理安裝的管理硬件和系統(tǒng)管理子系統(tǒng)（即 BMC 和/或 MMC）的管理功能的信息。二

用于 COM-HPC 實(shí)現(xiàn)的 Redfish 模式

但是，Redfish 將協(xié)議的定義與數(shù)據(jù)模型（模式）分開(kāi)。因此，Redfish 協(xié)議基本上是靜態(tài)的，對(duì)用戶來(lái)說(shuō)是好的。另一方面，Redfish 程序員可以獨(dú)立修改數(shù)據(jù)模型中定義的每個(gè)資源。這使得 Redfish 具有高度的靈活性和面向未來(lái)的能力，因?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è)語(yǔ)句中傳達(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í)施的保留和管理庫(kù)存的方式都是相同的，這可以確保長(zhǎng)期投資，即使對(duì)于定制開(kāi)發(fā)的管理控制臺(tái)也是如此。數(shù)百個(gè)“應(yīng)該”和“應(yīng)該”規(guī)范幾乎涵蓋了監(jiān)控和管理分布式系統(tǒng)所需的所有功能。最終，這一切都是為了確保即使系統(tǒng)處于帶外狀態(tài)，服務(wù)仍然可用——即，不再通過(guò)正確系統(tǒng)運(yùn)行期間提供的標(biāo)準(zhǔn)路由訪問(wèn)。

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

不同的實(shí)施方案

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

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

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

審核編輯：郭婷