Cloud Pilot 2.5 Google Cloud Platform 虚拟机迁移（下）

被迫营业的猫猫

本周赶上独立日休假，本来没打算写。后来看了看上周的素材还多了点边角料，就顺手凑了一篇。实属为了这点醋，包了顿饺子。

上一篇网络架构的内容引用了以下博客/论文/演讲：

1. 1. Facebook - Introducing data center fabric, the next-generation Facebook data center network
2. 2. Facebook - Introducing “6-pack”: the first open hardware modular switch
3. 3. Facebook - Fabric Aggregator: A flexible solution to our traffic demand
4. 4. Facebook - Reinventing Facebook’s data center network
5. 5. OCPSummit19 Facebook - Scaling to a Larger Bandwidth Network with MiniPack
6. 6. Google - Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network

本篇服务器虚拟化的内容则引用了以下博客/论文/演讲：

1. 1. AWS re:Invent 2017 - C5 Instances and the Evolution of Amazon EC2 Virtualization
2. 2. Neclab - My VM is Lighter (and Safer) than your Container
3. 3. Google Cloud Next 18 - Sandboxing your containers with gVisor
4. 4. AWS - Firecracker: Lightweight Virtualization for Serverless Applications
5. 5. VMware - The design of a practical system for fault-tolerant virtual machines
6. 6. Google VM Live Migration At Scale
7. 7. UCloud - KVM虚拟化跨机迁移原理
8. 8. UCloud - KVM虚拟化跨机迁移优化指南

VMware vSphere特性

VMware vSphere在销售的时候有四个重要的卖点：vMotion，Distributed Resource Scheduler，High Availability，Fault Tolerance。（销售的这些词不等于技术概念，VMware的主要目的是卖东西。售前工程师说话又好听，个个都是人才，什么超融合、私有云张口就来，Hyper-Converged Infrastructure、Software Defined Data Center、Private Cloud翻来覆去吹了好几年）

vMotion

支持将正在运行的虚拟机在不中断服务的情况从一台ESXi主机迁移到另一台ESXi主机中，或者将虚拟机的存储进行迁移。原理上

1. 1. 系统先目标ESXi主机上产生与源ESXi主机一样配置的虚拟机。同时源ESXi主机会创建内存位图，vMotion期间所有对虚拟机的操作都会被记录在内存位图中。
2. 2. 将源ESXi主机上的虚拟机内存状态复制到目标ESXi主机上，然后复制内存位图（会有一个秒级的停顿），接管虚拟机硬盘文件。当所有操作完成后，在目标ESXi主机上激活虚拟机。
3. 3. 替换网卡MAC地址，删除源ESXi主机上的虚拟机，释放内存。

DRS（Distributed Resource Scheduler）分布式资源调配

虚拟机可以在多台ESXi主机之间实现自动迁移，使ESXi主机与虚拟机能够实现负载均衡。原本vMotion是手动启动的，启用了DRS之后可以根据配置，自动vMotion。

HA（High Availability）高可用

监控群集中的ESXi主机以及虚拟机，使群集中的ESXi主机或虚拟机发生故障时自动到其他的ESXi主机上进行重新启动。启用HA时，会自动选举一台ESXi主机作为Master主机，其余作为Slave主机。Master主机与vCenter Server进行通信，并监控Slave主机的状态。Slave主机故障时，Master主机进行故障处理并重启虚拟机。当Master主机故障时，Slave主机会重新选举产生新的Master主机。

FT（Fault Tolerance）容错

以主从方式同时运行在两台ESXi主机上，如果主虚拟机的ESXi主机发生故障，在另一台ESXi主机上运行的从虚拟机立即接替它的工作

vLockstep

VMware vSphere 4.x中的FT使用vLockstep技术来实现容错，其本质是Log - Replay。

Log - Replay

当虚拟机启用FT后，虚拟机一主一从同时在两台ESXi主机上运行，Primary VM做的任何操作都会通过replay的方式传递到Backup VM。

FT protocol

这种方案存在一个时间差，称为vLockstep Interval，基本在1s左右。VMware在论文《The design of a practical system for fault-tolerant virtual machines》中介绍了这种技术。然而仔细读论文的话，这种技术有个前提条件那就是虚拟机的执行必须是确定性的，论文中也提了只支持单处理器，多处理器的支持还在研发中（有一些性能问题）。实际上，VMware根本没法解决多处理器的确定性重放。这个功能直到vSphere5.x版本中还是只支持单vCPU。

Fast Checkpointing

VMware vSphere 6.7中的FT使用新的Fast Checkpointing技术来实现容错，具体做法是类似上面vMotion的方案，每隔一段时间做一个check point，复制内存位图，走10 GE传到Backup VM。VMDK files也拆成多个，每次只复制变动的部分（主要还是网速提上来了）。

Google Cloud Compute Engine Live Migration特性

2018年Google发表了论文《VM Live Migration At Scale》 为了在live migration期间满足数据一致性，同时快速迁移，论文中介绍了Google使用的三阶段内存迁移。

Live Migration

第一阶段Pre-Copy预复制

进行多轮内存复制，直到满足以下三个条件之一：

• • dirty memory drops below a predetermined threshold 脏内存下降到预定的阈值以下
• • a predetermined number of passes have occurred 已经到达预设的复制次数上限
• • the total amount of dirty memory increases between two passes 两轮复制期间，脏内存的总量增加

理想状态下，随着多轮内存复制，脏内存应该不断减少。但是一个常见的场景就是vm在迁移时正在大量往内存里写数据，那么就会进入状态2：多轮内存拷贝直到到达复制次数预定上限；或者3 脏内存的增加快于复制，所以两轮复制期间，脏内存的总量增加。论文表示由于Google的Jupiter Network支持的网速比较快，所以99%的情况都是状态1，因此只通过Pre-Copy预复制就能实现最小中断（minimal blackout）。

第二阶段 Unpopulated Page Detection 检测未填满的页面

vm申请16G的内存，但是可能运行期间只占用了8G内存。这样说来有很大一部分内存是可用但是不需要复制的。这一阶段主要就是对这部分内存进行处理，保证这些内存在逻辑上可用。这样有两个好处：

• • 提高了使用超大内存的vm的性能
• • 不需要目标vm为这些空间分配真实的物理内存

第三阶段 Post-Copy 后期复制

后期复制主要是为了解决了长尾中断问题，给在迁移时大量往内存里写数据的vm一个中断，并捕捉这些写入操作，直到后期复制完成。这个过程一般耗时在毫秒级。Google在论文中稍微提了一句另一种优化方式：CPU degradation。具体做法应该可以参考UCloud发表的一篇博文 《KVM虚拟化跨机迁移优化指南》，他们在KVM上做live migration的方法也很巧妙。对于在迁移时大量往内存里写数据的vm，短暂的将vCPU的效率降低20%，这样往内存写入的速度就慢下来了，足够在线上做内存复制。