一种基于IAAS层应用感知的WEB多层应用动态资源调整方法.pdf

《一种基于IAAS层应用感知的WEB多层应用动态资源调整方法.pdf》由会员分享，可在线阅读，更多相关《一种基于IAAS层应用感知的WEB多层应用动态资源调整方法.pdf（18页珍藏版）》请在专利查询网上搜索。

1、10申请公布号CN104123189A43申请公布日20141029CN104123189A21申请号201410309032X22申请日20140630G06F9/50200601G06F9/45520060171申请人复旦大学地址200433上海市杨浦区邯郸路220号72发明人吕智慧王晶吴杰74专利代理机构上海正旦专利代理有限公司31200代理人陆飞盛志范54发明名称一种基于IAAS层应用感知的WEB多层应用动态资源调整方法57摘要本发明属于云计算和网络技术领域，具体为一种基于IAAS层应用感知的WEB多层应用动态资源调整方法。其步骤包括IAAS云平台对WEB多层应用架构的感知，即在传统的。

2、IAAS管理的基础上，增加对应用的管理及信息维护，以感知到IAAS层之上的WEB多层应用的状态；在感知基础上进行动态资源需求量化评估，即首先对其进行建模，进而提出WEB多层应用的动态资源需求的量化分析方法及算法；基于应用负载感知的资源动态调整，即在WEB多层应用负载发生变化时，及时检测到资源需求并量化，然后做出响应，以动态调整资源分配。本发明在不影响应用性能的情况下优化调整虚拟机的资源分配，避免潜在的资源浪费，提高了数据中心整体的资源利用率。51INTCL权利要求书4页说明书11页附图2页19中华人民共和国国家知识产权局12发明专利申请权利要求书4页说明书11页附图2页10申请公布号CN104。

3、123189ACN104123189A1/4页21一种基于IAAS层应用感知的WEB多层应用动态资源调整方法，其特征在于具体步骤为第一步IAAS云平台对WEB多层应用架构的感知在传统的IAAS管理的基础上，增加对WEB多层应用的管理及信息维护，以便能够感知其上部署的WEB多层应用及其状态；在用户向云平台申请资源时，与当前以虚拟机为粒度的部署方式不同，采用面向应用的构建方式；设用户可以申请M个虚拟机集群S1，S2，SM，其按序对应WEB多层应用的M个层次；对于每一个集群SI，用户可以选择部署一台或多台虚拟机作为初始配置；另外，设用户可以为每个集群配置未来进行资源调整的范围，即设定最少使用的虚拟机。

4、台数以及最多使用的虚拟机台数，分别标记为MINI和MAXI；其中，当某一集群的MINI和MAXI都设为1时，则认为该应用层次不能通过增加虚拟机来动态扩展；由此，除了获得传统IAAS云中用户期望的虚拟机资源配置信息外，同时得到用户应用的架构信息；将其应用信息总体标记为APPS1，S2，SM，其中|APP|体现应用的层数，而集合的每个元素SI记录当前的虚拟机配置数量|SI|以及MIN和MAX；云平台根据这些信息部署应用后，可以进一步追踪到每个层次每台虚拟机的放置位置，也即全面了解到该用户的应用在云中的部署情况；第二步WEB多层应用的动态资源需求的量化评估1WEB多层应用模型构建首先，从WEB多层应。

5、用的用户请求、服务能力、服务方式几个方面分析WEB多层应用的特征A应用的用户请求WEB多层应用的负载通常被认为是基于会话机制的用户请求，并且一个用户会话根据访问形式的不同，可能包括一系列请求；同一时刻，应用可以接受并处理众多并发用户请求；由于应用的用户请求是随机的，设两个连续到达的用户请求相隔的时间间隔相互独立，其到达情况服从泊松分布其中，表示请求到达的平均速度；B应用的服务能力一个应用程序通常能够对用户提供多种不同的服务；对于不同的服务类型，其响应时间也即服务时间，依赖于其所调用的应用程序和服务的实时状态；设所有服务类型的服务时间具有相同的概率分布，此外，它们之间的间隔时间也是相互独立的，服。

6、从负指数分布；对于WEB多层应用的每一层而言，其容器是一台虚拟机，或者是由几台虚拟机组成的集群；C应用的服务方式应用处理用户请求的顺序采用先来先服务模式；采用排队论的思想对WEB多层应用进行建模；典型的排队系统表示为X/Y/Z/A/B/C的形式，其中X表示顾客到达间隔时间分布，Y表示服务台服务时间分布，Z表示服务台个数，权利要求书CN104123189A2/4页3A表示系统容量限制，B表示顾客源总体数目，C表示服务规则；结合考虑WEB多层应用的特征，对于其每个层次，其用户请求到达时间服从泊松分布，同一层次的各台虚拟机的响应时间即服务时间服从负指数分布，其虚拟机数量为一台或多台，整个系统没有容量。

