MIT6.824-lecture4-笔记（包括FT VM）

Failures Modeling

1. fail-stop-failures

once failure happens, the computer will be down immediately

2. hadle none

logical bugs, configuration error, malicious fault

3. physical failure

Challenge

1. distinguish network fault or physical fault

avoid splt-brain system

2. keep primary/backu in sync

• apply all changes in right order
• deal with non-determinism

3. fail over

find out the scene. it means backup take over.

2 approaches

state transfer

when client’s request change primary status, the primary will make its state as a checkpoint to be backed up in the backup

replicate state machine(RSM)

primary sends operation rather than state checkpoint to backup. backup will consuct the operation to get consistency.
it will be inexpensive and fast, getting rid of network bandwidth limit.
this is what GFS take.
this required the operation is deterministic.

level of operations to replicate

• application-level operation
  file append, file write. the application may be need to modified too
• machine-level operation
  transparent about the app. it only focus on instructions.
  traditional replication will be expensive because of the regiters, interrupts and so on.
  virtual mahine to deal with.

VMFT

exploit virtualization

• transparent for application
• distributed -> strong consistensy
• VMWare Produce

thsis-Fault Tolerance Virtual Machine

Intoduction

• 状态复制（state replicaiton）
  状态复制时指把master的所有状态改变————内存、CPU和I/O设备都通过网络传输给备用机（backup）。
  这对网络带宽要求极高
• 状态机复制（state-mechine replication）
  这个机制把整个服务器看作是一个确定状态机，master和backup从同一状态开始，经过同一操作，到达同一新状态。
  这样，只需要通过网络传输操作， 就可以完成状态转移。这也被称为确定性重放（deterministic replay）\

Basic Design

• 确定性重放（deterministic replay）
  master和backup之间通过一个log channel来进行日志传输指令执行位置。由于指令中有一些非确定性操作，如中断（interrupt）、时钟计数器和一些未定义副作用，所以需要特殊的结构来记录这些信息。
  注意到，确定性操作并不会通过log通道进行同步，但是会有定时中断来刷新这些确定性操作的执行。
• 容错协议（FR Protocol）\
  • 输出要求（Output Requirement）
    如果backup由于master宕机而接管系统，backup应该保证给外界世界的输出同master的一致性
  • 输出规则（Output Rule）
    master在将输出传递给外界世界之前，必须接收到backup对于这个输出钱的所有日志记录的ACK\
  • 零额外时间
    只是延迟了输出的发送时间，而没有阻塞master继续执行。
  • 重复可接受
    由于网络基础协议、操作系统和用户程序都会做重复处理，所以不用担心backup和master发送了两个同样的输出。
• 宕机检测和响应\
  • 响应
    • backup失败：master立即go live，离开记录模式，不再向日志通道发送信息
    • master失败：backup接管，由于master和backup有小时间间隔，先进入重放模式把所有为执行完的日志执行完，然后go live
      这个时候FT VM还应该发布新的master的MAC地址和IO等
  • 检测
    • master和backup之间通过UDP传播HeartBeat来确定存在
    • Hyper Visor会监控日志通道上的流量
      由于定时中断的存在，所以这个流量应该是相对稳定的。这个流量降低，就有可能是故障
  • 脑裂（spit-brain）
    master和backup失去网络联系，但是物理上可能都仍是正常运行，这个时候master和backup都会想go live，所以就有可能出现脑裂问题————同时存在两个master，这回导致非常严重的数据损失和不一致性。
    使用在共享内存上进行一个原子测试集的操作，如果成功，就成为master，失败，那么就会进行自杀。

Practical Implementation of FT

1. FT虚拟机的启动和重启

master在整个系统的开始就完成了启动，并且master失败，应该由backup接管而并非重启。所以FT虚拟机的启动和重启就落在了针对backup的设计上。\

• 要求
  • master所有状态可用
    这个机制应该在backup首次创建和backup失败后都可用，无论master处于go live状态或者单独状态，都应该能够正确创建backup
  • master不会被显著中断
    backup的创建不应该过多的中断master执行，否则会给client带来宕机的感受，而影响整个系统设计目标的达成。
• 克隆master
  实际上，在创建backup之前，虚拟机只能成为源，master的概念并不存在。
  在原来的VMotion机制中，允许在小于1秒的暂停时间内，对虚拟机进行迁移（migrate）。
  FT VM利用类似的机制，对虚拟机进行克隆（clone）。在克隆完成后，建立日志通道（log channel），并把源虚拟机设为日志模式，把目的虚拟机设为重播模式。
  FT VMotion只是增加了日志通道的建立，所以整体上仍能保证在1秒内完成。
• 集群管理
  FT VM通常是在集群中运行的。集群管理应该提供创建backup的服务，master在需要重启或启动backup是调用这个服务，由集群管理根据各种原则选择目标机器，然后进行FT VMotion。
  这个操作通常能在几分钟内完成，client并不能明显感受到。

2. 日志通道的管理

• 正常执行
  master和backup通过日志通道完成同步。两个都在本地维护一个大的日志缓冲区，master将执行过程记录到缓冲区，再通过日志通道发送到backup。backup接收到记录后，向master回复一个ACK，再根据自身情况依次执行日志。
  master只有在收到输出前所有日志的ACK之后才会输出。这儿就造成了输出延迟。\
