CN102866918B - 面向分布式编程框架的资源管理系统 - Google Patents
面向分布式编程框架的资源管理系统 Download PDFInfo
- Publication number
- CN102866918B CN102866918B CN201210262881.5A CN201210262881A CN102866918B CN 102866918 B CN102866918 B CN 102866918B CN 201210262881 A CN201210262881 A CN 201210262881A CN 102866918 B CN102866918 B CN 102866918B
- Authority
- CN
- China
- Prior art keywords
- resource
- programming framework
- actuator
- information
- management system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Abstract
本发明涉及一种面向分布式编程框架的资源管理系统。该面向分布式编程框架的资源管理系统包括主部分和从部分,从部分用于启动编程框架执行器,监控编程框架执行器的运行状态,向主部分报告该从部分的资源使用信息和该从部分上编程框架执行器的资源使用信息;主部分包括:收集器,用于接收并保存从部分的资源使用信息和从部分上编程框架执行器的资源使用信息,保存集群资源信息,收集器中包括监控器,用于监控从部分上编程框架执行器的资源使用信息,根据编程框架定制的资源调整决策触发器向调度器发送为编程框架增加或减少资源的任务;调度器,用于调度、下发和控制监控器发送的任务。本发明具有良好的兼容性与灵活性。
Description
技术领域
本发明涉及计算机领域,尤其涉及一种面向分布式编程框架的资源管理系统。
背景技术
并行计算依赖于大规模的集群,并行计算的火热推动了集群管理系统的发展,面向并行计算的集群管理系统开始出现,比如LSF(LoadSharingFacility,负载共享设施)系统、PBS(ProtableBatchSystem,可移植批处理作业系统)系统等。这些系统都是面向并行计算,处理传统的批处理作业,管理集群资源,广泛应用于工业生产和科研环境中。随着分布式计算的兴起,各种新型并行编程框架的不断涌现,传统的集群管理系统因其本身系统设计与结构等方面的原因,无法良好的支持新型编程框架,更无法支持多编程框架共存于集群中的资源管理问题。面向多编程框架的集群资源管理是最近才出现的研究课题。下面列举3个有代表性的可支持多编程框架的集群资源管理系统:
1)计算密集型批处理作业管理系统Condor
Condor是威斯康辛大学开发的处理计算密集型作业的批处理系统。它的架构为典型的主-从(master-slave)结构,Condor的master主要由收集器(collector)和导航器(negotiator)组成,开启器(startd)是每个执行机器上都有的守护进程,相当于从部分,开启器负责启动任务,并定时上报机器的资源信息给收集器。开启器是每个提交作业的机器上都存在的调度器进程,负责接收用户作业,将任务匹配请求发送给收集器。导航器完成作业资源请求与机器的匹配工作,从而将作业分发给合适的机器,由开启器启动任务。
对于编程框架的支持,Condor实现了一套管理-工作者(master-worker)结构的框架,简称为MW框架。MW框架提供了一些基类,通过继承这三个基类,用户可以编写自己的框架。Condor支持编程框架的本质是提供了一套开发编程框架的API(ApplicationProgrammingInterface,应用程序编程接口),用户通过这套API可以开发出一个编程框架,因此Condor要支持已有的编程框架非常麻烦。资源虚拟化方面,Condor本身并没有对任何的资源虚拟化方案管理资源,因此多个框架之间会产生资源竞争,互相影响。总体而言,Condor在兼容现有的编程框架上存在困难,并且没有提供任何虚拟化的技术,使得多编程框架共享集群存在困难。
2)动态资源管理系统Mesos
Mesos是Berkeley大学实现的数据中心资源共享管理平台,负责为上层计算框架分配资源。Mesos的本质思想是集群复用。相比于传统的资源管理系统,Mesos从不同的资源视角对集群资源管理进行了抽象。Mesos通过与框架的调度器的通信完成资源分配的交互。
编程框架要运行于Mesos之上,必须要在编程框架的主部分中增加与Mesos的交互模块。Mesos提供了一套资源-提供(resource-offer)机制与编程框架的master交互。编程框架的主部分在基于资源-提供机制提供的API接收或者拒绝Mesos推送的资源,包括CPU和内存。因此对编程框架而言,需要进行大量的内部逻辑修改,对编程框架使用人员而言成本太高,大大降低了Mesos使用的灵活性。资源虚拟化方面,Mesos使用了操作系统级别虚拟化工具容器(LinuxContainer),管理CPU和内存两种资源,在保证编程框架性能的同时,也保证了编程框架之间的资源隔离,效果良好。在资源利用率方面,Mesos将空闲资源迅速回收,并通过资源-提供机制将空闲资源实时推送给编程框架,编程框架根据自身机制选择是否接受,通过这种方式能有效提高集群资源利用率。Mesos在资源虚拟化方面和提升资源利用率方面的表现很好,其缺点在于兼容现有的编程框架比较繁琐,兼容性不足。
3)Hadoop-Yarn
Hadoop0.23对Hadoop的架构进行了重大的革新。Hadoop0.23将编程框架与运行时框架解耦,分离出MapReduce编程框架和资源管理系统,新一代的架构称为Yarn。
Yarn采用主从架构,资源管理器(ResourceManager)是主部分,节点管理器(NodeManager)是其从部分。资源管理器负责调度分发资源请求,节点管理器负责启动任务。在Yarn中有两种运行实体,一种是程序管理器(AppMaster),一种是容器(Container)。程序管理器是应用程序的主部分,比如MapReduce的主部分,而容器是程序管理器向资源管理器申请资源获得匹配后启动的程序,比如MapReduce的工作者(worker)。
通过Yarn的架构,可以在Yarn上运行多种编程框架,比如MapReduce,DAG等等。Yarn提供了一套API,用户可以通过该API构建新的编程框架,也可以修改已有的编程框架,在其代码中加入与Yarn交互的资源管理模块。资源管理方面,节点管理器将运行任务的资源使用情况上报给资源管理器,资源管理器对其进行管理。Yarn目前仅对内存进行了管理,当某个程序的内存超出规定的额度时出触发相应的动作,比如杀死该任务。通过上述的描述可以发现,Yarn在兼容性上存在与Mesos一样的问题,要么重新编写编程框架,要么对已有的编程框架进行修改,以适配Yarn。资源虚拟化方面,Yarn使用JVM高级语言虚拟化来隔离资源,隔离性不高,另外,管理的资源目前仅包括内存,并没有对CPU和输入输出带宽资源的管理。总体而言,Yarn在兼容现有的编程框架上存在困难,在资源虚拟化方面稍显不足,资源利用率也相对较低。
综上所述,目前的集群资源管理系统存在如下问题:对数据处理编程框架支持困难,兼容性差;多编程框架共存集群中资源利用率不高,数据共享困难;资源竞争导致共存的编程框架效率不高。
发明内容
本发明所要解决的技术问题是提供一种面向分布式编程框架的资源管理系统,具有良好的兼容性,方便用户使用。
为解决上述技术问题,本发明提出了一种面向分布式编程框架的资源管理系统,包括主部分和从部分,其中:
所述从部分,用于启动编程框架执行器,监控编程框架执行器的运行状态,向所述主部分的调度器上报编程框架执行器的运行状态,向所述主部分报告该从部分的资源使用信息和该从部分上编程框架执行器的资源使用信息;
所述主部分包括:
收集器,用于接收并保存所述从部分的资源使用信息和所述从部分上编程框架执行器的资源使用信息,保存集群资源信息;
所述收集器中包括监控器,用于监控所述从部分上编程框架执行器的资源使用信息,并根据编程框架定制的资源调整决策触发器向调度器发送为编程框架增加或减少资源的任务;
调度器,用于调度、下发和控制所述监控器发送的为编程框架增加或减少资源的任务。
进一步地,上述面向分布式编程框架的资源管理系统还可具有以下特点,所述调度器中包括:
关键资源匹配模块,用于根据关键资源匹配算法选择匹配机器,所述关键资源匹配算法为:计算一台机器中每种资源的需求-可用比,所述需求-可用比为资源的需求与可用的比例,用需求-可用比最高的资源的需求-可用比作为该机器的关键资源比例,从集群中选出关键资源比例最高的机器作为匹配机器;
容器创建模块,用于在所述关键资源匹配模块选择的匹配机器上执行资源增加任务创建容器;
资源分配模块,用于将所述容器创建模块所创建的容器的资源分配给提出资源要求的编程框架。
进一步地,上述面向分布式编程框架的资源管理系统还可具有以下特点,所述容器为Linux容器。
进一步地,上述面向分布式编程框架的资源管理系统还可具有以下特点,所述决策触发器包括过载触发器,一个编程框架对应一个过载触发器,过载触发器判断编程框架是否处于高负载状态,若是则提出为编程框架增加资源的要求,所述高负载状态是指一个编程框架的所有执行器在过载触发器周期内的平均CPU利用率大于设定的CPU利用率阈值的情况。
进一步地,上述面向分布式编程框架的资源管理系统还可具有以下特点,所述过载触发器周期为60秒。
进一步地,上述面向分布式编程框架的资源管理系统还可具有以下特点,所述决策触发器包括空闲触发器,一个执行器对应一个空闲触发器,空闲触发器判断执行器当前是否处于空闲状态,若是则关闭该执行器,并回收该执行器的资源,所述空闲状态是指在空闲触发器周期内,执行器的子进程数目小于设定的数目阈值的情况。
进一步地,上述面向分布式编程框架的资源管理系统还可具有以下特点,所述空闲触发器周期为5分钟。
进一步地,上述面向分布式编程框架的资源管理系统还可具有以下特点,所述从部分的资源使用信息包括从部分总的CPU个数、从部分总的内存大小、从部分当前的可用CPU个数、从部分当前的可用内存大小和从部分当前的CPU利用率。
进一步地,上述面向分布式编程框架的资源管理系统还可具有以下特点,所述编程框架的资源使用信息包括编程框架当前占用的CPU利用率、编程框架占用的内存大小和编程框架当前的子进程数目。
进一步地,上述面向分布式编程框架的资源管理系统还可具有以下特点,所述分布式编程框架包括Hadoop编程框架、消息传递接口MPI编程框架。
进一步地,上述面向分布式编程框架的资源管理系统还可具有以下特点,所述从部分通过向所述主部分发送心跳信息来向所述主部分报告该从部分的资源使用信息和该从部分上编程框架执行器的资源使用信息,所述从部分的资源使用信息和该从部分上编程框架执行器的资源使用信息包含在所述心跳信息中。
本发明的面向分布式编程框架的资源管理系统对分布式编程框架是透明的,任何分布式编程框架(如Hadoop、MPI等)不经过任何修就可以运行于本发明的面向分布式编程框架的资源管理系统之上,从而使得多种编程框架能够运行在一个集群上,共享数据与集群资源,具有良好的兼容性与灵活性。并且,本发明的面向分布式编程框架的资源管理系统保证多个编程框架之间使用的资源(CPU、内存等)相互隔离、互不干扰,同时保证各个编程框架的性能。
附图说明
图1为本发明面向分布式编程框架的资源管理系统的总体架构图;
图2为本发明实施例中面向分布式编程框架的资源管理系统的一种具体结构图;
图3为本发明面向分布式编程框架的资源管理系统中主部分与从部分之间交互资源信息的示意图;
图4为一个集群的常态的资源视图;
图5为本发明中监控机制的示意图。
具体实施方式
以下结合附图对本发明的原理和特征进行描述,所举实例只用于解释本发明,并非用于限定本发明的范围。
本文中提到的机器是指集群中的计算机。
图1为本发明面向分布式编程框架的资源管理系统的总体架构图。本发明面向分布式编程框架的资源管理系统是一种主从式(master-slave)管理架构。如图1所示,本发明的面向分布式编程框架的资源管理系统包括主部分(master)和从部分(slave)。其中,从部分用于启动编程框架执行器,监控编程框架执行器的运行状态,向主部分的调度器上报编程框架执行器的运行状态,以及向主部分报告该从部分的资源使用信息和该从部分上编程框架执行器(executor)的资源使用信息。具体地,从部分可以通过向主部分发送心跳信息来向主部分报告该从部分的资源使用信息和该从部分上编程框架执行器的资源使用信息,从部分的资源使用信息和该从部分上编程框架执行器的资源使用信息包含在心跳信息中。主部分用于通过实时监控编程框架的资源使用情况为编程框架自动伸缩资源。
除了发送心跳信息外,从部分也可以通过其它途径向主部分上报资源使用信息,此处不再一一列举。
编程框架对于本发明的面向分布式编程框架的资源管理系统而言是黑盒,本发明的面向分布式编程框架的资源管理系统并不管理执行器的内部行为(比如其内部任务(task)的运行等),只能获取编程框架的资源使用情况,比如当前使用的CPU,当前使用的内存大小,以及当前使用的输入输出带宽资源,通过这些资源使用信息获取当前编程框架的负载,从而根据负载为编程框架动态伸缩资源。本发明的面向分布式编程框架的资源管理系统对编程框架而言是透明的,编程框架主部分与编程框架执行器之间的交互不做任何改变。本发明中的编程框架可以是所有面向数据处理的编程框架。
其中,分布式编程框架可以包括Hadoop、MPI(消息传递接口,MessagePassingInterface)等。
其中,编程框架的资源使用信息可以包括编程框架当前占用的CPU利用率、编程框架占用的内存大小、编程框架当前的子进程数目等。
图2为本发明实施例中面向分布式编程框架的资源管理系统的一种具体结构图。如图2所示,主部分包括收集器(collector)和调度器(scheduler),收集器中包含监控器(monitor)。其中,收集器用于接收并保存从部分的资源使用信息和从部分上编程框架执行器(executor)的资源使用信息,保存集群资源信息。监控器保存有每个编程框架的所有执行器的资源使用信息(该资源使用信息是由收集器发送给监控器的)。监控器用于监控从部分上编程框架执行器(executor)的资源使用信息,并根据编程框架定制的资源调整决策触发器向调度器发送为编程框架增加(Submit)或减少(Delete)资源的任务。监控器根据每个编程框架定制的资源决策机制决定是否触发反馈机制(feedback),一旦反馈机制被触发,监控器就向调度器发送增加资源的命令或减少资源的命令。调度器用于调度、下发和控制监控器发送的为编程框架增加或减少资源的任务。
如图2所示,当接收到增加资源的任务之后,调度器就对这个任务进行调度,将该任务的资源需求通过匹配(Match)命令发送给收集器匹配,收集器保存有当前集群最新的资源信息,收集器会选择一个合适的机器返回给调度器,调度器立即将这个任务下发到该机器上。
从部分还用于启动各个编程框架的执行器。对Hadoop而言,它的执行器就是任务跟踪器(tasktracker)。从部分负责启动这些执行器,监控它们的状态,并将这些信息及机器目前的资源使用情况通过心跳信息上报给主部分。如图2所示,当接收到调度器的启动任务命令后,从部分就派生(fork)一个进程启动该任务,从部分将任务的状态实时上报给调度器,比如任务启动成功、任务结束等。同时从部分保持与收集器的心跳,并通过心跳,将机器当前的资源情况和正在运行的执行器的资源使用情况上报给收集器。例如图2中示出的Hadoop执行器占用的内存为40M,当前占用的CPU利用率为50%,当前的任务数目为3个。
图2中,工具(tools)是指本发明面向分布式编程框架的资源管理系统的客户端工具,用户可以通过命令行工具向本发明面向分布式编程框架的资源管理系统挂载或者移除编程框架。
在用程序实现主部分时,收集器和调度器可以看作是主部分的程序中的两个进程。监控器是收集器内部的一个线程,并不是一个进程,线程之间传递消息的速度相比于进程更快。将主部分的程序拆成收集器和调度器两个进程会提高系统的可扩展性,容纳更多的机器,因为调度器只负责资源分配与调度工作,收集器只负责资源收集和监控工作,这种完全松耦合的设计可以提高进程的可靠性和稳定性,从而提高系统的扩展性。主部分程序和从部分程序一般运行于不同的机器上面,但是也可以部署在同一个机器上,这种情况下这个机器就有两个角色,既是主部分又是从部分。
图3为本发明面向分布式编程框架的资源管理系统中主部分与从部分之间交互资源信息的示意图。图3中,示出了3个从部分,分别为第一从部分、第二从部分和第三从部分。其中,第一从部分有两个执行器,即Hadoop执行器和MPI执行器,第二从部分有一个Hadoop执行器,第三从部分有一个MPI执行器。第一从部分、第二从部分和第三从部分分别将编程框架执行器的资源使用信息上报给主部分。第一从部分上报的内容是:MPI执行器占用的内存为100M,当前占用的CPU利用率为80%,当前的任务(也即子进程)数目为1个;Hadoop执行器占用的内存为100M,当前占用的CPU利用率为50%,当前的任务数目为3个。第二从部分上报的内容是:Hadoop执行器占用的内存为100M,当前占用的CPU利用率为50%,当前的任务数目为3个。第三从部分上报的内容是:MPI执行器占用的内存为100M,当前占用的CPU利用率为80%,当前的任务数目为1个。
由上可见,本发明的面向分布式编程框架的资源管理系统的主部分和从部分之间利用资源自动伸缩机制,通过实时监控编程框架的资源使用情况为编程框架自动伸缩资源,使得编程框架不需要做任何修改就能接入,极大地减轻了编程框架开发人员的负担,具有良好的兼容性,方便用户使用。
本发明的面向分布式编程框架的资源管理系统中,主部分的调度器可以进一步包括关键资源匹配模块、容器创建模块和资源分配模块。关键资源匹配模块用于根据关键资源匹配算法(又称为基于关键资源的最优匹配算法或者DRBF算法)选择匹配机器。容器创建模块用于在关键资源匹配模块选择的匹配机器上执行资源增加任务创建容器(Container)。资源分配模块用于将容器创建模块所创建的容器的资源分配给提出资源要求的编程框架。
其中,关键资源匹配算法为:计算一台机器中每种资源的需求-可用比,需求-可用比为资源的需求与可用的比例,用需求-可用比最高的资源的需求-可用比作为该机器的关键资源比例,从集群中选出关键资源比例最高的机器作为匹配机器。关键资源匹配算法的描述见表2。该关键资源匹配算法可以减少集群内的资源碎片,提升系统吞吐量,提升集群的资源利用率。
表2关键资源匹配算法伪代码描述
可见,本发明的面向分布式编程框架的资源管理系统使用资源匹配的模式将编程框架的资源需求与而系统可用的资源相匹配,因为系统中保存有集群最新的资源视图,因此资源匹配的机制将很容易实现。
本发明中,以容器为基本的调度分配资源。其中,容器可以是Linux容器,一个Linux容器只属于一个编程框架,一个编程框架拥有至少一个Linux容器的资源。将编程框架的执行器运行于容器之中,容器相当于为其提供了一个隔离的运行环境。
本发明的面向分布式编程框架的资源管理系统采用轻量级虚拟化方案(例如上面提到的基于Linux容器的虚拟化方案)管理编程框架的资源(CPU、内存等),使得编程框架之间的资源隔离,互不干扰,同时尽量降低虚拟化带来的开销,从而保证编程框架的性能。在采用基于Linux容器的虚拟化方案时,拥有特定资源的Linux容器被分配给编程框架,一个编程框架可以拥有多个容器作为资源。系统管理所有容器的分配和回收,以达到集群资源管理的目的。
Linux容器是开源的操作系统(OS)级别虚拟化工具,它通过内核模块cgroups管理进程组资源,通过增加系统调用clone新的标记实现资源隔离(CPU/内存和IO之间的隔离)。使用Linux容器建立的虚拟机将与宿主机器共享一个linux内核,多个虚拟机之间通过命名空间(namespace)进行区别,因此相比于传统虚拟机,Linux容器的开销很低,同时具有良好的资源隔离。
通过Linux容器可以管理的资源包括CPU、内存、磁盘IO以及网络IO等。从部分在初始化时,会获取系统可用的内存大小,以及系统总的CPU个数。假设机器是本系统独占的,设定系统总的CPU个数为可用的CPU个数,系统可用的内存大小为系统目前的内存数量。当从部分将这些信息上报给主部分之后,主部分就知道了每个机器的可用CPU个数以及可用的内存大小。每当系统要为编程框架启动一个执行器时,就会给执行器分配一定的资源,执行器会在某台从部分上启动起来,每一个执行器只会被一个Linux容器包住,从而保证编程框架之间的资源隔离。当执行器启动后,从部分会将当前的资源变化迅速的上报主部分;当执行器关闭时,对应的容器会被销毁,相应的,它占用的资源会被从部分立即回收,并及时更新可用信息给主部分。因此一个集群的常态的资源视图如图4所示。
在CPU方面,Linux容器提供的是CPU时间的比例。比如两个容器在一台机器上运行,给容器A的CPU时间份额是1024,给容器B的CPU时间份额是512,那么容器A与容器B占用这台机器的CPU时间之比就为2:1,如果这台机器是3个核,就可以认为容器A占用了2个核,而容器B占用了1个核,如果机器上只有运行了1个容器A,虽然给容器A的设定的CPU时间份额是1024,但容器A实际上占用了全部的核,即3个核。因此Linux容器并没有保证一个Linux容器能占用多少个核,这种方法不方便用户使用。本发明中,借鉴VMM(VirtualMachineMonitor,虚拟机管理器)中微CPU的概念对CPU资源进行一层抽象,设定1个CPU对应的时间份额为1024,这样给一个编程框架的执行器分配1个CPU,那么如果启动该执行器的机器是2个CPU,且被用满,则它能保证一半的CPU时间,即一个核,如果不被用满,则根据比例它会使用超过一半的CPU时间。通过这样的方式,如果给编程框架分配1个CPU,则它至少能使用1个CPU的时间。
在内存方面,Linux容器限制最大的内存容量。Linux容器提供了两种限制内存方式,一种是软限制(softlimit),即当系统中存在可用的内存时,Linux容器占用的内存可以超出最大的限制,但当别人需要时,需要被释放。另一种是硬限制(hardlimit),Linux容器占用的内存绝对不超出最大的限制,即使系统有空闲内存可用。本发明中,使用较为严格的硬限制,使用硬限制可以确保每个编程框架每时每刻都有资源可用,同时还是防止因编程框架本身的错误(比如内存泄露)而对系统整体产生影响。
在主部分中,不同的编程框架会有多个资源信息的队列,每个队列存放的是某一个编程框架执行器的自启动开始的所有资源信息,编程框架所有的执行器的资源信息队列就是编程框架的所有资源信息。这些队列作为一个整体,其后面挂有多个决策触发器。这些决策触发器对这些资源信息进行监控计算,一旦满足设定定条件,决策触发器就会被触发,从而执行资源申请或者释放的动作,也就是说编程框架所有决策触发器的触发策略决定了编程框架的资源申请与释放。各种编程框架的资源伸缩策略可以是不同的。为保证每个编程框架资源伸缩策略的合理,本发明中采用定制化的策略,提供相应的工具给用户,使得用户可以对编程框架的决策触发器进行增加,修改以及删除操作,从而保证各个编程框架的资源伸缩机制的合理性。图5为本发明中监控机制的示意图。如图5所示,Hadoop执行器后面挂有两个触发器(trigger),即触发器1和触发器2。
其中,决策触发器可以包括过载(Overload)触发器和空闲(Idle)触发器。
过载触发器是面向编程框架的,一个编程框架对应一个过载触发器,过载触发器判断编程框架是否处于高负载状态,若是则提出为编程框架增加资源的要求,所述的高负载状态是指一个编程框架的所有执行器在过载触发器周期内的平均CPU利用率大于设定的CPU利用率阈值的情况。过载触发器周期可以是60秒。当然,除了60秒,过载触发器周期也可以设定为其它的数值。
空闲触发器是面向编程框架的执行器的,一个执行器对应一个空闲触发器。在空闲触发器中存放了对应的执行器的编号。具体的信息如表1所示。空闲触发器判断执行器当前是否处于空闲状态,若是则关闭该执行器,并回收该执行器的资源,所述的空闲状态是指在空闲触发器周期内,执行器的子进程数目小于设定的数目阈值的情况。空闲触发器周期可以是5分钟。当然,除了5分钟,空闲触发器周期也可以设定为其它的数值。
表1触发器信息表
在决策触发器为空闲触发器的情况下,对于每个编程框架,会有多个空闲触发器对编程框架资源信息进行监控计算,一旦满足设定条件,空闲触发器就会被触发,从而执行资源申请或者释放的动作,达到对于每个框架动态伸缩资源的目的。
本发明的面向分布式编程框架的资源管理系统根据编程框架的负载自动为编程框架增加资源,保证编程框架的工作性能。本发明的面向分布式编程框架的资源管理系统(以下简称本系统)的自动扩容的工作流程如下:
(1)编程框架FK被挂载到本系统,本系统初始为编程框架FK启动一个执行器E在从部分A中;
(2)从部分A不断通过心跳将执行器E的资源使用信息发送给收集器,收集器转发给监控器;
(3)监控器中编程框架FK对应的监视器发现执行器E的CPU一直处于很高的状态,并持续了一段时间(超过60s),最终触发了过载触发器;
(4)过载触发器执行触发动作,向调度器发送一个增加(Add)执行器命令,希望为编程框架FK再增加一个执行器,从而增加编程框架FK的资源,为编程框架FK扩容;
(5)调度器接收到这个增加执行器的命令后开始调度这个任务,将任务的资源需求发送给收集器,请求匹配(Match)这个资源需求;
(6)收集器根据DRBF算法为其匹配了一个合适的从部分B,并把B返回给调度器;
(7)调度器向从部分B发送开始(Start)命令,以启动一个执行器G;
(8)从部分B启动执行器成功,把启动成功的信息上报给调度器,编程框架FK成功扩容。
本系统根据编程框架的负载自动为编程框架减少资源,把空闲的资源回收,给其它的编程框架使用。系统自动缩容的工作流程如下:
(1)从部分A和从部分B不断通过心跳将执行器E和执行器G的资源使用信息发送给收集器,收集器再转发给监控器;
(2)监控器中编程框架FK对应的监视器发现执行器E的子进程数目一直为0,并且持续时间超过了5分钟,此时空闲触发器被触发,执行器E被认为是空闲的,资源可以释放;
(3)空闲触发器执行触发动作,向调度器发送一个删除(Delete)执行器命令,希望删除执行器E;
(4)调度器接收到这个命令后,在任务池中找到这个执行器E所在的机器,为从部分A;
(5)调度器向从部分A发送杀死任务(KillTask)命令;
(6)从部分A接收到杀死任务命令后,找到执行器E,将执行器E杀死,并把回收的资源上报给收集器,资源成功回收。
本系统架构很适合进行容错处理。系统的容错分为进程级容错、服务器级容错、网络容错。对于进程级容错,比如编程框架的执行器突然执行失败,可以通过重新执行的机制处理,即从部分重新启动该执行器若干次,如果依旧无法启动,则上报给调度器,交由调度器重新调度。对于服务器级别的容错,如系统宕机,收集器会快速察觉这一变化。因为从部分通过心跳与收集器保持联系,因此一旦因为宕机致从部分长时间无法与收集器联系,收集器会知道哪些节点暂时不可用,从而将这些节点视为不可用节点,并将这些节点信息告知调度器。调度器根据这些节点信息找到在其上运行的所有的执行器,将它们调度到其他的节点上执行。当这些节点恢复正常时,与收集器重新保持心跳,收集器重新将这些节点作为可用节点,重新提供服务。对于网络容错,如果是网络闪断,系统对所有进程之间的通信都实现一定的网络容忍,通过重试机制保证通信的质量,如果是网络分割,则可视为宕机,使用与宕机一样的处理方式即可。
在EC2(AmazonElasticComputeCloud)上测试本发明的面向分布式编程框架的资源管理系统的过程及结果如下:在系统上运行上两个Hadoop集群,并在Hadoop集群上运行了一定规模的作业。通过实验发现,本发明的面向分布式编程框架的资源管理系统使得集群Hadoop不需要进行任何修改就能运行在系统上,兼容性极高,十分方便。另一方面,本发明的面向分布式编程框架的资源管理系统的资源虚拟化机制保证了两个Hadoop集群的执行效率。通过实验发现Hadoop集群中执行作业的效率基本不变。此外,通过实验还发现,本发明的面向分布式编程框架的资源管理系统所采用的DRBF算法可以有效改变集群的CPU使用曲线,使得CPU资源得到充分应用,提升集群吞吐量,提高资源利用率。
虽然本文中所列举的编程框架主要是用于数据处理的,但本发明适用所有的编程框架。因为本发明把编程框架当作一个黑盒放入容器中,不关心黑盒里面的内容。
由上可见,本发明的面向分布式编程框架的资源管理系统对分布式编程框架是透明的,任何分布式编程框架(如Hadoop、MPI等)不经过任何修就可以运行于本发明的面向分布式编程框架的资源管理系统之上,从而使得多种编程框架能够运行在一个集群上,共享数据与集群资源,具有良好的兼容性与灵活性。本发明的面向分布式编程框架的资源管理系统可以自动为编程框架伸缩资源,最大化资源利用率。并且,本发明的面向分布式编程框架的资源管理系统保证多个编程框架之间使用的资源(CPU、内存等)相互隔离、互不干扰,同时保证各个编程框架的性能。
以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (11)
1.一种面向分布式编程框架的资源管理系统,其特征在于,包括主部分和从部分,其中:
所述从部分,用于启动编程框架执行器,监控编程框架执行器的运行状态,向所述主部分的调度器上报编程框架执行器的运行状态,向所述主部分报告该从部分的资源使用信息和该从部分上编程框架执行器的资源使用信息;
所述主部分包括:
收集器,用于接收并保存所述从部分的资源使用信息和所述从部分上编程框架执行器的资源使用信息,保存集群资源信息;
所述收集器中包括监控器,用于监控所述从部分上编程框架执行器的资源使用信息,并根据编程框架定制的资源调整决策触发器向调度器发送为编程框架增加或减少资源的任务;
调度器,用于调度、下发和控制所述监控器发送的为编程框架增加或减少资源的任务;
所述调度器中包括:
关键资源匹配模块,用于根据关键资源匹配算法选择匹配机器,所述关键资源匹配算法为:计算一台机器中每种资源的需求-可用比,所述需求-可用比为资源的需求与可用的比例,用需求-可用比最高的资源的需求-可用比作为该机器的关键资源比例,从集群中选出关键资源比例最高的机器作为匹配机器。
2.根据权利要求1所述的面向分布式编程框架的资源管理系统,其特征在于,所述调度器中还包括:
容器创建模块,用于在所述关键资源匹配模块选择的匹配机器上执行资源增加任务创建容器;
资源分配模块,用于将所述容器创建模块所创建的容器的资源分配给提出资源要求的编程框架。
3.根据权利要求2所述的面向分布式编程框架的资源管理系统,其特征在于,所述容器为Linux容器。
4.根据权利要求1所述的面向分布式编程框架的资源管理系统,其特征在于,所述决策触发器包括过载触发器,一个编程框架对应一个过载触发器,过载触发器判断编程框架是否处于高负载状态,若是则提出为编程框架增加资源的要求,所述高负载状态是指一个编程框架的所有执行器在过载触发器周期内的平均CPU利用率大于设定的CPU利用率阈值的情况。
5.根据权利要求4所述的面向分布式编程框架的资源管理系统,其特征在于,所述过载触发器周期为60秒。
6.根据权利要求1所述的面向分布式编程框架的资源管理系统,其特征在于,所述决策触发器包括空闲触发器,一个执行器对应一个空闲触发器,空闲触发器判断执行器当前是否处于空闲状态,若是则关闭该执行器,并回收该执行器的资源,所述空闲状态是指在空闲触发器周期内,执行器的子进程数目小于设定的数目阈值的情况。
7.根据权利要求6所述的面向分布式编程框架的资源管理系统,其特征在于,所述空闲触发器周期为5分钟。
8.根据权利要求1所述的面向分布式编程框架的资源管理系统,其特征在于,所述从部分的资源使用信息包括从部分总的CPU个数、从部分总的内存大小、从部分当前的可用CPU个数、从部分当前的可用内存大小和从部分当前的CPU利用率。
9.根据权利要求1所述的面向分布式编程框架的资源管理系统,其特征在于,所述编程框架的资源使用信息包括编程框架当前占用的CPU利用率、编程框架占用的内存大小和编程框架当前的子进程数目。
10.根据权利要求1所述的面向分布式编程框架的资源管理系统,其特征在于,所述分布式编程框架包括Hadoop编程框架、消息传递接口MPI编程框架。
11.根据权利要求1所述的面向分布式编程框架的资源管理系统,其特征在于,所述从部分通过向所述主部分发送心跳信息来向所述主部分报告该从部分的资源使用信息和该从部分上编程框架执行器的资源使用信息,所述从部分的资源使用信息和该从部分上编程框架执行器的资源使用信息包含在所述心跳信息中。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210262881.5A CN102866918B (zh) | 2012-07-26 | 2012-07-26 | 面向分布式编程框架的资源管理系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210262881.5A CN102866918B (zh) | 2012-07-26 | 2012-07-26 | 面向分布式编程框架的资源管理系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102866918A CN102866918A (zh) | 2013-01-09 |
CN102866918B true CN102866918B (zh) | 2016-02-24 |
Family
ID=47445797
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210262881.5A Active CN102866918B (zh) | 2012-07-26 | 2012-07-26 | 面向分布式编程框架的资源管理系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102866918B (zh) |
Families Citing this family (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103246570A (zh) * | 2013-05-20 | 2013-08-14 | 百度在线网络技术(北京)有限公司 | Hadoop的调度方法、系统及管理节点 |
CN103530189B (zh) * | 2013-09-29 | 2018-01-19 | 中国科学院信息工程研究所 | 一种面向流式数据的自动伸缩及迁移的方法及装置 |
CN103699433B (zh) * | 2013-12-18 | 2017-07-14 | 中国科学院计算技术研究所 | 一种于Hadoop平台中动态调整任务数目的方法及系统 |
CN103810023B (zh) * | 2014-03-06 | 2016-09-07 | 中国科学院信息工程研究所 | 一种云平台中分布式应用的智能部署方法及系统 |
CN104123182B (zh) * | 2014-07-18 | 2015-09-30 | 西安交通大学 | 基于主从架构的MapReduce任务跨数据中心调度系统及方法 |
CN104486148B (zh) * | 2014-12-04 | 2018-11-23 | 北京百度网讯科技有限公司 | 一种服务器回收控制方法及装置 |
CN105045656B (zh) * | 2015-06-30 | 2018-11-30 | 深圳清华大学研究院 | 基于虚拟容器的大数据存储与管理方法 |
CN105404549B (zh) * | 2015-12-06 | 2019-04-26 | 北京天云融创软件技术有限公司 | 基于yarn架构的虚拟机调度系统 |
CN105550305B (zh) * | 2015-12-14 | 2019-11-22 | 北京锐安科技有限公司 | 一种基于map/reduce的实时响应方法及系统 |
US10970805B2 (en) | 2015-12-24 | 2021-04-06 | Intel Corporation | Graphics processing unit operation |
CN106293933A (zh) * | 2015-12-29 | 2017-01-04 | 北京典赞科技有限公司 | 一种支持多大数据计算框架的集群资源配置与调度方法 |
CN105653365A (zh) * | 2016-02-22 | 2016-06-08 | 青岛海尔智能家电科技有限公司 | 任务处理方法及装置 |
CN107402800B (zh) * | 2016-03-18 | 2020-11-13 | 阿里巴巴集团控股有限公司 | 一种更新容器守护进程的方法和设备 |
CN108073454A (zh) * | 2016-11-15 | 2018-05-25 | 阿里巴巴集团控股有限公司 | 资源划拨方法及系统、前端设备和后端设备 |
US20180159735A1 (en) * | 2016-12-02 | 2018-06-07 | Hewlett Packard Enterprise Development Lp | Managing hardware resources |
CN108334396B (zh) * | 2017-01-19 | 2022-12-30 | 阿里巴巴集团控股有限公司 | 一种数据处理方法和装置、资源组的创建方法和装置 |
CN109117252B (zh) * | 2017-06-26 | 2021-04-30 | 北京京东尚科信息技术有限公司 | 基于容器的任务处理的方法、系统及容器集群管理系统 |
CN108089924A (zh) * | 2017-12-18 | 2018-05-29 | 郑州云海信息技术有限公司 | 一种任务运行方法及装置 |
CN108170417B (zh) * | 2017-12-29 | 2022-02-11 | 曙光信息产业(北京)有限公司 | 一种在mesos集群中集成高性能的作业调度框架的方法和装置 |
CN108388470B (zh) * | 2018-01-26 | 2022-09-16 | 福建星瑞格软件有限公司 | 一种大数据任务处理方法及计算机设备 |
CN108762914A (zh) * | 2018-04-17 | 2018-11-06 | 广东智媒云图科技股份有限公司 | 一种系统架构的智能伸缩方法、装置、电子设备及存储介质 |
CN108897627B (zh) * | 2018-07-23 | 2021-11-09 | 南京叠嘉信息科技有限公司 | 针对典型容器的Docker动态调度方法 |
CN111930493B (zh) * | 2019-05-13 | 2023-08-01 | 中国移动通信集团湖北有限公司 | 集群中NodeManager状态管理方法、装置及计算设备 |
CN110275777B (zh) * | 2019-06-10 | 2021-10-29 | 广州市九重天信息科技有限公司 | 一种资源调度系统 |
CN110515595B (zh) * | 2019-08-02 | 2024-02-02 | 中国航空无线电电子研究所 | 一种航空电子分布式管理系统的资源建模及管理方法 |
CN110597634B (zh) * | 2019-09-12 | 2021-05-07 | 腾讯科技(深圳)有限公司 | 一种数据处理方法、装置及计算机可读存储介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6950874B2 (en) * | 2000-12-15 | 2005-09-27 | International Business Machines Corporation | Method and system for management of resource leases in an application framework system |
CN102033777A (zh) * | 2010-09-17 | 2011-04-27 | 中国资源卫星应用中心 | 基于ice的分布式作业调度引擎 |
CN102073546A (zh) * | 2010-12-13 | 2011-05-25 | 北京航空航天大学 | 一种云计算环境中分布式计算模式下的任务动态调度方法 |
CN102096602A (zh) * | 2009-12-15 | 2011-06-15 | 中国移动通信集团公司 | 一种任务调度方法及其系统和设备 |
CN102541640A (zh) * | 2011-12-28 | 2012-07-04 | 厦门市美亚柏科信息股份有限公司 | 一种集群gpu资源调度系统和方法 |
-
2012
- 2012-07-26 CN CN201210262881.5A patent/CN102866918B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6950874B2 (en) * | 2000-12-15 | 2005-09-27 | International Business Machines Corporation | Method and system for management of resource leases in an application framework system |
CN102096602A (zh) * | 2009-12-15 | 2011-06-15 | 中国移动通信集团公司 | 一种任务调度方法及其系统和设备 |
CN102033777A (zh) * | 2010-09-17 | 2011-04-27 | 中国资源卫星应用中心 | 基于ice的分布式作业调度引擎 |
CN102073546A (zh) * | 2010-12-13 | 2011-05-25 | 北京航空航天大学 | 一种云计算环境中分布式计算模式下的任务动态调度方法 |
CN102541640A (zh) * | 2011-12-28 | 2012-07-04 | 厦门市美亚柏科信息股份有限公司 | 一种集群gpu资源调度系统和方法 |
Also Published As
Publication number | Publication date |
---|---|
CN102866918A (zh) | 2013-01-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102866918B (zh) | 面向分布式编程框架的资源管理系统 | |
CN109885389B (zh) | 一种基于容器的并行深度学习调度训练方法及系统 | |
Zhong et al. | A cost-efficient container orchestration strategy in kubernetes-based cloud computing infrastructures with heterogeneous resources | |
CN104508634B (zh) | 虚拟机的动态资源分配 | |
US11627041B2 (en) | Dynamic reconfiguration of resilient logical modules in a software defined server | |
CN109923523B (zh) | 计算机系统及用于计算机系统的方法 | |
Chen et al. | Preemptive, low latency datacenter scheduling via lightweight virtualization | |
US20190220319A1 (en) | Usage instrumented workload scheduling | |
US20190370043A1 (en) | Cooperative memory management | |
CN108292235B (zh) | 使用选择性资源迁移的网络附连存储器 | |
US10187452B2 (en) | Hierarchical dynamic scheduling | |
WO2014090008A1 (zh) | 一种任务处理的方法和虚拟机 | |
CN102609295A (zh) | 虚拟机作业动态调度系统 | |
US20230393879A1 (en) | Coordinated Container Scheduling For Improved Resource Allocation In Virtual Computing Environment | |
CN101876926A (zh) | 一种非对称结构的软件三机热备容错方法 | |
CN103353852A (zh) | 一种虚拟化WebService的IaaS的构建方法 | |
CN105242872A (zh) | 一种面向虚拟集群的共享存储系统 | |
CN103294540A (zh) | 一种通过至强融核协处理器提升Erlang虚拟机性能的方法 | |
US20220229688A1 (en) | Virtualized i/o | |
Chen et al. | Pufferfish: Container-driven elastic memory management for data-intensive applications | |
Cirne et al. | Web-scale job scheduling | |
EP3084603B1 (en) | System and method for supporting adaptive busy wait in a computing environment | |
EP3042305A1 (en) | Selective resource migration | |
CN102799474A (zh) | 一种基于可靠性驱动的云资源容错调度方法 | |
CN116166413A (zh) | 针对异构基础设施上的工作负载的生命周期管理 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |