VM-FT论文分析总结（Lec4）

一、目的

1.提供容错虚拟机(fault-tolerant virtual machine)的企业级商业系统。
2.容错方案是提供一套primary/backup位于不同物理机的虚拟机，两者状态同步，当primary出错时backup可以无缝替代，客户端访问无感知。

二、primary/backup保持同步的两种方法

1.方法一：State transfer

State transfer (状态转移）：主服务器持续将所有状态（包括CPU、内存和I/O设备）变化发送给备份服务器。此方法传输的数据量大，所需的带宽非常大。

2.方法二：Replicated State Machine

Replicated State Machine (备份状态机）：将备份状态机视为确定状态机（Deterministic State Machine，DSM）。然后主/备份服务器都以相同的初始状态启动，然后以相同的顺序接收并执行相同的输入请求，然后得到相同的输出，这样就可以保持两者状态的一致。此方法较复杂，但传输的数据量小很多。（本文就是采用此方法）

3. 不确定性行为转为确定性行为

采用备份状态机会有一个问题，即对于真实物理机来讲，有些行为是不确定的（例如，中断，产生的随机数等），所以很难将行为看作是一个确定性（deterministic）的行为。
VMWare的解决方案是将所有操作虚拟化，并在VM和物理机之间加一个Hypervisor（虚拟机管理程序），然后就可以通过hypervisor让VM都能模拟成一个DSM运行，那么primary的所有操作都确定了，再通过Logging channel将这些操作传递到backup，然后backup进行replay，从而实现两者的高度一致。
具体是怎么将不确定的行为进行确定化操作的，它主要是进行了一个写日志的操作(WAL预写式日志)来保证的，后续会详细解释。

4.确定性状态机：

多台状态机从相同的初始状态开始、按照相同的顺序执行相同的操作，则它们的最终状态是一致的 。
状态机方法允许 primary 和 backup 进行更大的物理分离 。

三、为什么选择虚拟机——保证不确定性变成确定性

1.虚拟机 ( virtual machine ) 不是通过硬件来启动操作系统，而是在硬件之上会调用一个 Hypervisor ，Hypervisor 的工作实际上就是在硬件上模拟多个虚拟计算机 。Hypervisor 上执行着 GuestOS ，再上面是应用程序 ，如下图所示：

Hypervisor 即 virtual machine monitor ( VMM )
GuestOS 即运行在虚拟机中的操作系统，与之对应的是 HostOS ，指物理机里的操作系统 。
2.确定性重放replay
（1）VM-FT 建模为确定性状态机的复制 。对于一系列输入，对 primary 的执行进行记录并确保 backup 以相同方式执行的基本技术称为 确定性重放 。
（2）在物理机上确保确定性执行是困难的，因为其会接收到很多不确定输入（ 如定时器中断 ），因此可以采用虚拟机，Hypervisor 对硬件进行模拟和控制，可以捕获到这些不确定输入的所有相关信息，使得 backup 可以重放这些不确定输入 。
实现的最终结果是，primary 会将它所有的 input 以及所有可能会发生不确定性结果的相关状态全部会记录到日志log entry中，这个日志会交给 backup 进行 replay 操作，能够确保 backup 进行 replay 后同 primary 的状态是一模一样的。
例子：一个操作让 primary 生成一个随机数，那么 primary 会在日志中记录当前生成这个操作的所有状态，比如它是根据当前时间或者是当前某个时钟周期当作 seed，这些随机性全部由 hypervisor 来处理，backup 进行日志 replay 时，碰到这种随机性事件，hypervisor 让它执行的时候跟 primary 得出的结果一摸一样，让两者在状态上没有差别，很了不起。
（3）确定性重放记录 primary 的输入和 primary 执行相关的所有可能的不确定性，记录在 log entry 流中，发送给 backup 并使其重放 ：

• 对于不确定的操作，将记录足够的信息，确保其在 backup 上重新执行能够得到相同的状态和输出
• 对于不确定的事件，如定时器或 IO 完成中断，事件发生的确切指令会被记录下来，重放时，backup 会在指令流中相同的位置重放这些事件

（4）log entry 中应该包含了：（通过Log Channel的内容论文没说，Robert教授猜测日志条目中有三样东西：）

• 事件发生时的指令号
• 类型，指明是网络输入还是其他指令
• 数据：数据包里的数据，若是不确定指令，则此数据是该指令在 primary 的执行结果，所以 backup 就可以对该指令提供与 primary 相同的执行结果

（5）不确定性指令执行过程：
（ 即使 primary 和 backup 在同一状态，执行不确定性指令后也会产生不同结果 ）
primary：

• Hypervisor 在 primary 执行指令时设置中断
• Hypervisor 执行指令并记录结果
• 发送结果和指令序号到 backup
  backup：
• Hypervisor 读 log entry ，在该指令序号处设置中断
• Hypervisor 应用从 primary 执行得到的结果，自己产生的结果被丢弃，从而保证主备一致

3.因为我们讨论的故障主要是指服务器故障，因此不同的虚拟机要位于不同的物理机上，否则便失去了容错的意义 。

四、基本架构

1.VMWare的结构是运行在同一个网络下，两个虚拟机部署在不同的机器上，并且共享一个磁盘（这里会有一个split-brain问题，即primary 和 backup 之间通信断开，但此时 primary 还在运行，若 backup 此时上线，会造成两者同时执行的问题，可能会导致数据损坏 ）。
2.Primary接收的输入信息是通过Logging channel传输给Backup，以保持同步。Backup VM 的指令执行结果与 Primary VM 的结果相同，但只有 Primary VM 返回给 client 结果，Backup VM 的结果会被 Hypervisor 丢弃 。
3.对于外界，它们只知道有一个Primary VM在工作，并且所有的输入输出都是由Primary处理。因此所有网络输入或其他输入（磁盘、鼠标、键盘）都进入 Primary VM 。

4.系统使用 Primary VM 和 Backup VM 之间的心跳包和 Logging Channel 上的流量监控来检测 Primary VM 或 Backup VM 是否是失效 。此外，必须确保 Primary VM 和 Backup VM 中只有一个接管执行 。
5.事实证明，这些主备虚拟机并不适用于本地磁盘，而是会和某些磁盘服务器进行通信。（ 论文中并未提到这点 ）

五、FT Protocol

1.通过FT Protocol确保主备信息一致

（1）primary 会时刻写日志交给 backup 来进行 replay，这些日志通过 logging channel 传递，传递过程中满足 FT Protocol，FT Protocol 定义了一个最基本的要满足的需求，叫做 Output Requirement，它要求在系统外界看来（比如客户端），哪怕是发生了 primary 宕机然后 backup 顶上这种事情，外界还是认为一切正常，backup 顶上的行为要求和 primary 要一致。
（2）要满足这一点，VMware 定义了一个叫做 Output Rule 的准则，当收到要对外界做 output 类别的操作时，primary 要等到 backup 能够 replay 到 primary 能够执行将要进行 output 操作那一点，才能开始对外界进行 output 操作。
就是 primary 收到了一条信息，要对这个信息做 output（比如对这条信息进行回复），然后 primary 先写日志并传给 backup，并且确保 backup 收到了这条日志，也就是收到来自 backup 关于这条日志的 ACK 之后，才能够开始执行真正的 output 操作。
（3）上面这张图展示了 primary 和 backup 进行通信的时序图，primary 收到异步事件、input 和 output 时，都要对 backup 发送 log，但是收到 output 操作后，直到收到 backup 的确认信息后才发出 output，这样的话，哪怕是之后 primary 挂了，backup 顶上变成 primary 后，外界对此也不会有任何感知。

2.不能保证exactly once

因为若primary在收到backup的ACK之后，已经发出了output，但是此时挂掉了，然后backup顶上去之后不能判断是否是在发送了output之后宕机的，所以它会再发一次。这个问题容易解决：
（1）output是通过网络进行发送的，例如TCP之类的网络协议能够检测重复的数据包；
（2）对于一个写操作，它就是两次在同一个位置写，也不影响结果。

六、FT Logging Buffers and Channel

1.primary在各自生产和消费日志的时候它们不是将日志写到磁盘然后再读。primary和backup它们各自会有一个log buffer缓存，primary将产生的日志写入log buffer，然后通过Logging channel传到backup的的log buffer中，backup再从自己的缓存中读取日志并replay。
2.这里产生的问题是一个log buffer满了，一个log buffer空，即消费者和生产者处理日志的速度出现差距，导致backup处理太快而没有了日志处理，或backup处理太慢导致primary中的缓存已经满了，导致后面primary和backup差距越来越大。整个系统是不希望出现这样的情况的，因为如果 primary宕机了，backup 是需要完成 replay 才能顶上，差距大了，backup 就需要耗费比较长的时间追赶上，这样的话意味着系统的响应是不及时的。
3.为此系统设计了一个机制，使得primary和backup之间的差距保持在一个范围内。即，例如当primary产生日志过快和backup之间的延迟超过了这个范围，就降低primary的CPU资源让primary产生日志的速度慢一点，待backup追上后再提高primary的CPU资源。

七、检测和响应故障

1.两种 VM 都有可能发生故障：

• 如果是 backup 故障，primary 将停止在 logging channel 上发送 log entry ，并继续执行
• 如果是 primary 故障，backup 会继续重放 log entries ，重放结束后 上线 成为 primary ，此时，它可以向外界生成输出 。

2.VM-FT 检测故障的方式有 UDP 心跳检测和监控 logging channel 中的流量以及 backup 发送给 primary 的 ACK 。若心跳或日志流量停止的时间超过了特定超时时间（ 大约几秒 ），就会声明故障 。
3.这里有一个问题就是之前提到过的split-brain问题。backup长时间没有收到来自primary的heartbeat，此时可能是宕机了，可能是网络问题，这时backup是不能直接顶上去的，因为若primary没有宕机，那么此时就会有两个primary，如果它们都去操作共享存储可能会出现数据损坏。
4.primary 和 backup 之间会共享存储，当 primary 和 backup 两者之间任何一方认为对方挂了，想要做进一步行动之前，需要在共享存储中执行一个叫做test-and-set的原子操作，如果能成功则继续进行下一步，但是如果失败了，那就得自杀。当然，还有一种情况，就是共享存储也无法访问了，那遇到这种情况就没办法只能等，因为如果共享存储挂了，无论是 primary 还是 backup 谁顶上也没有办法，所以这里的共享存储其实是一个单点风险。
5.为解决 split-brain 问题，使 Disk Server 支持 atomic test-and-set 测试，即在 Disk Server 上维护一个 flag ，第一个访问此 flag 的 VM 会成为 primary ，第二个访问此 flag 的 VM 不会上线 。（ 类似于锁 ）

• 对于test-and-set操作，类似于下面这样的伪代码，对一个flag进行原子操作：

test-and-set() {
        acquire lock()
        if flag == true:
            release lock()
            return false
        else:
            flag = true
            release lock()
            return true
    }

八、虚拟机恢复

1.FT VMotion
虚拟机primary和backup都可能会失效，所以为了架构的高可用性，VMWare提出了一个技术FT VMotion，用来负责backup的创建。它能够直接对一个VM进行克隆，并且在完成克隆后会建立好和primary的Logging channel，被克隆一方是primary，另一个就是backup。
6.824的LEC4：即使是使用复制状态机，当有个主机宕机需要一个新的 backup 时，还是只能用状态转移方法。论文用 FT VMotion来在远端机器上克隆primary vm。

2.此外，VMware vSphere 还实现了一个可以监控并管理集群资源的服务，可用于选取适合启动新虚拟机的宿主机。

九、bounce buffer

1.这个机制就是防止由于操作系统导致失去时序控制（primary和backup写后读取的时机不同，会造成不同结果）

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

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

十、机器级复制和应用级复制

1.机器级复制

机器级复制 即复制了内存中和寄存器中的所有内容 。优点为可以在 VM-FT 上运行任何软件；缺点为不够高效

2.应用级复制

应用级复制 即 primary 仅发送 high-level 操作给 backup 。如数据库，同步的状态仅为数据库内容，不是所有的内存内容，操作仅为数据库命令（ get 、put 之类 ），没有网络包或中断 。GFS 使用的也是应用级复制 。
优点：更少的细粒度同步、更低的开销
缺点：应用程序必须理解系统的容灾

十一、额外的选择

1.针对于 VMware 给出的已有设计之外，论文中还提出了一些别的设计方案。比如将原本的共享存储更改为 primary 和 backup 各自有自己的存储。当在实际部署时，发现 primary 和 backup 的服务不得不架设在两个不同的区域，此时使用共享存储的方案就会比较低效。但是这样选择的话，就要保证 primary 和 backup 之间的存储也要高度一致才行，除此之外，还要再解决之前提到的 split-brain 问题。

2.另外还有一种设计方式，是让 backup 来处理读数据的请求，这样的方式能够有效减少 logging channel 在处理很多读操作时带来的压力，但是这样就会带来新的问题：

• 有可能造成 backup 的消费压力，这样导致 primary 和 backup 之间的差距越来越大，从而拖慢整个系统；
• 可能会发生这种情况，backup 处理一个读的请求，但是此时 primary 对同样的一个位置进行了写操作，这时就要让 backup 等待 primary 写入完成之后才可以进行读操作。

十二、VM-FT与GFS的容错性比较

1.VM-FT备份的是计算，GFS备份的是存储。
2.VM-FT提供了相对严谨的一致性，并且对客户端和服务器都是透明的。可以用它为任何已有的网络服务器提供容错。例如，可以将 FT 应用于一个已有的邮件服务器并为其提供容错性。
3.GFS 只针对一种简单的服务提供容错性，它的备份策略会比 FT 更为高效。例如，GFS 不需要让所有的操作都应用在所有的 Replica 上。

十三、总结

VMware 提出的这套 Fault-Tolerant 方案可以用在许多系统中。但是，它依然不适合进行高吞吐量的服务，毕竟它要对整个系统内的内存、磁盘、中断等都进行 replay，这是一个巨大的负担。