发帖
雷达卡
Slurm管理员应急手册：存储挂死与僵尸节点处理指南
当集群中的存储系统出现严重延迟或中断时，计算节点上的任务可能陷入无响应状态。此时需快速响应，防止问题扩散并逐步恢复服务。
一、问题识别与初步判断
若发现多个任务长时间停滞在运行状态但无实际进展，且相关进程处于不可中断睡眠（D状态），则极可能是后端共享存储出现问题。常见表现为：
- 大量作业卡在执行中，但CPU利用率极低；
- 进程状态显示为
D（Disk Sleep）； - 常规信号无法终止这些进程；
RUNNINGDkill -9上述现象表明I/O路径受阻，应立即启动应急流程。
二、第一阶段：紧急隔离与止损操作
在未解决底层存储故障前，首要目标是阻止更多任务被调度至已受影响的环境，避免“雪上加霜”。
1. 隔离故障节点或分区
根据影响范围选择封锁策略：
方案A：整个分区受影响（如所有节点共用同一存储）
scontrol update PartitionName=batch State=DOWN
方案B：仅个别节点异常（例如 cn04）
scontrol update NodeName=cn04 State=DRAIN Reason="Storage I/O latency issue"
注明原因有助于团队协作和后续审计。
2. 暂停待调度任务队列
防止新的Pending任务被错误分配到问题区域：
squeue -t pending -h -o %i | xargs -n 1 scontrol hold
3. 尝试重启计算节点
部分情况下，节点自身对网络存储的挂载已失联，可尝试本地恢复：
mount -t nfs -o nolock -o tcp -o nfsvers=3 xxx.xxx.xxx.xxx:/public /public
若该命令失败，说明问题不在客户端配置层面，需进一步检查服务端情况，并进入下一阶段排查。
三、第二阶段：存储服务器端诊断与修复
当前症状通常源于以下三类核心问题，请登录存储服务器逐一排查。
1. 磁盘负载过高或硬件故障
物理磁盘存在坏道可能导致RAID控制器频繁重试，引发整体IO延迟飙升。
查看系统负载与设备使用情况：
top # 观察load average是否异常
iostat -x 1 # 关注 %util 和 await 指标
若 await 值达到数百甚至上千毫秒：
await表明底层存储已不堪重负。此时应检查RAID卡日志以定位具体故障磁盘：
megaclistorcli确认后尽快更换损坏硬盘，重建阵列。
2. 网络带宽饱和
是否存在用户执行大规模读写操作（如海量小文件处理或压力测试）导致网络拥塞？
实时监控网络流量：
iftop -i eth0
netstat -an | grep ESTABLISHED | wc -l
dd若发现某IP占用极高带宽，可临时断开其连接或限制对应任务资源。
3. 存储服务进程僵死
NFS或Lustre等服务本身可能出现线程卡死、锁等待等问题。
检查NFS服务线程池状态：
cat /proc/fs/nfsd/threads
应对措施：
- 轻度卡顿：尝试重新加载NFS模块或重启nfsd服务（风险较低）；
- 严重卡死：必须重启存储服务时，需预判后果——所有客户端可能出现Stale File Handle错误，必要时需同步重启计算节点。
systemctl reload nfs-server四、第三阶段：客户端僵尸节点清理
存储恢复后，部分计算节点仍可能存在残留进程或挂载异常，需手动干预。
1. 清理卡死任务（Job 220311 类似案例）
首先尝试正常取消作业：
scancel 220311
登录对应节点尝试强制终止进程：
ssh cn04
kill -9 <PID>
注意：若进程处于D状态，则无法接收任何信号。
kill -92. 使用“懒卸载”恢复节点可用性
当挂载点因忙而无法卸载时，可采用lazy unmount方式解除阻塞：
umount -l /share
参数 -l 表示延迟实际断开，在进程释放引用后自动完成卸载。此举能有效避免SSH会话被锁定。
3. 最终解决方案：重启计算节点
对于持续处于D状态、无法恢复的节点，重启是最彻底有效的手段。
推荐通过管理接口远程硬重启：
ipmitool -H cn04-ipmi -U admin -P password power cycle
或在节点尚可操作时直接执行本地重启。
完成以上步骤后，逐步恢复Partition状态，解禁节点，并监控新提交任务的运行稳定性。
Stale file handle第四阶段：善后与恢复
确认节点状态
在节点完成重启并重新上线后，需立即验证共享存储挂载是否已恢复正常。可通过以下命令进行检测：
ssh cn04 "df -h /share && touch /share/testfile && rm /share/testfile"该操作将检查挂载点可访问性，并测试文件的读写与删除功能，确保文件系统处于可用状态。
恢复节点运行
确认节点无异常后，使用 Slurm 控制命令将其状态恢复为可调度：
scontrol update NodeName=cn04 State=RESUME此举将使该计算节点重新加入资源池，接受新的作业任务。
处理失败任务
针对因故障而中断的作业（如 Job 220311），应向相关用户发送通知：
由于存储系统出现异常，您的任务 220311 已无法继续执行，系统已重启对应节点以恢复服务。请重新提交该作业。
随后，清理残留任务状态，并释放此前被阻塞的排队作业：
scontrol release <job_list>soft经验总结：为何“响应缓慢”比“完全中断”更危险？
当存储服务完全中断（如网络不可达）时，NFS 客户端通常会根据挂载参数快速返回错误或超时退出，具体行为取决于挂载选项是使用硬挂载（hard）还是软挂载（soft）。
hard然而，当存储处于“高延迟”或“响应极慢”的状态时，若采用默认的硬挂载（hard mount）方式，NFS 客户端会持续重试请求，导致以下严重后果：
- 系统负载急剧上升：每一个等待 IO 操作完成的进程都会被计入系统 Load Average。例如，cn04 节点的负载可能因此飙升至 100 以上。
- 服务连锁失效：若 Slurmd 守护进程本身也需要向该共享存储写入日志，则其自身也会被阻塞，最终导致管理节点误判该节点失联，触发不必要的故障转移。
应对建议
在排除硬件或网络故障后，应进一步排查引发存储性能下降的根本原因。重点关注是否存在某个用户的作业正在进行高强度 IO 操作，尤其是涉及大量小文件的频繁读写行为——这类操作通常是导致存储响应变慢的主要源头。
京公网安备 11010802022788号
