Google三大论文之GFS

Google三大论文之GFS

Google GFS（Google File System） 文件系统，一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS 虽然运行在廉价的普遍硬件设备上，但是它依然了提供灾难冗余的能力，为大量客户机提供了高性能的服务。

1 简介

GFS 与传统的分布式文件系统有着很多相同的**设计目标，比如，性能、可伸缩性、可靠性以及可用性。**设计需要考虑的问题：

• 1. 组件失效被认为是常态事件，而不是意外事件。GFS 包括几百甚至几千台普通的廉价设备组装的存储机器，同时被相当数量的客户机访问。GFS 组件的数量和质量导致在事实上，任何给定时间内都有可能发生某些组件无法工作，某些组件无法从它们目前的失效状态中恢复。比如应用程序 bug、操作系统的 bug、人为失误，甚至还有硬盘、内存、连接器、网络以及电源失效等造成的问题。所以，持续的监控、错误侦测、灾难冗余以及自动恢复的机制必须集成在 GFS 中。
• 2. 其次，以通常的标准衡量，文件非常巨大。数 GB 的文件非常普遍，每个文件通常都包含许多应用程序对象。设计的假设条件和参数，比如 I/O 操作和 Block 的尺寸都需要重新考虑。
• 3. 绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。对文件的随机写入操作在实际中几乎不存在。一旦写完之后，对文件的操作就只有读，而且通常是按顺序读。对于这种针对海量文件的访问模式，客户端对数据块缓存是没有意义的，数据的追加操作是性能优化和原子性保证的主要考量因素。
• 4. 应用程序和文件系统 API 的协同设计提高了整个系统的灵活性。对 GFS 一致性模型的要求，这样就减轻了文件系统对应用程序的苛刻要求，大大简化了 GFS 的设计。引入了原子性的记录追加操作，从而保证多个客户端能够同时进行追加操作，不需要额外的同步操作来保证数据的一致性。

2 设计概述

2.1 设计预期

系统由许多廉价的普通组件组成，组件失效是一种常态。系统必须持续监控自身的状态，它必须将组件失效作为一种常态，能够迅速地侦测、冗余并恢复失效的组件。

系统的工作负载主要由两种读操作组成：大规模的流式读取和小规模的随机读取。小规模的随机读取通常是在文件某个随机的位置读取几个 KB 数据。如果应用程序对性能非常关注，通常的做法是把小规模的随机读取操作合并并排序，之后按顺序批量读取，这样就避免了在文件中前后来回的移动读取位置。数据一旦被写入后，文件就很少会被修改了。系统必须高效的、行为定义明确的2实现多客户端并行追加数据到同一个文件里的语意。文件被用于“生产者-消费者”队列，或者其它多路文件合并操作。最小的同步开销来实现的原子的多路追加数据操作是必不可少的。

2.2 接口

GFS 提供了一套类似传统文件系统的 API 接口函数，文件以分层目录的形式组织，用路径名来标识。支持常用的操作，如创建新文件、删除文件、打开文件、关闭文件、读和写文件。

2.3 架构

一个 GFS 集群包含一个单独的 Master 节点3、多台 Chunk 服务器，并且同时被多个客户端访问，

GFS 存储的文件都被分割成固定大小的 Chunk。在 Chunk 创建的时候，Master 服务器会给每个 Chunk 分配一个不变的、全球唯一的 64 位的 Chunk 标识。Chunk 以 Linux 文件的形式保存在本地硬盘上，并且根据指定的 Chunk 标识和字节范围来读写块数据。

Master 节点管理所有的文件系统元数据。Chunk 租用管理、孤儿 Chunk的回收、以及 Chunk 在 Chunk 服务器之间的迁移。Master 节点使用心跳信息周期地和每个 Chunk服务器通讯，发送指令到各个 Chunk 服务器并接收 Chunk 服务器的状态信息。客户端缓存数据几乎没有什么用处，因为大部分程序要么以流的方式读取一个巨大文件，要么工作集太大根本无法被缓存。

2.4 单一 Master 节点

单一的 Master 节点可以通过全局的信息精确定位Chunk 的位置以及进行复制决策。必须减少对 Master 节点的读写，避免 Master 节点成为系统的瓶颈。客户端并不通过 Master 节点读写文件数据。首先，客户端把文件名和程序指定的字节偏移，根据固定的 Chunk 大小，转换成文件的Chunk 索引。然后，它把文件名和 Chunk 索引发送给 Master 节点。Master 节点将相应的 Chunk 标识和副本的位置信息发还给客户端。客户端用文件名和 Chunk 索引作为 key 缓存这些信息。客户端通常会在一次请求中查询多个 Chunk 信息，Master 节点的回应也可能包含了紧跟着这些被请求的 Chunk 后面的 Chunk 的信息。