• 缓冲区界限
  • 空
    backup的日志缓冲区为空的时候，它将暂停自身执行。这种暂停没有任何影响，因为backup不会与FT外的机器通信。
  • 满
    当backup消耗太慢，或者master执行太快，都会造成缓冲区满而使master暂停执行。而这个暂停执行大概率会影响它对外界client的相应。这是不可接受的，所以需要机制来降低这种暂停，也就是减少缓冲区被填满的可能性。
    一般情况下，master和backup的机器配置应该是相同的，所以执行速度也大致相同。但是当backup负责太多的VM之后，就会造成性能折损的情况，而导致缓冲区满。
• 故障转移（failover）
  除了缓冲区满，导致master暂停造成延迟增加，还有一个理由需要对日志通道进行管理————故障转移（fail over）。
  当master发生故障，需要backup接管系统的过程就称为故障转移。这个速度应该不能过大（超过1秒），不然就会导致这个FT机制被暴露。
  当backup接管系统的之前，它必须重播所有已确认的日志来**赶上（catch up）**外界对FT VM的认知。完成重放的时间基本上是故障转移的时间。
• master和backup的速度同步
  • 降速防止backup落后太多
    在发送和确认日志条目的协议中加入对实时执行延迟的额外信息。当backup出现明显延迟，FT就通知调度器给master提供稍少的CPU来降速。
  • 加速提高性能
    当bakcup赶上了，就逐渐增加master的CPU限制。

3. FT VM的操作

• 普通操作
  一般的操作都在master上面被执行，然后通过特性的控制项传给backup进行同步。
• VMotion
  VM迁移可在master和backup上独立执行，但是由于FT要求master和backup保持联系，所以会增加复杂度。而且不允许master和backup迁移到同一个机器上，否则FT无法正常提供服务。
  • master VMotion
    master在迁移最后执行阶段，需要等待所有物理I/O处于静止（quiesced）或者叫已完成（completed）状态。
  • backup VMotion
    backup不能控制执行，所以没办法暂停所有的物理I/O以等待VMotion的完成。
    FT提供机制，使backup在最阶段可以在ACK中请求master暂停I/O。master暂停I/O的操作会在backup上重放，这样就有时间完成VMotion了。
    注意，master暂停I/O之后无需等待，仍可继续执行I/O操作。相当于master只是给了backup一个指令。

4. 磁盘I/O

• 不确定性结果
  • 对同一块的访问
    FT VM使用DMA直接进出内存，对相同内存页的磁盘操作将导致不确定性。
  • VM内的程序和磁盘IO冲突
    由于DMA的存在，VM的程序（包括操作系统）和磁盘IO对同一内存块进行访问时也会发生冲突。
• 解决方案
  磁盘操作对于同一块的访问，通常来说会检查这种冲突，并强制串行访问。
  下面主要讨论程序和磁盘IO冲突的限制。
  • 在页面上设置页面保护
    访问时先检查页面保护，如果页面被磁盘IO占用了，VM应该等待。但是更改磁盘上MMU保护是一个很昂贵的操作。
  • 弹性缓冲区（bounce buffer）
    类似程序控制IO，VM内程序将在bouce buffer上完成读写操作，然后定时写入磁盘。但是此时的读写仍由DMA控制，还是比程序控制IO更高效。
  • 故障接管（fail over）
    backup无法主动发起磁盘IO，所以当IO未结束的时候，master宕机，backup接管之后就无法接收到IO完成的信号，这需要客户机启动中止或重置过程来解决。
    这个时候由VM处理磁盘发送的错误信号。VM会在backup接管的过程中重新发布挂起的IO。由于消除了所有竞争，所以所有磁盘操作都是幂等的，可以重新发布以恢复。

网络IO

• 禁止异步网络优化
  普通的VM可以通过异步传输等优化策略尽可能地降低网络延迟地影响。但是由于从缓冲区更新的时间不确定，主从服务器很难同步，所以禁用。
  在网络进行异步传输的时候，实际并不会发送到网络，而只是陷入管理程序，由hypervisor来管理这些更新。
• 网络性能提升1：集群优化
  当VM以足够的比特率传输数据的时候，管理程序可以对每组数据执行一个传输陷阱。最优情况可以实现0陷阱。因为它可以将数据包作为接收数据包的一部分发送出去。也可以通过发布一组数据包的中断来减少管理程序和虚拟机的通信。
• 网络性能提升2：减少数据包延迟
  在日志通道的函数可以注册到TCP堆栈中使用类似Linux中的tasklet，来减少中断时间。

Design Alternatives

1. 共享和非共享磁盘

• 共享
  如果使用共享磁盘，backup将不会从共享磁盘上进行任何的读取和写入。这极大的降低了backup运行的时间。但是对log channel的带宽要求较高。
  • 磁盘读
    由于磁盘读可以看作是输入，所以可以通过日志通道进行传输而避免backup对磁盘读
  • 磁盘写
    磁盘写可以看作是VM对外界发送输出，所以必须遵守输出规则 添加延迟。
• 非共享
  master和backup的磁盘可以在本地也可以是网络磁盘。每次读写都需要进行。
  • 初始同步
    backup启动或重启，master和backup的VMotion操作，都需要将源磁盘和目标磁盘进行初始同步操作。
  • 脑裂处理
    仍然需要第三方来进行裁决。可使用集群中的其他服务器。

2. backup的磁盘读

backup读自己的磁盘能够避免日志通道带宽要求高。

• master需要等待backup读取成功
• master失败需要传递消息给backup，使backup也失败或忽略
• master对同一块的读写需要等待backup回复