CN104123189B - 一种基于IaaS层应用感知的Web多层应用动态资源调整方法 - Google Patents

Abstract

本发明属于云计算和网络技术领域，具体为一种基于IaaS层应用感知的Web多层应用动态资源调整方法。其步骤包括：IaaS云平台对Web多层应用架构的感知，即在传统的IaaS管理的基础上，增加对应用的管理及信息维护，以感知到Iaas层之上的Web多层应用的状态；在感知基础上进行动态资源需求量化评估，即首先对其进行建模，进而提出Web多层应用的动态资源需求的量化分析方法及算法；基于应用负载感知的资源动态调整，即在Web多层应用负载发生变化时，及时检测到资源需求并量化，然后做出响应，以动态调整资源分配。本发明在不影响应用性能的情况下优化调整虚拟机的资源分配，避免潜在的资源浪费，提高了数据中心整体的资源利用率。

Description

一种基于IaaS层应用感知的Web多层应用动态资源调整方法

技术领域

本发明属于云计算和新型网络技术领域，具体涉及一种Web多层应用动态资源调整方法。

背景技术

近年来，云计算因其动态分配、弹性扩展、资源共享、按需使用按需付费等特点，吸引了越来越多的关注。云计算的出现不仅改变了当今IT基础设施的架构模式，也改变了云服务使用者获取IT资源、以及云服务提供者管理和提供软件、技术和解决方案的方式。

云计算在为企业和用户带来便利的同时，也对云平台管理者提出了许多挑战。对于IaaS云而言，云平台的首要任务是要满足用户的资源需求，除此之外，如何从数据中心的层面更加合理的分配和使用资源、保证应用性能和可扩展性、优化整体的资源利用情况、并降低运维和管理成本，都是云管理者所面临的挑战，也是亟待解决问题。

本发明关注IaaS私有云的运行时资源动态调整技术，在IaaS私有云的云环境下，云管理者通常具备更高的自主权和对云资源和其上应用的控制权，也即存在更广的优化空间。为解决资源合理分配的问题，本设计首先量化评估云环境中Web多层应用负载的动态变化，在此基础上进一步提出了优化的Web多层应用动态资源调整方案，主要的设计侧重于评估何时需要进行资源调整以及如何调整两方面。

基于此，本发明利用业界主流的基准Web多层应用，通过实验验证了所设计的应用负载感知的的Web多层应用动态资源调整方法的正确性和有效性。

经对现有技术的文献检索发现，以亚马逊EC2为代表的、采用虚拟机组、性能监控与用户配置策略相结合的自动伸缩服务解决方案，在业界具有一定的代表性。一方面，它能够在某种程度上满足资源随用户需求变化而动态的改变；另一方面，这样的方式降低了云服务提供商对云资源管理的复杂程度，也具备一定的通用性。然而，其仍存在以下一些不容忽视的局限性：

1.以虚拟机作为资源伸缩的单位。这样固定大小、粗粒度的解决方式，仍将造成资源的浪费。

2.基于用户定义阈值的资源动态伸缩的触发条件不具有智能。用户其实很难自行、准确的描述资源供给与应用性能表现之间的关系，所以定义恰当的触发条件并不现实。

3.应用无感知。当前的研究大多只考虑虚拟机本身的运行情况，而忽略了其中的应用特性，也忽略了相同应用中虚拟机之间的相互关系。

针对以上问题，目前，虚拟资源动态伸缩模型的研究重点在于更加细粒度的资源调整方式，以及时、快速的响应应用负载的变化情况。另外，其负载自适应能力不仅需要依靠当前的负载情况，还希望能够预测出未来一段时间的工作负载变化，以更准确的、有前瞻性的调整虚拟资源大小。

近期，一些关注于更精细的动态虚拟资源伸缩模式的学术研究开始涌现，但是，其出发点及所用方法大多仍相对简单、处于研究初期。文献[Daniel A.Menasc′e,MohamedN.Autonomic Virtualized Environments[C].International Conference on Autonomicand Autonomous Systems,2006；Weiming Zhao,Zhenlin Wang,Yingwei Luo.Dynamicmemory balancing for virtual machines[J].ACM SIGOPS Operating Systems Review,2009.]仅考虑了单一资源的分配方式。其中，前者关注于计算资源的分配，它提出了一种随虚拟机工作负载变化而根据CPU优先级或CPU份额动态调整计算资源分配的方法；后者则通过预估每台虚拟机的内存使用量、并据此自动的调整内存分配大小，来提高内存资源的使用率。文献[Wenyu Zhou,Shoubao Yang,Jun Fang,et al.VMCTune:A Load BalancingScheme for Virtual Machine Cluster based on Dynamic Resource Allocation[C].International Conference Grid and Cooperative Computing,2010；Timothy Wood,Prashant Shenoy,Arun Venkataramani,et al.Sandpiper:Blcak-box and gray-boxresource management for virtual machines[J].Computer Networks,2009.]则多方面考虑了CPU、内存和网络带宽三种资源的综合优化分配方式。其中，前者提出了一种应用无关的负载均衡机制，通过实时监控物理机及虚拟机的各项资源使用情况，及时调整资源分配；后者则提出了一个自治系统，利用自动资源监测及热点检测，确定物理资源到虚拟资源的重新分配。

