阅读 The Design of a Practical System for Fault-Tolerant Virtual Machines

这篇文章介绍了VMware容错虚拟机的设计。

之前看到的GFS是应用级别的分布式应用，而VMware FT是基于机器级别（虚拟机）的复制。基本配置如下，主从服务器之间通过Logging channel来进行同步，使用的是共享存储。

文章提到，backup server是不会对存储进行读操作的。这里的backup server完全可以理解为是一个灾备服务器。

logging channel

logging channel主要用于primary backup同步的日志传输。

对于非确定型的事件（中断）或者操作（获取时间，或者随机操作），日志记录了足够的信息，能够使得backup server进行对应的操作后，其状态与primary server的状态是一致的。

另外，日志还维护了指令的执行顺序，保证backup server执行的顺序与primary server执行的顺序是一致的。

为了保证即使发生了故障，主从的状态也是一致的，对primary的一次请求，只有接收到来自backup server对对应日志的ack，才进行输出响应。也就是文章提到的需要遵循所谓的output rule。这样的处理方法还是比较常见，如mysql的主从复制的全同步，但这样会相应延长请求的响应时间。

Output Rule:the primary VM may not send an output to the external world,until the backup VM has recieved and acknowledge the log entry associated with the operation producing the output.

试想一下某个时刻primary server发生故障，backup准备接管，成为新primary server(go live)。backup server执行至最新的日志。对于最后的一个操作，backup server并不清楚旧的primary server是否完成了输出，还是会进行一次输出。这里提到的输出是指通过网络包传输给客户端或者对结果写盘。对于网络包的传输，如果客户端接收到重复发送的网络包，会丢弃相同的网络包。而对于写盘操作，写盘操作是幂等的，指定位置，写入相同的数据，结果是一致的。

因此，能够保证故障发生后，数据不丢失（backup server已经接收到日志的操作），状态一致的。

存活判断

通过心跳，以及logging channel来共同判断server的存活。

同时防止脑裂的情况，server需要通过在共享存储上面的test-and-set来抢占成为primary server的资格。

存储

文章还对存储展开做了一些讨论。

1）是否使用共享存储

出于成本考虑，或者primary server和backup server相距较远的情况下，使用非共享存储。那么磁盘的状态，在故障发生后，是可能会不一样，需要进行再次同步（resync）。

脑裂依赖于共享存储来解决，需要通过另外的服务，来提供类似的解决方案。

2）backup server是否读磁盘

之前也提到，backup server是不会读磁盘。如果允许磁盘读取的话，那能够减少logging channel的传输量，因为只需要告知backup server读取的指令，由backup server自行读取即可。而相应的某些比较繁重的磁盘读取请求，会拖慢backup server命令执行。

另外，需要处理磁盘IO失败的一些情况。
primary server读取成功，backup server读取失败的情况，backup server需要重试直至成功，来保证主从读入到内存中的数据是一致的。
相反，如果primary server读取失败，backup server读取成功。此时，primary server的内存状态是不确定的，primary server需要将内存的状态通过logging channel的方式传输到backup server。

如果使用的是共享存储的话，还需要的通过一些机制来保护。比如backup server正在读取，而primary server接受的新的请求刚好需要修改对应的内容，就需要写等待读完成之后，再进行写入。

另外，关于这篇文章的一些相关问答，还是很有意思，能够更好理解文章内容，附注如下：
https://pdos.csail.mit.edu/6.824/papers/vm-ft-faq.txt