热迁移（Live Migration）在云计算中是如同黑魔法一般的存在，它可以使用户在无感知的情况下将虚拟机从一台物理服务器迁移到另一台物理服务器上，且整个迁移过程中应用程序几乎不会发生中断，是保障SLA的利器。本期智汇华云将从热迁移的原理出发，为大家揭晓ArStack团队为持续优化热迁移能力进行的探索与实践。
热迁移的原理
当一个运行中的虚拟机在不同计算节点中进行移动的时候，对于用户的应用程序来说主要涉及到CPU和内存的运行状态，CPU状态的拷贝几乎是可以瞬时完成的，而由于内存的特性，其在迁移过程中已经拷贝的内存也会面临被重写的情况，所以在整个虚拟机迁移过程中，内存迁移需要消耗较长的时间。
在这篇文章中，我们主要介绍一种最常见的内存拷贝策略：预拷贝策略（Pre-Copy）。
简单来说，预拷贝策略主要分为三个阶段：
·Init Copy：将所有内存页标记为Dirty Page（脏内存），并将其拷贝到目标主机上，此时虚拟机管理器继续监视虚拟机的内存变化情况
·Iterative Pre-Copy：重新计算新产生的脏内存，并进行迭代，将被修改的内存页拷贝到目标主机上，直到满足条件退出
·Stop-and-Copy：停止运行源主机的 GuestOS，将剩余的脏内存以及设备状态信息迁移到目标主机上，并启动虚拟机
ArStack的探索与实践
根据第一性原理（First Principle），我们不难发现在虚拟机进行热迁移的过程中， Iterative Pre-Copy 是最重要的阶段，所以 ArStack 几乎所有的优化工作都是围绕这一阶段展开的。
超时参数的调整
在过去的一些反馈中，大规格的虚拟机（如128G内存）在承受中高强度的负载时往往会在迁移中产生瓶颈，经过研究相关案例后我们发现该问题主要是由于迁移时间超时导致的，由于网络带宽、内存量等因素的限制，这类虚机往往需要更长的迁移时间，所以针对这类情况我们按需调整了迁移超时的参数，以提升该场景下的迁移成功率。
最大停机时间的调整
还记得上面我们讲到的在Iterative Pre-Copy阶段中“直到满足条件退出”么，最大停机时间（Max Downtime）就是Nova选择退出的条件之一，在每次迭代中Libvirt都会重新计算虚拟机新产生的脏内存以及每次迭代需要耗费的时间，再根据当前带宽和脏页数计算出传输剩余数据的时间，即Downtime。
如果 Downtime 在管理员配置的 Live Migration Max Downtime 范围之内，则退出，进入到 Stop-and-Copy 阶段。
在与业务团队沟通后，我们进行了大量的实验与验证，最终提供了一套更为合理的参数配置，该参数的调整明显提升了热迁移的成功率。
VM级的内存收敛
需要注意的是，最大停机时间并不是如同杀手锏的存在，如果虚拟机持续处于高负载状态，即不断产生大量的脏内存，Downtime有可能一直无法进入我们预设的范围，此时的Iterative Pre-Copy就如同《开端》里的李诗情一样，不断在进行循环。
现在，内存自动收敛（Auto Converge）就要作为“银色子弹”登场了。
开启 Auto Converge 后，当进行热迁移时，Qemu 会降低虚拟机的运行速度，从而减少内存写入的操作，这样使得 Dirty Page 生成的速度降低，同时 Auto Converage 有一套自身的算法，会不断增加对 vCPU 的限制（上限为99%），直到迁移成功。
OpenStack自身提供了平台级的内存收敛能力，ArStack修改了社区代码的相关逻辑，为用户提供了颗粒度为虚拟机级的内存收敛能力，用户可以针对单台虚机进行相应的设置，从而获得更加灵活、高效的迁移体验。
VM级的Qos设置
对于一些业务敏感型用户来说，他们希望在获得高效迁移能力的同时又能尽可能降低因为热迁移对业务系统产生的影响。
能够限制热迁移的迁移速度便显得至关重要，Live Migration Bandwidth是迁移期间要使用的最大带宽，默认值为0，意味着不限制迁移带宽。
ArStack同样为用户提供了颗粒度为虚拟机级的Qos配置，以便于用户能够自主评估并控制迁移的速度。
多线程迁移
在获得了国产化团队的支持后，ArStack整合并提供了全局范围内的多线程迁移能力，在默认状态下，ArStack会为所有参与迁移任务的VM开启多线程迁移的选项，当Libvirt接收到来自ArStack传递的信号后，会通过多个网络连接将内存页发送至目标主机，以提升迁移性能。
总结
作为虚拟机生命周期管理的重要组成部分，ArStack经过数个版本的迭代，持续对热迁移进行了大量的优化工作，以提升用户的基础体验。
不仅如此，ArStack还完善丰富了多种复杂场景下的热迁移能力，相信在不久的将来会与用户见面。
责任编辑：焦旭
