简介这是一份面向HPC初学者、系统架构师与运维工程师的高性能计算架构设计参考文档围绕HPC基础概念、系统组成与主流技术路线展开帮助读者建立从计算、存储、网络到集群软件的完整认知框架。内容涵盖HPC分类方式高吞吐计算与分布计算、X86处理器与Linux操作系统的主流选型、刀片系统构建方式、IB与10GE互联网络以及MPI节点、胖节点、GPU加速节点三类计算节点的定位差异并延伸至CPU性能计算公式、Linpack基准测试、DIMM内存类型等关键知识点。资源包为1个docx文档约979KB结构紧凑适合作为技术入门与方案梳理的案头资料。目前已有225人学习读者可借此快速掌握HPC性能衡量方法、GPU加速原理及气象预报、材料科学、生命科学、金融分析等典型应用场景为架构选型与方案设计提供参考。1. 从一份 docx 说起HPC 高性能计算架构设计到底在解决什么问题很多人第一次接触 HPC 高性能计算架构设计是从一份名为HPC高性能计算架构设计.docx的文档开始的。它可能来自某个内部立项、某次技术评审或者某个甲方甩过来的需求附件。文档本身不神秘真正让人头疼的是看完之后不知道从哪下手——集群怎么搭、网络怎么选、存储怎么配、调度器用哪个、运维怎么兜底这些问题文档里往往只给了名词没给路径。HPC 高性能计算架构设计要解决的核心问题是把一堆 CPU、GPU、高速网络和并行存储组织成一台“逻辑上的超级计算机”让气象预报、CAE 仿真、分子动力学、AI 大模型训练这类算力密集型任务能在可接受的时间内跑完并且跑得稳、跑得可复现。它适合两类人一类是正在从零搭建或改造计算集群的工程师另一类是接手了别人集群、需要做架构评审和性能调优的运维人员。这份文档标题里没有写具体行业但架构设计的通用逻辑是相通的。下面我按“先立住理论、再动手复现、最后讲坑”的顺序把 HPC 架构设计拆成能落地的步骤。你不需要先看完那份 docx跟着走也能把最小可用集群跑起来。2. HPC 架构的四层骨架计算、网络、存储、调度怎么选2.1 计算节点选型CPU 主频、核数与 GPU 加速比的取舍HPC 集群的计算节点不是越贵越好而是要看任务特征。CFD 类任务通常吃内存带宽和核间通信主频高、核数适中32~64 核的 CPU 节点往往比 128 核低频节点更快AI 训练类任务则更依赖 GPU 的显存和 NVLink 带宽。常见做法是分池CPU 池跑传统 MPI 任务GPU 池跑 PyTorch/TensorFlow 任务通过调度器统一纳管。选型时先算一笔账假设你有 100 万核时/月的需求单节点 64 核、利用率 70%那么需要约 1000000 / (64 × 24 × 30 × 0.7) ≈ 31 个节点。这个粗算能帮你判断预算量级避免一开始就拍脑袋买机器。提示不要忽略内存配比。CFD 任务常见配比是每核 4~8GB 内存AI 训练节点则按 GPU 显存 2~4 倍配系统内存否则会出现“CPU 等内存”的假性瓶颈。2.2 网络互联InfiniBand 与 RoCE 的实测差异和选型边界HPC 的网络不是“能通就行”而是决定并行效率的关键。MPI 集合通信Allreduce、Alltoall对延迟和带宽极其敏感。InfiniBand 的延迟通常在 1~2 微秒RoCEv2 在 3~5 微秒看起来差距不大但在 512 节点以上的大规模并行任务里累积延迟会直接吃掉 20% 以上的加速比。选型边界很清晰节点数少于 32、任务以单机多卡为主RoCE 足够且成本低节点数超过 64、频繁跨节点 MPI 通信优先 InfiniBand。如果预算卡在中间可以计算节点用 IB、管理网络用万兆以太网这是最常见的混合做法。2.3 并行存储Lustre、GPFS 与 NFS 的适用场景存储是 HPC 架构里最容易翻车的一层。NFS 在小规模10 节点以内还能凑合一旦并发写超过 20 个节点元数据服务就会成为黑匣子式的瓶颈。Lustre 和 GPFS 是主流并行文件系统前者生态开放、社区资料多后者在 IBM 生态里集成度高。一个可抄的配置思路元数据节点MDS用 NVMe SSD 做元数据盘对象存储节点OSS用 8~12 块大容量 HDD 做 RAID6单 OSS 带宽目标 2~4GB/s。客户端挂载时务必调大max_read_ahead和max_write参数否则默认值会让顺序读写性能打对折。2.4 调度器Slurm 与 PBS 的配置差异与迁移成本Slurm 是目前新建集群的首选配置灵活、社区活跃PBS Pro 在传统超算和企业环境里仍有存量。两者核心概念对应关系是Slurm 的 partition 对应 PBS 的 queueSlurm 的sbatch对应 PBS 的qsub。迁移时最大的坑是资源限制语法不同。Slurm 用--mem-per-cpuPBS 用-l memSlurm 的 GPU 申请是--gresgpu:2PBS 是-l ngpus2。如果脚本里硬编码了调度器指令迁移时需要逐行改写建议一开始就用环境变量或包装脚本隔离。3. 从零跑通一个最小 HPC 集群Slurm MPI 实操3.1 三节点集群的硬件与系统准备先准备 3 台机器1 台管理/登录节点2 台计算节点。系统统一用 Rocky Linux 9 或 Ubuntu 22.04关闭 SELinux 和防火墙内网环境配置主机名和 hosts 解析。三台机器之间用万兆交换机互联管理节点额外挂一块 SSD 做共享存储。基础环境命令如下# 三台机器统一执行设置主机名和 hosts hostnamectl set-hostname hpc-master # 计算节点改为 hpc-node01 / hpc-node02 cat /etc/hosts EOF 192.168.1.10 hpc-master 192.168.1.11 hpc-node01 192.168.1.12 hpc-node02 EOF # 关闭 SELinux 和防火墙内网测试环境 setenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config systemctl stop firewalld systemctl disable firewalld # 配置免密登录管理节点生成密钥并分发 ssh-keygen -t ed25519 -N -f /root/.ssh/id_ed25519 for node in hpc-node01 hpc-node02; do ssh-copy-id -i /root/.ssh/id_ed25519.pub root$node done这段脚本做了三件事统一主机名和解析、关闭安全组件避免 MPI 通信被拦截、配置 root 免密登录。参数上ed25519比 RSA 更短更快-N 表示空密码适合内网自动化。注意生产环境不要直接关防火墙而是按端口放行 Slurm 的 6817/6818 和 MPI 的动态端口段。3.2 Slurm 的安装与 slurm.conf 关键参数管理节点和计算节点都安装 Slurm但角色不同。管理节点跑slurmctld计算节点跑slurmd。# 所有节点安装 Slurm dnf install -y slurm slurm-devel munge munge-devel # 生成 munge key 并分发所有节点一致 dd if/dev/urandom bs1 count1024 /etc/munge/munge.key chown munge:munge /etc/munge/munge.key chmod 400 /etc/munge/munge.key scp /etc/munge/munge.key roothpc-node01:/etc/munge/ scp /etc/munge/munge.key roothpc-node02:/etc/munge/ # 所有节点启动 munge systemctl enable --now mungeslurm.conf是核心配置文件管理节点和计算节点必须完全一致。最小可用配置如下# /etc/slurm/slurm.conf ClusterNamehpc-lab SlurmctldHosthpc-master SlurmUserslurm SlurmdUserroot AuthTypeauth/munge StateSaveLocation/var/spool/slurmctld SlurmdSpoolDir/var/spool/slurmd SchedulerTypesched/backfill SelectTypeselect/cons_tres SelectTypeParametersCR_Core_Memory NodeNamehpc-node01 CPUs32 RealMemory64000 StateUNKNOWN NodeNamehpc-node02 CPUs32 RealMemory64000 StateUNKNOWN PartitionNamecpu Nodeshpc-node01,hpc-node02 DefaultYES MaxTimeINFINITE StateUP关键参数说明SelectTypeselect/cons_tres表示按核和内存做资源分配比默认的按节点分配更精细SchedulerTypesched/backfill开启回填调度能利用大任务等待间隙跑小任务提升利用率RealMemory单位是 MB要略小于物理内存给系统留余量。配置完成后管理节点启动slurmctld计算节点启动slurmd用sinfo验证节点状态是否为idle。3.3 MPI 程序编译与 sbatch 提交模板装好 OpenMPI 或 MPICH编译一个最简单的 MPI 程序验证跨节点通信# 所有节点安装 OpenMPI dnf install -y openmpi openmpi-devel echo export PATH/usr/lib64/openmpi/bin:$PATH /etc/profile.d/openmpi.sh echo export LD_LIBRARY_PATH/usr/lib64/openmpi/lib:$LD_LIBRARY_PATH /etc/profile.d/openmpi.sh source /etc/profile.d/openmpi.sh/* hello_mpi.c打印每个进程所在节点和 rank */ #include mpi.h #include stdio.h #include unistd.h int main(int argc, char** argv) { MPI_Init(argc, argv); int rank, size; char hostname[256]; MPI_Comm_rank(MPI_COMM_WORLD, rank); MPI_Comm_size(MPI_COMM_WORLD, size); gethostname(hostname, sizeof(hostname)); printf(Rank %d of %d on %s\n, rank, size, hostname); MPI_Finalize(); return 0; }编译命令mpicc -O2 -o hello_mpi hello_mpi.c。然后用 sbatch 提交#!/bin/bash #SBATCH --job-namempi-test #SBATCH --nodes2 #SBATCH --ntasks-per-node4 #SBATCH --partitioncpu #SBATCH --time00:05:00 #SBATCH --outputmpi-test-%j.log module load mpi/openmpi-x86_64 mpirun -np 8 --hostfile $SLURM_JOB_NODELIST hello_mpi--nodes2和--ntasks-per-node4表示跨 2 个节点各起 4 个进程共 8 个 rank。$SLURM_JOB_NODELIST是 Slurm 自动生成的主机列表避免手写 hostfile。提交后看日志如果 8 个 rank 分布在两台机器上说明 MPI 跨节点通信已经通了。这一步跑通最小 HPC 集群就算立住了。4. 性能调优与运维让集群从“能跑”到“跑得快、跑得稳”4.1 用 perf 和 IPM 定位 MPI 通信瓶颈集群能跑之后下一步是看它跑得怎么样。MPI 程序最常见的性能问题是集合通信不均衡。用 IPMIntegrated Performance Monitoring可以低开销地采集每个 rank 的通信时间占比# 安装 IPM 后在 sbatch 脚本里替换 mpirun mpirun -np 8 -genv IPM_LOGfull ipm_hello_mpi # 运行结束后生成 root.ipm.xml用 ipm_parse 转成文本报告 ipm_parse -html root.ipm.xml报告里重点看MPI_Allreduce和MPI_Barrier的时间占比。如果 Allreduce 超过总时间 30%说明网络或算法需要优化常见手段是换用MPI_Allreduce的分层算法或者检查是否误用了全局同步。4.2 存储 IO 的 fio 基准测试与 Lustre 参数调整存储性能不能靠感觉要用 fio 压出来。在计算节点上对共享存储做顺序写测试# 顺序写1M 块大小8 个并发任务跑 60 秒 fio --nameseqwrite --directory/shared/test \ --rwwrite --bs1M --size10G --numjobs8 \ --time_based --runtime60 --group_reporting # 随机读4K 块大小32 队列深度 fio --namerandread --directory/shared/test \ --rwrandread --bs4k --size10G --numjobs32 \ --iodepth32 --time_based --runtime60 --group_reporting如果顺序写带宽低于 1GB/s先查 OSS 的 RAID 条带和网络是否跑满如果随机读 IOPS 低于 5000检查 MDS 的元数据盘是否成为瓶颈。Lustre 客户端侧可以调/etc/lustre/下的max_read_ahead_mb和max_write_mb通常设成 64~128 能明显改善大文件吞吐。4.3 节点健康检查与作业重排队机制HPC 集群最怕的是“僵尸节点”——Slurm 显示 idle但实际 SSH 不通或 GPU 掉卡。常见做法是写一个定时巡检脚本结合sinfo和pdsh批量检查#!/bin/bash # health_check.sh检查所有计算节点连通性和 GPU 状态 for node in $(sinfo -N -h -o %N); do if ! ssh -o ConnectTimeout5 $node nvidia-smi -L /dev/null; then echo [$(date)] $node GPU check FAILED, draining scontrol update NodeName$node StateDRAIN Reasonhealth_check_failed fi done配合 Slurm 的ReturnToService2参数节点被 drain 后如果 slurmd 重新注册成功会自动恢复服务。作业侧建议在 sbatch 里加--requeue节点故障时作业自动重排队避免人工重提。5. 避坑与排查HPC 架构设计里最容易翻车的 5 个点5.1 现象MPI 程序跨节点运行报“Permission denied (publickey)”原因Slurm 和 MPI 的认证体系是两套。Slurm 用 munge 认证MPI 的mpirun默认走 SSH如果计算节点之间没有配置免密跨节点启动就会失败。解决要么在所有计算节点之间配置 root 或专用用户的 SSH 免密要么在mpirun时指定--mca plm_rsh_agent ssh -q并确保密钥已分发。更彻底的做法是用 Slurm 的srun替代mpirun直接复用 Slurm 的认证通道。5.2 现象作业提交后一直 PENDINGReason 显示“Resources”原因分区资源被占满或者MaxTime设置过短导致大作业永远排不上。也可能是SelectType配置为按节点分配而节点内存碎片化严重。解决用scontrol show job jobid看具体原因用sinfo -o %P %a %l %D %t %N看分区状态。如果是内存碎片把SelectType改成cons_tres并开启CR_Core_Memory如果是 MaxTime 限制调整分区或作业的--time。5.3 现象Lustre 挂载后写入速度只有几十 MB/s原因客户端挂载参数默认值保守或者 OSS 的 RAID 条带宽度与块大小不匹配。也可能是网络走了管理网而不是高速网。解决检查lctl get_param osc.*.max_write和max_read_ahead调大到 64MB 以上确认 Lustre 的lnet网络接口绑定的是 IB 或万兆网卡而不是 1G 管理口RAID 条带建议 256KB~1MB与 Lustre 的stripe_size对齐。5.4 现象GPU 节点跑训练任务时随机掉卡dmesg 报 Xid 错误原因常见于 GPU 散热不良、PCIe 链路降速或驱动版本与 CUDA 不匹配。Xid 48 通常是 ECC 错误Xid 79 是 GPU 掉总线。解决先查nvidia-smi -q的 ECC 错误计数和 PCIe 链路宽度如果是散热问题清理风道或调高风扇曲线驱动和 CUDA 版本严格按 NVIDIA 兼容性矩阵来不要混用。掉卡频繁的节点直接 drain 送修不要带病运行。5.5 现象Slurm 控制节点重启后所有作业状态丢失原因StateSaveLocation指向的目录没有持久化或者slurmctld启动时没有正确加载状态文件。解决确保/var/spool/slurmctld在本地 SSD 或共享存储上并且slurmctld有写权限重启前用scontrol reconfigure而不是直接 kill生产环境建议配slurmdbd MySQL 做作业记账即使控制节点挂了也能从数据库恢复历史。6. 进阶技巧用 cgroup 做作业级资源隔离与能耗监控最小集群跑通之后真正拉开架构水平的是资源隔离和能耗控制。Slurm 默认只做逻辑分配不阻止作业超用内存或 CPU。开启 cgroup 后每个作业的 CPU、内存、甚至 GPU 都能被硬限制避免“一个作业拖垮整个节点”。配置分两步。第一步在slurm.conf里加ProctrackTypeproctrack/cgroup TaskPlugintask/cgroup ConstrainCoresyes ConstrainRAMSpaceyes ConstrainSwapSpaceyes第二步在计算节点创建/etc/slurm/cgroup.confCgroupAutomountyes ConstrainCoresyes ConstrainRAMSpaceyes AllowedRAMSpace100 AllowedSwapSpace0AllowedRAMSpace100表示允许使用申请内存的 100%超过就 OOM killAllowedSwapSpace0禁止用 swap防止作业被换出后性能断崖。改完systemctl restart slurmd再用systemd-cgtop就能看到每个作业的实时资源占用。能耗监控方面如果节点支持 IPMI可以用ipmitool采集整机功耗结合 Slurm 的sacct数据算出每个作业的能效比性能/瓦特# 采集节点功耗需要 IPMI 权限 ipmitool -I lanplus -H 192.168.1.11 -U admin -P password dcmi power reading # 结合 sacct 看作业耗时和 CPU 时间 sacct -j jobid --formatJobID,Elapsed,TotalCPU,MaxRSS,State把功耗和作业数据按天聚合就能识别出哪些用户或哪些代码在“空转烧电”。我一般会设一个阈值如果某作业的 CPU 利用率低于 30% 且持续超过 1 小时就发提醒给提交者。这个习惯帮我省过不少电费也逼着大家把串行代码改成并行。最后说一句血泪经验HPC 架构设计里最贵的不是硬件是返工。网络选型、存储配比、调度器参数这三件事一旦上线后再改迁移成本往往是初始投入的数倍。所以宁可前期多花两周做基准测试和 PoC也不要拍脑袋上生产。希望帮到你。本文还有配套的精品资源点击获取
