VM-ft

首先可以看tanxinyu 的论文笔记博客 对整个论文有大致的了解。Vmware-ft 论文主要为了解决两台主备物理机之间针对非确定事件的一致性同步问题，并对机器状态接受做了问题简化，只关注外部不确定事件输入（这里特别指网络数据包的到达）、定时器中断和怪异指令。他的底层思想仍然是复制状态机模型：多个机器在相同的初始状态下，执行相同的输入，那么最后的状态一定是相同的。需要解决的问题是，这些非确定的事件怎么依赖一种 捕获——重放机制以确定的顺序和位置记录下来，并精确的在备机上重放，在多台机器上达成同步的一致性状态。可以说，vm-ft 是补充实际应用下，除确定性指令外实现复制状态机的解决方案。

A1：捕获—模拟中断—重放机制的工作原理

这里有两个场景，分别是**primary 的定时器中断和来自网卡的网络包数据中断**，处理略有不同：

• 定时器中断：在运行了 Primary 虚机的物理服务器上，有一个定时器，这个定时器会计时，生成定时器中断并发送给 VMM（虚拟机监控）。VMM 会停止 Primary 虚机的指令执行，并记下当前的指令序号，然后在指令序号的位置插入伪造的模拟定时器中断，并恢复 Primary 虚机的运行。之后，VMM 将指令序号和定时器中断再发送给 Backup 虚机。虽然 Backup 虚机的 VMM 也可以从自己的物理定时器接收中断，但是它并没有将这些物理定时器中断传递给 Backup 虚机的 guest 操作系统，而是直接忽略它们。backup 接收到来自 primary 的伪造 log 中断，送入操作系统中。这样，就实现了从 primary 到 backup 的精确指令中断重放。
• 网卡中断：一个网络数据包到达了 primary 机器，网卡会将网络数据包拷贝给 VMM 的内存， VMM 在接收到网卡中断后会停止 primary 机器。这时候他会同时 将 primary 机器上的指令、网络数据包发送给 backup， backup 拷贝数据包内容到内存，在相同的指令序号位置模拟一个网卡中断；网络数据包拷贝给 primary 内存，发送网卡中断。这就是 Bounce-Buffer 机制
  可以看到，无论是定时器中断还是网络数据包，其本身的中断都是不确定的，vm-ft 提出用这种指令序列 + 捕获中断 + 重放的方式精准在主备机器上实现同步。

A2：考虑容错机制，vm-ft 怎么解决宕机的不一致？

问题背景：假设 Primary 生成了回复给客户端，但是之后立马崩溃了，或者因为网络不稳定，backup 没有收到网络包。primary 机向客户端回复后，backup 成为主机却没有上次的记录。
解决这个问题方法可以是等待 ack，即直到 Backup 虚机确认收到了相应的 Log 条目，Primary 虚机不允许生成任何输出。这里的核心思想是，确保在客户端看到对于请求的响应时，Backup 虚机一定也看到了对应的请求，或者说至少在 Backup 的 VMM 中缓存了这个请求。如果出现崩溃，那么主机不会收到 ack，自然也不会向客户端返回响应。
然而，这样是非常消耗性能的。更通常的做法是，备机维护一个 log 缓冲区，收集主机的网络包并依次确认，而这似乎并没有遵循 vm-ft 的输出控制

A3：vm-ft 主从切换仍然需要单点控制

如果两个机器之间发生了网络故障，或者本身两台机器出现物理故障，在其中一个的视角，是：网络数据包不可达或者超时。这时候需要主从切换，向一个可信的第三方 test-and-set 求证。类似锁的功能，决定谁是主节点，用标志位 0/1 来标识