大型集群管理指南

本文件包含了专门针对包含 1,024 个节点或更多的集群的 Slurm 管理员信息。 目前由 Slurm 管理的一些大型系统示例包括：

  • 位于橡树岭国家实验室（ORNL）的 Frontier，拥有 8,699,904 个核心。
  • 位于中国国防科技大学的天河-2，拥有 4,981,760 个核心。
  • 位于国家能源研究科学计算中心（NERSC）的 Perlmutter，拥有 761,856 个核心。
Slurm 在数量级更大的系统上的操作已经通过仿真得到了验证。 在这个规模上获得最佳性能确实需要一些调整，而本文件将帮助您良好地开始。 对 Slurm 的基本知识应被视为学习本材料的先决条件。

性能

以下时间是执行一个打印“Hello world”并退出的 MPI 程序的时间，包括处理输出的时间。您的性能可能因硬件、软件和配置的不同而有所变化。

  • 在 122,880 个 BlueGene/Q 计算节点上运行 1,966,080 个任务：322 秒
  • 在 15,000 个 Linux 集群计算节点上运行 30,000 个任务：30 秒

系统配置

必须设置三个系统配置参数，以支持大量打开的文件和 TCP 连接，并处理大量消息的突发。可以使用 /etc/rc.d/rc.local 或 /etc/sysctl.conf 脚本进行更改，以在重启后保留更改。在这两种情况下，您可以直接将值写入这些文件 （例如 "echo 388067 > /proc/sys/fs/file-max"）。

  • /proc/sys/fs/file-max： 同时打开的文件的最大数量。适当的数量高度依赖于系统规格和工作负载。我们建议至少从 388067 或您操作系统的默认值开始，以较大者为准。根据您的需求，这个值可能需要向上调整。
  • /proc/sys/net/ipv4/tcp_max_syn_backlog： 最大未收到连接客户端确认的连接请求数。 对于内存超过 128Mb 的系统，默认值为 1024，对于低内存机器，默认值为 128。如果服务器出现过载，尝试增加此数字。
  • /proc/sys/net/core/somaxconn： socket listen() backlog 的限制，在用户空间称为 SOMAXCONN。默认值为 128。该值应大幅提高以支持请求的突发。 例如，为了支持 1024 个请求的突发，将 somaxconn 设置为 1024。

传输队列长度（txqueuelen）也可能需要使用 ifconfig 命令进行修改。对于一个拥有非常大集群的站点，发现 4096 的值效果很好 （例如 "ifconfig txqueuelen 4096"）。

线程/进程限制

在 SLES 12 SP2 中引入了一个新的限制（用于 Cray 系统，搭载 CLE 6.0UP04，将于 2017 年中发布）。 随 SLES 12 SP2 一起发布的 systemd 版本支持 PIDs cgroup 控制器。 在新的 systemd 版本下，每个 init 脚本或 systemd 服务默认限制为 512 个线程/进程。 这可能会导致在大型集群或高作业吞吐率的系统上出现 slurmctld 和 slurmd 守护进程的问题。 要将限制提高到默认值以上：

  • 如果使用 systemd 服务文件：在 [Service] 部分添加 TasksMax=N。N 可以是一个特定数字，或特殊值 infinity。
  • 如果使用 init 脚本：创建文件
    /etc/systemd/system/<init script name>.service.d/override.conf
    内容如下： 
      [Service]
  TasksMax=N

注意：不支持 PIDs cgroup 控制器的早期版本的 systemd 会简单地忽略 TasksMax 设置。

用户限制

对于 slurmctld 守护进程生效的 ulimit 值应设置得相当高，以便于内存大小、打开文件计数和堆栈大小。

节点选择插件（SelectType）

虽然在节点内分配单个处理器对于较小的集群很有用，但跟踪每个节点内的单个处理器和内存的开销会增加显著的负担。 为了获得最佳的可扩展性，使用 select/linear 分配整个节点，避免使用 select/cons_tres。

