6.824-lecture4

最新推荐文章于 2020-10-18 22:48:23 发布

qq_34673038

最新推荐文章于 2020-10-18 22:48:23 发布

阅读量157

点赞数

分类专栏：分布式系统

分布式系统专栏收录该内容

13 篇文章 1 订阅

订阅专栏

主备复制

主题

容错的主从复制
VMware FT的案例研究这个主意的实现版本

容错

我们想要一个一个服务出现错误也能继续运行
一些理想的模型
- 高可用：尽管一些错误，但是仍然能用
- 强一致性：看起来就像单机服务
- client透明
- server 软件透明
- 有效率

我们需要处理哪些错误？

崩溃
独立的失败
网络丢包
网络分区

但不包括

执行不正确
不相关的错误
配置错误
恶意代码

行为

可用 (如服务器崩溃)
等待(网络错误)
永远停止(多个服务器崩溃)
故障(软硬件错误，软件故障)

核心思想：冗余

多个服务器
每个复制保持服务所需要的状态
一个复制失败了，其他的还能顶上去

例子：容错的mapreduce 主节点

lab1 workers是容错的，但是主节点不是，有单点故障
如果我们有两个master,会有失败吗
状态
- worker list
- 哪个job工作
- 呢个worker idle
- tcp 链接状态
- 程序内存和栈
- cpu寄存器

大问题

要复制什么状态？
主服务器是否必须等待备份？
什么时候切换到备份？
转换时是否可见异常？
如何加快更换速度？

两个主要方法

状态转移
“主”副本执行服务
主服务器将[新]状态发送到备份
复制状态机
所有副本执行所有操作
如果相同的开始状态，
相同的操作
相同的顺序
确定性的
然后相同的结束状态

状态转移更简单

但是状态可能很大，转移缓慢
VM-FT使用复制状态机

复制状态机可以更高效

如果操作比数据小
但是复杂操作才能正确
实验2/3/4使用复制状态机

在什么级别定义复制状态机？

K / V put gey？
“应用程序级” RSM
通常需要修改服务器和客户端
可以有效率主服务器仅将高级操作发送到备份
x86指令？
可能允许我们复制任何不带修改的现有服务器！
但需要更详细的主/备份同步
而且我们必须处理中断，DMA，奇怪的x86指令

The design of a Practical System for Fault-Tolerant Virtual Machines
Scales, Nelson, and Venkitachalam, SIGOPS OSR Vol 44, No 4, Dec 2010

非常雄心勃勃的系统：

目标：现有服务器软件的容错
目标：client不应注意到失败
目标：无需更改客户端或服务器软件
很有野心！

总览
[应用程序，操作系统，VM-FT，共享磁盘，网络，客户端]
单词：

虚拟机监控程序监视器 VMM（虚拟机监视器）
应用程序和操作系统是在虚拟机中运行的“宿主”
两台计算机，主计算机和备用计算机
共享磁盘用于持久存储
共享，这样可以更快地创建新备份
主数据库通过日志记录通道将所有输入发送到备份

为什么这个想法行得通？

这是一个复制状态机
具有相同初始状态的主启动和备份启动（内存，磁盘文件）
相同的指令，相同的输入->相同的执行
在所有其他条件相同的情况下，主数据库和备份数据库将保持不变

我们必须注意哪些差异来源？

保证许多指令在主要和备份上执行完全相同的操作
只要内存+寄存器是相同的，我们就通过归纳法来假设。

什么时候在主数据库上执行与备份上可能有所不同？

来自外部世界（网络）的输入。
从存储服务器读取的数据。
中断时间。
不是纯粹的状态功能的指令，例如循环计数器。
竞争

分歧的例子？

它们听起来都像是“如果主数据库发生故障，客户端将看到备份中出现的存储不一致”。
锁定服务器将锁定授予客户端C1，拒绝来自C2的后续请求。
主服务器和备用服务器最好在输入顺序上达成共识！
否则，主服务器将失败，备份现在会告诉客户端C2持有该锁。
锁定服务器在一分钟后撤消锁定。
假设C1保持锁定，并且分钟几乎精确到了。
C2请求锁定。
Primary可能会在计时器中断之前立即看到C2的请求，拒绝。
定时器中断后，准时备份可能会看到C2的请求。
因此：备份必须在指令流的同一点以相同的顺序看到相同的事件。

示例：计时器中断
目标：主要和备份应该在执行的完全相同的点看到中断
ie 同一对已执行指令之间
主：
FT产生定时器中断
FT从CPU读取指令号
FT在记录通道上发送“指令X的计时器中断”
FT向主节点传递中断，然后恢复
（这依靠CPU的特殊支持来计数指令，在X之后中断）
备份：
忽略自己的计时器硬件
FT在“备份”到指令X之前*看到日志条目
FT告诉CPU在指令X处中断
FT模拟计时器中断，恢复备份

