MIT6.824 Primary-Backup Replication论文导读

论文原文

背景

主从备份是实现可容错服务器的一种常用解决方案,在开启主动备份的系统中,备份服务器的状态需要时刻与主服务器保持一致,这样当主服务器失效的时候,备份服务器就能够立刻接管.实现主备间的状态同步方法:

• 状态转移(State transfer)

主服务器把所有状态变化都传给备份服务器,但是同步IO/内存要传输的数据量会比较大

• 备份状态机(Replicated State Machine)

把要备份的服务器看做是一个确定性状态机–主备以相同状态启动,导入相同输入,最后就会进入相同状态,给出相同输出.

虚拟机是运行在Hypervisor上的抽象机器,他可以方便地把非确定性的输入转变为确定性的输入.

Deterministic Replay

VMware实现的主从备份方法为VMWare vSphere Fault Tolerance,简称VMware FT,其基于VMware Deterministic Replay来实现.后者解决了以下两个问题:
1.正确获取所有输入事件以及他们的不确定性,以确保有足够信息能够重放这些事件
2.正确在备份虚拟机上重放这些输入事件与不确定性
前者(FT)则解决了性能不会受到影响的问题.

具体做法:
以日志形式记录主服务器接收到的输入,这些日志信息会由VMware FT传输到备份服务器并且被重放.

对于那些不确定的输入操作，Deterministic Replay 会记录足够多的信息，确保其在备份虚拟机上重新执行能够得到相同的状态和输出；而对于那些不确定的输入事件，如定时器、IO 操作完成中断等，Deterministic Replay 则会记录这些事件发生在哪个指令之后，这样在重放时备份服务器便能在指令流中相同的位置重放这些事件。

Fault Tolerance

整个架构由一主一备组成,两个虚拟机运行在两个不同的物理机上,物理机之间通过Logging 传输Deterministic Replay产生的日志信息,两个虚拟机都能访问一个Shared Disk

• 核心要求:

Output Requirement: if the backup VM ever tasks over after a failure of the primary, the backup VM will continue executing in a way that is entirely consistent with all outputs that the primary VM has sent to the external world.
输出要求：若在主虚拟机失效且由备份虚拟机接手后，备份虚拟机必须以一种与原主虚拟机已发送到外部的输出完全一致的方式运行

如果 Primary 宕机了，Backup 接替它的工作，Backup 之后向外界发出所有的 Output 要和 Primary 原本应当发送的一致.

简单解决方案:延迟主虚拟机的输出操作,直到备份虚拟机已经接受到至少足以让他重放至该输出操作的所有日志信息

• FT核心功能:

Output Rule: the primary VM may not send an output to the external world, until the backup VM has received and acknoledged the log entry associated with the operation producing the output.
输出规则：主虚拟机必须延后将输出发送到外部世界的动作，直到备份虚拟机已经接收并 ack 与产生该输出的操作相关联的日志信息

如上图所示,要确保backup收到本次output所有信息之后才能把output发送给外界.
注意延迟输出操作不代表主虚拟机完全暂停,只是把输出的操作延后.

但是这种方法不能保证 output 只发出一次，如果 primary 宕机了，backup 不能判断它是在发送了 output 之前还是之后宕机的，因此 backup 会再发送一次 output。但是这个问题很容易解决，因为：

1.output 是通过网络进行发送的，例如 TCP 之类的网络协议能够检测重复的数据包
2.即使 output 被发送了2次其实也没关系。如果 output 是一个写操作，它会在同一个位置写入两次，结果不会发生变化；如果 output 是读取操作，读的内容会被放入 bounce buffer（为了消除 DMA 竞争），数据会在 IO 中断之后被送到

主从切换

FT以两种方式来检测虚拟机节点的失效事件:

1.两个虚拟机所在的物理机会互相发送UDP心跳信息,判断对方是否存活
2.持续监控Logging Channel上的流量:由于周期定时中断的存在,主虚拟机发往备份虚拟机的日志和备份虚拟机发往主虚拟机的ack应该是持续不断的.信息中断意味着节点失效.

如果备份虚拟机失效,主虚拟机就会go live,即退出日志记录模式.不再产生和发送日志信息,并以普通方式继续运行.
如果主虚拟机失效,那么备份虚拟机就会在消费完Logging Channel中所有日志信息后升级为主虚拟机并且go llive,开始向外界发送输出

但是以上方案无法避免架构在主从虚拟机间发生网络隔离时候出现的裂脑综合征.
这指分布式系统中存在多个Master.

主从虚拟机之间网络不通会导致备份虚拟机误以为主虚拟机已经宕机,从而升级为主虚拟机,导致集群中存在两个主虚拟机.

解决方法:

无论主备,虚拟机在go live前首先会对存储在shared disk上的一个字段进行原子的test and set 如果操作成功就可以go live,否则意味着已经有另外一个虚拟机go live,它会立刻关闭自己.

具体实现细节

1.如何启动一个和Primary状态一样的Backup?

VMware Vmotion 操作能够将一台 VM 从一个 Server 完整的迁移到另一个 Server（只需要很短的中断），在该设计中的方法对 Vmotion 做了一点修改，不是进行迁移，而是直接克隆。

2.Logging Channel

VMware FT 的 Logging Channel 会在发送和接收端启用 Buffer 机制来减少网络传输对虚拟机执行速度的影响。主虚拟机会在 Buffer 满时暂停运行，而备份虚拟机则会在 Buffer 空时暂停运行

Case stduy

探讨Redis与MongoDB是怎么做主从备份的?
tbc

ref

论文总结
容错虚拟机分布式系统