基于opennebula的虚拟化服务器集群中节能的研究

. . . . . .

绪论相关研究成果

动态云资源管理系统CREAM设计与实现对CREAM进行实验验证

基于OpenNEbula的虚拟化服务器集群中节能的研究

杨嘉晨5070379022

June 17, 2011

杨嘉晨5070379022 基于OpenNEbula的虚拟化服务器集群中节能的研究

. . . . . .

大纲..1 绪论

背景介绍能耗模型虚拟化技术

2 相关研究成果硬件级别针对服务器节能的研究操作系统和应用级别对服务器节能的研究虚拟化技术以及Xen对节能的支持

3 动态云资源管理系统CREAM设计与实现CREAM系统总体介绍OpenNEbula云管理器CREAM主循环CREAM性能监视器CREAM调度器

4 对CREAM进行实验验证验证服务器的CPU利用率与其功率的关系TPC-Wcpu负载生成器的实现实验环境搭建验证CREAM

. . . . . .

本节大纲..1 绪论

. . . . . .

服务器能源消耗的增长..一直以来计算机产业的关注焦点是如何在摩尔定律的指导下提升系统的整体性能。随着计算机运算性能的指数级增长，计算资源所消耗的能源也一直不断增长。根据一份针对美国和世界上服务器消耗能源的调查报告显示,虽然每单位计算量的耗能是常数级别增长，但是如表所示，计算机系统的总耗电量一直在随着时间不断增加。

服务器类型 2000 2001 2002 2003 2004 2005 2006服务器组 186 193 200 207 213 219 225

中型服务器集群 424 457 491 524 574 625 675高端服务器集群 5,534 5,832 6,130 6,428 6,973 7,651 8,163

表1不同服务器级别的平均耗电量估计

. . . . . .

服务器能源消耗的增长..一直以来计算机产业的关注焦点是如何在摩尔定律的指导下提升系统的整体性能。随着计算机运算性能的指数级增长，计算资源所消耗的能源也一直不断增长。根据一份针对美国和世界上服务器消耗能源的调查报告显示,虽然每单位计算量的耗能是常数级别增长，但是如表所示，计算机系统的总耗电量一直在随着时间不断增加。

服务器类型 2000 2001 2002 2003 2004 2005 2006服务器组 186 193 200 207 213 219 225

中型服务器集群 424 457 491 524 574 625 675高端服务器集群 5,534 5,832 6,130 6,428 6,973 7,651 8,163

表1不同服务器级别的平均耗电量估计

. . . . . .

计算系统中不同层次的能源消耗

. . . . . .

CREAM— Coordinated Resource Energy-AwareManager..本文在开源云资源管理框架OpenNEbula 的基础上提出了CREAM云资源管理系统，它改变了现有云资源管理器对虚拟机的看待方式，虚拟机不再是当作任务，虚拟机的开始与结束不再被认为是任务的开启与停止。认为虚拟机会持续不断地执行相当长的一段时间，在这段时间内不断监视虚拟机资源利用率的动态变化，并做出预测，判断虚拟机需要多少物理资源。CREAM系统通过获得网页或者数据库这些服务器应用中都很常见的响应时间作为描述应用性能的指标，根据这个指标和CREAM监视到的动态变化的虚拟机的资源利用率，CREAM做出合理的资源需求预测。在应用层取得预测的服务器负载之后，根据预测负载来调整虚拟机的资源分配。当某台物理机资源空闲时，CREAM可以关闭它以节约能源，动态地将空闲的物理服务器转入待机状态，并在需要的时候通过网络唤醒技术（WOL，Wake On-Lan）自动地唤醒物理服务器。在4台物理服务器和8台虚拟机组成的集群上进行的长达7.5小时的实验表明，CREAM系统有效地降低了系统的总体能耗，节约了大约9.95%的能源。

. . . . . .

能耗模型

功率和能耗能用公式1和2表示。

E = P · T (2)

动态能耗可以用公式3定义：

Pdynamic = C · V2 · f (3)

. . . . . .

能耗模型

E = P · T (2)

. . . . . .

能耗模型

E = P · T (2)

. . . . . .

能耗模型

E = P · T (2)

. . . . . .

服务器不同组件的能源消耗

Disk(12W×1)

PSU Loss

PCI Slots(25W×2)

Memory(8W×8)

MotherboardOther

CPU 4core

Memory(8W×8)

PSU Loss

Disk(12W×1)

PCI Slots(25W×2)

Motherboard

服务器不同组件的能源消耗

. . . . . .

对能耗的建模

Fan等人发现了在服务器的CPU利用率和总功率之间的关系是线性关系，这种关系可以表示为公式4：

P(u) = Pidle + (Pbusy − Pidle) ∗ u (4)

其中u是CPU利用率，P(u)是在CPU利用率为u时估计的功率，Pidle是服务器空闲时的功率，Pbusy是服务器满载时的功率。作者还给出了一个更精确的非线性模型，由公式5表示：

P(u) = Pidle + (Pbusy − Pidle) ∗ (2u− ur) (5)

其中额外的r是校准因子。

. . . . . .

对能耗的建模

. . . . . .

对能耗的建模

. . . . . .

