云计算环境下能耗感知模型与方法进展研究

（1）提出了服务集群与云计算平台的两级能耗感知的系统框架EADC。（2）基于大范围变动负载和时间长相关性负载对服务的负载与性能模型进行建模。（3）重载服务采用基于准入控制规则，而轻载服务采用能耗感知方案决策，实现服务集群内部的高能低耗。 

本书基于服务的负载与性能模型的研究完成服务能耗感知决策。在此基础上研究虑及能耗的全局资源优化布局算法，实现整个平台系统的高能低耗。
全书共分7章： 第1章介绍在云计算中心开展能耗感知研究的背景和意义，进而阐述本书的研究内容和贡献；第2章从技术手段、模型构建和能耗管理三个方面介绍国内外研究现状；第3章提出能耗感知的云计算平台管理框架EADC，该框架以大数据集成应用平台为基础，构建了包括VEMS(服务集群内部)与DCMS(平台系统)两级的能耗优化管理；第4章研究统计回归分析方法，解决大范围变动下的负载特征提取，研究高阶MAP拟合的策略与机制，解决长时间相关负载性能分析中复杂度与时间开销过高的问题；第5章研究在性能分析基础上服务节点的按时定量切换的能耗感知决策机制，解决负载的有效整合与节点状态的按需切换；第6章研究兼顾性能与能耗的虑及服务迁移的全局资源优化调度算法，解决服务请求突发时因负载整合而造成服务质量严重下降的问题；第7章对本书的工作进行了总结，并阐述下一步的工作方向。本书的研究成果有助于提高云计算平台能耗有效性，具有重要的理论意义和实际应用价值。
本书的读者对象是云计算中心的信息主管、云计算平台的系统设计开发人员，以及对云计算平台有所了解或感兴趣的广大科技工作者和研究人员。本书也可以作为高等院校研究生与本科生云计算相关课程的参考教材。

目录

第1章绪论1

1.1研究意义1

1.2研究动机3

1.3研究内容5

1.4本书贡献11第2章相关研究与现状16

2.1绿色云计算中心的相关技术手段16

2.1.1低功耗处理器17

2.1.2服务器虚拟化19

2.1.3刀片服务器21

2.1.4高效率电源23

2.1.5部件级节能技术25

2.2相关模型的研究综述26

2.2.1负载模型28

2.2.2性能模型32

2.2.3优化模型33

2.2.4模型总结34

2.3云计算能耗的相关研究综述35

2.3.1传统的能耗管理36

2.3.2虚拟化云计算平台的能耗管理38

2.3.3兼顾性能与能耗的能耗感知管理39/云计算环境下能耗感知模型与方法进展研究目录/2.4本章小结41第3章能耗感知的云计算平台框架42

3.1能耗感知的云计算平台管理框架EADC42

3.1.1EADC框架的生命周期管理44

3.1.2基于自主计算思想的MAPE架构45

3.1.3平台与应用两级的交互式能耗模型47

3.1.4平台与应用两级的系统效用公式49

3.2大数据集成应用平台51

3.2.1平台的系统层次划分52

3.2.2满足不同数据处理要求的计算框架53

3.2.3存储云平台的分布式服务框架55

3.2.4高速搜索服务框架56

3.2.5分布式作业调度框架59

3.3本章小结60第4章大范围变动和时间长相关性负载的性能分析61

4.1大范围变动下的负载与性能模型62

4.1.1问题定义62

4.1.2性能分析模型64

4.1.3模型的在线参数化68

4.1.4模型验证与评测71

4.2时间长相关负载下的性能模型78

4.2.1问题定义78

4.2.2Markovian Arrival Processes(MAP)84

4.2.3JAMC MAP拟合方法89

4.2.4模型验证与评测94

4.3本章小结106第5章服务集群的能耗感知方案决策108

5.1重载服务的准入控制规则108

5.1.1自相关性准入控制策略109

5.1.2控制规则有效性的测试109

5.2轻载服务的能耗感知决策118

5.2.1节点切换时机的方案选择118

5.2.2节点切换序列的方案选择121

5.2.3实验评估122

5.3本章小结126第6章虑及能耗的云平台全局资源优化布局128

6.1全局资源调度的相关算法研究129

6.2全局资源布局决策器DCMS130

6.2.1DCMS的资源量化逻辑130

6.2.2DCMS的资源布局算法的选择132

6.2.3布局重配置开销的考量133

6.2.4资源布局遗传算法的步骤135

6.3实验评价136

6.3.1DCMS的算法有效性测试137

6.3.2DCMS虑及迁移开销的效果测试141

6.3.3DCMS的规模测试144

6.4本章小结145第7章总结与展望146

7.1本书工作总结146

7.2下一步工作建议147参考文献149

前言

云计算具有超大规模、虚拟化、高扩展性等特点，可以为企业和用户提供各种低成本的计算资源和IT服务，从而为实现高效信息化管理和海量数据服务提供强有力的计算支撑。但是管理这些云程序需要消耗大量电能并带来很大的操作开销，同时也会对环境造成巨大的负面影响。随着云计算平台规模的不断扩大，一方面数量不断增长、处理能力不断增强的服务器带来更多的能量消耗；另一方面每个服务器过低的利用率又造成巨大的电能浪费。国家能源局原局长张国宝2012年表示，他了解的中国联通云计算中心的能耗数据显示，该中心每年耗电99亿千瓦时，以中国目前标准煤的效能，需要消耗92万吨标准煤才能提供足够的电力供中国联通云计算中心的能耗需求；与中国联通云计算中心对应，中国电信云计算中心年耗电112亿千瓦时，总计年需消耗102.95万吨标准煤。所以，在云计算环境下开展能耗研究势在必行。

