虚拟机在线迁移实验V2——下

文章目录
  1. 1. 前言
  2. 2. 前情回顾
  3. 3. 实例准备
  4. 4. 脚本和软件准备
    1. 4.1. 总迁移时间
    2. 4.2. 停机时间
    3. 4.3. 迁移数据量
    4. 4.4. xshell
  5. 5. 实验流程
  6. 6. flavor实验
    1. 6.1. 系统压力实验
    2. 6.2. CPU实验
    3. 6.3. 内存实验
    4. 6.4. 磁盘实验
  7. 7. 网络故障实验
    1. 7.1. 网络延迟
    2. 7.2. 丢包
    3. 7.3. 包重复
    4. 7.4. 包损坏
  8. 8. 后记

前言

毕业论文送审的日期是3月22日,cloud2019的deadline也是3月22日。大概从2月27日开始写毕业论文,早八点半晚十点,周末不休,3月22日终于写完送审了,算是完成了一件大事。之后,还有两件大事:一个是实现阅卷系统,一个是发表小论文。

本来打算3月20日抽出一天时间做实验写小论文,没想到实验环境崩了!无奈只能放弃cloud。论文送审后一直在忙着修复实验环境,2月24日晚上十点左右,终于修复成功!是时候完成小论文了!

前情回顾

《虚拟机在线迁移实验V2——上》一文中,实验遇到瓶颈,所以不得不重新设计实验。经过思考,打算把web服务换成mysql服务,在实例中进行测试。但是,实验表明,如果在迁移过程中对mysql试压,那么会出现和web服务同样的问题,迁移无法成功。所以,本文中去掉了服务降级这个指标,只测量停机时间、迁移时间和迁移数据量。

实例准备

1、在horizon控制台,项目,计算,镜像。使用xenial-server-cloudimg-amd64-disk1.img镜像创建ubuntu16的镜像模板。

2、创建实例类型m1.tiny2,CPU个数为1,内存为512M,磁盘为5GB。

3、使用ubuntu16的镜像模板创建实例ubuntu0、ubuntu1、ubuntu2、ubuntu3、ubuntu4,实例类型分别选择m1.tiny2、m1.small、m1.medium、m1.large、m1.xlarge。之所以不使用默认的m1.tiny,是因为m1.tiny的磁盘太小,只有1G,无法安装ubuntu16。

4、创建成功后,分别分配浮动IP。

PS:在进行迁移实验时,关闭其他实例,防止资源占用产生干扰。

脚本和软件准备

总迁移时间

在控制节点,新建mtime.sh脚本:

1
2
3
4
5
#!/bin/bash
time1=`grep 'live-migration' list.log | head -n 1 | awk '{print $24}'`
time2=`grep 'live-migration' list.log | head -n 1 | awk '{print $26}'`
time=$(($(date +%s -d $time2) - $(date +%s -d $time1)));
echo "$time s";