作业计费收集插件（JobAcctGatherType）

作业计费依赖于每个计算节点上的 slurmstepd 守护进程定期采样数据。 此数据收集将占用计算周期，导致所谓的 系统噪声。 对于大型并行应用程序，这种系统噪声可能会影响应用程序的可扩展性。 为了获得最佳的应用程序性能，最好禁用作业计费（jobacct_gather/none）。 考虑使用作业完成记录（JobCompType）进行计费，因为这会涉及更少的开销。 如果需要作业计费，请将采样间隔配置为相对较大的值（例如 JobAcctGatherFrequency=task=300）。 可能需要进行一些实验以处理数据传输中的冲突。

节点配置

虽然 Slurm 可以跟踪每个计算节点上实际找到的内存和磁盘空间，并将其用于调度目的，但这会带来额外的开销。 通过使用可用参数（RealMemory、CPUs 和 TmpDisk）指定预期配置来优化性能。 如果发现节点的资源少于配置的资源，它将被标记为 DOWN 并不被使用。 虽然 Slurm 可以轻松处理异构集群，但使用 slurm.conf 中的最少行数配置节点将使管理更容易且性能更好。

定时器

EioTimeout 配置参数控制 srun 命令在用户应用程序终止时等待 slurmstepd 关闭用于转发数据的 TCP/IP 连接的时间。默认值为 60 秒。较大的系统和/或较慢的网络可能需要更高的值。

如果预计会有大量作业（即大量作业具有短暂的执行时间），则将 MinJobAge 配置为您环境中可行的最小间隔。MinJobAge 指定终止作业在 Slurm 控制守护进程中保留的最小秒数，然后才会被清除。在此时间之后，关于终止作业的信息将仅通过计费记录可用。

配置参数 SlurmdTimeout 确定 slurmctld 定期与 slurmd 通信的间隔。 通信发生在 SlurmdTimeout 值的一半。 这样做的目的是确定计算节点何时失败，因此不应分配工作。 较长的间隔会减少计算节点上的系统噪声（我们确实在集群中同步这些请求，但会对应用程序产生一些影响）。 对于真正大型的集群，SlurmdTimeout 值为 120 秒或更长是合理的。

如果使用 MPICH-2，srun 命令将管理用于引导应用程序的密钥对。 根据处理器的速度和架构，密钥对信息的通信可能需要额外的时间。 这可以通过在执行 srun 启动任务之前设置环境变量 PMI_TIME 来完成。 PMI_TIME 的默认值为 500，这是分配给传输每个密钥对的微秒数。 我们已经执行了最多 16,000 个任务，PMI_TIME=4000。

计算节点上的各个 slurmd 守护进程仅在启动时或作业的 epilog 完成时向 slurmctld 守护进程发送消息。当一个作业分配了大量节点并完成时，可能会导致这些节点上的 slurmd 守护进程同时向 slurmctld 守护进程发送大量消息。为了将这些消息流量分散到时间上并避免消息丢失，可以使用 EpilogMsgTime 参数。请注意，即使消息丢失，它们也会被重新传输，但这将导致重新分配资源到新作业的延迟。

其他

Slurm 在 slurmd 守护进程之间使用分层通信，以增加并行性并提高性能。 TreeWidth 配置参数控制消息的分支因子。 默认值为 16，这意味着每个 slurmd 守护进程可以与最多 16 个其他 slurmd 守护进程通信，并且可以通过三次消息跳跃联系到 4368 个节点。 默认值对于大多数集群效果良好。 如果将 TreeWidth 设置为集群中节点数量的立方根，通常可以实现最佳的系统性能。

srun 命令会自动将其打开文件限制提高到硬限制，以处理所有标准输入和输出连接到启动的任务。建议您在整个集群中将打开文件的硬限制设置为 8192。

最后修改于 2024 年 10 月 2 日