造成云计算平台能耗效率低下的一个重要原因是空闲服务器消耗的功耗没有随着其状态的空闲而线性降低，即使在诸如10% CPU利用率的情况下，服务器也要消耗超过50%的功耗。由此实现服务器状态的按需切换，进而缩减在线服务器规模是节省能耗的有效方式，最后的资源分配方案就是保证服务质量的前提下实现能耗尽可能的降低。由此可以得出如下两个结论。

(1) 云计算平台迫切需要进行能耗感知的研究，但是必须在服务性能优化与服务质量保证的前提下。这就需要深入研究服务能耗与性能的关系，寻求性能保证与能耗节省两者的和谐统一。

(2) 云计算平台能耗感知的实现是以其上所有服务的能耗感知为基础的。这就需要构建服务与平台两层的能耗感知系统框架，同时深入研究两者的交互关系，实现从局部到全局的高能低耗。

服务能耗感知研究是当前云计算能耗管理领域的研究热点与趋势，这些研究已形成/云计算环境下能耗感知模型与方法进展研究前言/了较为成熟的研究模式，并积累了丰富的模型、方法与经验。但是当前相关研究没有很好地实现性能保证与能耗降低的优化权衡。

本书针对当前云计算平台存在的高性能保证与低能耗需求这一对矛盾的需求问题，从全面认识服务负载特性以及服务性能分析模型构建的角度出发，完成服务的能耗感知方案决策，在充分调动服务器集群的计算能力的同时完成服务能耗的有效降低，并在此基础上通过全局资源在服务间的有效调度与布局，实现整个高可扩展云平台的所有服务的高能低耗。具体研究内容包括以下五个部分。

1. 大范围变动下的负载与性能模型

对于多类方式描述的大范围变动请求服务时间，传统上采用多类服务时间定律(基于单类服务时间定律扩展得到)不适用于实际监控环境，因为实际中无法获取每类请求对应的利用率信息Di,j。本书采用统计回归的数学模型求解计算每类请求的平均服务时间。假定将请求划分为N类，系统中有M个资源，根据利用率定律(Utilization Law)Uj=Bj/T=Dj×X0，j代表第j个资源，X0是整个系统的吞吐量，Dj是请求在第j个资源消耗的时间，T是监控窗口大小，Bj是第j个资源忙碌期间(简称忙期)，将利用率定律扩展为多类请求情况，得到第j个资源在监控窗口k的利用率公式为∑iNi,k×Di,j=Uj,k×T,1≤i≤N,1≤j≤M。由此估算出Di,j的近似值Ci,j，则第j个资源在第k个窗口T期间利用率的估算值为U′j,k=∑iNi,k×Ci,jT。

2. 时间长相关负载下的性能模型

长相关(LongRange Dependent，LRD)作为云计算环境下Internet负载的一个重要特征，与不具有相关性的更新过程(如泊松分布)负载和短相关的非更新过程负载相比，其对性能的影响更大。基于MAP(Markovian Arrival Process,马尔可夫到达过程)构建的性能模型可以通过矩阵分析法快速、有效地求解，且MAP模型描述负载的能力随着阶数增大而增大，所以以往研究常利用有限高阶MAP描述长相关负载。针对低阶MAP不准确而高阶MAP又存在复杂度高的问题，本书通过降低解决高阶MAP拟合问题复杂度最终达到利用非线性优化算法求解多个低阶组合MAP(2)s(Markovian Arrival Process of Second Order的缩写，即2阶MAP)的目的，然后借鉴KPC组合技术生成高阶MAP，使得生成的MAP更好地匹配实际负载。

3. 重载服务的准入控制规则

当服务集群长期处于重载状态时，就要使用准入控制规则。学术界已有的研究大多利用简单、固定的策略：
为请求到达速率、队列长度、服务器负载设定上限，一旦超过设定的阈值，则系统拒绝为新来的请求服务或拒绝建立新的连接/会话，并且现有的准入控制策略均未考虑负载的时间相关性这一因素。本书的关注点是研究针对时间长相关性Internet负载，何时开始丢弃以及如何丢弃才能最大化服务质量的同时尽可能减少请求丢弃的比例，采用了如下策略：
在请求到达时检查队列长度，如果队列长度大于阈值，则依据到达过程或服务过程的自相关系数判断准入或者丢弃，称之为基于自相关性的准入控制策略。之所以采用自相关系数，是因为它是最常见的用来描述负载时间相关性的指标。

4. 轻载服务的能耗感知决策

当服务集群处于轻载时，需要做出如下决策：
在当前的集群内的活跃节点能够保证服务质量的前提下何时可以将某些空闲节点的状态进行切换。对于当前的服务集群，就转化为一个局部优化问题，求解得到能够保证服务质量的活跃节点序列，将其余节点进行状态切换。本书引入了通信领域的爱尔朗公式，结合上述两个负载模型与性能模型，采用递推公式以迭代方式完成对不同状态服务的资源需求定量分析，最终求解得出该服务在满足服务质量前提下所需要的服务节点的最小序列。

5. 兼顾性能与能耗的虑及服务迁移的全局资源调度算法

