企业官网建设流程全解析

简介：OpenHPC是Linux基金会合作的开源高性能计算项目，多家厂商与计算中心均是其成员；这份PDF以配套幻灯片形式，面向HPC开发者、集群运维者及方案选型人员，系统梳理其简化部署、集中管理与高性能扩展的整体思路。资料从中提炼了关键组件：包含79个开源项目目录，重点讲解基于PostgreSQL的OpenManage Enterprise统一管理，免去额外OS/DB许可证；覆盖基于角色的集中访问控制、北向API与策略驱动管理；延伸到Pravega流数据平台和Omnia集群编排工具，说明如何通过YUM、Helm、源码编译等方式创建配置并让节点加入Slurm/Kubernetes资源管理器；同时展示Dell EMC PowerEdge节点对HPC/AI工作负载的支撑能力，并涉及开源社区共建及中国服务实施标准等延伸话题，覆盖从资源管理、开发工具到系统诊断的完整开源软件栈。资源为单个PDF文档，压缩包仅1.86MB，便于快速翻阅。目前已有348人学习，适合需要快速理解OpenHPC架构边界与开源生态的读者。通读后可建立HPC开源方案全局视图，掌握各组件协同完成集群部署与运维的要点，为后续选型、部署或二次开发提供简洁的入门参考。

1. OpenHPC开源HPC解决方案：为什么我把集群交付从两周压到加班一晚上

先开门见山。这里想聊的 OpenHPC 开源 HPC 解决方案，是当前 HPC 集群部署里绕不开的一个选项：它把裸机变成可提交作业的高性能计算集群的流程，做成了一套可重复的工程流水线。解决的问题很直观——以前搭 HPC 集群，从选驱动、配 MPI、装调度器到每台节点手动改配置，一个周末搭不完，还容易版本错位；用 OpenHPC 这套开源 HPC 解决方案，把仓库、镜像、调度器这些组件组合成标准模板，按顺序来，一天内交付一个最小集群是常事。

这套方案适合三类人：一是跑并行仿真和 MPI 计算的课题组，不想把精力耗在链路环境上；二是给客户交付 HPC 集群的集成商，需要更快复制环境；三是运维新人，需要一个能回溯的配置层，而不是在机房里一台台点鼠标。下面我会从组件选型、最小安装、参数调校、高频故障排查和二次封装五个层面展开。新手可以先照做，熟手可以重点看第 4 章和第 5 章的边界条件。

2. 看懂 OpenHPC 组件拼图：仓库、镜像、调度三件事缺哪件都容易睡不好

2.1 OpenHPC 仓库分层：为什么它不止是一个安装包

OpenHPC 最主要的形态是多个软件仓库，可以理解成一组经过组合测试的 RPM 集合：编译器、MPI 实现、调度器、数学库和工具链都从同一个仓库源发布。这样做最大的好处是版本之间打过包验证。我自己在接触 OpenHPC 之前，经常遇到 GCC 编译的 MPI 程序跑在另一个 MPI 库版本上报一堆符号错的事，那时候只能靠倒环境变量碰运气，属于玄学问题；用了统一仓库后，这类问题少很多。

仓库内部组件可以按角色分成四层：基础系统仓库、节点部署工具（Warewulf/xCAT）、集群管理组件（clustershell、chrony、SLURM）以及用户应用层（OpenMPI、厂商编译器、数值库）。安装时不要一股脑全装，按角色拆分。控制节点需要服务端组件，计算节点只需要基础镜像和客户端。

另一个常见误区是把 OpenHPC 当成操作系统镜像。它实际依赖一套底层 Linux 发行版，OpenHPC 负责的是在这套系统之上提供 HPC 软件栈和部署编排，而不是从零做一个 OS。这样偏好系统底座的团队可以沿用内网安装源，离线部署时少踩很多坑。

选型时建议优先看 OpenHPC 支持列表里与发行版版本和内核匹配的组合。仓库按发行版分目录，装错仓库源是新手最常见的翻车点，后面会有专门章节讲。

2.2 选 SLURM 还是 OpenPBS：调度器选型背后的成本账

