MIT 6.824 lec4 VMware FT
4.1
- 复制是一个实现容错方法，容错本身是为了提供高可用性
- 复制能够处理fail-stop的故障，也即某些东西出现了故障，那么它们就会单纯的停止运行
- 但是复制不能够处理软件本身具有的bug与硬件缺陷
- 副本之间会发生的错误不能够存在关联性
4.2 状态转移和复制状态机
- 状态转移，就是将Primary副本的内容复制给Backup副本，优化点是每次不用复制所有的Primary内存内容，而是拷贝每次上一次同步之后变更了的内存
- 复制状态机是，每台主机都是顺序执行的，只有外部事件发生了干预才会发生变化，那么Primary主机只需要将外部事件的干预发送给Backup，也就是只传递外部操作
- 外部操作相较于服务器的状态而言，要小的多。但是复制状态机会更复杂，其对于计算机的运行做了更多假设
- 对于随机操作，在复制状态机中会如何处理?
- 复制状态机的一些问题
- 在复制状态机中，需要关注Primary和Backup之间的同步频率
- Primary发生了故障，会切换到新的Priamry，客户端必然会知道这个变化的发生
- 如果Primary发生了故障，选择新的Primary，之后还需要添加新的副本，添加的新副本需要复制当前新Primary的所有内容
- GFS的复制是应用程序级别的操作，而VMware FT的复制是机器级别的复制，缺点是效率低，但是你可以将任何现有的软件，甚至你不需要有这些软件的源代码，你也不需要理解这些软件是如何运行的，在某些限制条件下，你就可以将这些软件运行在VMware FT的这套复制方案上。
4.3 VMware FT工作原理
- 通过虚拟监控器(VMM, Virtual Machine Monitor)可以在一个硬件上启动多个os
- VMware FT需要将Primary和Backup运行在两个不同的物理服务器上，在两台不同的物理服务器上的虚拟机中运行同样的服务器程序
- 什么魔法？
4.4 非确定性事件 (Non-Deterministic Events)
- 一些不由计算机当前内存决定的指令，那么这些指令在Primary和Backup中的运行结果就会不一致，这些指令被称为非确定性事件，那么需要考虑如何将这些事件在Primary和Backup之间同步，可以分为：
- 客户端输入，也就是网络数据包，当网络数据包送到时，网卡的DMA会将网络数据包的内容拷贝到内存(Ring Buffer)中,之后就是中断，CPU去处理中断，那么需要保证Primary和Backup处理这个中断的过程是一致的，也就是在相同的时间，相同的位置触发
- 怪异指令，这类指令在不同的计算机上的行为不一致：
- 随机数生成器，
- 获取当前时间，在不同的事件调用会的得到不同的结果
- 获取计算机的唯一ID，比如CPU的ID和序列号
- CPU的并发
- Log Channel中主要有三样东西：1.事件发生的指令序号 2. 日志条目的类型 3. 数据，比如网络数据包，或者怪异指令在Primary上的执行结果
4.5 输出控制
- 对于Primary的输出，由于要保证副本的可靠性，那么需要将其接收到的网络包的修改，发送给Backup之后，Backup确认之后，才会将输出发送给客户端。这里也就是保证了客户端在看到对于请求的响应之前Backup可看到了这个请求。也就是说需要保证Primary的执行不能超过Backup太多(虽然这样非常消耗性能，所以这种复制只适合低请求量的服务)，因为如果Primary超前了并且又故障了，对应的就是Backup的状态落后于客户端
- 啥意思鸭？
4.6 重复输出
- Primary和Backup有相同的IP地址？
4.7 Test-and-Set服务
- 通过第三方的Test-and-Set服务来来决定两个副本中谁是Primary，解决脑裂问题.应该也需要给Primary发送心跳包，检测当前的Primary是否还活着
