1. Redfish 是什么

Redfish 是面向现代服务器管理的标准接口。它基于 HTTPS、RESTful 风格和 JSON 数据格式，用统一的资源模型描述服务器、BMC、机箱、传感器、日志、账户、网络和固件更新等管理对象。

简单来说，Redfish 把服务器管理能力整理成了一套标准 Web API。

在传统服务器管理中，IPMI 使用较多，但 IPMI 以命令字和二进制数据为主，接口语义不够直观，扩展能力也有限。对于自动化运维平台来说，IPMI 更像是一组底层命令集合，而不是一套清晰的资源模型。

Redfish 的优势在于：

• 使用 HTTPS，便于安全访问
• 使用 RESTful API，接口语义清楚
• 使用 JSON，便于程序解析
• 使用标准资源模型，便于自动化平台集成
• 支持查询、配置、动作执行和事件管理

2. Redfish 的核心概念

理解 Redfish，主要需要掌握资源、URI、HTTP 方法、JSON 和 Schema 这几个概念。

2.1 资源

Redfish 把服务器管理对象抽象成资源。例如：

• System：被管理的主机系统
• Manager：BMC 管理控制器
• Chassis：机箱和硬件承载对象
• Sensor：传感器
• LogService：日志服务
• AccountService：账户服务
• SessionService：会话服务
• UpdateService：固件更新服务

这些资源共同组成服务器的管理视图。

2.2 URI

Redfish 使用 URI 定位资源。
Redfish 的根入口通常是：/redfish/v1/
客户端可以从这个入口开始发现系统支持哪些资源，再继续访问 Systems、Managers、Chassis、UpdateService 等集合。
例如：

/redfish/v1/Systems
/redfish/v1/Managers
/redfish/v1/Chassis
/redfish/v1/AccountService
/redfish/v1/UpdateService

URI 的好处是资源路径清晰，外部平台可以按标准路径发现和访问服务器管理能力。

2.3 HTTP 方法

Redfish 使用 HTTP 方法表达操作语义。
常见方法包括：

• GET 查询资源状态
• PATCH 修改资源属性
• POST 创建资源或执行动作
• DELETE 删除资源

例如：

• 查询传感器数据使用 GET
• 修改 BMC 网络配置使用 PATCH
• 执行主机重启使用 POST Action
• 删除会话或账户使用 DELETE

这样接口语义比传统命令式接口更直观。

2.4 JSON

Redfish 的响应通常是 JSON 格式。
JSON 中不仅包含普通字段，还会包含资源 ID、资源类型、状态、健康信息、关联链接和 Action 信息。
例如一个资源可能包含：

{ "@odata.id": "/redfish/v1/Systems/system", "Id": "system", "Name": "Computer System", "PowerState": "On", "Status": { "Health": "OK", "State": "Enabled" } }

客户端可以直接解析这些字段，并用于自动化管理。

2.5 Schema

Schema 定义资源应该有哪些字段、字段类型是什么、哪些属性只读、哪些属性可写、某个 Action 需要什么参数。
因此 Redfish 不是简单“返回 JSON”，而是返回有标准结构和语义的 JSON。
这对自动化平台很重要，因为平台可以基于 Schema 理解不同资源的含义，而不是靠厂商私有文档猜字段。

3. Redfish 在 OpenBMC 中的作用

在 OpenBMC 中，Redfish 主要由 bmcweb 实现。
bmcweb 对外提供 HTTPS 和 Redfish API，对内通过 D-Bus 访问 OpenBMC 后端服务。
整体链路可以理解为：

外部客户端 ↓ HTTPS / Redfish ↓ bmcweb ↓ D-Bus ↓ OpenBMC 后端服务 ↓ 驱动 / 硬件

这里要注意，bmcweb 不应该直接操作硬件。它主要负责：

• 接收 HTTP 请求
• 处理认证和会话
• 解析 Redfish URI
• 执行权限检查
• 把请求转换成 D-Bus 调用
• 把后端结果转换成 Redfish JSON 响应

真正的业务逻辑通常在后端服务中完成。例如传感器数据由传感器服务提供，网络配置由网络服务处理，固件升级由软件管理服务执行。
这种设计可以让 WebUI、Redfish、IPMI 和本地服务共享同一套后端状态，避免各自维护状态导致不一致。

