GFS Google File System 读书笔记

针对Google应用的问题与需求设计

1、在廉价、不可靠计算机上存储大量的数据，这使得节点失效是常态而不是异常。GFS 必须能够较高容错、持续监控自身的状态，同时还要能从节点失效中快速恢复；

2、纵观Google的内部应用，数据访问有以下特点：

1. 存储内容以大文件为主。系统需要存储的内容在通常情况下由数量不多的大文件构成，每个文件通常有几百 MB 甚至是几 GB 的大小；
2. 数据访问特点多为顺序访问，比较常见的场景是数据分析，应用程序会顺序遍历数据文件，产生顺序读行为；
3. 多客户端并发追加场景很常见，极少有随机写行为；
4. 一次写入，多次读取，例如互联网上的网页存储。

需要对存储的文件类型和访问模式进行优化

3、持久的高吞吐量、低延迟

…

GFS体系架构

GFS集群由一个Master节点和若干个Chunkserver组成。

文件以Chunk为单位存储（大数据块）

• 大小为固定的64MB
• 通过复制提高数据可靠性
• 每个Chunk有3个以上的副本存储在不同的Chunkservers

Master负责维护整个集群的元数据

• 文件与 Chunk 的 Namespace
• 文件与 Chunk 之间的映射关系
• 每个 Chunk Replica 所在的位置

提供系统API接口，但不是传统的POSIX API

• 简化问题，针对Google应用
• 添加了snapshot和record append操作

客户端和ChunkServer都不缓存文件数据

• 大数据集合、流数据读操作获益

Master

The master executes all namespace operations. In addition, it manages chunk replicas throughout the system: it makes placement decisions, creates new chunks and hence replicas, and coordinates various system-wide activities to keep chunks fully replicated, to balance load across all the chunkservers, and to reclaim unused storage.

Namespace Management and Locking

we allow multiple operations to be active and use locks over regions of the namespace to ensure proper serialization.

GFS logically represents its namespace as a lookup table mapping full pathnames to metadata. With prefix compression, this table can be efficiently represented in memory. Each node in the namespace tree (either an absolute file name or an absolute directory name) has an associated read-write lock.

通过使用 命名空间锁 来保证 master 并发操作的正确顺序 。

为了管理来自不同客户端的并发请求对 Namespace 的修改，Master 会为 Namespace 中的每个文件和目录都分配一个读写锁（Read-Write Lock）。所有 Master 操作在执行前都会需要先获取一系列的锁。由此，对不同 Namespace 区域的并发请求便可以同时进行。

由于大量的读写锁可能会造成较高的内存占用，这些锁会在实际需要时才进行创建，并在不再需要时被销毁。此外，所有的锁获取操作也会按照一个相同的顺序进行，以避免发生死锁：锁首先按 Namespace 树的层级排列，同一层级内则以路径名字典序排列。

Chunk and Chunk Replica

Replica Placement

The chunk replica placement policy serves two purposes: maximize data reliability and availability, and maximize network bandwidth utilization.

为了保证足够的可靠性以及写入的高效性，GFS在创建chunk时副本位置的选择算法：

1. 选择存储空间利用率最低的节点和磁盘；

2. 选择最近一段时间内新建chunk数量较少的节点和磁盘；

   保证一个节点/磁盘不会被频繁新建chunk（新建完接下来就是数据写入了），否则很容易沦为热点，导致磁盘IO和网络带宽被占满，影响效率。

3. 将多个副本分散在不同的节点上（负载均衡）。

Creation

(1) We want to place new replicas on chunkservers with below-average diskspace utilization. Over time this will equalize disk utilization across chunkservers.

(2) We want to limit the number of “recent” creations on each chunkserver. Although creation itself is cheap, it reliably predicts imminent heavy write traffic because chunks are created when demanded by writes, and in our append-once-read-many work load they typically become practically read-only once they have been completely written.

(3) As discussed above, we want to spread replicas of a chunk across racks.

master 创建一个 chunk 时，会选择在哪里放置初始的空的副本，主要考虑几个因素：

• 在低于平均硬盘使用率的 chunkserver 上存储新的副本
• 希望限制在每个 chunkserver 上 最近 的 chunk 创建操作的次数
• 希望把 chunk 分布在多个节点上

Re-Replication

The master re-replicates a chunkas soon as the number of available replicas falls below a user-specified goal.

当 chunk 的有效副本数量少于用户指定的复制因素的时候（ 默认为 3 ），master 会重新复制它 。

可能的原因有：chunkserver 不可用了、chunkserver 上副本损坏、chunkserver 磁盘不可用或 chunk 副本的复制因素被提高了 。

优先级因素：优先复制 副本数量和复制因素相差多的 、活跃的而非刚被删除的文件 、正在阻塞 client 程序的chunk。

