节点掉了之后要读的顺序
一句话总结
Slurm障碍诊断**sinfo缩小范围slurmctld.log大部分都以阅读理由**结束。
为什么需要这个？
收到“工作无效”的报告后，有几个地方可以确认。工作是否在队列中等待，节点是否丢失，认证是否被破坏，设置是否错误。但是是有顺序的。
怎么行动
第1阶段——整体状态
sinfo
sinfo -R # DRAIN/DOWN 이유만
sinfo -N -l # 노드별 상세
sinfo -R这个特别有用。只显示缺失的节点和其原因字符串。
节点状态的含义。
| 状态 | 意思 |
|---|---|
idle |
正常，无工作 |
alloc/mix |
全部/部分资源被分配 |
drain |
管理员或系统删除。不自动返回 |
down |
没有回复或注册失败 |
inval |
设置与实际不符 |
fail/failg |
报告硬件问题 |
第2阶段——阅读理由
scontrol show node gpu-node01 | grep -i reason
tail -100 /var/log/slurm/slurmctld.log
tail -100 /var/log/slurm/slurmd.log # 해당 노드에서
日志中出现的代表性信息和原因。
| 消息 | 原因 |
|---|---|
Low socket*core*thread count |
CPUs插座×核心×线程不一致 |
Low RealMemory |
设置的内存比节点的实际大 |
gres/gpu count reported lower than configured |
slurm.conf哇gres.conf数量不一致 |
Munge decode failed: Expired credential |
时钟不一致 |
Munge decode failed: Invalid credential |
身高不一致 |
partition X has unknown node Y |
未定义的节点被分区引用 |
Node unexpectedly rebooted |
节点重新启动后注册 |
区分munge错误的两种类型很重要。Expired credential因为是钟表问题，所以看了NTP，Invalid credential因为是身高问题/etc/munge/munge.key进行比较。完全不同的应对。
3阶段——工作无法进行时
节点没问题，但如果工作只是等待的话squeue看REASON列。
| REASON | 对应 |
|---|---|
Resources |
请求的资源还没有剩余。正常等待 |
Priority |
优先级高的工作在前面 |
Dependency |
等待先行工作 |
PartitionTimeLimit |
--time超过了该分区最大值 |
PartitionNodeLimit |
请求节点数超过了分区限制 |
ReqNodeNotAvail |
指定的节点不可使用 |
QOSMax... |
受到QOS限制 |
**PartitionTimeLimit相同的东西永远等待。**即使产生资源，也绝对不会开始，所以用户必须修改请求后重新提交。
4阶段——恢复
如果解决了原因，则明确地恢复节点。
scontrol update NodeName=gpu-node01 State=RESUME
scontrol update NodeName=gpu-node[01-03] State=RESUME
scontrol reconfigure # 설정 변경 반영
如果修改了设置文件，请在部署到所有节点后scontrol reconfigure必须这样做。如果只有一个节点不同，那个节点就会再次掉落。
提前抓住节点丢失的情况
在贫民窟运营中耗费最多时间不是工作失败，而是节点安静地 是掉落。用户只觉得“变慢了”，原因是半个群集在玩 有。
错过的原因总是被记录下来。
sinfo -R --format="%50E %12U %19H %N" # 사유, 지운 사람, 시각, 노드
scontrol show node <노드> | grep -E 'State|Reason|CfgTRES|AllocTRES'
节点是drain成为这个的常见原因三。
| 理由 | 实际原因 |
|---|---|
Low RealMemory |
设置的内存值比实际大。内核会稍微占用一些空间。 |
gres/gpu count too low |
一个GPU消失了(nvidia-smi确认为） |
Kill task failed |
工作流程没有结束，节点没有整理。 |
第一个特别经常出现。slurm.conf如果把物理内存值直接写在上面，
由于内核和预约区域，实际可用容量有点少，节点会立即掉线。slurmd -C
使用输出值，然后在那里再降低一点。
slurmd -C # 이 노드가 보고하는 실제 값
更改设置后确认传播。slurm.conf所有的节点都必须相同，
变了之后scontrol reconfigure需要。只要有一个节点不同，那个节点就会
一直掉出来，症状看起来像是那个节点的问题。
**整理失败通常是因为进程没有结束。**如果epilog没有结束，节点就会
completing被困在里面。UnkillableStepTimeout超过的话节点就会变成drain。
如果经常这样，那么文件系统（特别是NFS）的队列中进程处于D状态，
要修的地方不是贫民窟，而是仓库。
**复活时删除理由。**只要恢复状态并留下理由，在下一次健康检查时 又掉下来了。
scontrol update NodeName=<노드> State=RESUME
在现场相遇的样子
**时钟问题会定期复发。**如果NTP死机或防火墙阻止123端口，几天内会逐渐失调，然后有一天munge开始拒绝。最好在群集监控中设置时钟同步状态。
DRAIN 不删除理由字符串而留下的习惯。scontrol update ... State=RESUME只要做，理由就会消失。为了调查记录，在某个地方留下理由后返回的队伍很多。
下次实习要做的事情
收到包含故障设置和日志的照片，分别确定四个原因，制作修改版，填写恢复程序，并提交RCA报告。