已有的资源调度算法的整体目标是满足各个服务SLA需求的同时最大化全局效用，效用目标的定义各不相同，都有各自的考量，但基本上都关注解决共享式云计算平台资源闲置浪费的问题。针对传统全局资源布局中在资源动态调度时仅考虑性能指标并存在节点迁移开销过大的问题，加入性能与能耗的两维效用，采用改进的遗传算法确定节点在服务间的分配，最优解以满足重载服务的服务质量(QoS)为主要目标，通过提高能力高节点的利用率以实现全局能耗的降低。同时对于重载服务在扩容节点时加入迁移节点的时间开销惩罚，从而有效避免了节点在服务间的迁移抖动，在权衡性能与能耗的基础上达到绿色云计算中心的目标。

本书总结与归纳该领域已有的工作，首先完成服务模型构建、服务能耗感知决策以及全局资源调度算法等相关理论的学习和分析；然后对相关的关键问题逐一进行探讨，力求在模型与方法上有所创新，并通过实验验证其有效性；最后提出EADC(EnergyAware Data Center)系统框架，从系统的角度综合考虑各个环节，探讨整体的解决思路，避免对问题的孤立研究，并进一步对研究成果进行验证，EADC框架包括服务(VEMS)与系统(DCMS)两层的能耗模块。

(1) 在服务集群内，实验数据表明构建的负载与性能模型的计算输出与观察数据基本匹配；以负载与性能模型为基础，VEMS通过节点状态的切换决策，在服务质量保证的同时降低了服务能耗的33%。

(2) 在数据中心级别，全局资源布局决策器DCMS通过资源的优化布局算法实现了请求突发服务的服务质量满足，同时降低了全局能耗的24%；规模性测试表明算法具有良好的可扩展性，并没有因为云计算中心规模的扩大而降低算法的有效性。

本书为云计算平台的诸多关键问题的求解提供了一套系统的模型、方法与技术，推进了云计算平台服务能耗管理策略的进一步研究和发展，为解决云计算环境下的服务高能耗问题提供了系统的理论支撑。本书的研究成果对于云计算环境下实现精确、高效的服务能耗感知，构建高能低耗平台，从而为其上各类服务提供丰富强大的信息服务具有重要的应用价值，有助于为政府、高校、企业及个人用户提供高能低耗的可扩展的海量数据服务。

