高性能计算集群部署实战：从架构设计到Slurm调度与排错

说实话，集群这东西，没搭过的人觉得是玄学，搭过的人知道全是坑。我第一次给课题组搭高性能计算集群时，整整折腾了一周，从硬件上架、交换机配置到Slurm跑通第一个MPI作业，过程比预想曲折太多。后来陆续给不同团队部署过几套，有科研计算、有AI训练、也有大数据混部的，才慢慢形成一套比较稳的打法。这篇东西，就把我这些年做高性能计算集群部署的实际经验重新整理一遍，从架构设计、硬件选型、软件栈选择，到Slurm调度器、共享存储、MPI并行、GPU资源管理，再到常见的坑和排查方法，一次讲清楚。不管你是在实验室搭一套十台以内的小集群，还是给公司规划几十节点的大规模环境，这篇文章都能给你一个能直接照着做的参考。

在动手之前，我得先把话说清楚：高性能计算集群不等于“一台好电脑插很多卡”，它是一套完整的软硬件协同体系。CPU、内存、GPU、高速网络、共享存储、调度器、用户环境、监控运维，任何一个环节拉胯，最终都会变成“集群跑起来很慢”“作业互相干扰”“节点无缘无故DRAIN”这类玄学问题。所以这篇文章不会只教你敲命令，我会把每个关键选择的为什么也讲明白，这样你后面遇到问题才知道从哪里入手排查。

1. 部署前的架构设计：先想清楚再动手

1.1 集群到底解决什么问题

很多团队刚开始接触集群，认知是“单机跑不动，买几台机器拼起来就是集群”。这话对了一半。高性能计算集群的核心价值有三个：一是聚合算力，把多个节点的CPU、GPU、内存汇聚成一个逻辑资源池；二是提高并发，让多个用户、多个任务同时提交，通过调度器统一排队执行；三是提供可扩展性，算力不够了加节点就行，不需要重写应用。

但你得先搞清楚自己跑的是什么负载。负载类型直接决定集群架构：如果是分子动力学、CFD、有限元这类传统科学计算，瓶颈通常在CPU核数、内存带宽和高速网络互联；如果是深度学习训练，核心是GPU算力、显存容量以及GPU间通信带宽（NVLink、InfiniBand）；如果是大数据处理（Spark、Flink、Doris这类），瓶颈往往在存储IO和数据吞吐，调度方式也未必是Slurm，更可能是Yarn或K8s。

我见过最典型的失败案例是：有人看别人搭了Slurm集群跟风搭了一套，结果团队主要跑的是Spark，作业调度在Slurm里绕了一圈又映射到Yarn，调度逻辑重复，资源利用率反而低。所以第一步一定是列清楚你的工作负载清单：主流应用有哪些、单任务需要多少核多少内存、是否用GPU、任务时长是分钟级还是天级、有多少并发用户。这决定了后面所有选型。

1.2 硬件选型与预算分配

集群硬件规划有一个原则：角色分离。小型集群可以一台节点身兼数职，但节点规模超过几十台甚至上百台后，管理节点、登录节点、存储节点和计算节点必须分开。

标准角色分配大概是这样：

• 管理节点：跑调度器控制进程、认证服务、作业记账数据库，不需要很高计算性能，但内存和磁盘要可靠，建议双盘RAID1。
• 登录节点：用户在这里编辑代码、提交作业、做编译，交互IO比较重，CPU频率要高，内存充足，但不要在上面跑计算任务。
• 计算节点：集群主力，按需配置CPU、内存、GPU，不装多余软件，保持环境干净。
• 存储节点：负责共享家目录、应用软件和数据集，对IO和网络要求最高，建议配SSD缓存或直接上并行文件系统。

预算分配上，我自己的经验比例是：计算硬件（CPU/GPU/内存）大概占50%到60%，网络占15%到20%，存储占20%到25%，剩下的给管理、登录、机架电源和布线。很多人喜欢把钱全砸在GPU上，网络和存储随便买，结果多机训练时通信瓶颈严重，数据读取卡到爆，GPU利用率上不去，典型的省小钱花大钱。

举个我实际规划的节点示例，中等规模深度学习+仿真混合集群：

这个规模不算小，但思路是通用的：计算网和存储网独立，避免IO流量挤占MPI通信。如果你预算有限，至少也要做到管理/登录网和计算网分离，哪怕是两台交换机分开两个VLAN也好。