7、限制及用户通体数目限制，服务规则为先来先服务；所以，将其每个层次建模为一个M/M/C/FCFS型排队模型,也即M/M/C型；2WEB多层应用的资源需求量化评估方法基于以上WEB多层应用的队列模型，进一步提出量化评估应用每一层次的资源需求的方法，并通过增加新的虚拟机或关闭不必要的虚拟机来满足WEB多层应用的最佳资源配置；已知一个应用共有|APP|个层次，每层的虚拟机数目为|SI|I1,2,|APP|；对于应用的每个层次，将其建模为M/M/C型排队模型；首先，逐一考虑用户请求的到达率、应用的服务速率、应用的分层及总体的响应时间；其中，用户请求的到达率为每秒到达的用户请求数，应用的服务速率为应用每秒。

8、能够处理的用户请求数；用户请求的到达率WEB多层应用的第一层作为整个服务的入口，负责接收用户请求；应用的总请求到达率可以通过监控获得，其等于应用第一层的用户请求到达率，也即1；设一个用户请求离开应用第I层后直接进入第J层的概率为PIJ；特殊的，P0I表示用户请求直接从外部进入I层的概率；所有用户请求都从同一个入口即第一层进入应用，故P011，P0I0I2，3，|APP|；另外，PI0表示用户请求从I层直接离开应用的概率；对于应用的第I层，到达的用户请求在完成本层处理后，前往其他层次或离开系统的概率总和为1相似的，应用第I层的用户请求可能来自于从其他任意层次离开的请求，且每层的用户请求离开率等于。

9、其到达率，故该层总的请求率I为它们的总和，其中DJ表示第J层的用户请求离开率以上概率通过运行时或离线监控评估取得；应用的服务速率与服务强度设定WEB多层应用的同一层次的虚拟机采用相同的资源配置，都采用优化的贴近其应用特征的资源分配；用I表示应用第I层每一台虚拟机的服务速率；对于WEB多层应用的第I层整体而言，其平均服务速率为|SI|I，其中|SI|为该层的虚拟机数目，则该层系统的服务强度I为应用每层的响应时间权利要求书CN104123189A3/4页4根据M/M/C型排队模型，应用第I层用户请求的响应时间等于该请求在队列中的等待时间和平均服务时间的总和其中，WQI表示该请求在队列中的等待时间，。

10、计算方式如下式P0I表示第I层的系统稳态概率，即将67带入5，即可获得WEB多层应用第I层的响应时间；应用的总体端到端响应时间对于一个有|APP|个层次的WEB多层应用而言，可以计算出其总体的端到端响应时间等于各个层次响应时间的总和，这里用R标记将应用在SLA中期望的端到端响应时间标识为RSLA，为了保证应用的SLA，算法的目标即是对应用的每一层找到最小的|SI|，使得RRSLA；考虑比较严格的SLA保证方式，将其总体时间按照一定比例划分到每个层次，在具体计算时，如果某个层次的处理能力不匹配该层次的RISLA，则对其进行资源调整；3WEB多层应用的资源需求量化评估算法步骤首先，在应用持续运行期。

11、间，每隔几分钟监控一次应用的请求到达率，即；然后，以已知的一系列应用信息，包括当前应用的全局信息APP、各层次的服务速率、请求跳转概率等作为参数，对WEB多层应用的每个层次的资源需求进行量化评估；由此，计算出为满足SLA中该层应用的响应时间，其所需要的最低虚拟机数量，设为NUMI；最后，把该结果与当前已部署的虚拟机数量|SI|做对比如果NUMI|SI|，且小于该层次可部署的最多节点数量MAXI，则为其新开启NUMI|SI|台虚拟机；如果NUMI|SI|，且高于该层次的最少部署节点数量MINI，则关闭|SI|NUMI台虚拟机；否则，对该应用在当前的负载情况下，已无法做出更优的资源调整；第三步应用。

12、负载感知的资源动态调整根据第二步算法，在WEB多层应用负载发生变化时，及时检测到资源需求并做出响应，以动态调整资源分配；如果当前的资源配置不足以满足应用负载，则需要进行动态扩展、开启新的虚拟机；而当负载下降时，则可以采取动态收缩、关闭不必要的虚拟机，以减少资源浪费；基于相似性考量，设定对WEB多层应用的同一层次的集群中的所有虚拟机采用相同的资源分配，也即都采用根据其历史负载分析优化后的资源配置；应用负载感知的资源动态调整算法，在添加或减少虚拟机时，利用负载互补的思想促权利要求书CN104123189A4/4页5进资源共享、避免资源竞争；1资源动态扩展当对一个WEB多层应用的某个层次的集群进行扩。