2.5 Chunk 尺寸

Chunk 的大小是关键的设计参数之一，选择了 64MB。每个 Chunk 的副本都以普通 Linux 文件的形式保存在 Chunk 服务器上，只有在需要的时候才扩大。惰性空间分配策略避免了因内部碎片造成的空间浪费，内部碎片或许是对选择这么大的 Chunk 尺寸最具争议一点。

选择较大的 Chunk 尺寸有几个重要的优点：

• 减少了客户端和 Master 节点通讯的需求，因为只需要一次和 Mater 节点的通信就可以获取 Chunk 的位置信息，之后就可以对同一个 Chunk 进行多次的读写操作
• 采用较大的 Chunk 尺寸，客户端能够对一个块进行多次操作，这样就可以通过与 Chunk 服务器保持较长时间的 TCP 连接来减少网络负载
• 选用较大的 Chunk 尺寸减少了 Master节点需要保存的元数据的数量

采用较大的 Chunk 尺寸也有其缺陷：

• 当有许多的客户端对同一个小文件进行多次的访问时，存储这些 Chunk 的 Chunk 服务器就会变成热点
• 一个可执行文件在GFS 上保存为 single-chunk 文件，之后这个可执行文件在数百台机器上同时启动
• 几个 Chunk 服务器被数百个客户端的并发请求访问导致系统局部过载
• 通过使用更大的复制参数来保存可执行文件，以及错开批处理队列系统程序的启动时间的方法解决了这个问题
• 长效解决方案是允许客户端从其它客户端读取数据

2.6 元数据

Master 服务器存储 3 种主要类型的元数据，所有的元数据都保存在 Master 服务器的内存中。包括：

• 文件和 Chunk 的命名空间
• 文件和 Chunk 的对应关系
• 每个 Chunk 副本的存放地点

2.6.1 内存中的数据结构

元数据保存在内存中，所以 Master 服务器的操作速度非常快。Master 服务器可以在后台简单而高效的周期性扫描自己保存的全部状态信息。周期性的状态扫描也用于实现 Chunk 垃圾收集、在 Chunk服务器失效的时重新复制数据、通过Chunk 的迁移实现跨 Chunk 服务器的负载均衡以及磁盘使用状况统计等功能。

将元数据全部保存在内存中的方法有潜在问题：Chunk 的数量以及整个系统的承载能力都受限于 Master服务器所拥有的内存大小。但这不是严重的问题，因为每个文件的在命名空间中的数据大小通常在 64字节以下，因为保存的文件名是用前缀压缩算法压缩过的。另外为 Master 服务器增加额外内存的费用是很少的，通过增加有限的费用，就能够把元数据全部保存在内存里，增强了系统的简洁性、可靠性、高性能和灵活性。

2.6.2 Chunk位置信息

Master 服务器并不保存持久化保存哪个 Chunk 服务器存有指定 Chunk 的副本的信息。Master 服务器只是在启动的时候轮询 Chunk 服务器以获取这些信息。它控制了所有的 Chunk 位置的分配，而且通过周期性的心跳信息监控 Chunk 服务器的状态。轮询这种方式比位置信息永久保存到Master服务器上会更简单。这种设计简化了在有 Chunk 服务器加入集群、离开集群、更名、失效、以及重启的时候，Master 服务器和 Chunk 服务器数据同步的问题。只有 Chunk 服务器才能最终确定一个 Chunk 是否在它的硬盘上。

2.6.3 操作日志

操作日志包含了关键的元数据变更历史记录，这对 GFS 非常重要。这不仅仅是因为操作日志是元数据唯一的持久化存储记录，它也作为判断同步操作顺序的逻辑时间基线。文件和 Chunk，连同它们的版本都由它们创建的逻辑时间唯一的、永久的标识。

操作日志非常重要，必须确保日志文件的完整，确保只有在元数据的变化被持久化后，日志才对客户端是可见的。会把日志复制到多台远程机器，并且只有把相应的日志记录写入到本地以及远程机器的硬盘后，才会响应客户端的操作请求。Master 服务器在灾难恢复时，通过重演操作日志把文件系统恢复到最近的状态。为了缩短 Master 启动的时间，必须使日志足够小。Master 服务器在日志增长到一定量时对系统状态做一次 Checkpoint。Checkpoint 文件以压缩 B-树形式的数据结构存储，可以直接映射到内存，在用于命名空间查询时无需额外的解析，大大提高了恢复速度，增强了可用性。

