XEN答辩 - xengreencom

Report
基于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

similar documents