简介这份PDF围绕OpenHPC开源高性能计算方案展开面向HPC与AI方向的运维工程师、集群管理员及科研计算人员帮助理解如何借助开源软件栈降低部署与管理门槛。内容涵盖OpenHPC在Linux基金会下的社区协作模式、79个开源项目目录的组织方式以及基于CentOS与PostgreSQL设计的OpenManage Enterprise集中管理方案涉及基于角色的统一身份验证、机架与模块化统一管理、北界API与策略驱动管理同时介绍Omnia对YUM、Helm、源码编译的支持以及Pravega在流数据处理与存储上的能力并延伸到PowerEdge计算节点的选型参考。资源包内含1个PDF文件约1.86MB已有347人学习适合作为了解HPC开源软件栈的入门参考。1. 从一台裸机到八节点集群OpenHPC 省掉的到底是哪几步场地里凑了八台退役服务器没有装机服务带外管理口也没全配齐。真正卡住进度的从来不是某个算法跑不通而是从系统安装、网卡固件、时钟同步、共享家目录、MPI 编译到作业排队这一整条链路——每一步业内都有三四套做法每一套都有人踩过坑文档还散落在十几个开源项目的仓库里。OpenHPC 的定位就在这里。它不发明新技术而是把已经在生产环境里验证过的组件、版本组合和配置文件收敛成一组可以用 dnf 直接安装的元包再把配置模板落到 /opt/ohpc 目录下。你可以把它看成一份带安装脚本的参考架构一份关于“哪些组件搭配在一起不出事”的共识。它适合两类人手上只有几台到几十台机器、没有专职 HPC 运维的团队希望用最短路径把 Slurm 和 MPI 跑起来以及已经有集群、但想用一套可复现的开源基线替掉手工维护脚本的团队。下面从仓库结构讲起把装机、节点供给、调度和并行运行环境这条链走完。2. OpenHPC 仓库拆解与最小可控安装2.1 仓库里装的到底是哪些东西OpenHPC 仓库不是单一软件它是若干上游开源项目按功能重新打包后的集合。理解分层才能判断哪些包该装在管理节点、哪些该进计算节点镜像否则很容易在一台机器上把服务端和客户端装重最后 Slurm 起两个守护进程互相抢端口。分层解决的问题典型包名装在哪个角色基础环境目录规范、lmod 模块工具、环境变量ohpc-base所有节点计算节点侧计算节点必备运行时与依赖ohpc-base-compute计算节点调度层作业提交、资源分配、节点管理ohpc-slurm-server / ohpc-slurm-client按角色二选一并行运行库MPI、OpenMP、数学库、编译器ohpc- - -parallel-libs按程序需要在开源 HPC 生态里这类元包的价值主要体现在“版本组合”上。自己从源码编译 MPICH、OpenMPI、hwloc、PMIx、UCX最容易翻车的不是编译报错而是运行期接口不匹配——比如 MPI 用了一套 PMIxSlurm 编译时链的是另一套作业能提交但一步都跑不起来。元包把这种耦合关系固定下来代价是版本选择权变小。注意不要在已经装了发行版自带 mpich/openmpi 的机器上直接叠加 OpenHPC 的 parallel-libs 元包。两套 MPI 会在 PATH 里打架症状是mpirun能用但srun --mpi报MPI_Init失败。装之前先rpm -qa | grep -E mpich|openmpi清点一遍。2.2 装 ohpc-release 与按角色选元包ohpc-release这个包本身不做任何运行时安装它唯一的职责是往/etc/yum.repos.d/放入仓库定义文件。先装它、再装别的顺序不能反。# 1. 引入 OpenHPC 仓库定义会写入 /etc/yum.repos.d/ohpc.repo dnf install -y ohpc-release # 2. 管理节点侧基础环境 Slurm 控制端 dnf install -y ohpc-base ohpc-slurm-server # 3. 计算节点侧基础环境 Slurm 计算端 dnf install -y ohpc-base-compute ohpc-slurm-client # 4. 并行运行库按需装这里以某一套工具链 MPI 为例 dnf group list --hidden | grep -i ohpc dnf install -y ohpc-*-openmpi-parallel-libs # 5. 核对仓库与已安装的元包 dnf repolist enabled | grep -i ohpc rpm -qa | grep ^ohpc- | sort逻辑说明与参数说明第 1 步的-y是安全的仓库包没有交互项。后面几步建议先去掉-y跑一次dnf install看依赖树确认没有把发行版内核或 glibc 拉去降级。ohpc-base负责创建/opt/ohpc目录树并把 lmod 的初始化脚本落到/etc/profile.d/。这一步失败通常不是网络问题而是$releasever变量在你的发行版上取不到对应仓库目录。第 4 步用通配符是为了避开具体工具链版本号。生产环境我一般会先用dnf group list看有哪些 group再按 group 名装比通配符可控。rpm -qa | grep ^ohpc-是最快的自检方式。如果输出里出现两个不同 toolchain 前缀的 parallel-libs说明装重了。2.3 装完先看目录结构与 module 环境安装完成不等于环境可用。OpenHPC 把运行时放在/opt/ohpc/pub通过 lmod 的 modulefile 暴露给用户这一层是后面所有 MPI 作业的前置条件。# 目录概览确认安装确实落盘 find /opt/ohpc -maxdepth 2 -type d | head -20 # 检查 lmod 是否注入成功 echo $MODULEPATH type module # 列出可用模块确认 MPI 与工具链已注册 module avail 21 | head -40 module load gnu openmpi which mpicc mpirun目录内容由谁写入/opt/ohpc/pub/modulefileslmod 模块定义各 parallel-libs 元包/opt/ohpc/pub/libsMPI、数学库的 so 与头文件parallel-libs 元包/opt/ohpc/pub/compiler工具链与运行时toolchain 元包/opt/ohpc/admin管理节点脚本与模板ohpc-base提示module avail输出为空绝大多数情况不是安装失败而是MODULEPATH没被注入。非登录 shell比如ssh node command这种一次性执行不会读/etc/profile.d/作业脚本里必须显式source /etc/profile.d/lmod.sh或者在 SLURM 的TaskPrologue里统一加载。如果集群里同时有 Intel oneAPI HPC Toolkit 这类商用工具链做法是在 modulefile 层做二选一而不是把两套 MPI 都塞进默认MODULEPATH。用户module load哪一套就用哪一套编译和启动混用是并行作业最隐蔽的一类错误来源。3. 用 Warewulf 把计算节点拉起来3.1 先把 warewulf.conf 与 DHCP 参数对齐OpenHPC 的节点供给层在近几个大版本里从 Warewulf 3 换到了 Warewulf 4命令前缀从wwsh变成wwctl配置也从数据库驱动变成一份 YAML。写脚本前先确认你手上是哪一代两代的排错思路完全不同。# /etc/warewulf/warewulf.conf节选 ipaddr: 10.0.0.1 netmask: 255.255.255.0 network: 10.0.0.0 warewulf: port: 9873 autobuild: false # 关掉自动重建镜像避免每次改配置都触发全量构建 dhcp: enabled: true range start: 10.0.0.100 range end: 10.0.0.200 template: default tftp: enabled: true tftpdir: /var/lib/tftpboot参数含义改错的直接后果ipaddr供给网段上管理节点的地址节点 PXE 拿到地址却找不到 TFTP 服务器network / netmask供给网段定义DHCP 分配的地址和实际网卡不同段dhcp range动态分配区间区间与静态节点地址重叠节点互相抢 IPautobuild配置变更后是否自动重建镜像开着会让一次配置改动牵动整批节点重启autobuild: false是部署期值得坚持的一个选择。它把“改配置”和“重建镜像”两件事解耦出问题时你能清楚知道是哪一步引入的。3.2 构建可引导的 VNFS 镜像VNFSVirtual Node File System就是计算节点内存里的根文件系统。OpenHPC 把主机名、Slurm 配置、NFS 挂载点这些每台机器不同的内容放进 overlay镜像本身保持通用。# 首次构建基础容器镜像会拉取底层 chroot wwctl container build --force rocky-9 # 查看镜像与它的构建时间 wwctl container list # 把 Slurm 客户端配置与主机名交给 overlay 处理 wwctl overlay list wwctl overlay edit hostfile # 所有 overlay 变更后必须重新构建 wwctl overlay build这段里三个命令的作用边界要分清container build产出的是所有节点共享的主体overlay edit改的是按节点差异化的那一小部分overlay build是把两者拼在一起并推送到 TFTP 目录。只做前两步不做第三步节点引导起来后看到的是旧配置且不会有任何报错提示。注意容器构建过程会占用管理节点的磁盘和带宽镜像体积通常在几百 MB 到 1 GB 量级。放在业务时段执行可能把供给网段的 NFS 带宽吃满进而影响正在跑的作业。3.3 导入节点并触发一次 PXE 启动按型号批量导入比一台台手填可靠得多。# 批量建立节点对象IP 从 10.0.0.11 起顺序分配 for i in $(seq 1 8); do n$(printf n%02d $i) ip10.0.0.$((10 i)) wwctl node add $n --ipaddr $ip done # 指定镜像、网卡名与硬件地址硬件地址从 BMC 或交换机 MAC 表里取 wwctl node set n01 --container rocky-9 --netdev eth0 --hwaddr 52:54:00:00:00:01 # 触发一次重启让节点走 PXE 流程 wwctl power cycle n01这里最常被跳过的一步是--hwaddr。不填硬件地址Warewulf 只能靠 IP 反查来识别节点一旦 DHCP 分配顺序变化节点身份就会错位表现为两台机器互换主机名、Slurm 认为节点状态在IDLE和DOWN之间反复跳。批量导入后逐台核对 MAC是值得花的那十分钟。4. Slurm 与 MPI 运行环境联通验证4.1 slurm.conf 里必须先确认的参数Slurm 默认配置在单机演示时看不出问题一上多节点就会暴露。下面几项是必须按实际硬件改写的。# /etc/slurm/slurm.conf节选 ClusterNamelinux SlurmctldHostmgmt NodeNamen[01-08] CPUs32 RealMemory64000 StateUNKNOWN PartitionNamebatch NodesALL DefaultYES MaxTimeINFINITE StateUP SelectTypeselect/cons_tres ProctrackTypeproctrack/cgroup TaskPlugintask/cgroup参数作用配错的典型症状CPUs / RealMemory声明单节点资源提交超量作业不报错节点被压到卡死SelectType资源分配粒度设成 select/linear 后核数分配不精确ProctrackType进程跟踪方式作业结束进程残留节点状态卡在 completingTaskPlugin任务级资源限制单用户跑满内存别人 OOMStateUNKNOWN不是错误是让 Slurm 启动后通过slurmd上报来确认节点真实状态。改完配置后必须systemctl restart slurmctld并且在每个计算节点上重启slurmd只重启管理端不会生效。4.2 srun 与 mpirun 两条路径都要跑一遍这两条路径分别验证不同的东西缺一不可。# 路径一Slurm 原生启动器。验证调度、节点通信、PMIx 集成是否正常 srun -N 4 -n 32 --mpipmix hostname | sort | uniq -c # 路径二MPI 自带启动器在 Slurm 分配的资源内运行验证 MPI 运行时本身 salloc -N 4 -n 32 mpirun hostname | sort | uniq -c exit第一条命令的输出应该正好是 32 行分属 4 台主机。如果只看到 1 台主机的名字重复 32 次说明--mpipmix没生效Slurm 退化成在本地 fork 了 32 个进程。第二条命令验证的是 MPI 库层的进程发放能力它绕过 Slurm 的进程管理失败通常是 MPI 编译参数或LD_LIBRARY_PATH的问题而不是调度问题。再补一个能同时验证编译器与运行时的最小程序# 用 OpenHPC 提供的封装编译器它会自动带上正确的 MPI 头文件和链接参数 module load gnu openmpi mpicc -O2 -o /tmp/hello_mpi hello_mpi.c srun -N 2 -n 8 /tmp/hello_mpi用mpicc封装而不是直接gcc -I... -L...是避免链接到错误 MPI 的最省事做法。手动写链接参数在单机上能过换到多节点就会因为节点上库路径不一致而失败。4.3 报错先看这几个地方排错顺序比排错技巧更重要。下面的顺序按“信息量从高到低”排列。现象第一个该看的地方大概率原因作业一直 PDscontrol show job id的 Reason 字段资源声明与实际不符、QOS 限制节点状态 DRAINscontrol show nodeslurmd -C配置里的 CPUs/内存小于实际值srun 卡住不返回journalctl -u slurmd -n 50节点间端口被防火墙拦截MPI 初始化失败ldd /tmp/hello_mpi与echo $LD_LIBRARY_PATH链接到发行版自带 MPI节点之间通信除 Slurm 自身端口外MPI 还需要一批动态端口。开防火墙的情况下先用srun -N 4 -n 32 --mpipmix hostname这类不涉及 MPI 库的命令把调度链路和 MPI 链路分开能省下大量猜测时间。5. 进阶把自研软件包接入 module 体系并做回归验证把自研求解器塞进集群很多人第一反应是往/usr/local/bin一放了事结果版本一升级所有用户的作业结果都变了还查不出是哪天变的。正确做法是让它走 OpenHPC 的 module 体系每个版本独立目录、独立 modulefile。-- /opt/ohpc/pub/modulefiles/mytool/1.0.lua local root /opt/ohpc/pub/apps/mytool/1.0 prepend_path(PATH, pathJoin(root, bin)) prepend_path(LD_LIBRARY_PATH, pathJoin(root, lib)) setenv(MYTOOL_HOME, root) family(mytool) -- 同族模块互斥避免两版本同时加载 whatis(Name: mytool) whatis(Version: 1.0)family(mytool)这一行是关键用户先module load mytool/1.0再module load mytool/1.1lmod 会自动卸掉前一个不会出现两个版本同时进LD_LIBRARY_PATH的经典事故。构建侧建议用 EasyBuild 或 Spack 生成目录结构再让它们自动产出 modulefile手写只保留给内部自研代码。接入之后必须有回归验证否则版本切换的副作用会一路漂到用户那里。我一般会放一个能区分单核与多核结果的校验作业固定输入、固定核数、比对输出哈希#!/bin/bash #SBATCH -J regress #SBATCH -N 2 #SBATCH -n 16 #SBATCH -p batch module load gnu openmpi mytool/1.0 srun /opt/ohpc/pub/apps/mytool/1.0/bin/solver -i /data/ref/in.dat -o /tmp/out.dat # 输出哈希与基线比对不一致就让作业以非零状态退出 sha256sum /tmp/out.dat | awk {print $1} /tmp/got.txt diff -q /tmp/got.txt /data/ref/expected.sha256 || exit 1这个脚本的价值在于它的失败是可归因的哈希不一致只有三种可能——工具链换了、MPI 换了、代码变了。每换一次 OpenHPC 的工具链大版本跑一遍它比读十页 release note 都快。基线哈希文件本身也要进版本控制跟 modulefile 放在同一个仓库里谁改了什么在提交记录里一目了然。开源社区里那些维护得好的 HPC 软件仓库基本都靠这套“模块 基线哈希”的组合把版本漂移挡在集群外面。本文还有配套的精品资源点击获取