4. Redfish标准与EPYC管理接口

在上一节中我们已经看到，EPYC 平台的带外管理最终都汇聚到 BMC 上。但 BMC 对外暴露的接口并不只有传统的 IPMI 和厂商私有 CLI，现代 EPYC 服务器普遍同时提供 Redfish 接口。Redfish 由 DMTF 制定，是一套基于 REST 风格、以 JSON 为载荷、以 OData 为资源寻址约定的管理标准。理解它的资源模型和寻址方式，是后续用脚本批量管理 EPYC 节点的前提。

一、Redfish 的资源模型：一切皆资源

Redfish 的核心思想是把服务器内部所有可管理对象抽象成“资源”，每个资源有唯一的 URI、固定的 JSON 结构，以及一组标准属性。资源之间通过导航属性（通常是 @odata.id 指向的链接）互相引用，从而形成一棵从服务根出发的资源树。

对 EPYC 服务器而言，最常打交道的资源包括：

• /redfish/v1/：服务根，列出所有顶层集合，是遍历的起点。
• /redfish/v1/Systems/：计算系统集合，EPYC 节点通常对应 System.Embedded.1 或 1 这类成员 ID。
• /redfish/v1/Systems/{id}/Processors/：处理器集合，每个 EPYC Socket 是一个成员，可读取型号、核心数、主频、状态。
• /redfish/v1/Systems/{id}/Memory/：内存集合，对应各 DIMM 槽位。
• /redfish/v1/Chassis/：机箱资源，包含温度、风扇、电源等散热与供电子资源。
• /redfish/v1/Managers/：BMC 自身资源，包含网络配置、固件版本、虚拟介质等。
• /redfish/v1/UpdateService/：固件更新服务，EPYC 平台的 BIOS、BMC、CPLD 升级多从这里发起。

这些资源不是孤立的：从服务根可以导航到 Systems，从 Systems 成员可以导航到 Processors 和 Memory，从 Managers 可以导航到网络接口和日志服务。这种“根—集合—成员—子资源”的层级，正是 Redfish 与 IPMI 最大的区别——IPMI 是扁平的传感器和命令集合，而 Redfish 是有结构、可自描述的资源树。

二、OData 协议：Redfish 的寻址与查询语法

Redfish 直接复用了 OData 4.0 的 URL 约定。这意味着资源定位不是靠自定义命令，而是靠标准 URL 路径加查询选项。对 EPYC 运维来说，最常用的四类语法是：

路径导航。从服务根逐级向下，例如读取第一个 Socket 的处理器信息：

GET /redfish/v1/Systems/1/Processors/CPU0

返回的 JSON 中会包含 Model（如 "AMD EPYC 9654"）、TotalCores、MaxSpeedMHz、Status 等字段。注意成员 ID 由 BMC 定义，不同厂商可能是 CPU0、CPU1 或 0、1，因此脚本中应先 GET 集合再取 Members 数组，而不是硬编码 ID。

集合展开。默认 GET 一个集合只返回成员链接列表，要逐个再请求。使用 $expand 可以在一次请求中展开成员详情：

GET /redfish/v1/Systems/1/Processors?$expand=.($levels=1)

字段筛选。用 $select 只取需要的属性，减少带宽和解析负担：

GET /redfish/v1/Systems/1/Processors/CPU0?$select=Id,Model,TotalCores,Status

分页。日志类集合可能上千条，用 $skip 和 $top 分页读取，避免单次响应过大。

三、EPYC 服务器上的 Redfish 实现要点

标准只规定接口形态，具体实现由 BMC 固件完成。在 EPYC 平台上，需要特别关注以下几点：

• 认证方式。推荐使用 HTTP Basic 认证做快速验证，生产环境应使用 Redfish Session：先 POST /redfish/v1/SessionService/Sessions 创建会话，拿到 X-Auth-Token 和 Location，后续请求带 Token，最后 DELETE 会话注销。这样避免每次请求都传明文口令。
• 处理器资源映射。EPYC 的每个 Socket 对应一个 Processor 成员，ProcessorType 为 "CPU"，InstructionSet 为 "x86-64"。NUMA 节点、CCD/CCX 信息通常不在标准 Processor 资源中，而在 OEM 扩展属性里，需要查厂商文档。
• 电源与启动控制。对 Systems/1 执行 Actions/ComputerSystem.Reset，请求体 {"ResetType": "On"} 或 "GracefulRestart"，即可远程开关机或重启，这是批量运维最常用的动作。
• 固件更新。通过 UpdateService 的 SimpleUpdate 动作，传入镜像 URI 和 TransferProtocol，可对 BIOS、BMC 进行升级。EPYC 平台升级 BIOS 通常需要重启，应安排在维护窗口。
• 事件订阅。通过 EventService 的 Subscriptions 注册 HTTP 回调，BMC 在温度越限、电源故障、内存 CE/UE 等事件发生时主动推送，比轮询更及时。

四、常用操作示例

下面给出一个可直接参考的会话建立与处理器信息读取流程。示例中的 IP、账号和返回值为教学假设，实际以现场 BMC 为准。

# 1. 创建会话，获取 Token
curl -k -i -X POST https://192.168.10.20/redfish/v1/SessionService/Sessions \
  -H "Content-Type: application/json" \
  -d '{"UserName":"admin","Password":"Calvin123"}'

# 响应头中返回：
# X-Auth-Token: 8f3c...a91d
# Location: /redfish/v1/SessionService/Sessions/12

# 2. 用 Token 读取处理器集合
curl -k -H "X-Auth-Token: 8f3c...a91d" \
  https://192.168.10.20/redfish/v1/Systems/1/Processors

# 3. 读取单个 Socket 详情
curl -k -H "X-Auth-Token: 8f3c...a91d" \
  "https://192.168.10.20/redfish/v1/Systems/1/Processors/CPU0?$select=Model,TotalCores,Status"

# 4. 注销会话
curl -k -X DELETE -H "X-Auth-Token: 8f3c...a91d" \
  https://192.168.10.20/redfish/v1/SessionService/Sessions/12

判断操作是否成功，主要看三点：HTTP 状态码（200 表示读取成功，201 表示创建成功，204 表示删除成功）、响应 JSON 中的 Status/Health 字段（"OK" 表示正常），以及 @odata.id 是否与请求路径一致。若返回 401，说明 Token 失效或未携带；返回 404，说明资源路径或成员 ID 写错，应回到集合资源确认实际 ID。