1.3 软件栈选型：调度器怎么挑

调度器是整个集群的中枢，它的作用就是“排队叫号”：接收用户的作业，按策略分配资源，监督作业运行状态。传统HPC领域主流的开源调度器是Slurm，其次是PBS系（OpenPBS/Torque）、LSF商业版也常见。大数据生态则普遍用Yarn和K8s。

我个人的建议是：传统科学计算、MPI并行任务、GPU训练任务，首选Slurm。原因有三个：

一是Slurm的作业模型和HPC应用天然匹配，支持MPI启动器（srun/mpirun）深度集成，支持GPU资源管理（Gres），支持分区、QOS、抢占和回填调度，非常灵活。

二是社区活跃，几乎所有超算中心都用Slurm，网上排查案例多，踩坑容易找到答案。

三是配置复杂度可控，配好slurm.conf之后，日常运维命令就那么几条，不像K8s那样有大量控制器、CRD、网络插件需要维护。

但如果你主要是跑微服务、网页推理接口、大数据任务，那K8s可能更合适。注意，不要一上来就想把Slurm和K8s融合，那是大厂超融合的玩法，中小团队硬上会把自己搞死。后面第6章我会单独讲大数据和AI推理场景怎么和HPC集群共存。

另外，容器技术现在绕不开：HPC环境建议用Singularity/Apptainer，而不是Docker。因为Docker daemon有root权限，且用户态文件映射和MPI通信容易出权限问题；Singularity则是用户态容器，天然适合共享集群，配合Slurm用起来很顺。

2. 基础环境搭建：把地基打牢

2.1 节点规划和系统安装

文件动手之前，先把节点命名、IP地址、用户账户想好。我习惯用短主机名加编号：mng01、login01、cpu01、gpu01、stor01。IP按角色分段：管理网段192.168.10.0/24，计算网段192.168.20.0/24，存储网段192.168.30.0/24。物理上让管理网和计算网走不同物理交换机或不同VLAN，后面跑MPI时你会发现这是救命的设计。

我的规划表示例：

系统选择上，RHEL系（Rocky Linux 9、AlmaLinux 9）和Ubuntu Server 22.04 LTS都可以。传统HPC用得更多的是RHEL系，因为硬件厂商和MPI库对RHEL的适配最好，nvidia-driver、Infiniband驱动基本一键装好。这里多说一句，CentOS 7虽然很多人还在用，但真的不建议新集群再用它了，仓库源和依赖工具链越来越难适配新硬件，我踩过很大的坑。

系统装好后第一件事是确保所有节点能免密SSH互连。在管理节点上生成密钥，复制到所有节点：

bash复制ssh-keygen -t rsa -b 4096 -N "" -f ~/.ssh/id_rsa
for node in mng01 login01 cpu01 gpu01 stor01; do
  ssh-copy-id root@${node}
done

注意每一台节点的 /etc/hosts 里要把所有节点的主机名和IP写全。集群内部不要依赖DNS，不然Slurm解析节点名失败会让你排查到怀疑人生。

2.2 时间同步与DNS解析

集群里时间不同步是硬伤。作业日志时间戳混乱、Slurm报错“node reboot”时间不统一、分布式文件系统缓存冲突，追根溯源都是NTP问题。我的做法是让管理节点当NTP服务器，其他节点从管理节点同步，有条件的话管理节点再同步外部时钟源。

管理节点配置chrony：

bash复制# /etc/chrony.conf
server 0.pool.ntp.org iburst
allow 192.168.0.0/16

其他节点：

bash复制# /etc/chrony.conf
server mng01 iburst

然后统一执行 systemctl restart chronyd && chronyc makestep。我习惯在装机脚本里就做完NTP，不然后面手动逐台执行效率太低。

DNS这一块，我建议直接在 /etc/hosts 里写全所有节点映射，不要配置内部DNS服务器。集群规模不大时，hosts文件简单可靠；规模大了再考虑DNS，但也要保留hosts用来兜底。因为很多MPI实现和调度器服务对主机名解析有奇怪的要求，hosts文件优先是经验之谈。

2.3 共享存储：NFS和分布式文件系统