近期的研究开始关注面向应用的虚拟资源动态调整方案,旨在通过对应用性能进行分析，来帮助应用程序所有者做出资源调整的决策。其中，云中的多层应用(Multi-tierApplication)开始成为关注的重点。文献[B.Urgaonkar,P.Shenoy,A.Chandra,Dynamicprovisioning of multi-lier Internet Application[C].Second InternationalConference on Autonomic Computing,ICAC,2005；Urgaonkar,P.Shenoy,A.Chandra,Dynamic provisioning of multi-lier Internet Application ACM Transactions onAutonomous and Adaptive Systems,3,2008.]提出了针对多层Web应用的动态的容量配置模型，确定为应用的每层分配多少资源，以及通过预测和被动响应相结合的方式决定何时分配。类似的，文献[W.Iqbal,M.N.Dailey,D.Carrera,P.Janecek.Adaptive resourceprovisioning for read intensive multi-tier applications in the cloud[J].Future Generation Computer Systems27,2011.]为两层Web应用提出了基于被动响应的动态扩展以及基于预测的收缩的资源调整方法。文献[D.A.Bacigalupo,J.van Hemert,X.Chen,et al.Managing dynamic enterprise and urgent workloads on clouds usinglayered queuing and historical performance models,Simulation ModellingPractice and Theory19,2011.]利用排队论的思想将应用建模为三个层次，即程序、数据库和数据库磁盘层，然后对每一层分析平均响应时间、吞吐量和服务器资源利用率用以调整资源分配。文献[R Han,MM Ghanem,L Guo,Y et al.Enabling cost-aware andadaptive elasticity of multi-tier cloud application[J].Future GenerationComputer Systems,June2012.]在进行以虚拟机为粒度的资源动态调整时，还兼顾考虑的了不同虚拟机的部署成本。但是它们多采用了较简单的队列模型,存在较多的扩展空间。因此，本发明提出一种基于IaaS层应用感知的Web多层应用动态资源调整方法。

发明内容

本发明的目的在于提出一种基于IaaS层应用感知的Web多层应用动态资源调整方法。

本发明提出的基于IaaS层应用感知的Web多层应用动态资源调整方法，具体步骤为：

第一步:IaaS云平台对Web多层应用架构的感知

IaaS云平台所管理的对象是多台虚拟机，其理论上是无法感知用户应用的。为了更好的为云中的应用提供性能保证，本发明在传统的IaaS管理的基础上，增加对Web多层应用的管理及信息维护，以便能够感知其上部署的应用及其状态，这也将为后续的动态资源调整提供支持。

在用户向云平台申请资源时，与当前以虚拟机为粒度的部署方式不同，本发明采用面向应用的构建方式。用户可以申请m个虚拟机集群{S₁，S₂，...，S_m}，其按序对应Web多层应用的m个层次。对于每一个集群S_i，用户可以选择部署一台或多台虚拟机作为初始配置；为了简化设计，规定它们使用相同的资源配置和镜像文件。另外，用户还可以为每个集群配置未来进行资源调整的范围，也即设定最少使用的虚拟机台数以及最多使用的虚拟机台数，分别标记为min_i和max_i。其中，当某一集群的min_i和max_i都设为1时，则认为该应用层次不能通过增加虚拟机来动态扩展。

由此，除了获得了传统IaaS云中用户期望的虚拟机资源配置信息外，也同时得到了用户应用的架构信息。将其应用信息总体标记为App＝{S₁，S₂，...，S_m}，其中|App|体现了应用的层数，而集合的每个元素S_i记录了当前的虚拟机配置数量|S_i|以及min和max。云平台根据这些信息部署应用后，可以进一步追踪到每个层次每台虚拟机的放置位置，也即全面了解到该用户的应用在云中的部署情况。