对能耗的建模

. . . . . .

对能耗的建模

. . . . . .

CPU利用率和能源消耗之间的关系线性公式4与测量值之间有5%以下的错误率，非线性公式5的错误率则是1%以下。根据试验导出的r的估计值是1.4。

CPU利用率和能源消耗之间的关系杨嘉晨5070379022 基于OpenNEbula的虚拟化服务器集群中节能的研究

. . . . . .

CPU利用率和能源消耗之间的关系线性公式4与测量值之间有5%以下的错误率，非线性公式5的错误率则是1%以下。根据试验导出的r的估计值是1.4。

CPU利用率和能源消耗之间的关系杨嘉晨5070379022 基于OpenNEbula的虚拟化服务器集群中节能的研究

. . . . . .

虚拟化技术的优势

通常虚拟化的作用是分散并重新整合物理的计算资源，从而虚拟化技术可以方便地得到以下优势:

1 服务器整合将多个未能充分利用的服务器资源整合在一起，从而节约硬件、管理成本、能源消耗。

2 软件迁移可以方便地迁移运行中的软件。3 应用整合应用可能需要更新的硬件或者软件支持，通过虚拟化技术可以提供所需的支持从而运行应用。

4 沙盒化通过把应用放置在虚拟出的执行环境中，可以避免应用对外界造成影响。

5 虚拟硬件可以虚拟出更多硬件。6 并行执行操作系统可以在同一套硬件环境上执行并行执行多个操作系统。

7 调试可以方便调试软件的执行过程。

. . . . . .

虚拟化技术的分类

在相关工作中我将介绍各个领域对于控制服务器能源消耗的研究进展。这里我先介绍一下对于控制服务器能源消耗的关键技术虚拟化技术（Virtualization）的一些背景知识。

指令集级别的虚拟化硬件抽象层的虚拟化半虚拟化操作系统级别虚拟化

. . . . . .

指令集级别的虚拟化

Bochs 这是一个开源的X86架构的PC模拟器。它可以模拟几乎所有的X86指令集。Bochs解释执行从开机到关机的每一条指令，并且模拟X86架构上需要的所有物理设备。Crusoe 这是一个利用VLIW(Very Long Instruction Word，超长指令字)的处理器动态执行X86代码的硬件解释器。QEMU 这是一个使用动态翻译技术的快速处理器模拟器。它支持两种模式，只模拟用户空间进程或者模拟整个操作系统。由于使用了动态翻译技术，它的执行速度比Bochs要快很多。

. . . . . .

硬件抽象层的虚拟化

VMWare VMWare的虚拟机管理器（VMM Virtual MachineManager）可以以独立的方式运行，也可以以寄宿的方式运行在一个宿主（host）操作系统内部。在宿主操作系统内运行时，VMWare通过插入驱动的方式获得特权执行权限。Virtual PC 微软的Virtual PC采用类似VMWare的方式执行。与VMWare不同的是，Virtual PC提供了在Macintosh计算机上二进制翻译执行X86代码的能力。然而Virtual PC具有更多VMWare所没有的缺陷，比如虚拟机创建之后就不能再修改其硬件配置，以及支持更少的外部设备类型和客户(Guest)操作系统类型。

. . . . . .

硬件抽象层的虚拟化

VMWare VMWare的虚拟机管理器（VMM Virtual MachineManager）可以以独立的方式运行，也可以以寄宿的方式运行在一个宿主（host）操作系统内部。在宿主操作系统内运行时，VMWare通过插入驱动的方式获得特权执行权限。Virtual PC 微软的Virtual PC采用类似VMWare的方式执行。与VMWare不同的是，Virtual PC提供了在Macintosh计算机上二进制翻译执行X86代码的能力。然而Virtual PC具有更多VMWare所没有的缺陷，比如虚拟机创建之后就不能再修改其硬件配置，以及支持更少的外部设备类型和客户(Guest)操作系统类型。

. . . . . .

半虚拟化上述虚拟化技术的优势在于可以不经修改地运行绝大多数操作系统，不过牺牲了大量性能来解释执行。当虚拟机的数量达到更大规模的时候，解释执行由于其架构特点导致效率难以承受。这种虚拟化技术叫做全虚拟化（Full-virtualization）。另一种方式是修改操作系统的代码，以获得更高的执行性能以及更好的可扩展型。有至少两种不同的途径做到这一点。Denali 威斯康星大学的Denali项目通过传统的系统调用的方式实现一套虚拟指令集和虚拟寄存器，为其上层的软件和操作系统提供一套虚拟硬件设备，从而做到虚拟化执行的能力。Xen Denali项目需要整个重新编写新的运行于其上的操作系统，与此不同，Xen通过对现有操作系统打补丁修改的方式，实现虚拟化从而允许现有操作系统上的应用程序保持不变。本文的实验系统采用Xen虚拟机管理器构建的虚拟化环境。User Mode Linux 用户模式的Linux采用相反的方式，将Linux实现于用户模式中，从而允许在一个普通操作系统的进程里运行一个Linux操作系统。

. . . . . .

操作系统级别虚拟化

