fault tolerance

纠正的是failure，不是bug。failure表示的是服务器寄了宕机了（有人把电源线踢了）无法运行，无法检测bug。例如逻辑错误等bugs。部分error，例如硬件错误可以造成failure。

这里假设多台机器的failure是相互独立的，且同时产生的概率是极低的。例如同一个地区发生了地震，那么同一个地区的机房都会寄。这些是fault tolerance的前提

这些replica是值得的吗？——通常花费几倍的硬盘或者内存。 分情况考虑，银行服务或者课程主页，是否需要严格的容错。

replication

state transfer（状态转移或者复制）

整个状态复制，包括所有内存，cpu状态等。 也有可能只复制部分修改的内存以减少通信

replicated state mechine

来源于程序的运行是确定的，除了少数的输入的指令，获取时间和随机数等。所以这个方案只发送输入相关指令（operation）。当遇到随机数和获取时间类似指令时，secondary会接受指令但不执行，直接获取从primary发过来的结果。

这个方案的发送数据量较少，但是方案比较复杂，需要基于一些假设。而且在多核CPU上并行的计算导致此方案是不可行的。

需要考虑的状态？

考虑需要多强的一致性问题。

当primary、backup 失败（failure）时，需要切换

anomalies （异常），失败导致切换的时候，无感知是几乎无法实现的。

new replica。这里我们需要新的一个完整的状态，不得不采用方法一的情况来复制（state transfer），而且需要尽量快。

不同应用需要完成复制的状态层次不同，例如gfs，它几乎不复制内存和cpu的状态，是一种在应用层级而不是系统层级的状态抽象。应用层级的replica需要保存的信息更少。但这篇论文讨论的是内存和cpu状态的replica，这样使得应用级程序员无需关心状态如何复制，而交由系统负责实现。（一个虚拟机）缺点是慢，优点是通用。

VMware Fault Tolerance

什么是 Fault Tolerance 及其工作原理？| vSphere | VMware | CN

(13条消息) VMware Fault Tolerance 概述及功能_dawei2391的博客-CSDN博客

可以在一台机器上起多个虚拟系统。

Client -> primary，primary -> 虚拟机里面的应用，primary -> replica，虚拟机里面的应用->primary-> Client，虚拟机里面的应用->primary->null。 通过log channel。

非确定指令

1、输入 （数据包，中断，在相同指令#处中断）

2、获取时间，获取随机数等。多核cpu并行的情况完全不考虑，但是硬件可以拥有多核CPU，只是虚拟机中不应该模拟多核并行的情况。

综上，log entry（日志条目）应该包括：指令数（已经执行的指令数），输入种类和输入数据，

backup一定要在primary之后执行，所以当backup有primary过来的信息时才执行，否则阻塞。 从虚拟机外部输入的数据可能用DMA的方式送入app，此时为了保证执行的确定性，输入时往往也会阻塞。

output rule

primary不允许产生所有向client的输出，直到所有的backup承认（acknowledge）已经收到所有primary来的log。注意可以backup是已经收到，但无需执行完成。也可以选择执行完成来避免重复输出的问题？ C-(input)>P->B-(ack)>P-(output)>C

但是当primary 崩溃时，backup替换为primary时，可能会产生多余重复的输出，这里不得不需要client处理。

split brain disaster

当主从无法通信，但是可以和client通信时产生更多严重问题。解决方法：test-and-set （个人感觉类似peterson算法）