Slurm集群搭建实战：四类节点规划与配置全指南

在高性能计算HPC领域Slurm 几乎是绕不开的一个名字。无论你是在给实验室搭一套几十个节点的 GPU 集群还是帮学校/单位建设正式的 HPC 平台SlurmSimple Linux Utility for Resource Management都是当前最主流的开源作业调度系统。很多朋友第一次接触 Slurm看到一堆节点概念——控制节点、计算节点、登录节点、存储节点——容易一头雾水资料东拼西凑搭到一半就卡住。这篇内容我想聊的就是一套完整的 Slurm 集群构建实战方案。我会把四个核心角色控制 / 计算 / 登录 / 存储节点逐一拆开讲覆盖从硬件规划、基础环境、共享存储、MUNGE 认证、slurmctld/slurmd 配置到计算节点加入和作业提交测试的完整流程。文章适合两类人一是从来没搭过集群、想从零上手 HPC 调度的运维新手二是已经在用别的调度器、想平滑迁移到 Slurm 的工程师。我会把常见问题和排障思路也一起放进来尽量让你照着操作就能跑通。1. 整体架构设计与节点规划1.1 为什么 Slurm 集群要拆成四类节点先理解一个朴素的问题为什么不把控制、计算、登录、存储全部塞进同一台机器里对于跑hostname都嫌多的玩具环境这样做确实可以但一旦作业规模上来问题立刻暴露。计算节点需要把 CPU、内存和 GPU 绝大部分资源都让给作业使用如果同时跑着调度服务、文件服务、用户登录进程资源被抢占是小事更麻烦的是互相干扰某个用户跑了个top卡住或者文件服务把磁盘 IO 打满都会直接拖垮正在运行的作业甚至让调度器无响应。所以四类节点的职责边界很清晰控制节点slurmctld运行 Slurm 主控服务负责记录节点状态、管理作业队列、做出调度决策。计算节点slurmd运行 Slurm 计算代理服务接收控制节点下发的作业真正执行计算任务。登录节点login用户接入集群的入口在这里提交作业、查看结果不承担计算任务。存储节点storage统一提供共享文件系统保证用户在任意计算节点上都能读到自己的数据和软件。1.2 硬件规划参考与网络设计我做过的项目中一个入门级的小型集群通常长这样以 5 个计算节点为例节点角色主机名示例建议硬件配置关键软件控制节点slurmctl4C8GSSD 100GBslurmctld, slurmdbd, MariaDB, munge登录节点slurm-login8C16GSSD 200GBSlurm 客户端工具, pam_slurm计算节点slurm-node[01-05]按实际算力需求16C64G 起slurmd, munge存储节点slurm-storage机械盘按容量SSD 做读写缓存NFS / BeeGFS / Lustre网络方面小规模集群至少需要一张管理网络通常千兆即可负责节点通信、NFS 挂载、SSH 登录如果涉及并行计算MPI 跨节点通信建议再加一张高速计算网络常见方案是 InfiniBand100Gbps 起步或 RoCE 高速以太网这类网络只承载作业数据避免与管理流量抢带宽。提示如果你只是学习实验把控制节点和登录节点放在同一台机器上完全可以接受。但生产环境请务必分开否则控制节点上用户的交互式进程一多会影响整个集群的调度稳定性。2. 基础环境准备与依赖安装2.1 操作系统与主机名规划我习惯用 Rocky Linux 9或 AlmaLinux 9作为集群操作系统原因是它在 RHEL 生态下稳定性好、EPEL 源里可以直接拿到 Slurm 和 MUNGE 的软件包省去源码编译的折腾。Ubuntu 也有对应包但服务管理方式稍有差别下面以 Rocky Linux 9 为例。先把所有节点的主机名设置好并写入/etc/hosts。这一步看似简单却是后面很多诡异问题的根源# 在每台节点上执行 hostnamectl set-hostname slurmctl # 按角色分别设置# /etc/hosts 示例所有节点保持一致 192.168.10.10 slurmctl 192.168.10.11 slurm-login 192.168.10.21 slurm-node01 192.168.10.22 slurm-node02 192.168.10.23 slurm-node03 192.168.10.24 slurm-node04 192.168.10.25 slurm-node05 192.168.10.30 slurm-storage排查过太多失败案例后我可以说Slurm 节点之间对主机名的解析非常敏感不要依赖 DNS 出问题后再去查直接写死 hosts 是最省心的做法。2.2 时间同步集群调度不漂移的前提调度系统最怕的就是节点间时间不一致。作业的开始/结束时间、票据的过期时间都依赖节点时钟如果某个计算节点时间慢了 30 秒slurmctld 和 slurmd 之间会出现令牌校验失败或者作业状态错乱。用 chrony 统一时间选择控制节点作为时间源# 所有节点安装 chrony sudo dnf install -y chrony sudo systemctl enable --now chronyd控制节点/etc/chrony.conf建议增加对外时间源的同步同时允许内网其他节点跟随# 默认的 pool 行保留同时增加 allow 192.168.10.0/24 local stratum 10其余计算、登录、存储节点把/etc/chrony.conf里的pool全部注释掉改为server slurmctl iburst然后重启 chronyd用chronyc sources确认时间源状态。这里有经验的工程师往往还会顺手在所有节点上加上timedatectl set-timezone Asia/Shanghai按需避免时区不一致导致日志分析出现偏差。3. 存储节点与共享文件系统3.1 选型小规模 NFS大规模并行文件系统HPC 集群必须解决一个问题用户在登录节点提交作业作业被调度到某一台计算节点上执行计算节点得能读到用户的代码、输入数据和软件环境。这就需要一个所有节点都能访问的共享文件系统。小规模实验集群用NFS最简单直接部署快、概念清晰足够支撑几十个计算节点的负载。但如果要做严肃的并行计算大规模 MPI 作业、海量小文件读写NFS 会成为瓶颈这时就要上BeeGFS / Lustre / GPFS这类并行文件系统。本文先讲 NFS逻辑通了之后再去接触并行文件系统会容易很多。未完待续…为了直接给出完整文章下文继续延续实战细节存储节点在/home、/project、/opt/soft三个目录上分别提供共享并在/etc/exports中配置# 存储节点 /etc/exports /home 192.168.10.0/24(rw,sync,no_root_squash,no_subtree_check) /project 192.168.10.0/24(rw,sync,no_root_squash,no_subtree_check) /opt/soft 192.168.10.0/24(ro,sync,no_root_squash,no_subtree_check)no_root_squash这个参数在 HPC 环境非常关键。默认情况下 NFS 会把root用户映射为nobody导致计算节点上的管理员无法对共享目录做管理操作比如安装软件到/opt/soft。但要注意no_root_squash也意味着拥有 root 权限的客户端能直接改存储端文件所以仅限在内网可信环境使用。客户端挂载在/etc/fstab中写入192.168.10.30:/home /home nfs4 defaults,_netdev 0 0 192.168.10.30:/project /project nfs4 defaults,_netdev 0 0 192.168.10.30:/opt/soft /opt/soft nfs4 defaults,_netdev 0 0挂载后统一所有节点的用户 UID/GID 是必须做的一步。我见过太多集群因为用户在控制节点和计算节点 UID 不一致导致作业写出的文件所有权错乱。简单粗暴的做法是在所有节点上保持/etc/passwd中与 HPC 用户相关的条目一致更推荐的方式是引入 LDAP 或直接维护一份统一的用户数据库。总之用户管理务必集中化。4. Slurm 控制节点与计算节点的核心配置4.1 MUNGE 认证Slurm 集群的信任基石Slurm 集群内部所有通信都要做认证官方默认的认证机制就是 MUNGE。它相当于集群各节点共享的一把“万能钥匙”只有持有同一个 key 的节点之间才能互相通信。在所有节点控制、计算、登录、存储上安装并启动 MUNGEsudo dnf install -y epel-release sudo dnf install -y munge munge-libs munge-devel然后在控制节点上生成 key并通过 scp 分发到其他节点只分发一次后续新节点也要同步这份 keysudo create-munge-key sudo scp /etc/munge/munge.key rootslurm-node01:/etc/munge/ sudo scp /etc/munge/munge.key rootslurm-login:/etc/munge/分发完成后所有节点执行sudo chown -R munge:munge /etc/munge /var/log/munge /run/munge sudo chmod 0700 /etc/munge /var/log/munge /run/munge sudo systemctl enable --now munge用一个命令验证 MUNGE 是否正常munge -n | unmunge看到STATUS: Success就成了。这里有个经典坑key 文件权限必须是 0400 且属主为 munge如果权限不对MUNGE 服务能起来但节点间认证会反复失败日志里只留下一个含糊的Invalid credential。4.2 slurm.conf 详解一份配置全集群统一Slurm 的配置核心是/etc/slurm/slurm.conf。这份文件必须保持所有节点完全一致控制节点和计算节点用同一份所以配置好之后统一分发。下面是一份适合入门集群的配置ClusterNamehpc-cluster SlurmctldHostslurmctl SlurmUserslurm SlurmdUserroot AuthTypeauth/munge CryptoTypecrypto/munge ProctrackTypeproctrack/cgroup TaskPlugintask/cgroup SelectTypeselect/cons_tres SelectTypeParametersCR_Core_Memory SchedulerTypesched/backfill PriorityTypepriority/multifactor SlurmctldPort6817 SlurmdPort6818 StateSaveLocation/var/spool/slurmctld SlurmdSpoolDir/var/spool/slurmd SlurmctldPidFile/run/slurmctld.pid SlurmdPidFile/run/slurmd.pid AccountingStorageTypeaccounting_storage/slurmdbd AccountingStorageHostslurmctl AccountingStoragePort7030 AccountingStorageUserslurm AccountingStoragePassslurm_db_password ReturnToService1 MpiDefaultnone参数作用解释SelectTypecons_tres按可消耗资源CPU、内存等调度支持--mem、--cpus-per-task等细粒度限制SchedulerTypesched/backfill启用回填调度让短作业利用大作业的空闲资源提高集群利用率ProctrackType/cgroup用 cgroup 限制并跟踪作业占用的资源防止进程逃逸ReturnToService1节点从故障恢复后自动回到可用状态接下来定义节点和分区。假设每个计算节点有 16 核、64GB 内存这里RealMemory单位是MBNodeNameslurm-node[01-05] CPUs16 RealMemory64000 Sockets1 CoresPerSocket16 ThreadsPerCore1 StateUNKNOWN PartitionNamenormal Nodesslurm-node[01-05] DefaultYES MaxTime72:00:00 StateUPNodeName支持正则式的范围展开这在大规模集群里能省掉很多行配置。StateUNKNOWN表示节点初始状态未知等 slurmd 上线后会自动转入 idle。分区normal是默认分区作业不指定-p就会投递到这里。4.3 启动控制节点让调度器先跑起来控制节点准备好之后额外装一下 slurmctld 相关的包并启动sudo dnf install -y slurm slurm-slurmctld slurm-slurmdbd sudo systemctl enable --now slurmctld同时建议配置存储记账可选但强烈推荐。Slurm 的账户系统slurmdbd依赖 MariaDB先把数据库准备好sudo dnf install -y mariadb-server sudo systemctl enable --now mariadb mysql -e create database slurm_acct_db; mysql -e grant all on slurm_acct_db.* to slurmlocalhost identified by slurm_db_password;然后创建/etc/slurm/slurmdbd.conf注意权限必须是 600属主 slurmDbdHostslurmctl DbdPort7030 SlurmUserslurm DatabaseTypemysql DbHostlocalhost DbPort3306 DbNameslurm_acct_db DbUserslurm DbPassslurm_db_password再启动 slurmdbd并把集群加入账户系统sudo systemctl enable --now slurmdbd sacctmgr add cluster hpc-cluster不启用 slurmdbd 集群也能跑但没有历史作业记录用户提交作业后的sacct查询、计费、资源使用报表全部无法实现。生产环境几乎没有不做的理由。5. 计算节点加入集群从 slurmd 到节点上线5.1 计算节点的统一配置计算节点相对干净只需要三样东西munge.key、slurm.conf、cgroup.conf。前两样直接从控制节点复制过来# 在控制节点上执行这里以 slurm-node01 为例 sudo scp /etc/slurm/slurm.conf rootslurm-node01:/etc/slurm/ sudo scp /etc/slurm/cgroup.conf rootslurm-node01:/etc/slurm/cgroup.conf的内容用于让 Slurm 真正约束作业的 CPU 和内存CgroupAutomountyes ConstrainCoresyes ConstrainRAMSpaceyes ConstrainSwapSpaceyes然后安装并启动 slurmdsudo dnf install -y slurm slurm-slurmd sudo systemctl enable --now slurmd5.2 验证节点状态与常见加入失败原因回到控制节点通过sinfo和scontrol查看节点是否正常上线sinfo -N -l scontrol show node slurm-node01正常情况会看到StateIDLE。如果节点一直处于DOWN或UNKNOWN先按顺序检查MUNGE key 是否一致在计算节点执行munge -n | unmunge确认返回 Success。网络连通性从计算节点telnet slurmctl 6817确认能连上控制节点的调度端口。slurmd 日志查看/var/log/slurmd/slurmd.log里面有具体的认证失败或连接失败原因。节点状态强制恢复正常如果节点物理上没问题只是被标记为异常可以在控制节点执行scontrol update NodeNameslurm-node01 StateRESUME计算节点加入时我踩过最大的坑是slurmctld 已启动但 slurmd 未启动时节点状态显示为DOWN并且Reason字段写着一些含糊的调度器内部信息。这时候不要急着去乱改配置先把 slurmd 拉起来等几秒再看状态。6. 登录节点与作业提交实践6.1 登录节点的职责与防护配置登录节点是用户看到的“集群大门”。用户在这里编辑代码、上传数据、提交作业和管理任务。但登录节点绝对不能用来跑计算作业这是集群设计的基本原则。生产环境的登录节点我通常会装slurm客户端、pam_slurm和slurm-pam_slurm并做两个额外优化启用pam_slurm_adopt防止用户通过 SSH 直接登到计算节点上抢占资源。标准做法是在/etc/pam.d/sshd中添加account sufficient pam_slurm_adopt.so这样只有正在使用某个作业的用户才被允许 SSH 到该作业所在的计算节点。用 cgroup 限制登录节点上 SSH 会话的 CPU 和内存防止哪个用户随手起几个进程就把登录节点挤爆。从这层意义上说登录节点配置的核心不是“能提交作业”而是“如何规范用户行为、隔离异常负载”。6.2 第一个作业sbatch 与 srun 的使用在登录节点把测试脚本写好用sbatch提交批处理作业#!/bin/bash #SBATCH --job-namehello_hpc #SBATCH -p normal #SBATCH -N 1 #SBATCH --ntasks-per-node4 #SBATCH --mem4G #SBATCH --time00:05:00 srun hostname srun sleep 60提交并查看sbatch test.slurm squeue -u $USER scontrol show job 12345如果作业能正常进入RUNNING计算节点上执行hostname并输出结果说明整条链路登录节点 - 调度器 - 计算节点 - 共享存储已经打通。这是任何一个 Slurm 集群从搭建到交付的一个重要里程碑。关于交互式调试srun更合适srun -p normal -N 1 --ntasks-per-node4 --mem4G --time00:30:00 --pty /bin/bash进入计算节点交互 shell 后可以直接测试并行程序用完exit退出资源和计费自动回收。7. 常见问题与故障排查速查表现象最常见原因排查与解决办法节点状态始终 DOWNslurmd 未启动或 MUNGE 认证失败在计算节点启动 slurmd检查 munge.key 是否一致、权限是否是 0400作业一直 PENDING分区无资源、QOS 或账号限制、Backfill 未生效squeue -o %.18i %.9P %.8j %.8u %.2t %.10M %.6D %R查看 Reasonsrun报 unable to allocate resources请求的资源超过分区上限或节点被 drainsinfo -p normal -o %n %t %C %m看可用资源节点被 DRAIN 后不恢复节点健康检查失败或手动维护scontrol show node node看 Reasonscontrol update NodeNamenode StateRESUMENFS 挂载后 Permission denied客户端 UID/GID 与服务端不一致统一用户 UID检查 exports 的no_root_squash是否按需配置Slack 的 sacct 无记录slurmdbd 未启动或配置错误查看/var/log/slurmdbd.log确认 MariaDB 服务正常、密码正确重启节点后作业丢失计算节点 slurmd 的 spool 目录未持久化确保/var/spool/slurmd在重启后能保留不应放在 tmpfs提示修改 slurm.conf 之后不需要重启整个集群。在控制节点执行scontrol reconfigure即可热加载配置这个操作比重启 slurmctld 安全得多。计算节点端 slurmd 一般也能通过scontrol update NodeName...配合完成平滑生效。再分享一个我个人的实操心得新集群搭建阶段先不要急着挂载生产数据。先在共享存储里建一个 test 目录用一个小作业验证调度链路确认节点状态、账户系统、共享存储都稳定了再逐步放开用户数据和软件环境。这样即便出现问题排查范围也会小很多不会把“存储权限问题”和“调度认证问题”搅在一起。最后一个小技巧Slurm 集群日常维护时养成定期看/var/log/slurmctld/slurmctld.log和/var/log/slurmd/slurmd.log的习惯。很多节点假死、调度延迟的前兆都会提前出现在日志里。真等用户跑来抱怨作业跑不动再去看日志就已经晚了。这一套四节点架构搭完之后后续要扩充算力就是买机器、装系统、同步 munge.key 和 slurm.conf、启动 slurmd 这么简单这也是 Slurm 能在 HPC 领域长盛不衰的重要原因。