全虚拟化方式和半虚拟化方式，都是在执行层次中添加一层VMM层实现。而操作系统级别的虚拟化直接在操作系统层中实现VMM的功能，从而实现虚拟化。操作系统级别虚拟化中比较著名的是Linux KVM（Kernel modeVirtual Machine），它是在操作系统中隔离出不同的VE（VirtualEnvironment，虚拟执行环境），每一个VE有不同的根文件系统、进程组、启动引导脚本、网络配置等，从而从效果上达到将一个操作系统当作多个操作系统使用的能力。

. . . . . .

操作系统级别虚拟化

全虚拟化方式和半虚拟化方式，都是在执行层次中添加一层VMM层实现。而操作系统级别的虚拟化直接在操作系统层中实现VMM的功能，从而实现虚拟化。操作系统级别虚拟化中比较著名的是Linux KVM（Kernel modeVirtual Machine），它是在操作系统中隔离出不同的VE（VirtualEnvironment，虚拟执行环境），每一个VE有不同的根文件系统、进程组、启动引导脚本、网络配置等，从而从效果上达到将一个操作系统当作多个操作系统使用的能力。

. . . . . .

硬件级别针对服务器节能的研究操作系统和应用级别对服务器节能的研究虚拟化技术以及Xen对节能的支持

. . . . . .

硬件级别针对服务器节能的研究

如同在上一章中介绍的，对于计算资源的节能的研究开始于硬件阶段，最初应用于电池供电的手持设备上。这些技术运用于服务器之后，主要导致了两大技术，分别是

DVFS Dynamic Voltage and Frequency Scaling，动态电压频率调节ACPI Advanced Configuration and Power Interface，高级电源管理接口

. . . . . .

根据在前面给出的公式3，CPU的功率由两个动态部分决定，分别是表示电压的平方的V2以及表示时钟频率的f。由此我们也可以看出，尽管可以单独地调整CPU频率，不过这对功率的影响并不那么显著，而调整CPU的工作电压通常需要调整到合适的工作频率，因此通常一起调整CPU的电压和频率以降低功耗。这种技术就是DVFS技术。虽然DVFS技术的应用看起来似乎很简洁明了，不过要将这项在手持设备中广泛运用的技术实际应用到服务器环境中，还是有很多问题有待解决。首先，因为现代计算机CPU架构的复杂性（比如有流水线、多级缓存等），预测能够符合应用程序性能需求的CPU时钟周期并不那么简单。并且对CPU时钟频率的改变将直接影响到一段程序的执行时间，从而DVFS将导致执行时间的非线性变化，比如说相比较于CPU密集型的进程，I/O密集型的进程的执行时间就不那么受到DVFS的影响。

. . . . . .

许多动态电源管理策略，比如上面提到的DVFS控制策略，可以被单独用硬件电路实现，不过这将导致相当复杂的实现逻辑以及不灵活。因此，为了解决这个问题，于1996年 Intel、微软、东芝联合发表了第一版的ACPI标准，旨在将电源管理机制和策略分离，统一电源管理机制的接口，并用软件方式实现电源管理策略。ACPI定义了一系列耗电状态，可以在系统中适时调整。其中比较重要的是：

S状态C状态P状态

. . . . . .

S状态—睡眠状态

S状态S0–S5描述了计算机处于何种睡眠（Sleep）等级。其中S0是正常运行状态。S3是通常操作系统提供的待机（Suspend）状态，也叫内存睡眠状态（Sleep to Memory），此时CPU停止供电，内存维持低功耗状态保持数据，失去供电时数据会丢失，部分外设维持供电，允许产生中断事件唤醒CPU。S5是通常操作系统提供的休眠（Hibernate）状态，也叫磁盘睡眠状态（Sleep to Disk），此时所有设备停止供电，可以切断外接电源供电。除了这三个常见的S状态之外，S1和S2状态是不同程度的睡眠状态，保持不同等级的CPU缓存的数据不会丢失。S4状态是通常操作系统的混合睡眠状态（Hybrid Suspend），在写入磁盘S5状态所需的休眠数据后进入S3睡眠，从而可以在保持供电时快速唤醒，在失去供电时不至于丢失数据。S状态间的切换可能需要人可感知的秒级时间间隔，并且通常由计算机的操作者手动发起切换操作。

. . . . . .

C状态—空闲状态

C状态C0–C3描述了CPU处于何种空闲（Idle）等级。其中C0-C3依次是CPU的运转状态、停机（halt）状态、停止时钟状态、以及睡眠（Sleep）状态。在CPU没有任务运转时，C状态处于C1以上等级。ACPI设备通常还记录了CPU处于C0和C1状态的累计时间。由于没有CPU时钟，C2以上等级的时间则不记录。C状态间的切换由操作系统的调度程序在处于空闲没有可以调度的任务时进行，不同C状态等级间的切换间隔对人的感知而言很短，但是对计算机而言相对很长。

. . . . . .

P状态—运行状态

当CPU处于运转状态时，它有可能处于某一种P状态，P状态P0–Pn描述了CPU处于何种电压/频率，每一个P状态描述一种DVFS的电压/频率设置组合。P0–Pn总是按照频率降序排列。通过调节P状态节省电能的技术在Intel CPU中被称作SpeedStep技术，在AMD CPU中被称为PowerNow! 或者 Cool‘n’Quiet技术，在VIA CPU中被称作PowerSaver技术。

