基于YARN的面向GPGPU集的资源管理调度方法

本发明属于计算机集的资源管理技术领域，具体地涉及一种基于 YARN的面向GPGPU集的资源管理调度方法。

GPU英文全称Graphic Processing Unit，中文翻译为“图形处理器”。 GPU是相对于CPU的一个概念，由于在现代的计算机中(特别是家用系统， 游戏的发烧友)图形的处理变得越来越重要，需要一个专门的图形的核心 处理器。GPU是显示卡的“心脏”，也就相当于CPU在电脑中的作用，它决 定了该显卡的档次和大部分性能，现在市场上的显卡大多采用NVIDIA和 ATI两家公司的图形处理芯片。

今天，GPU已经不再局限于3D图形处理了，GPU通用计算技术发展已经 引起业界不少的关注，事实也证明在浮点运算、并行计算等部分计算方面， GPU可以提供数十倍乃至于上百倍于CPU的性能，所谓GPGPU。

GPGPU全称General Purpose GPU，即通用计算图形处理器。其中第一 个“GP”通用目的(GeneralPurpose)而第二个“GP”则表示图形处理 (GraphicProcess)，这两个“GP”搭配起来即“通用图形处理”。再加 上“U”(Unit)就成为了完整的通用处理器。人们一直在寻各种加速图 像处理的方法，然而受到CPU本身在浮点计算能力上的限制，对于那些需 要高密度计算的图像处理操作，过去传统的在CPU上实现的方法，并没有 在处理性能与效率上有很大进步。随着可编程图形处理器单元(GPU)在性 能上的飞速发展，利用GPU加速图像处理的技术逐渐成为研究热点。

与此同时，随着Open CL、CUDA等GPU通用计算标准的成熟和发展，GPU 的通用计算得到极大的发展，但是，由于GPU涉及到的通常是高密度的庞 大的计算量，一般很难在可接受的时间内完成，这样，GPU集应运而生。

基于Hadoop的GPU并行化或集，有过很多工作，例如Mars、MapCG、 SkePU等，但是这些工作多是针对一个GPU或单节点多GPU的Map-Reduce并 行化，在一定程度上实现了多核GPU和GPU混合平台下的并行计算。基本上 是结合GPU多线程并行计算的特性，将GPU多线程的编程模式实现 MapReduce过程，没有将GPU和Hadoop集真正结合。

而且这些工作多是基于第一代Hadoop的实现，没有采用第二代Hadoop 的YARN，很难构建真正的GPU弹性计算集。

YARN是一种新的Hadoop资源管理器，相对Hadoop1.0，它将资源管 理从计算框架中分离出来，变成一个通用资源管理系统，可为上层应用提 供统一的资源管理和调度，它的引入为集在利用率、资源统一管理和数 据共享等方面带来了巨大好处。

Hadoop原生YARN负责Hadoop的资源管理的架构图如图1所示，由资源 管理(Resource Manager or RM)，节点管理(NodeManager or NM)， Application Master(AM)以及容器(Container)等组成，原生YARN缺少 对GPU的资源管理。

YARN从某种那个意义上来说应该算做是一个云操作系统，它负责集 的资源管理。在操作系统之上可以开发各类的应用程序，例如批处理 MapReduce、流式作业Storm以及实时型服务Storm等。这些应用可以同时 利用Hadoop集的计算能力和丰富的数据存储模型，共享同一个Hadoop集 和驻留在集上的数据。此外，这些新的框架还可以利用YARN的资源管 理器，提供新的应用管理器实现。

当前的YARN系统支持CPU、内存等常见资源的管理和分配，但是不能 支持GPU资源的管理和分配。

针对上述技术问题，本发明旨在提供一种基于YARN的面向GPGPU 集的资源管理调度方法。改进了YARN资源模型、发明了GPU应用管 理器、在此基础上实现了集对GPU的统一调度，管理，实现了弹性的 GPU集。

为达到上述目的，本发明的技术方案是：

一种基于YARN的面向GPGPU集的资源管理调度方法，其特征在于， 包括以下步骤：

S01：节点管理器通过周期心跳向资源管理器报告节点信息；

S02：资源管理器应答节点管理器，触发调度器的NODE_UPDATE事件；

S03：调度器根据调度策略在节点上分配容器，把分配完成的容器报 告给资源管理器，并添加到资源分配列表；所述调度策略为GPU资源不超 额分配，零GPU资源仍继续CPU和内存的分配；

S04：GPU应用程序的GPU应用程序管理器向资源管理器发送心跳；

S05：资源管理器接受心跳，更新资源申请列表，并将所述列表中GPU 应用程序的容器应答给GPU应用程序管理器；

