CN115102851B - 一种面向hpc与ai融合计算的融合平台及其资源管理方法 - Google Patents

Abstract

本发明涉及融合计算系统领域，公开了一种面向HPC与AI融合计算的融合平台及其资源管理方法，使用容器化的方法将Slurm平台融合到Kubernetes平台中得到融合平台，并通过资源管理方法对融合平台的HPC集群和AI集群资源进行分配；融合平台包括客户端、控制节点、计算节点；在HPC集群和AI集群运行时，如果需要计算节点X的资源配置，通过所述的资源管理方法实现资源的重分配，改善了现有的融合平台中集群资源隔离和浪费问题，提高了集群平均资源利用率。

Description

一种面向HPC与AI融合计算的融合平台及其资源管理方法

技术领域

本发明涉及融合计算系统领域，具体涉及一种面向HPC与AI融合计算的融合平台及其资源管理方法。

背景技术

近些年AI训练对计算能力的需求日益，从AlexNet到AlphaGoZero计算量上增长了30万倍。而HPC可以给AI计算提供算力支持。另一方面，AI模型在材料科学、生命科学和大气海洋等HPC应用领域发挥越来越重要的作用，推动HPC计算领域的科学发现，帮助人们进一步理解科学问题。因此，HPC和AI的融合需求愈发强烈。

高性能计算（High Performance Computing，HPC）和AI两个集群的资源管理是融合必须考虑的问题。新华三和英特尔分别提出了各自的HPC-AI融合平台产品，在解决资源管理问题上，它们都将物理机集群以节点为单位划分为HPC分区和AI分区。但是本质上资源还是隔离的，当使用通用计算节点时，会有两类原因造成节点计算资源的浪费：

第一类是由于某段时间内任务提交量少，即集群工作存在闲时造成的资源浪费。

第二类是由于通用计算节点无法应对HPC与AI资源需求差异造成的资源浪费，HPC与AI资源需求差异主要是由其应用场景差异造成的。

传统的高性能计算，核心操作是各类方程组的求解计算，以CPU计算为核心。多数HPC的资源管理器采用排他的方法进行资源的调度即当有CPU作业占用节点资源时，会存在空闲的GPU无法被调度，导致GPU资源的浪费。

另外AI训练过程是一种典型的计算密集型应用，AI资源调度以GPU为核心，相对更强调GPU的公平性、亲和性和利用率，将导致CPU资源的浪费。

发明内容

为解决上述技术问题，本发明提供一种面向HPC与AI融合计算的融合平台及其资源管理方法。

为解决上述技术问题，本发明采用如下技术方案：

一种面向HPC与AI融合计算的融合平台，使用容器化的方法将Slurm平台融合到Kubernetes平台中，融合平台包括：

客户端，供用户提交计算任务；

控制节点，运行有Kubernetes平台的各控制组件，以及除节点监控进程slurmd外的Slurm平台的各控制组件；

计算节点，包括属于HPC集群的pod单元A和属于AI集群的pod单元B，pod单元A内的资源属于HPC集群，pod单元B内的资源属于AI集群；HPC集群的节点监控进程slurmd以容器形式运行在pod单元A中；事实上，不仅pod单元B内的资源属于AI集群，pod单元A外的资源均属于AI集群。

一种面向HPC与AI融合计算的融合平台的资源管理方法，对融合平台的HPC集群和AI集群资源进行分配，在HPC集群和AI集群运行时，如果需要调整计算节点X的资源配置，通过所述的资源管理方法实现资源的重分配，包括以下步骤：

步骤一：修改计算节点X的资源配置，并在计算节点X内pod单元A重启前使资源配置生效；

步骤二：判断重启pod单元A时计算节点X内是否有足够资源；如是，运行步骤三；如否，运行步骤四；

步骤三：为计算节点X设置NoSchedule污点；

步骤四：为计算节点X设置NoExecute污点；