13、展时，也即需要开启新的虚拟机以增加其服务能力时，该集群中已有的虚拟机在过去一段时间的负载表现能够体现出该应用层次的特征及趋势，故用于为新的虚拟机的放置选择提供参考；对于新增加的虚拟机，希望选择一台物理机，尽量使得新来的负载与该物理机上原有的负载错峰，从而提高潜在的资源共享能力；将互补的或相关性不强的负载放置在一起，通过填补未使用的资源而平衡整体负载的波动性，并且有效的提高资源利用率；在统计学中，皮尔逊相关系数用于度量两个变量X和Y之间的相关程度，其值介于1到1之间，其计算方式如下式所示借助以上公式，评估虚拟机负载时间序列与物理机负载时间序列的相关性，得到的结果越大，则说明二者相关性越强，应避免。

14、放置到一起；反之，则是比较优的候选对象；根据第二步3中算法的需求，即SCALEUPSI，NUMI|SI|函数，假设需要为应用的SI层开启NUMI|SI|台新虚拟机，这些虚拟机具有相同的资源配置需求，都采用优化后的虚拟机模板；对于物理机集群，首先对其根据剩余资源情况进行筛选，获得足够容纳待放置虚拟机的物理机列表LIST；这里，需要考虑多个资源维度，只有全部满足才能放置；由于应用每个层次之前具有一个请求分派器，使得用户请求按照一定的模式均衡的分配给各台服务器，所以，应用同一层次的多台虚拟机的历史负载波动情况非常类似；取该层次已有负载在过去一段时间的平均值作为虚拟机的潜在负载；将此负载与LIST中的。

15、各台物理机的历史负载计算RXY，选择值最小的将虚拟机部署在其上；当需要继续开启新的虚拟机时，更新该台物理机的可用资源，重新开始下一轮循环；2资源动态收缩相似的，当需要减少应用某一层次的虚拟机数量时，希望选择关闭其负载与承载它的物理机负载相关性最强的，从而平缓该物理机的资源消耗；根据第二步中3算法的需求，即SCALEDOWNSI,|SI|NUMI函数，假设需要为应用的SI层关闭|SI|NUMI台虚拟机；此时，在IAAS云中，对于该层次SI的每台虚拟机VMK，可以获知承载它的物理机PMK；通过监控功能分别取得VMK和PMK在过去一段时间的历史负载，利用公式8计算该虚拟机与物理机历史负载的相关性，结。

16、果记为RXY；在选择关闭对象时，根据RXY对各台虚拟机进行降序排列，选择值最高的、也就是相关性最强的一台关闭；如果这一轮循环还需要继续关闭虚拟机，则需要对物理机的历史负载进行处理，从中减去已关闭的虚拟机的负载值。权利要求书CN104123189A1/11页6一种基于IAAS层应用感知的WEB多层应用动态资源调整方法技术领域0001本发明属于云计算和新型网络技术领域，具体涉及一种WEB多层应用动态资源调整方法。背景技术0002近年来，云计算因其动态分配、弹性扩展、资源共享、按需使用按需付费等特点，吸引了越来越多的关注。云计算的出现不仅改变了当今IT基础设施的架构模式，也改变了云服务使用者获取IT。

17、资源、以及云服务提供者管理和提供软件、技术和解决方案的方式。0003云计算在为企业和用户带来便利的同时，也对云平台管理者提出了许多挑战。对于IAAS云而言，云平台的首要任务是要满足用户的资源需求，除此之外，如何从数据中心的层面更加合理的分配和使用资源、保证应用性能和可扩展性、优化整体的资源利用情况、并降低运维和管理成本，都是云管理者所面临的挑战，也是亟待解决问题。0004本发明关注IAAS私有云的运行时资源动态调整技术，在IAAS私有云的云环境下，云管理者通常具备更高的自主权和对云资源和其上应用的控制权，也即存在更广的优化空间。为解决资源合理分配的问题，本设计首先量化评估云环境中WEB多层应用。

18、负载的动态变化，在此基础上进一步提出了优化的WEB多层应用动态资源调整方案，主要的设计侧重于评估何时需要进行资源调整以及如何调整两方面。0005基于此，本发明利用业界主流的基准WEB多层应用，通过实验验证了所设计的应用负载感知的的WEB多层应用动态资源调整方法的正确性和有效性。0006经对现有技术的文献检索发现，以亚马逊EC2为代表的、采用虚拟机组、性能监控与用户配置策略相结合的自动伸缩服务解决方案，在业界具有一定的代表性。一方面，它能够在某种程度上满足资源随用户需求变化而动态的改变；另一方面，这样的方式降低了云服务提供商对云资源管理的复杂程度，也具备一定的通用性。然而，其仍存在以下一些不容忽。

