10-24 周二 论文阅读 Containerisation for High Performance Computing Systems: Survey and Prospects

10-24 周二 Containerisation for High Performance Computing Systems: Survey and Prospects 论文阅读

时间	版本	修改人	描述
2023年10月24日11:07:46	V0.1	宋全恒	新建文档
2024年4月12日15:26:50	V1.0	宋全恒	完成了论文的阅读

简介

 继续看文章了。

摘要

Abstract—Containers improve the efficiency in application deployment and thus have been widely utilised on Cloud and lately in High Performance Computing (HPC) environments. Containers encapsulate complex programs with their dependencies in isolated environments making applications more compatible and portable. Often HPC systems have higher security levels compared to Cloud systems, which restrict users’ ability to customise environments. Therefore, containers on HPC need to include a heavy package of libraries making their size relatively large. These libraries usually are specifically optimised for the hardware, which compromises portability of containers. Per contra, a Cloud container has smaller volume and is more portable. Furthermore, containers would benefit from orchestrators that facilitate deployment and management of containers at a large scale. Cloud systems in practice usually incorporate sophisticated container orchestration mechanisms as opposed to HPC systems. Nevertheless, some solutions to enable container orchestration on HPC systems have been proposed in state of the art. This paper gives a survey and taxonomy of efforts in both containerisation and its orchestration strategies on HPC systems. It highlights differences thereof between Cloud and HPC. Lastly, challenges are discussed and the potentials for research and engineering are envisioned.

• 容器在隔离的环境中封装了复杂的程序和它们的依赖，这使得应用更加的兼容和更可移植。
• HPC上的容器需要包含大量的库，导致尺寸较大。这些库针对硬件进行优化，这危害了容器的可移植性。
• 与HPC相比，Cloud实际上通常整合复杂的容器编排机制。但在HPC上启用容器编排机制的方法已经提出了。

 本文给出综述和分类，关于HPC系统上的容器化和编排策略。强调Cloud和HPC的差异。

引文

第一段 容器化技术

应用程序及其依赖项被封装到容器中[1]，这样可以保证环境兼容性，并使用户可以轻松地在集群之间移动和部署程序。

Applications together with their dependencies are encapsulated into containers [1], which can ensure environment compatibility and enable users to move and deploy programs easily among clusters.

 虚拟化技术：

• VM
• Container， 更加轻量级，因为共享host 内核。

第二段 HPC系统

 高性能计算 (HPC) 系统传统上用于执行大规模金融、工程和科学模拟 [4]，这些模拟需要低延迟（例如互连）和高吞吐量（例如在特定时间内完成的作业数量）。

• 不允许用户安装新的软件，因为可能会更改已有用户的工作环境，并且甚至引起安全风险。
• module软件环境对于dynamic AI软件栈也不方便

第三段 容器化复杂-容器编排策略

容器化不仅可以在 HPC 系统上实现定制环境，还可以将研究的可重复性付诸实践。

 HPC systems, per contra, lack features of efficiency in container scheduling and management (e.g. load balancing and auto container scaling), and often provide no integrated support for environment provisioning

 相反，HPC 系统缺乏容器调度和管理的高效功能（例如负载均衡和自动容器扩展），并且通常不提供对环境配置的集成支持

研究-containerisation and container orchestration on Cloud

containerisation and container orchestration on Cloud

容器化和容器编排

• 研究 HPC 系统上容器化的最新成果，并强调它们在云方面的差异；
• 介绍HPC和云环境上具有代表性的编排框架，并强调它们的功能差异；
• 汇聚云上容器编排策略融入HPC环境的相关研究
• 讨论挑战并展望研究和工程的潜在方向。

章节目录

• 第二部分： 容器技术和技巧

• 第三部分： 最领先的容器容器引擎关键技术

• 第四部分： 容器编排策略， HPC和Clound系统的特征差异。

• 第五部分： 研究挑战和愿景

• 第六部分： 总结本文

容器化概念和技术

 云和 HPC 系统上的容器化技术之间的主要区别在于安全性和工作负载类型。HPC 应用程序往往需要更多资源，不仅包括 CPU，还包括内存量和网络速度。因此，HPC 社区开发了复杂的工作负载管理器来利用硬件资源并优化应用程序调度。

 HPC系统上的容器技术和技巧可以分类为：

1. 容器引擎/运行时
2. 容器编排策略。

 在第一类中，已经开发了各种容器引擎架构，它们在命名空间的使用（参见第 2.1 节）、图像格式和编程语言方面有所不同。第二类则相对原始。

容器化概念

