2. Supermicro硬件与固件基础
在 Supermicro 服务器上做自动化运维，第一步不是写脚本，而是搞清楚“谁管谁”。一台机器上同时存在主板、BMC、BIOS 三套相对独立的运行环境，它们通过 IPMI 和 Redfish 两条管理通道对外暴露能力。批量配置的本质，就是找到正确的通道，把参数写到正确的对象上，并确认写入结果。理解这层关系，后面所有批量操作才有稳定的落点。
主板、BMC、BIOS 三者的职责边界
主板是物理载体，承载 CPU、内存、PCIe 插槽、网卡、硬盘背板以及一颗独立的管理芯片。Supermicro 主板通常把管理子系统称为 BMC（Baseboard Management Controller），在 X11、X12、H13 等世代上，BMC 芯片多为 ASPEED AST2500 或 AST2600，运行一套独立的嵌入式 Linux 系统，拥有自己的网口（常标注为 IPMI LAN 或 Dedicated LAN）、自己的 MAC 地址和 IP 地址。
关键点在于：BMC 与主机操作系统是两套电源域和两套网络栈。主机断电、系统崩溃、操作系统未安装时，只要服务器接入市电且 BMC 已上电，BMC 就可用。因此批量配置中，带外（out-of-band）操作全部走 BMC，不依赖主机系统。
BIOS（Supermicro 界面中也称 UEFI Setup）运行在主机侧，负责硬件初始化、启动顺序、CPU 特性、内存频率、PCIe 拆分、虚拟化开关等。BIOS 设置保存在主板上的 NVRAM 中，掉电不丢失。BMC 本身不能直接修改 BIOS 的每一项，但可以通过 IPMI 或 Redfish 下发“下次启动进入 BIOS 配置”或直接写入 BIOS 配置项，这是批量改 BIOS 的技术基础。
IPMI 与 Redfish：两条管理通道
IPMI 是较早的带外管理规范，基于 UDP 623 端口，提供电源控制、传感器读取、SEL 日志、SOL 串口重定向、FRU 信息等能力。Supermicro 的 ipmitool 用法非常典型：
ipmitool -I lanplus -H 10.0.20.31 -U ADMIN -P 'PASSWORD' chassis power status
ipmitool -I lanplus -H 10.0.20.31 -U ADMIN -P 'PASSWORD' sensor list | grep -i cpu
ipmitool -I lanplus -H 10.0.20.31 -U ADMIN -P 'PASSWORD' fru printIPMI 的短板是数据模型偏底层、返回格式不统一、扩展性差。Redfish 是新一代基于 HTTPS 和 JSON 的管理接口，默认端口 443，路径以 /redfish/v1/ 为根，用资源树的方式组织 Systems、Chassis、Managers、UpdateService 等对象。Supermicro 在 X11 后期及 X12、H13 世代上对 Redfish 支持较完整，适合做批量、结构化、可编程的配置。
两条通道不是替代关系，而是互补：IPMI 适合快速电源操作和兼容老机型，Redfish 适合批量读取/写入结构化配置、固件升级和事件订阅。批量脚本通常以 Redfish 为主，IPMI 作为兜底。
批量配置为什么必须理解这层关系
批量配置的难点不在“循环发请求”，而在于不同参数归属不同对象、生效时机不同、校验方式不同。举几个典型例子：
- BMC 网络参数（IP、掩码、网关、VLAN）属于 BMC 自身，通过 Redfish 的
Managers/1/EthernetInterfaces或 IPMIlan set修改，改完立即生效，但改错 IP 会直接失联。 - BIOS 参数（如
Hyper-Threading、BootMode、PowerPerformanceTuning）属于主机侧，通过 Redfish 的Systems/1/Bios写入，通常需要重启主机才生效。 - 电源策略（如
Restore on AC Power Loss）既涉及 BIOS 也涉及 BMC 的机箱电源策略，需要分别确认。 - 用户与权限属于 BMC，通过
AccountService/Accounts管理，批量创建运维账号时要注意权限级别和密码策略。
如果不区分对象，就会出现“脚本返回 200 但机器行为没变”的情况——请求写到了 BMC，但期望的是 BIOS 生效。因此批量脚本的第一步永远是：明确每个参数的目标对象、生效条件和校验方式。
一个可复用的批量配置参数归属表
下面这张表可以直接作为批量配置脚本的输入设计依据。字段含义：目标对象决定走哪个 Redfish 资源路径；生效方式决定是否需要重启；校验方式决定脚本如何判断成功。
| 配置项 | 目标对象 | 推荐通道 | 生效方式 | 校验方式 |
|---|---|---|---|---|
| BMC IP / 掩码 / 网关 | BMC | Redfish Managers | 立即 | 回读 EthernetInterfaces |
| BMC 用户与权限 | BMC | Redfish AccountService | 立即 | 回读 Accounts 列表 |
| 启动顺序 BootOrder | BIOS | Redfish Systems/Bios | 重启后 | 回读 Boot 属性 |
| 超线程 Hyper-Threading | BIOS | Redfish Systems/Bios | 重启后 | 回读 Bios 属性 |
| 电源恢复策略 | BMC/机箱 | Redfish Chassis | 立即 | 回读 PowerRestorePolicy |
| 固件版本 | BMC/BIOS | Redfish UpdateService | 升级后重启 | 回读 FirmwareVersion |
| 传感器阈值 | BMC | IPMI / Redfish | 立即 | sensor list 比对 |
Redfish 批量读取的实际形态
以 Supermicro X12 平台为例，批量脚本通常先做一次“资产与配置采集”，确认每台机器的 BMC 固件版本、BIOS 版本、当前关键参数。Redfish 请求形如：
# 读取系统基本信息
curl -k -u ADMIN:'PASSWORD' https://10.0.20.31/redfish/v1/Systems/1
# 读取 BIOS 当前属性
curl -k -u ADMIN:'PASSWORD' https://10.0.20.31/redfish/v1/Systems/1/Bios
# 读取 BMC 固件版本
curl -k -u ADMIN:'PASSWORD' https://10.0.20.31/redfish/v1/Managers/1返回的 JSON 中，FirmwareVersion、BiosVersion、PowerState 等字段可以直接进入资产库。批量场景下，把 IP 列表读入循环，逐台请求并落库，就能得到一份可对比的基线。后续配置变更前后各跑一次，diff 结果就是变更证据。
IPMI 与 Redfish 的选用判断
实际项目中可以按以下逻辑选择通道：
- 需要电源开/关/重启、SOL 串口、SEL 日志：优先 IPMI，命令短、兼容性好。
- 需要结构化读取或写入 BIOS、BMC、账户、固件：优先 Redfish，JSON 易解析、字段稳定。
- 老机型 Redfish 支持不完整：用 IPMI 兜底，但要把返回文本做规范化解析。
- 批量固件升级：走 Redfish UpdateService，配合任务轮询判断完成状态。