The Design of a Practical System for Fault-Tolerant Virtual Machines论文理解

本文主要是介绍The Design of a Practical System for Fault-Tolerant Virtual Machines论文理解，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

这篇论文主要介绍了VMware公司如何设计主从虚拟机机制保证整个系统的顺利运行

介绍

一般有两种方法可以把一个虚拟机的状态复制到另一个虚拟机里（这两种机制可以跟Redis的AOF、RDB持久化区别有点像）

1、完整复制，把cpu里寄存器信息、内存、IO设备状态都发送给另一个虚拟机

问题：需要传输的信息太大了，很耗费时间

当同步的back-up挂掉时VMware公司似乎采用了类似这种思路的方式进行了同步

2、State-Machine approach。思路类似有限状态机，即大部分时候输入一致，起点一致，应该指令会产生相同的效果。

当然很多时候二者无法完全同步，例如生成随机数、记录当前时间等，因此大部分时候依然需要额外信息输入，以便让主从虚拟机状态完全一致。即便加上额外信息，整体需要传递的信息依然远远小于第一种方法。

分布式特性，为了尽量避免一批机器同时挂掉（地震、断电等），尽量将机器进行分散，放在相隔较远的地方，这里也是这样设置的两个虚拟机机器的位置。

当然这种设计能处理的错误种类是有限的，即只能处理fail-stop failures（能被其他server发现到的错误）。像底层CPU运行出错这种问题不在考虑范围之内。

基础设计

在讲设计之前先介绍些虚拟机的名词概念。

hypevisor即Virtual Monitor Machine，可以监控到虚拟机的全部输入

整体设计如下，primary和back-up可以通过logging channel进行执行指令及额外信息的传递。另外二者还可以很容易地通过logging channel了解到二者的状态（例如每时每刻都有时间的interrupt，如果没有消息了说明primary或网络有问题）。primary的output会通过网络传递给client，back-up的output则会被VMM直接抛弃。

值得特别注意的是，二者使用了通过网络访问的共享内存，这使得他们之间的替换相对容易。

而且当访问不了内存的时候说明网络有问题，实际上程序也无法运行下去，故不影响整体效率。

替换机制

为了保证back-up可以替换primary，FT进行了很复杂的设计。

例如，back-up要保证执行时不落后primary太多log，否则primary失败时无法迅速替代。当然，为了实现这一点FT也付出了性能的代价，偶尔响应速度会变慢。

另外，很核心的一点是，如果primary进行output但在把信息传递给back-up的时候崩溃了，back-up之后可能再执行一遍，而且结果与primary的结果不一样，这时候怎么办。

为了解决这个问题，FT采用了Output Rule

Output Rule:

primary VM 只会有在收到back-up VM的ack后才会输出自己的结果

这样的话有两种可能

1、primary没有output，back-up进行output

2、primary进行了output，back-up接手后进行了相同的output，TCP等机制会自动处理相同的packet包，对整个系统的运行不会产生障碍。

那么这个等待的设计是否会影响效率呢？答案是不太会。

虽然没有输出，但primary依然在不断excute指令，只是把结果进行了缓存，整体效率没有下降。

错误检测

primary和back-up失败时会发生不同的后续。

primary失败：back-up进行替换，VM系统就自动进行MAC地址的转换，映射到新的机器上

back-up失败：primary恢复成正常模式，不再传输数据，FT自动创建新的同步back-up

检查是否失败主要有两种方式

1、通过UDP进行heartbeating来检测server是否crash了

2、查看logging channel，看是否有消息延迟

为了避免出现split-brain现象，FT会为二者提供一个共享内存，在里面设计一个类似锁的Test-and-Set标识，只有获得的才能执行。

实践细节

Logging Channel内部使用了buffer，可能会出现消息堆满或者消息过少的情况。

消息过少时，back-up会等待。因为back-up并不直接与外部沟通，实际上并不影响整体效率。

消息过多时，back-up无法消费完毕，这时候需要primary降速等待back-up以避免消息丢失的情况出现。

本身对于磁盘的读写操作可能产生冲突，一种是通过MMU对page加锁，但这种操作成本过高。因此采用bounce buffer机制。

磁盘操作可能和 VM 中的应用程序或 OS 存在内存访问竞争。

这种竞争在网络数据包或磁盘块到达 primary 时产生。在没有 VM-FT 的情况下，相关硬件会通过 DMA 将该数据复制到内存中。若 APP/OS 也在同时读取这块内存。那么对于 primary 和 backup ，由于时间上的微小差异，可能一个在 DMA 之前读取，一个在 DMA 之后读取，就导致了不一致。

一种解决方法是通过MMU对page加锁，但这种操作成本过高。因此采用bounce buffer机制。 bounce buffer 的大小与磁盘操作访问的内存大小相同。primary 的 Hypervisor 首先复制网络数据或磁盘块到 bounce buffer ，此时 primary 无法访问它，Hyperbisor 中断 primary 使其暂停执行，并记录中断的指令。然后 Hypervisor 将 bounce buffer 中的内容复制到 primary 的内存，并让其继续执行。通过 logging channel 将数据送到 backup 之后，backup 的 Hypervisor 在相同指令处中断 backup ，将数据复制到 backup 的内存后，最后恢复 backup 的执行。