Rebalancing

Finally, the master rebalances replicas periodically: it examines the current replica distribution and moves replicas for better diskspace and load balancing. Also through this process, the master gradually fills up a new chunkserver rather than instantly swamps it with new chunks and the heavy write traffic that comes with them.

master 服务器周期性地对副本进行 重新负载均衡 ：它检查当前的副本分布情况，然后移动副本以便更好地利用硬盘空间、更有效地进行负载均衡 。

若加入了新的 chunkserver ，master 会通过重新负载均衡的方式逐渐填满这个新的 chunkserver ，而不是短时间内填满它（可能导致过载）。

Chunk Lease

租约：GFS在chunk多副本之间选择出一个主副本，称为 primary，由主副本来协调客户端的写入，保证多副本之间维持一个全局统一的更新顺序。

租约是由Master分配给chunk的某个副本的锁。持有租约的副本方可处理客户端的更新请求，客户端更新数据前会从Master获取该chunk持有租约的副本并向该副本发送更新请求。

租约本质上是一种有时间限制的锁：租约的持有者（chunk的某个副本）需要定期向Master申请续约。如果超过租约的期限，那么该租约会被强制收回并重新分配给其他副本。

设置 primary 的 目的 ：为了最小化 master 的管理负担。

Garbage Collection

After a file is deleted, GFS does not immediately reclaim the available physical storage. It does so only lazily during regular garbage collection at both the file and chunk levels. We find that this approach makes the system much simpler and more reliable.

GFS 在文件删除后不会立刻进行回收可用的物理空间，GFS 空间回收采用惰性的策略，只在文件和 chunk 级的常规垃圾收集时进行 。

当一个文件被应用程序删除时，master 立即把删除操作记录到日志 。master 并不立马回收资源，而是把文件名改为一个包含 删除时间戳 的隐藏名字 。当 master 对命名空间做 常规扫描 的时候，会（彻底）删除三天前的隐藏文件 。在此之前，该文件仍然可以用新的特殊名字读取，并且可以通过将其重命名为正常文件名来撤销删除。若发现 orphaned chunk （ 即不被任何文件包含的 chunk ），会提示 chunkserver 删除这些 chunk 的副本 。

相比于立即删除资源，垃圾回收有以下几个优点：

• 对于组件失效是常态的大规模分布式系统上，这种垃圾回收方式简单可靠（可以清理没有任何文件引用的副本）
• 垃圾回收把存储空间的回收操作合并到 master 节点规律性的后台活动中（ 如 master 与 chunkserver 的握手 ），操作分批执行，开销被分散
• 防止意外的、不可逆的删除

数据一致性策略

GFS 支持一个宽松的一致性模型 。

GFS has a relaxed consistency model that supports our highly distributed applications well but remains relatively simple and efficient to implement.

首先，文件命名空间的修改（ 如：文件创建 ）是原子性的，它仅由 master 控制：命名空间锁提供了原子性和正确性、master 操作日志定义了这些操作在全局的顺序 。

对于文件的数据修改，文件状态会进入以下三种状态之一：

The state of a file region after a data mutation depends on the type of mutation, whether it succeeds or fails, and whether there are concurrent mutations.

• 一致的 (consistent)：对于一个 chunk ，所有 client 看到的所有副本内容都是一样的
• 不一致的(Inconsistent)：客户端读取不同的 Replica 时可能会读取到不同的内容，那这部分文件是不一致的
• 定义的 (defined)：数据修改后是一致的，且 client 可以看到写入操作的全部内容（ 换句话说，可以看到每步操作修改后的内容 ）

一个文件的当前状态将取决于此次修改的类型以及修改是否成功：

• 当一个数据写操作成功执行，且没有并发写入，那么影响的 region 就是 defined：所有 client 都能看到写入的内容。（ 隐含了 consistent ）
• 当并行修改写完成之后，region 处于 consistent but undefined 状态：所有 client 看到同样的数据，但是无法读到任何一次写入操作写入的数据 （ 因为可能有并行写操作覆盖了同一区域 ）。
• 失败的写操作导致 region 处于 inconsistent 状态（ 同时也是 undifined 的 ）：不同 client 在不同时间会看到不同的数据　。
• 当对文件进行追加操作，若追加操作成功，那么 region 处于 defined and consistent 状态；若某次追加操作失败，client 重新请求后会导致数据填充和重复数据的情况，此时 region 处于 defined but inconsistent 状态。

常见操作流程

读取文件流程

客户端从 GFS 集群中读取文件内容的过程大致如下：