. . . . . .

P状态—运行状态

当CPU处于运转状态时，它有可能处于某一种P状态，P状态P0–Pn描述了CPU处于何种电压/频率，每一个P状态描述一种DVFS的电压/频率设置组合。P0–Pn总是按照频率降序排列。通过调节P状态节省电能的技术在Intel CPU中被称作SpeedStep技术，在AMD CPU中被称为PowerNow! 或者 Cool‘n’Quiet技术，在VIA CPU中被称作PowerSaver技术。

. . . . . .

操作系统和应用级别对服务器节能的研究

如同上文所述，硬件中的节能相关研究关注于实现节能机制，从而将更多的节能策略留给操作系统层乃至应用层来实现。本节中我将讨论操作系统中实现的节能机制和相关研究。Pallipadi等人在Linux系统中实现了一套按需调节器（Ondemandgovernor）。该调节器监视每秒的CPU利用率，并设置一对时钟频率 /电压，对应当前的CPU工作负载，以保持CPU在大约80%的空闲。通过获取应用级别的负载数据而不是CPU利用率，可能达到更好的节能效果。Liu提到了通过排队预测来估计网页服务器负载的可能性。Horvath则实现了通过获取Apache服务器的吞吐率数据来指导调节CPU的DVFS方式，已经达到了比Linux内核的按需调节器更好的节能效果。Sachs等人开发了Illinois GRACE (Global Resource Adaptationthrough CoopEration)项目，他们提出在多层系统中通过正交自适应调节系统资源来满足应用的需求。

. . . . . .

虚拟化层对电源管理的影响

虚拟化技术及动态迁移技术的出现为这个领域注入了新的可能性。传统的负载均衡只能应用于HTTP服务器这样的无连接服务器，并且也不够灵活。而动态迁移的出现使得负载均衡能够施展在所有应用种类的服务器上，并且保证了不损伤用户体验。虚拟化层的引入允许对操作系统和其上的应用程序从运行它们的硬件环境中剥离出来。从而，有两种方式允许虚拟化层影响电源管理：

1 虚拟化层可以作为统一的电源管理的操作系统层，它监视整个系统的性能，并且适当地调节系统的DVFS等策略。

2 另一种途径是利用操作系统的特定的电源管理策略以及应用层的数据，然后映射那些对能耗控制相关的请求，综合考量这些来自虚拟机的请求并做出一致的决策。

. . . . . .

Xen对节能的支持..Xen在其ACPI相关驱动中实现了对CPU的P-State的调整策略。和Linux的电源管理子系统类似，Xen通过周期性地监视整个系统的CPU利用率，计算出合适的P-State，然后发出状态调节指令。Xen也提供了四种预设的调节策略:

Ondemand —根据当前的系统CPU利用率按需调节P-StateUserspace —根据用户的决策调节Performance —始终保持最高的时钟频率Powersave —始终保持最低的时钟频率

除了调整P-State之外，Xen也同样会调整CPU的C-State。并且Xen还支持虚拟机的LM（Live Migration动态迁移）技术，允许允许动态的VM整合。迁移技术是指在物理服务器之间搬运虚拟机。通常的迁移技术是通过停止虚拟机运行，然后复制虚拟机的内存数据，然后在目标物理机上恢复虚拟机运行的方式实现的。而动态迁移则允许在不中断虚拟机运行的前提下搬运内存，从而用户角度来看察觉不到迁移的过程。为了进行动态迁移，两台物理机都必须运行Xen，并且目标物理机必须有足够的物理资源（内存大小）。在LM开始时，Xen首先在目标物理机上建立一个虚拟机的空模板，然后不断的通过网络传输VM的内存，并监视哪些内存页被重写并重新传输。当Xen观测到重写的页面数量不再缩减之后，再终止源物理机上的虚拟机运行，并继续传输剩下为数不多的内存页面，然后在目标物理机上继续运行虚拟机。这么做的前提是所有虚拟机能够一致地访问磁盘存储，这通常使用NAS(Network Attached Storage)或者类似的方式实现，这样就避免了复制虚拟机的磁盘镜像。

. . . . . .

CREAM系统总体介绍OpenNEbula云管理器CREAM主循环CREAM性能监视器CREAM调度器

. . . . . .

CREAM系统总体介绍..

....CREAM.

OpenNEbula

CREAM的层次关系

CREAM构建于开源云管理框架OpenNEbula和开源虚拟机管理器Xen的基础上。这三者和虚拟机的管理的关系可以用左图表示。如同在图中所描述的，CREAM基于开源的虚拟化云管理引擎OpenNEbula 构建，它采用OpenNEbula搭建起来的云环境，调节控制由OpenNEbula管理的虚拟机。而OpenNEbula又基于Xen虚拟化技术构建起云环境。由于CREAM增加了更多OpenNEbula所不支持的虚拟机动态迁移决策，这一部分功能会抛弃OpenNEbula直接调用Xen执行。在Xen环境上则构建VM虚拟机。Xen提供了执行虚拟机的能力。在此基础上，OpenNEbula提供了创建和管理虚拟机集群的能力。我们的CREAM云管理器基于OpenNEbula构建，提供了对云资源的动态整合和调整的能力。

