• Desire

  • 希望搞一个Fault-Tolerant的Machine（Computer)
  • 是从计算机角度出发的FT(对计算机整个运行状态的replication)，而不是仅仅是应用层次的FT,

• Is Worthy?

  • 虚拟机相比直接在物理机层面更不重视硬件特性，适用范围更广。
  • 比state transfer这种方式要好，开销更小，但是实现相比更加复杂

• Apporaches of Replication

  • state transfer
    • 整个物理状态的传输（比如内存、磁盘）等等
  • replicated state machine
    • 控制开始状态相同，传输外部操作+额外的控制信息
    • 本质是让两者的内部操作相同

• What state?

  • 内存中的所有内容和寄存器状态，而不是应用层级别
    • 缺点：开销大
    • 优点：对上层应用的支持强（要求低）
  • 通过packet来传输

• Model

  • replicated state machine

• 不确定事件

  • Input（输入方式、中断）
    • 设定输入只来自网络
    • 数据包中的内容和中断的时机
      • primary发送发生中断的指令位置，backup接收中断，为了保证正确性，backup需要保证状态总落后于primary
  • weird instructions
    • 比如一些产生随机数，读取本机mac地址（等唯一性结果）
    • 这类指令的结果，backup只能通过primary转发获得相关结果来保证一致性
  • multi-core
    • 多核指令执行顺序不同
    • 尚未解决

• Output rules

  • 只有当所有的backup接收到消息之后,primary才能output
    • 避免了主机接收到消息后output,但是主机之后死掉了，而且由于网络原因发送给backup的消息也丢了，而导致的backup与primary状态不一致

• Test-and-Set server

  • 决定在发送故障时哪个服务器go live, 采用cas原理
  • 避免互相认为对方下线，并产生“split brain” 现象

• 同步程度

  • 部分延迟，backup是略延迟于主VM的

• Cut-over(Client 应该在主机宕机之后，知道去哪个backup*问 )

  • backup上线的时候，会模拟主机的一些特性，比如ip,mac等,对外，client不会察觉cut-over

• Extra Ouputs

  • backup上线的时候，可能会重复输出一些之前主VM已经输出的信息。因为backup无法确认主VM是在output之后下线，还是在output之前下线的。

• 支持运行时new replica

VMware Fault-Tolerant Virtual Machine 论文总结