19、视的局限性00071以虚拟机作为资源伸缩的单位。这样固定大小、粗粒度的解决方式，仍将造成资源的浪费。00082基于用户定义阈值的资源动态伸缩的触发条件不具有智能。用户其实很难自行、准确的描述资源供给与应用性能表现之间的关系，所以定义恰当的触发条件并不现实。00093应用无感知。当前的研究大多只考虑虚拟机本身的运行情况，而忽略了其中的应用特性，也忽略了相同应用中虚拟机之间的相互关系。0010针对以上问题，目前，虚拟资源动态伸缩模型的研究重点在于更加细粒度的资源调整方式，以及时、快速的响应应用负载的变化情况。另外，其负载自适应能力不仅需要依靠当前的负载情况，还希望能够预测出未来一段时间的工作负载变。

20、化，以更准确的、有前瞻性的调整虚拟资源大小。0011近期，一些关注于更精细的动态虚拟资源伸缩模式的学术研究开始涌现，但是，其说明书CN104123189A2/11页7出发点及所用方法大多仍相对简单、处于研究初期。文献DANIELAMENASCE,MOHAMEDNAUTONOMICVIRTUALIZEDENVIRONMENTSCINTERNATIONALCONFERENCEONAUTONOMICANDAUTONOMOUSSYSTEMS,2006；WEIMINGZHAO,ZHENLINWANG,YINGWEILUODYNAMICMEMORYBALANCINGFORVIRTUALMACHINESJA。

21、CMSIGOPSOPERATINGSYSTEMSREVIEW,2009仅考虑了单一资源的分配方式。其中，前者关注于计算资源的分配，它提出了一种随虚拟机工作负载变化而根据CPU优先级或CPU份额动态调整计算资源分配的方法；后者则通过预估每台虚拟机的内存使用量、并据此自动的调整内存分配大小，来提高内存资源的使用率。文献WENYUZHOU,SHOUBAOYANG,JUNFANG,ETALVMCTUNEALOADBALANCINGSCHEMEFORVIRTUALMACHINECLUSTERBASEDONDYNAMICRESOURCEALLOCATIONCINTERNATIONALCONFERENCEG。

22、RIDANDCOOPERATIVECOMPUTING,2010；TIMOTHYWOOD,PRASHANTSHENOY,ARUNVENKATARAMANI,ETALSANDPIPERBLCAKBOXANDGRAYBOXRESOURCEMANAGEMENTFORVIRTUALMACHINESJCOMPUTERNETWORKS,2009则多方面考虑了CPU、内存和网络带宽三种资源的综合优化分配方式。其中，前者提出了一种应用无关的负载均衡机制，通过实时监控物理机及虚拟机的各项资源使用情况，及时调整资源分配；后者则提出了一个自治系统，利用自动资源监测及热点检测，确定物理资源到虚拟资源的重新分配。0012。

23、近期的研究开始关注面向应用的虚拟资源动态调整方案,旨在通过对应用性能进行分析，来帮助应用程序所有者做出资源调整的决策。其中，云中的多层应用MULTITIERAPPLICATION开始成为关注的重点。文献BURGAONKAR,PSHENOY,ACHANDRA,DYNAMICPROVISIONINGOFMULTILIERINTERNETAPPLICATIONCSECONDINTERNATIONALCONFERENCEONAUTONOMICCOMPUTING,ICAC,2005；URGAONKAR,PSHENOY,ACHANDRA,DYNAMICPROVISIONINGOFMULTILIERINTE。

24、RNETAPPLICATIONACMTRANSACTIONSONAUTONOMOUSANDADAPTIVESYSTEMS,3,2008提出了针对多层WEB应用的动态的容量配置模型，确定为应用的每层分配多少资源，以及通过预测和被动响应相结合的方式决定何时分配。类似的，文献WIQBAL,MNDAILEY,DCARRERA,PJANECEKADAPTIVERESOURCEPROVISIONINGFORREADINTENSIVEMULTITIERAPPLICATIONSINTHECLOUDJFUTUREGENERATIONCOMPUTERSYSTEMS27,2011为两层WEB应用提出了基于被动响应的。

25、动态扩展以及基于预测的收缩的资源调整方法。文献DABACIGALUPO,JVANHEMERT,XCHEN,ETALMANAGINGDYNAMICENTERPRISEANDURGENTWORKLOADSONCLOUDSUSINGLAYEREDQUEUINGANDHISTORICALPERFORMANCEMODELS,SIMULATIONMODELLINGPRACTICEANDTHEORY19,2011利用排队论的思想将应用建模为三个层次，即程序、数据库和数据库磁盘层，然后对每一层分析平均响应时间、吞吐量和服务器资源利用率用以调整资源分配。文献RHAN,MMGHANEM,LGUO,YETALENA。