步骤五：删除pod单元A后重启pod单元A；HPC集群和重启后的节点监控进程slurmd建立连接后，删除计算节点X上的污点。

具体地，当HPC集群对应的计算节点X失联时，计算节点X上运行的任务会从running状态转为pending状态，加入任务队列重新调度；步骤五中在pod单元A删除前需要记录计算节点X内运行的HPC任务，在pod单元A重启后，若HPC任务仍在pending状态，则将该HPC任务放到任务队列队首；

当AI集群对应的计算节点X无法执行任务时，即当AI集群对应的计算节点X内的pod单元B无法自动重启时，根据需要重启AI任务。

具体地，步骤四中为计算节点X设置NoExecute污点前，判断计算节点X内是否有需要手动重启的pod单元B；如有，则需要备份pod单元B的资源配置文件。

与现有技术相比，本发明的有益技术效果是：

本发明改善了现有的融合平台中集群资源隔离和浪费问题，提高了集群平均资源利用率，尤其是cpu和gpu资源，进一步推进了HPC-AI融合平台资源的融合。另外，本发明中Slurm平台的容器化可以实现Slurm平台的快速部署，且计算节点中只需要配置Kubernetes平台，减少了节点的维护成本。

附图说明

图1为本发明融合平台整体架构图；

图2为本发明融合平台构建流程图；

图3为本发明slurmd镜像创建流程图；

图4为本发明pod单元A的资源配置文件结构图；

图5为本发明资源管理方法的流程图；

图6为本发明与对照组的集群资源利用率对比图。

具体实施方式

下面结合附图对本发明的一种优选实施方式作详细的说明。

现有的融合平台中HPC集群和AI集群的资源往往是隔离的，并且资源的划分粒度是节点，在面对HPC任务和AI任务的资源需求差异时会有资源浪费现象产生。

为应对以上问题，本发明设计了一种面向HPC与AI融合计算的融合平台及其资源管理方法，以打通HPC集群和AI集群之间的资源隔离，实现资源的统一管理并进一步细化集群资源的划分粒度。

本发明基于Kubernetes平台和Slurm平台，并使用容器化的方法将Slurm平台融合到Kubernetes平台中，并为融合后的平台设计了集群资源的资源管理方法。

1.名词解释

1.1Docker(容器虚拟化技术)：

虚拟机是移植环境的一种解决方案。虚拟机本质上也是一个软件，在这个软件中，可以运行另一种操作系统。但是虚拟机有几个缺点：占用资源多、运行步骤复杂、运行速度慢。为了解决虚拟机存在的这些缺点，Linux发展出了另一种虚拟化的技术：Linux容器。Linux 容器不是模拟一个完整的操作系统，而是对进程进行隔离，或者说，就是在正常进程的外面套用了一个保护层。对于容器里面的进程来说，它接触到的各种资源都是虚拟的，从而实现与底层程序的隔离。由于容器是进程级别的，相比虚拟机有更多优势：

占有资源少：容器只占用需要的资源，相比于虚拟机安装完整的操作系统，容器需要消耗的空间自然就少了很多；

资源利用率高：虚拟机都是独享资源，电脑需要为每个虚拟环境单独分配资源，不仅仅占用空间大，而且资源的利用率很低。而容器之间可以共享资源，最大化资源的利用率；

运行速度快：容器里面的应用就是底层系统的一个进程，所以启动容器相当于直接运行本机的一个进程，而不是一个完整并臃肿的操作系统，自然就快很多。

Docker属于Linux容器的一种封装，提供简单易用的容器使用接口，它也是目前最流行的Linux容器解决方案。Docker 将软件代码及其依赖的组件，全打包在一个文件中。运行单个文件，就会生成虚拟容器。在这个虚拟容器中，不管本地的操作系统是如何的不同，此容器都能照常运行。

1.2 Kubernetes平台：