虚拟化技术

 容器化是一种操作系统级虚拟化技术[17]，它提供应用程序执行环境的分离。容器是一个可运行的镜像实例，它将程序及其库、数据、配置文件等封装在一起。

 传统的VM加载完整的guest-kernel进入内存，这可能会占据数个G的存储空间，并需要相当大的系统资源来运行。VMs由虚拟机管理程序管理，VMM。

 🔤除了可移植性之外，容器还具有可重复性，即一旦在容器内定义了程序，无论其运行情况如何，其包含的工作环境都保持不变。🔤

 然而，共享内核策略存在一个明显的缺陷：Windows 容器化应用程序无法在 Unix 内核上执行。

 HPC 应用程序通常针对处理器架构、互连、加速器和其他硬件方面进行了高度优化。因此，容器化应用程序需要在性能和可移植性之间进行折衷。研究表明容器通常可以达到接近原生的性能

命名空间资源

 Linux 有几个命名空间 [28] 隔离各种内核资源：挂载（文件系统树和挂载）、PID（进程 ID）、UTS（主机名和域名）、网络（例如网络设备、端口、路由表和防火墙规则） 、IPC（进程间通信资源）和用户。

 🔤Linux 命名空间的一种应用是容器的实现，例如Docker 是使用最广泛的容器引擎，它使用命名空间来提供称为容器的隔离工作空间🔤

Docker

 Docker,起初基于LXC，是一个支持多个平台的容器引擎。

• Linux
• OSX
• Windows

Docker 容器镜像由一系列只读层之上的可读/可写层组成。当创建新的 Docker 容器时，一个新的可写层会添加到底层。对正在运行的容器所做的所有更改，例如写入新文件、修改或删除现有文件，都会写入这个薄的可写容器层。

 Docker采用命名空间，包括Cgroups来提供资源隔离和资源限额。

各种容器引擎命名空间的支持

 Docker创建了三种类型的网络来提供网络隔离和通信。

• host
• bridge(默认)
• none

网络问题

 该软件桥允许 Docker 容器在同一桥接网络内进行通信；同时，将容器与不同的桥接网络隔离。同一主机上的容器可以通过主机IP地址通过默认网络进行通信。

 为了与位于不同主机上的容器进行通信，主机需要在其 IP 地址上分配端口。

root权限问题

 在用户通常具有root权限的云上，Docker被广泛采用。例如，Unix套接字的使用可以更改为TCP套接字，这将授予攻击者远程控制权以特权模式执行任何容器。

HPC上容器引擎和运行时

 为HPC系统设计的容器引擎/运行时，并且比较主流容器引擎，Docker之间的差异。

最领先的容器引擎和运行时

 它们在功能范围和实施方面有所不同，但也有一些相似之处。

 容器引擎如下

• Shifter
• Charliecloud
• Singularity
• SARUS
• UDocker
• 其他HPC容器引擎

Shifter

 Shifter [31] 是 NERSC 开发的 HPC 容器引擎的原型实现。构建镜像后，用户可以将其提交到非特权网关，该网关会注入配置和二进制文件，将其扁平化为 ext4 文件系统镜像，然后压缩为会复制到节点上的并行文件系统的 squashfs 镜像。

 Shifter只可以授予用户级别的特权。

 支持MPI。为了在不影响容器可移植性的情况下启用 GPU 等加速器支持，Shifter 运行时会在容器启动时将 Shifter 容器的内置 GPU 驱动程序替换为 ABI（应用程序二进制接口）兼容版本。

Charliecloud

Charlicloud can convert a Docker image into a tar file and unpacks it on the HPC nodes. Installation of Charliecloud does not require root permission

Charlicloud 可以将 Docker 镜像转换为 tar 文件并在 HPC 节点上解压。 Charliecloud的安装不需要root权限

 支持MPI。Charliecloud 使用将主机文件注入图像来解决库兼容性问题，例如可能与特定内核版本相关的 GPU 库。

Singularity

 专门为HPC系统而设计的。

• 使用用户特权运行，并且没有守护进程。当用户想要构建或者重建镜像时，获取root权限才是必须的。
• 与HPC系统无缝集成。原生就支持GPU、MPI、和IB。
• 通过一个单一的镜像文件(SIF 格式)可移植。

 执行MPI应用的方式有两种：

• hybrid model
• bind model

 🔤前者将 MPI 二进制文件、库和 MPI 应用程序编译成 Singularity 映像。后者将容器绑定到主机位置，容器在该位置使用主机上的 MPI 库和二进制文件。🔤

 🔤建议使用混合模型，因为在主机上挂载存储卷通常需要特权操作。🔤

 大多数 Docker 镜像都可以通过简单的命令行直接转换为Singularity 镜像（例如 docker save、奇异性构建）。 Singularity 已迅速成为 HPC 系统的事实上的标准容器引擎。