第二步:Web多层应用的动态资源需求量化评估

(1)Web多层应用模型构建

首先，从Web多层应用的用户请求、服务能力、服务方式等几个方面分析Web多层应用的特征：

1.应用的用户请求

Web多层应用的负载通常被认为是基于会话(Session)机制的用户请求，并且一个用户会话根据访问形式的不同，可能包括一系列请求。同一时刻，应用可以接受并处理众多并发用户请求。

由于应用的用户请求是随机的，可以认为，两个连续到达的用户请求相隔的时间间隔相互独立，其到达情况服从泊松分布(Poisson Distribution)

其中，λ表示请求到达的平均速度。

考虑更复杂的情况，在Web多层应用的各个层次之间，前一层次的某个到达请求可能触发零个或多个请求到某一层。例如，一个静态网页的请求通过应用的Web层就能得到响应，而关键字搜索则需要被触发到下一层的多个请求。对于特定的应用，由于其每个层次所触发到其他层次的请求具有一定的规律性，所以近似认为各层的用户请求也满足泊松分布。

2.应用的服务能力

一个应用程序通常能够对用户提供多种不同的服务，例如，一个Web应用可以提供用户登录、浏览、请求数据、上传数据等不同功能。对于不同的服务类型，其响应时间也即服务时间，依赖于其所调用的应用程序和服务的实时状态。可以近似认为，所有服务类型的服务时间具有相同的概率分布。此外，它们之间的间隔时间也是相互独立的，服从负指数分布。

对于Web多层应用的每一层而言，其容器可能是一台虚拟机，或者是由几台虚拟机组成的集群。

3.应用的服务方式

应用处理用户请求的顺序可能存在多种方式，如先来先服务(First Come FirstServed)、后来先服务(Last Come First Served)、最短处理时间优先(ShortestProcessing Time First)、随机处理等等。这里，本设计考虑最常规的也是最通用的先来先服务模式。

基于上述对Web多层应用的特征分析，可以看出，用户请求及应用处理的模式符合典型的队列模型，故可以采用排队论(Queuing Theory)的思想对Web多层应用进行建模。排队论作为运筹学研究的一种有力手段，通常研究系统随机聚散现象和随机服务系统工作过程的数学理论和方法，可用于排队系统的优化。排队论在理论上相对成熟，且应用场景广泛。

一个典型的排队系统可以用国际排队论标准化会议提出的表示法表示为X/Y/Z/A/B/C的形式，其中X表示顾客到达间隔时间分布，Y表示服务台服务时间分布，Z表示服务台个数，A表示系统容量限制，B表示顾客源总体数目，C表示服务规则。

结合考虑Web多层应用的特征，对于其每个层次，其用户请求到达时间服从泊松分布，同一层次的各台虚拟机的响应时间即服务时间服从负指数分布，其虚拟机数量可以为一台或多台，整个系统没有容量限制及用户通体数目限制，服务规则为先来先服务。所以，本发明提出将其每个层次建模为一个M/M/c/∞/∞/FCFS型排队模型,也即M/M/c型。这样的建模相比采用M/M/1模型，更贴近真实的情况。

(2)Web多层应用的资源需求量化评估方法

基于以上Web多层应用的队列模型，本发明进一步提出量化评估应用每一层次的资源需求的方法，并通过增加新的虚拟机或关闭不必要的虚拟机来满足Web多层应用的最佳资源配置。

已知一个应用共有|App|个层次，每层的虚拟机数目为|S_i|(i＝1,2,…,|App|)。对于应用的每个层次，将其建模为M/M/c型排队模型。首先，需要逐一考虑用户请求的到达率、应用的服务速率、应用的分层及总体的响应时间等。其中，用户请求的到达率为每秒到达的用户请求数，应用的服务速率为应用每秒能够处理的用户请求数。

显然，在合理的情况下，用户请求的到达率应该低于应用的服务速率，否则，将导致队列长度无限增长，使得队列甚至系统不稳定。故可以认为，对于每一层而言，服务能力大于用户请求情况,且用户请求的到达率等于用户请求的离开率。

用户请求的到达率

Web多层应用的第一层作为整个服务的入口，负责接收用户请求。应用的总请求到达率λ可以通过监控获得，其等于应用第一层的用户请求到达率，也即λ＝λ₁。

考虑到根据请求类型的不同，用户请求在离开某一层次后，有可能被以一定的概率转发到其他任意层，也可能直接离开应用将结果返回给用户。以三层Web应用为例，用户请求到达Web服务器后，可能直接取得了静态页面而返回，也可能需要继续前往App层处理业务逻辑或从数据库层拉取数据。

