Live Migrate 操做 - 天天5分钟玩转 OpenStack（42）

Migrate 操做会先将 instance 停掉，也就是所谓的“冷迁移”。而 Live Migrate 是“热迁移”，也叫“在线迁移”，instance不会停机。

Live Migrate 分两种：

1. 源和目标节点没有共享存储，instance 在迁移的时候须要将其镜像文件从源节点传到目标节点，这叫作 Block Migration（块迁移）

2. 源和目标节点共享存储，instance 的镜像文件不须要迁移，只须要将 instance 的状态迁移到目标节点。

源和目标节点须要知足一些条件才能支持 Live Migration：

1. 源和目标节点的 CPU 类型要一致。

2. 源和目标节点的 Libvirt 版本要一致。

3. 源和目标节点能相互识别对方的主机名称，好比能够在 /etc/hosts 中加入对方的条目。
   

4. 在源和目标节点的 /etc/nova/nova.conf 中指明在线迁移时使用 TCP 协议。
   

5. Instance 使用 config driver 保存其 metadata。在 Block Migration 过程当中，该 config driver 也须要迁移到目标节点。因为目前 libvirt 只支持迁移 vfat 类型的 config driver，因此必须在 /etc/nova/nova.conf 中明确指明 launch instance 时建立 vfat 类型的 config driver。
   

6. 源和目标节点的 Libvirt TCP 远程监听服务得打开，须要在下面两个配置文件中作一点配置。

/etc/default/libvirt-bin

start_libvirtd="yes" libvirtd_opts="-d -l"

/etc/libvirt/libvirtd.conf

listen_tls = 0 listen_tcp = 1 unix_sock_group = "libvirtd" unix_sock_ro_perms = "0777" unix_sock_rw_perms = "0770" auth_unix_ro = "none" auth_unix_rw = "none" auth_tcp = "none"

而后重启 Libvirtd 服务
service libvirt-bin restart

非共享存储 Block Migration

咱们先讨论非共享存储的 Block Migration。流程图以下：

1. 向 nova-api 发送请求

2. nova-api 发送消息

3. nova-compute 执行操做

下面咱们详细讨论每个步骤。

向nova-api发送请求

客户（能够是 OpenStack 最终用户，也能够是其余程序）向API（nova-api）发送请求：“帮我将这个 Instance 从节点 A Live Migrate 到节点 B”

这里源节点是 devstack-compute1，目标节点是 devstack-controller，由于是非共享存储，记得将“Block Migration”勾选上。

这里还有一个“Disk Over Commit”选项，若是勾选了此选项，nova 在检查目标节点的磁盘空间是否足够时，是以 instance 磁盘镜像文件定义的最大容量为准；不然，以磁盘镜像文件当前的实际大小为准。

查看日志 /opt/stack/logs/n-api.log

nova-api 发送消息

nova-api 向 Messaging（RabbitMQ）发送了一条消息：“Live Migrate 这个 Instance” 源代码在 /opt/stack/nova/nova/compute/api.py，方法是 live_migrate。

nova-compute 执行操做

源和目标节点执行 Live Migrate 的操做过程以下：

1. 目标节点执行迁移前的准备工做，首先将 instance 的数据迁移过来，主要包括镜像文件、虚拟网络等资源，日志在 devstack-controller:/opt/stack/logs/n-cpu.log
   
   

2. 源节点启动迁移操做，暂停 instance
   

3. 在目标节点上 Resume instance
   

4. 在源节点上执行迁移的后处理工做，删除 instance
   
   

5. 在目标节点上执行迁移的后处理工做，建立 XML，在 Hypervisor 中定义 instance，使之下次可以正常启动。
   

Instance 在 Live Migrate 的整个过程当中不会停机，咱们经过 Ping 操做来观察

可见在迁移过程当中，Ping 进程没有中断，只是有一个 ping 包的延迟增长了。

下面咱们再来看源和目标节点共享存储下的 Live Migrate。

共享存储 Live Migration

有多种方式能够实现共享存储，好比能够将 instance 的镜像文件放在 NFS 服务器上，或者使用 NAS 服务器，或者分布式文件系统。

做为学习和实验，这里咱们采用 NFS 方案。其余共享存储方案对于 Live Migration 本质上是同样的，只是在性能和高可用性上更好。

搭建 NFS 环境

将 devstack-controller 做为 NFS 服务器，共享其目录 /opt/stack/data/nova/instances。 devstack-compute1 做为 NFS 客户端将此目录 mount 到本机，以下所示：

这样，OpenStack 的 instance 在 devstack-controller 和 devstack-compute1 上就实现共享存储了。

共享存储的迁移过程与 Block Migrate 基本上同样，只是几个环节有点区别：

1. 向 nova-api 提交请求的时候，不能勾选“Block Migrate”
   

2. 由于源和目标节点都能直接访问 instance 的镜像，因此目标节点在准备阶段不须要传输镜像文件，源节点在迁移后处理阶段也无需删除 instance 的目录。

3. 只有 instance 的状态须要从源节点传输到的目标节点，整个迁移速递比 Block Migration 快不少。

具体的日志分析留个你们练习。

以上是 Live Migrate 操做的详细分析，下一节咱们讨论 Evacuate。