
前面讲到了Slurmdbd的配置,Slurmdbd负责存储作业记录,其实同时它还提供了账务信息的存储并负责资源限制的功能。默认情况下Slurm只会根据各集群中的基本配置限制作业,而不会启动跟账务系统相关联的资源限制,我们需要配置AccountingStorageEnforce选项以启用该功能。该配置项允许配置多个限制条件,以逗号分隔,他们分别是:
- associations - 关联账户系统,如果用户在数据库中不存在相关联的账户信息,将阻止用户运行作业。此选项将阻止用户访问无效帐户。
- limits - 同时限制关联账户信息及QOS,设置该配置则默认会自动配置
associations - nojobs - 配置该选项后,账户系统不会记录作业信息,设置该配置则默认会自动配置
nosteps - nosteps - 配置该选项后账务系统将不会记录作业步信息
- qos - 配置该选项后系统会要求每个作业必须指定有效的QOS后才允许运行
- safe - 该配置要求作业必须有关联行账户信息或者有效的QOS,并且必须配置GrpTRESMins
- wckeys - 这将阻止用户在他们无权访问的wckey下运行作业,关于wckey可以查阅slurm文档,这里暂时不做详细介绍。
nojobs和nosteps听起来很奇怪,配置后将不会记录作业信息,这不是相当于阉割掉了一部分slurmdbd的功能吗?实际上这在你想要使用资源限制但不关心利用率的环境中可能会有所帮助。
资源限制
上面介绍了如何启用Slurm的Accounting资源限制,可以看到它提供了多种不同的限制条件,你可以设置一个或多个限制条件。Slurm的资源限制是一个多因素叠加的限制,包括QOS、Association以及Partition limit等等。它们之间遵循以下的优先级规则:
- Partition QOS limit
- Job QOS limit
- User association
- Account association(s), ascending the hierarchy
- Root/Cluster association
- Partition limit
- None
当限制条件出现在多个不同的层级时,以首次出现的限制条件为准。例如有以下限制规则:
- partition QOS中MaxJobs=20。
- job QOS中没有任何限制。
- User association中MaxJobs=4, MaxSubmitJobs=50
叠加到一起后最终的限制结果是MaxJobs=20,MaxSubmitJobs=50。
Association
前面总是提到QOS和Association两个词,究竟是什么东西?我们先说Association。根据官方文档的解释,Association是一个4元组,由群集名称,帐户,用户和(可选的)Slurm分区组成。简单的说它就是一个由集群名、账务系统的账户名、用户名和Slurm分区所组成的一个唯一的关联关系,你可以为这个关系设定一些资源限制,当作业提交时则会校验相应的限制。
你可以通过sacctmgr命令进行association的管理,下面是一些基本操作,更多可以参考sacctmgr文档:
1 | ## 创建一个名为cluster1的集群 |
QOS
QOS(Quality of Service)是一个我们常听说的词,它是一种控制机制,可以针对性的根据用户优先级或者不同的规则提供不同服务供给,以保障资源的更合理利用。在Slurm中也有QOS,它主要提供以下几个功能:
- 作业调度优先级调控
- 作业抢占
- 作业资源限制
- 队列资源限制
QOS也是通过sacctmgr工具进行管理,这里列举一些基本操作,更多可以参考QOS文档:
1 | ## 查看所有QOS配置 |
总结
QOS和Association的区别是QOS是一个一对多的限制条件,你可以为多个association配置同一个QOS,而Association则是一个特定的规则,它具备一定的继承性,但是最终生效的只有唯一的一个association,最终的限制都是对association上规则的校验。
QOS和Association都能配置很多限制规则,例如:
- GrpTRESMins: 限制TRES资源的总可用分钟数。
- GrpJobs: 限制允许同时运行的最大作业数量。
- MaxTRESMinsPerJob: 每个作业可用多最大TRES资源分钟数。
- GrpSubmitJobs: 允许提交的最大作业数量。
- …
上面列出的只是一部分限制条件,Slurm还提供了更多维度的多种限制条件,更多选项可以参考资源限制文档