假造化实战：对(类)假造机进行及时热迁移

对假造机进行及时热迁移

众所周知，对于假造化的工作负载（尤其是公有云场景），我们希望其具有足够的高可用性。当一个服务在物理层面上暴毙了，或者因为网络缘故原由断开了和主集群的连接，我们希望有备份机对于原有的服务进行及时的热迁移（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一次或者更长，这统统也取决与你的个人需求（以及代码编写水平）。
总结

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。