经典分布式论文阅读：GFS

本文是GFS论文的学习笔记。GFS（Google File System）是谷歌针对分布式大数据处理而设计的大规模分布式文件系统。在设计GFS的时候主要考虑了应用场景的如下特性：

• 故障时常发生
• 文件十分巨大
• 大部分文件修改操做只是追加而不是覆盖
• 协同设计文件系统和应用能够增长系统的灵活性

系统概览

根据应用场景的特性，论文对文件系统作了如下设定：

• 系统由廉价的硬件构成，所以故障也是时有发生的事情
• 系统须要存储大量大文件
• 读取任务主要包括大数据量的流式读取和小数据量的随机读取
• 写入任务主要是大数据量的数据写入到文件末尾
• 系统须要实现相应功能，保证不一样客户端可以高效并行写入同一个文件
• 高带宽比低延迟更重要

GFS以目录树的形式组织文件，可是并无提供相似POSIX标准的文件系统操做。操做只要包含建立、删除、打开、关闭、读取、写入、快照和记录追加，其中快照操做用于快速复制一个文件或者目录，记录追加功能容许多个客户端并行追加数据到一个文件。

GFS的集群由一个主服务器（master）和多个块服务器（chunkserver）构成。每一个文件由文件块组成，文件块采用64位的块句柄进行惟一标识，原文中文件块大小为64MB，不过这是16年前的系统，如今64MB显得就过小了。

• 主服务器：保存了整个文件系统的元数据，元数据包括命名空间、访问控制信息、文件到块的映射和每一个文件块的位置，还要负责文件块租借管理、垃圾回收、文件块迁移，在运行过程当中经过心跳包和块服务器交换信息。
• 块服务器：保存文件块并向主服务器报告状态。
• 客户端：从主服务器获取元数据，而后再从块服务器读写文件数据。

文件块大小

文中表示，使用较大的文件块好处多多：

• 可以减小客户端向主服务器查询块位置的次数，下降了主服务器负载
• 在单个文件块内的操做变多，下降了网络负载
• 减小了主服务器须要保存的元数据的数量

固然，大文件块会致使小文件只存在一个文件块中，所以若是大量客户端对某个小文件的写入，那么负载会集中在某几台保存这个文件块服务器上，不过能够增长小文件的副本数量。

元数据

主服务器保存的元数据主要为：文件命名空间、文件到数据块的映射和数据块的位置。文件命名空间和文件到数据块的映射的数据须要持久化地写入到一个操做日志中，而数据块的位置经过和块服务器通讯得到。

这些元数据须要保存在主服务器的内存中来加速访问。主服务器在运行中会周期性地进行扫描，来完成数据块垃圾回收、故障块服务器数据重备份以及迁移数据块进行负载均衡。

操做日志记录了元数据地修改历史，主要用于故障恢复。显然，操做日志还须要在主服务器以外的远程服务器备份，全部操做必须在写入到操做日志以后执行。操做日志一般会结合检查点机制进行高效地备份。

一致性模型

在分布式文件系统，一个文件被修改以后会出现如下状态

	写入	追加
顺序成功执行	肯定	肯定+不一致
并行成功执行	一致+不肯定	肯定+不一致
失败	不一致	不一致

• 一致：全部客户端看到的数据块是同样的
• 肯定：文件知足一致性，而且每次修改都能知道具体修改的内容

一次成功的独立写入后的数据是一致的，成功的并行写入后的数据是一致，可是并不知道每一个修改的具体内容。修改操做包括写入和记录追加，记录追加保证至少一次是肯定的（详细见后续解释）。

GFS中文件肯定性和实时性有如下两个策略肯定：

1. 在全部副本上的修改保持一致的顺序
2. 使用块版原本识别块是否过时

客户端能够缓存块位置，缓存超时或者从新打开文件后即从新获取位置。GFS主要经过心跳判断块服务器是否正常，若是一个块在全部块服务器上找不到，那么即为丢失，访问的时候返回错误信息。

系统交互

租约和修改顺序

修改操做包括对文件元数据和内容的修改，例如写入和追加。GFS使用租约来保证多个副本之间修改顺序的一致性，主节点会将租约受权给某个副本，每一个租约有必定的有效期。

1. 客户端询问主服务器持有当前块租约的块服务器以及其余副本位置。若是目前没有租约，那么选择一个副本受权租约。
2. 主服务器回复全部副本位置和主副本标识。
3. 客户端将数据推送到全部副本上。
4. 当全部副本确认收到了数据以后，客户端给主副本发送写入请求。而后，主副本规定顺序执行修改操做。
5. 主副本将写入请求发送给其余全部从副本。每一个从副本按照相同顺序执行修改操做。
6. 从副本告知主副本完成了操做。
7. 主副本答复客户端