26、BLINGCOSTAWAREANDADAPTIVEELASTICITYOFMULTITIERCLOUDAPPLICATIONJFUTUREGENERATIONCOMPUTERSYSTEMS,JUNE2012在进行以虚拟机为粒度的资源动态调整时，还兼顾考虑的了不同虚拟机的部署成本。但是它们多采用了较简单的队列模型,存在较多的扩展空间。因此，本发明提出一种基于IAAS层应用感知的WEB多层应用动态资源调整方法。发明内容说明书CN104123189A3/11页80013本发明的目的在于提出一种基于IAAS层应用感知的WEB多层应用动态资源调整方法。0014本发明提出的基于IAAS层应用感知的WEB多。

27、层应用动态资源调整方法，具体步骤为0015第一步IAAS云平台对WEB多层应用架构的感知0016IAAS云平台所管理的对象是多台虚拟机，其理论上是无法感知用户应用的。为了更好的为云中的应用提供性能保证，本发明在传统的IAAS管理的基础上，增加对WEB多层应用的管理及信息维护，以便能够感知其上部署的应用及其状态，这也将为后续的动态资源调整提供支持。0017在用户向云平台申请资源时，与当前以虚拟机为粒度的部署方式不同，本发明采用面向应用的构建方式。用户可以申请M个虚拟机集群S1，S2，SM，其按序对应WEB多层应用的M个层次。对于每一个集群SI，用户可以选择部署一台或多台虚拟机作为初始配置；为了简。

28、化设计，规定它们使用相同的资源配置和镜像文件。另外，用户还可以为每个集群配置未来进行资源调整的范围，也即设定最少使用的虚拟机台数以及最多使用的虚拟机台数，分别标记为MINI和MAXI。其中，当某一集群的MINI和MAXI都设为1时，则认为该应用层次不能通过增加虚拟机来动态扩展。0018由此，除了获得了传统IAAS云中用户期望的虚拟机资源配置信息外，也同时得到了用户应用的架构信息。将其应用信息总体标记为APPS1，S2，SM，其中|APP|体现了应用的层数，而集合的每个元素SI记录了当前的虚拟机配置数量|SI|以及MIN和MAX。云平台根据这些信息部署应用后，可以进一步追踪到每个层次每台虚拟机的。

29、放置位置，也即全面了解到该用户的应用在云中的部署情况。0019第二步WEB多层应用的动态资源需求量化评估00201WEB多层应用模型构建0021首先，从WEB多层应用的用户请求、服务能力、服务方式等几个方面分析WEB多层应用的特征00221应用的用户请求0023WEB多层应用的负载通常被认为是基于会话SESSION机制的用户请求，并且一个用户会话根据访问形式的不同，可能包括一系列请求。同一时刻，应用可以接受并处理众多并发用户请求。0024由于应用的用户请求是随机的，可以认为，两个连续到达的用户请求相隔的时间间隔相互独立，其到达情况服从泊松分布POISSONDISTRIBUTION0025002。

30、6其中，表示请求到达的平均速度。0027考虑更复杂的情况，在WEB多层应用的各个层次之间，前一层次的某个到达请求可能触发零个或多个请求到某一层。例如，一个静态网页的请求通过应用的WEB层就能得到响应，而关键字搜索则需要被触发到下一层的多个请求。对于特定的应用，由于其每个层次所触发到其他层次的请求具有一定的规律性，所以近似认为各层的用户请求也满足泊松分布。说明书CN104123189A4/11页900282应用的服务能力0029一个应用程序通常能够对用户提供多种不同的服务，例如，一个WEB应用可以提供用户登录、浏览、请求数据、上传数据等不同功能。对于不同的服务类型，其响应时间也即服务时间，依赖于。

31、其所调用的应用程序和服务的实时状态。可以近似认为，所有服务类型的服务时间具有相同的概率分布。此外，它们之间的间隔时间也是相互独立的，服从负指数分布。0030对于WEB多层应用的每一层而言，其容器可能是一台虚拟机，或者是由几台虚拟机组成的集群。00313应用的服务方式0032应用处理用户请求的顺序可能存在多种方式，如先来先服务FIRSTCOMEFIRSTSERVED、后来先服务LASTCOMEFIRSTSERVED、最短处理时间优先SHORTESTPROCESSINGTIMEFIRST、随机处理等等。这里，本设计考虑最常规的也是最通用的先来先服务模式。0033基于上述对WEB多层应用的特征分析，。

