对虚拟机进行实时热迁移

众所周知，对于虚拟化的工作负载（尤其是公有云场景），我们希望其具有足够的高可用性。当一个服务在物理层面上暴毙了，或者因为网络原因断开了和主集群的连接，我们希望有备份机对于原有的服务进行实时的热迁移（real-time & hot），而不丢失（或者很少丢失）原有的执行状态。尤其是对于那些负载较高或者可用性要求较高的服务来说，这个技术在业务侧进行混合云部署时也比较有用.

本文描述了一种解决方案，对于这个过程中的技术细节和可能出现的问题进行了一些讨论.

本项目的绝大部分思路来源于这篇非常经典的Remus论文：https://www.usenix.org/legacy/event/nsdi08/tech/full_papers/cully/cully_html/ 。

这里有一个示例项目的代码，客观来说写的略显杂乱，仅供参考：https://github.com/mahiru23/intravisor/tree/syscall 。

快照机制

显然，如果我们想要迁移一个服务，我们一定要有技术将一个服务的快照完整保存下来并且在另一台物理机上进行恢复.

如果你的服务是以一个进程/线程的方式存在，我们只需要迁移其上下文（thread context），当然也包括存储系统的维护。如果是容器或者虚拟机，我们可能需要一些额外的metadata和与底层基座/硬件解耦合的机制，这里不做过多讨论，仅为抛砖引玉.

如果你的集群使用OSS等技术来进行外部存储，则可以忽略对于同步持久化存储的需求.

这里我们讨论一个最简单的情况：一个单线程的进程，其可能的快照组成如下:

复制流水线（streaming replication pipeline）

一个典型的单线程复制流水线分为：停机(suspend) -> 快照采集(snapshot) -> 传输(network) -> 恢复(resume) 四个步骤.

模块化的主机操作流水线:

备份机操作流水线:

主备切换

我们需要一个灵敏的错误检测器，可能由多种机制组成:

• heartbeat心跳包
• 已存在的socket网络连接监测
• 外部服务状态检测器（基于云）
• 客户端状态反馈（基于端）

性能提升：异步事件队列（event queue）

根据需求，我们可能需要将快照采集和传输两个过程解耦合，使得我们主服务的停机时间尽可能短。这就需要几个额外的线程去采集并传输不同的资源，包括TCP状态，disk，context等.

我们的事件可能是heartbeat/snapshot/disk ops/net ops/其他...... 。

这样我们就可以对带宽和计算资源完全分开，并且动态调整了，甚至我们可以设置一个threshold来监控队列的大小，是否阻塞.

性能提升：脏页追踪（dirty page tracking）

显然我们不能在每一个复制周期都进行全量复制，相反，我们只传输自上一个复制周期以来被修改的那部分，也就是做增量的备份.

对于内存页面来说，脏页追踪（dirty page tracking）机制是我们需要的.

我们通过mmap监控物理内存段，手动disable掉自动page的write back机制，将用户虚拟页面的管理权限从kernel层面上移到user space层面，这也是本方案的一个核心要点.

在用户空间，我们可以使用hash table对于用户的页面进行编码，进行统一管理.

由于一个4KB的页面可能只有很小一部分被修改，一个合理的优化是将本周期的页面更新与上一个周期做差，用gzip或者run length encode做压缩，这个优化在高频复制时可以显著降低传输中的带宽需求.

代价

高可用永远都是有代价的，额外的带宽消耗/算力损耗/备份空间需求等都是潜在的问题，是否采用请自行抉择.

复制的频率从每秒10次到每10min一次或者更长，这一切也取决与你的个人需求（以及代码编写水平）.

总结

以上，就这样吧，如果有其他想要讨论的内容评论区见.

最后此篇关于虚拟化实战：对(类)虚拟机进行实时热迁移的文章就讲到这里了,如果你想了解更多关于虚拟化实战：对(类)虚拟机进行实时热迁移的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。