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

流程图

OVS Normal plug, Linux bridge, MacVTap, SR-IOV

在这里插入图片描述

OVS-Hybrid plug

处理来自neutron-l2-agent的RPC消息的序列是在下面的UML序列图中描述:

在这里插入图片描述

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页