32、可以看出，用户请求及应用处理的模式符合典型的队列模型，故可以采用排队论QUEUINGTHEORY的思想对WEB多层应用进行建模。排队论作为运筹学研究的一种有力手段，通常研究系统随机聚散现象和随机服务系统工作过程的数学理论和方法，可用于排队系统的优化。排队论在理论上相对成熟，且应用场景广泛。0034一个典型的排队系统可以用国际排队论标准化会议提出的表示法表示为X/Y/Z/A/B/C的形式，其中X表示顾客到达间隔时间分布，Y表示服务台服务时间分布，Z表示服务台个数，A表示系统容量限制，B表示顾客源总体数目，C表示服务规则。0035结合考虑WEB多层应用的特征，对于其每个层次，其用户请求到达时间服从。

33、泊松分布，同一层次的各台虚拟机的响应时间即服务时间服从负指数分布，其虚拟机数量可以为一台或多台，整个系统没有容量限制及用户通体数目限制，服务规则为先来先服务。所以，本发明提出将其每个层次建模为一个M/M/C/FCFS型排队模型,也即M/M/C型。这样的建模相比采用M/M/1模型，更贴近真实的情况。00362WEB多层应用的资源需求量化评估方法0037基于以上WEB多层应用的队列模型，本发明进一步提出量化评估应用每一层次的资源需求的方法，并通过增加新的虚拟机或关闭不必要的虚拟机来满足WEB多层应用的最佳资源配置。0038已知一个应用共有|APP|个层次，每层的虚拟机数目为|SI|I1,2,|AP。

34、P|。对于应用的每个层次，将其建模为M/M/C型排队模型。首先，需要逐一考虑用户请求的到达率、应用的服务速率、应用的分层及总体的响应时间等。其中，用户请求的到达率为每秒到达的用户请求数，应用的服务速率为应用每秒能够处理的用户请求数。0039显然，在合理的情况下，用户请求的到达率应该低于应用的服务速率，否则，将导致队列长度无限增长，使得队列甚至系统不稳定。故可以认为，对于每一层而言，服务能力大于用户请求情况,且用户请求的到达率等于用户请求的离开率。0040用户请求的到达率0041WEB多层应用的第一层作为整个服务的入口，负责接收用户请求。应用的总请求到说明书CN104123189A5/11页10。

35、达率可以通过监控获得，其等于应用第一层的用户请求到达率，也即1。0042考虑到根据请求类型的不同，用户请求在离开某一层次后，有可能被以一定的概率转发到其他任意层，也可能直接离开应用将结果返回给用户。以三层WEB应用为例，用户请求到达WEB服务器后，可能直接取得了静态页面而返回，也可能需要继续前往APP层处理业务逻辑或从数据库层拉取数据。0043设一个用户请求离开应用第I层后直接进入第J层的概率为PIJ。特殊的，P0I表示用户请求直接从外部进入I层的概率，根据以上分析，所有用户请求都从同一个入口即第一层进入应用，故P011，P0I0I2，|APP|；另外，PI0表示用户请求从I层直接离开应用的概。

36、率。0044由此可知，对于应用的第I层，到达的用户请求在完成本层处理后，前往其他层次或离开系统的概率总和为100450046相似的，应用第I层的用户请求可能来自于从其他任意层次离开的请求，且每层的用户请求离开率等于其到达率，故该层总的请求率I为它们的总和，其中DJ表示第J层的用户请求离开率00470048其中，以上概率可以通过运行时或离线监控评估取得。0049应用的服务速率与服务强度0050这里，设定WEB多层应用的同一层次的虚拟机采用相同的资源配置，都采用优化的贴近其应用特征的资源分配。故可以认为，它们具有相同或相似服务能力，也即服务速率相等。用I表示应用第I层每一台虚拟机的服务速率。005。

37、1对于WEB多层应用的第I层整体而言，其平均服务速率为|SI|I，其中|SI|为该层的虚拟机数目。则该层系统的服务强度I为00520053应用每层的响应时间0054分析了应用的用户请求率及服务器的服务速率，即可以利用排队论的思想计算应用每一层次的响应时间。0055根据M/M/C型排队模型，应用第I层用户请求的响应时间等于该请求在队列中的等待时间和平均服务时间的总和00560057其中，WQI表示该请求在队列中的等待时间，计算方式如下式说明书CN104123189A106/11页1100580059P0I表示第I层的系统稳态概率，即00600061将67带入5，即可获得WEB多层应用第I层的响应。