Kubernetes平台是基于容器（通常是Docker）的容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。Kubernetes平台适合大型分布式计算环境，由于其容器化技术以及声明式设计，故将计算资源应用于工作负载很容易。而通常在AI工作负载中，工程师或研究人员需要分配更多的资源，而Kubernetes让在物理基础架构之间迁移工作负载更加可行。因此Kubernetes平台往往被选为AI集群的管理平台。

Kubernetes平台是基于主从（master-Slaver）模型的系统，master节点负责整个集群的调度管理工作，不负责应用的运行。在Kubernetes中，master节点可以简称为master，Slave节点可以简称为node。pod单元是Kubernetes平台创建或部署的最小或者最简单的基本单位，一个pod单元代表集群上正在运行的一个进程。一个pod单元封装一个或者多个应用容器。

1.3 Slurm平台：

Slurm（Simple Linux Utility for Resource Management）平台是一种可用于大型计算节点集群的高度可伸缩和容错的集群管理器和作业调度系统，是HPC集群广泛使用的管理平台。

Slurm平台维护着一个待处理工作的队列并管理此工作的整体资源利用。它以一种共享或非共享的方式管理可用的计算节点（取决于资源的需求），以供用户执行工作。Slurm平台会为任务队列合理地分配资源，并监视作业至其完成。

控制进程slurmctld (Slurm central daemon)：负责监视集群中每个节点的状态，周期性地检查节点监控进程slurmd的信息；依据节点和分区的状态为作业分配分区；接受用户的作业请求，并根据调度算法和优先级决定是否对作业执行挂起、执行、完成等操作。

节点监控进程slurmd(Slurm local daemon)：周期性地向控制进程slurmctld反馈节点和作业的状态信息；在slurmctld指定完任务后，对该任务执行开始、监视和清除操作。

2.整体架构

图1为融合平台整体架构图，融合平台分为三个部分：客户端、控制节点、计算节点。

控制节点中运行Kubernetes平台的控制组件APIServer、调度器（Scheduler）、控制器管理组件（controller manager）和数据库ETCD，以及Slurm平台的控制组件：控制进程slurmctld进程、记账存储进程slurmdbd和数据库Mysql。此处要注意，虽然Slurm平台可以在控制节点中进行计算，即在控制节点中运行节点监控进程slurmd，但是Kubernetes平台中控制节点是不进行计算任务的，因此在控制节点上不启动节点监控进程slurmd，相应的需要在Slurm平台的配置文件slurm.conf中将控制节点的计算功能关闭。

计算节点中运行了Kubernetes平台的相关组件，其中核心为pod单元的管理组件kubelet，它负责监视管理pod单元，pod单元包括pod单元A（也称为slurm-pod）和pod单元B，其中pod单元B可以是0个，也可以是多个，节点监控进程slurmd以容器的形式运行在pod单元A中。计算节点的资源因此分为两份，pod单元A内资源为HPC集群的资源，其余资源为AI集群的资源。节点监控进程slurmd以容器的形式运行在kubelet监视管理的pod单元A中，即通过Kubernetes平台就可以监视管理HPC集群各计算节点的资源，实现了HPC集群和AI集群资源的统一管理。

任务的调度是隔离的，应用从客户端提交至融合平台，由融合平台判断任务类型。AI任务的调度由控制节点中的调度器（Scheduler）负责，HPC任务的调度由控制节点中的控制进程slurmctld负责。另外，节点监控进程slurmd与控制进程slurmctld是进行直接通信的，即越过了pod单元管理组件kubelet和控制节点中的控制组件APIServer。

3.融合平台构建

融合平台构建流程如图2所示。在安装和部署了Docker及Kubernetes平台之后，开始Slurm平台的容器化，关键步骤如下：

3.1镜像创建

创建slurmd容器，要先构建能够实现节点监控进程slurmd功能的镜像，镜像需要考虑到两个功能：与控制进程slurmctld及其他节点监控进程slurmd通信的功能；节点监控进程slurmd自身所需的计算功能。