1. 对于指定的文件名filename和根据字节偏移量offset，客户端可以根据固定的 Chunk 大小来计算出该位置在该文件的哪一个 Chunk 中（即chunk index）；
2. Client向 Master 发出请求，其中包含要读取的文件名filename以及 Chunk index；
3. Master 向Client响应该 Chunk Handle 以及其所有 副本（Replica） 当前所在的位置。Client会以filename和 Chunk index为键缓存该数据；
4. Client选取其中一个 Replica 所在的 Chunk Server 并向其发起请求，请求中会指定Chunk Handle 以及要读取的字节范围；
5. ChunkServer读取文件，返回数据（Chunk Data）。

写入文件流程

客户端尝试将数据写入到某个 Chunk 的指定位置的过程大致如下：

1. client向master询问chunk的哪个副本是primary，以及该chunk的位置 。若没有primary：
   • 若所有的 chunkserver 都没有最近的版本号，返回错误
   • master 在拥有最近版本的副本中选择 primary
   • 版本号递增，并写入硬盘中的 log
   • 告诉 primary 和 secondary 它们的身份和新版本号，并将新版本号写入 chunkserver 的硬盘
2. master 将 primary 的标识符和 secondary 的位置返回给 client ，client 缓存这些数据后续使用 。只有 primary 不可用或 lease 已到期，client 才会再跟 master 进行联系 ；
3. client 将数据推送到所有的副本上，chunkserver 接收到数据并保存在 LRU 缓存中；
4. 所有副本确认接收到数据后，client 发送写请求到 primary 。这个请求标识了早前推送到所有副本的数据，primary 为接收到的所有操作分配连续的序列号（ 这些操作可能来自不同的 client ）。primary按照序列号顺序在本地执行相应操作；
5. primary 将写请求传递到所有的 secondary ，secondary 按照序列号在本地执行操作 ；
6. 操作完成后，所有 secondary 回复 primary 已完成操作 ；
7. primary 回复 client 。期间在任何一个副本操作出现任何错误都将报告给客户端。若返回错误，client 将重复发起操作请求 。

Snapshot 文件快照

GFS 还提供了文件快照操作，可为指定的文件或目录创建一个副本。Snapshot是对系统当前状态进行的一次拍照。用户可以在任意时刻回滚到快照的状态。快照操作的实现采用了**写时复制（Copy on Write）**的思想：

1. 在 Master 接收到快照请求后，它首先会撤回这些 Chunk 的 Lease，以让接下来其他客户端对这些 Chunk 进行写入时都会需要请求 Master 获知 Primary 的位置，而这个时候Master 可以对chunk直接进行复制；
2. Master在日志中记录本次Snapshot操作，然后在内存中执行Snapshot动作，具体是将被Snapshot的文件或目录的元数据复制一份，被复制出的文件与原始文件指向相同的chunk；
3. 当有客户端尝试对这些 Chunk 进行写入时，Master 会注意到这个 Chunk 的引用计数大于 1。此时，Master 会为即将产生的新 Chunk 生成一个 Handle，然后通知所有持有这些 Chunk 的 Chunk Server 在本地复制出一个新的 Chunk（之所以本地创建是因为可以避免跨节点之间的数据拷贝，节省网络带宽），应用上新的 Handle，然后再返回给客户端；
4. 客户端收到Master的响应后，表示该Chunk已经COW结束，接下来客户端的更新流程与正常的没有区别

高可用性

We keep the overall system highly available with two simple yet effective strategies: fast recovery and replication.

Fast Recovery

不管 master 和 chunkserver 是如何关闭的，都在数秒内恢复状态并重新启动 。不区分正常关闭和异常关闭 。

master 在灾难恢复时，从磁盘上读取最近的快照，以及重演此快照后的有限个日志文件就能够恢复系统 。

chunkserver 重启后会发送 chunk 状态以及版本号给 master 。

Chunk Replication

这个在之前的Chunk and Chunk Replica详细叙述过，因此不再赘述。

Master Replication

Its operation log and checkpoints are replicated on multiple machines. A mutation to the state is considered committed only after its log record has been flushed to disk locally and on all master replicas.

When it fails, it can restart almost instantly. If its machine or disk fails, monitoring infrastructure outside GFS starts a new master process elsewhere with the replicated operation log.

master 所有操作日志和快照文件都被复制到多台机器的硬盘中 。若master失效。它可以快速重启以恢复。若 master 进程所在的机器或硬盘失效了，处于 GFS 系统外部的监控进程会在其他的存有完整操作日志的机器上启动一个新的 master 进程 。
starts a new master process elsewhere with the replicated operation log.

master 所有操作日志和快照文件都被复制到多台机器的硬盘中 。若master失效。它可以快速重启以恢复。若 master 进程所在的机器或硬盘失效了，处于 GFS 系统外部的监控进程会在其他的存有完整操作日志的机器上启动一个新的 master 进程 。