集群必须有一个所有节点都能看到的共享目录，否则用户的家目录、软件部署、数据集同步会让你疯掉。最简单可靠的方案是NFS。为什么不一开始就上Lustre或GPFS？因为配置复杂、维护成本高，小团队扛不住。我的原则是：节点少于几十台、IO压力不是极端场景时，先用NFS；等真的出现IO瓶颈，再迁移到Lustre或BeeGFS。

NFS我建议用NFSv4.2，支持服务端拷贝、稀疏文件等特性，性能比v3好很多。存储节点上导出目录：

bash复制# /etc/exports
/data/home      192.168.20.0/24(rw,sync,no_subtree_check,no_root_squash)
/data/software  192.168.20.0/24(rw,sync,no_subtree_check,no_root_squash)
/data/scratch   192.168.20.0/24(rw,sync,no_subtree_check,no_root_squash)

计算节点挂载：

bash复制mkdir -p /home /software /scratch
mount -t nfs4 -o rw,hard,intr,noatime stor01:/data/home /home
mount -t nfs4 -o rw,hard,intr,noatime stor01:/data/software /software
mount -t nfs4 -o rw,hard,intr,noatime stor01:/data/scratch /scratch

挂载参数里 hard, intr 很重要：NFS服务器短暂卡住时，hard模式会让进程挂起等待而不会写坏数据，intr允许Ctrl+C中断进程。noatime可以减少元数据IO。

这里有一个关键排查点：UID/GID一致性。NFS共享的是文件系统，不是用户账户。如果存储节点上用户UID是1000，计算节点上同一用户名UID是1001，那用户会在NFS上看到一堆Permission denied。解决方式是所有节点的用户和组ID保持一致，最好用LDAP或Ansible统一下发用户配置。

关于目录设计，我给用户分三个目录：/home/user（小容量，放代码和配置）、/scratch/user（大容量，放中间结果和工作目录）、/data（归档数据）。这个习惯能帮你避免“home目录写满，系统锁死”的经典事故。

3. 调度器Slurm部署全记录

3.1 安装与初始化

Slurm部署是我觉得整套流程中最容易出偏差的一步，因为版本一致性、munge认证、配置文件语法，随便哪里出错都是连环报错。先推荐版本组合：Slurm 23.11 + Munge 0.5.16 + Rocky Linux 9，这个组合我验证过比较稳定。

所有节点都安装Slurm相关包：

bash复制# 如果官网没有现成rpm，可以用rpmbuild自己打，或者用fabricmanager等仓库
dnf install -y slurm slurm-munge munge munge-libs

Slurm最关键的是生成munge密钥并保证所有节点一致。密钥文件权限必须是400，属主是munge用户：

bash复制# 在管理节点生成
dd if=/dev/urandom bs=1 count=1024 > /etc/munge/munge.key
chown munge:munge /etc/munge/munge.key
chmod 400 /etc/munge/munge.key

# 复制到所有节点
for node in login01 cpu01 gpu01 stor01; do
  scp /etc/munge/munge.key ${node}:/etc/munge/
  ssh ${node} "chown munge:munge /etc/munge/munge.key && chmod 400 /etc/munge/munge.key && systemctl restart munge"
done

Slurm主配置文件是 /etc/slurm/slurm.conf。我拿一个实际可用的精简配置做示范：

conf复制ClusterName=hpc01
SlurmctldHost=mng01
AuthType=auth/munge
ProctrackType=proctrack/linuxproc
ReturnToService=1
SlurmctldPidFile=/var/run/slurmctld.pid
SlurmdPidFile=/var/run/slurmd.pid

# 调度策略，回填可以让小作业插空跑，提升集群利用率
SchedulerType=sched/backfill
SelectType=select/cons_tres
SelectTypeParameters=CR_Core_Memory

# 管理节点的CPU和内存
NodeName=mng01 NodeAddr=192.168.10.11 CPUs=32 RealMemory=240000 Sockets=1 CoresPerSocket=32 ThreadsPerCore=1 State=UNKNOWN
NodeName=login01 NodeAddr=192.168.10.12 CPUs=32 RealMemory=240000 Sockets=1 CoresPerSocket=32 ThreadsPerCore=1 State=UNKNOWN

# 计算节点，cpus计算的是总逻辑核数
NodeName=cpu[01-08] NodeAddr=192.168.20.2[1-8] CPUs=128 RealMemory=500000 Sockets=2 CoresPerSocket=32 ThreadsPerCore=2 State=UNKNOWN

