slurm--大型集群管理指南

简介: slurm中文翻译系列,机翻后纠正了一点,发现其他错误望指出

大型集群管理指南

这份文件包含了Slurm管理员的信息,专门针对包含1024个节点以上的集群。目前由Slurm管理的大型系统包括天河二号(位于中国国防科技大学,拥有16000个计算节点和310万个内核)和Sequoia(位于劳伦斯-利弗莫尔国家实验室的IBM Bluegene/Q,拥有98304个计算节点和160万个内核)。Slurm在更大数量级的系统上的运行已经通过仿真验证。在这种规模下获得最佳性能确实需要一些调整,本文件应该有助于让你有一个好的开始。对Slurm的工作知识应该被认为是本资料的先决条件。

性能表现

以下时间是执行MPI程序打印 "Hello world "并退出的时间,包括处理输出的时间。由于硬件、软件和配置的不同,你的性能可能会有所不同。

  • BlueGene/Q的122,880个计算节点上的1,966,080个任务:322秒
  • 一个Linux集群的15,000个计算节点上的30,000个任务。30秒

系统配置

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

  • /proc/sys/fs/file-max:同时打开的文件的最大数量。我们推荐的限制是至少32832个。
  • /proc/sys/net/ipv4/tcp_max_syn_backlog:被记住的连接请求的最大数量,这些请求仍然没有收到来自连接客户端的确认。对于内存超过128Mb的系统,默认值为1024,对于低内存机器,默认值为128。如果服务器出现过载,可以尝试增加这个数字。
  • /proc/sys/net/core/somaxconn: socket listen()积压的极限,在用户空间称为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可以是一个特定的数字,也可以是特殊值无穷大。
  • 如果使用init脚本。创建文件/etc/systemd/system/.service.d/override.conf的内容。
[Service]
TasksMax=N


注意:早期版本的systemd不支持PIDs cgroup控制器,因此忽略了TasksMax的设置。

用户限制

对slurmctld守护进程有效的ulimit值应该对内存大小、打开的文件数和堆栈大小设置得相当高。

节点选择插件(SelectType)

虽然在一个节点内分配单个处理器对于较小的集群来说是很好的,但是在每个节点内跟踪单个处理器和内存的开销会增加很大的开销。为了获得最佳的可扩展性,使用select/linear来分配整个节点,避免select/cons_res。

作业会计收集插件(JobAcctGatherType)

作业核算依赖于每个计算节点上的slurmstepd守护程序定期采样数据。这种数据收集会占用应用程序的计算周期,从而引起所谓的系统噪音。对于大型并行应用来说,这种系统噪音会影响到应用的可扩展性。为了获得最佳的应用性能,最好禁用作业会计(jobacct_gather/none)。考虑使用作业完成记录(JobCompType)进行核算,因为这需要的开销要少得多。如果需要作业核算,将采样间隔配置成相对较大的尺寸(例如JobAcctGatherFrequency=300)。可能需要进行一些实验来处理数据传输中的碰撞问题。

节点配置

虽然Slurm可以跟踪每个计算节点上实际发现的内存和磁盘空间的数量,并将其用于调度目的,但这需要额外的开销。通过使用可用的参数(RealMemory、CPU和TmpDisk)指定预期配置来优化性能。如果发现节点包含的资源比配置的少,它将被标记为 "下降 "而不被使用。虽然Slurm可以很容易地处理一个异构的集群,但使用slurm.conf中最少的行数来配置节点,既可以使管理更容易,也可以使性能更好。

计时器

EioTimeout配置参数控制当用户应用程序终止时,srun命令将等待多长时间来关闭用于在用户应用程序和srun之间传递数据的TCP/IP连接。默认值是60秒。较大的系统和/或较慢的网络可能需要一个较高的值。

如果预计作业的吞吐量很高(即大量作业的执行时间很短),那么将MinJobAge配置为对你的环境实用的最小的间隔时间。MinJobAge指定了Slurm的控制守护程序在清除前保留已终止作业的最小秒数。在这个时间之后,关于终止作业的信息只能通过会计记录获得。

配置参数SlurmdTimeout决定了slurmctld与slurmd进行常规通信的间隔时间。通信发生在SlurmdTimeout值的一半。这样做的目的是为了确定一个计算节点何时发生故障,从而不应该被分配工作。较长的时间间隔可以减少计算节点上的系统噪音(我们确实在整个集群中同步这些请求,但对应用程序会有一些影响)。对于真正的大型集群,SlurmdTimeout值为120秒或更多是合理的。

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