OpenHPC 默认带多套调度器，实际项目里九成会卡在 SLURM 和 OpenPBS 之间。我的倾向是 SLURM。原因不复杂：SLURM 配置清晰、查看队列方便、和 OpenMPI 集成度高；很多团队管理员已经习惯 SLURM，出了问题找参考容易。

很多人以为选调度器只是定一个命令行风格，其实关联后续操作习惯、脚本资产、监控集成。SLURM 用 salloc、sbatch、srun 管理资源，OpenPBS 用 qsub、qstat、qdel；SLURM 分区可以按 CPU/GPU 规格切分，作业结算和抢占更灵活。这些差异在 OpenHPC 里不会被抹平，所以选型要按团队已有脚本和技能树来。

OpenHPC 还带一些辅助调度组件，比如 MUNGE 做节点间认证，slurm-exporter 给监控打指标。组件间有预设的配置骨架，我们只需要把节点名和分区填进去。这里经验是：如果团队全是 SLURM 习惯，就不要为“PBS 资源预留更宽松”去换；如果项目有 PBS 历史脚本，也别只看 SLURM 新，迁移成本要算进去。

2.3 Warewulf 无盘部署：把计算节点当成一次性系统

OpenHPC 默认节点部署大多用 Warewulf。计算节点不需要本机系统盘，启动时通过 DHCP/TFTP 获取引导镜像，然后挂载根文件系统。好处是一份镜像管所有节点，坏处是要理解容器、节点定义、引导镜像三层抽象。

日常工作流是：在控制节点的 chroot 根文件系统里安装软件、清理缓存，做成一个“容器”；Warewulf 的 wwctl 把容器导出成 PXE 可引导卷。一个节点定义包含网卡 MAC/IP 映射、对应容器名、内核参数。修改软件只需要更新容器并重新同步，重启计算节点生效。

很多运维喜欢这种一次性节点，因为不用再半夜到机房接键盘查本地盘日志。我第一次用时的感受是：把节点当成远程无盘工作站，拔掉本地盘，所有问题都回到控制端配置里去查，排查维度少了一大半。

3. 从零搭最小集群：控制节点加两台计算节点的落地流程

3.1 节点规划：双网卡控制端和两台计算节点的地址分配

实际部署中，控制端至少两张网卡：一张连接管理网，一张连接外部网络。计算节点只需要一张管理网网卡，通过 DHCP 自举。IP 要规划得和 Warewulf 的 DHCP 地址池一致，否则节点拿不到地址。下面是我常用的最小模板。

控制端建议内存不少于 8G、磁盘 200G 以上，因为 Warewulf 容器、NFS 共享、软件仓库都会占空间。计算节点内存按作业定，至少 4G 起步；如果超线程要关，提前在 BIOS 层统一，否则 SLURM 看到的逻辑核不一致，调度会出现“一半机器快一半慢”的怪现象。

3.2 控制节点安装：配置仓库和基础组件的最小命令

先安装操作系统，选最小化镜像。安装时最好把系统自带防火墙关掉，不然 DHCP/TFTP/NFS 端口足够排半天。控制端装好后，配置好外网/内网网卡和静态路由，继续。

# 安装 OpenHPC release 包，路径按实际下载目录替换 dnf install -y ./ohpc-release-*.rpm dnf makecache # 查看可用的组件组 dnf group list | grep -i ohpc # 安装 base 和 slurm-server 两组，量大，耐心等 dnf groupinstall -y "OpenHPC Base" "OpenHPC SLURM Server"

这里的ohpc-release是仓库入口包，它做的事很简单：把 OpenHPC 的 GPG key 和每个子仓库的 baseurl 写到系统里。dnf group list能看到多个组，分别对应控制端、开发端和计算端。注意不要在计算节点上装 server 组，那是控制端才需要的。OpenHPC Base里面包含 Warewulf、chrony、clustershell 等基础运维组件，无论什么角色都要装。

装完之后，启用对应服务：

# 控制端启用 chrony、DHCP、TFTP 和 Warewulf 的 provision 服务 systemctl enable --now chronyd systemctl enable --now dhcpd systemctl enable --now tftp.socket systemctl enable --now ww4-rpc

