基于ACK集群的Slurm最佳实践FAQ_容器服务 Kubernetes 版 ACK(ACK)-阿里云帮助中心

Slurm on ACK是以容器化的方式在ACK上部署Slurm集群的部署方案，帮助客户解决Slurm集群节点环境不统一，节点增删复杂等问题。本文提供了Slurm集群在ACK中的常见问题的排查方法以及排查思路。

1. 责任共担模型

Slurm on ACK包含slurm-operator以及slurm-copilot两部分，slurm-operator仅负责创建slurm集群中Head节点、Worker节点的Pod以及关联的SVC，slurm-copilot负责在ACK与slurm-operator之间进行对账，避免节点超卖。Slurm on ACK的部署架构，详情信息，请参见基于ACK集群容器化部署Slurm以及ACK集群上实现Slurm HPC & Kubernetes负载混合调度。

在您设计和部署企业应用系统之前，请您充分理解企业自身和阿里云的安全责任边界。

Slurm on ACK架构下集群的责任共担模型如下图所示。

2. 常见问题排查

2.1. Slurm Pod相关问题

集群中没有Head Pod
Head Pod由StatefulSet管理。如果集群中不存在Head Pod，通常是由于StatefulSet创建Pod失败所致。可以通过以下步骤排查问题：
1. 检查RayCluster所在命名空间下的StatefulSet，使用kubectl describe statefulset <statefulset-name>查看与Head Pod对应的StatefulSet的事件信息。
2. 如果未找到相关StatefulSet，可进一步查看ack-slurm-operator命名空间下ack-slurm-operator的日志，以确定StatefulSet创建失败的具体原因。
集群中没有Worker Pod或Worker Pod数量不足
查看ack-slurm-operator命名空间下的ack-slurm-operator的日志确定StatefulSet创建失败的原因。

2.2. GRES相关问题

节点的k8scpu和k8smemory显示为0

如果未启用slurm-copilot，则节点无需包含k8scpu和k8smemory资源。
如果已启用slurm-copilot，按照以下步骤排查问题：
1. 在ACK中检查该节点的资源是否已被Pod全部占用。
2. 确认SlurmRestD服务是否正常运行。
3. 使用kubectl logs查看Slurm Head Pod的日志，确认是否定期出现secret/ack-slurm-jwt-token patched的日志记录。
4. 检查slurm-copilot的日志，确认是否存在访问SlurmRestD失败的情况。

2.3. 任务调度相关问题

任务提交失败，提示node configuration is not available
当提交的任务请求的资源超过节点的最大可用资源时，可能会遇到该问题。请按照以下步骤进行排查和解决：
1. 检查任务的CPU和内存请求是否超过了节点的最大可用资源。
2. 确认节点是否存在k8scpu和k8smemory资源。如果存在，执行以下操作：
  - 使用scontrol show node -F查看集群中是否存在Future类型的节点，并检查这些节点的k8scpu和k8smemory是否满足任务的资源请求。
  - 如果不满足，可通过以下命令创建Future类型的节点：
```
scontrol create node=<node-name> gres=k8scpu=<value>,k8smemory=<value> state=Future
```
任务提交失败，提示tres_per_job is not supported for now, ...
job_submit插件报错，这些任务提交方式目前未支持。详细插件功能说明，请参见ACK集群上实现Slurm HPC & Kubernetes负载混合调度。
任务提交失败，提示job must set --ntasks
job_submit插件报错，这些任务提交方式目前未支持。详细插件功能说明，请参见ACK集群上实现Slurm HPC & Kubernetes负载混合调度。
任务提交成功，但Pod处于Pending状态
通过squeue查看任务处于Pending状态原因。详细信息，请参见Squeue Pending代码说明。

2.4. 节点运维相关问题

Slurm的Head Pod或Worker Pod持续重启
查看Pod日志以确认其是否正常启动：
- 如果Pod已正常启动，检查/var/log/slurmctld.log文件，定位SlurmCTLD启动失败的具体原因。
- 如果Pod未正常启动，检查初始化脚本是否已正确执行并完成。
重建集群后分区丢失
slurm-operator创建的Head Pod在启动时默认带有-R参数，会尝试读取/var/spool/slurmctld/part.state或/var/spool/slurmctld/part.state.old文件中的记录以恢复集群状态。如果在重建集群后出现分区丢失的情况，可按照以下步骤进行排查：
1. 检查集群的/var/spool目录是否挂载了持久化存储。
2. 确认Worker Pod或Head Pod在退出前是否通过scontrol update命令更新了分区信息。
3. 检查Pod创建过程中初始化脚本及Command中是否存在更新分区的操作。