1. 先打破一个幻想高性能集群不是买一堆高配机器怼上去做高性能计算集群部署这行久了我见过太多开局一台堡垒机其余全靠买买买的项目。采购清单里清一色顶配CPU、大内存、NVMe硬盘网络随便配了个万兆交换机结果集群装完一跑业务性能还不如原来几台独立服务器轮流干活来得快。这个现象在行业里特别典型我管它叫高性能摆设综合征。问题根源不在于硬件不够好而在于大部分人没想明白一个问题你的业务到底属于哪种计算模式集群的瓶颈到底在哪里。在我接手过的集群项目里真实需求大致可以分成三类第一类是计算密集型。典型如分子动力学模拟、有限元仿真、天气预报模式特点是单核计算量大节点之间通信频繁但数据量不算夸张。这类业务吃CPU主频和缓存更吃低延迟网络。第二类是数据密集型。典型如基因组比对、日志分析、机器学习训练样本处理特点是数据量巨大计算过程简单重复瓶颈往往在存储的IOPS和吞吐上CPU反而富裕。第三类是混合型。既要跑大规模并行计算又要承载数据入库、ETL、实时计算这些服务比如很多科研机构给高性能计算集群旁边再挂一套大数据平台。这类场景最难搞因为计算队列和存储队列会相互抢资源。我在做集群部署方案的时候第一步永远不是列硬件清单而是做一次业务画像。把团队现有的作业脚本、数据规模、运行时长全部统计一遍算出三个数单个作业的平均核心数、峰值并发作业数、数据读写比例。有了这三个数才能判断该把钱花在CPU上、网络上还是存储上。这里想给正在规划集群的团队一个比较实在的建议先花两周时间做负载观测把监控脚本跑起来看看现有服务器在业务高峰时CPU利用率多少、磁盘队列多长、网络带宽消耗多少。很多团队跳过这一步直接采购结果就是要么CPU常年闲置、要么存储读写拍脑袋配大了三倍。观测数据远比厂商宣传册上的理论性能靠谱。2. 硬件选型与网络拓扑从够用到好用的差距就在这些细节里2.1 计算节点配置的黄金配比确定业务模式之后计算节点的配置就比较好定了。我这些年总结出一个相对稳妥的配比可以供参考业务类型CPU配置内存配比本地存储网络要求计算密集型高主频3.0GHz每核心2~4GBSSD系统盘少量数据盘IB/25G以上低延迟数据密集型高核心数64核每核心4~8GB大容量NVMe或SATA SSD万兆起步GPU计算中高配CPUGPU每GPU 32~64GB高速本地缓存盘IB或100G这里单独说下CPU选型。Intel和AMD两个平台我都大规模部署过如果用一句话总结差异AMD EPYC在核心数上有明显优势性价比高适合大规模并行任务Intel在AVX-512指令集上有积累如果你的代码用到了MKL这类数学库Intel平台反而能发挥更大优势。所以不要盲目跟风追新平台要看自己的应用程序吃的是哪一套生态。内存这块有个容易被忽略的点高主频CPU对内存通道数很敏感。我见过一个案例两台配置几乎一样的机器一台插了8条32GB内存一台只插了4条跑同样的流体仿真后者性能掉了近三成。原因就是内存通道没跑满CPU等数据的周期变长了。买机器的时候务必确认主板支持多少内存通道尽量插满或者按通道数对称插。2.2 网络拓扑集群的心脏网络是高性能计算集群里最容易被低估的部分但恰恰是它决定了集群到底是不是高性能。先说结论能上IBInfiniBand就上IB上不了IB就老实上25G/100G以太网千万别用千兆口撑集群。这话听起来像废话但我在实际项目里真的见过不少集群内部还是千兆互联管理节点用万兆计算节点全体千兆。这种拓扑跑MPI作业跨节点通信直接拖垮所有并行效率四节点跑出来的加速比可能只有1.5。IB网络的优势在于RDMA远程直接内存访问机制数据不经过CPU协议栈就能从一块网卡直接进另一块网卡的显存/内存延迟低到微秒级带宽轻松跑满。缺点是贵而且交换机配线、子网管理器配置都有额外学习成本。如果预算有限25G以太网配合RoCERDMA over Converged Ethernet也能做到接近IB的效果但是配置调优的坑比较多。拓扑结构上小规模集群10节点以内可以单交换机扁平组网省事。几十节点规模的集群一定要分管理网和计算网管理网负责登录、调度、监控这类控制流量计算网专跑数据。让我觉得很无语的是有人图省事把管理和计算塞进同一个VLAN结果一个大作业跑起来SSH登录都卡成幻灯片。2.3 存储节点的独立价值我在前文提到存储常常是隐形瓶颈这里展开讲一下。很多高性能计算项目把存储挂在管理节点的几块盘上美其名曰NFS够用了。短期跑小数据确实没毛病但一旦并发作业数上来单台NFS的吞吐很容易被压垮。存储节点最好是独立1~2台机器配备硬件RAID卡或者HBA卡配上SSD缓存层对外提供NFS或者发给分布式文件系统做存储后端。硬件选型上存储节点对CPU要求不高但网卡一定要跟计算节点同规格否则计算节点的IB带宽全浪费在等数据上。内存大一点因为NFS服务本身比较吃内存做缓存。3. 集群软件栈搭建操作系统、调度器、MPI环境的组合拳硬件到位以后集群能不能稳定跑起来90%的功夫在软件栈的搭建上。这一节我完整走一遍我从零搭建集群的流程这些步骤基本可以直接抄作业。3.1 操作系统与基础环境配置计算节点操作系统我统一用Rocky Linux或AlmaLinuxRHEL系不折腾自己编译的定制内核——除非你有特殊驱动需求。选择RHEL系而不是Debian系的原因很现实Fluent、ANSYS、VASP这些商业软件和科学计算库对RHEL系的兼容性验证最充分遇到问题网上的解决方案也多。系统装完之后有几项基础配置必须做关闭防火墙和SELinux内网集群可以这样做省去大量排查诡异连接问题的精力统一NTP时间同步集群内所有节点的时钟误差必须控制在毫秒级否则分布式存储和时间戳类作业会出问题配置SSH免密登录建议用密钥认证而不是密码方便后期自动化管理设置tuned性能模式把CPU governor调成performance避免省电策略拖慢计算很多人在这一步会纠结要不要用容器化部署。我的经验是管理节点和登录节点可以把Slurm等核心服务放进容器跑但计算节点的作业执行环境最好还是用裸机加模块化环境管理。原因很直接高性能计算作业对CPU指令集、GPU驱动、MPI库版本都要精确匹配容器里多做一层虚拟化排查性能损耗的问题就多一层不确定性。3.2 作业调度器Slurm部署实践作业调度器是集群的中枢神经系统选型上我没纠结直接用的Slurm。免费、开源、生态大几乎所有主流科学计算应用都能对接而且文档齐全。Slurm部署入门其实不难基本流程如下第一步在管理节点安装slurmctld在各计算节点安装slurmd# 管理节点 yum install slurm slurmctld slurm-slurmmmd # 计算节点 yum install slurm slurmd第二步配置slurm.conf。这是最核心的文件需要定义节点信息、分区信息、调度策略。我给你一个最小可用的示例# slurm.conf 关键片段 ClusterNamehpc-cluster SlurmctldHostmaster MpiDefaultpmi2 ProctrackTypeproctrack/linuxproc ReturnToService2 SlurmctldPidFile/var/run/slurmctld.pid SlurmdPidFile/var/run/slurmd.pid AuthTypeauth/munge # 节点定义cnode01~cnode16每节点64核 NodeNamecnode[01-16] CPUs64 StateUNKNOWN # 分区定义 PartitionNamecompute Nodescnode[01-16] DefaultYES MaxTime72:00:00 StateUP这里有个我踩过的坑CPUs参数必须写对最好用scontrol show node核一遍。如果你定义的核心数和实际核心数不匹配作业调度很可能出现同一节点被超额分配的情况导致多个作业抢占CPU互相拖慢。第三步各节点启动服务并注册systemctl start munge systemctl start slurmctld # 管理节点 systemctl start slurmd # 计算节点 # 管理节点上确认节点注册成功 sinfoSlurm部署完成后日常提交作业用srun/sbatch/salloc三个命令就够了。我的习惯是给所有用户写一个作业提交模板脚本把--partition、--nodes、--ntasks、--cpus-per-task这些参数全部预设好避免新用户随手写个脚本把整个集群资源占满。3.3 MPI环境跨节点并行怎么落地HPC集群的灵魂是跨节点并行而跨节点并行全靠MPIMessage Passing Interface。部署MPI环境的时候有两个流派Intel MPI和OpenMPI我的建议是两边都装用环境模块Environment Modules切换。安装其实很简单# OpenMPI 安装示例 yum install openmpi openmpi-devel # Intel MPI 从Intel官网获取安装包注意和Intel编译器版本匹配真正需要注意的坑在路上编译和运行时MPI库必须一致。很多团队在编译应用时用了Intel MPI提交作业时环境里加载的却是OpenMPI这种错配会直接导致作业在某一节点上段错误崩溃。我这边定了一条铁律应用编译机器和运行节点的module环境必须完全一致服务器名改不了也要在编译前明确记录下来。另外一个MPI性能相关的优化点把网卡驱动和OFEDOpenFabrics Enterprise Distribution栈配齐。很多MPI作业跨节点传输走的是TCP回环看起来作业在跑实际吞吐根本没用上IB网卡。用ibstatus和ibv_devinfo验证一下网卡状态再在作业脚本里显式指定网络接口变量比如I_MPI_FABRICSshm:ofi只走了共享内存加IB能明显改善跨节点延迟。4. 共享存储系统集群的隐形瓶颈在哪里4.1 别让NFS变成集群的独木桥前面我已经多次提到存储这里专门展开讲。很多人部署集群的第一个反应是管理节点上开个NFS共享目录所有节点挂载上去就行了。这个方案在节点数少于8个、并发IO不高的场景下确实可行但一旦规模上去NFS单机服务就会成为整个集群的独木桥。NFS的问题主要集中在两方面单点吞吐上限。一台物理服务器的网络带宽和磁盘IO上限就那么多计算节点越多争抢越严重。锁机制性能差。NFSv4的锁在多个客户端并发写同一个文件时很容易出现锁竞争导致写入延迟飙升。我在实际部署中的做法是分级存储架构热数据正在计算的数据放在计算节点本地NVMe盘或SSD上用完即走路径统一指向/scratch/节点名。温数据频繁读写但不要求瞬时吞吐放到集中式存储节点用NFS或GlusterFS提供共享目录。冷数据归档备份放到大容量机械盘组成的存储池甚至可以接对象存储网关做异地备份。这样分级的好处是让昂贵的高速存储只服务高价值流量冷数据占用廉价机械盘成本直接下降一个量级。4.2 并行文件系统的选型与部署当集群规模超过20个计算节点NFS就已经明显hold不住了这时候要考虑并行文件系统。这个领域的标杆是Lustre、BeeGFS、GPFS现在叫Storage Scale这三选一。我的选择和个人经验如下BeeGFS开源性好部署简单社区活跃性能比NFS高一个数量级。适合中小规模集群运维成本低我们这边的主力存储就是BeeGFS。Lustre性能天花板极高但部署和运维复杂度也高需要专门的存储服务器和管理节点适合超算中心和几十PB级别的场景。如果你没有专职存储运维人员不建议直接上Lustre。GPFSStorage ScaleIBM的商业产品性能稳定功能丰富有配额、快照、双活等但授权费用不低适合企业级核心业务。以BeeGFS为例它的部署逻辑是组件化的管理服务management、元数据服务metadata、存储服务storage、客户端client。元数据服务和存储服务可以合在一台机器上也可以分开根据你的性能需求灵活调整。部署完以后我会专门做一轮IO500基准测试看看读写的聚合带宽到底达不达标。如果聚合带宽连单个节点网卡带宽的三倍都跑不到先怀疑网络配置再怀疑BeeGFS的stripe条带化参数没调好。5. 顺带聊聊大数据组件的集群化部署Kafka、Doris、Redis的注意点搜索热词里有好几个大数据组件这也是很多高性能计算集群演进的下一站——业务跑起来以后数据规模上来了大家自然会想引入实时数仓、消息队列、缓存这些配套组件。我在部署过若干套HPC集群之后也深度介入过Kafka、Doris、Redis的集群化部署这里把经验一并整理。5.1 Kafka三节点集群最少也要三个节点别幻想两节点能搞Kafka集群部署网络上教程很多我这边只想讲三个实际运维中最容易踩的坑第一个坑不懂副本机制就乱调分区数。Kafka的副本分布在多个broker上如果分区数少于broker数集群的优势就体现不出来。我遇到过一个集群Topic的分区数为2但是集群有三台broker结果其中一个broker完全空闲另外两台节点扛所有流量Kafka的性能优势丧失殆尽。合理做法是分区数至少和broker数对齐多分配几个分区也有利于并行消费。第二个坑存储盘类型选错。Kafka对磁盘要求是顺序写为主用HDD其实就能跑但是如果你给它配了NVMe盘但是把log.segment.bytes没调大反而会频繁创建segment文件产生大量小文件碎片性能不升反降。可以按照这个思路调log.segment.bytes536870912512MBlog.retention.hours72写入延时不敏感的可以开log.flush.interval.messages10000。第三个坑没配监控就敢上线。Kafka集群没有监控等于睁眼瞎。JMX_PORT开了之后配合PrometheusGrafana的Kafka Exporter可以盯着broker的under-replicated分区数、消息堆积速率、请求队列长度这几个核心指标。我见过太多Kafka集群挂掉之后查日志才发现消息堆积了整整三天。5.2 Doris集群部署从单机复核到分布式Doris在热词里排第一说明很多人正在做实时数仓选型。Doris的集群部署逻辑和传统HPC集群不太一样它是MPP架构有两个核心角色FEFrontend负责SQL解析、查询规划、元数据管理类似HPC集群里的登录调度节点。BEBackend负责数据存储和查询执行类似计算节点。Doris集群最小部署是1FE1BE生产环境建议3FE3BE起。FE之间用类似Raft的协议做元数据一致性BE负责数据多副本。部署的时候几个容易忽略的细节FE需要单独安装Java环境JDK8并设置JAVA_HOME。BE节点需要关闭swap否则Doris的基于内存的查询模型会频繁触发swap性能断崖式下跌。每个BE建议配置多块数据盘Doris会自动做数据均衡。如果部署后遇到Doris导入数据慢的问题先看磁盘IO如果查询慢先看FE的查询规划是否走了Broadcast还是Shuffle。这里有个经验表设计时尽量用Duplicate模型对大多数明细查询场景来说排序键和分桶键设置得当性能就已经很能打了。5.3 Redis集群别再用主从代替Cluster模式Redis集群部署也是搜索热门我想强调一个明显误区有很多人用主从复制哨兵模式来实现集群这其实不是Redis Cluster只是高可用方案。一旦数据量超过单机内存照样抓瞎。Redis Cluster模式至少需要3主3从部署时用redis-cli --cluster create命令可以把节点自动组织起来。配置方面核心是cluster-enabled yes、cluster-config-file nodes.conf这两项。实际操作中我会额外注意两点一是网络延迟。Redis Cluster要求节点间延迟尽量低。如果三个节点跨机房部署网络延迟一高会引起频繁的failover和cluster状态抖动。HPC集群内的Redis应该都放在同一机架或同一接入交换机下。二是内存配置。Redis的maxmemory不要配满物理内存要留一部分给操作系统页缓存和Redis自身的RDB持久化。否则一旦内存满了触发淘汰策略线上业务会明显卡顿。如果说HPC集群是算力工厂那么Kafka和Redis就是数据管道Doris则是数据仓库它们协同起来才构成一套完整的数据处理链路。6. 集群上线前的压测与验收不烧机三天的部署都是耍流氓集群部署完毕不代表大功告成。我见过太多集群交付时信心满满上线三天各种问题连环爆。所以我自己有一条铁规矩集群上线前必须经历72小时的压力测试与验收。这一步省了后面运维会被动到怀疑人生。压测主要分三个维度6.1 网络压测用iperf3跑TCP还是不够的HPC必须用MPI的延迟/带宽测试工具。典型做法是# 节点间延迟测试 mpirun -np 2 -host cnode01,cnode02 /usr/mpi/bin/imb-MPI1 PingPong # 聚合带宽测试 mpirun -np 16 -hostfile hosts /usr/mpi/bin/imb-MPI1 Alltoall重点关注两个数字PingPong延迟要在10微秒以下IB环境Alltoall聚合带宽要接近网卡理论带宽的80%以上。如果延迟明显偏高先排查SPOF交换机端口协商模式和MTU设置再检查网卡固件是否需要升级。6.2 存储压测用fio做单节点基准测试只是第一步集群级的存储压测必须让所有计算节点同时打存储。我这里的标准动作是# 在多个节点上同时启动 fio模拟并发写 # 每个节点执行 fio --namewrite_test --directory/mnt/bee/fs --rwwrite --bs1M --numjobs16 \ --size10G --time_based --runtime600 --group_reporting然后汇总所有节点的写入吞吐看总和能否接近存储节点的网络聚合带宽上限。如果读写性能波动剧烈通常不是存储本身的问题而是客户端的并发调优参数没设好——比如BeeGFS客户端要把tuningFileCacheType和tuningFileCacheMaxSize调大。6.3 作业压测用slurm提交你业务里典型的作业队列模拟峰值并发。很多时候问题在这里才暴露脚本里用了某个绝对路径但是计算节点上不存在某个动态库只在编译节点上有运行节点上没同步某个环境变量没写进sbatch脚本导致作业初始失败。所以我在验收的时候会专门安排一分钟的跑批测试用用户实际的作业脚本、实际的数据样本、实际的环境依赖去跑一遍完整流程。这一步能暴露80%以上的上线后翻车问题。6.4 监控系统集群自主运行的前提最后压轴的是监控系统。一个高性能计算集群如果没有一套看得见、查得到的监控体系运维就是盲人摸象。我的监控栈是Prometheus Grafana Node Exporter Slurm Exporter 存储Exporter统一采集所有节点的CPU、内存、磁盘、网络、GPU利用率、作业队列长度。告警规则一般配这几条CPU温度超过85度通知运维节点load average持续15分钟超过核心数通知管理员存储池使用率超过85%通知扩容任何节点down机超过5分钟立刻告警这套监控布好以后我基本可以放心把集群交给业务团队去跑自己只需要每周看一眼容量趋势做个预判。7. 最后分享几条实战心得走到这里一套高性能计算集群从需求分析到硬件选型、软件栈部署、存储规划、压测验收完整链路已经拉通了。最后我想掏心窝子讲几条用真金白银换来的体会第一集群部署最大的成本不是硬件是运维和人才。再好的集群如果没有一个懂调度器、懂存储、懂网络的人去维护三个月后必然变成一堆高性能废物。所以预算里一定要留出运维人力和监控体系建设的部分。第二用户培训和规范制定永远不嫌早。集群部署完成后把作业提交模板、存储目录规范、数据备份要求全部写成文档并培训用户能挡住至少一半的看起来是集群问题其实是用户操作问题的工单。我甚至见过有人在节点上跑rm -rf /把整个系统盘清空的事故规范说明真的很重要。第三不要盲目追新版本。调度器、MPI库、存储文件系统这些核心组件稳定版本比新功能重要得多。我一般会等一个发布版本出来两三个月以后再升级就是不想当小白鼠。第四日志和监控一定要一上来就配好。我接手过的第二次救火项目基本上都是前期没配监控、日志不全、出了问题只能靠猜。有了日志和监控排查问题的效率能提升三倍以上。回想起来我自己第一次部署集群时也踩了不少坑走了不少弯路。这篇博文里写的每一个细节都是真金白银堆出来的经验。高性能计算集群的部署不是一个一次性项目它更像一个生态工程——硬件、软件、存储、网络、调度、监控、人员几条线齐头并进才能让这台计算战车真正跑出应有的速度。希望这篇经验分享能帮你少走一些我走过的弯路把精力花在真正重要的事情上。