. . . . . .

OpenNEbula云管理器

在CREAM系统中，我使用了开源的OpenNEbula云管理器作为虚拟机的管理平台，负责创建、监视管理所有物理机和虚拟机组成的动态虚拟机池。

这样的服务器集群由如下部分组成：前端服务器(Front-end Server)

虚拟化服务器结点(Nodes)镜像仓库(Image Repository)OpenNEbula守护进程（Oned）OpenNEbula驱动程序（Drivers）

. . . . . .

OpenNEbula作为云管理器的优势..用户权限管理支持云环境的统一用户权限管理，多个云用户和管理员角色支持用户消耗的云资源（物理资源，不包括电能等动态变化的资源）的计数统计，以及更好的角色安全性。虚拟机镜像的集中式管理用OpenNEbula2.0版本以上构建的虚拟机镜像仓库（Image repository），支持仓库中的镜像的分类、访问控制。当创建虚拟机时，自动部署所需要的镜像到目标结点服务器上。虚拟网络管理支持虚拟机间、以及虚拟机和物理机存在的虚拟私有网络的统一管理。支持静态分配以及指定动态范围的IP、MAC地址分配。支持配置虚拟机的网络共享和网络隔离。虚拟机实例管理管理多种虚拟机管理器（VMM）创建出的虚拟机的生命周期，部署、创建、关闭、销毁、迁移虚拟机。支持在虚拟机的状态变化时触发指定脚本动作。虚拟机的共享存储管理支持采用多种共享存储方式，比如NFS共享存储、 iSCSI和LVM（Linux VolumeManager）共享存储。支持在不同的共享存储方式间复制虚拟机镜像文件。程序接口 OpenNEbula支持多种编程语言的访问接口，包括一套用C语言调用的libvirt虚拟化控制器库接口，一套XMLRPC（XML远程过程调用，XML　RemoteProcess Call）接口，以及通过Ruby、Java、Python等编程语言访问的接口。这给于了OpenNEbula极大的可扩展型。开源调度框架Haizea和我们的CREAM调度器都采用Python API与OpenNEbula相互调用。

. . . . . .

OpenNEbula的组成部分..OpenNEbula系统中的oned由以下几个子系统构成。

存储子系统（Storage）用于统一管理创建虚拟机所需要的磁盘和光盘镜像文件。物理机监视子系统(Information Monitor) 用于动态获取运行时期服务器集群中作为结点物理机的运行状态。通过IM驱动访问具体的虚拟机管理器以获取物理机数据。虚拟机监视子系统(Virtual Machine Monitor) 用于动态获取运行时期服务器集群中作为结点物理机的运行状态。传输子系统(Transmition Manager) 用于在镜像仓库和物理机之间部署虚拟机镜像。当虚拟机开始执行时部署到物理机的存储上，当虚拟机执行结束时传输回镜像仓库。调度子系统(Scheduler) 在提交到OpenNEbula虚拟机形式的任务中调度，分配物理资源给虚拟机，让虚拟机能够运行。调度子系统可以单独开启、关闭，没有调度子系统时，虚拟机按照用户指派的方式部署。可以用Haizea或者我们的CREAM的调度系统替换OpenNEbula的默认调度子系统。

. . . . . .

OpenNEbula中未能解决的问题 I

由于OpenNEbula目前还不够成熟，所以尚且具有相当多的问题没有解决。以下是我们认为其尚未解决的问题。

批处理模式的任务模型 OpenNEbula以虚拟机的生命周期的方式指派服务器集群中的任务。当虚拟机被提交时，OpenNEbula认为该任务开始执行，对该任务静态调度足够的计算资源，直到该虚拟机被关闭，表示任务执行结束。我们认为，这种对任务的描述方式不足以描述现今运行在服务器集群的任务。现在运行在服务器上的一般形式的任务，比如网页服务器或者数据库服务器，是开启之后就一直持续运行，直到服务维护的时候才停止。缺乏服务器动态整合 OpenNEbula的调度系统只在虚拟机部署前参与运算，并没有动态地调度搬迁虚拟机，因此不能应对动态变化的服务器负载。而通常在网页服务器这样的应用场景中，提交给服务器的负载需求是动态变化的，峰值时期的资源消耗将高于低谷时期，利用这一特点，我们可以在负载的低谷时期动态地整合服务器的计算资源节约更多能源消耗。

. . . . . .

OpenNEbula中未能解决的问题 II

系统程序级别的性能参数 OpenNEbula只能获取和记录系统级别的性能参数指标，但是如同Koller等人在中提出的，采用应用程序级别的性能参数来评估服务器的能源消耗可能比采用系统级别的性能参数更为有效。没有考虑到能耗模型 OpenNEbula的调度和分配算法认为，所有的物理计算资源一旦接受其管理，总是持续存在。这就意味着，整个物理服务器集群没有机会被关闭从而在低谷的任务负载时也消耗了大量的电力能源，没有了构建云服务器集群的优势。