设一个用户请求离开应用第i层后直接进入第j层的概率为p_ij。特殊的，p_0i表示用户请求直接从外部进入i层的概率，根据以上分析，所有用户请求都从同一个入口即第一层进入应用，故p₀₁＝1，p_0i＝0(i＝2，３，...，|App|)；另外，p_i0表示用户请求从i层直接离开应用的概率。

由此可知，对于应用的第i层，到达的用户请求在完成本层处理后，前往其他层次或离开系统的概率总和为1：

相似的，应用第i层的用户请求可能来自于从其他任意层次离开的请求，且每层的用户请求离开率等于其到达率，故该层总的请求率λ_i为它们的总和，其中d_j表示第j层的用户请求离开率：

其中，以上概率可以通过运行时或离线监控评估取得。

应用的服务速率与服务强度

这里，设定Web多层应用的同一层次的虚拟机采用相同的资源配置，都采用优化的贴近其应用特征的资源分配。故可以认为，它们具有相同或相似服务能力，也即服务速率相等。用μ_i表示应用第i层每一台虚拟机的服务速率。

对于Web多层应用的第i层整体而言，其平均服务速率为|S_i|×μ_i，其中|S_i|为该层的虚拟机数目。则该层系统的服务强度ρ_i为：

应用每层的响应时间

分析了应用的用户请求率及服务器的服务速率，即可以利用排队论的思想计算应用每一层次的响应时间。

根据M/M/c型排队模型，应用第i层用户请求的响应时间等于该请求在队列中的等待时间和平均服务时间的总和：

其中，W_qi表示该请求在队列中的等待时间，计算方式如下式：

P_0i表示第i层的系统稳态概率，即：

将(6)(7)带入(5)，即可获得Web多层应用第i层的响应时间。

应用的总体端到端响应时间

对于一个有|App|个层次的Web多层应用而言，本设计方法可以计算出其总体的端到端响应时间等于各个层次响应时间的总和，这里用r标记：

将应用在SLA中期望的端到端响应时间标识为r_sla。可见，为了保证应用的SLA，算法的目标即是对应用的每一层找到最小的|S_i|，使得r≤r_sla。

这里，我们考虑比较严格的SLA保证方式，将其总体时间按照一定比例划分到每个层次。在具体计算时，如果某个层次的处理能力不匹配该层次的r_isla，则对其进行资源调整。

为了清楚起见，下表总结了本节用到的主要符号集，并给出了相关描述信息。

表1 Web多层应用的资源需求量化符号

符号	描述	数据来源
			rsla	应用在SLA中协定的端到端响应时间	SLA协定
risla	应用第i层的期望响应时间	离线分析
			r	应用的端到端响应时间	计算
ri	应用第i层的响应时间	计算
			λi	应用第i层的用户请求到达率	实时监控
μi	应用第i层每台服务器的服务速率	离线分析
			ρi	应用第i层的服务强度	计算
pij	用户请求离开i层后直接进入j层的概率	离线分析
			p0i	用户请求直接从外部进入i层的概率	离线分析
pi0	用户请求从i层直接离开应用的概率	离线分析

(3)Web多层应用的资源需求量化评估算法设计

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

具体算法的伪码如下所示。

其中，ScaleUp函数和ScaleDown函数分别表示为应用的第i层开启num_i-|S_i|台虚拟机和关闭|S_i|-num_i台虚拟机.

第三步:应用负载感知的资源动态调整

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

在进行资源动态调整时，引出了另一个问题：如果需要开启新的虚拟机，应该将其放置在哪台物理机上更合理？如果需要关闭虚拟机，应该选择关闭哪台？

虚拟机的放置策略对于整体云平台的资源利用率具有重要的影响，其应结合考虑当前云平台已经承载的应用负载。如果一个新的虚拟机能够与已经运行在云中的虚拟机负载互补或错峰，则可以潜在的避免资源竞争、减少资源消耗，也即以更少的资源承载更多的应用。相似的，当关闭虚拟机时，如果能够选择对当前环境负载影响最大的那一台，则可以有效平缓资源消耗，以期能够在未来承载更多新负载。

本步骤提出了应用负载感知的资源动态调整算法，在添加或减少虚拟机时，利用负载互补的思想促进资源共享、避免资源竞争。这里的负载我们考虑最关键的也是潜在竞争最强的单一资源——CPU。算法的目标是最大化物理资源的利用率，同时又不影响应用的SLA。

