我和容器有个约会：浅析HPC容器的前世今生

本文作者：方春林（Qiyu8）
原文来源：
https://zhuanlan.zhihu.com/p/499544308

关于作者

方春林，Numpy/Taro Maintainer，USIMD和HPCRunner开源项目Leader，目前主要聚焦于openEuler HPC SIG运营，openEuler HPC SIG致力于建立气象、分子动力学、生物和制造等领域的生态交流圈，打造HPC多样性算力部署调优统一平台，自动容器化助力极简部署，一站式调优HPC应用，让看似阳春白雪的HPC应用走向平民化！

前言

最近看到一条消息，2022 年 3 月 31 日，数次被判“死刑”的容器化公司 Docker 宣布获得了由Bain Capital Ventures (BCV)牵头的1.05亿美元C轮融资，公司估值达21亿美元。相信对Docker熟悉的人看到这里都比较欣慰，面对谷歌、Redhat等巨头的围追堵截，Docker历经十年磨砺能走到今天实属不易，容器化技术对IT世界的影响力太大了，正如Docker的愿景：“我们共同关注开发人员的需求，帮助他们在任何地方都可以快速、安全地构建、共享和运行任何应用程序”，Docker的成功脱离不了以开发者为中心的模式，它帮助开发团队的发布频率提高了 13 倍，使用新技术提高生产力的时间减少了 65%，并将安全漏洞的平均修复时间 (MTTR) 压缩了 62%，然而现实世界存在着这样一类应用，它一般部署在最好的液冷机柜上，用着最流畅的千兆网络，十几W一张的显卡动辄几百片，然而应用的代码70%由古老的Fortran编写，和传统的应用貌似是两个世界的东西，它就是本文的主角-HPC应用，先看这张图：

▲ HPC应用和传统应用的差别

为了达到极致的性能，HPC应用这头性能猛兽对新技术的渴求日益增加，然而HPC应用本身存在的以下痛点让这个想法举步维艰：

痛点1：海量依赖带来部署的复杂性

高性能计算应用场景众多，并且变得越来越复杂，每种应用需要不同配套软件环境和大量的系统依赖，HPC开发人员花费大量时间部署软件，部署复杂度=M个编译器N个编译器版本O个依赖P个依赖版本Q个HPC应用版本

▲ HPC应用的海量依赖

痛点2：多架构体系带来迁移的复杂性

高性能计算应用普遍使用了大量硬件相关的并行技术和通信技术，导致不同架构之间迁移的复杂性陡增。

▲ 并行技术和通信技术

痛点3：性能为王，调优之道却难于登天

高性能计算应用属于交叉学科，专业性强，懂应用的不懂计算机，懂计算机的不懂应用是非常常见的现象，而且HPC算法晦涩难懂，架构设计复杂多样，导致调优难度普遍较高，2021年的图灵奖颁给了美国计算机科学家 Jack J. Dongarra，他是lapack、atlas等数学库的作者，因为他在数值算法和库方面做出了开创性的贡献，使得高性能计算软件能够跟上四十多年来的指数级硬件更新，说明业界普遍都在追求非常极致的性能、性价比与能耗比，仅是提高很少量的百分点都能为企业带来巨大的经济效益。

▲ HPC应用的专业性和算法的难度

为了解决上述痛点，HPC应用很自然的就向容器化技术伸出了橄榄枝。

拥抱Docker/Kubernetes？

容器技术对分布式系统的管理至关重要，主要解决的问题是自动部署和自动运维，并以此为核心催生了整个云原生生态，然而当它碰到异世界的HPC应用时，一些不容忽视的问题也冒了出来。

● 安全问题

HPC集群中的资源使用通常需要由调度管理器来进行分配，例如多瑙/Slurm/PBS/SGE等系统负责资源分配。调度管理器根据用户需求为每个作业分配一定的资源，实质上是利用cgroups针对每个作业进行配置实现的。而Docker镜像的启动实际上是由Docker Daemon去执行的，如此一来资源限制自然会失效。并且Docker Daemon是由 root 用户启动的，无论是为普通用户设置sudoer还是将普通用户添加到 docker 用户组中都不是一个安全的方式。

