Transcript XEN答辩fc - xengreencom

基于XEN虚拟机的
绿色计算
项目组成员：杨嘉晨、丁一、梁昊
指导老师：戚正伟
2010.07.05 – 2010.08.14
项目回顾
O 1~2周：实验环境的搭建及熟悉
 CentOS操作系统安装
 Xen在CentOS上源码安装
 SVN平台建立
 Xen的基本指令的熟悉
 网络文件系统（nfs，iSCSI）的搭建
 在VM上安装不同的OS，并通过Save / load、
Migrate、Live migrate三种迁移方式，nfs、iscsi
两种网络文件系统进行简单迁移，简单熟悉xm
api
 阅读相关领域论文
项目回顾
O 第3周
 测试在两个机器之间来回迁移VM，并测试
在迁移造成的down time。
 明确了以Shares and Utilities based Power
Consolidation in Virtualized Server
Environments为指导论文，通过已搭建的环
境，实现其算法并对所得结果进行分析，并
尝试改进算法作为项目目标。
项目回顾
O 4~6周
 使用PYTHON语言实现了论文提及算法，并
加以实验。
 通过算法，实现了一个简单的VM分配控制
器。通过检测CPU利用率及功耗，此控制器
可以根据VM的min,max,share值，分配VM至
PM。达到绿色计算的目的。
Shares and Utilities based Power Consolidation in
Virtualized Server Environments
O 现有的VM管理工具
O 没有考虑到资源分配与动态调整
O 没有考虑到节能因素
O 提供五个VM分派算法
O BS、GM、GMM、EMM、PEMM
O 考虑到上诉因素
O 通过模拟运算得出PEMM各方面最优
资源分配与动态调整
O Hypervisor支持调整VM获得资源的max、
min、share。
O 管理工具倾向于制定consolidation策略，并
给出每个VM获得资源的确定大小。
O 如果管理工具能够动态调整，则会更节
能。
VM1
Min
VM1
Size
VM2
Max
VM1
Max
VM2
Size
VM2
Min
动态调整的影响
O 在高负载下，动态调整MMS会得到更好的性能指标。
O Consolidation的结果是所有PM处于高负载状态。
分配算法对比
缩写 英文名 中文名 时间复杂性
行为描述
BS
Basic
Strategy
基础策略
M•log(M)+M•N
该算法模拟一个典型的系统管理员的行为，为每
台 VM 分配最大所需资源，并用first-fit方式放
置 VM 。
GM
Greedy
Max
贪心最大
M•log(M)+N•log(
N)+M•N
该算法首先将 VM 按照其最大资源需求排序，然
后采用与BS同样的策略用first-fit放置。
GMM
Greedy
Min Max
贪心最小
最大
M•log(M)+N•log(
N)+M•N
该算法基于GM，同时考虑 VM 的最小与最大资源
需求。
M•log(M)+N•log(
N)+M•N2logN
该算法首先考虑 VM 的需求最小值，然后尝试扩
展一些 VM 获取的资源量以充分利用 PM 的剩余资
源。每次尝试扩展时，都会比较扩展后相对于扩
展前的利用率收益，以决定是否实施扩展。
M•log(M)+N•log(
N)+M•N2logN
该算法基于EMM，计算扩展收益时，不仅考虑增
加 VM 带来的性能收益，还考虑增加 PM 会额外带
来的能源开销折算成的负收益。不同于以上算法，
PEMM尝试使用更少的 PM 来满足需求，达到节能
的目的。
EMM
Expend
Min Max
PEMM
Powerawared
Expend
Min Max
扩展最小
最大
能源扩展
最小最大
BS、GM、GMM
Server
VM1 1ma
min
x
reservation O BS：
VM2 min
max
VM3min
Server 2
VM4
min
max
Server
3 ma
VM6
min
x
VM5 min
max
ma
x
VM8
min
VM7
min
ma
x
O 只排序PM
O GM:
O 按照max时的
utility排序VM
max
Sorted by power rate Pj / Cj
O GMM:
O 同时考虑最
大最小值
EMM、PEMM
O EMM：首先按照min放置VM，之后试图扩
展一些VM的资源以利用PM的剩余资源。
O 实现算法上，每添加一台VM，计算添加并
扩展之后总体utility的收益，由此决定VM放
置在哪台PM上。
O PEMM：计算收益时，不仅仅考虑VM，还
考虑额外增加PM时的能耗，将能耗换算为
负收益。
模拟实验结果
系统功能
O
多种 VM分配算法的实现框架。
O
由于 VM 分配问题本质上是一个背包问题，属于NP问题，故实现的算法都是启
发式的搜寻算法而不是最优算法。
根据分配算法，分配 VM 到 PM 上运行。
O 对分配到特定 PM 上的 VM 根据min, max, share分配资源。
O 监视分配到 PM 上的 VM 的运行状态，根据 VM 分配算法的分配结果，执
行对 VM 的控制。控制包括：
O
create创建
 migration 迁移
 close & destory 关闭
 ajustment 调整 VM 的资源占用