数据流

为了提升网络效率，数据流和控制流是互相分开的。控制流从客户端开始，到主副本，再到从副本，而数据线性地沿着一个块服务器串以管道的形式传输。块服务器的串从客户端开始，每次选择最近的块服务器做为下个节点。

原子记录追加

GFS提供了原子记录追加功能，将数据追加到文件末尾，并将新数据的起始位置返回给客户端。追加操做写入前，主副本会检查追加数据是否会超出最后一个块的大小。若是超出，那么填补剩余空间，将数据追加到新的块中，并将位置告知客户端。不然，直接将数据追加到最后一个块中。

当任何一个副本写入故障以后，客户端就会开始重试，那些故障时写入的数据区就产生了不一致，所以只能保证数据写入至少有一次是一致的。

快照

快照可以快速复制一个文件或者文件夹树，采用写时复制。

主节点操做

命名空间管理和锁定

GFS支持命名空间上的锁操做来保证串行。GFS维护了一个文件路径到元数据的映射，之前缀压缩的形式保存。每一个文件夹或者文件是命名空间树中的一个节点，每一个节点都有读写锁。

每一个操做以前须要获取一系列的锁。若是某个操做涉及/d1/d2/.../dn/leaf，首先须要获取文件夹/d1,/d1/d2,...,/d1/d2/.../dn上的读锁，然而获取文件上的读锁或者写锁/d1/d2/.../dn。例如，咱们将/home/user快照副本到/save/user上，那么能够给/home/user加写锁阻止其余程序在/home/user下建立新的文件。显然，锁须要按顺序获取来避免死锁。

副本存放

副本存放策略须要达到两个目的：

• 最大化数据可靠性和可用性
• 最大化网络带宽利用率

所以，副本须要存放到不一样的机架上，读取操做就能利用多个机架的带宽。可是，写入操做的数据流须要跨越多个机架，这是能够接受的权衡。

建立、从新复制和从新平衡

快副本在三种状况下建立：块建立、从新复制和从新平衡。

当块建立的时候，块服务器的选择规则为：

1. 选择磁盘利用率低于平均值的服务器
2. 限制最近建立块数量
3. 将块散布到不一样机架上

从新复制会发生在：块服务器失联、副本损坏、磁盘损坏、备份数量增长。块的复制有优先级，通常是距离备份目标数量的差距，以及优先处理正在阻塞程序的块。

从新平衡移动副本位置来平衡磁盘空间和负载，通常将副本从高磁盘利用率的服务器移动到低磁盘利用率的服务器。

垃圾回收

当应用程序要求删除一个文件时，主节点将文件重命名为一个隐藏名并记录时间，三天以后才物理删除。在物理删除以前，还可使用隐藏文件名读取以及撤销删除。运行期间，主节点会扫描那些没法到达的块并删除元数据，块服务器经过心跳得知再也不有用的块。总之，全部主节点不知道的副本都是“垃圾”。

垃圾回收相对当即删除有如下优点：

1. 在平常发生组件故障的分布式系统中，垃圾回收比较可靠
2. 把空间回收放入主节点后台活动中
3. 延迟回收给意外删除提供了回旋的余地

垃圾回收的坏处就是没法在空间紧张的时候快速腾出空间，不过能够修改回收副本和策略解决。

过时副本检测

GFS使用块版本识别副本是否过时，每次受权新的租约以后增长版本号，而后通知其余副本更新版本号。

容错和诊断

高可用

高可用主要经过快速恢复和副本来实现。

• 快速恢复：主节点和块服务器都可以快速恢复和启动。
• 块副本：每一个块被复制到不一样机架上的不一样块服务器上，固然还有其余建立副本的方式，例如相似于RAID3中的奇偶校验。
• 主节点副本：主节点的操做日志和检查点会被备份在多个机器上，日志中包括修改操做已经后台任务。当主节点崩溃以后，GFS使用检查点和操做日志启动新的主节点。另外，能够设置一些影子主节点来缓解主节点压力，影子主节点上的文件元数据会有短期的过时。

数据完整性

每一个块服务器使用校验和来检测数据完整性，每一个块服务器负责检测本身维护的数据。在读取数据时，块服务器首先检查数据完整性，若是检查出错则返回错误。在写入数据时候，须要计算更新校验和。在空闲时间，块服务器须要扫描和检查那些不活跃的数据块。

诊断工具

GFS主要采用诊断日志来进行问题排查、调试和性能分析。

参考文献

1. Ghemawat, Sanjay, Howard Gobioff, and Shun-Tak Leung. "The Google file system." (2003).