Volcano：容器批量调度器实现材料模拟并行计算【与云原生的故事】

容器技术能够在性能损耗可忽略的前提下，使得材料模拟环境具备隔离性和可迁移性，但是将容器编排服务应用到材料模拟领域还需要开展多方面的研究工作，尤其是对于如何在材料模拟任务中发挥出容器编排服务的优势，以及如何使用更加贴合深度学习、大数据及 MPI 等计算模式的调度引擎来完成容器化科学计算任务，还缺乏相关的研究和实践。在容器化材料模拟应用中研究如何将 Kubernetes 扩展为批量容器调度模式，有利于容器技术更加深入地应用到高性能计算领域。因此本文将面向 Kubernetes 等容器编排服务，在 Volcano 批量容器调度引擎的加持下，就解决材料模拟等科学计算中存在的部署困难、环境依赖混乱，以及容器化应用批量计算时容器状态一致性等限制问题，展开分析和研究。

云原生与材料模拟现状

能源、环境危机等当代社会问题导致新型材料的需求量日益增长，计算辅助材料模拟俨然成为现代能源、功能材料分析的主要方式之一。但由于高性能计算系统的性能增长幅度远不及材料原子体系规模的扩大幅度，未来需要使用智能计算的方式来加快计算辅助模拟的时间尺度。高性能计算、人工智能和物理模型三者结合有望成为材料模拟领域中新的计算模式。

基于容器的虚拟化技术能够有效隔离不同材料模拟应用的依赖环境，并且能够在多种平台上进行迁移和扩展。一些深度学习训练和材料模拟任务需要多个容器同时配合运行，这就需要一种面向作业的批量容器处理系统。常见的高性能计算集群批量作业调度器（工作负载器）是面向节点等计算资源，并不是面向容器的，它无法深度集成容器管理功能和容器生命周期控制机制。在材料模拟研究中控制并调度容器以完成分子动力学模拟作业，这需要一套完善的容器批处理系统，该系统除了需要容器编排服务用于管理容器等资源，还需要批量容器调度器提供面向作业的批量容器调度机制。

Docker Swarm 和 Kubernetes 两种容器编排服务在材料模拟作业的适用性上仍然存在一定的限制。例如，Kubernetes 内置的资源调度程序根据容器对 CPU 和内存等资源的请求，依次调起每一个容器并开始运行服务，但是对于某些分布式深度学习训练任务或并行分子动力学计算任务，需要多个容器环境同时启动成功后，才能够开始进行计算，此类计算任务中包含的多个容器的状态必须是同步的， Kubernetes 需要新的容器调度引擎以满足这一需求。同时，将异构计算资源细粒度地分配给容器，还需要一些对包含GPU在内的异构计算设备混合调度能力。

Docker Swarm 和 Kubernetes 在运行材料模拟作业时，都存在一定的缺陷和不足，具体表现在如下几个方面：

（1）作业生命周期的管理。对于 MPI 并行计算模式，各个并行节点之间的容器需要频繁交互计算数据，此时如果某个容器出现故障，那么执行作业的所有容器都应该被重启。这个机制在 Docker Swarm 和 Kubernetes 上都是缺失的。例如使用Docker Swarm 运行分子动力学模拟作业时，如果 Worker 节点的容器发生故障，那么 Master 节点的容器计算任务不会自动重启，滞留在故障状态。

（2）任务清理。当材料模拟作业计算完成后，应当释放计算资源以供其他作业使用。但是 Docker Swarm 和 Kubernetes 在计算任务结束后，容器还在继续以长服务的方式运行，此时需要手动删除整个任务部署才能释放资源，缺少对容器针对性清理的机制。例如使用 Kubernetes 执行完分子动力学模拟作业后，负载计算任务的 Pod 不会自动进行资源释放，导致其他 Pod 申请不到足够的资源，此时形成资源请求死锁。

（3）多元异构资源的支持。CPU + GPU 的异构计算在材料模拟中应用广泛，使用Docker Swarm 或 Kubernetes 进行异构计算时使用 NVIDIA Docker 插件在容器中调用 GPU 设备，但是在默认情况下两者都缺少对 GPU 设备的管理方案，对于多个GPU 占用率低下的容器，不能充分利用 GPU 资源。

（4）调度策略。在以 Slurm 作为批量作业调度器的集群中，是以作业为调度对象的，而 Docker Swarm 和 Kubernetes 以容器或 Pod 为调度单位。当计算资源不足以运行即将调度的一批容器时，Docker Swarm 和 Kubernetes 不会感知到作业整体的资源占用。例如，将需要5个节点的并行计算任务提交到4个节点上，Kubernetes 会依次将4个 Pod 调度到4个节点上，当调度第5个 Pod 时，发现资源不足，此时之前的调度全部作废。容器编排服务缺少以作业为整体的调度策略。

