简介这是一份面向HPC初学者、架构设计人员及运维工程师的解决方案类文档围绕高性能计算架构设计展开帮助读者系统理解HPC系统的组成、分类与技术选型。内容涵盖HPC基础概念、高吞吐计算与分布计算的分类差异、计算存储网络与集群软件四大部分并深入讲解X86处理器、Linux系统、刀片构建、IB与10GE互联等主流技术特点同时涉及MPI节点、胖节点、GPU加速节点的划分以及CPU性能计算公式、Linpack测试工具、DIMM内存类型等关键知识点。资源包内含1个docx文档压缩包约979KB结构紧凑便于按章节查阅与整理笔记。目前已有225人学习下载适合需要快速建立HPC架构认知、梳理技术脉络或作为方案参考的读者可从中获取从性能指标衡量到应用领域落地的完整知识框架。1. 从一台刀片机箱说起这份 HPC 架构设计文档到底能解决什么问题很多人第一次接触 HPC是从机房巡检开始的。一台刀片机箱里插着十几块计算刀片后面拖着 IB 线缆和万兆网线前面板一堆绿灯但真要问“这套系统能跑多少 TFlops、为什么这么配、瓶颈在哪”能说清楚的人不多。这份《HPC高性能计算架构设计》文档的价值就在这——它不讲空泛概念而是把 HPC 系统的四大部分计算、存储、网络、集群软件拆开从处理器选型、节点分类、互联协议到并行文件系统一条线串下来。适合两类人一是刚接手 HPC 集群运维、需要快速建立架构认知的工程师二是做方案设计、需要给科研或工业场景配资源的售前与架构人员。它不教你写 MPI 程序但能让你在选型会上把“为什么用 IB 不用 10GE”“胖节点该配几台”这类问题讲明白。2. HPC 系统四件套计算、存储、网络、集群软件怎么配2.1 计算节点分三类别把胖节点当瘦节点用文档里把计算节点分成三种MPI 节点瘦节点、胖节点、GPU 加速节点。这个分类不是拍脑袋来的背后是内存带宽和并行粒度的差异。瘦节点一般是双路 X86每节点 64~128GB 内存适合跑 MPI 并行任务——每个进程只处理一小块网格进程间通信靠 IB 网络。胖节点是双路以上内存能到 1TB 甚至更多适合那些“单进程吃大内存”的应用比如某些 CFD 隐式求解器一个进程就要几百 GB根本没法拆。GPU 加速节点则是把浮点吞吐拉上去文档里提到 GPU 在浮点运算上能提供数十倍于 CPU 的性能但前提是你的算法能映射到几千个线程上。常见做法是先按应用峰值浮点需求算节点数量公式文档里给了——单节点性能 处理器主频 × 核数 × 单节点 CPU 数量 × 单周期指令数。单周期指令数取 8 或 16取决于 CPU 代际。比如你要 100 TFlops 峰值用双路 16 核 2.6GHz 的节点单节点性能 2.6 × 16 × 2 × 16 1331 GFlops约 1.33 TFlops那大概需要 75 个节点。但这是峰值实际 Linpack 效率通常只有 70%~85%所以节点数要往上浮。提示胖节点数量不是越多越好。文档明确说“胖节点的数量要根据实际应用需求而定”配多了就是浪费——胖节点单节点成本高而且并行效率未必比瘦节点集群好。2.2 存储选型Lustre 和 GPFS 为什么是 HPC 主流文档里列了一堆分布式文件系统Lustre、Hadoop、MogileFS、FreeNAS、FastDFS、NFS、OpenAFS、MooseFS、pNFS、GoogleFS。但真正在 TOP500 里常见的就两个Lustre 和 GPFS。原因不复杂——HPC 的 I/O 模式是“大文件、高并发、顺序读写为主”Lustre 的架构就是为这个设计的MDS 管元数据OSS 管对象存储客户端直接和 OSS 做数据交换元数据路径和数据路径分离。GPFS 类似但更偏向企业级支持 DMAPI 和 HSM。如果你要自己搭一套小规模 HPC 存储常见做法是至少 2 台 MDSHA多台 OSS每台 OSS 后面挂 JBOD客户端通过 IB 或 10GE 接入。Lustre 的 stripe 参数很关键——stripe_count 设小了单文件带宽上不去设大了小文件元数据压力大。一般大文件场景 stripe_count 设 4~8stripe_size 设 1MB~4MB。# Lustre 客户端挂载示例 mount -t lustre 192.168.1.10o2ib:/lustre /mnt/lustre # 查看文件 stripe 信息 lfs getstripe /mnt/lustre/testfile # 设置目录默认 stripe新文件继承 lfs setstripe -c 4 -S 4M /mnt/lustre/data上面命令里-c 4表示条带分布在 4 个 OST 上-S 4M表示每个条带 4MB。逻辑是文件被切成 4MB 的块轮流写到 4 个 OST读的时候 4 个 OST 并行返回带宽叠加。如果 OST 数量少-c不要超过 OST 总数否则 Lustre 会报错。2.3 网络IB 和 10GE 的分工不是随便定的文档里说 HPC 系统互联网络使用 IB 和 10GE。这不是二选一而是分工IB 走计算网络MPI 通信、存储数据面10GE 走管理网络带外管理、监控、登录。IB 的优势文档列了协议栈简单、处理效率高、对 RDMA 支持好、功耗低、时延低。RDMA 的核心是 Zero Copy——数据从一台机器的内存直接搬到另一台机器的内存不经过内核协议栈CPU 几乎不参与。IB 目前支持 FDR、QDR、EDR对应单口速率 56Gb/s、40Gb/s、100Gb/s。HCA 是 IB 连接的设备终结点提供传输功能和 Verb 接口TCA 是 HCA 的子集主要用于存储。如果你在配集群常见做法是计算节点插双口 HCA一口连计算 IB 交换机一口连存储 IB 交换机或者用同一张 fabric靠分区隔离。管理口用板载 10GE 或 1GE 就够了。注意IB 线缆和交换机端口要匹配速率。FDR 线插 QDR 交换机要么降速跑要么直接不亮。血泪经验是采购时把 HCA 型号、交换机型号、线缆速率列一张表逐项核对。3. 架构演进SMP、NUMA、MPP 到底怎么选3.1 SMP 的扩展瓶颈为什么 4 路以上就不划算了SMP 的结构是所有 CPU 共享总线、内存、I/O操作系统只有一个副本每个 CPU 平等访问内存。文档里给了一个关键结论实验证明 SMP 服务器 CPU 利用率最好的情况是 2 至 4 个 CPU。原因在于内存总线——所有 CPU 通过同一条总线访问同一块内存CPU 数量增加内存访问冲突迅速增加最终 CPU 都在等内存利用率反而下降。所以 SMP 适合什么场景小规模数据库、轻量级应用服务器、开发测试环境。如果你要跑大规模并行计算SMP 不是选项。文档里提到 SMP 扩展方式包括增加内存、换更快 CPU、增加 CPU、扩充 I/O但这些都是“垂直扩展”天花板很低。3.2 NUMA 的远地内存延迟为什么 64 路性能只有 20NUMA 把几十个 CPU 分到多个模块每个模块有本地内存和 I/O模块间通过 Crossbar Switch 互联。CPU 访问本地内存快访问远地内存慢——这就是“非一致存储访问”的由来。文档里举了 HP Superdome 的例子64 路 NUMA 相对性能值 20而 8 路 SMP 相对性能值 6.3。8 倍 CPU 数量只换来 3 倍性能提升差距就在远地内存延迟。NUMA 适合 OLTP 事务处理因为事务处理的数据交互相对少大部分操作在本地内存完成。但用于数据仓库就不行——大量复杂数据处理必然导致大量跨模块数据交互CPU 利用率会降低。如果你在 NUMA 机器上跑 HPC 应用常见做法是绑核 绑内存用numactl把进程绑到某个 NUMA 节点内存也分配在本地。# 查看 NUMA 节点拓扑 numactl --hardware # 把进程绑到 NUMA 节点 0内存只在节点 0 分配 numactl --cpunodebind0 --membind0 ./my_hpc_app # 查看进程的 NUMA 命中情况 numastat -p $(pidof my_hpc_app)--cpunodebind0让进程只在节点 0 的 CPU 上跑--membind0让内存只在节点 0 分配。这样进程访问内存永远是本地没有远地延迟。代价是只能用节点 0 的资源所以适合“单进程吃满一个 NUMA 节点”的场景。3.3 MPP 的 Share Nothing扩展性最好但调度复杂MPP 由多个 SMP 节点通过节点互联网络连接每个节点只访问自己的本地资源完全无共享。文档里说“理论上其扩展无限制目前的技术可实现 512 个节点互联数千个 CPU”。MPP 的节点间通信通过 I/O 实现节点之间的信息交互与节点本身的处理并行进行所以增加节点时性能基本线性扩展。但 MPP 的代价是调度复杂。每个节点有自己的操作系统和数据库副本节点间数据重分配需要复杂机制。文档里举了 Teradata 的例子——基于 MPP 的关系数据库开发人员面对的是同一个数据库系统不需要考虑节点负载调度。这就是 MPP 的典型用法用系统级软件屏蔽底层复杂性。选型建议OLTP 用 NUMA数据仓库和数据挖掘用 MPP小规模用 SMP。HPC 集群本质上是 MPP 的一种变体——每个计算节点独立通过 IB 网络做 MPI 通信存储用 Lustre 做全局共享。4. 避坑与排查HPC 集群落地时最容易翻车的五个点4.1 现象Linpack 实测只有峰值 50%远低于预期原因常见有三个——CPU 降频BIOS 里电源策略没设 Performance、内存没插满通道8 通道只插了 4 根、MPI 进程绑定不对进程在核间漂移。解决先查 BIOS 电源策略再查内存插法参考主板手册的通道填充顺序最后用numactl或taskset绑核。Linpack 对内存带宽敏感内存通道没插满性能直接腰斩。4.2 现象Lustre 挂载后小文件操作极慢原因MDS 负载过高或者 stripe_count 设太大导致元数据操作分散。解决小文件场景把 stripe_count 设为 1stripe_size 设小一点比如 1MB让文件落在一个 OST 上减少元数据开销。另外检查 MDS 的 IOPS如果 MDS 磁盘是 SATA 机械盘换 SSD。4.3 现象IB 网络时延忽高忽低MPI 通信超时原因IB 交换机的拥塞控制没开或者 HCA 固件版本不一致。解决检查交换机是否开启拥塞控制Congestion Control所有 HCA 固件统一版本。另外用ibstat看链路速率是否协商到预期值用ibping测节点间时延。# 查看 IB 链路状态 ibstat # 节点间 IB 时延测试 ibping -S # 服务端 ibping -c 100 -C mlx5_0 192.168.1.20 # 客户端发 100 个包ibstat看 State 是否为 ActiveRate 是否为预期速率。ibping的-c 100发 100 个包看平均时延和丢包率。如果时延抖动大查交换机端口错误计数。4.4 现象GPU 节点跑起来比 CPU 还慢原因数据在 CPU 和 GPU 之间来回拷贝PCIe 带宽成为瓶颈。解决尽量让数据留在 GPU 显存里用 CUDA Unified Memory 或者手动管理显存。另外检查 GPU 是否降频——nvidia-smi -q -d PERFORMANCE看 clocks throttle 原因。4.5 现象集群跑了一段时间节点莫名掉线原因常见是 IB 线缆松动或光模块老化其次是电源冗余失效。解决查dmesg看有没有 IB 链路 down 的日志查 BMC 日志看电源和温度事件。定期用iblinkinfo巡检所有 IB 链路。5. 从 Linpack 到实际应用性能验证与调优的进阶手法文档里提到 Linpack 是测试高性能计算机系统浮点性能的 Benchmark用高斯消元法求解 N 元一次稠密线性代数方程组。但 Linpack 跑分高不代表实际应用快——Linpack 是计算密集型而很多 HPC 应用是内存带宽密集型或 I/O 密集型。所以验证一套 HPC 系统我一般会走三步Linpack 看峰值、STREAM 看内存带宽、IOmeter 看存储吞吐。STREAM 的用法很简单编译后直接跑# 编译 STREAM gcc -O3 -fopenmp -DSTREAM_ARRAY_SIZE100000000 -DNTIMES10 stream.c -o stream # 运行看 Copy/Scale/Add/Triad 四项带宽 ./streamSTREAM_ARRAY_SIZE设大一点比如 1 亿确保数组超过 LLC 容量测的是真实内存带宽。NTIMES10跑 10 次取最优。如果 Triad 带宽远低于理论值查内存通道和 NUMA 配置。IOmeter 测存储时重点看 4K 随机读 IOPS 和 1M 顺序读带宽。HPC 场景更关注顺序带宽但元数据操作多的时候 4K 随机也重要。我一般会跑一个混合负载70% 顺序读 30% 随机写模拟真实应用。还有一个容易被忽略的点MPI 进程绑定。OpenMPI 默认可能把进程散到所有核上导致跨 NUMA 访问。我习惯在提交脚本里显式绑核# OpenMPI 绑核提交示例 mpirun --bind-to core --map-by socket:PE4 -np 32 ./my_app--bind-to core把每个 MPI 进程绑到一个物理核--map-by socket:PE4表示按 socket 分布每个 socket 放 4 个进程。这样进程不会在核间漂移NUMA 命中率最高。具体参数要根据节点拓扑调——先用lstopo看拓扑再决定PE设多少。从那以后我每次交付 HPC 集群都强制走一遍 Linpack STREAM IOmeter 三件套不跑完不签字。这套流程帮我提前发现过内存通道没插满、IB 链路降速、Lustre stripe 设错好几个坑。希望帮到你。本文还有配套的精品资源点击获取