ww4-rpc是 Warewulf v4 的服务名。如果装的 OpenHPC 版本比较旧，服务名可能叫wwserver；用systemctl list-units | grep ww确认最稳。DHCP、TFTP 任何一个没起来，计算节点就会卡在 PXE 阶段，所以这一步建议配置完顺手systemctl status看一遍。

3.3 生成镜像并注册：Warewulf 命令清单

接下来创建计算节点容器和节点定义。Warewulf v4 的交互命令是wwctl，下面给的是一个最小可用流程。

# 创建计算节点容器，名字叫 rocky9 wwctl container create rocky9 # 从控制端当前文件系统同步文件到容器 wwctl container sync rocky9 # 注册一台计算节点，指定管理网地址 wwctl node add compute001 --netdev default --ipaddr 192.168.100.11 --netmask 255.255.255.0 # 把该节点关联到容器 wwctl node set compute001 --container=rocky9 # 生成该节点的引导镜像和 DHCP 配置 wwctl provision --update wwctl dhcp

这三段命令各有一个容易踩的坑。wwctl container create只是建立一个容器目录，不是从零创建一个系统，所以很多模板要求先有一个基础镜像；有经验的流程通常先wwctl container import从 ISO 导入，我这里为了演示就省略。wwctl node add的--netdev参数名在不同版本可能叫eth0或default，最好先用wwctl node list -v看模板。最后wwctl provision --update会生成镜像，如果再改网卡参数、容器名、内核参数，必须重新跑这个子命令，只改配置不重新生成是起不来的。

3.4 验证最小集群：第一次提交作业要看三行输出

全部节点起来后，在控制节点上看 SLURM 节点状态：

sinfo # 正常输出类似： # PARTITION AVAIL TIMELIMIT NODES STATE NODELIST # normal* up infinite 2 idle compute00[1-2] srun -N 2 hostname

如果sinfo能看到节点且状态是 idle，说明集群基本通了。srun -N 2 hostname会并行到两台节点上执行，输出两个不同主机名就说明计算节点已从 Warewulf 网段引导成功，并能响应调度。若这里停留在 PD（pending），优先看分区和对列有没有默认限制，其次查 MUNGE 认证。

这个阶段不需要急着跑浮点优化，先验证“能上去作业”最重要。很多团队在这个环节就直接拿 MPI 跑矩阵乘法，结果报错一堆，实际是基础没通。

4. 调顺 OpenHPC 运行参数：NFS、SLURM 和存储 IO 的必改配置

4.1 NFS 共享目录：别让用户数据落在计算节点临时盘

无盘节点的最大特点，是计算节点重启后目录不保留。用户数据和软件栈必须通过 NFS 从控制端共享出来，而不是靠镜像里的只读层硬塞。OpenHPC 的典型做法是控制端导出/home和/opt/ohpc，计算节点挂载同一路径。

# 控制端导出 /home 和 /opt/ohpc echo "/home 192.168.100.0/24(rw,sync,no_root_squash)" >> /etc/exports echo "/opt/ohpc 192.168.100.0/24(rw,sync,no_root_squash)" >> /etc/exports exportfs -ra showmount -e localhost

参数说明：sync保证写盘完成后才返回，避免掉电丢数据和 NFS 缓存不一致；no_root_squash是让计算节点上的 root 用户能管理到共享软件目录，如果你的计算节点 root 权限被严格控制，可以去掉。rw必不可少，no_subtree_check在新版内核里常加，能减少断点挂载的告警，但不用强求。

计算节点挂载要在镜像容器里配置好/etc/fstab，否则节点启动后也挂不上。我习惯把挂载延迟到网络配置文件生效之后，用_netdev选项。不写这项的话，开机时 NFS 设备找不到，系统会反复等待直到超时，最后掉进 emergency mode。

4.2 SLURM 三个必调参数：cgroup、内存和进程跟踪

OpenHPC 装好的 SLURM 默认配置偏保守，三个参数我每次必改：SelectType、ProctrackType和DefMemPerNode。前两个直接影响作业能否正确调度和回收资源。