4. 功能举例

4.1 查询传感器

传感器数据通常来自底层硬件，例如 I2C 温度芯片、PMBus 电源模块或风扇 tach 输入。
OpenBMC 中的典型链路是：

硬件传感器 ↓ 内核驱动 / hwmon ↓ dbus-sensors ↓ D-Bus 传感器对象 ↓ bmcweb ↓ Redfish Sensor 资源

外部平台通过 Redfish 查询传感器时，不需要知道底层传感器挂在哪条 I2C 总线，也不需要知道 sysfs 路径。它只需要访问标准 Redfish 资源即可。

4.2 电源控制

远程开机、关机、重启是 Redfish 常见功能。
Redfish 通常通过 System 资源下的 Reset Action 表达电源动作。客户端发送 POST 请求，指定 ResetType，例如开机、关机、重启或电源循环。
大致流程如下：

客户端发送 Reset Action ↓ bmcweb 校验用户权限和参数 ↓ 调用 D-Bus 电源控制服务 ↓ 后端服务根据当前状态执行电源动作 ↓ 返回执行结果

这种方式比直接暴露 GPIO 更安全，因为后端服务可以做状态判断、时序控制和错误处理。

4.3 修改网络配置

BMC 网络配置也可以通过 Redfish 管理。
例如修改 IP 地址、网关、DNS 时，客户端通常使用 PATCH 请求修改对应网络资源。
流程可以理解为：

Redfish PATCH 请求 ↓ bmcweb 解析参数 ↓ 调用 Network D-Bus 服务 ↓ 网络服务更新配置 ↓ systemd-networkd 或相关组件生效 ↓ Redfish 返回新的状态

这样无论用户从 WebUI、Redfish 还是命令行查看网络配置，最终都应该看到同一套后端状态。

4.4 用户和会话管理

Redfish 提供 AccountService 和 SessionService，用于管理用户、角色、权限和登录会话。
常见能力包括：

• 创建会话
• 删除会话
• 查询用户
• 创建用户
• 修改密码
• 修改角色权限

这些操作涉及安全边界，因此必须经过认证、授权和审计。bmcweb 负责 Redfish 层面的接口处理，后端用户服务负责真正的用户管理。

4.5 固件更新

固件更新是 Redfish 中比较复杂的功能。
OpenBMC 中通常通过 UpdateService 组织固件更新流程。上传镜像后，后端软件管理服务会进行镜像解析、校验、版本对象创建和激活状态管理。
大致流程如下：

上传固件镜像 ↓ bmcweb 接收请求 ↓ 软件管理服务解析镜像 ↓ 创建版本对象 ↓ 触发 Activation 状态机 ↓ 执行刷写动作 ↓ 返回成功或失败状态

固件升级涉及风险较高，因此不能简单理解为“接口收到文件后直接刷写”。它需要校验、状态机、日志、错误处理和必要的回滚机制。

5. 总结

Redfish 是现代服务器带外管理的重要接口标准。它使用 HTTPS、RESTful、JSON 和标准 Schema，把服务器管理能力组织成统一资源模型。
在 OpenBMC 中，Redfish 主要由 bmcweb 实现。bmcweb 对外提供 Redfish API，对内通过 D-Bus 连接传感器、电源、网络、用户、日志和固件升级等后端服务。
理解 Redfish，需要同时理解两层内容：一是 Redfish 标准如何定义资源、方法、动作和 Schema；二是 OpenBMC 如何把这些标准接口映射到底层 D-Bus 对象和后端服务。
对于服务器自动化运维来说，Redfish 的意义在于把复杂的 BMC 管理能力变成标准 Web API，使状态查询、配置修改、电源控制和固件升级都能被统一管理和自动化编排。

参考链接

• 本文为学习整理文章，部分内容参考自 CSDN 博文《OpenBMC之Redfish：现代服务器管理接口解析》。
• 原文链接：https://blog.csdn.net/weixin_49775784/article/details/162074457
• 原文遵循 CC 4.0 BY-SA 版权协议。本文仅用于学习交流。