(1)资源动态扩展

当对一个Web多层应用的某个层次的集群进行扩展时，也即需要开启新的虚拟机以增加其服务能力时，该集群中已有的虚拟机在过去一段时间的负载表现能够体现出该应用层次的特征及趋势，故可以用于为新的虚拟机的放置选择提供参考。

对于新增加的虚拟机，希望选择一台物理机，尽量使得新来的负载与该物理机上原有的负载错峰，从而提高潜在的资源共享能力。将互补的或相关性不强的负载放置在一起，可以通过填补未使用的资源而平衡了整体负载的波动性，并且有效的提高资源利用率。

在统计学中，皮尔逊相关系数(Pearson Coefficient)常用于度量两个变量X和Y之间的相关程度，其值介于-1到1之间。其计算方式如下式所示。

借助以上公式，可以评估虚拟机负载时间序列与物理机负载时间序列的相关性。得到的结果越大，则说明二者相关性越强，应避免放置到一起；反之，则是比较优的候选对象。

根据第二步(3)节中算法的需求，即ScaleUp(S_i，num_i-|S_i|)函数，假设需要为应用的S_i层开启num_i-|S_i|台新虚拟机，这些虚拟机具有相同的资源配置需求，都采用优化后的虚拟机模板。对于物理机集群，首先对其根据剩余资源情况进行筛选，获得足够容纳待放置虚拟机的物理机列表list。这里，需要考虑多个资源维度，如CPU和内存，只有全部满足才能放置。由于应用每个层次之前具有一个请求分派器，使得用户请求按照一定的模式均衡的分配给各台服务器，所以，我们可以认为，应用同一层次的多台虚拟机的历史负载波动情况非常类似。取该层次已有负载在过去一段时间(如2小时)的平均值作为虚拟机的潜在负载。由于这样的相关性判断是为了判定物理机上已有的虚拟机与新增加负载的冲突情况，所以不考虑使用新的num_i进行平均。此时，将此负载与list中的各台物理机的历史负载计算r_xy，选择值最小的将虚拟机部署在其上。当需要继续开启新的虚拟机时，我们更新该台物理机的可用资源，重新开始下一轮循环。

(2)资源动态收缩

相似的，当需要减少应用某一层次的虚拟机数量时，希望选择关闭其负载与承载它的物理机负载相关性最强的，从而平缓该物理机的资源消耗。

根据第二步中(3)节算法的需求，即ScaleDown(S_i，|S_i|-num_i)函数，假设需要为应用的S_i层关闭|S_i|-num_i台虚拟机。此时，在IaaS云中，对于该层次S_i的每台虚拟机vm_k，可以获知承载它的物理机pm_k。通过监控功能分别取得vm_k和pm_k在过去一段时间(如2小时)的历史负载，利用公式(8)计算该虚拟机与物理机历史负载的相关性，结果记为r_xy。在选择关闭对象时，根据r_xy对各台虚拟机进行降序排列，选择值最高的、也就是相关性最强的一台关闭。如果这一轮循环还需要继续关闭虚拟机，则需要对物理机的历史负载进行处理，从中减去已关闭的虚拟机的负载值。

本发明在不影响应用性能的情况下优化调整虚拟机的资源分配，避免潜在的资源浪费，提高了数据中心整体的资源利用率。

附图说明

图1用户请求率及对应的RUBiS应用服务器台数。

图2RUBiS应用90％情况下的请求响应时间。

图3RUBiS应用服务器的CPU资源使用情况。

图4为本发明方法的总体构架。

具体实施方式

(1)实验环境

首先介绍本发明的实验环境，包括硬件环境和软件环境。

在硬件方面，采用3台物理机作为云资源池，它们具有相同的物理资源配置，参见下表；另外，使用一台相同的物理机作为总控制台。为了兼容所选择的测试应用，选择安装Fedora5和Xen3.0.3版本的虚拟化软件。

表2 实验环境

物理机CPU	Intel i5-2400，四核，3.10GHz
		物理机内存	4GB
操作系统	Fedora5
		虚拟化软件	Xen3.0.3

在软件方面，选取业界主流的开源基准(Benchmark)Web多层应用——RUBiS应用。RUBiS由Rice大学开发，之后常被用于验证Web多层应用相关的设计及算法的有效性。它实现了与eBay类似的、包含所有核心功能的在线拍卖网站，包括用户注册、浏览、买卖产品等。