S06：GPU应用程序管理器获取容器并作双层调度中的第二层调度；

S07：将除GPU之外的资源的应用程序管理器向资源管理器发送心跳；

S08：资源管理器接受心跳，更新资源申请列表，并将列表中除GPU 之外的资源的容器应答给资源管理器。

优选的，用多元组表示资源，或， 表示x个CPU，y GB内存和z个GPU的资源。

优选的，所述步骤S03中GPU资源的辨识和绑定包括如下步骤：

S11：节点管理器维护节点上所有设备的运行状态信息；

S12：使用哈希表表示当前时间GPU设备与容器之间的对应关系，所 述哈希表为gpu_info＝Map；

S13：当有新的容器启动时，从哈希表中选取空闲设备与其绑定。

优选的，GpuClient提供用户和YARN交互的接口，交互应用程序、 应用程序状态、属性；通信步骤如下：

S21：初始化并获取GPU应用程序ID；

S22：设置GPU应用程序管理器运行环境，包括环境变量、命令、参 数、资源；

S23：提交gpuApplion Master到资源管理器；

S24：周期性获取GPU应用程序管理器的状态，并在异常时做异常处 理或结束时退出程序。

优选的，GPU应用程序管理器用于向资源管理器通信申请资源，与节 点管理器交互来启动和监控任务，对GPU资源进行二次分配。

优选的，所述GPU应用程序管理器用于实现容器的启动和回收；包括 以下步骤：

S31：GPU应用程序管理器接受到新的容器后，向节点管理器请求启动 容器，并发送启动容器所需的信息，包括启动命令、环境变量、参数、各 种资源等尤其GPU资源；节点管理器负责执行容器指定的命令；同时，GPU 应用程序向资源管理器继续后续任务的资源申请，这两个过程不断进行直 到所有任务分配完成；

S32：容器启动后，节点管理器通知GPU应用程序管理器，GPU应用程 序开始检测启动的容器的状态并维护，收集信息判断程序是否完成。

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

本发明改进了YARN资源模型、发明了GPU应用管理器、在此基础上 实现了集对GPU的统一调度，管理，实现了弹性的GPU集。

图1为现有YARN的架构图；

图2为本发明基于YARN的GPU集的资源管理的架构图；

图3为本发明基于YARN的面向GPGPU集的资源管理调度方法流 程图；

图4为gpuClient通信流程图。

为使本发明的目的、技术方案和优点更加清楚明了，下面结合具体实 施方式以及附图，对本发明进一步详细说明。应该理解，这些描述只是示 例性的，而并非要限制本发明的范围。此外，在以下说明中，省略了对公 知结构和技术的描述，以避免不必要地混淆本发明的概念。

实施例：

如图2所示，本发明的GPU集基于对原生YARN框架的改进，发明 了GPU的集管理方法，使GPU资源在集层可见、可管理、可调度。

本发明的YARN系统支持CPU(X86、ARM等)、内存和GPU(本阀门以 NVIDIA的GPU和相应的CUDA编程框架为例，但本发明不限于NVIDIA的 GPU)。

CPU和内存的分别是”yarn.nodemanager.resource.memory-mb”和” yarn.nodemanager.resource.cpu-vcores”，和原生的YARN一致，但是需 要增加对GPU资源的表示。

在YARN中增加GPU类型和数量的表示，例如 “yarn.nodemanager.resource.gpu-type”表示GPU的种类， “yarn.nodemanager.reosurce.gpu-ngpgpu”表示本节点上的物理可用的 通用GPU的数量，缺省是0.

针对GPU不同CPU特点，(下面都以Nvidia和CUDA为例)，GPU一次只 能运行一个CUDA程序，相应设计了GPU的状态列表，能表示单机单开、 单机多卡等复杂GPU环境、并在CUDA任务启动时表示GPU设备动态绑定 信息。

最终用多元组表示资源，例如或，表 示x个CPU，y GB内存和z个GPU的资源。将一般的二维由CPU和内存 组成的二元组扩成多样组，以支持GPU。

资源调度模型

A)双层调度框架

资源管理器Resource Manager将资源分配给应用程序/GPU应用程序 管理器Application/gpuApplication manager； Application/gpuApplication manager将资源进一步分配给各个任务 Task。

B)基于资源预留的调度

如图3所示，调度策略过程如下：

1.节点管理器Node Manager通过周期心跳向Resource Manager报告 节点Node的信息，含GPU信息，例如GPU卡种类、数量等；

2.Resource Manager应答Node Manager；

3.Resource Manager触发调度器Scheduler的NODE_UPDATE事件；