SARUS

 SARUS依赖runc来实例化容器。

 runc 是一个 CLI（命令行界面）工具，用于根据 OCI（开放容器计划）规范生成和运行容器。

 

 两个组件

• image manager
• runtime

CLI 组件采用命令行来调用图像管理器组件或运行时组件。后者通过创建包含根文件系统目录和 JSON 配置文件的包来实例化和执行容器。然后，运行时组件调用 runc 来生成容器进程。

UDocker

 UDocker是Docker容器的Python包装器，它只在用户空间执行简单的Docker容器，无需获取root权限。提供类似 Docker 的 CLI，仅支持 Docker 命令的子集，即搜索、拉取、导入、导出、加载、保存、创建和运行。

🔤值得注意的是，UDocker 既不使用 Docker，也不要求其存在于主机上。🔤

其他HPC容器引擎

 Podman 容器镜像与 Docker 一样包含多层读写文件。它采用与 SARUS 和 Docker 相同的运行时 runc。还支持比 runc 更快的运行时 crun。 Podman 的一个显着特点正如其名称所示：Pod 的概念。 Pod 将一组容器分组，这些容器共同实现复杂的应用程序以共享命名空间并简化通信。此功能可以与 Kubernetes [37] 环境（第 4.2.1 节）融合，但是需要高级内核功能。

 Socker 用于在 HPC 环境中运行 Docker，更具体地说是 SLURM。

 Enroot 来自NVIDIA， 可以被视为是一个增强的非授权chroot。🔤它消除了其他容器引擎通常提供的大部分隔离，但保留了文件系统分离。 Enroot 使用用户和挂载命名空间。🔤

HPC容器引擎性能评估

 performance of containers that are specifically targeted for HPC systems in terms of CPU, memory, disk (I/O), network and GPU.

 专门针对 HPC 系统的容器在 CPU、内存、磁盘 (I/O)、网络和 GPU 方面的性能。

 benchmark

 Singularity 在 CPU、内存和网络带宽方面提供接近本机的性能

• CPU计算开销， MPI库不同时Singularity表现
• CPU 容量，内存，网络带宽和GPU，使用Linpack，利用4个典型的HPC应用NAMD， VASP， WRF, AMBER.
• Singularity 随着GPU节点的增加时的表现。
• Shifter容器和HPGMG-FE基准测试，性能边缘不显著。
• Shifter和Singluarity在裸机上计算时间消耗。

 Without performance comparison with bare-metal applications, the work in [27] studied the CPU, memory, network and I/O performance of Charliecloud, Podman and Singularity.

 在没有与裸机应用程序进行性能比较的情况下，[27]中的工作研究了 Charliecloud、Podman 和 Singularity 的 CPU、内存、网络和 I/O 性能。

 SARUS展示了强缩放能力，使用hybrid GPU和CPU节点。

章节重点

 向HPC系统中引入容器，这是因为它们能够为用户提供环境定制的能力，这提供了应用兼容性问题的解决方案。

 相同的特征

• 非root特权
• 通常能够将Docker镜像转换为它们自己的镜像格式。
• 支持MPI
• 使用host网络而不是可插拔网络驱动。

容器编排

编排： 本文上下文中的编排是指云或 HPC 系统的自动配置、协调和管理。

• HPC workload managers
• Cloud orechestrators

 大多数情况下，HPC 系统的容器编排要么依赖于现有云编排器的编排策略，要么利用当前 HPC 工作负载管理器或软件工具的机制。

HPC系统负载管理器

 A workload manager comprises a resource manager and a job scheduler. A resource manager [52] allocates resources (e.g. CPU and memory), schedules jobs and guarantees no interference from other user processes. A job scheduler determines the job priorities, enforces resource limits and dispatches jobs to available nodes [53].

  工作负载管理器包括资源管理器和作业调度器。资源管理器[52]分配资源（例如CPU和内存），调度作业并保证不受其他用户进程的干扰。作业调度程序确定作业优先级，强制执行资源限制并将作业分派到可用节点[53]。

 HPC工作负载调度器: 包括

• PBS *
• Spectrum LSF
• Grid Engine
• OAR
• Slurm *

工作负载管理器共享一些相同的特征： 中央调度系统， 排队系统和静态资源管理机制。

PBS

PBS： Portable Batch System ，一共有三个版本

• OpenPBS
• PBS Pro
• TORQUE