Master 服务器使用独立的线程切换到新的日志文件和创建新的 Checkpoint 文件。新的 Checkpoint 文件包括切换前所有的修改。Master 服务器恢复只需要最新的 Checkpoint 文件和后续的日志文件。旧的 Checkpoint 文件和日志文件可以被删除。但是为了应对灾难性的故障，通常会多保存一些历史文件Checkpoint 失败不会对正确性产生任何影响，因为恢复功能的代码可以检测并跳过没有完成的 Checkpoint 文件。

2.7 一致性模型

GFS 支持一个宽松的一致性模型，这个模型能够很好的支撑高度分布的应用，同时还保持了相对简单且容易实现的优点。

2.7.1 GFS一致性保障机制

文件命名空间的修改（例如，文件创建）是原子性的， 仅由 Master 节点的控制：命名空间锁提供了原子性和正确性的保障；Master 节点的操作日志定义了这些操作在全局的顺序。

• 如果所有客户端，无论从哪个副本读取，读到的数据都一样，那么认为文件 region 是“一致的”；
• 如果对文件的数据修改之后，region 是一致的，并且客户端能够看到写入操作全部的内容，那么这个 region是“已定义的”。

通常情况下，文件 region 内包含了来自多个修改操作的、混杂的数据片段。失败的修改操作导致一个 region 处于不一致状态（同时也是未定义的）：不同的客户在不同的时间会看到不同的数据。

数据修改操作分为写入或者记录追加两种：

• 写入操作把数据写在应用程序指定的文件偏移位置上

• 记录追加操作至少可以把数据原子性的追加到文件中一次，偏移位置是由

  GFS 选择的

GFS 返回给客户端一个偏移量，表示了包含了写入记录的、已定义的 region 的起点。另外，GFS 可能会在文件中间插入填充数据或者重复记录

GFS 通过 Master 服务器和所有 Chunk 服务器的定期“握手”来找到失效的 Chunk 服务器，并且使用 Checksum 来校验数据是否损坏。一旦发现问题，数据要尽快利用有效的副本进行恢复。

2.7.2 程序的实现

尽量采用追加写入而不是覆盖，Checkpoint，自验证的写入操作，自标识的记录。写入所有数据之后，应用程序自动将文件改名为一个永久保存的文件名，或者周期性的作 Checkpoint，记录成功写入了多少数据。Checkpoint 文件可以包含程序级别的校验和。Readers 仅校验并处理上个 Checkpoint 之后产生的文件 region，这些文件 region 的状态一定是已定义的。这个方法满足了我们一致性和并发处理的要求。追加写入比随机位置写入更加有效率，对应用程序的失败处理更具有弹性。

3 系统交互

设计这个系统时，一个重要的原则是最小化所有操作和 Master 节点的交互。

3.1 租约lease和变更顺序

变更是一个会改变 Chunk 内容或者元数据的操作，比如写入操作或者记录追加操作。变更操作会在 Chunk的所有副本上执行。使用租约（lease）机制来保持多个副本间变更顺序的一致性。Master 节点为 Chunk的一个副本建立一个租约，把这个副本叫做主 Chunk。主 Chunk 对 Chunk 的所有更改操作进行序列化。所有的副本都遵从这个序列进行修改操作。修改操作全局的顺序首先由 Master 节点选择的租约的顺序决定，然后由租约中主 Chunk 分配的序列号决定。设计租约机制的目的是为了最小化 Master 节点的管理负担。即使Master节点和主Chunk失去联系，它仍然可以安全地在旧的租约到期后和另外一个Chunk副本签订新的租约。

客户机向 Master 节点询问哪一个 Chunk 服务器持有当前的租约，以及其它副本的位置。如果没有一个Chunk 持有租约，Master 节点就选择其中一个副本建立一个租约。只有在主 Chunk 不可用，或者主 Chunk 回复信息表明它已不再持有租约的时候，客户机才需要重新跟 Master 节点联系。客户机可以以任意的顺序推送数据。Chunk 服务器接收到数据并保存在它的内部 LRU 缓存中，一直到数据被使用或者过期交换出去。由于数据流的网络传输负载非常高，通过分离数据流和控制流，我们可以基于网络拓扑情况对数据流进行规划，提高系统性能。当所有的副本都确认接收到了数据，客户机发送写请求到主 Chunk 服务器。主 Chunk 为接收到的所有操作分配连续的序列号，这些操作可能来自不同的客户机，序列号保证了操作顺序执行。

如果应用程序一次写入的数据量很大，或者数据跨越了多个 Chunk，GFS 客户机代码会把它们分成多个写操作。这些操作都遵循前面描述的控制流程，但是可能会被其它客户机上同时进行的操作打断或者覆盖。共享的文件 region 的尾部可能包含来自不同客户机的数据片段。

3.2 数据流

