P4

P4

Replication

1. 可以解决fail-stop faults，纯粹的硬件故障或者网络问题导致的偶尔发生的挂机错误
2. 不能解决软件bug和硬件缺陷导致的计算错误问题以及关联性故障（所有副本的机器由于同样的原因发生同样的故障比如地震）

methods

1. state transfer primary将自己状态发送给后备，以便在自己出问题时可以由后备机器接管

2. replication state machine: primary 发送给backup来自外部的操作，而不发送自己的状态，操作的代价远小于发送状态。这种方式也是有问题的，当某些指令会导致两台机器不一样时，比如获取当前的时间，会导致不一致，这时候具体计算操作的答案就由primary完成并发给back up。另外，如果在多核机器运行，结果就不会很理想，因为相同的指令们各自都会运行出不一致的操作，由于并行操作。

   some problems of replication state machine

   1. 同步，操作从Primary到back up会有一定延迟，如何让他们紧密同步
   2. primary出错然后切换到back up，这会有相当多的问题
   3. 当replication挂了，需要一个新的replication上线，这就不可避免地需要state transfer。但GFS（以及大多数fs）不会复制所有的东西，每一个细节，只是复制当前机器正在干的事，也就是应用程序级的数据。（我的理解是，这只是一个紧急的replication，临时使用，毕竟原来的机器还有硬盘，数据可以恢复）

VMWARE FT

有两个物理机器，上面都运行了虚拟机，虚拟机里面运行有我们的副本服务器，当一个client发送数据给primary时，primary的VMM（虚拟机监视器）会将请求给primary的操作系统的同时发给replication**（转发），然后replication会同时做这些操作。当有些随机数或者如上面methods 2 说的不一致工作，replication的VMM会过滤掉这样的操作请求并从log channel中获得primary的结果。当要反馈给client时，两台服务器都会发送一个应答数据包，但只有primary的VMM允许发送出去，replication的则不允许发送。（我感觉两台服务器都表现的和单一服务器一样，不知道是副本系统，于是由VMM来控制）**

VMM传入传出数据流的方式叫LOG CHANNEL，primary不断中断产生log entry给replication，当通信停止时，意味着Primary挂了，这个时候replication的VMM就会让replication如primary那样工作。接收第一手数据包和发送应答数据包。（虚拟机会有虚拟的MAC地址，这个时候replication会声明primary的地址是自己的，这样所有的client就开始向他发送数据）

Non-def events

1. 中断时机 给primary和replication发送指令集时，两者的操作系统都会产生中断，但是中断可能发生在指令流的位置不同导致状态不同，由此结果也不同。当primary有中断指令的log entry到达replication时，虚拟机会忽略并在特殊的CPU支持下安排相同的中断位置，伪造中断指令给backup 的操作系统。
2. 在不同电脑产生的结果不同的指令，例如随机数和当前时间
3. 多核并行，如果允许并行操作会有类似于进程异步的情况发生，导致结果不同。因为两个任务在两台机器拿到锁的顺序可能不同。于是虽然机器是多核的，但是虚拟机是单核的

为防止backup的执行状态比primary更快（这种情况由于primary中断指令到的迟了，backup已经执行了，backup会有一个buffer，只有当buffer有一个事件的时候才会执行，而时间只有primary生成才会发出，这样backup始终比primary晚一个事件

Bounce buffer

我们要让系统在特定时间点看到数据，所以NIC（网络接口）传过来的数据不能直接通过DMA的方式放入内存，系统不能直接在内存中看到数据。这意味着NIC会将数据放入虚拟机监视器的私有内存，然后给VMM发一个中断信号，这时候VMM会将primary挂起(当然，挂起的指令和位置会记住）（这样primary看不到内存），然后将整个数据包复制到primary的内存中。

之后再将指令和数据包发送给replication，replication会做和primary一样的事

output rule

primary输出相应包给client之后挂了，而replication没有收到这部分的log entry,这样replication中的数据就是旧数据，而接下来replication又要作为primary，这很危险。事实上，没有设计可以达到没有重复的标准。

解决办法就是output rule，规定replication buffer收到之后回一个ack确认信息给primary,primary才可以发送相应数据包给client**（数据保留在VMM，primary不会暂停）**。这同时也防止了primary执行太快。

但如果每个操作都这样，性能会大大降低，所以需要系统理解操作语义，比如只读操作不需要停顿等待，而写操作需要。

还有一个问题，当backup上线，处理完buffer的数据和client的请求后，会发送一个重复的数据包给client，这和primary发的一样，会产生异常。幸运的是，由于backup记得所有的TCP编号，会发送一个相同的TCP的数据包，这样client的TCP stack就可以识别然后丢弃。

split brain

当primary和replication之间的网络挂掉，两边都认为对方挂了，会导致split brain

解决办法是，引入外界仲裁服务器。事实上，磁盘是一个单独的服务器，当split brain发生时，两者会联系服务器，获得一个flag值，第一个联系到的就是新的Primary.