利用Apache JMeter作为RUBiS Web应用的客户端压力和性能测试工具，其可以用于对服务器、网络或对象模拟巨大的客户端访问负载，来在不同压力类别下测试它们的强度并分析整体性能。根据RUBiS应用的特征，在JMeter中配置的用户操作尽可能覆盖各种RUBiS支持的行为，且调整其比例使之更符合真实的用户访问网站的操作流程。为了避免JMeter成为实验的瓶颈，采用分布式的部署方式。

选用两层的PHP版本的RUBiS应用用作测试。初始情况下，部署两台虚拟机，如表3所示，其中一个作为前台的Apache2.2Web服务器，另外一台则是后台的MySQL4.0数据库。对这两台虚拟机，为它们各自分配2个vCPU和1G内存。另外，对其可以调整的资源范围，即虚拟机台数的上限及下限。DB由于其版本的特性，不能通过增加虚拟机的方式进行动态伸缩，故固定为1台；而Apache可以方便的进行扩展，可以设定其范围为1～5台。

表3 三层应用部署

虚拟机	CPU	内存	Min	Max
					Apache	2vCPU	1G	1	5
DB	2vCPU	1G	1	1

另外，为了验证之后多台Apache服务器的情形，我们还在RUBiS应用前部署了一台单独的Apache服务器作为反向代理和负载均衡器。为了避免该反向代理成为性能瓶颈，将其部署在一台物理机上。

(2)实验验证

进一步，为了验证本发明提出的应用动态资源调整方案，首先对RUBiS应用进行压力测试和离线分析，得到表4列出的参数设定信息，包括Apache和DB服务器的服务速率(每秒处理的请求数)、请求跳转率，以及应用各层的SLA等。。

经过分别对优化资源配置后的Apache虚拟机和DB虚拟机利用JMeter进行压力测试，确定当前环境下，1030req/s和2200req/s。

对于请求跳转率，通过分析典型的用户请求类型，发现一部分页面浏览操作将不通过后台而直接从Apache返回，如浏览homepage等；另外的大部分请求如浏览产品信息、拍卖等都将经过数据库。通过预估，将直接从Apache返回给用户请求结果的概率p₁₀设为0.2，跳转到DB的概率p₁₂设为0.8，而经过DB的请求将全部直接返回，故p₂₀＝1。

考虑到实验环境相对简单，将应用的SLA时间设为500ms。由于Apache A作为前台也兼顾了应用逻辑的处理，而后台的DB由于将大量数据载入内存而加速了响应时间，把SLA按照60％和40％的比例分到这两层。

表4 RUBiS服务参数设定表

再次利用JMeter对RUBiS应用逐步增加请求的负载，将用户请求率以200req/s为单位、从400req/s增加到2400req/s，每个请求率保持一段时间，共持续90分钟。以半分钟为单位，分别监控反向代理上的用户请求率、JMeter得到的90％请求响应时间、以及Apache服务器和DB服务器的CPU资源使用情况。

设计的Web多层应用动态资源需求评估方法执行模块可以根据监控到的请求率实时计算RUBiS应用的两个层次需要的虚拟机数量。图1展示了与用户请求率相对应的Apache和DB虚拟机的台数。可见，当用户请求率达到1200req/s时(16min)，触发了第一次资源动态调整，Apache的数量增加到两台，此时，它创建了一台新的Apache虚拟机、并通过脚本将该IP加入到前端的反向代理服务器上；当用户请求率达到2000req/s时(62min)，再一次触发了Apache服务器的增加。

图2和图3分别记录了对应时刻90％情况下用户的请求响应时间以及Apache和DB虚拟机的CPU资源使用情况。

由图2可以看出，在触发资源动态扩展的两个时刻(16min和62min)，用户的请求响应时间的确出现了明显的升高，而在增加虚拟机后该情况得到显著缓解。另一方面，观察两台虚拟机的CPU使用情况(图3)，本发明算法正是在资源需求的高峰期执行了资源的动态调整，从而有效保证了应用的性能。由于新的虚拟机开启并配置到反向代理需要一定的时间，故虚拟机开启并配置到反向代理需要一定的时间，高响应时间和高负载的状态持续了一段短暂的时间。

通过上述实验，验证了本发明提出的基于IaaS层应用感知的Web多层应用动态资源调整方法具有较好的效果。

Claims (1)

1.一种基于IaaS层应用感知的Web多层应用动态资源调整方法，其特征在于具体步骤为：

第一步: IaaS云平台对Web多层应用架构的感知

在传统的IaaS管理的基础上，增加对Web多层应用的管理及信息维护，以便感知其上部署的Web多层应用及其状态；