基于Volcano的容器批处理系统

Volcano 是基于 Kubernetes 的容器批量调度引擎，它提供了 Kubernetes 目前缺少的一套作业管理机制，该机制正是深度学习、大数据应用、科学计算、特效渲染等多种高性能工作负载场景所需的。作为一个通用容器批量调度器，Volcano 与主流计算框架（例如 Spark，TensorFlow，Argo，OpenMPI 等）均实现了对应接口，还提供了包含 CPU（ ARM 架构）和 GPU 在内的异构计算设备混合调度能力。因此，对于材料模拟领域所需的材料模拟应用环境和深度学习环境，基于 Kubernetes 的 Volcano 不但能够将这两种环境一次封装进容器中后多次使用，还能够满足在多个封装后的容器之间进行并行计算的条件，以作业的形式在容器化的材料模拟系统中进行批量容器调度。

方案设计

方案介绍

Volcano批量容器调度器及调度策略

在混合多种场景的高性能计算系统中，不同的应用场景需要不同的计算框架。 目前没有一种资源管理系统能做到各种计算框架、业务场景的统一，资源管理层形成相互独立的、分割的 “孤岛”，这样会导致组件无法解耦，资源管理混乱，硬件利用率低下等问题。 Volcano 是基于 Kubernetes 的容器批量计算平台，它适用于大规模的容器应用场景，提供了 Queue 和 Volcano Job 通用作业管理 API，支持在线和离线作业混合部署。Volcano 集成了多种主流的计算框架，结合 Kubernetes 的资源管理功能，将多种混合场景的资源管理层统一化管理，因此 Volcano 对于高性能计算、 人工智能和物理模型融合的新型计算模式的发展有重要的影响。

它主要解决了 Kubernetes 以下几个限制：

（1）作业管理能力的缺失。Kubernetes 基本调度单元是 Pod，不能感知到多个 Pod 存在作业层面的联系。Volcano Job 将一组关联的 Pod 抽象成作业，不但能够控制整个作业的生命周期（启动、终止、完成、重启），而且提供了资源队列，作业任务依赖等方面的支持。

（2）任务清理。Volcano 在作业执行完成后，不会直接将 Pod 删除，而是将 Pod 标记为完成状态（日志和输出结果得到保留），释放 Pod 占用的资源，完成本地资源回填，提高资源利用率。

（3）调度策略的局限性。Kubernetes 没有针对科学计算作业进行资源预留， 不支持作业间的公平调度等调度策略。Volcano 为成组的容器提供批处理功能， 能够解决以上缺陷导致的局部容器无效启动，以及当整体作业失败时的资源无效占用问题。

（4）对各领域的计算框架支持不足。不同作业场景需要不同的计算框架， Kubernetes 很难统一集成。Volcano 集成了多种作业场景的计算框架，例如 TensorFlow、Spark、Argo、OpenMPI 等。

Volcano 主要在 Kubernetes 的资源管理功能基础上进行扩展，与 Kubernetes 结合后的各组件架构如图1所示，蓝色部分为 Kubernetes 的组件，绿色部分为 Volcano 的组件。

图1 Volcano架构

从架构上看，Volcano 在 Kubernetes 的基础上增加了 volcano-admission、volcano-controllers、volcano-scheduler 三个组件。这三个组件的运作流程如下：

（1）volcano-admission 初始化后，kubectl 将在 kube-apiserver 中创建 Job （Volcano CRD）对象，使用 vsub 以命令行的方式提交作业。

（2）volcano-controllers 会根据 Job 的配置创建相应的 Pod 及 PodGroup。 volcano-controllers 包含了 QueueController、JobController、PodGroupController 等。 JobController 是本实验的主要控制器，工作原理如图 2 所示。

图2 Volcano的JobController工作原理

（3）Pod 及 PodGroup 创建好后，volcano-scheduler 会从 kube-apiserver 中 获取 Pod 或 PodGroup，以及对应节点的信息。Kubernetes 允许多个调度器在集 群系统中并存，为了保证高性能计算作业运行时的稳定性，防止发生调度器冲突， 本实验用volcano-scheduler完全替换了Kubernetes的原生调度器kube-scheduler。

（4）volcano-scheduler 获取到 Cache 处理过的相应信息（Jobinfos）后，将 根据其配置的调度策略（以插件的形式配置）为每一个 Pod 选取合适的节点， 调度过程在一个 Session 会话中进行，每个调度周期会创建一个 Session。volcano-scheduler 工作原理如图 3 所示。

图 3 推特数据中心资源利用率

