LEC3_GFS_Outline
为什么我们要阅读 GFS 论文?
- 分布式存储是关键的抽象概念
- 接口和语法应该是怎样的?
- 内部是怎么运行的?
- GFS 论文对6.824这门课的很多主题有指导意义
- 并行性能
- 容错
- 副本机制
- 一致性
- 优秀的系统论文,无论是从应用程序还是到网络的所有细节
- 工业界的成功设计
- 有影响力的开源实现 Hadoop HDFS
为什么分布式存储难?
- 高性能 -> 数据分布在多节点
- 多节点 -> 故障常态化
- 容错 -> 多副本
- 副本 -> 数据一致性问题
- 强一致性 -> 性能开销大
我们希望有什么样的一致性?
- 理想状态下与单节点服务相同
- 理想服务器下服务器会完美执行客户端发送的请求,即使多客户端同时发送
- 每次读取都会与之前写入的内容完全相同,即使服务器故障重启了
- 所有客户端读取到的数据都是相同的
假设 C1 C2同时写入,然后 C3 C4 读,他们读到的是1还是2?
C1: Wx1
C2: Wx2
C3: Rx?
C4: Rx?
有可能是1也有可能是2,但是它们必须看到一样的数,这就是强一致性模型,但是单节点的容错性很差
为了解决容错性而使用多副本导致实现强一致性很难.
一个简单但失效的副本如下
两个副本服务器 S1 S2
客户端并行发送写请求给两个服务器
客户端向其中一个发送读请求
上一个例子中,C1 C2 的写请求到达副本的顺序可能不同
如果 C3 读 S1 副本 那他可能读到 1
如果 C4 读 S2 副本 那他可能读到 2
又或者 S1 收到一个写请求,但是客户端在发送请求给 S2 之前崩了
这就不是强一致性 S1 S2的数据不一样了
确保副本之前的强一致性会有很大网络开销 很慢
在性能和一致性之前有一些折中的选择我们今天会介绍
GFS
背景
很多 Google 服务需要一个大型高效统一的存储系统
MR 爬虫 索引 日志存储及分析
在这些应用程序之间共享
自动分发每个文件到很多服务器节点及磁盘上
- 多客户端并行性能 -- mapreduce
- 单节点大文件
节点故障自动恢复
每次只部署在一个数据中心
只需服务 Google 应用和用户
针对大文件的顺序读取和追加
不是一个低时延的小项目
在2003年这篇论文有什么新颖的点?怎么说服 SOSP 接收这篇文章的?
- 不是基本的分布式,分区,容错思想
- 巨大的规模
- 工业界的实践
- 弱一致性的成功使用
整体结构
- 客户端 (库 RPC -- 但是对 UNIX 文件系统不可见)
- Coordinator 管理文件名 (元数据)
- 块节点存储 64MB 的块
- 大文件被分割成 64MB 的块,写入到块服务器上
- 每个块有3个副本
Coordinator 状态
- 内存中保存的表(为了速度,且必须小)
- 文件名对应一个块 handles 的列表 nv
- 块 handle 版本 nv
- 块节点的列表 v
- 是否 primary v
- 租约 v
nv为非易失性存储,追加写入磁盘日志
客户端 C 读取文件的步骤是怎样的?
- C 发送文件名和偏移量给 CO (如果没有缓存)
- CO 找到块句柄
- CO 回复块句柄和块服务器的列表,仅返回有最新版本的
- C 缓存接受的列表
- C 发送请求给最近的块节点,请求包含块句柄和偏移量
- 块节点从磁盘读取块文件返回给 C
客户端仅仅请求文件名和块句柄列表
- 客户端缓存文件名和块句柄信息的映射
- CO 不处理数据,所以不会有很大的负载
CO 怎么知道哪些块节点有哪些块?
启动的的时候轮询
客户端记录追加的步骤是怎样的?
- C 向 CO 请求文件最新的块
- CO 返回 C 主块 P 和副本
- C 发送数据给所有块服务器(不写入),等待所有快服务器的回应
- C 告诉 P 可以追加了
- P 校验租约是否到期,块空间是否足够
- P 计算出追加的偏移量 在文件末尾
- P 把数据写入块中(Linux 文件)
- P 告诉副本偏移量,告诉他们可以追加数据了
- P 等待所有副本回复,超时或者磁盘空间不足会回复 error
- P 告诉 C 成功或失败
- 如果失败 C 重试
GFS 为客户端提供哪些一致性保证?
需要以一种形式告诉应用程序如何使用 GFS
如果 p 告知 c 一个追加请求成功了,那么之后所有的读取者都会在这个文件的某个地方看到这个追加记录
这允许很多异常情况:不同客户端可能看到此条数据的不同记录方式,可能会看到重复数据,可能会看到错误写入的数据,GFS 应用程序要为这些做好准备
想想 GFS 是怎么实现它所承诺的?
看看它对各种故障的处理:
崩溃,崩溃+重启,崩溃+替换,消息丢失,分区
GFS是怎么处理每种故障的?
如果客户端在追加记录的时候失败了怎么办?
如果一个客户端缓存了一个错误的主块怎么办?
如果客户端缓存了一个块的过期的服务器列表呢?
CO 崩溃重启会不会导致它忘记这个文件?或者忘了哪些块服务器存有哪些块
两个客户端在完全相同的时间追加记录,他们会不会覆盖对面的记录?
假设一个从节点没有收到主节点发送的追加命令
- 由于临时网络故障
- 如果客户端从这个节点读取数据会怎样?
如果主节点 S1 还活着并且和客户端通信,但是 CO 和 S1 之间网络故障怎么办?
- 网络分区
- CO 会选一个新的主节点吗?
- 现在会有两个主节点吗?
- 所以现在会追加到一个主节点然后从另一个读取吗?这不是会破坏一致性吗?
- 这就是脑裂
主节点在向从节点发送追加请求之前崩溃了怎么办?
- 从节点在没有收到这个追加指令会被选为新主节点吗?
块服务器 S4 有一个老的过期的块副本是离线的.主从节点都崩溃了.
- S4 在主从节点恢复之前恢复了.CO 会挑 S4 作为主节点吗?
- 会选择老的数据作为主块还是根本没有副本?
CO 怎么设置一个块为主块?
客户端要写入一个块,但是这个块不是主块或者租约过期
CO 会轮询块服务器他们有哪些块以及哪些版本
- 如果块服务器没有最新版本 报错
- 从含有最新版本的块服务器上选择主块
- 递增版本号 写入磁盘
- 告诉主块和副本他们新的版本号
- 副本写入新版本号到磁盘
如果副本经常写入失败,主块怎么办?
可能是崩溃,磁盘空间不足或者磁盘损坏
保持错误的客户请求?
还是让 CO 声明一组新的服务器和版本?
这篇论文没有这些描述
如果主块租约到期,CO 分配一个新主块,这个主块会有以前那个主块的最新数据吗?
如果 CO 完全崩溃了怎么办?
替代者会知道这个 CO 上保存的信息吗?
如每个块的版本,哪个是主块以及租约的到期时间.
谁决定 CO 的生死?以及是否要替换它?
CO 的副本能不能一直 ping CO,如果中断了就替代它.
如果整个机房断电然后恢复,服务器重启会发生什么?
假设 CO 向创建一个新的块副本,也许是因为副本数量太少了.
假设这个块是文件的最后一个块,而且正在追加数据,新的副本怎么确保数据同步,毕竟这个新副本还没有设置为 secondaries
有什么情况 GFS 不能履行它所保证的?
如追加成功了,但是读取不到数据.
所有的 CO 副本永久失效(磁盘永久失效).
可能更糟:结果可能是没有回应,而不是回应错误数据,故障停止
所有持有该块的块服务器磁盘永久失效.
- 同样的,故障停止,可能不是最坏结果
CPU 内存 网络或者磁盘产生异常值.
- 校验和可以解决部分 但不是全部
时间不同步导致租约没有正常工作怎么办?
- 因此可能有多个主块,读一个,写另一个
要怎么才能不出现异常,也就是强一致性
也就是说所有的客户端读到的文件内容都是相同的
这太难了,可以考虑以下几点
- 所有副本都应该执行原子性的写入,或者可以缓存写入,在所有副本都缓存成功之后再执行写入
- 主块应该检测副块的重复写入
- 如果主块崩了,一些副本可能会丢失最后的几个写入操作,新推举的主块应该与副本通信找到丢失的操作,然后同步
- 客户端必须防止从过期的副本中读取数据,也许副本有租约或者客户端知道块版本,或者从 CO 获取版本和租约
性能
04年的性能没有参考价值
值得考虑的一些问题
- 怎么很好的支持小文件
- 怎么支持十亿数量级的文件
- GFS 能用在广域网文件系统?
-
- 副本存在不同的城市
-
- 所有的副本在一个数据中心容错性不是很好
- GFS 从故障中恢复需要多长时间?
-
- 一个块服务器故障,或者一个 CO 故障
- GFS 如何应对缓慢的块服务器
文件数量是最大的问题
- 最终的数字增长到了表2中的1000倍!
- 很难装入协调器的RAM
- 协调器对所有文件/块的GC扫描很慢
- 1000多个客户对协调器的CPU负荷太大
- 应用程序必须被设计来应对GFS的语义和限制
- 协调器的故障切换最初完全是手工操作，需要10多分钟的时间
- BigTable是解决许多小文件问题的一个答案
- 而Colossus显然是将协调器数据分散到许多协调器上的。
摘要
性能,容错,一致性的专项研究.支持 MapReduce 的专项应用.
good ideas:
- 全球集群文件系统作为通用基础设施
- 将命名（协调器）与存储（chunkserver）分开
- 分片以实现并行吞吐量
- 巨大的文件/分块以减少开销
- 主要的写入顺序
- 防止脑裂的 chunkserver 初代的租约
not so great:
- 单个协调器的性能
- 内存和CPU耗尽
- 分块服务器对小文件的效率不高
- 缺乏自动故障转移到协调者副本的功能
- 也许一致性太宽松了
浙公网安备 33010602011771号