在用户向云平台申请资源时，与当前以虚拟机为粒度的部署方式不同，采用面向应用的构建方式；设用户申请m个虚拟机集群，其按序对应Web多层应用的m个层次；对于每一个集群，用户选择部署一台或多台虚拟机作为初始配置；

设用户为每个集群配置未来进行资源调整的范围，即设定最少使用的虚拟机台数以及最多使用的虚拟机台数，分别标记为和；其中，当某一集群的和都设为1时，则认为该应用层次不能通过增加虚拟机来动态扩展；

除了获得传统IaaS云中用户期望的虚拟机资源配置信息外，同时得到用户应用的架构信息；将其应用信息总体标记为，其中体现应用的层数，而集合的每个元素记录当前的虚拟机配置数量以及min 和max；云平台根据这些信息部署应用后，进一步追踪到每个层次每台虚拟机的放置位置，也即全面了解到该用户的应用在云中的部署情况；

第二步: Web多层应用的动态资源需求的量化评估

(1) Web多层应用模型构建

首先，从Web多层应用的用户请求、服务能力、服务方式几个方面分析Web多层应用的特征：

（a）应用的用户请求

Web多层应用的负载被认为是基于会话机制的用户请求，并且一个用户会话根据访问形式的不同，可能包括一系列请求；同一时刻，应用接受并处理众多并发用户请求；

应用的用户请求是随机的，设两个连续到达的用户请求相隔的时间间隔相互独立，其到达情况服从泊松分布：

其中，λ表示请求到达的平均速度；

（b）应用的服务能力

一个应用程序对用户提供多种不同的服务；对于不同的服务类型，其响应时间也即服务时间，依赖于其所调用的应用程序和服务的实时状态；设所有服务类型的服务时间具有相同的概率分布；它们之间的间隔时间也是相互独立的，服从负指数分布；

对于Web多层应用的每一层，其容器是一台虚拟机，或者是由几台虚拟机组成的集群；

（c）应用的服务方式

应用处理用户请求的顺序采用先来先服务模式；

采用排队论的思想对Web多层应用进行建模；排队系统表示为X/Y/Z/A/B/C的形式，其中，X表示顾客到达间隔时间分布，Y表示服务台服务时间分布，Z表示服务台个数，A表示系统容量限制，B表示顾客源总体数目，C表示服务规则；

根据Web多层应用的特征，对于其每个层次，其用户请求到达时间服从泊松分布，同一层次的各台虚拟机的响应时间即服务时间服从负指数分布，其虚拟机数量为一台或多台，整个系统没有容量限制及用户通体数目限制，服务规则为先来先服务；将其每个层次建模为一个M/M/c///FCFS型排队模型,也即M/M/c型；

(2) Web多层应用的资源需求量化评估

基于以上Web多层应用的队列模型，进一步提出量化评估应用每一层次的资源需求的方法，并通过增加新的虚拟机或关闭不必要的虚拟机来满足Web多层应用的最佳资源配置;

已知一个应用共有个层次，每层的虚拟机数目为（i=1,2,…,）;对于应用的每个层次，将其建模为M/M/c型排队模型;首先，逐一考察用户请求的到达率、应用的服务速率、应用的分层及总体的响应时间;其中，用户请求的到达率为每秒到达的用户请求数，应用的服务速率为应用每秒能够处理的用户请求数；

用户请求的到达率

Web多层应用的第一层作为整个服务的入口，负责接收用户请求;应用的总请求到达率通过监控获得，其等于应用第一层的用户请求到达率，也即；

设一个用户请求离开应用第i层后直接进入第j层的概率为；特殊的，表示用户请求直接从外部进入i层的概率；所有用户请求都从同一个入口即第一层进入应用，故，；表示用户请求从i层直接离开应用的概率；

对于应用的第i层，到达的用户请求在完成本层处理后，前往其他层次或离开系统的概率总和为1：

应用第i层的用户请求来自于从其他任意层次离开的请求，且每层的用户请求离开率等于其到达率，故该层总的请求率为它们的总和，其中表示第j层的用户请求离开率：

以上概率通过运行时或离线监控评估取得；

应用的服务速率与服务强度

设定Web多层应用的同一层次的虚拟机采用相同的资源配置，都采用优化的贴近其应用特征的资源分配；用表示应用第i层每一台虚拟机的服务速率；

对于Web多层应用的第i层整体而言，其平均服务速率为，其中为该层的虚拟机数目，则该层系统的服务强度为：

应用每层的响应时间

根据M/M/c型排队模型，应用第i层用户请求的响应时间等于该请求在队列中的等待时间和平均服务时间的总和：

