管理 Slurm#

简介#

工作负载管理是在系统上提交和控制工作。Slurm 是 DGX SuperPOD 上使用的工作负载管理系统。它是一个用于 Linux 集群的开源作业调度系统，最常用于高性能计算 (HPC) 应用程序。本节将介绍作为 DGX SuperPOD 用户开始使用 Slurm 的一些基础知识。有关 Slurm 使用的更多高级信息，请参阅 Slurm 文档。

工作负载管理系统的基本流程是用户向队列提交作业。作业是要执行的工作的集合。提交的内容是一个命令，可以由 shell 脚本或二进制文件定义。Shell 脚本是最常见的，因为一个作业通常由许多不同的命令组成。

系统将获取所有已提交但尚未运行的作业，查看系统状态，然后将这些作业映射到可用资源。此工作流程允许用户管理大型组中的工作，系统将找到最佳方式来排序作业，以最大化系统利用率或系统管理员可以配置的其他指标。

关键 Slurm 术语在表 10中详细说明。

表 10. Slurm 关键术语

术语

定义

作业 (job)

可以在集群上调度的最小工作单元。每个作业请求特定数量的计算节点，并且在达到请求的节点数后可以由 Slurm 启动。

批处理作业 (batch job)

使用作业脚本提交到集群，作业脚本是可执行文件，例如 bash 脚本。Slurm 将等待请求数量的节点可用，然后将这些节点分配给作业，并在组中的第一个节点上运行脚本。然后，脚本中的命令负责在分配中的节点上运行用户工作负载。可以使用 sbatch 命令提交批处理作业。当使用 sbatch 提交作业时，命令将立即返回并将作业放入队列中。

交互式作业 (interactive job)

提交到集群并请求伪终端，以便用户可以交互式地在集群上工作，而无需编写脚本。可以使用带有 –pty 标志的 srun 命令提交交互式作业。当您以交互方式提交作业时，srun 命令将阻塞，直到请求的节点可用，然后为用户提供交互式终端。

Slurm 控制器 (Slurm controller)

该服务器负责跟踪集群中的所有服务器、接受作业提交以及在集群上调度工作。控制器运行 slurmctld 守护程序以管理集群上的工作，并运行 slurmdbd 守护程序以跟踪作业记帐数据库。

计算节点 (compute node)

计算节点（或简称节点）是集群中运行作业的单个服务器。例如，单个 DGX A100 系统就是一个 Slurm 节点。每个节点都运行一个 slurmd 守护程序，用于管理在该节点上运行的作业。

登录节点 (login node)

常规用户通过 SSH 登录以向集群提交工作的服务器。登录节点不运行 slurmd 或 slurmctld 守护程序，但安装了 Slurm 工具，以便用户可以查询作业信息和提交工作。

分区 (partition)

Slurm 中计算节点的逻辑组。每个计算节点可以属于多个分区。作业被提交以在特定分区中运行，并将使用该组中的节点。

队列 (queue)

当前正在运行或正在等待分配节点以运行的作业列表。如果在提交作业时资源可用，它将立即运行。如果没有足够的资源来运行作业，它将被放入队列中并等待直到资源可用。

检查节点状态#

使用 sinfo 命令检查集群上所有节点的状态。

 1dgxa100@pg-login-mgmt001:~$ sinfo
 2PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
 3debug        up 1-00:00:00      1 drain* dgx049
 4debug        up 1-00:00:00      1  drain dgx017
 5debug        up 1-00:00:00      4  alloc dgx[070,081,090,097]
 6batch*       up 1-00:00:00     96  alloc dgx[001-012,018-048,050-069,091,098-129]
 7batch*       up 1-00:00:00     38   idle dgx[013-016,071-080,082-089,092-096,130-140]
 8su01         up 1-00:00:00     15  alloc dgx[001-012,018-020]
 9su01         up 1-00:00:00      4   idle dgx[013-016]
10su02         up 1-00:00:00     20  alloc dgx[021-040]
11su03         up 1-00:00:00     19  alloc dgx[041-048,050-060]
12su04         up 1-00:00:00      9  alloc dgx[061-069]
13su04         up 1-00:00:00     10   idle dgx[071-080]
14su05         up 1-00:00:00      4  alloc dgx[091,098-100]
15su05         up 1-00:00:00     13   idle dgx[082-089,092-096]
16su06         up 1-00:00:00     20  alloc dgx[101-120]
17su07         up 1-00:00:00      9  alloc dgx[121-129]
18su07         up 1-00:00:00     11   idle dgx[130-140]

sinfo 列出集群中的所有分区，然后按状态对每个节点列表进行分组。状态说明在表 11中。

表 11. sinfo 状态说明

状态

描述

idle (空闲)

节点在线，当前未运行作业，并且可用于运行作业

alloc (已分配)

