本指南演示了如何使用 Slurm 的结算和服务质量 (QOS) 功能来有效管理由多个团队共享的单个训练集群,这些团队具有不同的优先级和资源需求。
目标
完成本教程后,您将拥有一个可执行以下操作的集群资源管理框架:
- 强制执行每个团队的资源限制。
- 根据紧急程度确定作业的优先级并抢占作业。
- 清晰地说明资源消耗情况。
- 在保持公平性的同时最大限度地提高集群利用率。
前提条件
一个正在运行的训练集群,其中配置了结算、抢占和优先级,用于管理账号、安排作业和确定作业优先级。
集群登录节点上的
sudo访问权限,以运行管理员命令。
核心概念:Slurm 结算的组成要素
Slurm 使用清晰灵活的层次结构来管理资源。了解这四个构建块至关重要。
| 组件 | 示例 | 用途 |
|---|---|---|
| 账号 | 团队或项目 | 用于对用户进行分组和设置总体资源限制(例如,team_ace 最多可以使用 10 个节点)的主要单位。 |
| 用户 | 个人研究者 | 提交作业的人员。每位用户都必须属于一个默认账号。 |
| 分区 | 硬件队列 | 节点的逻辑分组。为了获得最大的灵活性,我们建议使用包含所有节点的单个分区。 |
| QOS | 规则手册 | 一组已命名的规则,用于定义作业限制(例如,“此 QOS 中的作业只能使用 2 个节点”)和调度优先级。 |
借助此模型,您可以为整个账号设置高级别配额,并使用 QOS 应用更精细的作业级限制。
角色:管理员与研究人员
有两个不同的角色会与此系统互动:集群管理员和研究人员。
集群管理员
- 主要工具:
sacctmgr(Slurm 账号管理器) - 您的工作:构建账号、用户和 QOS 规则的“框架”。这通常是一项“配置一次,根据需要更新”的任务。
- 主要任务:创建账号、将用户分配给账号、定义服务质量规则手册,并将它们关联起来。
研究人员
- 主要工具:
sbatch、squeue、sinfo - 他们的工作:提交和监控研究作业。
- 神奇之处在于:当研究人员提交作业时,Slurm 会自动检查与其账号和 QOS 关联的规则。如果作业违反了任何限制,Slurm 会拒绝该作业并显示明确的错误消息。
教程:循序渐进的演示
以下教程通过一系列循序渐进的场景将这些概念付诸实践。在此演示中,我们假设您是集群管理员。您的任务是设置一个账号 team_ace 和一个用户 user_alice。这些方案从不受限开始,逐步添加控制层。
第 1 部分:初始设置(无限制)
创建账号并关联用户。
- 目标:为
team_ace和user_alice创建基本层次结构。 - 方法:使用
sacctmgr添加账号,然后添加与该账号关联的用户。
# --- (Run as Admin) ---
# 1. Create the 'team_ace' account
sudo sacctmgr add account team_ace Description="The Ace Team"
# 2. Create the 'user_alice' user and map them to their default account
# (Note: 'user_alice' must already exist as a Linux user on the node)
sudo sacctmgr add user user_alice Account=team_ace
# 3. Show the hierarchy we just built to confirm
sacctmgr show associations where account=team_ace
结果:作为用户 user_alice,您现在可以提交大型作业。由于没有限制,系统会接受 7 节点作业并立即运行(假设有 7 个节点处于空闲状态)。
第 2 部分:向账号添加群组级限额
接下来,为 team_ace 账号应用资源上限,将整个团队的节点总数限制为最多 6 个,作业总数限制为最多 4 个。
# --- (Run as Admin) ---
# 1. Add group-level job and node limits to the 'team_ace' account
sudo sacctmgr modify account where name=team_ace set GrpJobs=4 GrpTRES=node=6
# 2. View the limits to confirm the change
sacctmgr show association where account=team_ace
结果:如需验证新限制是否生效,请以 user_alice 身份执行以下测试:
- 节点限制:现在提交 7 节点作业会失败。作业进入待处理 (
PD) 状态,原因是 (AssocGrpNodeLimit)。 - 作业限制:提交 5 个单节点作业会导致 4 个作业运行 (
R),第 5 个作业处于待处理状态 (PD),并显示原因 (AssocGrpJobsLimit)。
账号级限额功能运行正常。
第 3 部分:添加具有 QoS 的每个作业限制
账号级群组限制可有效限制团队的总资源用量。不过,它不会阻止用户提交消耗整个团队配额的单个作业。如需控制各个作业的大小,下一步是使用服务质量 (QOS)。
- 目标:限制团队提交的任何单个作业的最大规模。
- 方法:我们将创建一个名为
qos1的服务质量 (QOS),其中包含MaxTRESPerJob=node=2规则。然后,我们会将此 QOS 设置为整个team_ace账号的默认 QOS。
# --- (Run as Admin) ---
# 1. Create a QOS with a per-job limit of 2 nodes
sudo sacctmgr add qos qos1 MaxTRESPerJob=node=2
# 2. Allow the 'team_ace' account to use this QOS
sudo sacctmgr modify account where account=team_ace set QOS=qos1
# 3. Set 'qos1' as the DEFAULT QOS for all users in this account
sudo sacctmgr modify account where account=team_ace set DefaultQOS=qos1
结果:现在,如果 user_alice 提交一个 3 节点的作业,该作业会进入待处理状态,并显示原因 (QOSMaxNodePerJobLimit)。用户仍在其总账号配额(6 个节点)范围内,但已违反每个作业的 QOS 规则。
第 4 部分:添加特定于用户的替换项
如果 user_alice 是实习生,需要限制其只能执行更小规模的作业,但不能影响团队中的其他成员,该怎么办?
- 目标:对单个用户应用更严格的限制。
- 方法:我们将创建一个新的、限制性更强的 QOS (
qos_intern),并将其作为默认 QOS 专门应用于user_alice。此标志会替换账号的默认 QOS。
# --- (Run as Admin) ---
# 1. Create a more restrictive QOS with a 1-node limit
sudo sacctmgr add qos qos_intern MaxTRESPerJob=node=1
# 2. Allow the account to use this new QOS
sudo sacctmgr modify account where account=team_ace set QOS+=qos_intern
# 3. Apply 'qos_intern' as the default QOS for the specific user association
sudo sacctmgr modify user where name=user_alice account=team_ace set DefaultQOS=qos_intern
结果:如果 user_alice 尝试提交之前在 qos1 下允许的 2 节点作业,则会失败并显示 (QOSMaxNodePerJobLimit)。更具体的用户级规则已成功替换一般账号级规则。
第 5 部分:配置优先级和抢占
最后,配置作业优先级和抢占,以确保即使集群已满,关键作业也能立即运行。
- 目标:创建高优先级的“紧急”QOS,该 QOS 可以暂停或取消低优先级的作业以释放资源。
方法:
- 创建一个具有较高
Priority值的新qos_urgent。 - 告知
qos_urgent允许Preempt在qos1中运行的作业。 - 将
qos1配置为在作业被抢占时将其设置为REQUEUE。
- 创建一个具有较高
# --- (Run as Admin) ---
# 1. Create a new 'qos_urgent' with a high priority that can preempt 'qos1'
sudo sacctmgr add qos qos_urgent Priority=1000 Preempt=qos1
# 2. Configure 'qos1' to requeue preempted jobs after a 10-second grace period
sudo sacctmgr modify qos where name=qos1 set PreemptMode=REQUEUE GraceTime=10
# 3. Allow the 'team_ace' account and 'user_alice' to use this new QOS
sudo sacctmgr modify account where account=team_ace set QOS+=qos_urgent
sudo sacctmgr modify user where name=user_alice account=team_ace set QOS+=qos_urgent
# 4. For this scenario, remove the group limits so preemption is easier to trigger
sudo sacctmgr modify account where name=team_ace set GrpJobs=-1 GrpTRES=node=-1
结果:
- 在一个终端中,
user_alice提交了一个长时间运行的作业,该作业具有默认的qos1。开始运行 (R)。 - 在第二个终端中,
user_alice使用紧急 QOS (sbatch --qos=qos_urgent ...) 提交一个大型作业。 - 在几秒钟内,第一个作业的状态从运行 (R) 变为待处理 (
PD),原因是 (Preempted)。然后,紧急作业开始运行。
大功告成!您已配置一个系统,其中高优先级工作会自动取代低优先级工作。
总结与后续步骤
通过本教程,您已学会使用 Slurm 的分层结算功能来精细控制共享集群。现在,您可以:
- 设置全局限制:使用账号为整个团队设置总资源配额。
- 强制执行作业级规则:使用 QOS 控制各个作业的大小和优先级。
- 创建特定替换项:为用户应用不同的服务质量,以实现精细控制。
- 保证优先级:配置抢占,以确保关键工作负载始终可以运行。
这种分层模型提供了一种灵活而强大的方式来公平高效地管理集群资源。如需了解更高级的配置,请参阅 Slurm 官方文档。