OpenNEbula存在的这些缺陷不仅仅是OpenNEbula这个云集群管理软件存在的问题，它普遍地存在于包括Eucalyptus 在内的所有现有的云集群管理软件中。因此，我们在OpenNEbula的基础上重新定义了任务的描述方式，破除了上述这些限制，提出了我们的CREAM动态的云资源管理器系统。

. . . . . .

CREAM设计思想 I

针对上文描述的现存的云集群管理软件存在的问题，我们设计了CREAM云资源管理系统。它具有以下特点：

服务模式的任务模型在这种模型中，虚拟机中运行的任务被认为是一种服务，从它被提交给CREAM管理框架开始就持续运行，直到不定期的服务维护时才停止。这对管理框架的灵活性、动态性和自适应性等方面提出了更高的要求。服务器动态整合由于任务模型变成了服务模式，这就意味着需要认为虚拟机一旦开启，就会在很长一段时间内不再关闭，从而需要在虚拟机运行状态下监视虚拟机的运行状态并且动态整合服务器资源。

. . . . . .

CREAM设计思想 II

应用层获取数据根据Koller等人提出的观点，对于网页服务器应用这种真实服务器应用而言，通过应用层的系统性能数据来评估服务器负载，比通过系统级的性能数据要有效很多。因此，我们CREAM通过获取应用级的性能评估数据来估算服务器的动态负载，调节服务器的资源配比。搬迁虚拟机在应用层取得预测的服务器负载之后，根据预测负载来调整虚拟机的资源分配，这意味着通过调用Xen的LiveMigration虚拟机动态迁移来搬迁虚拟机的位置。动态关闭、唤醒物理机当某台物理机资源空闲时，我们可以关闭它以节约能源。研究显示，处于Idle空闲状态（C-0）的物理机将消耗它峰值功率的60%的功率，而处于待机状态（S-3）的物理机将只消耗其峰值功率的约1%。因此我们决定动态地将空闲的物理服务器转入待机状态，并在需要的时候通过网络唤醒技术（WOL，Wake On-Lan）自动地唤醒物理服务器。

. . . . . .

CREAM设计思想 III

因此，CREAM系统由三个主要部分组成，分别是CREAM的能耗监视器、负载监视器以及调度器。这三个部分由CREAM主循环依次调用，下面将依次讨论这几个部分的设计。

. . . . . .

CREAM主循环

CREAM系统和OpenNEbula的守护进程同时运行在Front end节点上。CREAM系统周期性地运行CREAM主循环，如代码，主循环控制CREAM的各个部分。

Listing 1: CREAM主循环

1 for i in range(0, SCHED_MONITOR ):2 reload_vm_config()3 measure_cpu_util()4 measure_app_qos()5 predict_cpu()6 schedule()7 wol_sleeped_hosts()8 migrate_vm()9 suspend_hosts()

. . . . . .

CREAM系统流程整个流程如图所描述。

..调度器.

应用监视器

应用性能

虚拟机监视器

资源利用率

迁移执行器

放置策略

睡眠执行器

睡眠策略

CREAM系统流程

. . . . . .

CREAM能耗监视器和负载生成监视器

CREAM系统的能耗监视器动态监视整个系统运行的能耗状态。我们采用力创公司开发的 JCB1-132型智能计量插座iPDU(智能功耗分配单元)来对整个物理服务器集群进行功耗测量和采集。CREAM系统需要生成和采集应用相关的系统负载数据。下一章中我将描述试验使用的应用负载。

. . . . . .

CREAM性能监视器

CREAM系统对于应用负载的描述，采用一般网页和数据库应用中都很容易获取的响应时间作为应用的QoS（Quality of Service）参数。因此，性能监视器被分为虚拟机的性能监视器、应用的性能监视器，以及性能预测器三大部分，

. . . . . .

CREAM虚拟机性能监视器

虚拟机性能监视器采集虚拟机的CPU利用率Ucurrent作为性能描述。通过不断获取虚拟机对物理机CPU的占用情况，来估计在当前应用负载下，虚拟机使用了多少物理机资源。CREAM通过shell管线2来实现虚拟机性能监视器。

Listing 2: CREAM虚拟机性能监视器

1 ssh HOSTNAME xentop−bi2 | grep VMNAME | awk’{print 4}’ |tail−n1

. . . . . .

CREAM应用性能监视器应用性能监视器采集来自虚拟机内的应用的响应时间 t作为应用的性能描述。在每个监视周期内，我们采集Sample次虚拟机的响应时间的数据，形成一组响应时间 ti，如公式6

ti, i ∈ 0, Sample (6)

然后我们设定一个期望的虚拟机服务的响应时间T，来作为衡量标准。根据这个标准我们计算出服务器上满足了QoS指标的次数c和比率r，如公式7和 7

c = count ti if ti < T (7)

Sample(8)

然后设定期望的满足比率R，我们根据这个满足比率 r与预设的违反比率R估计虚拟机是否满足其性能要求。

. . . . . .

Sample(8)

. . . . . .

Sample(8)

. . . . . .

Sample(8)

. . . . . .

Sample(8)

. . . . . .

