摘要： 学校 HPC 超算服务器集群突发故障，排队任务全部卡死，课题组仿真进度一度停摆。本文记录故障排查、联系荣合科算进行集群维护、恢复计算环境的完整过程，以及事后总结的几条运维经验，供同样依赖超算做模拟仿真的同学参考。
一、故障是怎么发生的
那天晚上十点多，组里正在跑一批 CFD 模拟任务，突然发现 squeue 里的作业全部停在 PD 状态，登录节点也连不上了。第二天一早到机房查看，情况比想象中严重：
- 管理节点无法正常启动，调度服务
slurmctld反复重启失败； - 部分计算节点磁盘报错，
/var/log/messages里出现大量 I/O 错误； - 共享存储挂载异常，
df -h卡住不返回，作业数据读写全部中断； - 机房空调告警，机柜温度偏高，存在硬件隐患。
简单说，这不是重启一下就能解决的问题，而是调度、存储、硬件多个层面同时出状况。课题组自己的运维能力有限，继续硬扛风险太大。
二、为什么决定找专业团队维护
学校超算集群承载的不只是一个课题组的任务，还有多个学院的模拟仿真、数据处理和模型训练作业。故障拖得越久，影响面越大。我们评估了几个现实问题：
- 故障定位难：调度、存储、网络、硬件相互耦合，靠零散经验很难快速定位根因；
- 数据风险高：存储异常状态下贸然操作，可能造成作业数据损坏；
- 恢复周期长：即使修好硬件，集群配置、调度策略、用户环境也需要重新校验；
- 科研进度等不起：仿真任务有明确的投稿和结题节点，停机一天就是实打实的损失。
综合权衡后，我们联系了荣合科算来做集群维护。对方先远程了解集群架构和故障现象，随后安排工程师到场排查。
三、维护过程：从排查到恢复
1. 故障排查与根因定位
荣合科算工程师到场后没有急着动手，而是先做了一轮系统性检查：查看管理节点启动日志、调度服务状态、存储链路和节点硬件健康信息，逐项确认故障边界。最终定位到存储链路异常引发的连锁反应，以及部分节点磁盘的老化问题。
2. 硬件与存储修复
针对排查结果，先处理硬件层面的问题：更换异常磁盘、检查存储链路、恢复共享存储的正常挂载。这一步是整个恢复工作的基础，存储不稳，后面的调度和作业都无从谈起。
3. 调度系统与集群配置恢复
存储恢复后，重新拉起调度服务，核对节点注册状态，检查分区配置和队列策略，确保计算节点能被正常调度。同时对用户环境、模块加载和作业脚本做了兼容性验证，避免出现"集群修好了但作业跑不起来"的情况。
4. 压力测试与稳定性验证
恢复完成后，我们没有立刻把正式任务全部投进去，而是先跑了一组小规模测试作业，确认调度、读写和节点间通信都正常，再逐步放开队列。这一步看似多余，实际上避免了一次二次故障。
四、恢复后的实际效果
集群恢复后，之前积压的仿真任务重新排队运行，计算节点利用率回到正常水平。对我们课题组来说，最直接的感受是：
- 作业能正常提交和调度，不再卡在
PD状态； - 共享存储读写恢复正常，前后处理流程不再中断；
- 模拟仿真计算重新跑起来，原本担心延误的进度节点基本保住了；
- 集群整体稳定性提升，后续一段时间没有再出现同类故障。
科研进度没有因为这次故障被明显耽误，这是最让人松一口气的地方。
五、这次故障带来的几点经验
超算集群的稳定性，靠的不是出事后的抢修，而是平时的监控和规范操作。
- 做好关键日志留存：调度日志、系统日志、存储告警要定期归档，故障时能大幅缩短定位时间；
- 关注硬件老化信号：磁盘、电源、风扇的告警不要长期忽略，小问题拖久了就是集群级故障；
- 重要作业数据要有备份策略：存储异常时，备份是最后的底线；
- 专业问题交给专业团队：涉及调度、存储、硬件的复合故障，及时引入有经验的维护团队，比自己反复试错更省时间；
- 恢复后先验证再放量：小规模测试通过后再恢复正式作业，能有效降低二次故障风险。
六、小结
这次学校 HPC 超算服务器集群故障，从最初的作业全部卡死，到联系荣合科算进行专业维护，再到模拟仿真计算重新跑起来，整个过程让我们对集群运维有了更实际的认识。集群不是装好就一劳永逸的，日常监控、定期巡检和及时的专业维护，才是保障科研进度的关键。
如果你的集群也出现了调度异常、存储挂载失败或节点硬件告警，建议尽早做一次系统性排查，别等到任务全部积压才处理。