Live Migration

在线迁移的好处太多太多,前段时间由于客户用的虚拟机对内存需求量过高,导致节点内存不够需要扩容,而由于是线上,只好两方人员凌晨来进行内存扩容,涉及到开发,测试,运维以及客户机房,运维一堆人,而且需要各种验证,关机,扩容,开机等,时间拉得十分长,如果顺利则已,由于是和硬件打交道,假如出现了硬件之间不兼容之类的问题,肯定会是一个大坑,甚至出现节点上虚拟机无法使用等风险,此时遥想如果能够在不中断服务的前提下,直接通过一种在线迁移的方式,将各种运行着业务的虚拟机迁移到大容量的节点上,既过渡平滑又节省大量人力,是一个完美的解决方案

去年测试过H版OpenStack的live-migration接口,对于配额容量比较小的虚拟机,直接调用在线迁移接口,的确丝毫感觉不到任何动静,就的确更换了其宿主机,但是做了一种极端的情形,创建了一台32G内存的虚拟机,然后通过一个内存负载工具,将虚拟机内存负载增加到80%~90%,来测试一下服务中断时间,这里主要就关注网络连通性情形

负载如下

top - 09:13:41 up 12:32,  2 users,  load average: 0.63, 0.19, 0.10
Tasks:  72 total,   2 running,  70 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  33018772 total, 32800052 used,   218720 free,      936 buffers
KiB Swap:        0 total,        0 used,        0 free,     7180 cached

测试的结果网络的中断时间达到了几百秒

Start: 2015-07-19 09:15:38
Stop: 2015-07-19 09:20:52

当时刚来公司,也没有进一步细细地测试以及原因是什么,当时的结论就是虚拟机内存负载占满,热迁移持续时间很长,而且网络会中断许久

今年在许多新需求的要求下,重新进行了在线迁移的测试

而在今年与同事一起进行测试的时候,在当前nova-compute的配置下,调用libvirt热迁移接口时传入的flag值是默认的“VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER”。根据flag的值,源端虚拟机在迁移开始时会被pause,这样网络就会中断,迁移完成之后才会恢复。调用libvirt热迁移接口时可以指定flag参数为“VIR_MIGRATE_LIVE, VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER”,这样在迁移时就会保持源端虚拟机始终处于running状态。但是如果源端虚拟机内存刷新率较高就会出现qemu无限迭代拷贝内存的情况,这时热迁移永远不会结束或者需要非常久的时间才会结束。

这里可以得到两个信息量:

1:目前测试的在线迁移,调用接口之后,就会立马将虚拟机PAUSE住,直到迁移结束,也就是说这个过程中是断网的

2:想要不断网也是可以的,改变一下flag参数即可,但是会出现另一个问题,如果内存刷新率比迁移数据传输更快的话,那么迁移永远赶不上刷新的进度,导致迁移永远无法结束

下面再来看看去年测试的这套环境,庆幸还在

先看看网络传输环境,其实才前兆传输速率

~$ /sbin/ethtool eth0.100
Settings for eth0.100:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Half 1000baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Half 1000baseT/Full
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Full
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: off
Cannot get wake-on-lan settings: Operation not permitted
	Link detected: yes

那么在迁移过程中,宿主机上验证留传输速率,正好大概在前兆范围内

########################################################################################################################
2016-07-28 14:48:59 eth0.100 | rx bps:	110.9 M	bytes/s	| rx packets:	10.0 K	pkts/s	| rx dropped:	0.0  	pkts/s
2016-07-28 14:48:59 eth0.100 | tx bps:	3.7 M	bytes/s	| tx packets:	9.5 K	pkts/s	| tx dropped:	0.0  	pkts/s
########################################################################################################################
2016-07-28 14:49:00 eth0.100 | rx bps:	111.7 M	bytes/s	| rx packets:	10.1 K	pkts/s	| rx dropped:	0.0  	pkts/s
2016-07-28 14:49:00 eth0.100 | tx bps:	2.2 M	bytes/s	| tx packets:	9.8 K	pkts/s	| tx dropped:	0.0  	pkts/s
########################################################################################################################
2016-07-28 14:49:01 eth0.100 | rx bps:	110.4 M	bytes/s	| rx packets:	10.9 K	pkts/s	| rx dropped:	0.0  	pkts/s
2016-07-28 14:49:01 eth0.100 | tx bps:	4.5 M	bytes/s	| tx packets:	10.2 K	pkts/s	| tx dropped:	0.0  	pkts/s
########################################################################################################################
2016-07-28 14:49:02 eth0.100 | rx bps:	110.7 M	bytes/s	| rx packets:	11.0 K	pkts/s	| rx dropped:	0.0  	pkts/s
2016-07-28 14:49:02 eth0.100 | tx bps:	2.8 M	bytes/s	| tx packets:	10.1 K	pkts/s	| tx dropped:	0.0  	pkts/s
########################################################################################################################
2016-07-28 14:49:03 eth0.100 | rx bps:	112.4 M	bytes/s	| rx packets:	10.7 K	pkts/s	| rx dropped:	0.0  	pkts/s
2016-07-28 14:49:03 eth0.100 | tx bps:	1.3 M	bytes/s	| tx packets:	9.8 K	pkts/s	| tx dropped:	0.0  	pkts/s
########################################################################################################################
2016-07-28 14:49:04 eth0.100 | rx bps:	112.0 M	bytes/s	| rx packets:	11.0 K	pkts/s	| rx dropped:	0.0  	pkts/s
2016-07-28 14:49:04 eth0.100 | tx bps:	4.8 M	bytes/s	| tx packets:	10.8 K	pkts/s	| tx dropped:	0.0  	pkts/s
########################################################################################################################
2016-07-28 14:49:05 eth0.100 | rx bps:	111.3 M	bytes/s	| rx packets:	10.1 K	pkts/s	| rx dropped:	0.0  	pkts/s
2016-07-28 14:49:05 eth0.100 | tx bps:	1.7 M	bytes/s	| tx packets:	9.4 K	pkts/s	| tx dropped:	0.0  	pkts/s
########################################################################################################################

因此在我测试过程中,所有的时间都花在了32G内存负载的拷贝中,此时已经被pause住了,就不会有内存刷新了,就直接依赖网络传输,32GB /100MBps 大约300秒左右,与去年验证的5分钟左右相符

也就是说,其实耗时长以及导致断网,与云网络其实没有任何关系,主要取决于live-migration的接口传参导致虚拟机pause断网,而耗时过长则取决于宿主机数据传输的带宽

发表回复