OpenStack之Live-migration

本文主要是介绍OpenStack之Live-migration，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

我们考虑具有一个port的VM由带有nova-compute1、neutron-l2-agent1 和 neutron-l3-agent1的主机host1，迁移到带有nova-compute2、neutron-l2-agent2 和 neutron-l3agent2的主机host2.

由于准备迁移的VM的宿主机为nova-compute1，nova通过RPC向nova-compute1发送live-migration的指令。

Nova Live Migration包含以下的阶段:

Pre-live-migration
Live-migration-operation
Post-live-migration

Pre-live-migration actions

Nova-compute1首先通过一个同步的RPC调用请求ova-compute2执行re-live-migration动作。Nova-compute2将使用Neutron REST API获取VM的端口列表。之后，调用它的VIF驱动通过函数plug_vifs()创建VM的port端口（VIF）。

如果使用的是Open vSwitch Hybrid plug，Neutron-l2-agent2将会检测到此新VIF，并且从Neutron服务器请求设备的详细信息，据此配置它。尽管如此，port的状态不会改变，因为此port还没有绑定到nova-compute2.

Nova-compute1调用setup_networks_on_hosts。此举将使用目标主机的信息更新Neutron端口的binding:profile。Neutron服务器发出的port更新RPC消息，将由neutron-l3-agent2接收到，其主动的设置DVR router。

如果pre-live-migration阶段失败，Nova将回滚，并从host2删除port。如果pre-live-migration阶段成功，Nova继续live-migration-operation阶段。

网络相关的潜在错误

在host2插入 VIFs 失败

由于Live Migration还没有开始，host1主机上的实例还处于ACTIVE状态.

Live-migration-operation

一旦nova-compute2完成了pre-live-migration阶段的动作，nova-compute1可开始live-migration。这将导致在节点2上创建VM及其相关的TAP接口。

对于Open vSwitch normal plug的情况，使用Linux网桥或者MacVTap，Neutron-l2-agent2将检测到此新TAP设备，并相应的配置它。尽管如此，port的状态不会改变，因为此port还没有绑定nova-compute2.

一旦实例在host2上变得活动，删除host1上的原始实例及其对应的TAP设备。假设OVS-hybrid plug没有使用，Neutron-l2-agent1将检测到删除操作，并告知Neutron服务器通过RPC消息设置port的状态到DOWN。

在live-migration-operation阶段如果失败没有回滚机制。另外，错误由post-live-migration阶段处理。

网络相关的潜在错误

在实例定义中指定的主机设备不会出现在目标主机中。在它真正开始前Migration将失败。对于MacVTap代理将发生此错误，参见bug： https://bugs.launchpad.net/bugs/1550400

Post-live-migration actions

一旦live-migration阶段成功，nova-compute1 和 nova-compute2 都执行post-live-migration阶段动作。感知到成功的Nova-compute1发送RPC广播到nova-compute2告知其开始执行post-live-migration动作。

在host2上，nova-compute2发送REST调用"update_port(binding=host2, profile={})"到Neutron服务器，告知其更新port的绑定信息。这将清除port的绑定信息并将port的状态变为DOWN。ML2插件将根据它的新主机重新绑定port。此update_port REST调用总是触发port-update RPC删除消息到每个neutron-l2-agent。既然现在neutron-l2-agent2拥有此端口，它将考虑此消息，并通过RPC消息向Neutron服务器请求此port的详细信息，重新同步端口。这将port的状态从DOWN变为BUILD，随后回到ACTIVE。

此更新还将从portbindng字典删除“migrating_to”值。并不是向{}表示的完全清除，而是仅删除“migrating_to”的键和值。

在host1上，ova-compute1调用其VIF驱动拔出VM的port。

假设，使用Open vSwitch Hybrid plug，Neutron-l2-agent1检测到此删除，并通过RPC消息告知Neutron服务器设置port的状态到DOWN。对于其它情况，此发生在实例及其TAP设备在host1上销毁的那一刻，正如live_mig_operation一节所描述。

如果Neutron没有处理REST调用"update_port(binding=host2)"，port的状态实际上转变为BUILD，之后到DOWN。否则，port绑定到host2，Neutron不会改变port的状态，因为它没有绑定到发送RPC消息的主机。

如果post-live-migration阶段发送错误没有回滚机制。发送错误后，实例设置为“ERROR”状态。

网络相关的潜在错误

host2的Portbinding失败

如果发生，port的vif_type设置为’binding_failed’。当Nova尝试在迁移目标上重新创建domain.xml时，它将失败于此无效的vif_type。实例设置到“ERROR”状态。

Post-Copy Migration

通常，Live Migration作为pre-copy迁移执行。实例在host1上是活动的，直到几乎所有的内存被拷贝到host2。在拷贝的内存达到一定阈值，在源主机上的实例暂停，拷贝剩余的内存，实例开始在目标主机运行。此方式的缺陷在于，当实例繁忙的写入内存时，迁移可能花费无尽的时间。

此问题由post-copy迁移解决。在一些时间点，host2上的实例设置为活动，虽然仍有大量的内存页仅驻留在host1。开始的阶段叫做post_copy阶段。如果实例试图访问还没有拷贝的内存页面，libvirt/qemu马上将此页移动到目标主机。新页面将只能写入源主机。使用此方式迁移操作花费有限的时间。

今天，从host1到host2的port重绑定发生在迁移完成之后的post_live_migration阶段。这对pre-copy没有影响，因为目标机上实例的激活与port绑定到目标机的时间差非常小。但这对post-copy迁移将带来问题。目标机上的实例很早就激活，但是portbinding仍然发生在迁移完成之后。在这段时间内，实例可能不能通过网络访问。这应解决参见bug：https://bugs.launchpad.net/nova/+bug/1605016