1. 课程导入与验证目标定义
Supermicro 计算节点在数据中心里承担的是“长时间不中断地提供算力”这一角色。与单次性能跑分不同，稳定性验证关注的不是峰值有多高，而是节点在持续负载、温度波动、供电扰动、固件交互和业务压力叠加的条件下，能否保持可预测的行为。本课程讨论的对象，是 Supermicro 机架式与多节点（如 BigTwin、Ultra、GPU 系列）计算节点的整机稳定性，覆盖 CPU、内存、PCIe 设备、NVMe 存储、BMC、电源与散热子系统之间的协同表现。
需要先明确一个边界：稳定性验证不等于“跑一遍压力测试”。它是一套有交付标准的工程活动。我们把它拆成三个层次来理解。第一层是部件级稳定性，例如内存 ECC 纠错是否频繁触发、NVMe 盘是否出现掉盘或降速、GPU 是否出现 XID 报错。第二层是整机级稳定性，关注在持续满载下 CPU 频率是否被热或功耗墙压制、风扇转速曲线是否震荡、BMC 传感器读数是否跳变。第三层是系统级稳定性，即节点在集群调度、网络通信、电源冗余切换等真实环境下是否出现宕机、重启或性能塌陷。三层之间是包含关系，任何一层不达标，整机稳定性结论都不成立。
为了让验证目标可执行，我们需要先认识常见的失效模式。Supermicro 计算节点的稳定性问题，往往不是单一原因造成的，而是多个因素耦合的结果。下面这张图把验证范畴、典型失效模式与判定出口放在同一张关系图里，便于建立整体认知。
从图中可以看到，验证流程并不是单向的。当判定为“不通过”时，需要回到验证输入条件，重新审视环境温度、固件版本或负载模型是否合理，再决定是整改硬件、更新固件，还是调整测试方法。这个闭环是稳定性验证区别于普通测试的关键。
接下来定义整体验证流程框架。一个完整的稳定性验证周期通常包含五个阶段：基线采集、负载施加、过程监控、异常捕获、结论判定。基线采集是在空载或轻载下记录 CPU 温度、内存带宽、NVMe 健康度、风扇转速等初始值，作为后续对比的参照。负载施加阶段需要选择与业务匹配的负载模型，例如用 stress-ng 打 CPU 与内存、用 fio 打 NVMe 顺序与随机混合读写、用 GPU burn 类工具打加速卡，并让多类负载同时运行以模拟真实争用。过程监控阶段要持续采集 BMC 传感器、操作系统层面的频率与温度、以及 dmesg 中的硬件报错。异常捕获阶段关注的是 SEL 日志、MCE、PCIe AER、NVMe 控制器复位等事件。最后依据预设的判定阈值给出结论。
这里给出一个可直接参考的验证参数示例表，用于说明各阶段需要记录哪些字段。表中数值为教学示例，实际项目应根据机型规格和业务要求调整。
| 阶段 | 关键对象 | 示例参数 / 阈值 | 观察方式 |
|---|---|---|---|
| 基线采集 | CPU 温度、风扇转速、NVMe 健康度 | CPU 空闲 38～45℃；风扇 3000～4500 RPM | ipmitool sensor list |
| 负载施加 | CPU / 内存 / NVMe / GPU | CPU 满载 ≥ 95%；NVMe 混合读写 70/30 | stress-ng、fio、gpu-burn |
| 过程监控 | 频率、温度、功耗 | CPU 频率不低于基频 90%；温度低于 Tjmax 10℃ | turbostat、sensors、BMC 曲线 |
| 异常捕获 | SEL、MCE、AER、NVMe 复位 | UCE = 0；PCIe 链路速率不降级 | ipmitool sel list、dmesg、lspci |
| 结论判定 | 综合证据链 | 连续运行 ≥ 72h 无致命事件 | 日志归档 + 曲线复核 |
需要特别强调的是，稳定性验证中最容易被忽视的是“可复现性”。如果一次不通过无法在相同条件下复现，那么结论就缺乏工程价值。因此每次测试都必须记录固件版本、BIOS 设置、环境温度、负载脚本版本和开始结束时间戳。这些信息构成了证据链，也是后续根因定位的基础。