为了提高网络效率，采取了把数据流和控制流分开的措施。在控制流从客户机到主 Chunk、然后再到所有二级副本的同时，数据以管道的方式，顺序的沿着一个精心选择的 Chunk 服务器链推送。充分利用每台机器的带宽，避免网络瓶颈和高延时的连接，最小化推送所有数据的延时。

为了充分利用每台机器的带宽，数据沿着一个 Chunk 服务器链顺序的推送，而不是以其它拓扑形式分散推送。每台机器都尽量的在网络拓扑中选择一台还没有接收到数据的、离自己最近的机器作为目标推送数据，通过 IP 地址就可以计算出节点的“距离”。利用基于 TCP 连接的、管道式数据推送方式来最小化延迟。Chunk 服务器接收到数据后，马上开始向前推送。在没有网络拥塞的情况下，传送 B 字节的数据到 R 个副本的理想时间是B/T+RL ，T 是网络的吞吐量，L 是在两台机器数据传输的延迟。

3.3 原子的记录追加

GFS 提供了一种原子的数据追加操作–记录追加。对同一个 region 的并行写入操作不是串行的：region 尾部可能会包含多个不同客户机写入的数据片段。GFS 保证至少有一次原子的写入操作成功执行，写入的数据追加到 GFS 指定的偏移位置上，之后 GFS 返回这个偏移量给客户机。工作中，文件通常用于多个生产者/单一消费者的队列系统，或者是合并了来自多个客户机的数据的结果文件。

记录追加是一种修改操作。主 Chunk 会检查这次记录追加操作是否会使 Chunk 超过最大尺寸（64MB）。如果超过了最大尺寸，主 Chunk 首先将当前 Chunk 填充到最大尺寸，之后通知所有二级副本做同样的操作，然后回复客户机要求其对下一个 Chunk 重新进行记录追加操作。（记录追加的数据大小严格控制在 Chunk 最大尺寸的 1/4，这样即使在最坏情况下，数据碎片的数量仍然在可控的范围。）

如果记录追加操作在任何一个副本上失败了，客户端就需要重新进行操作。GFS并不保证Chunk的所有副本在字节级别是完全一致的。它只保证数据作为一个整体原子的被至少写入一次。如果操作成功执行，数据一定已经写入到 Chunk 的所有副本的相同偏移位置上。

3.4 快照

快照操作几乎可以瞬间完成对一个文件或者目录树（“源”）做一个拷贝，并且几乎不会对正在进行的其它操作造成任何干扰，经常是递归的拷贝拷贝。

用标准的 copy-on-write技术实现快照。当 Master 节点收到一个快照请求，它首先取消作快照的文件的所有 Chunk 的租约。这个措施保**证了后续对这些 Chunk 的写操作都必须与 Master 交互以找到租约持有者。这就给 Master 节点一个率先创建Chunk 的新拷贝的机会。**新创建的快照文件和源文件指向完全相同的 Chunk 地址。确保数据在本地而不是通过网络复制（硬盘比100Mb 以太网大约快 3倍）。

4 Master节点的操作

Master 节点执行所有的名称空间操作。此外，它还管理着整个系统里所有 Chunk 的副本：它决定 Chunk的存储位置，创建新 Chunk 和它的副本，协调各种各样的系统活动以保证 Chunk 被完全复制，在所有的 Chunk服务器之间的进行负载均衡，回收不再使用的存储空间。

4.1 名称空间管理和锁

Master 节点的很多操作会花费很长的时间，因此允许多个操作同时进行，使用名称空间的 region 上的锁来保证执行的正确顺序。

在逻辑上，GFS 的名称空间就是一个全路径和元数据映射关系的查找表。利用前缀压缩，这个表可以高效的存储在内存中。操作首先要获得目录/d1，/d1/d2，…，/d1/d2/…/dn 的读锁，以及/d1/d2/…/dn/leaf 的读写锁。注意，根据操作的不同，leaf 可以是一个文件，也可以是一个目录。采用这种锁方案的优点是支持对同一目录的并行操作。目录名的读取锁足以的防止目录被删除、改名以及被快照。文件名的写入锁序列化文件创建操作，确保不会多次创建同名的文件。节点，读写锁采用惰性分配策略，在不再使用的时候立刻被删除。同样，锁的获取也要依据一个全局一致的顺序来避免死锁：首先按名称空间的层次排序，在同一个层次内按字典顺序排序。

4.2 副本的位置

GFS 集群是高度分布的多层布局结构，而不是平面结构。Chunk 服务器被来自同一或者不同机架上的数百个客户机轮流访问。不同机架上的两台机器间的通讯可能跨越一个或多个网络交换机。多层分布架构对数据的灵活性、可靠性以及可用性方面提出特有的挑战。

Chunk 副本位置选择的策略服务两大目标：

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

