酷应用

UCloud虚拟化在线迁移优化实践系列（二）之普通应用场景

百家作者：Ucloud 2017-07-04 09:54:19

在系列（一）我们分析了基于KVM的虚拟化迁移技术原理，通过这种虚拟化迁移技术能够提供很好的在线迁移解决方案。但考虑到云平台环境的复杂性以及用户需求的多样性，在迁移过程中还需要解决宿主机选择、磁盘镜像处理、网络切换设置、内存磁盘压力处理等，因此UCloud云平台需要对在线迁移过程进行多方面优化。本篇将分成两部分具体分析UCloud在不同应用场景下对KVM虚拟化迁移技术各个阶段所做的优化，先介绍普通应用场景的迁移优化。

准备阶段

在迁移准备阶段，需要选择相同业务类型的宿主机，以便创建相同配置的虚拟机。该机型除了具有足够空闲内存和磁盘物理机外，还需要考虑目标物理机的配置是否合适，特别是需要考虑CPU型号与内核版本号。

另外，还需考虑到迁移过程网络带宽问题，如果带宽被其他任务占用，就会使得迁移速度下降，甚至影响最终迁移的成功率。为此，除非物理机之间的网络带宽足够大，在UCloud平台原则上并不允许相同两台物理机之间进行多个并行的迁移任务，从而尽量确保在线迁移的成功率。

迁移阶段

在线迁移过程中需要迁移虚拟机的所有磁盘和内存数据，而且虚拟机在迁移过程中并不停机，这就要迁移更多增量数据。如果能够减少数据的迁移量，就可以减少迁移时间，进而更快实现云平台资源动态调整和故障处理。

零数据优化
UCloud的虚拟机使用本地存储（UDisk除外），磁盘在物理机上是以文件方式存在，这个文件是sparse文件。假设虚拟机的磁盘是100G，但实际使用了10G，那么这个磁盘文件在物理机上只占用了10G空间（如图 2 1所示）。但原生的Qemu在迁移磁盘时并没有保持sparse特性，所以这个100G的磁盘迁移到目标物理机上后就实际占用了100G空间。该情况对物理机磁盘空间来说非常浪费，而且还严重影响迁移的完成时间。
（图2-1 磁盘文件零块数据迁移前后示意图）
（图2-2 磁盘文件零块数据迁移优化示意图）
如图2-2所示，UCloud优化方案是在源端读到全0的“块”，不发送到目标端，这样目标端就是跳着块来写一个文件，也保持了磁盘文件的sparse特性。同时，考虑到线上通常存在多种Qemu版本，还要考虑原生Qemu和打了patch的Qemu之间迁移机器时如何保持sparse。
为此，可以通过在Qemu中接收磁盘数据过程判断一个“块”是否全部为0，如果是，不实际写磁盘即可解决，所有零块数据都被跳过，不进行传输。使用上述方法就可以忽略磁盘迁移过程中的零数据，大大减少传输的数据量。最终，通过Qemu的patch，还可以明显减少在线迁移的数据传输量和镜像文件的空间占用量。
UDisk网络盘优化
由于UDisk是网络块存储，在迁移一台带有Udisk的机器时，并没有必要迁移UDisk盘，因为这个盘可以通过网络挂到目标。为此，UCloud在迁移时过滤掉虚拟机的UDisk盘，同时对UDisk产品做了改造，支持多点挂载，这样就解决了问题，提高了迁移效率。
在迁移前，目标端DestHost会将UDisk进行挂载操作，在迁移过程中会跳过UDisk的传输。当迁移结束时，源端SourceHost会将UDisk进行卸载，这样既避免对UDisk数据进行迁移，还避免虚拟机在迁移过程中对UDisk数据的访问，实现迁移过程对用户完全透明。
迁移结束优化
目前，在线迁移默认情况下不能很好地处理内存写密集型的虚拟机。由于在线迁移过程中，用户虚拟机并不关机，这就使得迁移过程中用户会不停产生新的内存脏数据。这些新增脏数据需要通过多次迭代的增量数据迁移来传递到目标端DestHost上，并在预期新增脏数据传输时间少于最大停机时间时，进行最后一次停机增量数据传输，然后将虚拟机切换到目标端DestHost。
如果用户产生的内存脏数据过多，就会使迁移的增量数据传输时间一直大于最大停机时间，造成增量传输阶段不断进行循环迭代，导致整个迁移过程无法完成。
（图2-3 内存迁移的auto-coverge优化）
由于用户产生内存脏数据速度与虚拟机vCPU被提交运行的时间有关，因此减少用户虚拟机vCPU执行时间可以阻止用户产生过多内存脏数据，从而让迁移数据传输得以在内存脏数据产生之前完成。
为此，UCloud对Qemu的auto-converge功能进行了优化。首先，UCloud提高了Qemu的throttling迁移速度，避免迁移速度限制迁移完成时间。其次，修改了auto-converge的触发条件，在增量迁移数据时，如果产生脏数据的量大于上次产生传输数据量的50%，并重复发生多次，则自动触发auto-converge功能。该功能默认情况下，将削减20%的虚拟机vCPU执行时间，也就降低用户虚机vCPU的执行速度，并减少新增脏数据。
在每次内存迭代开始时，会根据之前的削减情况，决定后续削减情况。如果新增脏数据仍然过多，它将重复削减10%的许可vCPU运行时间，直到削减CPU至99%，从而触发最后阶段的停机迁移，以完成迁移过程。
虽然，这种优化会使虚拟机的停机时间稍长，但根据长期实践结果，整个迁移的停机时间仍然非常小（小于100ms），因此这项优化对提高迁移成功率有重要意义。
压缩迁移优化
虽然Qemu的auto-converge功能可以在一定程度上解决用户内存负载对迁移的影响，提高迁移成功率，但如果用户产生的脏数据对vCPU的执行速度依赖不大，就会使迁移的增量数据传输时间一直大于最大停机时间，从而导致整个迁移过程无法完成。
考虑到内存负载高的用户，往往会反复修改某一内存页，而这些内存页面很容易被压缩。为此，可以考虑在迁移内存数据前，对内存进行压缩（如图 2 6所示），当前Qemu支持的XBZRLE压缩算法会将之前发送的内存页面维护在其内存缓存区内。
迁移内存页面时，会先查找该页面是否在其XBZRLE缓存内，如果在缓存内，则进行异或编码，只传输被压缩后的增量数据；如果没有，则直接传输内存页面。此过程可以极大减少发送内存页面数据量，并提高内存迁移速度。
（图2-4 内存迁移的xbzrle压缩迁移优化）
目前，UCloud的在线迁移已经使用XBZRLE进行高内存负载的迁移优化。实践表明，通过这种压缩方法可以提高高内存负载虚拟机的迁移成功率并缩短迁移时间，CPU使用率升高也在合理范围内，而且对普通内存负载虚拟机的迁移几乎没有额外的CPU使用率消耗。后续还会结合底层硬件加速卡，并适时开启多线程内存压缩迁移优化。

