[发明专利]面向分布式编程框架的资源管理系统

说明书

技术领域

本发明涉及计算机领域，尤其涉及一种面向分布式编程框架的资源管理系统。

背景技术

并行计算依赖于大规模的集群，并行计算的火热推动了集群管理系统的发展，面向并行计算的集群管理系统开始出现，比如LSF（Load Sharing Facility,负载共享设施）系统、PBS（Protable Batch System,可移植批处理作业系统）系统等。这些系统都是面向并行计算，处理传统的批处理作业，管理集群资源，广泛应用于工业生产和科研环境中。随着分布式计算的兴起，各种新型并行编程框架的不断涌现，传统的集群管理系统因其本身系统设计与结构等方面的原因，无法良好的支持新型编程框架，更无法支持多编程框架共存于集群中的资源管理问题。面向多编程框架的集群资源管理是最近才出现的研究课题。下面列举3个有代表性的可支持多编程框架的集群资源管理系统：

1)计算密集型批处理作业管理系统Condor

Condor是威斯康辛大学开发的处理计算密集型作业的批处理系统。它的架构为典型的主-从（master-slave）结构，Condor的master主要由收集器（collector)和导航器(negotiator)组成，开启器（startd）是每个执行机器上都有的守护进程，相当于从部分，开启器负责启动任务，并定时上报机器的资源信息给收集器。开启器是每个提交作业的机器上都存在的调度器进程，负责接收用户作业，将任务匹配请求发送给收集器。导航器完成作业资源请求与机器的匹配工作，从而将作业分发给合适的机器，由开启器启动任务。

对于编程框架的支持，Condor实现了一套管理-工作者(master-worker)结构的框架，简称为MW框架。MW框架提供了一些基类，通过继承这三个基类，用户可以编写自己的框架。Condor支持编程框架的本质是提供了一套开发编程框架的API（Application Programming Interface，应用程序编程接口），用户通过这套API可以开发出一个编程框架，因此Condor要支持已有的编程框架非常麻烦。资源虚拟化方面，Condor本身并没有对任何的资源虚拟化方案管理资源，因此多个框架之间会产生资源竞争，互相影响。总体而言，Condor在兼容现有的编程框架上存在困难，并且没有提供任何虚拟化的技术，使得多编程框架共享集群存在困难。

2)动态资源管理系统Mesos

Mesos是Berkeley大学实现的数据中心资源共享管理平台，负责为上层计算框架分配资源。Mesos的本质思想是集群复用。相比于传统的资源管理系统，Mesos从不同的资源视角对集群资源管理进行了抽象。Mesos通过与框架的调度器的通信完成资源分配的交互。

编程框架要运行于Mesos之上，必须要在编程框架的主部分中增加与Mesos的交互模块。Mesos提供了一套资源-提供（resource-offer）机制与编程框架的master交互。编程框架的主部分在基于资源-提供机制提供的API接收或者拒绝Mesos推送的资源，包括CPU和内存。因此对编程框架而言，需要进行大量的内部逻辑修改，对编程框架使用人员而言成本太高，大大降低了Mesos使用的灵活性。资源虚拟化方面，Mesos使用了操作系统级别虚拟化工具容器（Linux Container），管理CPU和内存两种资源，在保证编程框架性能的同时，也保证了编程框架之间的资源隔离，效果良好。在资源利用率方面，Mesos将空闲资源迅速回收，并通过资源-提供机制将空闲资源实时推送给编程框架，编程框架根据自身机制选择是否接受，通过这种方式能有效提高集群资源利用率。Mesos在资源虚拟化方面和提升资源利用率方面的表现很好，其缺点在于兼容现有的编程框架比较繁琐，兼容性不足。

3)Hadoop-Yarn

Hadoop0.23对Hadoop的架构进行了重大的革新。Hadoop0.23将编程框架与运行时框架解耦，分离出MapReduce编程框架和资源管理系统，新一代的架构称为Yarn。

Yarn采用主从架构，资源管理器(ResourceManager)是主部分，节点管理器(NodeManager)是其从部分。资源管理器负责调度分发资源请求，节点管理器负责启动任务。在Yarn中有两种运行实体，一种是程序管理器(App Master)，一种是容器（Container）。程序管理器是应用程序的主部分,比如MapReduce的主部分，而容器是程序管理器向资源管理器申请资源获得匹配后启动的程序，比如MapReduce的工作者（worker）。