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 日