节点在线并已分配给正在运行的作业

drain (排空)

节点在线，但已被标记为“排空”，以防止作业在它们上面运行。这可能是因为它们未通过健康检查，或者因为管理员手动将它们标记为排空，以便管理员可以进行维护。

drng (正在排空)

节点正在“排空”：它们已被标记为排空，但仍有作业在它们上面运行。当该作业完成时，将不会有更多作业在它们上面运行。

down (宕机)

节点未在线，并且 Slurm 无法联系它们

boot (启动中)

节点正在被 Slurm 重新启动

可以使用 -p option 将 sinfo 限制为仅显示有关特定分区的信息

1dgxa100@pg-login-mgmt001:~$ sinfo -p batch
2PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
3batch*       up 1-00:00:00     32  alloc dgx[098-129]
4batch*       up 1-00:00:00    102   idle dgx[001-016,018-048,050-069,071-080,082-089,091-096,130-140]

它还可以仅显示宕机或排空的节点，并通过使用 -R option 显示它们处于该状态的原因

1dgxa100@pg-login-mgmt001:~$ sinfo -R
2REASON               USER      TIMESTAMP           NODELIST
3crashing on boot     root      2020-12-04T10:33:15 dgx049
4NHC: check_hw_ib:  N root      2020-12-04T10:32:42 dgx017

sinfo -R 命令仅显示失败原因的几个字符。要查看有关原因的更详细信息，请运行以下命令

1dgxa100@pg-login-mgmt001:~$ scontrol show node dgx017 | grep Reason
2   Reason=NHC: check_hw_ib:  No IB port mlx5_4:1 is ACTIVE (LinkUp 40 Gb/sec). [root@2020-12-04T10:32:42]

显示详细节点信息#

有关 Slurm 节点的详细信息通过使用 scontrol 命令显示

 1dgxa100@pg-login-mgmt001:~$ scontrol show node dgx017
 2NodeName=dgx017 Arch=x86_64 CoresPerSocket=64
 3   CPUAlloc=0 CPUTot=256 CPULoad=1.78
 4   AvailableFeatures=(null)
 5   ActiveFeatures=(null)
 6   Gres=gpu:8(S:0-1)
 7   NodeAddr=dgx017 NodeHostName=dgx017 Version=20.02.4
 8   OS=Linux 5.4.0-54-generic #60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020
 9   RealMemory=1031000 AllocMem=0 FreeMem=1017487 Sockets=2 Boards=1
10   State=DOWN+DRAIN ThreadsPerCore=2 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A
11   Partitions=debug
12   BootTime=2020-12-05T19:26:50 SlurmdStartTime=2020-12-05T19:30:32
13   CfgTRES=cpu=256,mem=1031000M,billing=256
14   AllocTRES=
15   CapWatts=n/a
16   CurrentWatts=0 AveWatts=0
17   ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
18   Reason=NHC: check_hw_ib:  No IB port mlx5_4:1 is ACTIVE (LinkUp 40 Gb/sec). [root@2020-12-04T10:32:42]

排空节点#

排空节点将阻止任何进一步的作业在节点上运行。如果节点不健康或需要不运行作业的维护工作，则应排空节点。

节点可以由 Slurm；NHC；或管理员手动排空。

手动排空节点

1[headnode01->device]% use dgx-001
2[headnode01->device[dgx-001]]% drain
3Engine            Node             Status           Reason
4----------------  ---------------- ---------------- --------------------
5slurm-dgxsuperpod dgx-001                Drained          Drained by CMDaemon

取消排空您想要再次在其上运行作业的节点

1[headnode01->device[dgx-001]]% undrain
2Engine            Node             Status           Reason
3----------------  ---------------- ---------------- ----------------
4slurm-dgxsuperpod dgx-001

更新 Slurm 配置#

Slurm 使用 cm-wlm-setup 进行配置。这将在/cm/shared/apps/slurm/var/etc/slum中设置 slurm.conf 文件。该文件共享到集群中的每个节点，并且在每个节点上都具有相同的内容。

slurm.conf 的大多数选项都不在本文档的范围之内。要阅读有关配置 Slurm 的可用选项，请参阅 slurm.conf 文档。

注意

由于 Slurm 由 BCM 管理，因此手动对此文件所做的任何更改都将被覆盖。应使用基本视图或 cmsh 进行更改。

Slurm Prolog 和 Epilog#

工作负载管理器在作业执行之前运行 prolog 脚本，并在作业执行之后运行 epilog 脚本。这些脚本的用途可以包括

  • 在提交可能使用节点的作业执行之前，检查节点是否已准备就绪。

  • 以某种方式准备节点以管理作业执行。

  • 在作业执行结束后清理资源。

尽管有全局 prolog 和 epilog 脚本，但应避免编辑它们。无法使用基本视图或 cmsh 设置脚本。相反，脚本必须由管理员放置在软件映像中，并从映像更新相关节点。

