面向网构软件的云平台的资源管理工具技术白皮书北京大学信息科学技术学院软件研究所2010年6月i目录第一章概述....................................................................................................1第二章分布式的资源分配动态规划方法....................................................4第三章基于虚拟机技术的节点资源动态分配机制..................................15第四章支持应用按需部署的中间件动态配置框架..................................17面向应用的共享集群的资源管理工具技术白皮书1第一章概述在可复用软件构件等技术的支持下,软件实体以自主的软件服务的形式存在于Internet的各个节点之上,它们通过各种交互机制进行动态的互连、互通、协同和联盟,来满足最终用户提出的、可能随时间而变的需求,这样一种Internet环境下的新的软件形态被称为网构软件(Internetware)1。网构软件是在Internet开放、动态和多变环境下软件系统基本形态的一种抽象,JavaEE网络应用(简称应用),这类在开放、动态、多变的网络环境中的大型复杂应用就是一类典型的网构软件。已有调研报告指出,在开放、动态、多变的网络环境中,JavaEE网络应用的负载通常具有较大幅度的波动。为了应对负载量峰值,传统仅能支持单个应用运行的集群环境往往需要配备远高于应用平均需求的计算资源,结果导致大部分集群资源在多数时段处于闲置状态(利用率通常不足30%)。因此,能够按需提供资源的云计算平台已被视为一种理想的网构软件运行支撑技术。在云平台中,通常管理着一个大规模的服务器集群,用于同时支持多个应用的运行,因此这类集群通常也被称为共享集群。共享集群基于不同应用的负载量往往相互独立这一事实(例如,某个应用正处于负载量高峰时,另一个应用的负载量可能正处于平均值之下),根据应用在不同时刻的资源需求,动态地对其分配和回收资源,在满足应用性能、可用性、易伸缩性等多方面需求的同时,实现计算资源在多个应用之间共享,提高集群计算资源的利用率,也更加有利于企业IT系统的整合和管理。资源管理是云平台中共享集群的核心问题,为此,在国家重大基础研究计划(973计划)的资助下,我们在JO2nAS中间件上设计并实现了一个适用于大规模共享集群的资源管理工具(简称资源管理工具),并遵循LGPL开放源代码许可证。JO2nAS是北京大学与国际著名开源中间件JOnAS合作,合并优势技术,联合打造新一代开源中间件。本资源管理工具针对JO2nAS中间件主要进行了以下三方面的扩展:包括一种分布式的资源分配动态规划方法,一种基于虚拟机技术的节点资源动态分配机制,和一种支持应用按需部署的中间件服务动态配置框架,体系结构如图1所示。上述扩展使得JO2nAS成为,使其成为云计算平台上网构软件的运行支撑平台:支持共享集群在应用请求发生变化时迅速调整共享集群中资源在应用间的分配,同时支持节点资源在应用实例间的明确划分和应用实例在节点上的按需部署,以保证资源分配方案实施的效果和效率,此外,资源管理工具还1[杨02]杨芙清,梅宏,吕建,金芝.浅论软件技术发展.电子学报,2002年,2003,26(9):1104-1115.面向应用的共享集群的资源管理工具技术白皮书2在资源分配规划过程中支持为不同应用赋予不同的优先级。图1面向网构软件的云平台的资源管理工具分布式的资源分配动态规划方法共享集群是云平台中的一个重要组成部分。针对共享集群这类大规模集群环境,考虑所有节点的集中式资源分配规划方法由于问题规模造成的复杂性,往往难以具有较好的易伸缩性和较快的变化响应能力。为此,本资源管理工具提出并实现了一种分布式的资源分配规划方法,其核心思想是共享集群中的节点分别完成对自身资源分配的规划,并通过某种协同方式相互影响,最终所有节点的局部资源分配规划形成了共享集群整体的资源分配规划。在分布式资源分配规划方法的设计中,节点自身资源规划策略以及节点间协同方式是研究的重点和难点。通过调研现有的分布协同技术,和分析共享集群资源分配规划问题的特点,方法借鉴了市场中买卖双方的协作模型,让节点根据自身的资源使用情况,自发地向其它节点转让或从其它节点获取后续一段时间内到来的应用请求;从而,共享集群的资源规划体现为应用请求在节点间转移的过程,当请求转移停止时,共享集群也就完成了其整体的资源分配规划。基于虚拟机技术的节点资源动态分配机制中间件中现有的节点资源分配大多借助下层操作系统和语言平台提供的支持机制而实现,这些机制在划分资源的同时,很难保证应用对资源使用的隔离性。面向应用的共享集群的资源管理工具技术白皮书3因此,本资源管理工具在中间件上提出一种基于虚拟机技术的节点资源划分机制,其核心思想是在中间件中实现对虚拟机监控器的封装,在底层利用虚拟机为每个应用实例隔离出一个独立的运行环境,并通过调用虚拟机监控器提供的资源操作原语,例如,设置为某个虚拟机划分的内存量,动态地为每个应用实例分配和回收资源;在上层由中间件完成从资源分配方案到下层资源操作原语的解释,并提供一组用于控制应用实例可使用资源的接口。支持应用按需部署的中间件动态配置框架中间件服务的动态配置是按需部署应用的必要条件。针对目前大多数中间件无法在运行时刻动态地配置中间件服务的种类和实现这一现状,本资源管理工具提出并实现了一种基于OSGi技术的中间件服务动态配置框架,其核心思想是首先在对中间件上容器和服务依赖关系进行梳理的基础上,基于OSGi中的构件模型对容器和服务进行封装,并在它们之间建立所需的静态和动态两种依赖关系,从而使得在运行时刻装载或卸载中间件服务成为可能;然后,增加对应用同中间件服务之间、中间件服务同容器之间、以及不同中间件服务之间的依赖关系的管理,其中包括对依赖关系的描述,和运行时刻解析,从而使得运行时刻中间件能够按照应用需要自动地完成对中间件服务的配置。面向应用的共享集群的资源管理工具技术白皮书4第二章分布式的资源分配动态规划方法本方法基于对应用的请求量预测和当前共享集群的资源分配状况,通过节点自身的资源评估和节点间的协作寻求出一种能较好满足各应用需求的资源分配规划方案,也即共享集群的每个节点部署哪些应用实例以及为该应用实例分配多少资源。由于不同的应用可能具有不同的重要程度,方法为每种应用请求赋予不同的价值,重要程度越高,价值越大,资源分配的目标是最大化应用请求的价值之和。目前,该方法仅考虑CPU和内存两类资源。方法核心思想描述如下所述:(1)方法将共享集群看成一个“市场”,集群中的节点看成“交易者”,应用的请求份额看成“商品”。节点通过“出售”和“购买”应用请求份额来完成对共享集群中资源的分配规划。(2)每个节点会周期性地对自身的资源使用情况进行评估,当它发现自身资源量不足以处理收到的请求时,它会主动向其它节点转让其所持有的应用请求份额;而当节点发现有资源空闲时,它会选择其它节点转让的应用请求份额进行出价,试图从其它节点处获得更多的应用请求份额。具体地说,每个节点将会自发的,周期性的进行下列操作:节点会根据当前的应用请求量,对自身的资源使用情况给出一个评估,判断是否能处理自身应用请求份额。如果不能处理,则会使用背包算法选择尽可能多的应用请求进行处理。该节点会根据评估结果决定自己在这一周期之内是转让部分的请求份额,还是获取更多的请求份额。当节点决定转让部分请求份额时,则它会将那些由于资源不足而不能处理的应用请求的份额通知其它节点。并等待其它节点的回复。当该节点决定获取更多的请求份额时,则它根据当前自身空闲的资源量以及其上运行的应用,从接收到的其它节点的请求份额转让消息中选择一定份额,进行“出价”,出价越高,表明该节点越希望获得这部分应用请求。当转让请求的节点接收到了其它节点的“出价”信息后,会将请求份额转让给“出价”较高的节点。其后的卖方节点将根据请求份额面向应用的共享集群的资源管理工具技术白皮书5的转让情况,通知请求分发器。“交易”过后双方节点都将进入下一个周期。(3)集群内有一个请求分发器,会接收用户发送至集群的所有请求,并按比例转发给集群内的节点。转发的比例与节点所持有的请求所属应用的份额保持一致。(4)经过一系列节点间自发的分散“交易”,整个集群趋于一个稳定的状态,集群中的资源利用率达到一个较高的值。图2分布式资源分配规划方法:例子为了更清楚的说明该方法,下面以一个例子来介绍方法的整个工作过程。如上图所示,集群初始状况(如图2(a))。若当前C应用的请求量增多,由于CPU资源的限制,1号节点无法处理所有C应用的请求。此时,假设该节点通过评估函数计算得出有50%的C应用无法处理。那么它会将“卖出50%C应用”的消息发送给集群其它节点。而自身CPU资源比较充足的50号和65号节点接收到了该消息(如图2(b)),并通过评估函数计算得出,分别需要应用C的35%份额和20%份额。它们将此消息以及计算出的“出价”告诉1号节点。最终1号节点予以回复,完成“交易”,并告知请求分发器修改应用请求份额。交易过后的各节点对自身的负载情况重新评估。此时,节点50根据背包算法,选择了一组不同于交易之前的应用请求份额进行处理,卸载了应用B的实例(释放内存),并装载了应用C的实例(如图2(c))。为了实现上述方法,需要在JO2nAS集群的基础上进行三个部分的扩展,分别是请求分发模块、节点资源规划模块和集群管理模块。总体设计框架如图3所示,应用请求统一由ApacheHttp服务器负责接收,并根据请求分发模块计算的结果,转发到集群中相应的物理节点上。集群的每个物理节点都运行着JO2nAS中间件,并装载了某些应用的实例。每个节点装载的应用实例不一定相同,每个应用实例所占用的资源也不一定相同。而每个节点应当装载哪些应用的实例,每个应用实例应该分配多少资源则由该节点上的节点资源规划模块实时计算得出,并根据请求量变化情况实时更改。整个集群当前的状态可通过集群管理模块察看。面向应用的共享集群的资源管理工具技术白皮书6图3资源分配规划工具设计图(1)节点资源规划模块节点资源规划模块通过相互间协调,来完成集群的资源分配规划。该模块根据接收的下一阶段请求量的变化信息,对节点自身的资源利用情况进行评估,并根据评估的结果相互通信协调集群资源的重新分配方案。得出的资源分配规划方案中,对应用请求份额的修改部分将通过告知请求分发模块修改分发比例予以实施,节点内的应用实例装卸载与资源分配部分将由底层的虚拟机控制模块负责实施。(2)请求分发模块请求分发模块是通过扩展Apache的mod_jk模块得来,它根据请求分发的比例,以代理服务器的方式将用户的请求转发至适当的集群节点。请求分发的比例,会根据实时接收节点资源规划模块发送的应用请求份额消息进行修改。(3)集群管理模块集群管理模块提供了一个方便集群管理员察看集群状态并管理集群的界面。该模块会从节点资源规划模块和请求分发模块中接收集群的当前状态信息,进行整理并显示出来。为了对资源分配规划方法的功能和性能进行了验证,我们进行了如下两部分试验:第一部分试验用于验证资源分配规划方法的有效性,证明其确实在JO2nAS集群上正常工作;第二部分试验通过一些模拟的方式,对方法的资源分配规划效面向应用的共享集群的资源管理工具技术白皮书7果和消息传递的代价进行了评估。资源分配规划方法有效性的验证通过模拟客户端,对含有资源分配规划方法的JO2nAS集群进行访问来验证资源分配方法的有效性。实验环境如下所述:1.实验中的集群包含10个节点,对外提供6个应用的服务,集群的节点拥有不同的性能,即节点的CPU和内存性能不同。2.每个节点的CPU资源总量是根据实际测试出来的对于应用的相对值。如根据实际测试,节点A在1秒内,能够处理10个用户对于应用B的请求,我们认为一个应用请