# GPU节点，用Gres声明GPU资源
NodeName=gpu[01-06] NodeAddr=192.168.20.3[1-6] CPUs=128 RealMemory=950000 Gres=gpu:4 Sockets=2 CoresPerSocket=64 ThreadsPerCore=1 State=UNKNOWN

PartitionName=compute Nodes=cpu[01-08] Default=YES MaxTime=INFINITE State=UP
PartitionName=gpupool Nodes=gpu[01-06] MaxTime=INFINITE State=UP

注意这个配置里NodeAddr不要和NodeName混淆。NodeAddr是网络地址，NodeName是逻辑名，很多新手卡在“节点通信失败”就是因为这两者没对应好。

配置文件写完后检查语法，有问题会直接报错：

bash复制slurmctld -t
slurmd -t

启动顺序也有讲究：先在每个计算节点启动 slurmd，再在管理节点启动 slurmctld。反了容易出现节点UNKNOWN状态。

bash复制systemctl start slurmd   # 计算节点
systemctl start slurmctld  # 管理节点

3.2 启动与验证

启动完成后第一件事是用 sinfo 看节点状态：

bash复制sinfo -N -o "%N %t %C %m %G"

正常情况节点应该都是 idle 状态。如果出现 down、drain、unknown，优先查 /var/log/slurm/slurmd.log 和 /var/log/slurm/slurmctld.log，日志里面会明确写出原因。最常见的几类错误：

• munge认证失败：日志里出现 Invalid credential 或 Permission denied，多半是munge.key不一致或权限不对。
• 节点名解析失败：确认 /etc/hosts 是否正确。
• 节点Resource limit冲突：RealMemory写太大，超过实际内存，节点启动后自动变成down，Slurm会报“node has too much memory configured”之类。

验证调度的第一步，提交一个最简单的作业：

bash复制srun -N 1 -n 1 hostname

如果能正常返回节点名，说明基本链路通了。接着测试跨节点作业：

bash复制srun -N 2 -n 2 hostname

我习惯再提交一个占用全部资源的cpu密集型测试，比如stress工具跑满节点，确认不同节点上的任务确实在同时执行，而不是排队串行。

3.3 分区与队列设计

集群建好后，别急着全给用户共享，先规划分区。分区就是资源池，可以按硬件类型和项目用途划分。我的分区设计通常是这样：

分区里可以配置QOS（服务质量），用来限制用户使用上限，避免某个人直接占满整个集群跑一周。QOS配置在 /etc/slurm/slurm.conf 同级的 qos.conf 中：

conf复制QOSName=normal
Priority=100
GrpTRES=cpu=6400,gres/gpu=8
MaxWall=14-00:00:00

QOSName=low
Priority=10
MaxWall=3-00:00:00
GrpTRES=cpu=2000,gres/gpu=2

然后把用户加入对应QOS：

bash复制sacctmgr add account science
sacctmgr add user zhangsan account=science qos=normal

到这里，一个能跑基础作业的Slurm集群就成型了。但距离好用的集群还差两块拼图：应用环境管理和并行计算适配。下面继续。

4. 应用环境与MPI并行计算配置

4.1 编译环境和模块化管理

HPC集群最怕的就是“软件环境打架”。用户A需要gcc 9，用户B需要gcc 12，用户C需要自己编译MPI。直接把软件装到系统公共路径，总有一天会冲突到怀疑人生。

我推荐用Environment Modules或Lmod来管理并行环境。Lmod是新一代方案，语法更友好，支持modulefile自动加载依赖。安装很简单：

bash复制dnf install -y lmod

然后在 /etc/profile.d/modules.sh 里添加初始化代码，让用户登录时自动加载module命令。

modulefile放在 /software/modulefiles 目录下。比如OpenMPI的modulefile：

tcl复制#%Module1.0
set root /software/openmpi/5.0.5
prepend-path PATH $root/bin
prepend-path LD_LIBRARY_PATH $root/lib
prepend-path MANPATH $root/share/man
setenv MPI_HOME $root

注意安装OpenMPI时，建议用 --with-slurm 编译选项，这样mpirun能直接识别Slurm的PMI环境。我自己就吃过没加这个选项的亏：mpirun从Slurm里启动节点但互相找不到，折腾了两个晚上。

4.2 MPI作业跑通

常见的MPI实现有OpenMPI和MPICH。两者二选一即可，但同一个集群内最好统一，不然用户编译的代码从一个MPI换到另一个MPI必须重编译。

用Slurm提交MPI作业有两种方式：

• 最简单的方式：直接用srun启动MPI程序：

bash复制srun -N 2 -n 64 --partition=compute ./mpi_hello

• 很多用户习惯用mpirun，此时要防止mpirun二次分配资源。我建议统一用srun，或者在批处理脚本中这样写：

bash复制#!/bin/bash
#SBATCH -N 2
#SBATCH -n 64
#SBATCH -p compute
#SBATCH -o job_%j.out

module load openmpi
mpirun -np 64 ./mpi_hello

但这里有一个隐蔽的坑：如果用 mpirun，OpenMPI默认会去找环境变量里的Slurm资源信息，但如果 --with-slurm 没正确编译，mpirun可能会试图通过SSH去拉节点，导致作业卡住或者node list为空。所以再次强调，编译OpenMPI务必加上 --with-slurm。

跑通MPI之后，建议做一个检查：

bash复制srun -N 2 -n 64 --partition=compute hostname | sort | uniq -c

如果能看到每个计算节点上均匀出现了hostname输出，说明跨节点任务分发正常。如果所有输出都是同一个节点名，说明资源分配有问题。

4.3 GPU节点与CUDA环境

GPU节点配置稍微麻烦一点。首先确保驱动装好：

bash复制nvidia-smi

能正常列出显卡信息就说明驱动和NVML库OK。接着装CUDA Toolkit，建议用runfile安装法而不是系统包管理器，因为runfile更容易锁定具体版本，虚拟环境也好掌控：

bash复制wget https://developer.download.nvidia.com/compute/cuda/12.4.1/local_installers/cuda_12.4.1_550.54.15_linux.run
sh cuda_12.4.1_550.54.15_linux.run --toolkit --silent

Slurm里要管理GPU，必须配置通用资源（Gres）。在slurm.conf里加上Gres行和gres.conf：

bash复制# /etc/slurm/gres.conf
NodeName=gpu01 Name=gpu Type=A100 File=/dev/nvidia0
NodeName=gpu01 Name=gpu Type=A100 File=/dev/nvidia1
...

如果节点上的GPU型号和数量都一样，可以用更简洁的声明：

conf复制NodeName=gpu[01-06] Name=gpu Type=A100 File=/dev/nvidia[0-3]

提交GPU作业：

bash复制srun -p gpupool --gres=gpu:2 nvidia-smi

这里要特别注意：只分配GPU资源却不指定CPU和内存，很容易出现“GPU在节点A，CPU任务在节点B”的怪象吗？不会，Slurm默认同资源绑定，但你需要保证 SelectTypeParameters=CR_Core_Memory 并打开 Gres 的绑定，具体可以在slurm.conf里加：

conf复制GresTypes=gpu
NodeName=gpu[01-06] Gres=gpu:4

有的集群还需要考虑MIG（Multi-Instance GPU）切分。如果你的GPU是A100/H100且允许MIG，可以在Gres里声明为 Gres=gpu:4 并用MIG工具切分，但MIG对大型训练任务不一定友好，除非你的场景是小模型高并发推理，否则我不建议一上来就开MIG，它会让调试复杂度飙升。

5. 网络、存储与IO的调优细节

5.1 高速网络选型与配置

没有高速网络，多节点集群和一堆散电脑没有本质区别。MPI通信和分布式训练，动不动就是几十GB甚至上百GB的数据在节点间流动，千兆网根本不够看。

集群网络分两种典型方案：

• InfiniBand（IB）：延迟最低，RDMA支持最好，HPC网络老选，但交换机价格较贵，生态位在高性能计算。
• RoCE（RDMA over Converged Ethernet）：基于以太网的RDMA，性价比高，很多AI集群和大数据集群用RoCE，但需要交换机支持无损以太网（PFC、ECN）配置，不然RDMA性能会断崖式下跌。

不管哪种，我的建议都是：管理网和计算网分离，计算网至少25GbE起步，能上100GbE更好。当你有GPU训练需求时，GPU到GPU的数据交换走计算网，如果计算网被存储IO、登录流量污染，训练速度立刻打折。