4.Scheduler根据调度策略(下面第四节内容会详述)在Node上分配 容器Container；

5.Scheduler把分配完成的Container报告给Resource Manger，并 添加到资源分配列表；

6.GPU应用程序的GPU应用程序管理器gpuApplication Master向 Resource Manager发送心跳；

7.Resource Manager接受心跳，更新资源申请列表，并将列表中属于 6中GPU应用程序的Container应答给gpuApplication Master；

8.gpuApplication Master获取Container并做上述双层调度中的第 二层调度；

6’，7’，8’与上述6，7，8类似，是不含GPU资源的分配过程。

YARN原有的开源资源调度不适合GPU调度，原有的实现允许资源列表 超额一次，本发明实现GPU资源不超额分配，零GPU资源仍继续CPU 和内存的分配，如下表：

资源上限 分配资源需求 剩余资源 能否继续分配

<12，24，3> <3，12，3> <9，12，0> 能

<9，12，0> <1，4，1> <8，8，-1> 不能

<8，8，-1> <4，4，0> <4，4，-1> 不能

(1)本发明资源调度能够完成CPU、内存和GPU的调度，原生 YARN自带三种调度器，包括FlFO，Capacity scheduler和Fair Scheduler，但是它们不支持GPU的调度。本发明改进了这三种调度器， 当GPU资源第一次不足时，不做GPU资源超额分配；当GPU资源是零 时，而CPU、内存资源的分配继续，不受其中GPU资源是零的影响。它 们都能够支持GPU的调度。

下面以Fair Scheduler的主资源公平调度(Dominant Resource Fairness，DRF)为例，举例说明DRF的调度过程，其他调度策略类似需 要对GPU做处理。

假设系统总资源是<12CPU，24GB，3GPU>，有A、B两个用户， 它们的每个任务资源需求是<1CPU，3GB，0GPU>和<2CPU，2GB，1 GPU>，则A的主资源是内存，B的主资源是GPU。DRF的分配过程如下 表：

下面描述第三节资源调度模型中步骤4的执行Container过程。

原生YARN的Container不支持GPU，本发明为了支持GPU，为了 克服两个技术问题：(1)YARN资源模型不具备区分同一个node下相同 资源的不同设备的能力，(2)GPU一次只能运行一个任务。本发明采用了 动态绑定的方法，如下：

一)节点管理器维护节点上所有设备的运行状态信息；实现方式可 以采用下面的哈希表，但不限制于此方法。

二)gpu_info＝Map；该 哈希表表示了当前时间GPU设备与Container之间的对应关系。

三)当有新的Container启动时，从gpu_info中选取空闲GPU和 container动态绑定，达到GPU资源在集上的可管理。

gpuClient

为了GPU程序在我们的YARN集上运行，本专利发明了集上的 GPU的运行环境，主要由gpuClient和gpuApplication Master组成。非 GPU的应用仍采用原生的Client和Application Master。

GpuClient提供用户和YARN交互的接口，交互应用程序、应用程序 状态、属性等，通信协议是gpuClient和Resource Manager的RPC协议。 其流程见图4，步骤如下：

1.初始化并获取GPU应用程序gpuApplication ID；

2.设置gpuApplication Master运行环境，包括环境变量、命令、参 数、资源等；

3.提交gpuApplion Master到Resource Manager。

周期获取gpuApplication Master的状态，并在异常时做异常处理或 结束时退出程序。

gpuApplication Master一方面与Resource Manager通信申请资源， 尤其GPU资源，一方面与Node Manager交互来启动和监控task等，另 外还有资源尤其GPU资源的二次分配等。非GPU有关的应用仍采用原生 的Application Master。

gpuApplication Master是针对计算密集型的GPU应用的程序控制 器，主要有container的启动和回收过程。对应图3过程5。

(一)gpuApplication Master接受到新的Container后，向Node Manager请求启动Container，并发送启动Container所需的信息，包括 启动命令、环境变量、参数、各种资源等尤其GPU资源；节点管理器负 责执行Container指定的命令；同时，gpuApplication向Resource Manger 继续后续任务的资源申请，这两个过程不断进行直到所有任务分配完成。

Container启动后，Node Manager通知gpuApplicatoin Master， gpuApplication开始检测启动的Container的状态并维护，收集信息判断 程序是否完成等。应当理解的是，本发明的上述具体实施方式仅仅用于示 例性说明或解释本发明的原理，而不构成对本发明的限制。因此，在不偏 离本发明的精神和范围的情况下所做的任何修改、等同替换、改进等，均 应包含在本发明的保护范围之内。此外，本发明所附权利要求旨在涵盖落 入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变 化和修改例。