● 缺少对HPC架构的支持

Docker假设资源都在本地存储，而HPC应用使用最多的是共享存储资源。

Docker假设应用通过TCP/IP通信，而HPC应用都是通过专属网络(IB/ROCE)进行通信的。

● 包含了不必要的资源开销

既然普通的容器化技术满足不了HPC应用的需求，那还有其它办法吗？所谓天降大任于斯人也，必先苦其心志,劳其筋骨,饿其体肤,空乏其身，在经过一番搜寻，终于找到了合适的约会“对象”。

邂逅Singularity

近年劳伦斯伯克利国家实验室专门用于高性能计算场景的容器化技术Singularity横空出世，它完全基于可移植性进行虚拟化，更加轻量级，部署更快，Singularity目前已被广泛地各高性能计算中心。更重要的是，它支持直接将Docker镜像仓转变为Singularity镜像！

针对HPC应用它还有一些独特的优势：

● 更加轻松的环境打包迁徙

Singularity所依赖的东西都在镜像文件中，不需要再单独打包或导入，直接拷贝走镜像即可。没有复杂的缓存机制，并且该镜像已经过压缩，只需占用非常少的磁盘空间。开发态允许直接在笔记本上运行，优化完成后再跑在HPC超算集群上。

和现有系统和调度软件无缝整合

系统用户权限、网络等均直接继承宿主机配置，并且无需进入某个镜像后再执行命令，可以直接在外部调用镜像内的指令，就像执行一个本地安装的指令一样。

● 无需运行 daemon 进程

Singularity提供的完全是一个运行时的环境，在不使用时不需要单独的进程，不占用任何资源。不由daemon进程代为执行指令，资源限制和权限问题也得以解决。

● 性能优良

阿里云使用宿主模式和容器模式对singularity进行了测评，结果显示性能损失<2%，而且对GPU的支持也很好。

▲ 阿里的评测

手把手教你****通HPC容器镜像

经过一段时间的摸索，已经可以将HPC应用通过容器构建出来了，下面是详细步骤：

步骤1：下载HPCRunner包

git clone https://gitee.com/openeuler/hpcrunner.git

**步骤2：初始化环境
**

cd hpcrunner
source ./init.sh

步骤3：安装singularity

./jarvis -install go/1.18 com
./jarvis -install singularity/3.9.6 gcc

步骤4：生成QE容器包

cd container
singularity build openeuler-kgcc9-openmpi4-qe-6.4.sif openeuler-kgcc9-openmpi4-qe-6.4.def

步骤5：安装和容器同版本的MPI库

cp ./templates/qe/6.4/data.qe.container.config ./
./jarvis -use data.qe.container.config
./jarvis -d -dp -e
source env.sh

步骤6：运行容器(-np 后面的数字为核数，请按实际核数指定)

cd container
mpirun --allow-run-as-root -x OMP_NUM_THREADS=1 -np 96 singularity exec --pwd /hpcrunner/workloads/QE/qe-test openeuler-kgcc9-openmpi4-qe-6.4.sif /hpcrunner/q-e-qe-6.4.1/bin/pw.x -input test_3.in

如果你跑通了这个HPC应用容器，那么恭喜你完成了和Singurarity的美妙约会！请在评论区写出你的感受。

总结

美好的时光总是短暂的，HPC应用的生态需要大家共同建设才能结出美丽的果实，如果您对HPC有兴趣请加入openEuler HPC-SIG，这里除了有迁移调优技术分享，还有大量开源实习机会，坐在家里就能领工资，更有百万奖金众智计划等你来拿，同时关注开源项目贾维斯，为多样性算力添砖加瓦，共建openEuler生态。