Slurm平台的通信基于munge。munge是认证服务，用于生成和验证证书，应用于大规模的HPC集群中。munge允许进程在具有公用的用户和组的主机组中，对另外一个本地或者远程的进程的UID和GID进行身份验证。即在集群中，munge能够实现本地或者远程主机进程的GID和UID验证。

节点监控进程slurmd的计算功能则可由完整的slurm安装包涵盖，如果计算任务需要特定的任务环境，比如需要python环境及相应的库，则需要另外安装。

镜像的创建流程如图3所示，镜像名称为slurmd：

选定基础镜像为centos7，也可以根据应用场景更换基础镜像；

安装munge，配置munge；

安装Slurm平台及所需依赖，配置Slurm平台；

任务计算相关安装（如python）。

3.2pod及容器配置

Pod单元是Kubernetes平台的最小单位，里面包含一组容器，其中一个为Pause容器。本发明中创建名为slurm-node的pod单元A，其中除了Pause容器只有slurmd容器，pod单元A的资源配置文件结构如图4所示。

pod单元A配置：

pod单元A名称设置为slurm-node-X，其中node-X为对应计算节点的编号，如pod单元A（slurm-node-1）部署在计算节点node-1上。本发明中一个计算节点对应于一个pod单元A（slurm-node）。

除了pod单元A的名称，首先要考虑，Slurm平台建立通信需要各计算节点名称及IP地址与Slurm平台的配置文件slurm.conf中一致。为了使节点监控进程slurmd稳定部署到与配置一致的节点上，需要使用pod单元A资源配置文件中的节点选择器（nodeSelector）字段，给及计算节点打上相应的标签Label（例nodename: node-1）。IP地址则使用（hostNetwork）字段，当hostNetwork: true时，可以使pod单元A拥有和宿主机一致的IP地址。

容器的配置：

容器名称为slurmd，镜像选择为上述创建的镜像slurmd。

端口配置：

为了保证Slurm平台正常使用，容器需要配置两个特定的端口，两个端口分别为slurmctldport和slurmdport，slurmctldport实现与控制进程slurmctld的交互实现slurmctld服务，slurmdport实现与节点监控进程slurmd的交互实现slurmd服务。两个端口的配置需要与Slurm平台的配置文件slurm.conf中一致（如slurmctldport：6817、slurmdport：6818）。

存储挂载：

每个slurmd容器都需要有与整个Slurm平台一致的配置文件（hosts，slurm.conf，munge.key）。另外，需要保存每个slurmd容器临时的计算数据。

在pod单元A的资源配置文件之外，需要先通过NFS服务创建集群的共享文件夹，共享文件夹下创建两个子文件夹：configure，用于存放集群的配置文件；data，用于存放节点的临时计算数据。使用Kubernetes平台创建对应的PV（PersistentVolume，持久化卷）和PVC（PersistentVolume controller ，持久化卷控制器）。

pod单元A的资源配置文件中，Kubernetes平台存储卷挂载需要使用存储挂载字段（volumeMounts）和存储卷字段（volumes）两个字段来实现共享文件夹的挂载。

资源配置：

容器的资源配置需要满足与Slurm平台配置文件中计算节点的资源配置一致。容器的资源配置使用资源字段（resources）包括需求字段（requests）和限制字段（limits），其中需求字段（requests），保证被调度的计算节点上至少有的资源配额；限制字段（limits），容器可以分配到的最大资源配额。为了保证计算节点给予slurmd容器的资源后，slurmd容器内的资源不可以超过资源的限制，并且在slurmd容器资源空闲时，Kubernetes平台其他pod单元，也不能占用slurmd的资源，此处需要将需求字段（requests）和限制字段（limits）的值设置为相同的。

