VM-FT 论文阅读
本文最后更新于：3 年前
背景
本论文主要介绍了一个用于提供容错虚拟机 (fault-tolerant virtual machine) 的企业级商业系统，该系统包含了两台位于不同物理机的虚拟机，其中一台为 primary，另一台为 backup，backup 备份了 primary 的所有执行。当 primary 出现故障时，backup 可以上线接管 primary 的工作，以此来提供容错。
内容
分布式容错方案
分布式系统中需要对一份数据进行冗余存储才能提供容错性，因此问题是：
如果有一份会随时变动的数据，如何确保它正确地存储于网络中的几台不同机器之上？
对于 primary/backup 型的同步方式，可行的解决方案有两种：状态转移（State Transfer）和操作转移（Operation Transfer）。
状态转移
对于状态转移，其方案是 primary 持续地将所有状态（包括 CPU、内存和 I/O 设备等或者整个状态机实例）变化发送给 backup，backup 不需要耗费太多 CPU 资源就可以达到跟 leader 相同的状态，这也导致传输的数据量往往会大很多。当然也可以有一些优化，比如只传送相比上次变化的数据等等，但总之这种方法所需带宽非常大，延迟较高，因此在工业界中应用不多。
操作转移
操作转移能够运行的前提是状态机，其特性是：
任何初始状态一样的状态机，如果执行的命令序列一样，则最终达到的状态也一样。如果将此特性应用在多参与者进行协商共识上，可以理解为系统中存在多个具有完全相同的状态机（参与者），这些状态机能最终保持一致的关键就是起始状态完全一致和执行命令序列完全一致。
操作转移一般有两种复制级别：
- 机器级别：按序复制 CPU 指令，中断，客户端请求等等来保证不同节点间状态一致，这也就是本文的解决方案。这种方案需要解决若干问题，比如多节点间如何处理不明确性命令（获取当前时间），如果避免脑裂等等。看了论文之后，感觉很多关键点在论文中并没有纰漏实现细节，比如 disk server，test-and-set 等。
- 应用级别：按序复制明确性的操作来保证不同节点间的状态一致。比如 MySQL Cluster 的主从全同步复制需要保证所有的从节点接受成功才能返回成功，这一定程度上会导致扩展性受限，即每增加一个 Slave 节点，都导致造成整个系统可用性风险增加一分。因此也出现了基于 Paxos，Raft 的 quorum 同步方案，即一旦系统中过半数的节点中完成了状态的转换，就认为数据的变化已经被正确地存储在系统当中，这样就可以容忍少数（通常是不超过半数）的节点失联，使得增加机器数量对系统整体的可用性变成是有益的，这也是目前大多数应用的容错方案。
总结
作为一篇 10 年前的论文，在那时 Raft 还没有出现，Paxos 还没有得到广泛的承认，该论文对于分布式容错方案提出了一种基于机器级别的操作转移方案，拓展了理论的边界并证明了工业界可用，可以说是比较划时代的贡献了。