干货分享 | 虚拟化性能提升之本地热迁移

友情提示：全文1000多文字，预计阅读时间5分钟

前言

在当下万物互联的浪潮下，无论企业还是个人，数据上云已经进行的如火如荼。5G+移动云产品新功能也在不停地迭代发布上线，其中有些产品能力依赖底层虚拟化组件的新功能新特性，比如保证在不中断用户业务的情况下达到虚拟化组件在线升级的目的，为云上产品新功能成功上线提供助力。

面临的问题

目前主流的解决方案是使用虚拟化热迁移技术，但是云环境中虚拟机的热迁移存在迁移周期长，成功率低，运维工作量巨大的问题，因为目前虚拟机的热迁移技术（libvirt层）仅仅局限于异地迁移，即将虚拟机从一台物理服务器迁移到另一台远端的物理服务器，这样带来的问题就是：

虚拟机的所有数据要通过网络进行传输，给线上网络带宽带来很大压力
当网络带宽成为迁移的瓶颈时，高负载虚机无法完成传输导致迁移失败

针对以上问题，社区主要从减少数据的生成和压缩传输数据两个方向进行了优化，但是对于带宽受限，负载极高的虚机来说，效果基本看不见。就现有环境测试来看，脏页达到250M/s左右时，即便各种优化特性全开，也难逃迁移失败的命运。

因此，面对云上版本升级的迫切诉求：

突破带宽限制，无视虚机负载，尽量保证100%成功迁移
保证迁移成功的同时，大大缩短迁移时间，以减轻运维负担

考虑到版本升级的特殊性（不同于负载均衡必须跨节点），如果有一种方法可以在本地就能完成虚机的版本升级，那么文章开头提到的由于跨节点而带来的各种问题都可以完美解决。

我们的方案

通过调查发现libvirt社区曾经有开发者提议是否引入本地热迁移技术的支持，最终讨论的结果是本地迁移需要libvirtd同时纳管两个完全相同的虚拟机，会产生很多资源冲突和脑裂（brain split）的问题，因此拒绝实现该功能。

鉴于此，通过前期调研，在没有相关储备知识的情况下，梳理迁移过程的每一个细节，制定了详细的开发流程并严格执行，克服遇到的一个又一个技术问题，最终设计并实现了我们大云自己的本地热迁移技术，架构如下：

图（1）本地热迁移架构图

通过该技术，当某个物理节点需要实现虚拟机版本升级时，首先直接升级qemu版本，然后对存量的虚拟机在本节点进行迁移，完成后所有的虚拟机都进入高版本。这尤其对于bug修复，新功能上线来说非常有用，而且相对于热补丁技术的重启失效，这是一个持久化的解决方案，并且几乎没什么限制。

同时，本地热迁移还顺带解决了另一个问题：非共享存储的磁盘数据迁移。

在跨机迁移中，如果虚拟机的磁盘使用的是本地磁盘，那么就不止要迁移内存数据，磁盘也要一起迁。而当下虚拟机的磁盘动辄几百GB甚至上TB，真要迁，可能得耗时达数小时之久，费机器不说，还费运维人员。

有了本地热迁之后，这个问题也就不再是个问题了。

性能表现

本地迁移效果怎么呢？来看一组数据：

规格	负载	迁移时间	丢包（1s）
2vcpu 64G	1GB/s dirty page	< 1min	无

表（1）本地热迁移高负载虚机性能表现

同样的环境下，如果是跨机迁移，脏页1GB/s的负载是100%失败的。即便这个负载再降四分之三，可能半盒烟都抽完了还没迁过去，但如果用本地热迁，你拿根儿烟出来点个火就已经迁完了。这就是差距。

总结

本地迁移技术的优点：

在本地迁，不占用网络带宽，避免了网络波动挤压其他业务正常运行
迁移速度快，高负载的虚机也能实现秒级迁移，意味着几乎100%成功率
非共享存储的情况下，避免了磁盘数据的拷贝，节省大量时间

本地热迁移技术将在BC-Linux 7.5 libvirt 3.9.0开始支持，之前因为线上版本众多且版本跨度太大、互相迁移各种异常问题频发、数万台节点升级耗时数月之久的日子一去不复返了。现在可以快速拉平资源池版本，在大大减小运维人员压力的同时给数据中心软硬件升级带来更大的灵活性和选择性，也给客户带来更快捷的问题响应速度。

-End：）

往期精选