《The Google File System》论文阅读笔记——GFS设计原理

1、设计预期

设计预期每每针对系统的应用场景，是系统在不一样选择间作balance的重要依据，对于理解GFS在系统设计时为什么作出现有的决策相当重要。因此咱们应重点关注：

• 失效是常态
• 主要针对大文件
• 读操做：大规模流式读取、小规模随机读取
• 写操做：大规模顺序追加写，写入后不多修改
• 高效明肯定义的并行追加写
• 稳定高效地网络带宽

2、总体设计

一、系统架构

GFS主要由如下三个系统模块组成：

• Master：管理元数据、总体协调系统活动
• ChunkServer：存储维护数据块（Chunk），读写文件数据
• Client：向Master请求元数据，并根据元数据访问对应ChunkServer的Chunk

二、设计要点

1）Chunk尺寸

因为GFS主要面向大文件存储和大规模读写操做，因此其选择了远大于通常文件系统的64MB的Chunk尺寸。

好处：

• 减小元数据量，便于客户端预读缓存，减小客户端访问Master的次数，减少Master负载；
• 减小元数据量，Master能够将元数据放在内存中；
• 客户端短期内工做集落在同一Chunk上的几率更高，减小客户端访问不一样ChunkServer创建TCP链接的次数，从而减小网络负载。

坏处：

• 易产生数据碎片；
• 小文件占用Chunk少，对小文件的频繁访问会集中在少数ChunkServer上，从而产生小文件访问热点。

可能的解决方案：

• 增大小文件复制参数；
• 客户端间互传数据。

2）元数据存储方式

Master存储的元数据包括：命名空间、文件和Chunk的对应关系、Chunk位置信息。

命名空间、文件和Chunk的对应关系的存储方式：

• 内存：真实数据；
• 磁盘：按期Checkpoint（压缩B树）和上次CheckPoint后的操做日志；
• 多机备份：Checkpoint文件和操做日志。

Chunk位置信息的存储方式：

• 内存：真实数据
• 磁盘：不持久存储

系统启动和新Chunk服务器加入时从Chunk服务器获取。避免了Master与ChunkServer之间的数据同步，只有Chunk服务器才能最终肯定Chunk是否在它的硬盘上。

3）一致性模型

命名空间修改：原子性和正确性

文件数据修改（以后详细解释）：

• 修改失败：不一致
• 串行随机写：一致且已定义
• 并行随机写：非原子写，一致但未定义
• 串行/并行追加写（推荐）：少许不一致，保证已定义

3、详细设计

一、系统交互设计

1）重要原则

最小化全部操做与Master的交互。

2）缓存机制

最小化读取操做与Master的交互：

客户端访问Chunk前从Master获取元数据的过程当中，会预取和缓存部分Chunk的元数据，从而减小与Master的交互。

2）租约机制

最小化变动操做与Master的交互：

Master收到变动操做请求后

• 选择一个Chunk副本发放定时租约做为主Chunk并返回给客户端；
• 客户端与主Chunk进行通讯进行变动操做；
• 租约超时前，对该Chunk的变动操做都由主Chunk进行序列化控制。

3）数据流与控制流分离

数据推送与控制操做同时进行。

数据流：管道方式按最优化的Chunk服务器链推送，以最大化带宽，最小化延时（全双工交换网络，每台机器进出带宽最大化）；

控制流：

• 主ChunkServer肯定二级副本接收完毕后，对全部变动操做分配连续序列号（序号肯定操做顺序）；
• 按序修改本地数据；
• 请求二级副本按序修改；
• 全部副本修改完成成功，不然失败重作。

4）非原子写操做

一次写入数据过大，可能被客户端分为多个写操做，这些写操做序号可能不连续，被其余并发写操做打断或覆盖，出现数据一致但未定义的状态。

5）原子记录追加

追加写时GFS推荐的写入方式，应重点研究。

a. 原子记录追加：客户端指定写入数据，GFS返回真实写入偏移量。

b. 追加写的过程：

• 追加操做会使Chunk超过尺寸
  • 填充当前Chunk；
  • 通知二级副本作一样操做；
  • 通知客户机向新Chunk追加；
• 追加操做不会使Chunk超过尺寸
  • 主Chunk追加数据；
  • 通知二级副本写在相同位置上；
  • 成功 - 返回偏移； 失败 - 再次操做。

c. 追加结果：失败的追加操做可能致使Chunk间字节级别不一致，但当最终追加成功后，全部副本在返回的偏移位置一致已定义，以后的追加操做不受影响。以下图所示：

d. 冗余数据处理：对于追加写产生的冗余数据