必须在多个机架间分布储存Chunk的副本。这保证Chunk的一些副本在整个机架被破坏或掉线（比如，共享资源，如电源或者网络交换机造成的问题）的情况下依然存在且保持可用状态。在网络流量方面，尤其是针对 Chunk 的读操作，能够有效利用多个机架的整合带宽。

4.3 创建，重新复制，重新负载均衡

Chunk 的副本有三个用途：Chunk 创建，重新复制和重新负载均衡。

当 Master 节点创建一个 Chunk 时，它会选择在哪里放置初始的空的副本, 会考虑几个因素：

• 希望在低于平均硬盘使用率的 Chunk 服务器上存储新的副本，平衡 Chunk服务器之间的硬盘使用率
• 希望限制在每个 Chunk 服务器上“最近”的 Chunk 创建操作的次数
• 希望把 Chunk 的副本分布在多个机架之间

当 Chunk 的有效副本数量少于用户指定的复制因数的时候，Master 节点会重新复制它。每个需要被重新复制的 Chunk 都会根据几个因素进行排序：一个因素是 Chunk 现有副本数量和复制因数相差多少；优先重新复制活跃（live）文件的 Chunk 而不是最近刚被删除的文件的 Chunk；提高会阻塞客户机程序处理流程的 Chunk 的优先级；

选择新副本的位置的策略和创建时类似：**平衡硬盘使用率、限制同一台 Chunk 服务器上的正在进行的克隆操作的数量、在机架间分布副本。**对克隆操作的数量都进行了限制，对源 Chunk 服务器读请求的频率来限制它用于克隆操作的带宽。

Master 服务器周期性地对副本进行重新负载均衡：它检查当前的副本分布情况，然后移动副本以便更好的利用硬盘空间、更有效的进行负载均衡。Master 节点移走那些剩余空间低于平均值的Chunk 服务器上的副本，从而平衡系统整体的硬盘使用率。

4.4 垃圾回收

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

4.4.1 机制

当一个文件被应用程序删除时，Master 节点象对待其它修改操作一样，立刻把删除操作以日志的方式记录下来。但是，Master 节点并不马上回收资源，而是把文件名改为一个包含删除时间戳的、隐藏的名字。Master 节点对文件系统命名空间做常规扫描的时候，它会删除所有三天前的隐藏文件（时间可以自己定）。直到文件被真正删除，它们仍旧可以用新的特殊的名字读取，也可以通过把隐藏文件改名为正常显示的文件名的方式“反删除”。当隐藏文件被从名称空间中删除，Master 服务器内存中保存的这个文件的相关元数据才会被删除。这也有效的切断了文件和它包含的所有 Chunk 的连接。

4.4.2 讨论

在GFS系统中可以轻易的得到 Chunk 的所有引用：它们都只存储在 Master 服务器上的文件到块的映射表中。也可以很轻易的得到所有Chunk 的副本：它们都以 Linux 文件的形式存储在 Chunk服务器的指定目录下。所有 Master 节点不能识别的副本都是“垃圾”。

垃圾回收在空间回收方面相比直接删除有几个优势。首先，对于组件失效是常态的大规模分布式系统，垃圾回收方式简单可靠。

• Chunk 可能在某些 Chunk 服务器创建成功，某些 Chunk 服务器上创建失败，失败的副本处于无法被 Master 节点识别的状态
• 垃圾回收把存储空间的回收操作合并到 Master 节点规律性的后台活动中，，垃圾回收在 Master 节点相对空闲的时候完成
• 延缓存储空间回收为意外的、不可逆转的删除操作提供了安全保障

延迟回收空间的主要问题是，延迟回收会阻碍用户调优存储空间的使用，特别是当存储空间比较紧缺的时候。可以通过显式的再次删除一个已经被删除的文件的方式加速空间回收的速度。

4.5 过期失效的副本检测

当 Chunk 服务器失效时，Chunk 的副本有可能因错失了一些修改操作而过期失效。Master 节点保存了每个 Chunk 的版本号，用来区分当前的副本和过期副本。、

无论何时，只要 Master 节点和 Chunk 签订一个新的租约，它就增加 Chunk 的版本号，然后通知最新的副本。如果 Master 节点看到一个比它记录的版本号更高的版本号，Master 节点会认为它和 Chunk 服务器签订租约的操作失败了，因此会选择更高的版本号作为当前的版本号。

Master 节点在例行的垃圾回收过程中移除所有的过期失效副本。

5 容错和诊断

在设计 GFS 时遇到的最大挑战之一是如何处理频繁发生的组件失效。组件的数量和质量让这些问题出现的频率远远超过一般系统意外发生的频率：

• 不能完全依赖机器的稳定性
• 也不能完全相信硬盘的可靠性

5.1 高可用性