SLURM 通过SelectType决定资源分配粒度。要支持一个节点上不同作业分不同内存，可以用SelectType=select/cons_tres并启用CR_Core_Memory资源类型。这样作业请求--ntasks和--mem都会映射到真实物理核心和内存上，而不是只按“整节点调度”。后者容易导致一个程序吃满内存后，其它作业排队干瞪眼。

# 编辑 /etc/slurm/slurm.conf，然后重启 slurmctld SelectType=select/cons_tres SelectTypeParameters=CR_Core_Memory DefMemPerNode=0

DefMemPerNode=0是可选的，表示作业不显式申请内存时不设每节点默认上限；如果集群内存统一固定，设成24000反而更清楚。但要意识到，这个值是“每节点内存”，不是“每核”，设小了会拒绝作业，设大了可能超卖。另外修改了slurm.conf后一定要先slurmctld -t做语法检查，再重启，否则一个错误会带崩控制端。

第三个参数是ProctrackType=proctrack/cgroup。它让内核 cgroup 记录作业进程树，作业结束后不会残留孤儿进程。没有它，一个作业里的后台子进程会在作业结束时继续占用 GPU，下次调度的节点资源看着被占用，反复出现“作业没了 GPU 还在忙”的诡异状态。这个参数在 OpenHPC 默认仓库里一般已经启用，但初装时容易被覆盖掉，建议确认一次。

4.3 存储 IO：镜像刷写和作业数据别抢一张盘

最后一类调校围绕 IO。OpenHPC 的无盘节点如果频繁通过 Warewulf 重新同步容器，会反复覆盖计算节点的全部根文件系统。如果节点有本地 SSD，但你的作业数据也写在同一个盘上，两者会互相拖慢。常见做法是把镜像放在一个小分区，业务数据挂到另一个盘，或者直接走 NFS 到控制端存储。

遇到小规模集群，我一般把临时目录/tmp放到 tmpfs，并限制大小：

# 在容器镜像的 /etc/fstab 中增加一行 tmpfs /tmp tmpfs rw,nosuid,nodev,size=16G 0 0

这样做有两个好处：减少本地盘写放大；防止跑作业的人把/tmp塞爆控制端共享的 NFS 目录。size=16G按计算节点内存的一半给，避免临时文件超过内存时被内核频繁 swap。对高 IO 应用，还可以把/var/log从镜像改挂到控制端收集，集中看日志对调试帮助极大，代价是 log 量大时 NFS 成为瓶颈。这里建议用nodev,nosuid保证安全和性能，别把整个根目录都做成 tmpfs，系统会因/etc找不到而崩掉。

5. OpenHPC 避坑与排查：五条血泪记录，遇到别硬扛

5.1 现象：计算节点反复 PXE 重启，机器一直闪

这通常不是硬件问题，而是防火墙或 DHCP 配置问题。第一次搭集群时，我用最小化系统没关 firewalld，结果 DHCP 的 67/68 端口把客户端的请求丢了一部分；节点拿到一次 IP 后又拿不到，看起来像 boot 环。另一个可能是 Warewulf 的 provision 服务没有绑定到管理网 IP，默认绑到了外网口。

解决：先在控制端临时停掉 firewalld 测试，通了再按需开端口。然后看/etc/ww4/ww4.conf的bind_interface，把管理网 IP 写进去。同理/etc/dhcp/dhcpd.conf里的 subnet、mask 要和网卡 IP 对应，别拿内网和外网掩码混着填。

5.2 现象：计算节点启动卡在“Mounting NFS Server”

现象是日志停在这一行，过几分钟进 emergency shell，输入journalctl -xe能看到 NFS mount 失败。原因基本是控制端 NFS 导出和计算节点挂载参数不匹配。我见过最离谱的是/etc/exports里网段写成了192.168.100.0/32，当然挂不上。

解决：exportfs -v看实际导出的网络段；再检查计算节点/etc/fstab中的控制端 IP 是否与控制端管理网 IP 一致。如果控制端有两张网卡，计算节点必须能路由到管理网 IP，不能依赖默认路由。临时验证用mount -t nfs 192.168.100.2:/home /mnt，能挂上再看镜像里的配置。

5.3 现象：MPI 作业一启动就报“undefined symbol: mpi_comm_rank”