• Chunk尺寸不足时的填充数据
• 追加失败时产生的重复内容

可在插入数据时附带记录级别的Checksum或惟一标识符，在客户端读取数据时进行校验过滤。

6）快照

使用COW技术，瞬间完成。快照实现的过程：

• 收回文件全部Chunk的租约；
• 操做元数据完成元数据拷贝；
• 客户端要写入该文件的Chunk时，Master通知该Chunk所在ChunkServer进行本地拷贝；
• 发放租约给拷贝Chunk；
• 返回拷贝Chunk的位置信息。

二、Master节点设计

1）名称空间管理

多操做并行，名称空间锁保证执行顺序，文件操做需得到父目录读锁和目标文件/目录写锁。

2）副本位置

Chunk跨机架分布：

好处 -

• 防止整个机架破坏形成数据失效
• 综合利用多机架整合带宽（机架出入带宽可能小于机架上机器的总带宽，因此应最大化每台机架的带宽利用率）；

坏处 - 写操做需跨机架通讯。

3）Chunk管理

a. 建立操做，主要考虑：

• 平衡硬盘使用率；
• 限制单ChunkServer短时间建立次数（建立开销虽小，但每次建立每每意味着大量的后续写入）；
• 跨机架分布。

b. 重复制，即有效副本不足时，经过复制增长副本数。优先考虑：

• 副本数量和复制因数相差多的；
• live（未被删除）文件的；
• 阻塞客户机处理的

Chunk进行重复制。策略与建立相似。

c. 重负载均衡，经过调整副本位置，平衡格机负载。策略与建立相似。新ChunkServer将被逐渐填满。

4）垃圾回收

惰性回收空间：删除操做仅在文件名后添加隐藏标记，Master在常规扫描中删除超时隐藏文件的元数据，并通知对应ChunkServer删除Chunk。

好处 -

• 与建立失败的无效Chunk一致的处理方式；
• 批量执行开销分散，Master相对空闲时进行；
• 删除操做必定时间内可逆转。

坏处 - 不便于用户进行存储空间调优。

解决方案 - 再次删除加速回收，不一样命名空间不一样复制回收策略。

5）过时失效副本检测

过时检测：Master维护Chunk级别版本号，新租约增长Chunk版本号，并通知全部副本更新版本号，过时Chunk会因版本号过旧被检测。

三、容错机制设计

1）高可用性

主要的提升可用性的机制：

• 组件快速恢复
• Chunk复制
• Master服务器复制
  • Checkpoint和操做日志多机备份；
  • Master进程失效重启，硬件失效则新机器重启Master进程；
  • “影子”Master，经过操做日志“模仿”主Master操做，元数据版本稍慢。做用 - 分担必定负载、失效期暂时接管。

2）数据完整性

ChunkServer独立维护CheckSum检验副本完整性。缘由：

• 跨Chunk服务器比较副本开销大；
• 追加操做形成的的byte级别不一致，致使没法经过比较副本判断完整性。

Chunk读取和Chunk服务器空闲时，进行CheckSum校验，发现损坏Chunk上报Master，进行重复制。

Checksum校验的开销：

• Checksum读取开销；
• Checksum校验计算开销。

但总体开销能够接受，特别是对追加写操做。

覆盖写与追加写的Checksum计算开销比较。二者的关键区别在于不完整块的CheckSum计算：

• 追加写 - 对最后一个不完整块，在写入后进行增量的CheckSum计算。New CheckSum由Old CheckSum和新数据算出，未对原有数据从新计算，原有数据损坏，依然能够发现；
• 覆盖写 - 对第一个和最后一个不完整块，在写以前进行CheckSum校验。不然，覆盖写只能从新对整块计算CheckSum，若写操做未覆盖部分存在损坏数据，新CheckSum将从包含损坏数据的Chunk算出，以后再也没法校验出该损坏数据。

4、总结

本文是我在阅读论文《The Google File System》时记下的笔记，对论文的各部份内容进行了梳理。

系统设计过程每每就是在各类因素间根据目标需求权衡利弊的过程。分布式系统设计须要权衡的问题存在许多共性，GFS在设计过程当中基于分布式环境的特色，作的许多重要决策对于其余分布式系统开发具备指导性的意义。

因此，我尽力把以为有趣的设计要点进行了提炼，并对重要细节进行了重点分析，特别是各类权衡带来的好处和坏处，以及针对最终选择带来的坏处的弥补方案。

若是这篇文章在梳理本身思路的同时，能为感兴趣的朋友们提供一点点帮助，那也算作了件有意义的事情了！