📚 课程目录第4章 Redfish与DMTF现代管理接口

4. Redfish与DMTF现代管理接口

IPMI 在过去二十多年里承担了服务器带外管理的主力角色，但它基于二进制消息、依赖 RMCP+ 会话、数据模型扁平且扩展困难，已经难以适应现代数据中心对自动化、可编排和强安全的需求。DMTF 主导的 Redfish 正是为解决这些问题而设计的现代管理接口：它用 RESTful 风格、JSON 数据格式和面向资源的模型，把服务器、机箱、电源、散热、存储、固件、会话等管理对象统一表达为可寻址的资源树。对 Intel Xeon 平台而言，Redfish 通常由 BMC 提供，通过 HTTPS 暴露在 443 端口，配合 Redfish Schema 与 OEM 扩展，能够覆盖从单机运维到大规模批量编排的完整场景。

从 IPMI 到 Redfish：接口范式的变化

理解 Redfish 最有效的方式，是把它与 IPMI 放在同一张对照表里看。IPMI 的典型操作是“发命令、收响应”，例如用 ipmitool sensor list 读取传感器，返回的是按传感器编号排列的文本；而 Redfish 的典型操作是“访问资源、读取属性”，例如 GET /redfish/v1/Chassis/1/Thermal，返回的是带层级结构的 JSON，里面包含温度、风扇、状态和阈值。前者面向命令，后者面向资源。这种差异直接决定了自动化脚本的写法：IPMI 脚本往往要解析文本、处理厂商差异，而 Redfish 脚本可以直接按 JSON 字段取值，稳定性和可维护性明显更高。

另一个关键差异是安全模型。IPMI 的 RMCP+ 虽然支持认证和加密，但历史上存在弱口令、明文传输、Cipher Suite 0 等风险，且会话管理相对粗糙。Redfish 建立在 HTTPS/TLS 之上，天然具备传输加密和服务器身份验证；认证方式则从基础的 HTTP Basic 逐步演进到 Session 认证、Token 认证，并支持基于角色的访问控制。对于 Intel Xeon 服务器，BMC 通常还提供 Redfish 账户、角色和权限的独立配置，使带外管理面能够与数据中心统一身份体系对接。

Redfish 资源模型：从 Service Root 出发

Redfish 的所有内容都从 /redfish/v1 这个 Service Root 开始。它像一棵树的根，下面挂载着若干集合：/Systems 表示服务器系统，/Chassis 表示机箱，/Managers 表示 BMC 自身，/SessionService 管理会话，/AccountService 管理账户，/UpdateService 管理固件更新。每个集合又包含具体成员，例如 /redfish/v1/Systems/1 代表第一台服务器，其下可继续访问 /Processors、/Memory、/Storage、/EthernetInterfaces 等子资源。对于 Intel Xeon 平台，/Systems/1/Processors/CPU1 通常会暴露处理器型号、核心数、主频、状态和健康信息，运维脚本可以据此做资产核对或故障定位。

资源模型的价值在于“可预测”。只要知道资源路径和 Schema，就能用统一方式读取或修改属性。例如读取 CPU 信息：

GET /redfish/v1/Systems/1/Processors/CPU1
{
  "Id": "CPU1",
  "Model": "Intel(R) Xeon(R) Gold 6338",
  "TotalCores": 32,
  "Status": { "State": "Enabled", "Health": "OK" }
}

如果要做电源控制，则不是直接改属性，而是向 /Actions/ComputerSystem.Reset 发送 POST，请求体中指定 ResetType，例如 On、GracefulShutdown、ForceRestart。这种“属性用 PATCH、动作用 POST”的区分，是 Redfish 操作中非常关键的一点。

RESTful 操作与安全认证的实际做法

Redfish 使用标准 HTTP 方法：GET 读取资源，POST 创建资源或触发动作，PATCH 修改可写属性，DELETE 删除资源。实际运维中，最常见的是先建立会话，再复用 Token 执行多次操作。以 curl 为例，创建会话：

curl -k -X POST https://bmc.example.com/redfish/v1/SessionService/Sessions \
  -H "Content-Type: application/json" \
  -d '{"UserName":"admin","Password":"StrongPass!23"}'
# 响应头返回 X-Auth-Token: 8f3c...，后续请求携带该 Token

拿到 Token 后，读取系统状态：

curl -k -H "X-Auth-Token: 8f3c..." \
  https://bmc.example.com/redfish/v1/Systems/1

安全认证方面，Basic 认证适合临时调试，但每次请求都携带明文口令，必须依赖 TLS 保护；Session 认证通过 /SessionService/Sessions 创建会话，返回 Token 和会话超时时间，适合自动化脚本；Token 认证则用于跨服务或短期授权场景。无论哪种方式，都应启用 HTTPS、禁用弱协议、为 Redfish 账户设置强口令，并按最小权限原则分配角色。Intel Xeon 服务器的 BMC 通常支持将 Redfish 账户与 IPMI 账户分离，建议关闭不必要的 IPMI 访问，仅保留 Redfish 作为带外管理入口。

在批量运维中，建议为每台 BMC 使用独立凭据或集中式身份源，并定期轮换 Token 与口令；脚本中不要把口令硬编码在命令行历史里，可改用环境变量或凭据文件。

对比结论与选型建议

IPMI 仍然适合少量、临时的带外操作，例如快速查看传感器或强制重启；但一旦进入自动化、编排、审计和规模化场景，Redfish 的优势就非常明显：JSON 易解析、资源路径稳定、HTTPS 安全、Schema 可扩展、支持批量会话。对于 Intel Xeon 服务器，建议把 Redfish 作为主管理接口，IPMI 仅作为兼容性后备。实际落地时，可以先从 /Systems 和 /Chassis 读取资产与健康信息，再逐步扩展到固件更新、BIOS 配置和电源动作，最终接入 Ansible、Python 脚本或运维平台，实现带外管理的标准化与自动化。