第3章能耗感知的云计算平台框架在能耗已成为云计算中心发展瓶颈的情况下，需要重新思考云计算平台原有的相关策略(以服务质量保证为主要目标)，将能耗有效性这个重要的因素引入到参数列表中，综合考虑性能与能耗的关系，在性能保证与能耗降低两者权衡的基础上实现云计算平台的高能低耗，从而实现绿色云计算中心的目标，由此本书提出并实现了能耗感知的云平台管理框架EADC(EnergyAware Data Center)。本章主要包括如下两部分内容。(1) 第一部分首先提出EADC的系统框架，在该框架下根据基本系统环境按照自主计算的思想为其分别构建了MAPE(Monitor/Analyze/Plan/Execute)4个模块，对其各个模块及相互交互关系进行了介绍，然后结合系统功能对系统待解决的问题进行归约，针对系统的资源管理的3个级别： 服务节点、服务集群和云平台，分别进行相应的效用函数定义。(2) 第二部分首先基于EADC框架提出大数据集成应用平台的层级结构，依次构建了计算框架、分布式服务框架、搜索服务框架和分布式作业调度框架，从而完成大数据集成应用平台的构建。3.1能耗感知的云计算平台管理框架EADC近年来提供大量第三方应用的大规模共享式云计算中心引起大家广泛的关注，特别是这些应用相互独立并需要不同的SLA性能保证。随着运行于其上的应用越来越多，云计算中心的电力消耗在过去的几年里飞速增长，并成为严重影响其发展的瓶颈。本书认为实现服务器状态的按需切换，关闭空闲服务器是节省能耗的有效方式，但是这必须以服务质量保证为前提。为了实现云计算平台能耗降低与性能保证的均衡满足，设计并实现/云计算环境下能耗感知模型与方法进展研究第3章能耗感知的云计算平台框架/了一种基于能耗感知的云计算平台资源管理框架EADC。其通过控制服务节点状态的按需变化实现服务集群能耗的有效降低，而通过控制服务节点在服务集群间的按需切换实现整个云计算平台的整体服务质量的满足和全局资源能耗有效降低的目标。为云计算中心构建的高能低耗的EADC系统基本环境如图3.1所示。在图3.1中，实线矩阵框代表云计算中心DC(Data Center)，由多个物理机器构成，物理机器之间异构具有不同的硬件配置。每个物理机器或者直接构建应用的服务节点，或者通过虚拟化技术构建可服务于不同应用的多个虚服务节点。运行同一应用的服务节点构建成该应用的服务集群，称之为VE(Virtual Environment)，由图中虚线矩阵框代表。EADC系统主要由服务集群管理系统VEMS(VE Management System)和云计算中心管理系统DCMS(DC Management System)两部分组成，分别在云计算平台的管理服务器与服务集群控制器上实现。在该框架下采用局部到全局的能耗优化机制以实现各个服务到系统整体的能耗有效性保证。图3.1EADC系统环境3.1.1EADC框架的生命周期管理图3.2所示，EADC框架实现了对服务集群与云计算平台的两级能耗有效性管理。图3.2平台系统架构图(1) 在服务集群内部，通过节点状态的按需变化实现服务集群能耗的有效降低。(2) 在云计算平台上，通过控制节点在服务集群间的按需切换，实现整个平台其上所有应用的QoS保证和全局资源能耗有效降低的目标。按照应用服务的生命周期，该平台的主要工作流程如下。(1) 初始化阶段。云计算平台的计算资源、存储资源与网络资源完成注册，并对其中的各类资源按照性能/能耗进行分级登记处理。(2) 应用服务的建立。综合考虑当前空闲资源以及当前的节点资源给出资源的分配方案；应用部署系统对分配的各类资源进行绑定与认证，启动节点并配置服务，从而完成服务集群的建立与运行。(3) 应用的运行与监控。构建节点、集群与平台的三级监控体系，采集到的数据作为应用能耗感知决策系统的输入从而实现应用服务请求转发到最合适的节点处理，同时进行节点的状态切换以达到节能目的。(4) 应用服务的扩容。当服务集群因为服务请求突发等因素造成服务质量的违背时，采用全局资源优化技术对平台系统发出资源申请命令以进行集群容量的扩容。(5) 应用间的资源调度。当系统发现当前的空闲资源无法满足应用服务的资源申请时，同样采用全局资源优化技术对相应低优先级的服务集群发出资源回收命令，进行资源在服务集群间的在线迁移。(6) 应用的终止。系统对于要求完毕或者已经完毕的应用服务，应用部署系统解散服务集群、关闭计算节点以及释放后端存储资源。3.1.2基于自主计算思想的MAPE架构为了更好地解构系统框架及其中各个组成部分的关系，按照自主计算的思想[71]为其划分为Monitor、Analyze、Plan与Execute 4个模块，从而构建了本系统的MAPE架构，图3.3描述了该框架下的各个模块组件以及模块之间的数据流，其中用到的时间周期如图3.4所示。多个服务运行在公共的硬件平台上，组合成对应服务所需的虚拟服务器。实时监控器的监控数据通过负载特征分析器分析、计算负载特征参数，负载特征参数作为性能分析器的输入，预测应用的性能。性能分析器、效用评估器和性能优化器组成一个优化回路，性能优化器在性能分析的基础上，根据效用评估器从庞大的解空间中选择一个效用最大的资源分配方案。资源分配方案交给优化执行器来完成相应的优化动作，包括资源的分配和回收。图3.3EADC 的MAPE系统架构图3.4EADC的时间周期定义正如图3.3所示，大数据集成应用平台通过异构节点池对全局异构节点资源进行管理，为每个服务构建对应的服务环境VE。Monitor模块每隔Monitor Interval实时收集当前所有VE的运行信息，包括负载强度、服务状态、能耗效率等。预测模型FM(Forecasting Model)以Monitor模块收集的History时间内的历史数据为输入，采用相应的预测算法对下一个周期的负载强度进行预测。性能模型PM(Performance Model)为每个VE构建分析公式，以给定负载与特定配置为输入，求解得到服务的性能效用值与能耗效用值。Plan模块在服务集群与云计算平台两个层面开展工作。首先在服务集群层面，VEMS每隔Monitor Interval，采用效用评估部件针对该VE当前的性能与能耗指标，再加上VE的SLA目标以及预测模型得到的未来的负载强度，分别对VE的性能与能耗效用进行评估，在评价的基础上由配置优化部件得到下一周期的服务节点的状态变化，然后通过Execute模块在VE内部进行服务节点状态的切换，从而实现VE的低能耗。而在云计算平台层面，每隔Adoption Window时间段，DCMS通过效用评估部件在完成各个VE局部评估的基础上进行效用整合得到当前云计算平台的全局效用，并对当前的系统效率进行评估，以便判断是否需要进行资源配置的优化调整。配置优化部件对每个可能的候选方案通过虚线路线表示的Optimizing Loop进行优化抉择，在这些工作的基础上最终生成一个最优的布局方案。Execute模块一旦接收到最优布局方案，就调整VE与节点的映射以实现全局资源的重新分配。Execute模块由大数据集成应用平台担当，具体请参见3.2节，其通过生成对应的服务映像并将其与硬件节点进行映射以完成服务的部署从而为每个服务构建对应的服务环境VE，同时充当决策生成器： ①接收节点状态切换指令完成服务节点的状态调整(VEMS发布)； ②接收节点的重配置命令对VE与节点的映射关系进行重新配置，从而完成VE规模的调整(DCMS发布)。3.1.3平台与应用两级的交互式能耗模型为共享式云计算平台构建了高能低耗的EADC系统框架，在该框架下要解决如下两个问题。(1) 服务集群层面。在满足服务质量的前提下如何实现负载请求的有效聚集从而使得能力低的节点得到空闲；如何根据负载变化进行服务节点状态的按需切换以实现服务集群的节能目的。(2) 共享云计算平台层面。在(1)的基础上对其上所有服务情况进行汇总，确认当前资源配置下能否满足其上所有服务的需要；而当有服务性能不能满足需要时，如何快速、按需、低耗地进行全局资源的调度以满足该服务需要。本书构建了DCMS与VEMS两级的能耗模型，VEMS对于实时运行的服务集群系统，在满足服务质量的前提下实现能耗的降低，而DCMS则是全局资源布局决策器，通过资源的重新配置实现全局效用最优，并对两者的相互关系进行深入研究以解决上述问题。系统各个组成模块的功能以及相互的关系如图3.5所示。从图3.5可看出，大数据集成应用平台是研究基础与使能平台，其必须能够保证实现VE的迅速构建以及服务节点在VE间的快速切换。图3.5两层能耗模块关系图VEMS能耗模块的主要目标在能耗上： 对于实时运行的服务集群，如何在满足在服务质量的前提下实现服务能耗的有效降低。其主要功能包括以下3个方面。(1) 通过服务请求的有效转发以满足服务质量(请求转发)。(2) 通过有效调控节点状态实现服务的低能耗(状态切换)。(3) 在服务质量违背时触发服务资源请求决策(资源申请)。而DCMS能耗模块的主要目标在性能上： 在对于其上运行的所有服务均通过VEMS实现各自局部能耗有效性的基础上，如何进行资源的全局调度实现局部到全局的最优，即在满足这些服务质量的基础上实现系统的总能耗有效降低。其主要功能包括以下3个方面。(1) 判断整体资源配置能否满足其上所有运行服务的需要(资源量化)。(2) 当某VE服务质量违背时，进行资源的全局调度以满足服务新增资源需求(资源调度)。(3) 通过资源在VE间的迁移实现服务容量的按需调整(资源剥夺)。资源申请与剥夺是两级能耗模块的交互时刻。(1) 资源申请。当面对服务请求突发、服务质量违背时，VEMS向DCMS发出请求，要求进行服务容量扩容。(2) 资源剥夺。当面对服务的容量扩容请求，全局空闲资源不足时，DCMS向其中轻载的VE发出剥夺要求，进行资源的回收。3.1.4平台与应用两级的系统效用公式可将EADC的核心问题归结为服务节点的状态切换与属主变换。服务节点状态定义为3种，分别为Active(Ready For Service)、Standby(Service Configured But In Sleep Status)、Poweroff(Physical Poweroff)，而服务节点或者是属于某个VE或者属于Idlepool(所有未分配出去的空闲关机节点的集合)。节点状态与属主的大体转换流程如图3.6所示，其中VEMS主要负责节点状态在Standby与Active间的切换，而DCMS则主要负责节点属主的变换。图3.6节点状态转换图EADC系统的主要功能就是在服务轻载时降低能耗，服务重载时满足性能。(1) 当VE轻载时： VEMS负责节能(Node:Active>Standby)，而DCMS先关机(Node:Standby>Poweroff)再将其转入Idlepool。(2) 当VE重载时： VEMS将其所有节点状态切换为Active后如果仍然不能实现性能保证，则向DCMS提交新增资源申请；而DCMS从Idlepool和其他轻载VE中迁移节点以满足该服务质量。将平均响应时间作为应用的主要性能指标，并使用请求到达速率来表示应用的负载强度，表3.1对系统使用到的相关参数进行了符号定义。服务节点随时间t变化消耗的能量可以表示为Et=(Sbase (Smax－Sbase)×load)×t，运行某服务的节点服务速率即该节点每秒可以完成的服务请求数,可以表示为μ=c/D。表3.1系统相关参数定义符号含义备注c节点的容量Nodeμ节点的服务速率Nodeload节点当前负载NodeSbase节点的基础能耗(Standby状态能耗)NodeSmax节点最大能力时的能耗NodeEt节点t时间内消耗的能耗 NodeD服务的服务需求均值VER服务期望的响应时间VEB服务期望的请求丢弃率VEPri服务的优先级权重VEλ当前服务的负载强度VERt服务的当前响应时间VEC服务的总容量VEUp服务的性能效用函数VEUe服务的能耗效用函数VEN云计算中心服务节点数目DCM云计算中心运行服务个数DCUg云计算中心全局效用函数DC对于节点效用，以每瓦能够完成请求数作为判断节点能力的依据(c/Smax)。对于VE的效用，因为VEMS的主要工作就是在QoS满足时降低能耗，在QoS违背时提高性能，所以VE的效用函数分别为能耗效用与性能效用两个，如公式(3.1)所示。在VE轻载(RtR)时，关注的则是VE的性能满意度的最高，其随响应时间Rt的增大而减少，并且当Rt超过QoS规定的响应时间期待值R时，下降的幅度增大，而当响应时间为零时，性能效用的值为100。其中Ki及K′i为放缩因子，而放缩因子取值Ki=1001 eRi×K′ieRi×K′i。Uei=e(Ej)=∑nj=1EjUpi=p(Rt,R)=Kie(-Rt R)×K′i1 e(-Rt R)×K′i(3.1)对于全局效用函数Ug来说，相应的也是分段函数，如公式(3.2)所示，以其上所有VE的QoS都得到满足作为判断依据。如果所有VE 的QoS都能得到满足，则以整个云计算中心全部的N 个节点的能耗累加和作为全局能耗效用Uge；而如果存在有VE的QoS未能得到满足，则以所有VE的性能效用的加权和作为全局性能效用Ugp，其中Uf为空闲机器贡献的效用。Uge=∑Nj=1EjUgp=up(Up1,Up2,…,UpM,Uf)(3.2)3.2大数据集成应用平台能耗感知的EADC框架对云计算平台提出更多的要求，具体包括以下5个方面。(1) 资源扩展的可独立性。计算资源和存储资源需要可以完全独立地扩展。这才能确保用户可以根据其需求独立地增减所需资源。(2) 资源管理的可独立性。对于存储资源和计算资源的管理也需要完全独立。这不仅能够简化系统管理的复杂度，而且能够丰富系统管理的涵盖面。(3) 存储资源的可共享性。存储资源需由多个计算资源所共享。这会大大提高存储资源的利用率，有效地降低采购、管理和运营成本。(4) 数据资源的可共享性。存储于网络存储设备之上的数据可由多个计算资源平等地共享。这为机群计算环境提供了协作计算的基础。(5) 数据资源的可移动性。在云计算环境中，由于计算资源是通过网络访问数据资源，数据资源的位置相对透明。所以，数据资源应该能够自由地在网络设备间移动。3.2.1平台的系统层次划分顺应存储网络化、虚拟化、智能化、按需化的趋势，同时为了满足EADC框架的需要，在对云计算平台相关的技术解决方案全面了解掌握的基础上，提出并构建了企业大数据存储云平台，如图3.7所示。在存储平台基础上针对数据处理的不同需求，设计了一个全新的计算框架，满足离线与在线计算的需要，接着研究了存储云平台的分布式协调机制，然后设计了存储云平台的搜索服务机制框架，最后设计了分布式作业调度框架。图3.7大数据存储云平台如图3.7所示，构建的大数据基础存储平台以分布式文件系统HDFS[72]为核心，支持PB级数据存储。平台按照层次划分，大致包括大数据存储服务、分布式数据服务、缓存服务、计算服务、大数据处理服务、搜索服务、消息队列服务和资源调度服务等，具体描述如下。(1) 大数据存储服务包含HDFS与HBase，其中HDFS 采用分布式存储机制用于存储海量数据，没有数据格式的限制，同时支持PB级数据存储；而HBase用于存储结构化数据，对实时性要求高的业务给予支持，HBase同样采用分布式存储机制，能够存储海量数据。同时分布式数据库服务 HBase、Hive[73]等都是分布式部署，能够为平台提供更加可靠的数据。(2) 分布式数据服务和缓存服务使用 Redis[74] Zookeeper[75]进行定制与开发。(3) 计算服务是混合计算服务架构，满足对数据处理的不同需求，动态分配所需运算资源，Hadoop MapReduce[76]计算框架支撑离线批处理应用，使用Spark[77]计算框架提供基于内存的实时计算服务。 (4) 大数据处理服务包括Hive 与Apache Kylin[78]，此类服务在存储平台的基础之上对外提供ERP与EMS标准化通用接口，同时设计数据收集同步服务为Flume[79]，实现通过ERP与EMS接口在大数据平台与传统的关系型数据库之间同步数据。(5) 搜索服务为 Spark Lucene[80]索引架构，它是高速检索核心，提供海量数据SQL查询接口，可对PB级数据进行查询。在保证了整个平台对数据查询的需求的同时，还从用户的使用权限上保证了Hive中数据的安全性与保密性。(6) 消息队列服务Kafka[81]是一个基于分布式的、快速的、可扩展的、持久的消息发布订阅系统，保证每个用户只能查看和使用当前用户创建的队列。(7) 资源调度服务为YARN[82]，它主要为平台上任务的执行按需分配资源，保证每个任务的正常执行。3.2.2满足不同数据处理要求的计算框架基于云平台上数据的多样性，对于不同数据的处理的实时性要求也不相同，从更加全面的角度考虑，在大数据平台的基础上设计了一种全新的计算框架，它既可以适用于离线的计算，又可以适用于在线的实时计算，主要技术支持为MapReduce Spark。1.  离线计算串行计算早已不再是云计算的工作模式，并行计算的出现极大地拓展了大规模数据处理问题的解决方案，从以下两个方面考虑最终选择MapReduce作为本方案的并行处理框架。（1) 抽象模型。MPI等并行计算方法缺少高层并行编程模型，为了克服这一缺陷，MapReduce借鉴了Lisp函数式语言中的思想，用Map和Reduce两个函数提供了高层的并行编程抽象模型。(2) 统一构架。为程序员隐藏系统层细节。MPI等并行计算方法缺少统一的计算框架支持，程序员需要考虑数据的存储、划分、分发、结果收集、错误恢复等诸多细节；为此，MapReduce设计并提供了统一的计算框架，为程序员隐藏了绝大多数系统层面的处理细节。2.  实时计算云计算平台对于实时计算有着更为迫切的需求，而Spark作为一个高速的实时计算框架，具有轻、快、灵、巧四大特点。（1) 轻。相比于Hadoop 2.0 22万行的代码量，Spark 0.6核心代码只有2万行。这一方面要感谢Scala语言简洁与丰富的表达能力，而另一方面，Spark很好地利用了Hadoop和Mesos(集群的动态资源管理)的基础设施。虽然很轻，但Spark在容错设计上不打折扣(其负责人Matei声称： “不把错误当特例处理”)。（2) 快。Spark对小数据集的处理能达到亚秒级的延迟，这对于MapReduce是无法想象的(由于“心跳”间隔机制，仅任务启动就有数秒的延迟)。就大数据集而言，对典型的迭代机器学习、即席查询(AdHoc Query)、图计算等应用，Spark比基于MapReduce、Hive和Pregel的实现要快上十倍到百倍。这其中内存计算、数据本地性(Locality)和传输优化、调度优化等该居首功，当然也与设计伊始即秉持的轻量理念不无关系。（3) 灵。Spark提供了不同层面的灵活性。在实现层，它完美演绎了Scala trait动态混入(Mixin)策略(如可更换的集群调度器、序列化库)；在原语(Primitive)层，它允许扩展新的数据算子(Operator)、新的数据源(如HDFS之外支持DynamoDB)、新的Language Bindings(Java和Python)；在范式(Paradigm)层，Spark支持内存计算、多迭代批量处理、即席查询、流处理和图计算等多种范式。（4) 巧。巧在借势和借力。Spark借Hadoop之势，与Hadoop无缝结合；接着Shark(Spark上的数据仓库实现)借了Hive的势；图计算借用Pregel和PowerGraph的API以及PowerGraph的点分割思想。而这一切都借助了Scala(被广泛誉为Java的未来取代者)之势。为支持交互式编程，Spark只需对Scala的Shell小做修改(相比之下，微软为支持JavaScript Console对MapReduce交互式编程，不仅要跨越Java和JavaScript的思维屏障，在实现上还要做很多工作)。除此之外，Spark还启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。Spark的一站式解决方案，减少开发和维护的人力成本和部署平台的物力成本。而且Spark并没有以牺牲性能为代价，相反在性能方面，Spark与MapReduce相比也具有很大的优势。3.2.3存储云平台的分布式服务框架 Zookeeper分布式服务框架是Apache Hadoop的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，具体包括统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。这些数据管理问题在大数据集成应用平台上表现依然非常突出，所以基于Zookeeper实现了平台上多个节点协调的访问。在分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。Zookeeper是Hadoop的一个子项目，是目前大数据Hadoop平台上最常用的分布式协调服务，其架构图如图3.8所示。图3.8Zookeeper系统架构图Zookeeper是一个分布式的、开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务、配置维护和命名服务等。Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议称为Zab协议。Zab协议有两种模式，它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后，Zab就进入恢复模式；当领导者被选举出来，且大多数Server完成了和Leader的状态同步以后，恢复模式就结束了。状态同步保证了Leader和Server具有相同的系统状态。通过Zookeeper可以很好地协调分布式文件系统，保证了云平台数据的一致性与准确性。3.2.4高速搜索服务框架为了保证数据查询的需求，达到PB级数据秒级查询的需求，同时保证数据的安全性与保密性，方案使用Spark Lucene索引架构作为高速检索核心，以保证整个平台对数据查询的需求。Lucene是一个搜索引擎包，而不是像Tomcat一样的产品，它衍生出了Solr和ElasticSearch两种机制。本方案选择的是ElasticSearch(ES)，实现了毫秒级的查询响应时间。ElasticSearch的优点主要包括： 优秀的全文检索能力、高效的列式存储与查询能力、数据分布式存储(Shard 分片)等。其列式存储可以有效地支持高效的聚合类查询，如groupBy等操作，分布式存储提升了处理的数据规模。但相应的ElasticSearch也存在一些缺点，例如缺乏优秀的SQL支持、缺乏水平扩展的Reduce(Merge)能力、现阶段的实现局限在单机、JSON格式的查询语言缺乏编程能力，以及难以实现非常复杂的数据加工等，而Spark 作为一个计算引擎，可以克服ElasticSearch存在的如下缺点。(1) 良好的SQL支持。(2) 强大的计算引擎，可以进行分布式Reduce。(3) 支持自定义编程(采用原生API或者编写UDF等函数对SQL做增强)。所以，在构建即席多维查询系统时，Spark 可以和ElasticSearch取得良好的互补效果。通过ElasticSearch的列式存储特性，可以非常快地过滤出数据，并且支持全文检索，之后这些过滤后的数据从各个Shard 进入Spark，Spark分布式的进行Reduce/Merge操作，并且做一些更高层的工作，最后输出给用户。通常而言，结构化的数据结构可以有效提升数据的查询速度，但是会对数据的构建产生一定的吞吐影响。ElasticSearch强大的Query能力取决于数据结构化的存储(索引文件)，为了解决这个问题，通过Spark Streaming有效地对接各个数据源(Kafka/文件系统)等，将数据规范化后批量导入到ElasticSearch的各个Shard。Spark Streaming 基于以下两点可以实现为ElasticSearch快速导入数据。(1) Spark RDD 的Partition 能够良好地契合ElasticSearch的Shard的概念，避免经过ElasticSearch的二次分发。(2) Spark Streaming 批处理的模式和Lucene(ElasticSearch的底层存储引擎)的Segment对应得非常好。一次批处理意味着新生成一个文件，从而可以有效地控制生成文件的大小、频度等。最终的搜素服务框架设计如图3.9所示，分成4个部分。(1) API层。API 层主要是做多查询协议的支持，例如可以支持SQL、JSON等形态的查询语句，并且可以做一些启发式查询优化。从而决定将查询请求是直接转发给后端的ES来完成，还是走Spark 计算引擎。(2) Spark 计算引擎层。对于一个普通的SQL语句，可以把 where 条件的语句，部分group 等相关的语句下沉到ES引擎执行，之后可能汇总了较多的数据，然后放到Spark中进行合并和加工，最后转发给用户。(3) ElasticSearch 存储层。ElasticSearch的Shard数量在索引构建时就需要确定，确定后无法进行更改。这样单个索引里的Shard 会越来越大，从而影响单Shard的查询速度。但因为上层有了 Spark Compute层，所以可以通过添加Index的方式来扩大Shard的数目，然后查询时查询所有分片数据，由Spark完成数据的合并工作。(4) ElasticSearch 索引构建层。数据的结构化必然带来构建的困难。所以有了Spark Streaming层作为数据的构建层。这里有两种选择，既可以通过ElasticSearch原生的bulk API 完成索引的构建；也可以通过然Spark 直接对接到ElasticSearch的每个Shard，直接针对该Shard 进行索引，从而有效提升索引的吞吐量。图3.9高速搜索服务框架图3.2.5分布式作业调度框架Hadoop 2.0提出一种新的资源管理系统YARN，为不同的并行化计算提供资源分配服务。由于YARN具有灵活且支持多计算框架的架构设计、主节点功能的分离、资源调度机制的改进、资源的隔离和Hadoop原生支持等诸多特性，它目前已经成为新一代资源管理的典型代表，许多互联网公司，如阿里的云梯集群、腾讯的Gaia平台等就是基于YARN建立的大数据平台。YARN作为整个平台的资源调度核心，主要负责整个平台资源(包括计算、内存、带宽等)的调度。Master/Slave结构的YARN由两个角色构成、ResourceManeger和NodeManager。(1) ResourceManager将各个资源部分(计算、内存、带宽等)精心安排给基础 NodeManager(YARN 的节点代理)。ResourceManager还与ApplicationMaster一起分配资源，与NodeManager一起启动和监视它们的基础应用程序。ApplicationMaster管理一个在YARN内运行的应用程序的每个实例，负责协调来自ResourceManager的资源，并通过NodeManager监视容器的执行和资源使用(CPU、内存等的资源分配)。(2) NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况(CPU、内存、硬盘、网络)并且向调度器汇报。NodeManager 提供针对集群中每个节点的服务，从监督一个容器的终生管理到监视资源和跟踪节点健康。事实上，每一个应用的ApplicationMaster 是一个详细的框架库，它结合从 ResourceManager 获得的资源和 NodeManager 协同工作来运行和监控任务。ResourceManager 支持分层级的应用队列，这些队列享有集群一定比例的资源。从某种意义上讲它就是一个纯粹的调度器，它在执行过程中不对应用进行监控和状态跟踪。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务。ResourceManager是基于应用程序对资源的需求进行调度的，每一个应用程序需要不同类型的资源，所以就需要不同的容器。资源包括内存、CPU、磁盘、网络等，这同 Mapreduce 固定类型的资源使用模型有显著区别。资源管理器提供一个调度策略的插件，它负责将集群资源分配给多个队列和应用程序，调度插件可以基于现有的能力调度和公平调度模型。3.3本 章 小 结为提高云计算平台的能耗有效性，本章提出能耗感知的云计算中心管理框架EADC，首先基于自主计算思想设计了MAPE架构，然后结合EADC的功能模块关系归约了其核心问题，并对三层资源进行了效用定义。构建完整的EADC系统需要3个部分。(1) 大数据集成应用平台是方案执行器，节点状态的切换与属主的变化都需要通过其来执行，在已有技术方案的基础上进一步集成实现了满足不同数据处理要求的计算框架与分布式服务框架，实现了高速的数据搜索与分布式作业调度，有力地支持了数据资源的部署，从而更好地满足用户对于资源的各种调度需求。(2) VEMS是服务集群低能耗的保证，这实际上就是在满足服务性能的基础上确定服务节点的切换时机与切换序列。所以，在第4章进行相关的模型构建与公式选择，然后第5章在此基础上对这两个问题的解决效果进行验证。(3) DCMS其实就是一个全局资源布局决策器，其首先要确定当期资源是否能够满足其上服务的资源要求；然后进行全局资源的优化重配置，实现在满足所有服务质量基础上全局资源能耗的有效降低。在第6章引入遗传算法对云计算中心全局资源的最优布局进行求解。第4章大范围变动和时间长相关性负载的性能分析在基于模型的解决方法中，方案决策的准确性取决于负载与性能模型的有效性。Internet服务负载呈现大范围变动与时间长相关性特征，而基于单一类负载描述的性能模型对于大范围变动负载的性能分析是不准确的；已有的基于泊松分布或指数分布负载的性能模型的评价技术在时间相关性负载下也是不适用的，相关性负载作用下的队列长度分布的衰减比不相关负载的作用下要慢，其结果就是更大的延时，以及利用率和吞吐量的下降。总的说来，在线性能分析面临如下3个问题： 其一是建立有效的负载与性能模型，要求它能准确抽象系统，捕获负载的主要特征，模型求解简单，模型的输出能完整的描述系统的性能；其二是模型的参数化，即负载模型参数(也称为负载特征参数)的在线提取；其三是特别以负载整合和状态切换作为节能手段的服务集群必然出现负载集中的趋势，能耗感知的容量决策对负载模型和性能模型有了更高的准确性与及时性要求。所以，只有有效地分析大范围变动和时间相关性的负载在系统中的流动，构建有效的负载与性能模型，才能对服务应用做出准确的性能评价。本章主要包括如下两部分内容。(1) 第一部分首先对大范围变动负载分析及性能分析存在的问题进行描述；然后介绍分析模型及分析模型参数化时用到的分类和统计回归分析方法；最后对模型与性能评价的有效性做了验证。(2) 第二部分首先介绍高阶MAP拟合长相关负载时存在的问题和相关研究；然后提出了JAMC(Joint Approximation of the Moments and Correlations)MAP拟合方法，重点从MAP分布和时间相关性特性、谱特征和MAP组合技术3个方面进行阐述；最后通过实验对JAMC MAP拟合方法的拟合效果做了测试和评价。