使用两条简单但是有效的策略保证整个系统的高可用性：快速恢复和复制。

5.1.1 快速恢复

不管 Master 服务器和 Chunk 服务器是如何关闭的，它们都被设计为可以在数秒钟内恢复它们的状态并重新启动。不区分正常关闭和异常关闭， 如果在发出的请求会超时，需要重新连接到重启后的服务器，然后重试这个请求。

5.1.2 Chunk复制

每个 Chunk 都被复制到不同机架上的不同的 Chunk 服务器上。用户可以为文件命名空间的不同部分设定不同的复制级别。当有 Chunk 服务器离线了，或者通过 Chksum 校验发现了已经损坏的数据，Master 节点通过克隆已有的副本保证每个 Chunk 都被完整复制。其它形式的跨服务器的冗余解决方案，比如使用奇偶校验、或者 Erasure codes来解决日益增长的只读存储需求。

5.1.3 Master 服务器的复制

为了保证 Master 服务器的可靠性，Master 服务器的状态也要复制。Master 服务器所有的操作日志和checkpoint 文件都被复制到多台机器上。对 Master 服务器状态的修改操作能够提交成功的前提是，操作日志写入到 Master 服务器的备节点和本机的磁盘。一个 Master 服务进程负责所有的修改操作，包括后台的服务，比如垃圾回收等改变系统内部状态活动。GFS 中还有些“影子”Master 服务器，这些“影子”服务器在“主”Master 服务器宕机的时候提供文件系统的只读访问。它们是影子，而不是镜像，所以它们的数据可能比“主”Master 服务器更新要慢，通常是不到 1 秒。对于那些不经常改变的文件、或者那些允许获取的数据有少量过期的应用程序，“影子”Master 服务器能够提高读取的效率。

“影子”Master 服务器为了保持自身状态是最新的，它会读取一份当前正在进行的操作的日志副本，并且依照和主 Master 服务器完全相同的顺序来更改内部的数据结构。“影子”Master服务器在启动的时候也会从 Chunk 服务器轮询数据（之后定期拉数据），也会定期和 Chunk 服务器“握手”来确定它们的状态。

5.2 数据完整性

每个 Chunk 服务器都使用 Checksum 来检查保存的数据是否损坏，每个 Chunk 服务器必须独立维护 Checksum 来校验自己的副本的完整性。Checksum 与其它的用户数据是分开的，并且保存在内存和硬盘上，同时也记录操作日志。如果写操作覆盖已经存在的一个范围内的 Chunk，必须读取和校验被覆盖的第一个和最后一个块，然后再执行写操作。一旦发现有 Chunk 的数据损坏，Master 可以创建一个新的、正确的副本，然后把损坏的副本删除掉。

5.3 诊断工具

详尽的、深入细节的诊断日志，在问题隔离、调试、以及性能分析等方面能带来无法估量的帮助，同时也只需要很小的开销。GFS 的服务器会产生大量的日志，记录了大量关键的事件（比如，Chunk 服务器启动和关闭）以及所有的 RPC 的请求和回复。可以重演所有的消息交互来诊断问题。日志还用来跟踪负载测试和性能分析。日志对性能的影响很小（远小于它带来的好处），因为这些日志的写入方式是顺序的、异步的。最近发生的事件日志保存在内存中，可用于持续不断的在线监控。

6 度量

6.1 小规模基准测试

6.1.1 读取

整体读取速度达到理论的极限值是 125MB/S，或者说每个客户机配置的 100Mbps 网卡达到饱和时，每个客户机读取速度的理论极限值是 12.5MB/s。对于 16 个客户机，整体的读取速度达到了 94MB/s，大约是理论整体读取速度极限值的75%，也就是说每个客户机的读取速度是6MB/s。

6.1.2 写入

N 个客户机同时向 N 个不同的文件中写入数据。每个客户机以每次 1MB 的速度连续写入 1GB 的数据。图 3（b）显示了整体的写入速度和它们理论上的极限值。理论上的极限值是 67MB/s。一个客户机的写入速度是 6.3MB，大概是理论极限值的一半。

6.1.3 记录追加

记录追加的速度由一个客户机的 6.0MB/s 开始，下降到 16 个客户机的 4.8MB/s 为止，速度的下降主要是由于不同客户端的网络拥塞以及网络传输速度的不同而导致的。

6.2 实际应用中的集群

集群 A 通常被上百个工程师用于研究和开发。典型的任务是被人工初始化后连续运行数个小时。它通常读取数 MB 到数 TB 的数据。集群 B 主要用于处理当前的生产数据。集群 B 的任务持续的时间更长，在很少人工干预的情况下，持续的生成和处理数 TB 的数据集。

6.2.1 存储