另外，在slurmd容器处理任务时会在sys/fs/crgoup/freezer下创建slurm的cgroup，用于挂起或者恢复cgroups中Slurm平台作业步守护进程slurmstepd。在Kubernetes平台默认策略中容器是没有创建cgroup的权限。此处使用Security context字段，当privileged: true时，可以时容器具有宿主机文件系统的权限以此来创建cgroup。

命令设置：

复制挂载的共享文件夹中的配置文件至对应的文件夹；启动munged进程和slurmd进程。

3.3 HPC集群部署

在控制节点中启动控制进程slurmctld和记账存储进程slurmdbd后，依次创建对应各计算节点的pod单元A，HPC集群即可部署完成。

4.资源管理方法

本发明设计了一个资源管理方法，在HPC-AI集群运行时，当有集群资源调整的需求时实现资源池的在线重分配。图5为资源管理方法的流程图；资源管理方法伪代码如下：

Input: 待调整节点Node，调整后资源值R={x₁,x₂,...,x_N}(cpu、gpu、内存...)；

1：open slurm.conf , Node’s slurm resource <= R //修改slurm.conf文件；

2：if Node satisfy(Node’s slurm resource) then

3： set Node’s taint : NoSchedule；

4：else

5： if flag <= any pod in Node needs manually reboot then

6： record the yaml of pod；

7： end if；

8： set Node’s taint : NoExecute；

9：end if；

10：J <= slurmjob in the Node //记录slurmjob；

11：delete the slurm-pod；

12：open slurm-pod.yaml , slurm-pod’s resource <=R //修改yaml文件；

13：slurm reconfig //配置文件生效；

14：top J //修改重启slurmjob的优先级；

15：create slurm-pod , delete Node’s taint //重启slurm-pod，删除污点；

16：if flag then

17： reboot pod by recorded yaml , top pod；

18：end if。

4.1配置文件修改

通过Slurm平台的配置文件slurm.conf修改对应计算节点的资源配置。在pod单元A重启前需要使用Slurm平台中的scontrol reconfig命令使新的配置文件生效。

修改资源调整的计算节点对应的pod单元A资源配置文件，根据重启pod单元A时计算节点内是否有足够的资源，有两种处理方式：

如果在计算节点不驱逐已有pod单元的情况下能满足容器调整后的资源需求，则只需要保证在pod单元进行配置资源调整及重启pod单元期间，该计算节点不能再调度其他pod单元所占用的资源，即给该计算节点打上污点（taint），属性为NoSchedule，可以使该计算节点暂时不调度pod单元，再给pod单元A打上相应的容忍；

如果在计算节点不驱逐已有pod单元的情况下不能满足容器调整后的资源需求，则需要驱逐计算节点中运行的pod单元，即给该计算节点打上污点（taint），属性为NoExecute，可以使该计算节点驱逐运行中的pod单元且暂时不调度pod单元，再给pod单元A打上相应的容忍。当驱逐pod单元没有相应的控制器或Job对象维护时，需要在资源调整后手动重启，则在打污点前需要记录有手动重启需求的pod单元B的资源配置文件以便之后重启。

计算节点上的污点需要等待Slurm平台和重启后的节点监控进程slurmd建立连接后再删除。

4.2任务的重启：

Slurm平台中当计算节点失联时，计算节点上运行的任务会从running状态转为pending状态，加入任务队列重新调度。因此在pod单元A删除前需要记录节点内运行的HPC任务，在pod单元A重启后，若这些任务仍在pending状态则将其放到任务队列队首。

pod单元B单元的资源配置文件中，如果记录有手动重启需求，则重启AI任务。

5.实施例

平台部署：

假设一个物理机集群，集群中有1个控制节点master和2个计算节点node-1、node-2。其中node-1：48cpu、2gpu；node-2：48cpu、1gpu。

在master和node-1，node-2上安装Docker、Kubernetes，并部署Kubernetes平台，即完成了AI集群的部署。