如果用了IB网络，安装驱动后最常用的验证命令是：

bash复制ibstat

看端口状态是否Active，速率是否正常。然后用 ib_write_bw 做带宽测试，比如在管理节点和某个计算节点间跑：

bash复制# 服务端（计算节点）
ib_write_bw -d mlx5_0
# 客户端（管理节点）
ib_write_bw -d mlx5_0 192.168.20.31

如果带宽远低于理论值，通常是交换机丢包或者MTU不一致导致的，检查 IB 的MTU设置（默认2048或4096），以及pfc配置。

如果用的是RoCE，调试更要小心。我遇到过明明RDMA跑通，但MPI进程走TCP回退的问题。排查方法是看 /sys/class/infiniband/ 下是否有对应rdma设备，然后 ethtool -S <网卡> 看是否有 tx_prio_xoff 这类丢包计数器。出现丢包就说明PFC配置有问题，要回过去查交换机。

5.2 共享存储的性能陷阱

NFS在共享存储里属于“够用但不完美”。几个典型性能陷阱：

• 大量小文件IO：比如代码编译目录、Python解释器文件、爬虫数据目录，都是用NFS高并发访问很容易锁死。解决办法是让用户把需要大量小文件操作的任务都放到本地盘，只有需要共享的过程数据才放NFS。
• NFS单点故障：存储节点挂了，所有依赖/scratch的作业会全部卡住。我对生产集群的建议是至少做两个存储节点的HA，用DRBD或共享存储阵列+VIP漂移。小预算团队最低限度也要定期备份，不能裸奔。
• NFS over RDMA：存储节点网卡支持RDMA时，可以开启NFS over RDMA，大幅提升顺序读写的吞吐。具体在存储节点 /etc/exports 加 proto=rdma 选项，挂载端加上 rdma。

如果你的IO需求真的是持续高吞吐，果断上Lustre、BeeGFS或GPFS。Lustre是超算主流，但需要独立的MDS、OSS角色，运维门槛高；BeeGFS安装简练，社区版免费，中小规模团队用起来比较友好。我在中等规模集群上迁移过一次Lustre，说实话，迁移过程本身不复杂，复杂的是把文件系统里的数据做分层管理，以及让用户适应新的配额策略。

5.3 CPU绑定与亲和性

多核CPU上的NUMA架构是另一个性能暗坑。两个CPU插槽的主板上，内存访问本地和跨CPU的延迟差距可以到50%以上，如果你的应用是内存密集型，内存分配在远端会造成明显性能损失。

Slurm可以通过 --cpu-bind 绑定CPU核心：

bash复制srun --cpu-bind=cores -n 64 ./app

你也可以用 numactl 跑单机任务：

bash复制numactl --cpunodebind=0 --membind=0 ./app

在Slurm脚本里，通常建议让Slurm自动绑定，不要用户自己指定mask。因为用户一旦指定了自己的taskset绑定，很可能和Slurm的资源分配冲突，导致“节点明明很多核，但作业并发上不去”。

另外，在混合模式下，如果GPU训练任务在CPU端做数据预处理，建议用 --cpus-per-task 显式分配CPU核数，并配合 --gres/gpu 一起提交，比如：

bash复制srun -p gpupool --gres=gpu:4 --cpus-per-task=8 --mem=64G ./train.py

这种资源显式声明的习惯，能避免节点被某个人的隐形CPU核数占满导致GCN收敛不稳定。

6. 从HPC到云原生与AI：集群部署的新常态

6.1 大数据生态怎么和HPC共存

如果你不只是跑MPI程序，还需要跑Spark、Flink、Kafka、Doris这类大数据组件，就不能期望一个Slurm解决所有问题。传统HPC调度器对长服务、高并发短任务、状态存储支持不好。我建议的路线是：算力底座按业务拆成两套逻辑集群，物理节点可以共用，但调度层分离。

一种方案是物理节点分成两组，一组挂Slurm，一组挂K8s/Yarn。另一种方案是在K8s上把Slurm做成operator管理，也就是常说的HPC on K8s，但这需要团队对K8s和HPC都有足够经验，否则建议放弃。我见过一个团队强行HPC on K8s，结果Slurm的cgroup资源统计在K8s里各种不对，最终又拆回两套。

