诊断一个坏掉的集群

在 TT Lab 中继续学习

目标

拿到损坏的 Slurm 配置和日志后，分别确定四个原因，修复它们，并留下恢复步骤和 RCA 报告。

为什么重要

Slurm 故障的特点是一行日志就把原因说清楚了。问题在于，如果不知道查找这一行的顺序，就要花上好几天。顺序是固定的——用 sinfo 缩小范围，在 slurmctld.log 中读出原因，再到配置文件中确认那一行。

尤其重要的是区分 munge 错误的两种类型。Expired credential 是时钟问题，要去看 NTP；Invalid credential 是密钥问题，要比对密钥文件。这是完全不同的处理方式。

夹具位于 /opt/fixtures/slurm/broken/。共有 slurm.conf、gres.conf、slurmctld.log、sinfo.txt 四个文件。

步骤

创建 /root/rca 目录，把 sinfo.txt 中状态不是正常（idle/alloc/mix）的、互不相同的节点名称，每行一个写入 /root/rca/bad-nodes.txt。
找出节点定义不一致的地方，用两行写入 /root/rca/node.txt。 NODE=<문제 노드 이름> / KEY=<불일치가 난 설정 키 이름>（占位符依次为问题节点名称与出现不一致的配置键名称）
确定 munge 认证失败的类型，用两行写入 /root/rca/munge.txt。 KIND=<expired|invalid> / CAUSE=<clock|key>
把分区引用了但没有定义的节点名称，用一行写入 /root/rca/partition.txt。
把 GRES 数量不一致的情况，用两行写入 /root/rca/gres.txt。 CONFIGURED=<slurm.conf 가 선언한 그 노드의 GPU 수> / REPORTED=<gres.conf 가 실제로 가리키는 장치 수>（占位符依次为 slurm.conf 为该节点声明的 GPU 数量与 gres.conf 实际指向的设备数量）
提交已修复全部四个问题的 /root/rca/slurm.conf 和 /root/rca/gres.conf。把问题节点的 CPUs 改成与实际一致，把分区节点列表中不存在的节点删掉，并让 GRES 数量一致。（munge 是运维问题而不是配置文件问题，所以这些文件中不涉及。）
编写 /root/rca/recovery.sh。其中必须按顺序包含以下两类命令。
- 使配置变更生效的命令（scontrol reconfigure）
- 让掉出的节点恢复的命令（scontrol update NodeName=... State=RESUME）
把 /root/rca/report.txt 创建为下面 6 行。 CAUSE1=cpus-mismatch / CAUSE2=munge-<3번의 CAUSE 값> / CAUSE3=unknown-node / CAUSE4=gres-count / BAD_NODES=<1번 파일의 줄 수> / FIXED=yes（占位符依次为第 3 步中的 CAUSE 值与第 1 步文件的行数）

参考

只想在日志中看错误，用 grep -i error /opt/fixtures/slurm/broken/slurmctld.log 比较方便。
范围写法 gpu-node[01-04] 表示 4 个节点。请展开后再比较。
第 6 步的文件，建议用上一个实验的 validate.sh 检查一下。
常见错误 1：第 1 步中同一个节点出现在多个分区里，被重复计数。请只写互不相同的节点名称。
常见错误 2：第 6 步中把 GRES 数量改成与 gres.conf 一致的较大值。实际设备有 4 个，所以应把 slurm.conf 一侧改成 4。

整理症状

创建 /root/rca 目录，把 sinfo.txt 中状态不是正常（idle/alloc/mix）的、互不相同的节点名称，每行一个写入 /root/rca/bad-nodes.txt。

请数一数 sinfo 输出中状态不正常的节点。状态字符串要准确写出。

找出节点定义不一致

找出节点定义不一致的地方，用两行写入 /root/rca/node.txt。 NODE=<문제 노드 이름> / KEY=<불일치가 난 설정 키 이름>（占位符依次为问题节点名称与出现不一致的配置键名称）

日志中写着哪个节点因为什么原因掉出了。请在配置文件中确认该节点的那一行。

确定认证失败的类型

确定 munge 认证失败的类型，用两行写入 /root/rca/munge.txt。 KIND=<expired|invalid> / CAUSE=<clock|key>

munge 错误有两种类型。请直接看日志中的措辞，判断属于哪一种。

引用了未定义的节点

把分区引用了但没有定义的节点名称，用一行写入 /root/rca/partition.txt。

请把分区的节点列表与实际定义的节点作比较。必须展开范围写法。

GRES 数量不一致

把 GRES 数量不一致的情况，用两行写入 /root/rca/gres.txt。 CONFIGURED=<slurm.conf 가 선언한 그 노드의 GPU 수> / REPORTED=<gres.conf 가 실제로 가리키는 장치 수>（占位符依次为 slurm.conf 为该节点声明的 GPU 数量与 gres.conf 实际指向的设备数量）

分别数出两个配置文件中的数量并作比较。日志中也打印了数字。

提交修复版本

提交已修复全部四个问题的 /root/rca/slurm.conf 和 /root/rca/gres.conf。把问题节点的 CPUs 改成与实际一致，把分区节点列表中不存在的节点删掉，并让 GRES 数量一致。（munge 是运维问题而不是配置文件问题，所以这些文件中不涉及。）

四个问题都必须修复。可以复用上一个实验中编写的检查脚本。

编写恢复步骤

编写 /root/rca/recovery.sh。其中必须按顺序包含以下两类命令。

使配置变更生效的命令（scontrol reconfigure）
让掉出的节点恢复的命令（scontrol update NodeName=... State=RESUME）

让配置生效和让节点恢复是两条不同的命令。顺序也很重要。

RCA 报告

把 /root/rca/report.txt 创建为下面 6 行。 CAUSE1=cpus-mismatch / CAUSE2=munge-<3번의 CAUSE 값> / CAUSE3=unknown-node / CAUSE4=gres-count / BAD_NODES=<1번 파일의 줄 수> / FIXED=yes（占位符依次为第 3 步中的 CAUSE 值与第 1 步文件的行数）

用规定的键整理出四个原因。值必须是前面步骤中确定下来的内容。