VM 启动后的自动配置，运行指定服务。
O 收集 VM 的性能测量数据，包括
O
VM 的cpu利用率
 VM 的http响应时间

分布式系统组成
Dispatching Server
分派服务器
O 职责
运行dispatcher分配算法，并运行所有参
数收集程序的服务器。
O 软硬件环境
CentOS 5.5
Dispatching Server
分派服务器
文件名
描述
dispatch_plan.py
分配计划，指导dispatcher自动化地按照计划运行上述
分配算法，对每一种算法，逐渐增加 VM数量。
dispatcher.py
分配算法框架。将算法计算出的分配策略写入每一个虚
拟机的stat文件。
└─dispatcher_BS.py
BS实现。
│dispatcher_GM.py
GM实现
│dispatcher_GMM.py
GMM实现
│dispatcher_EMM.py
EMM实现
│dispatcher_PEMM.py
PEMM实现
util_measure.py
监视并测量所有VM的cpu utility并写入util_log日志。
set_arch_count.py
由dispatch_plan调用或者管理员手动调用，设置开启的
虚拟机总数，开启虚拟机池中的相应虚拟机
Storing Server
存储服务器
O 职责
运行NFS服务，在nfs的根目录上保存
所有系统代码，以及所有虚拟机的硬
盘镜像，为系统运行提供持久存储。
O 软硬件环境
CentOS 5.5
NFS 服务器
PM
物理机服务器
O 职责
运行xen，dom0中运行CentOS。其上运行
monitor.py，监视分配给自己的VM的状态，并根据
其状态控制VM的启动、迁移、关闭，并分配PM资
源。
O 软硬件环境
Xen 3.4.3
CentOS 5.5 linux-xen 2.6.18内核
dom0_mem = 1024 MB
Intel Core 2 Due E8500 3.16GHZ×2
2GB物理内存资源
PM
物理机服务器
文件名
描述
输出文件
monitor.py
监视VM的状态，根
据dispatcher的分配
结果控制VM
xmlog_server_ip
xmapi.py
VM管理服务的抽象
API
N/A
xmapi_xm.py
通过xm工具实现的
VM管理服务
N/A
HPL_gen_mpdhosts.
py
/home/sesjtu/mpd.
配置HPL benchmark
hosts
的mpdhosts文件为
/home/sesjtu/N_ho
当前开启的所有VM
sts
HPL_get_data.py
获取HPL benchmark
HPL_data
测试数据
VM
虚拟机
O 职责
运行虚拟机，其中运行测量虚拟机性
能的各服务器组件。
O 软硬件环境
Archlinux 10
Python 2.6
虚拟机分配1个vcpu
128MB内存
VM
虚拟机
文件名
描述
占用端
口
res_server.py
报告VM的response time
8000
util_server.py
报告VM的virtual cpu utility
8800
cpu_usage.py
报告VM的cpu占用率，百分比单位
8880
pydoc
提供python doc的http服务，用于确认VM已
8888
经正常开启
/etc/vm/set_ip_as_
mac.py
在VM的初始化启动时期，VM根据分配到
的mac计算出自己的ip并做相应网络设置。
/etc/vm/init.sh
VM启动末期，设置好ip之后，mount位于
N/A
storing server的NFS，并运行
/mnt/nfs/hostname/init.sh的后期启动脚本。
lookup_vmname.py
设置好ip并mount了NFS之后，根据ip查找
自己的虚拟机名
N/A
N/A
系统架构详述
组件模型
O 公用代码
公用代码供所有其余组件引用。
文件名
描述
输出文件
VM.py
对VM状态的抽象，可写入
stat文件，或者从stat文件
读出
stat
server.py
对Server状态的抽象，可写
入server_ip文件，或者从
server_ip文件读出
server_ip
美化输出格式，让对象列表
print_pretty.py 的输出呈现csv格式，方便
N/A
数据处理
get_vms.py
查询并读取所有VM的状态
N/A
组件模型
O 测试 & 数据收集代码
这些代码在主框架之外，度量评估VM的性能参数。对于每一个参
数，代码都是成对出现，一个位于VM中生成数据，一个位于
Dispatching Server上，收集来自所有VM的数据并记录。
度量参数
VM上的数据生
端口
成代码
DS上的数据收集
代码
日志记录
文件
虚拟利用率
util_server.py
8800
util_measure.py
util_log
响应时间
res_server.py
8000
response_time.py
res.csv
vcpu利用率
cpu_usage.py
8880
N/A
N/A
组件间通信模型
O XenGreenCom系统是一个分布式系统，组
件间的通讯方式分为两种：
O 黑板模式
O http通讯
黑板模式
实现方式
每一个独立的组件，通过写入一个存放在nfs上、属于自己的
黑板文件，来报告该组件的当前状态。每一个黑板文件的结
构是定义了一些特殊变量的python脚本。其它组件通过读取
并解析黑板文件上的内容，来决定自己的行为。组件之间避
免直接通讯，通过黑板文件实现间接通讯。
O 优点
任何时刻，系统管理员可以手动修改黑板文件的内容，从而
控制整个系统的行为。并且，关闭并修改任何一个组件，都
不会影响到系统其余部分的正常运作，因为黑板文件的内容
会保持不变。
O 缺点
周期性地检查黑板内容效率很差，且周期很长，实现中为了
达到nfs同步的速度，周期至少是5s这样的数量级。
但是考虑到本系统组件的基本操作，比如虚拟机动态迁移的
耗时是20s左右，虚拟机冷启动的耗时是40s左右，5s的周期
性对于我们实现的系统而言不算是太大的缺陷。
O
系统中的黑板文件
文件名
arch_#/stat
server_ip
黑板撰写者
黑板阅览者
描述
•monitor.py
•set_arch_count.py
•dispatcher.py
•get_vm.py
•dispatcher.py
•xmapi_xm.py
•lookup_vmname.
p
该文件产生自VM.py的
write，描述一台虚拟机
的属性
•monitor.py
pubkey/arch_
•ssh-keygen
#_pubkey
•dispatcher.py
该文件产生自server.py
的write，描述一台PM
的属性
•sshd
在pubkey目录中统一放
置所有VM用ssh-keygen
生成的dsa公有密钥。
在VM启动时，将这些密
钥统一收集到
~/.ssh/authorized_keys
文件，授权所有VM间的
相互信任。
http server/client通讯
O 实现方式
通过开放http服务，对外公布数据。
系统中引入这种通讯方式的地方，都是前述的，用
于VM的性能等指标数据测量与收集的地方。
O 优点
该种方式建立起来的进程间通讯，无论从稳定性、
速度等方面考虑都受到严格验证，并且只需要一个
普通浏览器就可以很容易地调试。
O 缺点
解析http请求的方式实现复杂，占用一个通信端口。
并且任何一端程序失败，都会导致链接断开。
系统运行流程
Monitors
Dispatcher
Plan
Dispatcher
PMs
VM 1
Stat
VM 2
Stat
Util_Server
Util_Server
...
VM n
Stat
Util_Server
Migrate/Create/Destroy
Util_Data
网络和NFS服务
O 系统设置的第一步是建立起一个内部局域网，
保证所有虚拟机的网络连接性，同时内部网路
有助于维持虚拟机迁移时的稳定性。
hostname
IP address
MAC address
数量
描述
cent#
192.168.2.1#
物理网卡MAC
3
PM 物理机
arch_#
192.168.2.10#
00:1B:C0:A8:02:(64
+#)
21
VM虚拟机，MAC地址由ip地址算出。
cent0
192.168.2.10
物理网卡MAC
1
Storing Server，实现中运行于PM1
上
cent0
192.168.2.10
物理网卡MAC
1
Dispatching Server，实现中运行于
PM1上
O 网络正常配置之后，Storing Server开始提供
NFS服务，为所有PM和VM提供统一的数据存
储。
PM的启动
O PM在CentOS启动时，通过/etc/fstab配置，
自动挂接 nfs到/mnt/nfs位置上。
O 启动monitor.py，首先通过读取/proc的方式
收集物理机的相关性能参数，包括cpu频率、
ip地址等，写入server_ip文件。这一步是将
PM注册给Dispatcher，DS会读取所有的
server文件来获取可用PM列表。
O 随后monitor进入监视循环，每一次监视周
期中，逐一读取每一个VM的状态，并执行
相应操作。
Monitor行为
VM被分配给
VM状态
了当前PM?
VM在当前
执行的操作
PM上运行？
T
stop
T
关掉该VM。
T
stop
F
无。
T
create
T
修改VM的状态为run。
T
create
F
调用VM的创建脚本，创建VM。
T
run
T
读取并确保VM被分配到dispatcher
决定的资源量。
T
run
F
无。等待别的PM将该VM迁移过来。
F
stop
T
关掉该VM。
F
run
T
将该VM迁移到它被分配到的PM上。
F
create
T
输出并记录报错信息，并关掉该
VM。
F
-
F
无。
VM创建脚本
O VM创建脚本
 VM是通过arch.cfg脚本创建的。
 在该脚本中，读取当前VM被分配的ip地址，
并据此算出MAC地址，设置虚拟网卡。
 VM的MAC地址是IP地址的16进制表示，前缀
00:1B形成的，在VM的OS启动时根据MAC地
址再反向算出IP地址。
VM arch 启动脚本
 安装在VM中的arch被配置为自动登录。
 /etc/vm/init.sh执行以下序列：
 查询自己被分配的MAC地址并回算出IP地址。
 用ifconfig重新设置IP地址。
 挂载SS上的NFS到/mnt/nfs中。
 调用lookup_vmname.py，在/mnt/nfs中，根据自己的IP地
址推算出自己的hostname。
 设置自己的hostname，并同时设置$VMNAME环境变量。
 进一步调用位于/mnt/nfs/$VMNAME/init.py的python脚本。
（该脚本目前为空）
 进一步调用位于/mnt/nfs/$VMNAME/init.sh的bash脚本。
VM arch 启动脚本
 /mnt/nfs/$VMNAME/init.sh执行以下序列：
 检查/mnt/nfs/pubkey中是否存在自己的pubkey，若没有，调用
ssh-keygen生成自己的dsa公钥密钥对。
 收集/mnt/nfs/pubkey中的所有VM的公钥，记录到
~/.ssh/authorized_keys，信任所有其它的VM。
 开启 VM 虚拟机中列出的所有http服务，开始监听相应端口。
 开启HPL benchmark服务。
度量参数
VM上的数据生
端口
成代码
DS上的数据收集
代码
日志记录
文件
虚拟利用率
util_server.py
8800
util_measure.py
util_log
响应时间
res_server.py
8000
response_time.py
res.csv
vcpu利用率
cpu_usage.py
8880
N/A
N/A
实验数据分析
实验数据分析
图1 utility变化图
（VM每过定长时间增加一台，PM按需增长）
实验数据分析
图2 utility与VM个数
实验数据分析
图3 考虑功耗后的utility变化图
实验数据分析
图4 考虑功耗后 VM与utility关系图
数据分析
O BS,GM,GMM曲线
 在X轴方向上长度较短
 相同物理机数量上能够
放置的VM数量较少
 相同任务量的情况下这
三种算法需要更多的物
理机资源来完成。
O PEMM曲线




该曲线分为明显的3段
第一个折点
第二个折点
PEMM在接受了更多的
VM的情况下,utility还有上
升的空间.
数据分析
O 新开物理机的能耗作
为影响utility的参数
O 参数调小,曲线升高,反
之参数调大,曲线降低
O 这个参数会影响到
tradeoff的大小,可以
在节能模式下将参数
调大或者在性能模式
下将参数调小.
数据分析
O PEMM算法改进设想:
VM1
VM2
VM3
VM4
PM1 On
VM1
VM2
PM1 On
PM2 On
VM3
PM3 Off
VM4
PM2 On
PM3 Off