计算节点上的各个slurmd守护进程只有在启动时或作业的尾声完成时才会向slurmctld守护进程发起消息。当一个分配了大量节点的作业完成后,会导致这些节点上的slurmd守护进程同时向slurmctld守护进程发送非常多的消息。为了将这种消息流量分散到不同的时间,避免消息丢失,可以使用EpilogMsgTime参数。注意,即使消息丢失,也会被重新传送,但这将导致重新分配资源给新作业的延迟。

其他

Slurm在slurmd守护进程之间使用分层通信,以增加并行性和提高性能。TreeWidth配置参数控制消息的扇出。默认值是50,这意味着每个slurmd守护进程可以与其他50个slurmd守护进程进行通信,并且可以通过两个消息跳来联系超过2500个节点。默认值对大多数集群来说是很好的。如果将TreeWidth设置为集群中节点数的平方根,对于不超过2500个节点的系统来说,通常可以达到最佳的系统性能,对于更大的系统来说,则是立方根。

srun命令会自动将其打开文件的限制增加到硬限制,以便处理所有启动任务的标准输入和输出连接。建议你将整个集群的开放文件硬限制设置为8192。


目录
相关文章
|
分布式计算 Kubernetes Cloud Native
Kubernetes云原生实战:分布式GeaFlow实现图研发,构建第一个商业智能应用
Kubernetes在云原生应用中扮演着至关重要的角色,为商业智能(BI)强大赋能。不同于传统的BI,容器化部署在集群中可以获得更高的可靠性、弹性和灵活性。
Kubernetes云原生实战:分布式GeaFlow实现图研发,构建第一个商业智能应用
|
6月前
|
资源调度 大数据 调度
【云计算与大数据技术】集群资源统一管理系统YARN、Mesos、Omega讲解(图文解释 超详细)
【云计算与大数据技术】集群资源统一管理系统YARN、Mesos、Omega讲解(图文解释 超详细)
248 2
|
Kubernetes Cloud Native 测试技术
在云计算平台上部署Kubernetes:无缝管理和弹性扩展
Kubernetes已成为云计算平台上部署和管理容器化应用程序的首选解决方案。无论您选择使用Google Cloud Platform(GCP)、Amazon Web Services(AWS)、Microsoft Azure或其他云计算提供商,Kubernetes都为您提供了一种灵活、可移植且可扩展的方式来管理容器化应用程序。本文将深入探讨如何在云计算平台上部署Kubernetes,并为您提供一些实际的示例。
160 1
|
大数据 关系型数据库 MySQL
基于Docker搭建大数据集群(二)基础组件配置
基于Docker搭建大数据集群(二)基础组件配置
|
存储 资源调度 Kubernetes
新书自荐《深入集群:大型数据中心资源调度与管理》
深入集群 大型数据中心资源调度与管理,已经第2版了(2021-10月)。之前在ata和百晓生发布了新书自荐,这次同步到社区。
724 1
新书自荐《深入集群:大型数据中心资源调度与管理》
|
Java 测试技术
【2022】快速部署一个可用的EFK-7.17架构
【2022】快速部署一个可用的EFK-7.17架构
168 0
|
机器学习/深度学习 人工智能 算法
【数据编制架构】Data Fabric 架构是实现数据管理和集成现代化的关键
【数据编制架构】Data Fabric 架构是实现数据管理和集成现代化的关键
|
SQL 消息中间件 NoSQL
[第二部:容器和微服务架构] (7)分布式数据管理的挑战与解决方案
[第二部:容器和微服务架构] (7)分布式数据管理的挑战与解决方案
|
缓存 运维 Kubernetes
CNStack 多集群服务:基于 OCM 打造完善的集群管理能力
CNStack 多集群服务:基于 OCM 打造完善的集群管理能力
CNStack 多集群服务:基于 OCM 打造完善的集群管理能力
|
Kubernetes 安全 Cloud Native
Kubernetes 多集群管理平台 OCM v0.9.0 发布:进一步改善托管集群安全性问题
随着 OpenClusterManagement(OCM)项目的持续发展,我们觉得有必要周期性向大家同步近期项目的一些进展了,包括我们我们下一步未来发展的方向以及作为贡献者如何参与进来我们的社区。2022 年的尾声即将到来,让我们来进一步看一下项目研发方面的新内容吧!