两个集群都由上百台 Chunk 服务器组成，支持数 TB 的硬盘空间。两个集群存储的文件数量都差不多，但是集群 B 上有大量的死文件。所谓“死文件”是指文件被删除或者是被新版本的文件替换。但是存储空间还没有来得及被回收。由于集群 B 存储的文件较大，因此它的Chunk 数量也比较多。

6.2.2 元数据

Chunk 服务器总共保存了十几 GB 的元数据，大多数是来自用户数据的、64KB 大小的块的Checksum。保存在 Chunk 服务器上其它的元数据是 Chunk 的版本号信息。在 Master 服务器上保存的元数据就小的多了，大约只有数十 MB，或者说平均每个文件 100 字节的元数据。Master 服务器的内存大小在实际应用中并不会成为 GFS 系统容量的瓶颈，Master 服务器上存放的其它元数据包括了文件的所有者和权限、文件到 Chunk 的映射关系，以及每一个 Chunk 的当前版本号。

6.2.3 读写速率

读取速率要比写入速率高的多。正如设想那样，总的工作负载中，读取比例远远高于写入的比例。

6.2.4 Master服务器的负载

Master 服务器的操作请求大概是每秒钟 200 到 500 个。Master 服务器可以轻松的应付这个请求速度，所以 Master 服务器的处理能力不是系统的瓶颈。修改了 Master 服务器的数据结构，通过对名字空间进行二分查找来提高效率，也可以通过在名称空间数据结构之前设置名称查询缓冲的方式进一步提高速度。

6.2.5 恢复时间

当某个 Chunk 服务器失效了，一些 Chunk 副本的数量可能会低于复制因子指定的数量，必须通过克隆副本使 Chunk 副本数量达到复制因子指定的数量。恢复所有 Chunk 副本所花费的时间取决于资源的数量。为了减小克隆操作对正在运行的应用程序的影响，以及为 GFS 调度决策提供修正空间，缺省的把集群中并发克隆操作的数量设置为 91 个（Chunk 服务器的数量的 40%），每个克隆操作最多允许使用的带宽是 6.25MB/s（50mbps）。所有的 Chunk 在 23.2 分钟内恢复了，复制的速度高达 440MB/s。

6.3 工作负荷分析(Workload Breakdown)

集群 X 用于研究和开发，集群 Y 用于生产数据处理。

6.3.1 方法论和注意事项

从 GFS 服务器记录的真实的 RPC 请求日志中推导重建出关于 IO 操作的统计信息，可以通过这些 RPC 请求推导出原始的读操作。

读取操作按操作涉及的数据量大小呈现了双峰分布。小的读取操作（小于 64KB）一般是由查找操作的客户端发起的，目的在于从巨大的文件中查找小块的数据。大的读取操作（大于 512KB）一般是从头到尾顺序的读取整个文件。

大的操作（超过256KB）占据了主要的传输量。小的读取（小于 64KB）虽然传输的数据量比较少，但是在读取的数据量中仍占了相当的比例，这是在文件中随机 Seek 的工作负荷而导致的。

6.3.3 记录追加 vs. 写操作

数据修改操作主要是记录追加操作而不是覆盖方式的写操作。

6.3.4 Master的工作负荷

大部分的请求都是读取操作查询 Chunk 位置信息（FindLocation）、以及修改操作查询 lease 持有者的信息（FindLease-Locker）。

7 经验

使用 Checksum 来校验数据，同时也修改内核来处理这些因为协议不匹配带来的问题。在某一个地址空间的任意一个线程都必须在从磁盘 page in（读锁）的时候先 hold 住，或者在 mmap()调用（写锁）的时候改写地址空间。发现这个单个锁在磁盘线程交换以前映射的数据到磁盘的时候，锁住了当前的网络线程，阻止它把新数据映射到内存。

8 相关工作

与AFS不同的是，GFS 把文件分布存储到不同的服务器上，这种方式更类似 Xfs和 Swift，这是为了提高整体性能以及灾难冗余的能力。GFS 目前只使用复制的方式来进行冗余，因此要比 xFS 或者 Swift 占用更多的裸存储空间。与 AFS、xFS、Frangipani以及 Intermezzo等文件系统不同的是，GFS 并没有在文件系统层面提供任何 Cache 机制。某些分布式文件系统，比如 Frangipani、xFS、Minnesota’s GFS、GPFS，去掉了中心服务器，只依赖于分布式算法来保证一致性和可管理性。我们选择了中心服务器的方法，目的是为了简化设计，增加可靠性，能够灵活扩展，极大地简化了原本非常复杂的 Chunk 分配和复制策略的实现方法。GFS 设计预期是使用大量的不可靠节点组建集群，因此，灾难冗余方案是设计的核心。GFS 实现了诸如重新负载均衡、复制、恢复机制等等在生产环境中需要的特性。通过原子的记录追加操作实现了生产者-消费者队列，使用的是跨主机的、基于内存的分布式队列，为了实现这个队列，必须仔细控制数据流。