在master中安装并部署Slurm平台，注意在写slurm配置文件slurm.conf时，需要先将node-1和node-2的配置设置完成，例如slurm-node-1：24cpu、1gpu；slurm-node-2：24cpu、0gpu。之后按照本发明中的方法构建slurmd镜像，并在Kubernetes平台中创建并部署对应的pod单元A，完成HPC集群的部署。

任务提交：

融合平台部署完成后，用户可以提交计算任务，任务从客户端提交至融合平台，融合平台判断任务类型并提交至对应集群。

资源监控：

AI集群和HPC集群的资源使用情况都可以通过Kubernetes平台获取。例如使用Kubernetes平台的资源监控插件Prometheus得到node-1的cpu利用率50%，node-2的cpu利用率30%，slurm-node-1的cpu利用率60%，pod单元A（slurm-node-2）的cpu利用率50%，则可以简单计算出AI集群cpu利用率25%，HPC集群cpu利用率55%。

资源调整：

当需要进行集群资源调整时，调用本发明设计的资源管理方法，例如，函数输入节点为node-1，资源R={40，2}（cpu，gpu）。则在资源调整结束后slurm-node-1有40cpu和2gpu，且HPC任务和AI任务都运行正常，包括驱逐的pod单元。

当向融合平台输入合理的资源值时，本发明中的资源管理方法能够有效提高资源利用率，所以本发明可以配合机器学习或其他方法优化集群资源利用率。图6为在仿真实验中资源管理方法配合深度强化学习时融合平台的集群平均资源利用率，对照组为资源隔离的集群资源利用率。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内，不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立技术方案，说明书的这种叙述方式仅仅是为了清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (4)

1.一种面向HPC与AI融合计算的融合平台，使用容器化的方法将Slurm平台融合到Kubernetes平台中，其特征在于，融合平台包括：

客户端，供用户提交HPC任务和AI任务；

控制节点，运行有Kubernetes平台的各控制组件，以及除节点监控进程slurmd外的Slurm平台的各控制组件；

计算节点，包括属于HPC集群的pod单元A和属于AI集群的pod单元B，pod单元A内的资源属于HPC集群，pod单元B内的资源属于AI集群；HPC集群的节点监控进程slurmd以容器形式运行在pod单元A中。

2.一种如权利要求1所述的面向HPC与AI融合计算的融合平台的资源管理方法，对融合平台的HPC集群和AI集群资源进行分配，其特征在于：在HPC集群和AI集群运行时，如果需要调整计算节点X的资源配置，通过所述的资源管理方法实现资源的重分配，包括以下步骤：

步骤一：修改计算节点X的资源配置，并在计算节点X内pod单元A重启前使资源配置生效；

步骤二：判断重启pod单元A时计算节点X内是否有足够资源；如是，运行步骤三；如否，运行步骤四；

步骤三：为计算节点X设置NoSchedule污点；

步骤四：为计算节点X设置NoExecute污点；

步骤五：删除pod单元A后重启pod单元A；HPC集群和重启后的节点监控进程slurmd建立连接后，删除计算节点X上的污点。

3.根据权利要求2所述的面向HPC与AI融合计算的融合平台的资源管理方法，其特征在于：当HPC集群对应的计算节点X失联时，计算节点X上运行的任务会从running状态转为pending状态，加入任务队列重新调度；步骤五中在pod单元A删除前需要记录计算节点X内运行的HPC任务，在pod单元A重启后，若HPC任务仍在pending状态，则将该HPC任务放到任务队列队首；

当AI集群对应的计算节点X无法执行任务时，根据需要重启AI任务。

4.根据权利要求2所述的面向HPC与AI融合计算的融合平台的资源管理方法，其特征在于：步骤四中为计算节点X设置NoExecute污点前，判断计算节点X内是否有需要手动重启的pod单元B；如有，则需要备份pod单元B的资源配置文件。

Images