通用资源 (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 日