OpenStack虚拟机冷迁移与热迁移

 一、虚拟机迁移分析

openstack虚拟机迁移分为冷迁移和热迁移两种方式。

1.1冷迁移

冷迁移(cold migration),也叫静态迁移。关闭电源的虚拟机进行迁移。通过冷迁移,可以选择将关联的磁盘从一个数据存储移动到另一个数据存储。

好处:虚拟机不需要位于共享存储器上,数据丢失率小。

缺点:需要关闭电源,业务中断。

1.2热迁移:

热迁移(Live Migration),又叫动态迁移、实时迁移,即虚拟机保存/恢复,通常是将整个虚拟机的运行状态完整保存下来,同时可以快速的恢复到原有硬件平台甚至是不同硬件平台上。恢复以后,虚拟机仍旧平滑运行,用户不会察觉到任何差异。

好处:软件和硬件系统的维护升级,不会影响用户的关键服务,提高了服务的高可用性和 用户的满意度。

缺点:过程不可中断,操作复杂。

1.3虚拟机迁移的场景:

场景 1:物理机器硬件系统的维护,故障修复和升级(upgrade),但运行在这台物理机器上的虚拟机不能关机,因为用户重要的服务跑在上面。

场景 2:物理机器软件系统升级,打补丁(patch),为了不影响上面跑的虚拟机,在升级和打补丁之前,需要把虚拟机迁移到别的物理机器上。

场景 3:一个物理机器上的负载太重,需要减少一些虚拟机来释放资源。

场景 4跨域环境下,有的域里有的物理机上的虚拟机太多,有的域里物理机上虚拟机太少,做一下资源平衡。

1.4虚拟机迁移中数据处理

虚拟机的迁移,就是数据的转移,如果计算节点之间没有共享存储,所以要转移的数据包括两部分:

1、静态数据:存储在本地的虚拟机的镜像文件,包括后端镜像(libvirt Base)和虚拟机单独的增量镜像文件(libvirt instance disks)

2、动态数据:内存里虚拟机的运行时数据,内存里的数据是动态变化的数据,虚拟机里运行的负载的大小直接影响迁移的时间长短。

1.5虚拟机迁移中存储

共享存储与非共享存储

虚拟机的数据存在共享磁盘上(Shared storage-based live migration),迁移只需要完成内存数据的迁移。

 

虚拟机的数据存在本地磁盘(block migration),需要对镜像文件和内存数据同时迁移。

 

注意:本文使用的系统是ubuntu18.04,OpenStack版本是Pike。其他系统略有出入

 

二、冷迁移

冷迁移实现方法有多种,例如有快照来迁移实例、实例文件迁移。以文件迁移为例,完成冷迁移。

2.1虚拟机文件冷迁移步骤:

1、关闭虚拟机

2、找到虚拟机位于/var/lib/nova/instances下文件

3、将虚拟机的文件全部copy到目标主机的相同位置下

4、修改用户组

5、更新数据库中host,node字段为目标主机的名字

6、重启目标主机的nova-compute服务

2.2操作记录

显示运行的虚机

 

关闭虚机

将文件copy到目标主机的对应位置下

 

修改权限

  

修改数据库中的字段

update instances set host='compute15', node='compute15' where uuid='3483d9f1-4015-48d9-9837-b67ca82dd54d';

 

查询虚机所在的主机

 启动虚机

 

三、热迁移

热迁移是在不停机的情况下完成迁移,步骤比起冷迁移要复杂。

3.1热迁移步骤:

1、迁移前的条件检查

2、迁移前的预处理

3、迁移过程

4、迁移后的处理

3.1.1迁移前的条件检查

动态迁移要成功执行,一些条件必须满足,所以在执行迁移前必须做一些条件检查。

1、权限检查,执行迁移的用户是否有足够的权限执行动态迁移。

2、参数检查,传递给 API 的参数是否足够和正确,如是否指定了 block-migrate 参数。