pbs 服务器守护进程和作业调度程序守护进程位于头节点上。批处理作业提交到头节点（某些情况下，作业会先提交到登录节点，然后传输到头节点）

 在TORQUE上提交作业的流程简述如下：

1. 作业通过命令 qsub 提交到头节点。作业通常以 PBS 脚本的格式编写。作业 ID 作为 qsub 的标准输出返回给用户。
2. 生成包含作业 ID 和作业属性的作业记录并将其传递到 pbs 服务器。
3. pbs 服务器将作业记录传输到作业调度程序守护进程。作业调度程序守护进程将作业添加到作业队列中，并对其应用调度算法（例如 FIFO：先进先出），该算法确定作业优先级及其资源分配。
4. 当调度程序找到作业的节点列表时，它会将作业信息返回给 pbs 服务器。该列表中的第一个节点成为Mother Superior node，其余节点称为sister MOMs 或sister nodes。 pbs 服务器分配资源，并将作业控制以及执行信息传递给安装在 mom superior 节点上的 pbs mom 守护进程，指示在指定的计算节点上启动作业。
5. 计算节点上的 pbs mom 守护进程管理作业的执行并监视资源使用情况。 pbs mom 将捕获所有输出并将它们定向到 stdout 和 stderr，这些输出和错误文件将被写入输出和错误文件，并在作业成功完成时复制到指定位置。作业状态（已完成或终止）将由 pbs mom 传递到 pbs 服务器。职位信息将会更新。

 一个作业pbs批处理脚本示例：

#!/bin/bash
#PBS -l nodes=1:ppn=4 【设定该作业所需1个节点，每个节点使用4核】
#PBS -l walltime=1500:00:00 【设定作业所需的最大wallclock时间】
#PBS -j oe
#PBS -q batch
source /public/software/profile.d/mpi_openmpi-intel-2.1.2.sh
nodecpu=’cat /proc/cpuinfo|grep processor|wc -l’
Id=’echo $PBS_JOBID | awk -F. ‘{print $1}’’
NP=’cat $PBS_NODEFILE|wc -l’
echo “The Jobbed is $id”
echo “Worker dir is $PBS_O_WORKDIR”
cat $PBS_NODEFILE
echo “begin time is ‘date’”
cd $PBS_O_WORKDIR
mpirun -np 4 vasp_std
echo “End time is ‘date’”

 在Torque中，节点被划分成不同的组中，这称为queues。分组有利于异构节点的管理，或者说某些节点为了特定的用户而预留。

调度器

 默认调度器：FIFO，并通常集成更加复杂的作业调度器，诸如Maui。Maui有如下高级特征：

• 动态工作优先级
• 可配置参数
• 广泛的公平共享功能
• 回填调度 （backfill scheduling）

 Maui会开启新的迭代，当下面的条件满足时：

• 作业或者资源状态变更时
• 保留的边界事件发生时
• 当触发了恢复调度的外部命令发起时
• 配置的定时器过期时

 在每个迭代中，Maui遵循如下的步骤：

1. 从TORQUE获取资源记录。
2. 从TORQUE获取负载信息
3. 更新统计数据
4. 刷新预定（reservation）
5. 选择有资格优先调度的作业。
6. 为有资格的作业分配先后次序
7. 根据优先级调度作业并创建预订。
8. 回填作业。

调度策略

 回填调度[61]允许作业占用保留的作业槽，如果此操作不会延迟已保留资源的其他作业的启动，从而允许大型并行作业执行并避免资源利用不足。

• Backfilling Scheduling
• Gang Scheduling

SLURM

SLURM: Simple Linux Utility for Resource Management

• slurmctld: 负责集群资源和作业管理。并且slurmctld可以主备部署，高可用
• slurmd: 位于计算节点： 负责作业暂存和执行
• slurmdbd: 收集和记录记账信息。
• slurmrestd: 提供REST API服务，与SLURM交互。

 

Spectrum LSF

LSF: Load Sharing Facility(LSF)IBM 平台负载共享设施 (LSF) 面向企业，专为分布式 HPC 部署而设计。基于Utopia job schduler。

 LSF支持容器负载： Docker, Singularity,和Shifter。

 🔤LSF 在由系统管理员管理的应用程序配置文件 4 中配置容器运行时控制。🔤

 Users do not need to consider which containers are used for their jobs, instead only need to submit their jobs to the application profile and LSF automatically manages the container runtime control.

云上编排框架

 云集群通常包括协调任务和硬件资源的编排机制。云已经发展出成熟的编排器来有效地管理容器。

 容器编排机制能够提供：