CREAM性能预测..根据QoS的满足比率r和设定比率R以及当前的CPU利用率Ucurrent，我们预测虚拟机需要的CPU利用率为Upredict，根据公式9。

Upredict = Ucurrent ·Rr

CREAM的性能预测器的实现代码如代码3。

Listing 3: CREAM性能预测器

1 EXPECTED_QOS = 10002 RATIO = 0.83

4 def predict_cpu():5 global vm_cpu_utils,vm_cpu_demand,hosts,，vmsapp_qos6 for vm in vms:7 count = 08 for qos in app_qos:9 if qos < EXPECTED_QOS :10 count +=111 vm.cpu_demand = vm.cpu_utils*len(lines)/count*RATIO

其中EXPECTED_QOS是上文算法中的期望服务响应时间T，RATIO是上文算法中提到的期望的QoS满足比率R。

. . . . . .

CREAM调度器..OpenNEbula的调度只针对于虚拟机的创建阶段，一旦虚拟机创建好并运行在物理服务器上，则OpenNEbula只监视该虚拟机的运行状态，而不再重新调度虚拟机。换句话说，实际上OpenNEbula提供的调度器并不是真正意义上的调度器（Scheduler）而是某种资源分配器（Provisioner）CREAM调度器独立于OpenNEbula调度器运行，监视虚拟机的动态运行负载，迁移虚拟机以使其满足动态负载的压力。也就是说相比较于OpenNEbula提供的默认调度器，CREAM的调度器才是真正意义上的动态调度。为了澄清概念，这里再说一下Xen的调度器。Xen的调度器是类似于Linux的进程调度，作用是调度虚拟机在物理CPU上的执行时间。这个调度器和我们的CREAM调度器没有关系。CREAM调度算法本质上是一个两维约束的装箱问题的首次匹配算法(FirstFit)。为了减少虚拟机的迁移次数，同时避免虚拟机迁移的顺序问题，CREAM的调度执行了两次首次匹配算法。第一次在所有物理服务器集合上执行，首先计算出需要的物理服务器集合，第二次在这个所需集合上执行，优先防止虚拟机在其原来所在的物理机上。

. . . . . .

CREAM调度算法第一次装箱

Listing 8: CREAM调度1

1 def schedule():2 global vms,hosts,free_mem, free_cpu3 host_init(free_mem,free_cpu)4 use_host = set()5 for vm in vms:6 solved = False7 for host in hosts:8 if solved: break9 if free_mem[host.id] > vm.memory10 and free_cpu[host.id] > vm.cpu_demand:11 free_mem[host.id]−= vm.memory12 free_cpu[host.id] −= vm.cpu_demand13 use_host.add(host)14 solved = True15 host_init(free_mem,free_cpu)16 result = {}

. . . . . .

CREAM调度算法第二次装箱..

Listing 9: CREAM调度2

1 for vm in vms:2 solved = False3 if config[vm] in use_host:4 host = vm.on_host5 if free_mem[host.id] > vm.memory6 and free_cpu[host.id] > vm.cpu_demand:7 result [vm]=host8 free_mem[host.id]−= vm.memory9 free_cpu[host.id] −= vm.cpu_demand10 solved = True11 for host in use_host:12 if solved: break13 if free_mem[host.id] > vm.memory14 and free_cpu[host.id] > vm.cpu_demand:15 result [vm]=host16 free_mem[host.id]−= vm.memory17 free_cpu[host.id] −= vm.cpu_demand18 solved = True19 if not solved:20 free_mem[host.id]−= vm.memory21 free_cpu[host.id] −= vm.cpu_demand22 result [vm]= config[vm]23 return result

. . . . . .

CREAM执行虚拟机迁移

执行虚拟机迁移的方法用shell脚本实现，如代码10所示。

Listing 10: 执行虚拟机迁移

1 ssh FROM_HOST xmmigrate−l VMNAME TO_HOST

值得一提的是，虽然OpenNEbula的XMLRPC API中也提供了执行虚拟机迁移的接口，不过我们没有采用这个接口而是直接调用了Xen的。

. . . . . .

执行物理级的待机/唤醒是能源节约的主要来源。我们采用shell脚本实现虚拟机切换至S-3模式，具体的脚本代码非常简单，其中让机器进入待机部分的代码如代码13所示。

Listing 13: 执行物理机的待机

1 bash−c \"ssh HOSTNAME pm-suspend & \"

让机器WOL唤醒的代码如代码14所示。

Listing 14: 执行物理机的唤醒

1 wol HOST_MAC_ADDRESS

. . . . . .

验证服务器的CPU利用率与其功率的关系TPC-Wcpu负载生成器的实现实验环境搭建验证CREAM

. . . . . .

验证服务器的CPU利用率与其功率的关系..根据第一章中的公式4，物理服务器的CPU利用率和功耗之间成线性关系。这种线性关系对于我后文的预测算法极为重要，因此我需要首先验证这种线性关系的正确性。我用两台计算机组成一个混合系统来验证这种线性关系。这两台计算机的配置信息如表中列出的。

验证CPU利用率与其功率的线性关系的计算机配置计算机名称 CPU型号内存大小操作系统和虚拟机管理器版本server Intel Core2 Duo E7500 3 GiB OpenSuSE 11.3 Xen 4.0laptop Intel Core2 Duo T7300 2 GiB OpenSuSE 11.3 Xen 4.0