对大数据的组件部署，单独说几个注意点：

• Spark集群：通常用独立模式或Spark on Yarn。数据要尽量本地化，NodeManager的磁盘目录配置合理，否则shuffle读写会集中到一个磁盘。
• Doris集群：分FE（Frontend）和BE（Backend），FE可以多节点，BE负责数据存储计算。Doris对内存、磁盘和网络的依赖很高，机器选型和配置文件是最大的坑，建议先小规模验证再扩。
• Kafka集群：broker节点的日志目录要独立磁盘阵列，不能放系统盘；分区副本数和acks参数需要结合业务权衡，不是越大越稳。
• 这些大数据组件最好都跑在K8s、Docker或裸金属上，不要直接在Slurm分区里长期跑daemon进程，因为Slurm按作业生命周期管理进程，daemon进程被Slurm杀掉会让你生不如死。

6.2 大模型本地部署与推理集群

最近很多人搜“DeepSeek本地部署”“Ollama本地部署”“LM Studio本地部署”，说明AI部署需求从中心化训练平台下沉到了个人和小团队。这和HPC集群部署有什么关系？关系很大：传统HPC把资源集中调度给大批量科学计算，而AI推理通常是长时间运行的服务，需要另一套更偏云原生的部署模式。

如果你拿到一台8卡A100，想部署类DeepSeek这样的开源模型，我建议走vLLM/TensorRT-LLM，配合K8s或裸机systemd服务。这些工具会把计算图切成多个worker，支持多卡张量并行。相比用Slurm启动推理服务，vLLM这类的长服务更稳定，支持动态批处理，对刚上手的团队更友好。

至于本地单机部署，Ollama和LM Studio确实是“零门槛”选择，适合学习验证。但要清楚，它们面向的是桌面应用和单机推理，做不了多机分布式推理。等你需要把多个节点的显卡聚合起来做大规模推理，还是得回到多机多卡方案，那时候你需要考虑的又是“高性能计算集群”这套底子：高速网络、共享模型文件、GPU资源调度。

我实际测试过，用一个Slurm集群临时跑多节点vLLM分布式推理是可行的，配置DeepSeek的tensor-parallel的时候，需要所有的GPU在同一个节点或通过高带宽互联，低延时的RoCE/IB网络能显著降低推理瓶颈。但你如果要做生产级在线服务，需要弹性伸缩、滚动升级、故障自愈，那还是绕不开K8s。

6.3 监控与运维

集群搭好只是开始，运维才是长期战。我的运维三件套是：Prometheus + node_exporter + Grafana，配合Slurm exporter把作业运行状态也纳管进来。主要监控指标：

• 节点状态：CPU使用率、内存剩余、磁盘IO、网络流量、GPU温度/利用率/显存。
• Slurm作业状态：排队数、运行数、失败数、节点DRAIN变化。
• 存储健康：NFS响应时间、元数据操作延迟、inode消耗。

node_exporter装一遍后，用Prometheus抓取，Grafana画板子。我个人的建议是别追求画花哨的大屏，先记住四个关键面板：节点总览、GPU利用率、作业队列长度、存储IO延迟，这四个图排一起够用。

日志管理上，Slurm默认日志在 /var/log/slurm/，我习惯用journald转发加syslog集中存储，这样节点故障后可以在管理节点看到所有节点的系统日志。否则每次排查都要挨个登录计算节点，效率极低。

另外一定要做定期巡检，至少每周一次：磁盘空间、ZFS/RAID健康、GPU显卡是否掉卡、IB网卡的丢包计数。这些巡检命令可以用脚本放到管理节点上定时跑，有问题发邮件通知。我这边很多“突发故障”最后其实都是早期巡检已经发现苗头但没处理的。比如某块磁盘S.M.A.R.T.开始报错，没当回事，一个月后节点DRAIN，所有作业中断。

7. 常见问题与排查技巧实录

7.1 作业排队却不见节点

表现是 squeue 里作业一直在排队，但 sinfo 显示所有节点都是idle。这种情况99%是资源分配配置问题。优先检查：

• 作业请求的资源是否超过分区限制（比如请求了4隐藏GPU但分区没有这么多空闲）。
• 节点是否被DRAIN，用 sinfo -R 查看。
• 是否因为QOS限制，用户超过最大运行作业数。

