通用资源 (GRES) 设计指南
概述
通用资源 (GRES) 是与特定节点相关联的资源,可以分配给作业和步骤。最明显的 GRES 使用示例是 GPU。GRES 通过特定名称进行标识,并使用可选插件提供设备特定的支持。本文件旨在提供有关 Slurm 实现 GRES 支持的详细信息,包括相关的数据结构。有关 GRES 配置和使用的概述,请参见通用资源 (GRES) 调度。
数据结构
GRES 与 Slurm 节点、作业和作业步骤相关联。您会在这些数据结构中找到一个名为 gres 的字符串变量,用于存储在节点上配置的 GRES 或作业或步骤所需的 GRES(例如 "gpu:2,nic:1")。该字符串在查看有关这些数据结构的信息的各种 Slurm 命令中也是可见的(例如 "scontrol show job")。与每个数据结构相关联的第二个变量在 slurmctld 守护进程中名为 gres_list,仅供程序使用。列表 gres_list 中的每个元素提供有关特定 GRES 类型的信息(例如一个数据结构用于 "gpu",另一个结构包含有关 "nic" 的信息)。gres_list 中的结构包含一个 ID 号(与字符串比较更快)以及指向另一个结构的指针。这个第二个结构在节点、作业和步骤中有所不同(有关详细信息,请参见 gres_node_state_t、gres_job_state_t 和 gres_step_state_t 在 src/common/gres.h 中),但包含各种计数器和位图。如果没有 GRES 与节点、作业或步骤相关联,则 gres 和 gres_list 都将为 NULL。
------------------------ | 作业信息 | |----------------------| | gres = "gpu:2,nic:1" | | gres_list | ------------------------ | +--------------------------------- | | ------------------ ------------------ | 列表结构 | | 列表结构 | |----------------| |----------------| | id = 123 (gpu) | | id = 124 (nic) | | gres_data | | gres_data | ------------------ ------------------ | | | .... | | ------------------------------------------------ | gres_job_state_t | |----------------------------------------------| | gres_count = 2 | | node_count = 3 | | gres_bitmap(按节点) = 0,1; | | 2,3; | | 0,2 | | gres_count_allocated_to_steps(按节点) = 1; | | 1; | | 1 | | gres_bitmap_allocated_to_steps(按节点) = 0; | | 2; | | 0 | ------------------------------------------------
操作模式
在 slurmd 守护进程读取配置文件后,它会为每个配置的插件调用函数 node_config_load()。这可以用于验证配置,例如验证适当的设备确实存在。如果该资源类型没有 GRES 插件,则假定配置文件中的信息是正确的。每个节点的 GRES 信息在节点注册时由 slurmd 报告给 slurmctld 守护进程。
slurmctld 守护进程在上述数据结构中维护每个节点的 GRES 信息,包括配置和分配的资源数量。如果这些资源是通过特定设备文件而不是仅通过计数来识别的,则使用位图记录哪些特定资源已分配给作业。
slurmctld 守护进程关于作业的 GRES 信息包括几个数组,其长度等于分配节点的数量。每个数组的索引是该作业分配中节点的序列号(例如,第一个元素是 job 分配的节点零)。作业步骤的 GRES 信息与作业的类似,包括数组的索引基于作业的分配。这意味着当作业步骤被分配或终止时,所需的位图操作非常容易执行,而无需计算作业和步骤数据结构的不同索引值。
对 GRES 数据结构的最复杂操作发生在作业大小发生变化时(添加或移除节点)。在这种情况下,按节点索引的数组必须重建,记录相应地移动。请注意,当前软件不支持按节点具有不同的 GRES 计数(一个作业不能在一个节点上有 2 个 GPU,而在第二个节点上有 1 个 GPU),尽管这可能在以后得到解决。
当作业或步骤被启动时,其凭证包括分配的 GRES 信息。这可以被 slurmd 守护进程用来将这些资源与该作业关联。我们的计划是使用 Linux cgroups 逻辑将作业和/或其任务与特定 GRES 设备绑定,然而目前该逻辑尚不存在。现在存在的是一对插件 API,job_set_env() 和 step_set_env(),可以用于设置环境变量,指示程序使用已分配的 GRES(CUDA 库根据环境变量选择 GPU,因此如果用户不尝试操作保留给 CUDA 使用的环境变量,这一逻辑今天应该适用于 CUDA)。
如果您想查看 GRES 逻辑如何分配资源,请配置 DebugFlags=GRES 以记录 GRES 状态变化。请注意,生成的输出可能非常详细,特别是在较大的集群中。
最后修改于 2021 年 8 月 6 日