nss_slurm

nss_slurm 是一个可选的 NSS 插件，可以允许在计算节点上通过本地 slurmstepd 进程处理 passwd、group 和云节点主机解析，而不是通过 LDAP、DNS、SSSD 或 NSLCD 等其他网络服务。

当在集群上启用时，对于每个作业，作业的用户将其完整的 struct passwd 信息 — 用户名、uid、主 gid、gecos 信息、主目录和 shell — 安全地作为每个步骤启动的一部分发送，并缓存于 slurmstepd 进程中。然后，这些信息将通过 getpwuid()/getpwnam()/getpwent() 系统调用提供给该步骤启动的任何进程。

对于组信息 — 从 getgrgid()/getgrnam()/getgrent() 系统调用 —，将提供 struct group 的简化视图。在给定的进程中，响应将仅包括用户所属的那些组，但仅将用户自己列为成员。不会提供完整的组成员列表。

对于主机信息 — 从 gethostbyname()/gethostbyname 系统调用 —，将提供 struct hostent 的简化视图。在给定的进程中，响应将仅包括属于分配的云主机。

所有这些信息由 slurmctld 填充，因为它在运行 slurmctld 的主机上看到。

安装

源代码：

在您的 Slurm 构建目录中，导航到 contribs/nss_slurm/ 并运行：

make && make install

这将安装 libnss_slurm.so.2 与其他 Slurm 库文件一起放置在您的安装路径中。

根据您的 Linux 发行版，您可能需要将其符号链接到包含其他 NSS 插件的目录以启用它。在 Debian/Ubuntu 上，推荐使用 /lib/x86_64-linux-gnu，而对于基于 RHEL 的发行版，推荐使用 /usr/lib64。如果不确定，可以使用类似 find /lib /usr/ -name 'libnss*' 的命令来帮助查找。

设置

必须配置 slurmctld 以查找并发送适当的 passwd 和 group 详细信息作为启动凭证的一部分。这通过在 slurm.conf 中设置 LaunchParameters=enable_nss_slurm 并重新启动 slurmctld 来处理。

启用后，可以在计算节点上使用 scontrol getent 命令打印与该节点上作业步骤相关的所有 passwd 和 group 信息。例如：

tim@node0001:~$ scontrol getent node0001
JobId=1268.Extern:
User:
tim:x:1000:1000:Tim Wickberg:/home/tim:/bin/bash
Groups:
tim:x:1000:tim
projecta:x:1001:tim

JobId=1268.0:
User:
tim:x:1000:1000:Tim Wickberg:/home/tim:/bin/bash
Groups:
tim:x:1000:tim
projecta:x:1001:tim

NSS Slurm 配置

nss_slurm 有一个可选的配置文件 — /etc/nss_slurm.conf。只有在以下情况下需要此配置文件：

• 节点的主机名与 NodeName 不匹配，在这种情况下，您必须显式设置 NodeName 选项。
• SlurmdSpoolDir 与 Slurm 的默认位置 /var/spool/slurmd 不匹配，在这种情况下也必须提供。

NodeName 和 SlurmdSpoolDir 是目前支持的唯一配置选项。

初步测试

在节点上直接启用 NSS Slurm 之前，您应该在新启动的作业步骤中使用 -s slurm 选项来 getent，以验证其余设置是否已成功完成。-s 选项允许 getent 查询特定数据库 — 即使它未通过系统的 nsswitch.conf 默认启用。请注意，nss_slurm 仅响应来自作业步骤本身的进程的请求 — 您必须在作业步骤中启动 getent 命令才能看到任何返回的数据。

成功查询的示例：

tim@blackhole:~$ srun getent -s slurm passwd
tim:x:1000:1000:Tim Wickberg:/home/tim:/bin/bash
tim@blackhole:~$ srun getent -s slurm group
tim:x:1000:tim
projecta:x:1001:tim

NSS 配置

启用 nss_slurm 只需将 slurm 添加到 /etc/nsswitch.conf 中的 passwd 和 group 数据库（仅在将运行 slurmd 的系统上）。建议将 slurm 列为第一项，因为顺序（从左到右）决定了 NSS 数据库查询的顺序，这确保 Slurm 在能够处理请求之前不会向其他来源提交查询。

要启用云节点名称解析，必须将 slurm 添加到 /etc/nsswitch.conf 中的 hosts 数据库。建议将 slurm 列为最后一项。

启用后，通过启动 getent 查询进行测试，例如：

tim@blackhole:~$ srun getent passwd tim
tim:x:1000:1000:Tim Wickberg:/home/tim:/bin/bash
tim@blackhole:~$ srun getent group projecta
projecta:x:1001:tim

限制

nss_slurm 仅会返回给定作业步骤内进程的结果。它不会返回这些步骤外进程的任何结果，例如系统监控、节点健康检查、前置或后置脚本以及相关节点系统进程。

nss_slurm 并不打算完全替代网络目录服务，例如 LDAP，而是作为一种方式来减轻这些系统的负担，以提高大规模作业启动的性能。它通过消除“雷鸣群体”问题来实现这一点，即如果大型作业的所有任务同时发出查找请求 — 通常是与用户自身相关的信息，而这是 nss_slurm 唯一能够提供的信息 — 并压倒基础目录服务。

nss_slurm 只能与单个 slurmd 通信。如果使用 --enable-multiple-slurmd，您可以在 nss_slurm.conf 文件中使用 NodeName 和 SlurmdSpoolDir 参数指定使用哪个 slurmd。

由于信息是从 slurmctld 节点收集的，如果控制器和工作节点之间的信息不同，可能会出现意外后果。一个可能的场景是，如果用户的 shell 在 slurmctld 机器上是 /sbin/nologin，但在 slurmd 节点上是 /bin/bash。交互式 salloc 可能无法启动，因为它将尝试生成默认 shell，而根据 slurmctld，默认 shell 是 /sbin/nologin。

使用 proctrack/pgid 时，nss_slurm 将依赖于进程的 pgid 来确定是否可以响应该请求。使用 srun --pty 启动的登录 shell 必须在其自己的会话中运行，因此必须有自己的 pgid，因此 nss_slurm 不会响应交互式会话中的请求。

最后修改于 2025 年 5 月 22 日