（5）在为 Pod 分配节点后，kubelet 将从 kube-apiserver 中获取 Pod 的配置， 启动相应的容器。Pod 的生命周期如图 4 所示，Volcano 在 Kubernetes 的默认 容器状态（蓝色部分）上加入 volcano-scheduler 中的 Sessison 调度状态（绿色部 分）和 Cache 状态（橙色部分）。

图4 Volcano的volcano-scheduler工作原理

通过分析分子动力学模拟场景下的计算需求，结合 Kubernetes 和 Volcano 组件的各个功能，将 Kubernetes 和 Volcano 二者应用于材料模拟中的优势在于：

（1）能够提供通用的作业类型。开发者可以在 Volcano Job 定义文件中描述大部分分子动力学模拟任务，包括指定作业提交时的变量、命令，以及对计算资源的需求量，指定不同类型计算节点等。

（2）能够支持高性能并行计算框架。在分子动力学模拟计算领域，通过多节点并行计算模拟可以很大程度地提高作业运行效率，并行计算作业一般需要 MPI 实现。Volcano 通过配置 SSH 插件的形式使得容器之间可以直接在 Kubernetes 网络上进行数据通信。

（3）能够管理作业生命周期和选择合适的调度策略。Volcano 通过控制分子动力学模拟作业的生命周期，自动执行计算任务结束后的资源回填，不需要开发者手动释放资源。能够选择适用于 MPI 的调度策略。在进行并行模拟计算之前感知资源状态，满足条件后再进行批量调度。

（4）能够支持多元异构算力。目前分子动力学模拟不单单只运行在 X86 架构的系统上，随着近几年 ARM 架构处理器的发展，分子动力学模拟应用也逐渐有了面向诸如鲲鹏、昇腾等处理器的移植优化版本。同时，CPU 和 GPU 异构计算也在分子动力学模拟中应用广泛。Volcano 可以兼容 ARM 架构进行批量计算系统部署，对 GPU 等多元异构资源也提供了调度和共享机制。

Kubernetes+Volcano 对于 GPU 共享的实现

容器化材料模拟应用进行异构计算时，如果存在 GPU 内存占用量较低的问题，很容易造成资源浪费。而 Kubernetes 集群默认会将节点上的 GPU 设备暴露在该节点的所有 Pod 中，多个 Pod 对 GPU 资源的使用将没有限制，容易造成 GPU 内存溢出异常（Out Of Memory Error）。 Volcano 能够提供对 GPU 资源的共享功能，使得多个 Pod 合理有序地利用 GPU 资源。其工作流程如图 5 所示，流程中的主要三个步骤说明如下：

（1）用 volcano.sh/gpu-memory 资源请求创建一个 Pod，该 Pod 携带 GPU 共享资源请求。

（2）volcano-scheduler 会根据 kube-apiserver 中的请求信息，为该 Pod 确 定并分配 GPU 资源，并添加相应的调度注释。

（3）kubelet 监视绑定到其自身的 Pod，并在运行容器之前调用 allocate API 来设置环境变量。环境变量默认为：容器内可见的 GPU 索 引 （ NVIDIA_VISIBLE_DEVICES ） 、 容 器 被 分 配 的 GPU 内 存 容 量 （ VOLCANO_GPU_ALLOCATED ） 、 容 器 内 可 见 的 GPU 内 存 总 量 （VOLCANO_GPU_TOTAL）。

图5 Volcano GPU Share 工作流程

落地效果

Volcano下经典势函数材料模拟系统的实现

这里使用AIREBO经典势函数为例，在 300 K 恒定温度的集成过程中分别模拟 1000、10000、 100000 原子体系，分别在 1、3、5 个 Pod 并行环境下，不同原子体系的模 拟性能对比如图 6 所示。

图6 AIREBO势函数不同CPU核心下的模拟性能

图中显示，在较小的（1000）原子体系模拟过程中， 单个 Pod（共 32 核心）计算效果比较好，模拟性能达到了 744.414 timesteps/s， 而 5 个 Pod（共 160 核心）时的模拟性能为 469.947 timesteps/s，此时增加 Pod 的 数量只会徒增容器间的通信时延，使得性能下降。但是在较大的（100000）原子 体系中，增加 Pod 数量可以使得并行计算效率有明显的提升，在单个 Pod（共 32 核心）时的模拟性能为 32.485 timesteps/s，而 5 个 Pod（共 160 核心）将模拟性 能提升至 85.989 timesteps/s。