. . . . . .

验证服务器的CPU利用率与其功率的关系1我通过程序占用CPU的工作负荷，然后调节Xen虚拟机的P状态来改变CPU频率，最终数据中得出图。

−idle

800M1200M

1600M2000M

−idle

1600M1867M

2133M2400M

2667M2933M

ServerLaptop

. . . . . .

验证服务器的CPU利用率与其功率的关系2针对数据的进一步分析，将两个CPU利用率相加得到能耗。从两幅图中可以看出，CPU利用率与能耗之间的关系的确是线性关系。

0 500 1000 1500 2000 2500 3000 3500 4000 4500 500080

Total CPU Frequency (MHz)

. . . . . .

TPC-Wcpu负载生成器的实现

CREAM需要来自应用的性能信息，我选取了大部分网页和数据库服务器应用都很容易获得的响应时间作为指导调度的应用信息。为了验证CREAM模型的正确性，我设计了一个负载生成器来模拟一个标准的网页或者数据库应用。我在标准的网站性能测试软件TPC-W的基础上进行了简要修改，来作为我的负载生成器。TPC-W是事务处理性能评委会（TPC，Transaction Processing Performance Council）制定的一套网页事务处理基准测试。它模拟了一个标准的商业网站，包括一个网页服务器和一个数据库服务器，用模拟的浏览器在这个商业网站上进行图书购买等操作，来测试服务器对于网页和数据库处理的性能。在我的实验环境上的初步试验表明。TPC-W的性能评估的瓶颈主要在磁盘访问操作而不是CPU性能，因此难以反应真实的试验结果，所以我简要修改了TPC-W的一小部分代码，在每个网页请求中计算一次数据加密解密，以使得TPC-W应用从I/O密集型应用转变为CPU密集型应用。我将修改后的TPC-W称为TPC-Wcpu。

. . . . . .

变化的负载..

IBM官方网站一周之内访问量变化趋势图

另外，由于TPC-W一旦开始测试，其工作负载就不再变化，这种情况比较适合于模拟一个网站在数小时内的固定性能。而针对真实网站的访问量的研究表明，一个真实网站的负载通常是以日或周为周期波动的。根据Jeffrey S. Chase等人在文章中的总结和实验,数据中心的负载特别是网络服务的负载在短时间内,比如一天或者一周,变化会很大。如图所示是IBM官方网站一周之内的负载变化情况,从图上可以看出,一周内的每一天的下午4点钟是负载最高的时刻,是负载最低时刻的260%,这充分说明了数据中心负载变化的巨大波动性。

. . . . . .

模拟变化的负载..因此，我需要模拟一个以周期变化的动态负载。调用TPC-W时有参数EB的个数，这个参数不那么精确地反映了TPC-W网站的负载压力，可以从1变化到20。于是，我根据服务器的执行时间，动态调整不同的EB的值，产生如图所示的变化负载。

10:00:00 11:00:00 12:00:00 13:00:00 14:00:00 15:00:00 16:00:00 17:00:00 18:00:002

EB的数量遂时间的变化

. . . . . .

实验环境搭建物理服务器配置..

实验环境的物理机配置物理服务器名称 CPU型号内存大小操作系统和虚拟机管理器版本linux-nfs Intel Core2 Duo E7500 3 GiB OpenSuSE 11.3 Xen 4.0linux-GC1 Intel Core2 Duo E8400 3 GiB OpenSuSE 11.3 Xen 4.0linux-GC2 Intel Core2 Duo E8400 3 GiB OpenSuSE 11.3 Xen 4.0linux-GC3 Intel Core2 Duo E8400 3 GiB OpenSuSE 11.3 Xen 4.0

. . . . . .

实验环境搭建虚拟机配置

实验环境的虚拟机配置虚拟服务器名称 VCPU 内存大小操作系统

tpcw1 1 512 MiB OpenSuSE 11.3tpcw2 1 512 MiB OpenSuSE 11.3tpcw3 1 512 MiB OpenSuSE 11.3tpcw4 1 512 MiB OpenSuSE 11.3tpcw5 1 512 MiB OpenSuSE 11.3tpcw6 1 512 MiB OpenSuSE 11.3tpcw7 1 512 MiB OpenSuSE 11.3tpcw8 1 512 MiB OpenSuSE 11.3

. . . . . .

对CPU预测器的结果评估

10:30 10:40 10:50 11:00 11:10 11:20 11:30 11:40 11:50 12:00 12:10 12:20 12:30 12:40 12:50 13:000

2.5x 10

Avg CPU Frequency

Demand CPU Frequency

. . . . . .

验证CREAM调度器计算的调度策略

10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00

linux−nfs

linux−GC1

linux−GC2

linux−GC3

. . . . . .

验证CREAM节约的能耗

10:00:00 11:00:00 12:00:00 13:00:00 14:00:00 15:00:00 16:00:00 17:00:00 18:00:0050

NON−CREAM

基于opennebula的虚拟化服务器集群中节能 的研究

Technology

基于opennebula的虚拟化服务器集群中节能的研究