OpenBMC：服务器的带外管理

1. BMC 与带外管理的作用

在服务器系统中，BMC 是一个相对独立的管理控制器。它不依赖主机操作系统运行，即使主机没有开机、操作系统崩溃，或者业务网络不可用，管理员仍然可以通过 BMC 对服务器进行状态查看、远程控制和故障定位。

带外管理的核心价值在于：管理链路和业务链路解耦。业务系统出问题时，BMC 仍然可以提供一条独立的维护通道。

常见能力包括：

• 查看温度、电压、风扇、电源等硬件状态
• 远程开机、关机、重启
• 查看系统事件日志和 POST Code
• 通过 Redfish 或 Web UI 管理服务器
• 使用 iKVM 进行远程控制台操作
• 进行 BMC 固件升级和回滚

2. OpenBMC 的整体架构

OpenBMC 可以理解为运行在 BMC 芯片上的 Linux 系统。它不是一个单独的应用，而是一套完整的软件栈。

从整体上看，OpenBMC 通常可以分成几层：

• 底层硬件：BMC SoC、传感器、风扇、电源、Flash、GPIO、I2C 等
• 内核与驱动层：负责访问底层硬件资源
• 硬件抽象层：把不同平台的硬件差异抽象成统一接口
• 核心服务层：包括传感器服务、电源控制、事件日志、用户权限、固件管理等
• 协议与接口层：提供 Redfish、IPMI、Web、SSH 等访问方式
• 用户交互层：管理员通过浏览器、命令行或自动化平台访问 BMC

这种分层设计的好处是：上层服务不需要直接关心硬件细节，不同服务器平台只需要适配底层硬件和配置，就可以复用大量 OpenBMC 公共组件。

3. 带外管理的数据流

OpenBMC 的管理流程一般分为两类：状态上报和控制下发。

状态上报流程大致如下：

硬件传感器 ↓ 内核驱动 / HAL ↓ D-Bus 服务 ↓ Redfish / Web / 日志系统 ↓ 管理员或监控平台

例如温度传感器的读数会先被底层驱动获取，再由传感器服务处理，最终通过 Web 页面或 Redfish API 展示出来。如果超过阈值，还会产生事件日志或告警。

控制下发流程则相反：

管理员操作 ↓ Web / Redfish / IPMI ↓ 权限校验和状态机判断 ↓ 电源控制服务 ↓ GPIO / PMBus / CPLD 等硬件接口 ↓ 服务器执行动作

例如远程重启服务器时，BMC 不会简单地直接拉 GPIO，而是会经过权限检查、状态判断和电源控制逻辑，最后再操作底层硬件。

4. 硬件状态监控

硬件状态监控是 BMC 最基础也最重要的功能之一。OpenBMC 会周期性读取服务器中的各种硬件状态，例如：

• CPU、主板、进风口、出风口温度
• 电源电压、电流、功耗
• 风扇转速和风扇状态
• PSU 状态
• 主机电源状态
• 各类故障信号

这些数据经过处理后，会被映射成 D-Bus 对象，再由 Web UI、Redfish 或日志系统使用。
当状态异常时，OpenBMC 可以记录事件，也可以配合告警系统通知管理员。这使得服务器故障可以在业务受影响之前被提前发现。

5. 远程电源控制

远程电源控制是带外管理中常见的功能。管理员可以通过 Web 页面、Redfish API 或 IPMI 命令执行：

• Power On
• Power Off
• Power Cycle
• Graceful Shutdown
• Hard Reset

OpenBMC 收到请求后，会先判断当前系统状态和权限，再通过底层硬件接口执行对应操作。
这里比较关键的一点是：BMC 的电源控制不是单纯的“按钮模拟”，而是一个状态机流程。它需要考虑当前主机是否已经开机、是否正在关机、是否处于升级或异常状态，避免错误操作导致系统状态混乱。

6. iKVM 远程控制台

iKVM 的作用是让管理员可以远程看到主机画面，并远程输入键盘鼠标事件。
它的基本流程可以理解为：

主机视频输出 ↓ BMC 采集和编码 ↓ 网络传输 ↓ 浏览器或远程控制台显示 ↓ 浏览器键鼠输入 ↓ BMC 接收事件 ↓ 注入到主机侧

iKVM 的优势是即使主机操作系统没有启动，管理员仍然可以看到 BIOS、Bootloader、安装界面等早期启动阶段的画面。这对于远程装机、故障排查非常有价值。

7. POST Code 日志

POST Code 是主机启动过程中 BIOS 或固件输出的启动阶段码。BMC 可以通过 LPC/eSPI 等通道获取这些 POST Code，并记录成日志。
在 OpenBMC Web 页面中，POST Code Logs 通常用于查看主机启动过程中停在哪个阶段。如果服务器无法正常启动，POST Code 能帮助定位问题发生在内存初始化、PCIe 初始化、设备枚举还是其他阶段。
对于调试平台来说，POST Code 是非常实用的诊断信息。

8. 固件升级与 A/B 分区

OpenBMC 通常会支持 BMC 固件升级。为了降低升级失败导致设备不可用的风险，很多平台会采用 A/B 分区机制。基本思想是：

当前运行 A 分区 ↓ 上传新固件 ↓ 校验镜像 ↓ 写入 B 分区 ↓ 重启并切换到 B 分区 ↓ 启动成功则确认生效 ↓ 启动失败则回滚到 A 分区

A/B 分区机制可以提高固件升级的可靠性。即使新固件异常，也可以回退到旧版本，避免 BMC 无法启动。

9. 总结

OpenBMC 的核心作用是为服务器提供独立于主机操作系统之外的管理能力。它通过 Linux 内核、D-Bus 服务、Redfish/Web/IPMI 接口以及底层硬件驱动，构建了一套完整的带外管理体系。
对于服务器运维来说，BMC 解决的是“主机不可用时如何继续管理服务器”的问题。对于平台开发来说，理解 OpenBMC 的分层架构、数据流和硬件抽象方式，是进行驱动适配、功能开发和故障调试的基础。

参考链接

• 说明：本文为学习整理文章，部分内容参考自 CSDN 博文《OpenBMC之BMC管理架构：服务器带外管理如何工作》。
• 原文链接：https://blog.csdn.net/weixin_49775784/article/details/161310040
• 原文遵循 CC 4.0 BY-SA 版权协议。本文仅用于学习交流，如有不当引用，请联系处理。