Prolog 和 Epilog 脚本的详细信息#

即使不建议这样做，但一些管理员可能仍然希望直接链接和编辑脚本以满足自己的需求，而不是通过基本视图或 cmsh 前端。以下是有关 prolog 脚本如何工作的更详细说明。

当使用 cm-wlm-setup 或基本视图设置向导配置 Slurm 时，它被配置为运行位于/cm/local/apps/cmd/scripts/prolog中的通用 prolog 和位于/cm/local/apps/cmd/scripts/epilog中的通用 epilog。通用 prolog 和 epilog 脚本在特殊目录中为特定的工作负载管理器调用一系列脚本。

目录的路径格式为

  • /cm/local/apps/slurm/var/prologs/

  • /cm/local/apps/slurm/var/epilogs/

在这些目录中，脚本以具有与之关联的后缀和前缀的名称存储，这使得它们以特殊方式运行，如下所示

  • prolog/epilog 目录中使用的后缀

    • -prejob 脚本在所有作业之前运行。

    • -cmjob 脚本在云中运行的作业之前运行。

  • prolog/epilog 目录中使用的前缀：00- 到 99-。

数字前缀确定脚本执行的顺序，数字较低的脚本较早运行。因此，脚本名称可能如下所示

  • 01-prolog-prejob

  • 10-prolog-cmjob

prolog/epilog 脚本的返回值具有以下含义

  • 0：运行目录中的下一个脚本。

  • 非零返回值：不从 prolog/epilog 目录执行进一步的脚本。

通常，prolog/epilog 目录中的脚本不是真正的脚本，而是一个符号链接，该符号链接指向位于不同目录中的真实文件。然后，通用脚本能够处理对符号链接的期望。符号链接的名称和目标文件通常暗示脚本预期执行的操作。

例如，如果在 cm wlm 设置配置期间将任何健康检查标记为作为 prejob 检查运行，则每个 PBS 工作负载管理器变体都在 prolog 目录/cm/local/apps/<workload manager>/var/prologs/中使用符号链接 01-prolog-prejob。符号链接链接到的脚本是 /cm/local/apps/cmd/scripts/prolog-prejob。

在这种情况下，脚本预计在作业之前运行。

1[root©headnode apps]# pwd
2/cm/local/apps
3[root©headnode apps]# ls -l *pbs*/var/prologs/ openpbs/var/prologs/:
4total  0
5lrwxrwxrwx 1 root root ... 01-prolog-prejob -> /cm/local/apps/cmd/scripts/prolog-prejob
6pbspro/var/prologs/:
7total  0
8lrwxrwxrwx 1 root root ... 01-prolog-prejob -> /cm/local/apps/cmd/scripts/prolog-prejob

Epilog 脚本（在作业运行后运行）的位置是 /cm/local/apps/<workload manager>/var/epilogs/。Epilog 脚本名称遵循与 prolog 脚本名称相同的执行顺序模式。

01-prolog-prejob 符号链接由集群管理器在每个计算节点上创建和删除，其中在工作负载管理器实体中启用了 prejob。每个此类实体都提供一个“启用 Prejob”参数，该参数会影响符号链接的存在

1[head->wlm[openpbs]]% get enableprejob yes
2[head->wlm[openpbs]]%

当至少选择一个健康检查作为 prejob 检查时，cm-wlm-setup 会将此参数设置为 yes。如果在执行 cm wlm 设置之前将任何健康检查配置为 prejob 检查，并且管理员对该健康检查进行了复选标记，则 prejob 被视为已启用。

Prolog 和 Epilog 脚本的工作负载管理器配置#

集群管理器在工作负载管理器设置期间使用 cm-wlm-setup 配置通用 prolog 和 epilog。管理员可以通过在工作负载管理器的配置中使用适当的参数，通过在本地 prolog 和 epilog 目录中创建符号链接来配置 prolog 和 epilog。

默认情况下，通用 prolog 和 epilog 配置为在 Slurm 的作业计算节点上运行（每个作业每个节点运行一次）。

可以使用 cmsh 或基本视图配置以下 prolog 和 epilog 参数

  • Prolog Slurmctld：在授予新作业分配之前要执行的程序的完全限定路径。该程序在分配了 slurm 服务器角色的同一节点上执行。该路径对应于 slurm.conf 中的 PrologSlurmctld 参数。

  • Epilog Slurmctld：在作业分配终止时要执行的程序的完全限定路径。该程序在分配了 slurm 服务器角色的同一节点上执行。与 slurm.conf 中的 EpilogSlurmctld 参数相对应。

  • Prolog: the fully 要在作业计算节点上执行的程序的完全限定路径，在授予新作业或步骤分配之前。该程序对应于 Prolog 参数，默认情况下指向通用 prolog。如果 Prolog 标志参数包含标志 Alloc（默认值），则此 prolog 在作业的每个节点上运行，否则仅在作业的第一个节点上执行。

  • Epilog: the fully 在作业分配释放时要在作业计算节点上执行的程序的完全限定路径。