新建allmtime.sh脚本,可以计算所有迁移时间:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#!/bin/bash
time1=`grep 'live-migration' list.log | awk '{print $24}'`
time2=`grep 'live-migration' list.log | awk '{print $26}'`
IPS=' '
array1=($time1)
array2=($time2)
length=${#array1[@]}
COUNTER=0
while [ $COUNTER -lt $length ]
do
COUNTER=`expr $COUNTER + 1`
t1=${array1[COUNTER]}
t2=${array2[COUNTER]}
time=$(($(date +%s -d $t2) - $(date +%s -d $t1)));
echo "$time s";
done

停机时间

在控制节点,新建downtime.sh脚本:

1
2
3
4
5
#!/bin/bash
transmitted=`grep 'packets transmitted' ping.log | tail -n 1 | awk '{print $1}'`
received=`grep 'packets transmitted' ping.log | tail -n 1 | awk '{print $4}'`
lost=`expr $transmitted - $received`
echo "downtime is $lost ms"

迁移数据量

在两个计算节点,安装iptraf-ng。
apt install iptraf-ng

xshell

使用xshell,打开两个controller节点的shell,一个登录实例B后用来ping实例A;一个用来执行迁移命令,迁移之后执行mtime.sh脚本。打开一个compute1节点的shell,用来运行iptraf-ng。打开一个compute2节点的shell,用来运行iptraf-ng。

实验流程

假设当前只启动了ubuntu0实例,nova show ubuntu0位于compute1节点。

1、在两个compute节点启动iptraf-ng,配置参考《虚拟机在线迁移的性能统计》

2、在实例中启动压力测试软件,或者在两个compute节点中启动网络故障模拟软件。(flavor实验中不需要)

3、在实例B中ping实例ubuntu0
sudo ping ubuntu0_internal_ip -i 0.001 >> ping.log

4、在controller中执行迁移
nova live-migration ubuntu0 compute2

5、观察compute节点的iptraf-ng,等到流量不再增加。关闭压力测试软件或者网络故障模拟软件,然后在实例B中Ctrl+C结束ping命令。

6、在controller节点记录迁移列表
nova migration-list > list.log

7、controller节点执行mtime.sh得到迁移时间,在实例B中执行downtime.sh得到停机时间,在两个计算节点观察iptraf-ng得到迁移数据量。

以上流程,适用于接下来的所有实验。

flavor实验

按照实验流程,分别使用五个flavor,进行五次迁移实验,记录实验结果。

1
2
3
4
5
6
#Flavor    迁移时间s    停机时间ms    迁出数据量MB   迁入数据量MB
tiny 24 297 275 277
small 26 14 329 332
medium 27 69 373 375
large 30 50 846 852
xlarge 31 57 923 929

由实验结果可以看出,随着CPU和内存的增加,迁移时间也会随之增加。tiny模板的停机时间最大,其他模板的停机时间在10ms到70ms之间。源主机的迁出数据量和目标主机的迁入数据量也会随之增加,而且迁入数据量要比迁出数据量多2到6MB。

系统压力实验

CPU实验

接下来的实验,都使用small类型的flavor。
1、先给实例安装stress-ng
sudo apt install stress-ng

2、在实例中创建一个CPU进程,CPU占用率10%
stress-ng -c 1 -l 10

3、创建CPU进程,CPU占用率20%-100%,记录实验结果。

1
2
3
4
5
6
7
8
9
10
11
12
# CPU占用率%   迁移时间s    停机时间ms    迁出数据量MB   迁入数据量MB
Idle 26 14 329 332
10% 27 15 330 333
20% 26 18 331 333
30% 24 403 330 333
40% 25 3332 330 334
50% 25 3175 330 332
60% 24 505 327 329
70% 26 10372 328 331
80% 25 292 329 331
90% 26 124 330 333
100% 26 573 328 330

由实验结果可以看出,随着CPU占用率的提高,迁移时间没有太大变化。停机时间在CPU使用率大于30%之后,停机时间普遍大于100ms,偶尔会出现停机时间大于3s,没有明显的规律。迁移数据量并没有太大变化,迁入数据一直比迁出数据多2到4MB。

在迁移时,偶尔会出现OpenStack显示实例迁移成功,但是实例停机时间特别长(大于600s)的情况。本文中认为这种情况属于异常,会重做实验,去除这些异常值。

内存实验

1、在实例中创建一个200M的内存进程
stress-ng --vm 1 --vm-bytes 200M --vm-keep

2、创建内存进程,内存占用400M-1600M,记录实验结果。

1
2
3
4
5
6
7
8
9
10
# 内存占用MB   迁移时间s    停机时间ms    迁出数据量MB   迁入数据量MB
Idle 26 14 329 332
200 79 3090 6543 6585
400 199 144 21344 21481
600 308 440 33368 33585
800 422 560 47712 48019
1000 541 23560 61417 61814
1200 649 250080 74617 75103
1400 925 27230 107004 107702
1600 1049 3140 121600 122390

从实验结果中可以看出,随着内存使用量的增加,总迁移时间急剧增加。停机时间一般大于100ms,有时甚至超过20s。迁移数据量也急剧增加,数量级变为GB。当内存占用1600MB时,总迁移时间超过1000s,迁移数据大于120GB,传输到目标机器的数据与从源机器传输的数据之间的差异为700MB。

磁盘实验

1、在实例中创建2个写入进程,每个进程写入大小为1M的文件。
stress-ng -d 2 --hdd-bytes 1M

2、在实例中创建4-20个写入进程,记录实验结果。

1
2
3
4
5
6
7
8
9
10
11
12
# 写入进程数   迁移时间s    停机时间ms    迁出数据量MB   迁入数据量MB
0 26 14 329 332
2 42 510 2178 2192
4 50 100 2954 2974
6 127 3350 12456 12537
8 137 490 13519 13608
10 172 4570 18179 18296
12 182 6340 18948 19072
14 172 6860 18034 18150
16 189 410 19569 19696
18 179 600 18790 18910
20 246 3160 26687 26859

从实验结果中可以看出,随着写入进程的增加,迁移时间也在不断增加。停机时间普遍大于400ms,频繁出现大于3s停机时间。迁移数据量呈现阶梯式变化,数量级变成GB。当写入进程数为20时,迁移时间约为250s,迁移数据约为27GB。

网络故障实验

网络故障实验之前,需要重启测试实例,否则测出的迁移数据量会偏大一个数量级。

网络延迟

1、在compute节点(迁出节点)添加网络延迟20ms
sudo tc qdisc add dev eth1 root netem delay 20ms
注:原本的延迟在0.2ms上下。

2、将网络延迟修改为40ms-200ms,记录实验结果。
sudo tc qdisc replace dev eth1 root netem delay 40ms

1
2
3
4
5
6
7
8
9
10
11
12
# 网络延迟ms   迁移时间s    停机时间ms    迁出数据量MB   迁入数据量MB
0 26 14 329 332
20 27 6720 354 356
40 29 320 354 356
60 32 3200 355 357
80 39 160 356 358
100 39 3370 360 362
120 43 320 357 358
140 45 310 358 360
160 51 580 356 357
180 51 5480 356 357
200 59 620 380 382

由实验结果可以看出,随着网络延迟时间的增加,迁移时间也会随之增加。停机时间普遍大于300ms,经常出现3s到7s的停机时间。迁出数据量和迁入数据量没有明显的变化,差值也保持在稳定的范围。

此外,在网络延迟实验中,实例死机(停机时间大于600s)的频率要高于CPU、内存和磁盘实验。

3、取消模拟:
sudo tc qdisc del dev eth1 root

丢包

1、两个计算节点,都模拟丢包率1%
sudo tc qdisc add dev eth1 root netem loss 1%

2、将模拟丢包率修改为1%-10%,记录实验结果。
sudo tc qdisc change dev eth1 root netem loss 2%

1
2
3
4
5
6
7
8
9
10
11
12
# 丢包率   迁移时间s    停机时间ms    迁出数据量MB   迁入数据量MB
0% 26 14 329 332
1% 24 1460 354 356
2% 26 4190 355 356
3% 30 3990 358 359
4% 38 2640 357 357
5% 43 7610 359 360
6% 67 5960 361 361
7% 131 43890 363 363
8% 170 20850 368 368
9% 283 11430 371 371
10% 392 67520 365 365

从实验结果中可以看出,随着丢包率的增大,迁移时间也会明显增加。丢包率大于7%之后,停机时间普遍大于10s,甚至出现了68s的停机时间。迁移数据量变化不大,迁入迁出数据量的差值稳定在1MB以内。

3、取消模拟:
sudo tc qdisc del dev eth1 root

包重复

1、两个计算节点,都模拟包重复率10%
sudo tc qdisc add dev eth1 root netem duplicate 10%
随机产生 10% 重复的包。

2、将模拟包重复率修改为20%-100%,记录实验结果
sudo tc qdisc change dev eth1 root netem duplicate 20%

1
2
3
4
5
6
7
8
9
10
11
12
# 包重复率   迁移时间s    停机时间ms    迁出数据量MB   迁入数据量MB
0% 26 14 329 332
10% 32 180 652 656
20% 28 180 712 717
30% 27 120 769 774
40% 28 300 840 845
50% 29 3060 887 893
60% 29 140 959 965
70% 28 540 1016 1023
80% 32 440 1073 1080
90% 35 3490 1135 1142
100% 32 90 1196 1204

从实验结果可以看出,随着包重复率的增加,总的迁移时间变化不大。停机时间普遍大于100ms,偶尔出现大于3s的情况,没有明显的变化趋势。迁移数据量随着包重复率的增加而增大,迁入数据量和迁出数据量的差值在4M到8M。

3、取消模拟:
sudo tc qdisc del dev eth1 root

包损坏

1、两个计算节点,都模拟包损坏率1%
sudo tc qdisc add dev eth1 root netem corrupt 1%
随机产生 1% 损坏的报文(在报文的随机位置造成一个比特的错误)。

在ping的时候会报错:Warning: time of day goes back , taking countermeasures,不过没关系,不影响我们的停机时间统计结果。

2、将模拟包损坏率修改为2%-5%,记录实验结果。
sudo tc qdisc change dev eth1 root netem corrupt 2%

1
2
3
4
5
6
7
8
# 包损坏率   迁移时间s    停机时间ms    迁出数据量MB   迁入数据量MB
0% 26 14 329 332
1% 26 660 333 334
2% 27 1120 334 335
3% 35 4160 337 337
4% 149 2760 342 342
5% 254 15040 352 353
6% 1228 117760 356 356

从实验数据中可以看出,包损坏率大于3%之后,迁移时间会急剧增加。停机时间普遍大于1s,总体呈上升趋势。停机时间在包损坏率等于5%和6%时发生突变。迁移数据量没有明显变化。当包损坏率等于6%时,迁移时间超过20min,停机时间接近120s。

而且,在本文中的实验环境中,包损坏率大于等于7%时,迁移会失败。迁移进行了1600s还没有完成,OpenStack会自动撤销迁移。还有一个有趣的现象是,正常迁移中只要使用49152端口就可以了,在出现包损坏的情况下,会使用49153-49216端口来辅助传输数据。

3、取消模拟:
sudo tc qdisc del dev eth1 root

PS:如果迁移无法成功,那么就取消包损坏的模拟,或者撤销迁移。

1
2
3
nova migration-list
nova server-migration-show 29a58cf7-646a-43f2-b1d6-89ec421fc9d6 152
nova live-migration-abort 29a58cf7-646a-43f2-b1d6-89ec421fc9d6 152

后记

从以上结果可以看出,在OpenStack中选择VM进行迁移的时候,为了提高迁移的效率,有以下几个结论:
(1)选择更小的flavor,能够减少迁移时间和迁移数据量。
(2)基本不用考虑CPU使用率,因为它对迁移影响很小。
(3)选择内存占用小的VM,能够减少迁移时间、停机时间和迁移数据量。
(4)选择磁盘写入进程较少的VM,能够减少迁移时间、停机时间和迁移数据量。
(5)包延迟会稍微增加迁移时间,对停机时间和迁移数据量的影响很小。
(6)丢包会急剧增加迁移时间,对停机时间和迁移数据量的影响很小。
(7)包重复会增加一些迁移数据量,但是对迁移时间和迁移停机时间的影响很小。
(8)包损坏率小于等于3%时,对迁移影响较少,可以忽略。包损坏率大于4%之后,迁移时间和停机时间会急剧上升。包损坏率大于7%时,已经无法迁移成功。

至此,实验完成,数据有了,就差论文了!加油加油!