3、检查目标物理主机是否存在。

4、检查被迁移的虚拟机是否是 running 状态。

5、检查源和目的物理主机上的 nova-compute service 是否正常运行。

6、检查目的物理主机和源物理主机是否是同一台机器。

7、检查目的物理主机是否有足够的内存(memory)

8、检查目的和源物理主机器 hypervisor hypervisor 的版本是否相同。

3.1.2迁移前的预处理

在真正执行迁移前,做一些准备工作

1、在目的物理主机上获得和准备虚拟机挂载的块设备(volume)

2、在目的物理主机上设置虚拟机的网络(networks)

3、目的物理主机上设置虚拟机的防火墙(fireware)

3.1.3迁移过程

条件满足并且做完了预处理工作后,就可以执行动态迁移了。主要步骤如下:

1、调用 libvirt python 接口 migrateToURI,来把源主机迁移到目的主机。

2、以一定的时间间隔(0.5)循环调用 wait_for_live_migration 方法,来检测虚拟机迁移 的状态,一直到虚拟机成功迁移为止。

3.1.4迁移后的处理

当虚拟机迁移完成后,要做一些善后工作。

1、在源物理主机上 detach volume

2、在源物理主机上释放 security group ingress rule

3、在目的物理主机上更新数据库里虚拟机的状态。

4、在源物理主机上删除虚拟机。

上面四步正常完成后,虚拟机就成功的从源物理主机成功地迁移到了目的物理主机了。

3.2热迁移配置:

热迁移需要libvirt远程登录和传输,所以开启libvirtTCP连接方式

virsh -c qemu+tcp://172.171.8.14/system

例如:qemu+tcp://172.16.0.15/system,服务端只需要配置

修改/etc/libvirt/libvirtd.conf:

listen_tls = 0         

listen_tcp = 1           

tcp_port = "16509"      

listen_addr = "0.0.0.0"

auth_tcp = "none"

 修改libvirtd的配置文件/etc/default/libvirtd:

# Start libvirtd to handle qemu/kvm:

start_libvirtd="yes"

# options passed to libvirtd, add "-l" to listen on tcp

libvirtd_opts="-d -l --config /etc/libvirt/libvirtd.conf"

以上修改后,执行

service libvirt-bin restart

netstat -anpt | grep libvirt

可以看到libvirtd监听在TCP 16509端口。

配置nova.conf

计算节点的/etc/nova/nova.conf文件中添加如下的内容,使得compute服务支持热迁移。

live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

重启nova-compute

service nova-compute restart

修改用户组

查看目标主机的用户组信息

id nova

 修改所有计算节点为相同的用户组id

usermod -u *** nova

usermod -u *** libvirt-qemu

groupmod -g *** nova

groupmod -g *** kvm

openstack迁移命令

查看所有实例

nova list

查看需要迁移虚拟机实例

nova show [实例id]

查看可用的计算节点

nova-manage service list

查看目标节点资源

nova-manage service describe_resource computer1

开始迁移,正常无任何回显

nova live-migration  [实例id]  [计算节点] 

3.3操作记录

查看虚拟机

 

查看虚拟机所在计算节点

 

迁移

 

查看迁移后的虚拟机所在节点

 

在迁移过程中,dashboard中会出现正在迁移的任务

3.4 大型镜像测试

OpenLab平台镜像迁移

创建虚拟机,镜像是ubuntu1.8G

 

迁移之前ubuntu所在的主机为compute14

 

迁移中 

迁移之后ubuntu所在的主机为compute15

 

运行测试

创建虚拟机ubuntu_two,所在主机为compute14

迁移之前的界面

迁移过程

 

迁移之后的虚拟机所在的主机为compute15

 

迁移过程很快,2min左右,迁移之后界面仍然是之前的界面

 

 

posted @ 2018-09-04 19:58  金色旭光  阅读(25455)  评论(5编辑  收藏  举报