HPC环境容器技术应用漫谈

容器技术是一种轻量级的虚拟化技术，过去十年在云计算领域中得到了广泛应用，也逐步向高性能计算（HPC）领域渗透。

容器共享操作系统的内核，不需要虚拟各种硬件，也不需要再运行一个操作系统，它的效率会更高。容器是一种操作系统层面的虚拟化技术，一个运行的容器中通常包含程序和程序所依赖的库文件、数据和配置文件等。

容器的轻量和依赖封装等特点在HPC环境中大有用武之地。轻量意味着使用它所造成的性能损失较小，依赖封装则让用户在很大程度上省去在各种异构的HPC环境中重复编译软件的麻烦。

容器怎样适应HPC环境

容器技术主要是在云计算环境中发展的，要在HPC领域得到应用，需要考虑两种应用环境对性能的取舍以及工作负载的差异。

性能的取舍

在云环境中，容器倾向于屏蔽底层硬件的差异，为上层应用提供一致的软件环境。同时，为满足云计算用户对资源隔离的需求，容器大量使用了命名空间（Namespace）技术实现对多种内核资源的隔离，比如文件系统树和挂载点、主机名和域名、网络、IPC和用户等等。

在HPC环境中，通常有很多为性能而进行优化的处理器、高速互联网络、加速器、GPU/TPU等尖端硬件，如何充分利用这些硬件来加速计算是主要的关注点，通用性和可移植性往往退居次要位置。相对云环境，容器需要更多地接触和使用这些特殊硬件。

另外，在HPC环境中，用户通常只有普通用户的权限，且工作负载管理器（WLM，Work Load Manager，也称调度器）已实现了对用户任务资源的分配管理，没有必要在容器中再做隔离设置。而减少命名空间的使用，也能节省系统资源，提高程序的运行效率。

工作负载的差异

在云环境中，容器可以对外提供长期运行的服务，也可以提供按次收费的短时计算服务（如FaaS，Function as a Service）。请求往往是即时调度，即时处理，不需排队等待资源就位。当容器出现故障时，容器管理系统会删除它并重新创建，没有检查点（Checkpointing）功能。

在HPC环境中，用户提交的任务一般称为作业（Job）。作业提交后进入批处理队列中等待运行作业所需的资源就位，排队等待时间可以是数秒钟，也可能是数天。HPC作业的调度策略一般是某种类型的回填（Backfilling）策略，以充分利用HPC环境中的硬件资源，减少用户作业的等待时间。作业在被调度执行后，会一直执行直到完成或异常退出，执行时间可能是数小时、数天或数月。由于作业执行时间较长，为避免作业因各种原因中断而需重新计算，HPC环境的调度器会提供检查点（Checkpointing）功能，将作业分成几个阶段，一个阶段完成后对作业状态及中间计算结果进行保存。如果在某阶段作业出现异常，可从上阶段的检查点重新开始执行。

HPC环境中的容器通常作为作业的主程序执行，由调度器进行资源的分配和管理，不会长期运行。

HPC容器应用现状

容器技术在HPC环境中的应用主要分为两个方面：容器引擎和容器编排。

云计算业界有多款容器引擎（Docker/rkt/runc/Podman等），它们主要针对云计算环境的需求，并不贴合HPC的使用场景。因此，很多以HPC应用为目标的容器引擎涌现了出来，主要有Singularity/Apptainer、Charliecloud、Shifter等。

这些HPC容器引擎与通用容器引擎Docker有一些共同点，比如使用命名空间、支持MPI、支持访问主机GPU、支持访问主机文件系统等。但两者也存在明显的差异。

首先，通用容器引擎一般使用可插拔的网络驱动（比如bridge、macvlan、ipvlan等），而HPC容器引擎通常选择复用主机网络。因为HPC网络可能经过高度定制，从底层驱动到上层的通信协议都与一般的TCP/IP网络有很大差别，直接复用可以充分利用网络本身特性，避免协议转换造成的性能损失。

其次，HPC容器引擎在镜像格式的选择上更倾向于单个镜像文件或者文件系统打包，而不是分散的多层文件结构。这有利于容器镜像的传输和部署，因为HPC环境的大规模共享存储往往是朝吞吐带宽最大化的方向进行优化的，小文件读写性能相对较差。如果在环境中频繁地创建和销毁容器，多层文件结构的容器镜像将给存储带来很大压力。

再次，HPC容器引擎一般选择与现有的HPC调度器集成，而不是使用主流的容器编排软件。

当前主流的容器编排软件主要是Kubernetes、其他基于Kubernetes的软件（比如OpenShift和Rancher），以及Docker Swarm、Apache Mesos等。它们在不经过大幅修改的情况下，不能较好地适应HPC环境。

HPC容器编排技术目前存在几个发展方向。

一是在现有的调度器中增加对容器编排的支持。这种方式对HPC用户较为友好，但很多容器编排功能无法复用现有代码，开发量较大。

二是通过插件对接调度器和容器编排软件，使两个环境能相互调用对方的资源。这种方式可复用现有的容器编排功能，较灵活。但如果两个环境之间的数据交互频繁，数据传输量大，插件本身可能成为瓶颈，带来较高的网络延迟。

三是在云计算环境中部署HPC集群，通过容器编排系统下发HPC作业，作业也封装成容器执行。这种方式对HPC环境的运行逻辑进行了较大改动，无法较好地与现有HPC环境集成。

四是在HPC调度器和容器编排系统之上再增加一个编排策略层，编排策略层根据需要下发普通作业或容器作业，还可在其上实现与现有容器编排系统不同的编排策略。这种方式灵活性更好，但增加了架构的复杂性和维护难度，开发量较大。

相对容器引擎而言，HPC容器编排还在发展的初期，用户主要还是使用调度器直接调用封装好的容器执行作业。更为复杂的容器编排方式在积极探索中，还没有形成被广泛接受和使用的方法和实践。