这是典型的编译环境和运行环境不一致。很多人用mpicc编译完，提交作业时却用了系统自带 PATH 里的另一个mpirun，两个 OpenMPI 版本不同，或者编译时没有加载 OpenHPC 的 module。

解决：统一用 module 环境，编译和作业脚本里都先加载同一个 module 栈：

source /etc/profile.d/ohpc.sh module load gnu12 openmpi4

再用ldd查编译产物依赖的 libmpi 路径，确认指向/opt/ohpc/pub/compiler/...，而不是/usr/lib64/。这类问题和 OpenHPC 本身无关，但没有统一仓库管理时更容易踩。

5.4 现象：节点一直 drain，squeue 排起长队

先看原因：scontrol show node compute001 | grep -i drain，常见是 “Memory config does not match” 或者 “Not responding”。前者是 SLURM 的 RealMemory 比节点实际内存大，后者是节点时钟漂移或 MUNGE 密钥坏了。

解决：编辑slurm.conf把 RealMemory 改成free -g看到的物理内存，然后重启 slurmctld；时钟同步检查 chrony 是不是控制端和计算端没统一到同一时钟源。MUNGE 服务异常时看/var/log/munge/munged.log，重新同步密钥文件最直接。遇到这种排查，别急着state=idle把节点强制拉起来，后面的作业还会继续踩。

5.5 现象：仓库更新后，镜像和软件栈版本分叉

这是 OpenHPC 特有坑。控制端重新升级了依赖，但 Warewulf 容器没重新同步，计算节点加载的还是老内核和旧库，表现为作业本地编译正常，一跑就 crash。常见更新操作：明明只dnf install xxx，却因为依赖变化，连 kernel 也悄悄升级了。

解决：给 OpenHPC 仓库配置锁定关键包，更稳妥的做法是所有软件变更后，在控制端重新wwctl container sync并wwctl provision --update。生产环境里我一般会在/etc/yum.conf里加exclude=kernel*之类，防止版本漂移。升级前先清点 container 内软件清单，再动手。

这五条都是遇到频率最高的。排错的核心方法论是：先把“网络通不通、服务有没有起来、版本统不统一”这三层查完，再碰 MPI 业务，顺序不要反。

6. 进阶玩法：把 OpenHPC 封装成站点 Profile，一键复刻整套集群

到这里，基础集群已经能跑。要更进一步，是把“搭集群”升级成“造模板”，用 Profile 方式把版本、分区、软件包固定下来。项目重复交付时，你会发现这是最大的隐性收益。

6.1 定制容器：把业务软件写进镜像

常见做法是在容器里预装业务软件。与其每次部署后到节点上装，不如把它们写进 Warewulf 容器。把软件的二进制放在共享目录下，然后在容器/etc/profile.d里写环境变量文件。更新容器后，所有新开机节点天然带这套软件。

我习惯维护一份站点 profile 脚本：

# 生成一个定制容器 wwctl container create site-profile # 用 chroot 进入容器装软件 wwctl container exec site-profile bash -c "dnf install -y python3-pip vim" # 再导出自定义 fstab wwctl container set site-profile --fstab /etc/ww4/site-fstab

--fstab可以让你复用时不用每次改挂载点。之后注册节点时把--container=site-profile指过去，整个集群就等于套用了同一份模板。跑顺之后，我习惯在白天重新构建容器，晚上再批量重启计算节点，避免影响白天作业。

6.2 验证模板：多轮重启和日志留痕

验证模板是否可靠的技巧也简单：拿零点测试节点，wwctl node add后用scontrol suspend/resume反复调度几轮，看有没有漂移。不要只看第一次启动正常，就以为模板没问题。时钟、NFS、模块环境这些隐性问题往往在第三次重启后才露头。

最后分享一个习惯：我每次改集群配置前，都会用 tar 把/etc/ww4、/etc/slurm、/etc/exports这些关键目录打包备份，然后写一份 changelog 文档放在/root/openhpc-cluster.log里，方便回滚。这个习惯救过我两次，一次是误改了 slurm.conf，一次是 Warewulf 容器被误清。虽然看着笨，但 HPC 集群最怕“没留下记录”。希望帮到你。

本文还有配套的精品资源，点击获取