虚拟机在线迁移实验

文章目录
  1. 1. 前言
  2. 2. 实例准备
  3. 3. 正常虚拟机迁移
  4. 4. 取消迁移
  5. 5. CPU故障
  6. 6. 内存故障
  7. 7. IO故障
  8. 8. 磁盘故障
  9. 9. 网络延迟
  10. 10. 丢包
  11. 11. 包重复
  12. 12. 包损坏
  13. 13. 后记

前言

《虚拟机在线迁移的性能统计》解决了性能统计的问题,《虚拟机在线迁移过程中的故障注入》解决了环境模拟的问题。接下来我们进行一些虚拟机迁移实验,收集不同环境下迁移过程中产生的性能统计数据。

共享存储和非共享存储的虚拟机迁移,性能差别很大。本次实验,在共享存储的条件下进行。对于非共享存储的虚拟机迁移实验,放在其他文章中记录。

实例准备

《OpenStack中虚拟机的在线迁移》《OpenStack中共享存储的虚拟机在线迁移》两篇文章中,使用cirros作为迁移对象;本次实验中,使用ubuntu16作为迁移对象,因为这样可以更方便地注入故障,实例创建参考《OpenStack添加镜像》《Ubuntu16手动安装OpenStack——创建实例》

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

2、使用ubuntu16的镜像模板创建实例ubuntu0,实例类型选择m1.small,配置为1核2G内存20G存储。

3、创建成功后,分配浮动IP。本次分配的浮动IP为10.0.2.154。

4、登录ubuntu0实例,安装stress-ng,方便接下来的实验。

正常虚拟机迁移

1、controller节点ping实例并记录
sudo ping 10.0.2.154 -i 0.01 >> ping.log

2、在compute和compute2节点,都启动iptraf,监听49152 to 49261。

3、在控制节点执行迁移命令
nova live-migration ubuntu0 compute2

4、查看是否迁移完成
nova show ubuntu0

5、迁移完成后进行统计。
(1)在compute节点执行time.sh,得到总的迁移时间,22s。
(2)在controller执行downtime.sh,计算downtime,6.28s。
(3)根据iptraf的监听结果,得到迁出和迁入的数据量,283M,248M。

downtime不合理!为什么这么久?理论上是毫秒级的哇!参考《详解openstack下热迁移机制》,发现OpenStack可以进行迁移的参数设置,downtime可以进行调节。
查看迁移日志:
grep downtime /var/lib/docker/volumes/kolla_logs/_data/nova/nova-compute.log
发现日志中显示的downtime都是固定的50ms,每次迁移只有一次停机。感觉挺复杂的样子,先不管它,按照默认设置来实验吧。

取消迁移

如果虚拟机迁移失败,可以取消迁移。

1、查看迁移任务
nova server-migration-list ubuntu0
该命令查看到迁移任务的ID为12。

2、查看迁移过程
nova server-migration-show ubuntu0 12

3、取消迁移
nova live-migration-abort ubuntu0 12

CPU故障

1、在ubuntu0实例中创建一个CPU进程,CPU占用率10%
stress-ng -c 1 -l 10
使用top可以看到,CPU占用率不稳定,stress-ng进程偶尔跳到最高,占用率10%到90%不等。

2、实例迁移,得到总的迁移时间,34s。

3、设置CPU占用率分别为20%、30%到100%,统计结果如下:

CPU占用率 迁移时间 停机时间 迁出数据量 迁入数据量
0% 18s 6.28s 283M 248M
10% 20s 6.53s 353M 341M
20% 19s 4.52s 323M 300M
30% 20s 4.58s 354M 338M
40% 21s 4.62s 336M 347M
50% 20s 5.41s 355M 323M
60% 19s 4.54s 303M 309M
70% 21s 5.24s 356M 355M
80% 19s 4.41s 351M 338M
90% 17s 7.31s 328M 362M
99% 19s 5.77s 351M 348M

内存故障

1、在实例中创建一个100M的内存进程
stress-ng --vm 1 --vm-bytes 100M --vm-keep
使用free -h,可以看到内存被使用掉了100M。

2、虚拟机迁移,得到总的迁移时间,22s。

3、设置内存进程分别占用300M、600M到1.5G,统计结果如下:

内存占用 迁移时间 停机时间 迁出数据量 迁入数据量
100M 22s 7.63s 501M 653M
300M 29s 7.88s 1238M 1159M
600M 26s 7.72s 1341M 1279M
900M 78s 8.31s 5572M 6155M
1200M 92s 8.14s 8208M 8070M
1500M 102s 8.47s 8396M 9088M

IO故障

1、在实例中创建一个IO进程
stress-ng --io 1
使用iostat -d -k 2查看IO状态,发现tps稳定在200以上,而磁盘读写都为0。使用top命令可以看到,CPU占用率很高,在90%上下。

2、在实例中创建1-10个IO进程,统计结果如下:

IO进程数 迁移时间 停机时间 迁出数据量 迁入数据量
1 37s 7.59s 2067M 1954M
2 40s 6.83s 2032M 2007M
3 36s 7.04s 2071M 1788M
4 36s 8.08s 1846M 1969M
5 36s 6.02s 2074M 2012M
6 35s 7.44s 1805M 2032M
7 36s 5.64s 2066M 2010M
8 36s 8.60s 1972M 1987M
9 34s 10.95s 2064M 1880M
10 36s 7.02s 1865M 1981M

磁盘故障

1、在虚拟机中创建一个写入进程
stress-ng -d 1
使用iostat -d -k 2查看IO状态,发现tps在30上下,kB_wrtn/s在30000上下。使用top命令可以看到,CPU占用率在25%到99%浮动。

2、在实例中创建1-10个写入进程,统计结果如下:

写入进程数 迁移时间 停机时间 迁出数据量 迁入数据量
1 35s 4.83s 2059M 2023M
2 37s 8.70s 1874M 1957M
3 34s 8.92s 2055M 1980M
4 36s 4.97s 2024M 1959M
5 36s 5.50s 2055M 1960M
6 35s 4.64s 2025M 1957M
7 34s 6.02s 2055M 2041M
8 43s 9.11s 2009M 1978M
9 35s 6.60s 2069M 1997M
10 34s 8.89s 1931M 1942M

网络延迟

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

2、将网络延迟修改为20ms-100ms
tc qdisc replace dev eth0 root netem delay 20ms

统计结果如下:

延迟时间 迁移时间 停机时间 迁出数据量 迁入数据量
10ms 28s 10.43s 325M 307M
20ms 36s 8.80s 305M 287M
30ms 38s 5.73s 344M 305M
40ms 43s 11.28s 305M 290M
50ms 44s 6.81s 240M 292M
60ms 47s 7.09s 256M 295M
70ms 52s 14.48s 303M 292M
80ms 50s 12.17s 242M 297M
90ms 51s 11.37s 249M 297M
100ms 63s 18.22s 298M 344M

在延迟时间大于100ms后,迁移显示成功,实例状态active,但是无法ping通实例。

取消模拟:
tc qdisc del dev eth0 root

丢包

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

2、将模拟丢包率修改为2%-10%
tc qdisc change dev eth0 root netem loss 2%

统计结果如下:

丢包率 迁移时间 停机时间 迁出数据量 迁入数据量
0.5% 20s 8.55s 295M 330M
1% 31s 11.24s 301M 249M
1.5% 29s 7.44s 335M 313M
2% 28s 11.62s 261M 299M
2.5% 40s 10.34s 300M 325M
3% 43s 15.19s 306M 268M

在丢包率大于3%后,迁移显示成功,实例状态active,但是无法ping通实例。

取消模拟:
tc qdisc del dev eth0 root

包重复

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

2、将模拟包重复率修改为2%-10%-100%
tc qdisc change dev eth0 root netem duplicate 2%

统计结果如下:

包重复率 迁移时间 停机时间 迁出数据量 迁入数据量
1% 18s 4.82s 288M 283M
2% 21s 4.06s 308M 288M
3% 18s 8.02s 249M 309M
4% 21s 6.37s 316M 300M
5% 19s 4.70s 314M 307M
6% 18s 4.18s 285M 316M
7% 21s 3.81s 324M 315M
8% 18s 7.60s 305M 234M
9% 21s 6.87s 328M 316M
10% 18s 7.71s 310M 317M
20% 21s 11.24s 360M 347M
30% 19s 9.90s 381M 388M
40% 22s 6.67s 429M 376M
50% 18s 4.43s 445M 434M
60% 24s 8.04s 499M 438M
70% 19s 11.30s 488M 518M
80% 25s 5.61s 581M 485M
90% 29s 5.08s 745M 646M
100% 21s 7.89s 706M 727M

取消模拟:
tc qdisc del dev eth0 root

包损坏

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

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

2、将模拟丢包率修改为2%-10%
tc qdisc change dev eth0 root netem corrupt 2%

包损坏率 迁移时间 停机时间 迁出数据量 迁入数据量
0.5% 20s 4.43s 359M 369M
1% 24s 5.90s 371M 351M
1.5% 30s 12.13s 374M 357M
2% 32s 9.09s 331M 362M
2.5% 42s 7.49s 345M 337M
3% 48s 13.46s 378M 374M

迁移成功率随着包损坏率的增加而降低,包损坏率大于3%之后,基本不会成功。会停留在迁移状态,每秒几K传输。

取消模拟:
tc qdisc del dev eth0 root

后记

至此,完成了系统故障对于OpenStack虚拟机在线迁移过程中的性能影响的实验。实验数据和预期差别很大,比如停机时间量级不合理,比如停机时间基本上不受系统故障影响,比如迁移成功后却出现无法ping通的现象等等。

后续任务有两个,一是需要进行共享存储的虚拟机在线迁移实验,用于对比。二是尝试进行调参,把停机时间调整到毫秒级。

再进一步的话,可以研究下虚拟机迁移成功后无法ping通的原因,还可以研究下同样故障下虚拟机迁移时而成功时而失败的原因。