2. EPYC服务器硬件与固件基础

在开始批量运维之前，必须先建立对 EPYC 服务器“硬件—固件—管理接口”三层结构的清晰认识。自动化脚本最终操作的对象，往往不是操作系统里的某个文件，而是 BIOS 选项、BMC 的 Redfish 接口或 IPMI 的传感器读数。如果对型号代际、芯片组拓扑和固件入口没有概念，后续的批量配置很容易写错字段、刷错固件或误判健康状态。

EPYC 型号与代际：从 Naples 到 Turin

AMD EPYC 服务器 CPU 按代际大致可分为：Naples（7001 系列，Zen 架构）、Rome（7002 系列，Zen 2）、Milan（7003 系列，Zen 3）、Genoa（9004 系列，Zen 4）、Bergamo（97x4 系列，Zen 4c 高密度）以及 Turin（9005 系列，Zen 5）。型号命名本身携带关键信息，例如 EPYC 9654 中，第一位“9”表示面向双路/高端服务器，后三位“654”中“6”代表 Genoa 代际层级，“54”为 SKU 序号；而 EPYC 9754 属于 Bergamo，核心数高达 128，但单核频率与缓存结构不同于同代 Genoa。

代际差异直接影响运维动作。Rome 及更早平台普遍使用 SP3 插槽，Milan 仍为 SP3，Genoa/Turin 则切换到 SP5，散热器、主板和 BIOS 固件互不兼容。内存通道数也从 Naples/Rome 的 8 通道，提升到 Genoa/Turin 的 12 通道 DDR5。若批量脚本中写死了内存插槽编号或 DIMM 命名规则，跨代执行就会失败。因此，在自动化清单中至少应记录：CPU 型号、代际、插槽类型、内存代际与通道数、支持的 PCIe 代数。

主板芯片组与平台拓扑

EPYC 是 SoC 化程度很高的处理器，很多传统“北桥”功能已集成在 CPU 内部。主板上常见的芯片组主要是 AMD 的服务器平台控制芯片，例如 Promontory（SP3 平台）和 Genoa/Turin 平台上的配套控制芯片。它们负责提供额外的 SATA、USB、低速 PCIe 通道以及 LPC/eSPI 等传统接口，而 CPU 直接引出大量 PCIe 通道用于 GPU、NVMe 和网卡。

在双路系统中，两颗 EPYC 通过 xGMI 互连，形成 NUMA 结构。每颗 CPU 直连一部分内存和 PCIe 设备，跨路访问延迟明显高于本地访问。批量部署时，如果业务对延迟敏感，需要在 BIOS 中确认 NUMA 节点设置（如 NPS1/NPS4），并在操作系统层用 numactl --hardware 验证节点分布。下图给出一个典型的双路 EPYC 服务器硬件与固件管理关系示意。

BIOS/UEFI 关键设置

EPYC 平台的 BIOS 设置项数量庞大，但批量运维真正需要统一控制的通常集中在以下几类。第一类是内存与 NUMA 相关：NUMA nodes per socket（NPS）决定每颗 CPU 暴露几个 NUMA 节点，NPS1 适合通用虚拟化，NPS4 适合对内存带宽和本地性要求高的 HPC 场景。第二类是 SMT 开关，关闭 SMT 会改变逻辑 CPU 数量，影响操作系统授权和调度。第三类是 IOMMU 与 ACS，开启 IOMMU 才能支持设备直通和 SR-IOV 安全隔离。第四类是启动模式，现代批量部署应统一为 UEFI，并关闭 CSM，避免 Legacy 引导带来的分区差异。

这些选项在不同厂商（如 Dell、HPE、Supermicro、Lenovo）的 BIOS 菜单中名称不完全一致，但底层通常对应 AMD 的 CBS/PBS 选项。自动化时，不建议直接按菜单路径模拟按键，而应优先使用厂商提供的 BIOS 配置工具，例如 Dell 的 racadm、HPE 的 ilorest 或通用 Redfish 的 Bios 资源。下面是一个通过 Redfish 读取并修改 BIOS 属性的示例，参数为教学假设值：

# 读取当前 BIOS 属性（示例）
curl -k -u admin:password \
  https://192.168.10.21/redfish/v1/Systems/1/Bios

# 提交待生效属性（示例：NPS4、开启 IOMMU、UEFI 启动）
curl -k -u admin:password -X PATCH \
  -H "Content-Type: application/json" \
  -d '{"Attributes":{"NumaNodesPerSocket":"4","Iommu":"Enabled","BootMode":"Uefi"}}' \
  https://192.168.10.21/redfish/v1/Systems/1/Bios/Settings

# 重启使设置生效
curl -k -u admin:password -X POST \
  -H "Content-Type: application/json" \
  -d '{"ResetType":"ForceRestart"}' \
  https://192.168.10.21/redfish/v1/Systems/1/Actions/ComputerSystem.Reset

提交后应再次读取 Bios 资源确认属性已变为目标值，而不是只看 PATCH 返回 200。部分属性需要冷重启才生效，且不同固件版本对属性名大小写敏感，批量执行前应先在单台样机上验证。

BMC/IPMI 管理接口

BMC 是服务器上独立于主 CPU 运行的管理控制器，拥有独立供电和独立网口。即使主机断电，只要电源线连接且 BMC 供电正常，仍可通过 BMC 访问。EPYC 服务器常见的 BMC 实现包括 ASPEED AST2500/AST2600 系列，支持 IPMI 2.0、Redfish 以及厂商 Web 界面。

IPMI 适合快速读取传感器和电源控制，例如 ipmitool -I lanplus -H 192.168.10.21 -U admin -P password sensor 可列出温度、电压、风扇转速；power status 和 power cycle 用于电源管理。Redfish 则更适合结构化批量配置，它用 JSON 描述系统、机箱、存储、固件清单等资源，便于脚本解析。实际运维中，建议把 IPMI 作为兜底通道，把 Redfish 作为主要自动化接口。

固件基线与批量检查清单

把上述内容落到可执行层面，可以形成一份最小检查清单。它不追求覆盖所有选项，而是保证跨代批量操作时不会因硬件/固件差异而中断。

完成这一层基线采集后，后续的批量配置才有稳定的输入。无论是刷 BIOS、改启动项还是采集健康数据，都应先确认目标机器的代际、插槽、固件版本和管理接口能力，再决定使用 IPMI 还是 Redfish、使用厂商工具还是标准接口。这样，自动化脚本才不会在异构机型上“一刀切”地失败。