LAMMPS 计算任务的 Pod 的 CPU 资源利用率如图7所示。当计算作业开始时，MPI 分别启动 lmp_mpi 可执行程序，从某一时刻各 Pod 的 CPU 利用率 可以看出，在Volcano层面上，角色为Master的Pod的CPU利用率为9332.266%， 角色为 Worker 的 Pod 的 CPU 利用率为 8920.065%和 9447.651%。 结合图 4-2 中节点的 CPU 利用率表明，Pod 占据了节点 36 个核心中的 32 核 心，当 Pod 的 CPU 占用达到节点 32 核心的 90%左右时，节点的 CPU 利用率将 会在 80%左右，说明 Volcano 调度结果符合预期。

图7 Pod CPU利用率监控

Volcano下深度势函数材料模拟系统的实现

深度势能（Deep Potential，DP）通过神经网络生成的深度势函数（DP势函数）相对于DFT密度泛函能够处理更大的体系，时间成本更低，并且与现有的经典力场相比，能够达到更高的精度。本文将在基于Kubernetes的Volcano容器批处理系统中实现深度势函数材料模拟环境。深度势函数训练和模拟过程需要充分利用 GPU 资源，构建本文提出的深度势函数材料模拟系统，需要在经典势函数材料模拟系统基础上配置 Volcano 的 GPU 共享功能，主要构建流程如下：

（1）修改 Docker 配置文件，将 NVIDIA Docker 作为容器运行时配置，用以 在容器中调用 GPU 设备。

（2）配置Volcano的GPU共享功能，首先需要在volcano-scheduler-configmap 配置文件中加入 predicate.GPUSharingEnable 参数，并将其值配置为 true，其次部 署 volcano-device-plugin 插件。

（3）在指定任务相关资源细节方面，追加 Pod 请求的 GPU 资源量（GPU 块数和 GPU 内存容量）。

这里先以能够使用GPU加速的经典势函数Tersoff 为例，对某材料进行 GPU 加速 LAMMPS 模拟时，分别在 2 个节点中进行 1000 原子体系的模拟，此时每个节点只能调度 1 个 Pod，否则会引发 GPU 内存溢出错误。使用 Volcano 的 GPU 共享功能，可以在每个节点上调度 2 个 Pod，将每个 Pod 请求 GPU 资源容量设定为 16280MiB（1 块 GPU 设备）。 在 2 个节点 4 块 GPU 设备的相同硬件资源下，使用 Tersoff 势函数进行材料模拟，2 个 Pod（不使用 GPU 共享）和 4 个 Pod（使用 GPU 共享）10 分钟内对于 GPU 的利用率情况如图 8 和图 9 所示。

图8 10分钟内节点GPU利用率监控

图9 10分钟内节点GPU利用率监控

可以看出，不使用 GPU 共享 的 2 个 Pod 对于某个节点 GPU 的利用率只能达到 45%左右（其中 1 块 GPU 设备始终空闲），使用 GPU 共享的 4 个 Pod 对某个节点的 GPU 利用率均能维持在 80% 左右，这说明 Volcano 使得 Pod 以相应 GPU 资源请求的形式被合理调度， 硬件资源可以得到更加充分地利用。

DP 势函数主要集中在向量矩阵计算，因此采用 GPU 加速可以达到理想的性能提升。使用 DP 势函数对某材料进行 GPU 加速 LAMMPS 模拟时，分别在 2 个节点（每个节点 1 个 Pod）中进行 10000 个原子体系负载，发现 Pod 对每个节点的两块 GPU 设备使用较充分。因此将每一个 Pod 资源请求设定为 GPU 内存占用量 32560MiB（两块 GPU 设备）。在 DP 势函数的 GPU 加速 LAMMPS 模拟中，对单个节点的两块 GPU 设备利用率在 1 小时内进行监控，DP 势函数的记录如图 10 所示。

图10 1小时内GPU利用率监控（使用GPU共享）

在这段时间内，该节点的两块 GPU 设备利用率均稳定在 93%左右，可以看出在 Volcano 的调度下，可以使得 Pod 能够充分地调用 GPU 资源进行 LAMMPS 模拟加速。

计划与展望

本文通过利用批量容器调度器，使得容器批量调度器能够极大地促进材料模拟和深度学习两种计算场景的结合。虽然本文的案例在材料模拟领域比较典型，但是在例如智能医疗、药物设计、高能物理、大气模拟、天文学数据处理等其他领域，此解决方案的适用性还有待研究，如果将各个领域中的典型应用都纳入到此解决方案中进行批量容器计算，将会使得容器技术与高性能计算和人工智能进一步融合。另外本文结束后将会继续模拟更大的体系，以及扩大计算资源的规模，深入到大型超算系统的应用场景中。

【与云原生的故事】有奖征文火热进行中：https://bbs.huaweicloud.com/blogs/345260

云原生 云端实践

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。