切换阶段

源端paused优化
迁移过程由Qemu具体执行，但对于整个迁移过程的控制则来自更上层的Libvirt。当Qemu在执行最后一步机器数据迁移切换时，两边的虚拟机都是处于paused状态。后续Libvirt将关闭源端SourceHost上的被迁移虚拟机，并拉起目标端DestHost上的对应虚拟机。
在线迁移的最大优点是不能因为迁移失败而导致虚拟机关机，不管成功或者失败，都要保障虚拟机实例的存活（源端或目标端）。为了加强迁移过程的保障，避免源端和目标端关机的情况出现，UCloud将Libvirt中迁移过程源端开关机的控制逻辑移到UCloud自身运维管理平台中，以便在出现迁移异常时，及时恢复源端SourceHost上的虚拟机。这个改造上线以来，多年未出现由于迁移导致虚拟机宕机的情况。
OVS切换优化
另外，迁移过程中还观察到，迁移即将完成时存在数秒网络中断的情况，这会导致用户业务出现短暂中断，使后台迁移过程对用户不透明。同时为减少对用户业务造成不利影响，一般需要事先和用户协调沟通迁移事项，也限制了在线迁移的应用。
为此，UCloud通过大量测试迁移实验发现，最后一轮的虚拟机迁移关机时间downtime基本在70ms左右，并不是长时间网络中断的主要原因，而且虚拟机内部压力和迁移速度的变化对迁移downtime并无明显影响。
考虑到UCloud的虚拟机网络采用openswitch来定义组建，经过大量实验确认迁移过程中的网络中断时间与openswtich设置目标端虚拟机新flow规则的延时时间存在正相关的关系，因此UCloud专门为在线迁移开发了网络下发虚拟机新flow的接口。
在虚拟机迁移到目标端DestHost后，及时为虚拟机下发新的flow规则。通过优化openswtich的网络配置机制，目前已经将迁移过程的网络中断时间控制在几百毫秒，基本做到用户无感知，并不会因为在线迁移造成用户业务中断。