我自己遇到过最经典的场景：用户请求 --nodes=4 但分区里只有3个节点，作业自然一直排队，但用户看不到节点数限制，以为集群坏了。在提交作业时用 scontrol show job <jobid> 能看到详细的资源申请原因，排查非常有帮助。

7.2 MPI作业卡死或慢

MPI作业慢，最常见的原因是走了TCP回退而非RDMA。怎么确认？查看运行作业的节点上的 /sys/class/infiniband/ 设备是否有活动，或者用 ib_write_bw 测试。如果带宽只有几个Gb/s，而不是几十上百Gb/s，那就说明网络栈没走对。

排查步骤：

• 确认OpenMPI编译时带 --with-slurm 和 --with-ucx 或 --with-opa。
• 检查是否开启FAST HASH，比如UCX的 UCX_TLS=ib。
• 在节点上用 ibstat 确认HCA口处于Active。

另外，MPI作业卡死的常见原因：节点间需要互信时，某些节点私钥不对；或者NFS挂载在主节点返回IO错误，导致进程在写文件时无限等待。遇到卡死不要盲目kill，先 scontrol show job <jobid> 看进程分布，再确认是不是有节点IO异常。

7.3 存储IO打满，存储节点负载高

存储节点CPU不高但系统load很高，多半是IO性能问题。用 iostat -x 1 看 util%，如果接近100%，说明磁盘阵列已经饱和。再配合 nfsstat 看NFS协议的读写分布和延迟。

处理办法有几个方向：

• 把适合并行访问的数据和随机访问的参数文件拆到不同目录，避免串扰。
• 有条件上SSD缓存（BCache/LVM cache或用ZFS的ARC/L2ARC）。
• 对大目录做配额限制，防止某个用户把存储写爆，导致全集群IO抖动。

7.4 GPU任务报错显存不足或卡死

GPU任务常见的报错包括 CUDA error: out of memory、cannot allocate memory、NCCL failure。先明确是显存不够还是GPU驱动/通信库问题。

• nvidia-smi 看显存占用，如果真满了，找是谁占了：fuser -v /dev/nvidia* 或 nvidia-smi --query-compute-apps=pid,used_memory --format=csv。
• 如果显存明明够但NCCL报错，检查节点间的GPU通信是否走NVLink/IB。NCCL常见环境变量：NCCL_DEBUG=INFO 可以看到具体走的是什么传输。
• 多卡训练时，建议给每个进程设置唯一CUDA设备，防止多进程抢占同一块卡。用Slurm提交时加 --gres/gpu 以及环境变量：

bash复制srun -p gpupool --gres=gpu:4 --cpus-per-task=8 bash -c "CUDA_VISIBLE_DEVICES=$SLURM_JOB_GPUS python train.py"

7.5 作业意外中断

作业运行到一半被kill，排查优先级是：

• sacct -j <jobid> 查看ExitCode和终止信号。
• 查看/var/log/slurm/slurmctld.log，确认是不是被Slurm强制回收。
• 确认是否超出Partition或QOS的MaxTime。
• 检查是否是OOM（Out Of Memory），用 dmesg | grep -i oom 在计算节点上确认。

这里有个容易被忽略的点：OOM Killer 只会在操作系统内存耗尽时触发，但你在Slurm配置里如果 RealMemory 设置得比实际内存小，任务实际用内存并没有超过节点物理限制，但Slurm会提前终止作业，报错还特别隐晦。所以给节点配RealMemory的时候，最好按物理内存的95%左右写，留下系统余量。

7.6 常见问题速查表

这表格是我实际排障的浓缩版，对刚上手的朋友来说，可以作为兜底的排查清单。

最后再分享一个小习惯。每次搭完一台新节点，不管多忙，我都要求自己把三样东西记下来：节点硬件清单、网络IP和VLAN对应关系、Slurm和NFS的配置变更记录。为啥？集群一旦超过10台，配置管理靠脑子的时代就结束了。我后来养成了用Ansible管理集群配置的习惯：主机名、hosts文件、chrony、NFS挂载、Slurm配置、munge key分发，全部写成playbook。新节点加进来，一条ansible-playbook跑完，再也不会出现节点间配置不一致的鬼故事。这个投入对长期运维来说非常值得。