本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
Slurm多队列模式指南
以下各节提供了有关将 Surm 群集与扩展架构结合使用的概述。
概览
扩展架构基于Slurm的云计划指南
云节点生命周期
在整个生命周期中,云节点进入几个(如果不是全部)以下状态:POWER_SAVING
、POWER_UP
(pow_up
),ALLOCATED
(alloc
),以及POWER_DOWN
(pow_dn
)。在某些情况下,云节点可能会进入OFFLINE
状态。以下列表详细介绍了云节点生命周期中这些状态的几个方面。
-
中的一个节点
POWER_SAVING
state此时会显示~
后缀(例如idle~
) 在sinfo
. 在此状态下,没有 EC2 实例支持该节点。但是,Slurm仍然可以将作业分配给节点。 -
正在过渡到
POWER_UP
state此时会显示#
后缀(例如idle#
) 在sinfo
. 节点自动转换为POWER_UP
状态,什么时候Slurm将作业分配给POWER_SAVING
状态。或者,也可以将节点转换到
POWER_UP
使用手动状态scontrol update nodename=
命令。在这个阶段,nodename
state=power_upResumeProgram
被调用、启动和配置 EC2 实例,并且节点将转换为POWER_UP
状态。 -
当前可以使用的节点出现没有后缀(例如
idle
) 在sinfo
. 设置完节点并加入群集后,它就可以运行作业。在此阶段,节点配置正确并可供使用。一般来说,我们建议 EC2 实例的数量与可用节点的数量相同。在大多数情况下,在创建群集之后,静态节点可用。
-
正在过渡到
POWER_DOWN
state此时会显示%
后缀(例如idle%
) 在sinfo
. 动态节点自动输入POWER_DOWN
之后的状态ScaledownIdletime
. 相比之下,在大多数情况下,静态节点没有关闭电源。但是,节点可以放置在POWER_DOWN
使用手动状态scontrol update nodename=
命令。在此状态下,与节点关联的实例将被终止,并将该节点设置回nodename
state=powering_downPOWER_SAVING
状态并在之后可以使用ScaledownIdletime
.这些区域有:
ScaledownIdletime
设置将保存到Slurm配置SuspendTimeout
设置。 -
脱机的节点此时会显示
*
后缀(例如down*
) 在sinfo
. 如果Slurm控制器无法联系该节点,或者如果静态节点被禁用且备份实例被终止。
请考虑以下内容所示的节点状态sinfo
示例。
$
sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 4 idle~ efa-dy-efacompute1-[1-4] efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 1 idle% gpu-dy-gpucompute1-1 gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10] ondemand up infinite 2 mix# ondemand-dy-ondemandcompute1-[1-2] ondemand up infinite 18 idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
这些区域有:spot-st-spotcompute2-[1-2]
和efa-st-efacompute1-1
节点已经设置了备份实例并可供使用。这些区域有:ondemand-dy-ondemandcompute1-[1-2]
节点位于POWER_UP
状态并且应在几分钟内可用。这些区域有:gpu-dy-gpucompute1-1
节点位于POWER_DOWN
状态,然后转变为POWER_SAVING
之后的状态ScaledownIdletime
(默认为 10 分钟)。
所有其他节点都在POWER_SAVING
状态没有 EC2 实例支持它们。
使用可用节点
可用节点由 EC2 实例提供支持。默认情况下,可以使用节点名称直接 SSH 进入实例(例如ssh efa-st-efacompute1-1
)。可以使用scontrol show nodes
命令并检查nodename
NodeAddr
字段中返回的子位置类型。
对于不提供的节点,NodeAddr
字段不应指向正在运行的 EC2 实例。相反,它应该与节点名称相同。
Job 状态和提交
在大多数情况下,提交的作业会立即分配给系统中的节点,如果所有节点都已分配,则将其置于挂起状态。
如果分配给作业的节点包括POWER_SAVING
状态,工作从一开始CF
,或者CONFIGURING
状态。此时,作业正在等待POWER_SAVING
状态将其切换到POWER_UP
状态并变为可用。
分配给作业的所有节点都可用之后,作业将进入RUNNING
(R
状态。
默认情况下,所有作业都提交到默认队列(称为中的分区)Slurm)。这表示的是*
队列名称后面的后缀。您可以使用-p
作业提交选项。
所有节点都配置了以下功能,可在作业提交命令中使用:
-
实例类型(例如
c5.xlarge
) -
节点类型(这是
dynamic
要么static
。)
您可以通过使用scontrol show nodes
命令并检查nodename
AvailableFeatures
列表。
考虑群集的初始状态,您可以通过运行sinfo
命令。
$
sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 4 idle~ efa-dy-efacompute1-[1-4] efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 10 idle~ gpu-dy-gpucompute1-[1-10] ondemand up infinite 20 idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
请注意spot
是默认队列。它由*
后缀。
将作业提交到默认队列中的一个静态节点 (spot
)。
$
sbatch --wrap
"sleep 300"
-N1
-Cstatic
将作业提交到中的一个动态节点EFA
queue.
$
sbatch --wrap
"sleep 300"
-pefa
-Cdynamic
向八 (8) 提交工作c5.2xlarge
节点和两 (2)t2.xlarge
中的节点ondemand
queue.
$
sbatch --wrap
"sleep 300"
-pondemand
-N10
-C "[c5.2xlarge*8&t2.xlarge*2
]"
将作业提交到中的一个 GPU 节点gpu
queue.
$
sbatch --wrap
"sleep 300"
-pgpu
-G1
使用squeue
命令。
$
squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 12 ondemand wrap ubuntu CF 0:36 10 ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2] 13 gpu wrap ubuntu CF 0:05 1 gpu-dy-gpucompute1-1 7 spot wrap ubuntu R 2:48 1 spot-st-spotcompute2-1 8 efa wrap ubuntu R 0:39 1 efa-dy-efacompute1-1
乔布 7 和 8(在spot
和efa
已运行队列)R
)。作业 12 和 13 仍在配置中(CF
),可能等待实例可用。
# Nodes states corresponds to state of running jobs
$
sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 3 idle~ efa-dy-efacompute1-[2-4] efa up infinite 1 mix efa-dy-efacompute1-1 efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 1 mix~ gpu-dy-gpucompute1-1 gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10] ondemand up infinite 10 mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2] ondemand up infinite 10 idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 1 mix spot-st-spotcompute2-1 spot* up infinite 1 idle spot-st-spotcompute2-2
节点状态和功能
在大多数情况下,节点状态完全由Amazon ParallelCluster根据本主题前面介绍的云节点生命周期中的具体流程而定。
但是,Amazon ParallelCluster还会在中替换或终止运行状况不佳的节点DOWN
和DRAINED
具有运行状况不佳的支持实例的状态和节点。有关更多信息,请参阅 clustermgtd。
分区状态
Amazon ParallelCluster支持以下分区状态。一个Slurm分区是中的队列Amazon ParallelCluster.
-
UP
:表示分区处于活动状态。这是分区的默认状态。在此状态下,分区中的所有节点都处于活动状态,可供使用。 -
INACTIVE
:表示分区处于非活动状态。在此状态下,所有支持非活动分区节点的实例都将终止。不会为非活动分区中的节点启动新实例。
pclusterupdate-compute-fleet
-
停止计算机队列-执行以下命令时,所有分区都会转换为
INACTIVE
状态,Amazon ParallelCluster进程将分区保留在INACTIVE
状态。$
pcluster update-compute-fleet --cluster-name
testSlurm
\ --regioneu-west-1
--status STOP_REQUESTED -
启动计算机队列-执行以下命令时,所有分区最初都会转换为
UP
状态。但是,Amazon ParallelCluster进程不会将分区保留在UP
状态。你需要手动更改分区状态。几分钟后,所有静态节点都可用。请注意,将分区设置为UP
不会启动任何动态容量。$
pcluster update-compute-fleet --cluster-name
testSlurm
\ --regioneu-west-1
--status START_REQUESTED
何时update-compute-fleet
已运行,您可以通过运行pcluster describe-compute-fleet
命令并检查Status
. 以下列出了可能的状态:
-
STOP_REQUESTED
:停止计算队列请求将发送到集群。 -
STOPPING
: 该pcluster
进程目前正在停止计算队列。 -
STOPPED
: 该pcluster
进程完成停止过程,所有分区都在INACTIVE
状态,并且所有计算实例都被终止。 -
START_REQUESTED
:启动计算队列请求会发送到集群。 -
STARTING
: 该pcluster
进程当前正在启动集群。 -
RUNNING
: 该pcluster
进程完成了启动过程,所有分区都在UP
状态和静态节点在几分钟后可用。 -
PROTECTED
:此状态表示某些分区存在一致的引导失败。受影响的分区不活动。请调查问题然后运行update-compute-fleet
重新启用队列。
手动控制队列
在某些情况下,您可能希望对中的节点或队列(称为分区)进行某些操作。Slurm) 在群集中。您可以通过以下常见过程管理群集中的节点。
-
在中启动动态节点
POWER_SAVING
state运行
scontrol update nodename=
命令或提交占位符nodename
state=power_upsleep 1
Job 请求一定数量的节点然后依赖Slurm以启动所需数量的节点。 -
之前关闭动态节点
ScaledownIdletime
我们建议您将动态节点设置为
DOWN
使用scontrol update nodename=
命令。Amazon ParallelCluster自动终止并重置已关闭的动态节点。nodename
state=down通常,我们建议您不要将节点设置为
POWER_DOWN
直接使用scontrol update nodename=
命令。这是因为Amazon ParallelCluster自动处理关闭电源过程。nodename
state=power_down -
禁用队列(分区)或停止特定分区中的所有静态节点
将特定队列设置为
INACTIVE
使用scontrol update partition=
命令。这样做将终止分区中支持节点的所有实例。queue name
state=inactive -
启用队列(分区)
将特定队列设置为
UP
使用scontrol update partition=
命令。queue name
state=up
扩展行为和调整
以下是普通扩展工作流程示例:
-
调度程序收到一个需要两个节点的作业。
-
调度程序将两个节点转换为
POWER_UP
州和电话ResumeProgram
使用节点名称(例如queue1-dy-spotcompute1-[1-2]
)。 -
ResumeProgram
启动两个 EC2 实例并分配的私有 IP 地址和主机名queue1-dy-spotcompute1-[1-2]
等待ResumeTimeout
(默认时间为重置节点之前的 30 分钟。 -
实例已配置并加入群集。作业开始在实例上运行。
-
作业完成并停止运行。
-
在配置之后
SuspendTime
已过去(设置为ScaledownIdletime
),调度程序将实例设置为POWER_SAVING
状态。然后调度程序设置queue1-dy-spotcompute1-[1-2]
到POWER_DOWN
州和电话SuspendProgram
使用节点名称。 -
SuspendProgram
被称为两个节点。节点保留在POWER_DOWN
例如,通过保持状态idle%
对于SuspendTimeout
(默认时间为 120 秒(2 分钟))。晚于clustermgtd
检测到节点正在关闭电源,它会终止备份实例。然后,它会过渡queue1-dy-spotcompute1-[1-2]
进入空闲状态,然后重置私有 IP 地址和主机名,以便准备为未来的作业启动电源。
如果出错而且由于某种原因无法启动特定节点的实例,则会发生以下情况:
-
调度程序收到一个需要两个节点的作业。
-
调度程序将两个云突发节点转换为
POWER_UP
州和电话ResumeProgram
用节点名称,(例如queue1-dy-spotcompute1-[1-2]
)。 -
ResumeProgram
仅启动一 (1) 个 EC2 实例并配置queue1-dy-spotcompute1-1
,使用一 (1) 个实例,queue1-dy-spotcompute1-2
,未能启动。 -
queue1-dy-spotcompute1-1
没有受到影响并在到达后上线POWER_UP
状态。 -
queue1-dy-spotcompute1-2
将其切换到POWER_DOWN
状态,并且该作业会自动申请,因为Slurm检测到节点故障。 -
queue1-dy-spotcompute1-2
之后变为可用SuspendTimeout
(默认值为 120 秒(2 分钟))。与此同时,该作业是需要的,可以在另一个节点上开始运行。 -
上述过程将重复,直到作业可以在可用节点上运行而不会发生故障。
如果需要,可以调整两个时序参数:
-
ResumeTimeout
(默认值为 30 分钟):ResumeTimeout
控制时间Slurm在将节点转换到关闭状态之前等待。-
延长可能会有用
ResumeTimeout
如果你的安装前/安装后过程需要将近那么长的时间。 -
ResumeTimeout
也是最长时间Amazon ParallelCluster如果出现问题,请等待替换或重置节点。如果在启动或设置过程中发生任何错误,则计算节点自行终Amazon ParallelCluster进程在检测到已终止的实例时替换节点。
-
-
SuspendTimeout
(默认值为 120 秒(2 分钟)):SuspendTimeout
控制节点重新放置到系统中并准备好再次使用的速度。-
更短
SuspendTimeout
意味着节点可以更快地重置,而且Slurm可以尝试更频繁地启动实例。 -
更长
SuspendTimeout
意味着失败的节点重置速度更慢。与此同时,Slurm尝试使用其他节点。如果SuspendTimeout
超过几分钟,Slurm尝试循环浏览系统中的所有节点。更长SuspendTimeout
可能有利于大型系统(超过 1000 个节点)以减轻压力Slurm当它尝试经常重新排队失败的作业时。 -
请注意
SuspendTimeout
不是指时间Amazon ParallelCluster等待终止节点的备份实例。支持实例POWER_DOWN
节点立即终止。终止过程通常会在几分钟内完成。但是,在此期间,该节点将保留在POWER_DOWN
状态并且不提供给调度程序使用。
-
架构的日志
以下列表包含关键日志。亚马逊使用的日志流名称CloudWatch日志的格式为
,其中{hostname}
.{instance_id}
.{logIdentifier}
logIdentifier
跟随日志名称。
-
ResumeProgram
:/var/log/parallelcluster/slurm_resume.log
(slurm_resume
) -
SuspendProgram
:/var/log/parallelcluster/slurm_suspend.log
(slurm_suspend
) -
clustermgtd
:/var/log/parallelcluster/clustermgtd.log
(clustermgtd
) -
computemgtd
:/var/log/parallelcluster/computemgtd.log
(computemgtd
) -
slurmctld
:/var/log/slurmctld.log
(slurmctld
) -
slurmd
:/var/log/slurmd.log
(slurmd
)
常见问题以及如何调试:
无法启动、启动或加入群集的节点
-
动态节点:
-
检查
ResumeProgram
登录以查看是否ResumeProgram
是用节点调用的。如果没有,请检查slurmctld
记录以确定是否Slurm试图打电话ResumeProgram
与节点一起。请注意,上的权限不正确ResumeProgram
可能会导致它默默失败。 -
如果
ResumeProgram
被调用,请检查是否为该节点启动了实例。如果实例未启动,应该有明确的错误消息,说明为什么实例无法启动。 -
如果启动了实例,在引导过程中可能出现了一些问题。从
ResumeProgram
日志并查看中特定实例的相应引导日志CloudWatch日志。
-
-
静态节点:
-
检查
clustermgtd
日志以查看是否为该节点启动了实例。如果实例没有启动,那么实例无法启动的原因应该存在明显的错误。 -
如果启动了实例,则引导过程存在一些问题。从
clustermgtd
日志并查看中特定实例的相应引导日志CloudWatch日志。
-
节点意外被替换或终止,以及节点故障
-
节点意外替换/终止:
-
在大多数情况下,
clustermgtd
处理所有节点维护操作。检查是否clustermgtd
替换或终止了节点,请检查clustermgtd
日志。 -
如果
clustermgtd
替换或终止了节点,则应该有一条消息指明该操作的原因。如果原因与调度程序相关(例如,节点是DOWN
),检查slurmctld
有关更多信息,请登录。如果原因与 EC2 相关,请使用诸如亚马逊之类的工具CloudWatch或者AmazonEC2 控制台、CLI 或 SDK,用于检查该实例的状态或日志。例如,您可以检查实例是否有计划事件或 EC2 运行状况检查失败。 -
如果
clustermgtd
没终止节点,请检查是否computemgtd
终止了节点或者 EC2 终止了实例以回收竞价型实例。
-
-
节点故障:
-
在大多数情况下,如果节点出现故障,则会自动对作业进行请求。查看
slurmctld
记录以查看作业或节点失败的原因并从那里评估情况。
-
替换或终止实例时失败,关闭节点电源时出现故障
-
一般来说,
clustermgtd
处理所有预期的实例终止操作。查看clustermgtd
记录以查看为什么它无法替换或终止节点。 -
对于动态节点失败
ScaledownIdletime
,看SuspendProgram
登录以查看是否slurmctld
处理以特定节点作为参数进行调用。注意SuspendProgram
实际上没有执行任何具体的操作。相反,它只会在调用时记录。所有实例终止和NodeAddr
重置由以下方式完成clustermgtd
.Slurm将节点转换到IDLE
之后SuspendTimeout
.
其他问题:
-
Amazon ParallelCluster不做工作分配或扩展决策。它只会尝试启动、终止和维护资源Slurm的说明。
有关作业分配、节点分配和扩展决策的问题,请查看
slurmctld
记录错误。