9 结束语

Google 文件系统展示了一个使用普通硬件支持大规模数据处理的系统的特质。虽然一些设计要点都是针对特殊的需要定制的，但是还是有很多特性适用于类似规模的和成本的数据处理任务。

首先，根据当前的和可预期的将来的应用规模和技术环境来评估传统的文件系统的特性。根据设计思路，认为组件失效是常态而不是异常，针对采用追加方式（有可能是并发追加）写入、然后再读取（通常序列化读取）的大文件进行优化，以及扩展标准文件系统接口、放松接口限制来改进整个系统。

系统通过持续监控，复制关键数据，快速和自动恢复提供灾难冗余。Chunk 复制使得我们可以对Chunk 服务器的失效进行容错。使用 Checksum 在磁盘或者 IDE 子系统级别检测数据损坏，在这样磁盘数量惊人的大系统中，损坏率是相当高的。

设计保证了在有大量的并发读写操作时能够提供很高的合计吞吐量。通过分离控制流和数据流来实现这个目标，控制流在 Master 服务器处理，而数据流在 Chunk 服务器和客户端处理。

10 致谢

• Brain Bershad
• Anurag Acharya
• Jeff Dean
• David des-Jardins
• Fay Chang
• Guy Edjlali
• Markus Gutschke
• Kramer
• Urs Hoelzle
• Max Ibel, Sharon Perl, Rob Pike,
• Debby Wallach
• Yoshka

11 参考

• [1] Thomas Anderson, Michael Dahlin, Jeanna Neefe, David Patterson, Drew Roselli, and Randolph Wang. Serverless networkfil e systems. In Proceedings of the 15th ACM Symposium on Operating System Principles, pages 109–126, Copper Mountain Resort, Colorado, December 1995.
• [2] Remzi H. Arpaci-Dusseau, Eric Anderson, Noah Treuhaft, David E. Culler, Joseph M. Hellerstein, David Patterson, and Kathy Yelick. Cluster I/O with River: Making the fast case common. In Proceedings of the Sixth Workshop on Input/Output in Parallel and Distributed Systems (IOPADS ’99), pages 10–22, Atlanta, Georgia, May 1999.
• [3] Luis-Felipe Cabrera and Darrell D. E. Long. Swift: Using distributed disks triping to provide high I/O data rates. Computer Systems, 4(4):405–436, 1991.
• [4] Garth A. Gibson, David F. Nagle, Khalil Amiri, Jeff Butler, Fay W. Chang, Howard Gobioff, Charles Hardin, ErikR iedel, David Rochberg, and Jim Zelenka. A cost-effective, high-bandwidth storage architecture. In Proceedings of the 8th Architectural Support for Programming Languages and Operating Systems, pages 92–103, San Jose, California, October 1998.
• [5] John Howard, Michael Kazar, Sherri Menees, David Nichols, Mahadev Satyanarayanan, Robert Sidebotham, and Michael West. Scale and performance in a distributed file system. ACM Transactions on Computer Systems, 6(1):51–81, February 1988.
• [6] InterMezzo. www.inter-mezzo.org, 2003.
• [7] Barbara Liskov, Sanjay Ghemawat, Robert Gruber, Paul Johnson, Liuba Shrira, and Michael Williams. Replication in the Harp file system. In 13th Symposium on Operating System Principles, pages 226–238, Pacific Grove, CA, October 1991.
• [8] Lustre. www.lustreorg, 2003.
• [9] David A. Patterson, Garth A. Gibson, and Randy H. Katz. A case for redundant arrays of inexpensive disks (RAID). In Proceedings of the 1988 ACM SIGMOD International Conference on Management of Data, pages 109–116, Chicago, Illinois, September 1988.
• [10] FrankS chmuck and Roger Haskin. GPFS: A shared-diskfi le system for large computing clusters. In Proceedings of the First USENIX Conference on File and Storage Technologies, pages 231–244, Monterey, California, January 2002.
• [11] Steven R. Soltis, Thomas M. Ruwart, and Matthew T.O’Keefe. The Gobal File System. In Proceedings of the Fifth NASA Goddard Space Flight Center Conference on Mass Storage Systems and Technologies, College Park, Maryland, September 1996.
• [12] Chandramohan A. Thekkath, Timothy Mann, and Edward K. Lee. Frangipani: A scalable distributed file system. In Proceedings of the 16th ACM Symposium on Operating System Principles, pages 224–237, Saint-Malo, France, October 1997

转载自掘金🔗