The Design of a Practical System for Practical System for Fault-Tolerant Virtual...

这篇文章是 MIT 6.824 课程安排的一篇阅读材料，最近正好在做 FT 相关调研，没想到 VMware 居然很早以前就把文章发出来还是 MIT 课程推荐的经典文章，真是孤陋寡闻了。

我 Fork 了别人整理的 MIT 6.824 的课程材料，关于这篇文章的内容可以在这里找到： https://github.com/MatheMatrix/MIT-6.824-Distributed-Systems/tree/master/Lectures/LEC04

下面是笔记。

摘要

VMware 在 2010 年发布了这篇文章，主要描述它们在 vShpere 4.0 上实现的虚拟机高可用方案，这是一个商用的、企业级的方案，虚拟机性能下降在 10% 以内，虚拟机同步需要 20M 左右带宽。文章提到让这样一个系统支撑企业应用除了复制虚拟机的指令外，还有很多其他问题。

介绍

实现高可用的基本思路是主备，主备最简单的想法就是 复制主的所有状态 ，包括 CPU、内存、IO。但是这个方案无疑需要非常大的带宽。

另一种方法是 复制状态机思路 ，简单的说，这个思路就是把虚拟机当作一个确定状态机，两边先保持一个一致的初始状态，然后保证它们能够一样的顺序接收一样的指令。 因为总有一些操作造成的结果不是确定性的，因此还需要额外的工作来保持同步 （主要是内存）。

这个思路在物理机上无疑很难实现，但是在虚拟机上就好做很多，因为虚拟机就是一个定义的很完善的状态机，其所有操作、设备都是虚拟化的。但是相比物理机，虚拟机自己也有一些非确定性操作，例如读取时间和发送中断，这就是为什么我们刚才说需要额外操作来保持同步。

VMware vSphere FT 基于确定性重放（deterministic replay），但是增加了必要的额外协议和功能来保证系统功能完整。到写这篇文章时，FT 生产版本还只能支持单 CPU 虚拟机，因为对多 CPU 来说，几乎每次读写共享内存都是非确定性操作，由此带来巨大的性能损失。

这个系统的设计目标只处理 fail-stop 错误，也就是系统一旦出错则立即 stop，而且正确的服务器立刻知道它 stop 了。（分布式系统中的各种错误可以参考： http://alvaro-videla.com/2013/12/failure-modes-in-distributed-systems.html , fail-stop 几乎是最简单的错误类型)

FT 设计

首先我们将备份虚拟机运行在一个和主虚拟机不同的物理机上，备份虚拟机与主虚拟机保持同步和一致但有一个很小的时间差，这时我们称这两个虚拟机处于 virtual lockstep。

两个虚拟机的虚拟磁盘位于共享存储上（例如 FC 或 iSCSI，后面会讨论非共享存储的场景），只有主虚拟机会在网络上对外通告，所以所有网络输入只会进入主 VM，其他输入例如键盘和鼠标也是一样只到主虚拟机。

所有主虚拟机收到的输入，会通过网络（logging channel）来发到备份虚拟机。VMware 通过特定协议做收到确认，来保证主虚拟机失效时不会有数据丢失。

为了检测主虚拟机或备份虚拟机失效，VMware 会在两个服务器上跑心跳，同事监控 logging channel 的流量。

确定性重放（Deterministic Replay）的实现

虚拟机有大量的输入，包括：

• 收到网络报文
• 磁盘读
• 键盘鼠标输入

还有大量非确定性事件（比如虚拟中断）和非确定性操作（比如读取 CPU 时钟计数器）都会影响虚拟机状态。

难点有三处：

• 正确捕捉所有的输入和不确定性
• 正确的在备份虚拟机上应用这些输入和不确定性
• 确保不太多影响性能

此外，x86 处理器有很多复杂操作会造成未定义的、造成不确定性的副作用。

VMware 确定性重放（2007 年的这篇文章更详细的做了介绍： http://www-mount.ece.umn.edu/~jjyi/MoBS/2007/program/01C-Xu.pdf ）解决了上述的前两个问题。