Transcript XEN答辩 - 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。达到绿色计算的目的。
系统功能
O
O
O
O
多种 VM分配算法的实现框架。 由于 VM 分配问题本质上是一个装箱问题，属于
NP问题，故实现的算法都是启发式的搜寻算法而不是最优算法。
根据分配算法，分配 VM 到 PM 上运行
对分配到特定 PM 上的 VM 分配资源。系统实现了分配CPU利用率资源。
监视分配到 PM 上的 VM 的运行状态，根据 VM 分配算法的分配结果，执行对
VM 的控制。控制包括：




O
O
create创建 调用每个 VM 自身的创建脚本，在指定 PM 上创建该 VM 。创建之前保证 PM
上的资源足够容纳该 VM 。
migration 迁移 将一台 PM 上的一个 VM 动态迁移live migration到另一台 PM 上。分配算
法在不同初始条件的前提下，有可能将一台已经分配过的 VM 重新分配，考虑到迁移的
效率远快于关闭并重新开启，并且迁移能够保证 VM 上的所有服务继续运行，故我们实
现了虚拟机的动态迁移。
close & destory 关闭 如果分配算法决定排除一台已经分配到 PM 的 VM ，则将其关闭。
ajustment 调整 VM 的资源占用。实现中通过xm工具调整 VM 的weight与cap值来实现。
VM 启动后的自动配置，运行指定服务。
收集 VM 的性能测量数据，包括


VM 的cpu利用率
VM 的http响应时间
分配算法对比
缩写
英文
名
中文名
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 的最小与最大资源
需求。
EMM
Expend
Min Max
扩展最小
最大
M•log(M)+N•log(
N)+M•N2logN
该算法首先考虑 VM 的需求最小值，然后尝试扩
展一些 VM 获取的资源量以充分利用 PM 的剩余资
源。每次尝试扩展时，都会比较扩展后相对于扩
展前的利用率收益，以决定是否实施扩展。
PEMM
Powerawared
Expend
Min Max
M•log(M)+N•log(
N)+M•N2logN
该算法基于EMM，计算扩展收益时，不仅考虑增
加 VM 带来的性能收益，还考虑增加 PM 会额外带
来的能源开销折算成的负收益。不同于以上算法，
PEMM尝试使用更少的 PM 来满足需求，达到节能
的目的。
能源扩展
最小最大
时间复杂性
*
行为描述
分布式系统组成
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 双核处理器
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
8800
.py
util_meas
ure.py
util_log
响应时间
res_server
8000
.py
response_
res.csv
time.py
vcpu利用
率
cpu_usag
e.py
N/A
8880
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
...
VM n
stat
Migrate/Create/Destroy
Util_Data
系统运行流程
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 网络正常配置之后，StoringServer开始提供
NFS服务，为所有PM和VM提供统一的数据存
储。
系统运行流程
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
无。
系统运行流程
O
VM创建脚本



O
VM是通过arch.cfg脚本创建的。
在该脚本中，读取当前VM被分配的ip地址，并据此算出MAC地址，设置虚拟网卡。
VM的MAC地址是IP地址的16进制表示，前缀00:1B形成的，在VM的OS启动时根据
MAC地址再反向算出IP地址。
VM arch 启动脚本














安装在VM中的arch被配置为自动登录，在登录的最后阶段，会执行/etc/vm/init.sh中
的启动脚本。
/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脚本。
/mnt/nfs/$VMNAME/init.sh执行以下序列：
检查/mnt/nfs/pubkey中是否存在自己的pubkey，若没有，调用ssh-keygen生成自己
的dsa公钥密钥对。
收集/mnt/nfs/pubkey中的所有VM的公钥，记录到~/.ssh/authorized_keys，信任所
有其它的VM。
开启 VM 虚拟机中列出的所有http服务，开始监听相应端口。
开启HPL benchmark服务。
实验数据分析
图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