Slurm问题-关于节点共享队列以及配置cgroup的问题

最新推荐文章于 2024-09-08 16:25:03 发布

Felix.Lee

最新推荐文章于 2024-09-08 16:25:03 发布

阅读量2.6k

点赞数 2

分类专栏： Slurm调度系统文章标签： linux 云计算

本文链接：https://blog.csdn.net/weixin_43537820/article/details/129438501

版权

Slurm调度系统专栏收录该内容

12 篇文章 3 订阅

订阅专栏

节点共享使用队列问题

问题描述：分区配置允许为不同的节点组(或分区)建立不同的作业限制或访问控制。节点组可能位于多个分区中，使分区成为通用队列。例如，可以将同一组节点放到两个不同的分区中，每个分区都有不同的约束(时间限制、作业大小、允许使用分区的组等等)。作业在单个分区内分配资源。在slurm.conf中每个分区的所有参数放在一行中。每一行分区配置信息应该代表一个不同的分区。

根据官网描述，可以通过在slurm进行相应的限制，来达到节点共享使用队列，但是不会造成作业执行冲突。

AllocNodes

表示队列的节点列表，一个节点可以出现在多个队列中，可以使用节点范围表达式指定节点名称，默认值是”ALL“表示全部节点。

AllowAccounts

用逗号分隔开的账户列表，表示可以使用该分区的账户，这样就可以以账户来限制作业执行在哪个队列里，由于Linux用户与Slurm用户打通的，而slurm用户跟slurm账户是绑定的，但是Linux没有Account的概念。因此对于账户的限制只需要关注slurm中的account即可。

AllowGroups

用逗号分隔开组名列表，表示允许这些组在队列中执行作业。其中root用户与slurmuser用户可以在任何队列中执行作业。默认情况下，AllowGroups是不设置的，表示所有的组都可以使用队列。由于Linux中用户跟Slurm用户是打通的，因此slurm采用了Linux组限制作业运行在队列中。简言之，就是AllowGroups允许Linux组中与slurm相关联的用户来使用该队列。

Default

当提交到slurm的作业没有指定具体的队列时候，作业就会默认提交到默认的队列中。对应参数有两个，”YES“和”NO“，在一个集群中，只允许出现一个默认队列。

DefaultTime

用来未指定运行时间的作业运行时间限制，如果不设置DefaultTime，将采用集群配置的MaxTime。

DenyAccounts

用逗号分隔开的列表，表示哪些账号不允许使用该队列，与AllowGroup相对应。

DisableRootJobs

从上面可以了解到，root用户和slurmuser默认可以向任何队列提交作业，该配置项是了组织root用户在该队列运行任何作业。DisableRootJobs=YES表示阻止root用户在该分区运行作业。

ExclusiveUser

表示该队列下的节点都将专门非配给用户，可以给一个用户运行多个作业。但是一次只能激活一个用户。

Hidden

表示默认情况下是否隐藏队列以及运行在该队列上面的作业。SlurmAPI默认情况下不会报告隐藏分区。可用的参数是“ YES”和“ NO”。默认值是“ NO”。请注意，默认情况下，用户由于 AllowGroups 参数而无法访问的队列也将被隐藏。

slurm使用cgroup来解决作业指定资源与实际分配资源问题

现有的资源是以节点为粒度的资源分配，在多核心CPU中如果作业申请资源不能全部占满全部核心，就会出现资源超额分配的问题，如何将资源申请与管理的粒度细化到核心这一级。

尝试的解决办法

Resource Selection：资源选择，定义作业资源（节点）选择算法----需要修改控制节点和所有计算节点的slurm.conf的选择算法
SelectType=select/cons_tres #使用cons_tres插件
** select/cons_tres: 单个的CPU核、内存、GPU及其它可追踪资源作为可消费资源（消费及分配），建议设置**
** select/cons_res: 单个的CPU核和内存作为可消费资源**
** select/cray_aries: 对于Cray系统**
** select/linear: 基于主机的作为可消费资源，不管理单个CPU等的分配**
修改slurmctld的slurm.conf配置文件之后，会出现作业能够执行，资源也能够细粒度到以核心为单位。但是在运行到33秒之后，通过squeue以及scontrol查看作业信息，作业状态会变成CG状态，且在slurmd的log日志文件中会出现下面的问题（插件找不到）：

根据官网关于配置文件的翻译，以及百度到的插件机制，出现CG的原因是因为执行完作业的进程没有完全退出，导致出现作业状态变成CG，同时执行作业的节点状态变成comp状态。如果想要把节点状态由comp状态变成idle状态，需要使用scontrol update nodename=xxx state=down reason=xxx以及scontrol update nodename=xxx state=resume reason=xxx，这样节点状态就会重启了。
通过查看安装的插件位置，发现相应的插件已经通过rpmbuild编译过了，应该不是插件没有打开的问题。

查看CPU核数以及线程数

另外关于重新编译的问题。可以参考：https://cloud.tencent.com/developer/ask/sof/1917449具体内容如下图所示：

最后，解决办法竟然是同步修改slurmd节点的slurm.conf文件，因为SelectType是作用在slurmd的配置项，所以需要同步修改配置文件。（不知道为什么，在计算节点公司也给安排了slurm.conf配置文件，绝了）