示例：磁盘/网络输入
主要和备用两者都要求硬件读取
FT拦截，在备份时忽略，在主节点上给出真实的硬件
主：
FT告诉硬件将DMA数据存入FT的专用“反弹缓冲区”
在一些时候，硬件执行DMA，然后中断
FT收到中断
FT暂停了主要
FT将退回缓冲区复制到主数据库的内存中
FT模拟主要中断，然后恢复
FT将数据和指令＃发送到备份
备份：
FT从日志流中获取数据和指令＃
FT告诉CPU在指令X处中断
FT在中断期间复制数据

为什么需要跳动缓冲区bounce buffer？
也就是说，为什么要等到主/备份未执行后再复制数据？
我们希望数据在内存中的同一位置出现
执行主数据库和备份数据库。
否则它们可能会分歧。

请注意，备份必须滞后一个事件（一个日志条目）
假设primary在指令X之后得到中断或输入
如果备份已在X以后执行，则无法正确处理输入
因此，备份FT在看到第一个日志条目之前根本无法开始执行
然后，它仅执行该日志条目中的指令＃
并等待下一个日志条目，然后重新启动备份

示例：非功能指令
即使主数据库和备份数据库具有相同的内存/寄存器，
一些指令仍然执行不同
例如，读取当前时间或周期数或处理器序列号
主：
FT将CPU设置为在主要执行该指令时中断
FT执行指令并记录结果
将结果和指令＃发送到备份
备份：
备份在尝试执行该指令时也会中断
FT提供了primary获得的价值

磁盘/网络输出如何？
主和备用都执行输出指令
Primary的FT实际上执行输出
备份的FT放弃输出

但是：论文的“输出规则”（第2.2节）说，主要的首要的
在产生输出时告诉备份，并延迟输出直到
备份说它已经收到日志条目。

为什么要使用输出规则？
假设没有输出规则。
主服务器立即发出输出。
假设主要对象看到输入I1 I2 I3，然后发出输出。
备份已在日志上收到I1和I2。
主要崩溃，网络丢失了I3的数据包。
现在，备份无需处理I3就可以上线。
但是某些客户端看到的输出反映了执行I3的主要对象。
这样，如果客户端再次与服务对话，则该客户端可能会看到异常状态。
因此：主节点在知道备份之前不会发出输出
已经看到所有输入，直到该输出为止。

输出规则很重要
在所有复制系统中以某种形式发生
严重限制性能性能的敌人
特定于应用程序的智能区域
例如。也许不需要主服务器等待回复只读操作
FT没有应用级知识，必须保守

问：如果主服务器在从备份获得ACK后立即崩溃，
但是在主要发出输出之前？
这是否意味着将永远不会生成输出？

答：这是当主节点发生故障而备份接管时发生的情况。
备份从主数据库获取一些日志条目。
备份继续执行那些输出被抑制的日志条目。
在最后一个日志条目之后，备份开始发出输出
在我们的示例中，最后一个日志条目是I3
因此，在输入I3之后，客户端将开始发出输出
因此，它将发出主要节点未能发出的输出

问：但是如果主服务器在发出输出之后崩溃了怎么办？
备份会在第二秒内发出输出吗？

答：可以。
对于TCP，单击“确定”，因为接收者将忽略重复的序列号。
可以写入共享磁盘，因为备份会将相同的数据写入相同的块＃。

转换时复制输出在复制系统中非常普遍
客户＆c并非总是可能忽略重复项
例如，如果输出是从ATM机上赚钱

问：FT可以应对网络分区吗？它会遭受脑裂吗？
例如，如果主服务器和备用服务器都认为对方故障了。
他们俩都会“生活”吗？

答：共享磁盘打破了常规。
共享磁盘服务器支持原子测试和设置。
主/备份中只有一个可以成功测试并设置。
如果只有一个人还活着，它将赢得测试和设定并开始上线。
如果两者都尝试，一个将失败并停止。

共享存储是单点故障
如果共享存储关闭，则服务关闭
也许他们想到了一个复制的存储系统

问：为什么他们不支持多核？

绩效（表1）
FT/Non-FT：令人印象深刻！
有点慢
日志带宽
直接反映磁盘读取率+网络输入率
对于MySQL，速度为18 Mbit / s
这些数字对我来说似乎很低
应用程序可以至少400 Mbps的速度读取磁盘
因此他们的应用程序不是很占用磁盘

FT何时会具有吸引力？
关键但强度较低的服务，例如名称服务器。
软件不方便修改的服务。