38、时间。0062应用的总体端到端响应时间0063对于一个有|APP|个层次的WEB多层应用而言，本设计方法可以计算出其总体的端到端响应时间等于各个层次响应时间的总和，这里用R标记00640065将应用在SLA中期望的端到端响应时间标识为RSLA。可见，为了保证应用的SLA，算法的目标即是对应用的每一层找到最小的|SI|，使得RRSLA。0066这里，我们考虑比较严格的SLA保证方式，将其总体时间按照一定比例划分到每个层次。在具体计算时，如果某个层次的处理能力不匹配该层次的RISLA，则对其进行资源调整。0067为了清楚起见，下表总结了本节用到的主要符号集，并给出了相关描述信息。0068表1WEB。

39、多层应用的资源需求量化符号0069符号描述数据来源RSLA应用在SLA中协定的端到端响应时间SLA协定RISLA应用第I层的期望响应时间离线分析R应用的端到端响应时间计算RI应用第I层的响应时间计算I应用第I层的用户请求到达率实时监控I应用第I层每台服务器的服务速率离线分析I应用第I层的服务强度计算PIJ用户请求离开I层后直接进入J层的概率离线分析P0I用户请求直接从外部进入I层的概率离线分析说明书CN104123189A117/11页12PI0用户请求从I层直接离开应用的概率离线分析00703WEB多层应用的资源需求量化评估算法设计0071首先，在应用持续运行期间，每隔几分钟监控一次应用的请。

40、求到达率，即。然后，以已知的一系列应用信息，包括当前应用的全局信息APP、各层次的服务速率、请求跳转概率等作为参数，对WEB多层应用的每个层次的资源需求进行量化评估。由此，可以计算出为满足SLA中该层应用的响应时间，其所需要的最低虚拟机数量，设为NUMI。最后，把该结果与当前已部署的虚拟机数量|SI|做对比如果NUMI|SI|，且小于该层次可部署的最多节点数量MAXI，则为其新开启NUMI|SI|台虚拟机；如果NUMI|SI|，且高于该层次的最少部署节点数量MINI则可以关闭|SI|NUMI台虚拟机；否则，对该应用在当前的负载情况下，已无法做出更优的资源调整。0072具体算法的伪码如下所示。0。

41、07300740075其中，SCALEUP函数和SCALEDOWN函数分别表示为应用的第I层开启NUMI|SI|台虚拟机和关闭|SI|NUMI台虚拟机0076第三步应用负载感知的资源动态调整0077根据第二步提出的算法，可以在WEB多层应用负载发生变化时，及时检测到资源需求并做出响应，以动态调整资源分配。如果当前的资源配置不足以满足应用负载，则需要进行动态扩展、开启新的虚拟机；而当负载下降时，则可以采取动态收缩、关闭不必要的虚拟机，以减少资源浪费。基于相似性考量，设定对WEB多层应用的同一层次的集群中的所有虚拟机采用相同的资源分配，也即都采用根据其历史负载分析优化后的资源配置。0078在进行资。

42、源动态调整时，引出了另一个问题如果需要开启新的虚拟机，应该将其放置在哪台物理机上更合理如果需要关闭虚拟机，应该选择关闭哪台0079虚拟机的放置策略对于整体云平台的资源利用率具有重要的影响，其应结合考虑说明书CN104123189A128/11页13当前云平台已经承载的应用负载。如果一个新的虚拟机能够与已经运行在云中的虚拟机负载互补或错峰，则可以潜在的避免资源竞争、减少资源消耗，也即以更少的资源承载更多的应用。相似的，当关闭虚拟机时，如果能够选择对当前环境负载影响最大的那一台，则可以有效平缓资源消耗，以期能够在未来承载更多新负载。0080本步骤提出了应用负载感知的资源动态调整算法，在添加或减少虚。

43、拟机时，利用负载互补的思想促进资源共享、避免资源竞争。这里的负载我们考虑最关键的也是潜在竞争最强的单一资源CPU。算法的目标是最大化物理资源的利用率，同时又不影响应用的SLA。00811资源动态扩展0082当对一个WEB多层应用的某个层次的集群进行扩展时，也即需要开启新的虚拟机以增加其服务能力时，该集群中已有的虚拟机在过去一段时间的负载表现能够体现出该应用层次的特征及趋势，故可以用于为新的虚拟机的放置选择提供参考。0083对于新增加的虚拟机，希望选择一台物理机，尽量使得新来的负载与该物理机上原有的负载错峰，从而提高潜在的资源共享能力。将互补的或相关性不强的负载放置在一起，可以通过填补未使用的资。

44、源而平衡了整体负载的波动性，并且有效的提高资源利用率。0084在统计学中，皮尔逊相关系数PEARSONCOEFCIENT常用于度量两个变量X和Y之间的相关程度，其值介于1到1之间。其计算方式如下式所示。00850086借助以上公式，可以评估虚拟机负载时间序列与物理机负载时间序列的相关性。得到的结果越大，则说明二者相关性越强，应避免放置到一起；反之，则是比较优的候选对象。0087根据第二步3节中算法的需求，即SCALEUPSI，NUMI|SI|函数，假设需要为应用的SI层开启NUMI|SI|台新虚拟机，这些虚拟机具有相同的资源配置需求，都采用优化后的虚拟机模板。对于物理机集群，首先对其根据剩余资。