列出队列中的 Slurm 作业#

当前在集群上运行或在队列中等待运行的作业可以使用 squeue 命令显示

1dgxa100@pg-login-mgmt001:~$ squeue
2             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
3             25668     debug submit_h  dgxa100 PD       0:00      1 (Priority)
4             25669     debug submit_h  dgxa100 PD       0:00      1 (Priority)
5             25670     debug submit_h  dgxa100 PD       0:00      1 (Priority)
6             25592     debug submit_h  dgxa100  R       1:13      1 dgx081
7             25593     debug submit_h  dgxa100  R       1:13      1 dgx090
8             25594     debug submit_h  dgxa100  R       1:13      1 dgx097

squeue 输出的第五列是作业状态（标题中的 ST）

  • 正在运行的作业将显示为 R 状态。最后一列将列出作业正在运行的节点。

  • 等待运行的作业将显示为 PD 状态，表示待处理。最后一列将显示作业尚未运行的原因。这可能是某些原因，例如 Resources（如果没有足够的节点可用）或 Priority（如果作业正在等待队列中优先级更高的另一个作业）。

有关可用作业状态以及过滤输出的方法的信息，请参阅 squeue 文档。

取消 Slurm 作业#

使用 scancel 命令取消 Slurm 作业。

1$ scancel <job-id>

如果取消正在运行的作业，Slurm 将向作业中的所有进程发送 SIGTERM 信号。如果作业进程在一定秒数（默认情况下为 30 秒，使用 KillWait 配置）内未结束，则 Slurm 将发送 SIGKILL 信号。

如果取消待处理的作业，Slurm 将仅将其从队列中删除。

管理作业上的参数#

每个作业都有几个与其关联的配置参数，例如时间限制或它正在运行的分区。可以使用以下命令查看这些参数

 1dgxa100@pg-login-mgmt001:~$ scontrol show job 25632
 2    JobId=25632 JobName=submit_hpl_cuda11.0.sh
 3    UserId=dgxa100(13338) GroupId=dgxa100(13338) MCS_label=N/A
 4    Priority=44385 Nice=0 Account=compute-account QOS=normal
 5    JobState=PENDING Reason=Priority Dependency=(null)
 6    Requeue=1 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
 7    RunTime=00:00:00 TimeLimit=02:00:00 TimeMin=N/A
 8    SubmitTime=2020-12-06T06:36:59 EligibleTime=2020-12-06T06:36:59
 9    AccrueTime=2020-12-06T06:36:59
10    StartTime=2020-12-06T22:04:00 EndTime=2020-12-07T00:04:00 Deadline=N/A
11    SuspendTime=None SecsPreSuspend=0 LastSchedEval=2020-12-06T08:04:40
12    Partition=debug AllocNode:Sid=pg-login-mgmt001:1107071
13    ReqNodeList=dgx081 ExcNodeList=(null)
14    NodeList=(null) SchedNodeList=dgx081
15    NumNodes=1-1 NumCPUs=8 NumTasks=8 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
16    TRES=cpu=8,node=1,billing=8
17    Socks/Node=* NtasksPerN:B:S:C=8:0:*:1 CoreSpec=*
18    MinCPUsNode=8 MinMemoryCPU=0 MinTmpDiskNode=0
19    Features=(null) DelayBoot=00:00:00
20    OverSubscribe=NO Contiguous=0 Licenses=(null) Network=(null)
21    Command=/mnt/test/deepops/workloads/burn-in/submit_hpl_cuda11.0.sh
22    WorkDir=/mnt/test/deepops/workloads/burn-in
23    StdErr=/mnt/test/deepops/workloads/burn-in/results/1node_dgxa100_20201206063703/1node_dgxa100_20201206063703-25632.out
24    StdIn=/dev/null
25    StdOut=/mnt/test/deepops/workloads/burn-in/results/1node_dgxa100_20201206063703/1node_dgxa100_20201206063703-25632.out
26    Power=
27    TresPerNode=gpu:8
28    MailUser=(null) MailType=NONE

其中一些参数可以动态更新。例如，要延长可能无法在允许的时间内完成的作业的时间限制，请使用 scontrol update 命令

1dgxa100@pg-login-mgmt001:~$ scontrol update job id=25632 timelimit=02:10:00

有关查看或修改 Slurm 配置的更多信息，请参阅 scontrol 文档。

其他资源#

Slurm 提供了许多高级功能，可以提供对作业调度、系统使用、用户和组帐户以及系统使用公平性的更精细控制。有关更多信息，请参阅以下链接

在本页中