其中，表示该请求在队列中的等待时间，计算方式如下式：

表示第i层的系统稳态概率，即：

将（6）（7）带入（5），即获得Web多层应用第i层的响应时间；

应用的总体端到端响应时间

对于一个有个层次的Web多层应用而言，计算出其总体的端到端响应时间等于各个层次响应时间的总和，这里用r标记：

将应用在SLA中期望的端到端响应时间标识为，算法的目标即是对应用的每一层找到最小的，使得；

按照SLA保证方式，将其总体时间按照一定比例划分到每个层次，如果某个层次的处理能力不匹配该层次的，则对其进行资源调整；

(3) Web多层应用的资源需求量化评估算法步骤：

首先，在应用持续运行期间，每隔几分钟监控一次应用的请求到达率，即；

然后，以已知的一系列应用信息，包括当前应用的全局信息App、各层次的服务速率、请求跳转概率等作为参数，对Web多层应用的每个层次的资源需求进行量化评估；计算出为满足SLA中该层应用的响应时间，其所需要的最低虚拟机数量，设为；

最后，把该结果与当前已部署的虚拟机数量做对比：如果，且小于该层次可部署的最多节点数量，则为其新开启；如果，且高于该层次的最少部署节点数量，则关闭台虚拟机；否则，对该应用在当前的负载情况下，不再作资源调整；

第三步: 应用负载感知的资源动态调整

根据第二步算法，在Web多层应用负载发生变化时，及时检测到资源需求并做出响应，以动态调整资源分配；如果当前的资源配置不足以满足应用负载，则进行动态扩展、开启新的虚拟机；而当负载下降时，则采取动态收缩、关闭不必要的虚拟机，以减少资源浪费；基于相似性要求，设定对Web多层应用的同一层次的集群中的所有虚拟机采用相同的资源分配，即都采用根据其历史负载分析优化后的资源配置；

(1)资源动态扩展

当对一个Web多层应用的某个层次的集群进行扩展时，即需要开启新的虚拟机以增加其服务能力时，该集群中已有的虚拟机在过去一段时间的负载表现能够体现出该应用层次的特征及趋势，故用于为新的虚拟机的放置选择提供参考；

对于新增加的虚拟机，选择一台物理机，尽量使得新来的负载与该物理机上原有的负载错峰，从而提高潜在的资源共享能力；将互补的或相关性不强的负载放置在一起，通过填补未使用的资源而平衡整体负载的波动性，并且有效的提高资源利用率；

在统计学中，皮尔逊相关系数用于度量两个变量X和Y之间的相关程度，其值介于-1到1之间，其计算方式如下式所示：

借助以上公式，评估虚拟机负载时间序列与物理机负载时间序列的相关性，得到的结果越大，则说明二者相关性越强，应避免放置到一起；反之，则是比较优的候选对象；

根据第二步(3)中算法的需求，即ScaleUp (,)函数，假设需要为应用的层开启台新虚拟机，这些虚拟机具有相同的资源配置需求，都采用优化后的虚拟机模板；对于物理机集群，首先对其根据剩余资源情况进行筛选，获得足够容纳待放置虚拟机的物理机列表list；这里，有多个资源维度，只有全部满足才能放置；应用每个层次之前具有一个请求分派器，使得用户请求按照一定的模式均衡的分配给各台服务器，应用同一层次的多台虚拟机的历史负载波动情况非常类似；取该层次已有负载在过去一段时间的平均值作为虚拟机的潜在负载；将此负载与list中的各台物理机的历史负载计算，选择值最小的将虚拟机部署在其上；当需要继续开启新的虚拟机时，更新该台物理机的可用资源，重新开始下一轮循环；

(2)资源动态收缩

当需要减少应用某一层次的虚拟机数量时，希望选择关闭其负载与承载它的物理机负载相关性最强的，从而平缓该物理机的资源消耗；

根据第二步中(3)算法的需求，即ScaleDown(,)函数，假设需要为应用的层关闭台虚拟机；此时，在IaaS云中，对于该层次的每台虚拟机，获知承载它的物理机；通过监控功能分别取得和在过去一段时间的历史负载，利用公式（8）计算该虚拟机与物理机历史负载的相关性，结果记为；在选择关闭对象时，根据对各台虚拟机进行降序排列，选择值最高的、也就是相关性最强的一台关闭；如果这一轮循环还继续关闭虚拟机，则对物理机的历史负载进行处理，从中减去已关闭的虚拟机的负载值。