45、源情况进行筛选，获得足够容纳待放置虚拟机的物理机列表LIST。这里，需要考虑多个资源维度，如CPU和内存，只有全部满足才能放置。由于应用每个层次之前具有一个请求分派器，使得用户请求按照一定的模式均衡的分配给各台服务器，所以，我们可以认为，应用同一层次的多台虚拟机的历史负载波动情况非常类似。取该层次已有负载在过去一段时间如2小时的平均值作为虚拟机的潜在负载。由于这样的相关性判断是为了判定物理机上已有的虚拟机与新增加负载的冲突情况，所以不考虑使用新的NUMI进行平均。此时，将此负载与LIST中的各台物理机的历史负载计算RXY，选择值最小的将虚拟机部署在其上。当需要继续开启新的虚拟机时，我们更新该台。

46、物理机的可用资源，重新开始下一轮循环。00882资源动态收缩0089相似的，当需要减少应用某一层次的虚拟机数量时，希望选择关闭其负载与承载它的物理机负载相关性最强的，从而平缓该物理机的资源消耗。0090根据第二步中3节算法的需求，即SCALEDOWNSI，|SI|NUMI函数，假设需要为应用的SI层关闭|SI|NUMI台虚拟机。此时，在IAAS云中，对于该层次SI的每台虚拟机VMK，说明书CN104123189A139/11页14可以获知承载它的物理机PMK。通过监控功能分别取得VMK和PMK在过去一段时间如2小时的历史负载，利用公式8计算该虚拟机与物理机历史负载的相关性，结果记为RXY。在选。

47、择关闭对象时，根据RXY对各台虚拟机进行降序排列，选择值最高的、也就是相关性最强的一台关闭。如果这一轮循环还需要继续关闭虚拟机，则需要对物理机的历史负载进行处理，从中减去已关闭的虚拟机的负载值。0091本发明在不影响应用性能的情况下优化调整虚拟机的资源分配，避免潜在的资源浪费，提高了数据中心整体的资源利用率。附图说明0092图1用户请求率及对应的RUBIS应用服务器台数。0093图2RUBIS应用90情况下的请求响应时间。0094图3RUBIS应用服务器的CPU资源使用情况。0095图4为本发明方法的总体构架。具体实施方式00961实验环境0097首先介绍本发明的实验环境，包括硬件环境和软件环。

48、境。0098在硬件方面，采用3台物理机作为云资源池，它们具有相同的物理资源配置，参见下表；另外，使用一台相同的物理机作为总控制台。为了兼容所选择的测试应用，选择安装FEDORA5和XEN303版本的虚拟化软件。0099表2实验环境0100物理机CPUINTELI52400，四核，310GHZ物理机内存4GB操作系统FEDORA5虚拟化软件XEN3030101在软件方面，选取业界主流的开源基准BENCHMARKWEB多层应用RUBIS应用。RUBIS由RICE大学开发，之后常被用于验证WEB多层应用相关的设计及算法的有效性。它实现了与EBAY类似的、包含所有核心功能的在线拍卖网站，包括用户注册、。

49、浏览、买卖产品等。0102利用APACHEJMETER作为RUBISWEB应用的客户端压力和性能测试工具，其可以用于对服务器、网络或对象模拟巨大的客户端访问负载，来在不同压力类别下测试它们的强度并分析整体性能。根据RUBIS应用的特征，在JMETER中配置的用户操作尽可能覆盖各种RUBIS支持的行为，且调整其比例使之更符合真实的用户访问网站的操作流程。为了避免JMETER成为实验的瓶颈，采用分布式的部署方式。0103选用两层的PHP版本的RUBIS应用用作测试。初始情况下，部署两台虚拟机，如表3所示，其中一个作为前台的APACHE22WEB服务器，另外一台则是后台的MYSQL40数据库。说明书CN104123189A1410/11页15对这两台虚拟机，为它们各自分配2个VCPU和1G内存。另外，对其可以调整的资源范围，即虚拟机台数的上限及下限。DB由于其版本的特性，不能通过增加虚拟机的方式进行动态伸缩，故固定为1台；而APACHE可以方便的进行扩展，可以设定其范围为15台。0104表3三层应用部署0105虚拟机CPU内存MINMAXAPACHE2VCPU1G15DB2VCPU1G110106另外，为了验证之后多台APACHE服务器的情形，我们还在R。