基于Redfish的COM-HPC平台管理接口-电子发烧友网

专为 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 以及软件定义数据中心（SD DC）。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 插件。