维护完成后节点可以 SSH 登录、系统服务大多为绿色，并不意味着它已经适合重新承载 GPU 作业。驱动模块可能未加载，设备枚举可能缺失，Fabric Manager 与驱动版本可能不匹配，容器运行时可能还没有恢复设备注入，调度器却已根据旧心跳把节点标为可用。可靠流程应先禁止调度，由硬件到应用逐层验证，最后才解除隔离。
启动前先明确维护改变了什么
内核、驱动、固件、BIOS、Fabric Manager、容器运行时或编排代理的变更，检查重点不同。维护单必须列出变更前版本、目标版本、重启原因和预期设备数量。若只是电源维护，也不能跳过设备基线，因为断电重启可能暴露枚举或链路问题。节点从启动开始保持 cordon 或等价隔离，避免健康检查尚未完成就接收任务。
从操作系统和设备枚举开始
确认内核、时间、文件系统、网络和必要服务正常，再核对 GPU 数量、UUID、PCIe 状态、错误记录和持续性告警。枚举序号变化不一定是故障，但稳定 UUID 与物理位置映射必须一致。若某张设备缺失或出现新的 Xid/ECC 事件，应停止后续放行。不要通过重启多次把偶发枚举问题“刷好”后直接投入生产，而应保留每次状态并查明条件。
Fabric Manager 要验证版本与实际状态
需要 Fabric Manager 的平台，应确认服务运行、版本与驱动组合符合当前文档，且相关 Fabric 状态正常。进程存在不等于管理对象全部可用，应查看服务日志和平台查询结果。升级驱动而遗漏 Fabric Manager，或包仓库安装了不同分支，可能在节点内多 GPU 通信时才暴露。不存在该组件需求的平台也不应机械安装，是否需要由具体平台说明决定。
容器和调度层必须重新发现资源
确认宿主设备后，验证 NVIDIA Container Toolkit 或驱动容器、设备插件和节点代理。运行一个受控容器检查设备枚举与基础 CUDA，再观察调度器上报的资源数量、标签和健康状态。旧 Pod、残留 CDI 规范或设备插件缓存可能造成资源视图不一致。平台应比较宿主真实设备、容器可见设备和调度资源三者，而不是只看 DaemonSet Ready。
最小业务测试比空闲健康更有价值
在正式放行前运行短时诊断与代表性计算，必要时覆盖多 GPU 通信和网络路径。测试目标是发现初始化、内存、互连和容器问题，不是追求峰值分数。结果与同类节点基线比较，偏差超出批准范围就继续隔离。测试结束还要确认进程、显存和临时资源释放，防止验收任务影响首个生产作业。
节点放行后仍应设置观察期，将最初若干生产作业的初始化、错误事件和性能分布与同类节点比较。若出现持续偏差，平台应自动重新隔离并保留现场，而不是让调度器继续用重试掩盖问题。观察期结束需要明确的完成记录。
逐层放行步骤
- 保持调度隔离，记录内核、驱动、固件、服务和预期设备清单。
- 核对 GPU UUID、PCIe、错误事件与平台所需 Fabric 状态。
- 验证容器内设备、运行时注入、设备插件和调度资源数量一致。
- 执行单 GPU、必要的多 GPU 与网络代表性测试，并与同类节点基线比较。
- 观察稳定窗口后解除隔离，跟踪首个生产任务并保留回滚触发条件。
Fabric Manager 的适用平台、安装、版本和服务行为可参考 NVIDIA Fabric Manager User Guide。节点是否需要该组件以及具体检查项必须以实际 GPU 平台为准。本文强调放行门禁，不假设所有服务器具有相同互连或服务结构。
WeChat
Profile