• 资源限制控制。为容器预留一定数量的CPU和内存，抑制其他容器的干扰，为调度决策提供信息；
• 调度。它确定优化容器在节点上的放置的策略；
• 负载均衡。它在容器实例之间分配工作负载；
• 健康检查。它验证是否需要销毁或更换有故障的容器；
• 容错。 允许维持一定数量的容器
• 自动扩缩。 能够自动的添加和删除容器。

 另外，容器编排器应该也能够简化网络，启用服务发现和支持持续部署。

Kubernetes

deployment: 提供服务。

 Kubernetes 基于高度模块化的架构，该架构抽象了底层基础设施并允许内部定制，例如软件定义网络或存储解决方案的部署。

 Kubernetes 包含一个调度系统，允许用户为每个作业指定不同的调度程序。调度系统在实际调度操作之前根据两个步骤进行决策：

1. )节点过滤。调度程序找到适合工作负载的节点，例如pod 指定了节点亲和性，因此，只有某些节点可以满足亲和性要求，或者某些节点可能没有足够的 CPU 资源来服务请求。通常调度程序不会遍历整个节点列表，而是选择首先检测到的一个或多个。
2. 节点优先级计算。调度程序计算每个节点的分数，得分最高的节点将运行该 pod。

Docker Swarm

Docker Swarm是为Docker引擎构建的，是一个更加简单的编排器。它提供的功能不太丰富，定制和扩展有限。因此轻量级，适合小的工作负载。相比之下，Kubernetes 对于个人开发人员来说是重量级的，他们可能只想为简单的应用程序设置一个编排器并执行不频繁的部署。尽管如此，Docker Swarm仍然有自己的API，并提供过滤、调度和负载均衡。

Docker Swarm可以用来在HPC系统上执行容器编排。

Apache Mesos and YARN

 Apache Mesos [70] 是一个集群管理器，可跨分布式应用程序或框架提供高效的资源隔离和共享。

 Mesos 是一个非整体调度程序，充当仲裁者，在多个调度程序之间分配资源、解决冲突并确保资源的公平分配。

Apache YARN: Yet Another Resource Negotiator. 是一个整体调度程序，最初是为了调度 Hadoop 作业而开发的。YARN 专为长时间运行的批处理作业而设计，不适合长时间运行的服务和短期的交互式查询。

 Mesosphere Marathon是容器编排框架，为Apache Mesos而设计。Mesos together with Marathon已经用于了HPC系统。

Ansible

 Ansible [73] 是一种流行的软件编排工具。更具体地说，它处理配置管理、应用程序部署、云配置、临时任务执行、网络自动化和多节点编排。

 配置由使用 yaml 描述自动化作业的 playbook 设置，并且通过 ssh 连接到其他节点

OpenStack

 在Cloud上，OpenStack在多数情况下被部署成基础设施即服务(IAAS).它可用于部署和管理基于云的基础设施，支持各种用例，例如网络托管、大数据项目、软件即服务 (SaaS) [76] 容器、虚拟机或裸机的交付和部署。

 加上对容器、容器编排器（例如 Docker Swarm、Kubernetes 和 Mesos）的支持，Openstack 使快速部署、维护和升级复杂且高度可用的基础设施成为可能。

HPC和Cloud的桥梁编排策略

章节重点

研究挑战和展望

挑战和开放问题

容器化实现了兼容性、移植性和可重现性，容器化的环境仍然需要匹配宿主机的架构并且利用底层的硬件。

在HPC系统上容器化面对的挑战有三重：

• 兼容性
• 安全性
• 性能

研究和工程机会

总结

 其实这篇文章是自己从23年10月20日开始看的，结果啊，到了今天才完成了阅读，真的是非常惭愧。看了一下zhou naweiluo这个原来是四川大学的学生，还是很优秀的。

 通过本文的阅读，自己了解到了HPC和容器化两个核心的观念，

 最近呢，自己一直在阅读文献，但是问题很大，因为在阅读文献的时候，也只是悠悠放任，因为文献阅读没有目标，我们真的要想想阅读一个文献，为什么要读这个文献，自己要构思一下，自己真的要改变一下自己的这个病态的从容的这个毛病，习气太重了，还是应该尽情改刷。另外，就是在文献阅读的时候，因为一篇文献有很多很多的内容，怎么把这些内容抽取出来，然后自己去使用呢，自己发现了一个Zotero的插件叫做Zeocard,在看这个文章的时候，自己定义了许多的卡片

 自己也在淘宝上购买了一本卡片式读书笔记的方法，但关键是怎么快速的检索这些卡片呢？看网上有许多的内容讲述的事Zotero和Obsidian联动，然后进行卡片的同步更新，自己还没有弄清楚。不过，不管怎么说，又看完了一篇paper了，开心。