The Google File System中文版

时间 2020-06-22 标签 google file system 中文版

The Google File System中文版

By Alexhtml

摘要

咱们设计并实现了Google GFS文件系统，一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS虽然运行在廉价的广泛硬件设备上，可是它依然了提供灾难冗余的能力，为大量客户机提供了高性能的服务。node

虽然GFS的设计目标与许多传统的分布式文件系统有不少相同之处，可是，咱们的设计仍是以咱们对本身的应用的负载状况和技术环境的分析为基础的，无论如今仍是未来，GFS和早期的分布式文件系统的设想都有明显的不一样。因此咱们从新审视了传统文件系统在设计上的折衷选择，衍生出了彻底不一样的设计思路。linux

GFS彻底知足了咱们对存储的需求。GFS做为存储平台已经被普遍的部署在Google内部，存储咱们的服务产生和处理的数据，同时还用于那些须要大规模数据集的研究和开发工做。目前为止，最大的一个集群利用数千台机器的数千个硬盘，提供了数百TB的存储空间，同时为数百个客户机服务。web

在本论文中，咱们展现了可以支持分布式应用的文件系统接口的扩展，讨论咱们设计的许多方面，最后列出了小规模性能测试以及真实生产系统中性能相关数据。算法

分类和主题描述

D [4]: 3—D分布文件系统数据库

经常使用术语

设计，可靠性，性能，测量编程

关键词

容错，可伸缩性，数据存储，集群存储后端

1. 简介

为了知足Google迅速增加的数据处理需求，咱们设计并实现了Google文件系统(Google File System – GFS)。GFS与传统的分布式文件系统有着不少相同的设计目标，好比，性能、可伸缩性、可靠性以及可用性。可是，咱们的设计还基于咱们对咱们本身的应用的负载状况和技术环境的观察的影响，无论如今仍是未来，GFS和早期文件系统的假设都有明显的不一样。因此咱们从新审视了传统文件系统在设计上的折衷选择，衍生出了彻底不一样的设计思路。缓存

首先，组件失效被认为是常态事件，而不是意外事件。GFS包括几百甚至几千台普通的廉价设备组装的存储机器，同时被至关数量的客户机访问。 GFS组件的数量和质量致使在事实上，任何给定时间内都有可能发生某些组件没法工做，某些组件没法从它们目前的失效状态中恢复。咱们遇到过各类各样的问题，好比应用程序bug、操做系统的bug、人为失误，甚至还有硬盘、内存、链接器、网络以及电源失效等形成的问题。因此，持续的监控、错误侦测、灾难冗余以及自动恢复的机制必须集成在GFS中。安全

其次，以一般的标准衡量，咱们的文件很是巨大。数GB的文件很是广泛。每一个文件一般都包含许多应用程序对象，好比web文档。当咱们常常须要处理快速增加的、而且由数亿个对象构成的、数以TB的数据集时，采用管理数亿个KB大小的小文件的方式是很是不明智的，尽管有些文件系统支持这样的管理方式。所以，设计的假设条件和参数，好比I/O操做和Block的尺寸都须要从新考虑。

第三，绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。对文件的随机写入操做在实际中几乎不存在。一旦写完以后，对文件的操做就只有读，并且一般是按顺序读。大量的数据符合这些特性，好比：数据分析程序扫描的超大的数据集；正在运行的应用程序生成的连续的数据流；存档的数据；由一台机器生成、另一台机器处理的中间数据，这些中间数据的处理多是同时进行的、也多是后续才处理的。对于这种针对海量文件的访问模式，客户端对数据块缓存是没有意义的，数据的追加操做是性能优化和原子性保证的主要考量因素。

第四，应用程序和文件系统API的协同设计提升了整个系统的灵活性。好比，咱们放松了对GFS一致性模型的要求，这样就减轻了文件系统对应用程序的苛刻要求，大大简化了GFS的设计。咱们引入了原子性的记录追加操做，从而保证多个客户端可以同时进行追加操做，不须要额外的同步操做来保证数据的一致性。本文后面还有对这些问题的细节的详细讨论。

Google已经针对不一样的应用部署了多套GFS集群。最大的一个集群拥有超过1000个存储节点，超过300TB的硬盘空间，被不一样机器上的数百个客户端接二连三的频繁访问。

2.设计概述

2.1设计预期

在设计知足咱们需求的文件系统时候，咱们的设计目标既有机会、又有挑战。以前咱们已经提到了一些须要关注的关键点，这里咱们将设计的预期目标的细节展开讨论。

系统由许多廉价的普通组件组成，组件失效是一种常态。系统必须持续监控自身的状态，它必须将组件失效做为一种常态，可以迅速地侦测、冗余并恢复失效的组件。
系统存储必定数量的大文件。咱们预期会有几百万文件，文件的大小一般在100MB或者以上。数个GB大小的文件也是广泛存在，而且要可以被有效的管理。系统也必须支持小文件，可是不须要针对小文件作专门的优化。
系统的工做负载主要由两种读操做组成：大规模的流式读取和小规模的随机读取。大规模的流式读取一般一次读取数百KB的数据，更常见的是一次读取 1MB甚至更多的数据。来自同一个客户机的连续操做一般是读取同一个文件中连续的一个区域。小规模的随机读取一般是在文件某个随机的位置读取几个KB数据。若是应用程序对性能很是关注，一般的作法是把小规模的随机读取操做合并并排序，以后按顺序批量读取，这样就避免了在文件中先后来回的移动读取位置。
系统的工做负载还包括许多大规模的、顺序的、数据追加方式的写操做。通常状况下，每次写入的数据的大小和大规模读相似。数据一旦被写入后，文件就不多会被修改了。系统支持小规模的随机位置写入操做，可是可能效率不彰。
系统必须高效的、行为定义明确的（alex 注：well-defined）实现多客户端并行追加数据到同一个文件里的语意。咱们的文件一般被用于”生产者-消费者“队列，或者其它多路文件合并操做。一般会有数百个生产者，每一个生产者进程运行在一台机器上，同时对一个文件进行追加操做。使用最小的同步开销来实现的原子的多路追加数据操做是必不可少的。文件能够在稍后读取，或者是消费者在追加的操做的同时读取文件。
高性能的稳定网络带宽远比低延迟重要。咱们的目标程序绝大部分要求可以高速率的、大批量的处理数据，极少有程序对单一的读写操做有严格的响应时间要求。

2.2 接口

GFS提供了一套相似传统文件系统的API接口函数，虽然并非严格按照POSIX等标准API的形式实现的。文件以分层目录的形式组织，用路径名来标识。咱们支持经常使用的操做，如建立新文件、删除文件、打开文件、关闭文件、读和写文件。

另外，GFS提供了快照和记录追加操做。快照以很低的成本建立一个文件或者目录树的拷贝。记录追加操做容许多个客户端同时对一个文件进行数据追加操做，同时保证每一个客户端的追加操做都是原子性的。这对于实现多路结果合并，以及”生产者-消费者”队列很是有用，多个客户端能够在不须要额外的同步锁定的状况下，同时对一个文件追加数据。咱们发现这些类型的文件对于构建大型分布应用是很是重要的。快照和记录追加操做将在3.4和3.3节分别讨论。

2.3 架构

一个GFS集群包含一个单独的Master节点（alex注：这里的一个单独的Master节点的含义是GFS系统中只存在一个逻辑上的Master组件。后面咱们还会提到Master节点复制，所以，为了理解方便，咱们把Master节点视为一个逻辑上的概念，一个逻辑的Master节点包括两台物理主机，即两台Master服务器）、多台Chunk服务器，而且同时被多个客户端访问，如图1所示。全部的这些机器一般都是普通的Linux机器，运行着用户级别(user-level)的服务进程。咱们能够很容易的把Chunk服务器和客户端都放在同一台机器上，前提是机器资源容许，而且咱们可以接受不可靠的应用程序代码带来的稳定性下降的风险。

GFS存储的文件都被分割成固定大小的Chunk。在Chunk建立的时候，Master服务器会给每一个Chunk分配一个不变的、全球惟一的 64位的Chunk标识。Chunk服务器把Chunk以linux文件的形式保存在本地硬盘上，而且根据指定的Chunk标识和字节范围来读写块数据。出于可靠性的考虑，每一个块都会复制到多个块服务器上。缺省状况下，咱们使用3个存储复制节点，不过用户能够为不一样的文件命名空间设定不一样的复制级别。

Master节点管理全部的文件系统元数据。这些元数据包括名字空间、访问控制信息、文件和Chunk的映射信息、以及当前Chunk的位置信息。Master节点还管理着系统范围内的活动，好比，Chunk租用管理(alex注：BDB也有关于lease的描述，不知道是否相同)、孤儿Chunk(alex注：orphaned chunks)的回收、以及 Chunk在Chunk服务器之间的迁移。Master节点使用心跳信息周期地和每一个Chunk服务器通信，发送指令到各个Chunk服务器并接收 Chunk服务器的状态信息。

GFS客户端代码以库的形式被连接到客户程序里。客户端代码实现了GFS文件系统的API接口函数、应用程序与Master节点和Chunk服务器通信、以及对数据进行读写操做。客户端和Master节点的通讯只获取元数据，全部的数据操做都是由客户端直接和Chunk服务器进行交互的。咱们不提供POSIX标准的API的功能，所以，GFS API调用不须要深刻到Linux vnode级别。

不管是客户端仍是Chunk服务器都不须要缓存文件数据。客户端缓存数据几乎没有什么用处，由于大部分程序要么以流的方式读取一个巨大文件，要么工做集太大根本没法被缓存。无需考虑缓存相关的问题也简化了客户端和整个系统的设计和实现。（不过，客户端会缓存元数据。）Chunk服务器不须要缓存文件数据的缘由是，Chunk以本地文件的方式保存，Linux操做系统的文件系统缓存会把常常访问的数据缓存在内存中。

2.4 单一Master节点

单一的Master节点的策略大大简化了咱们的设计。单一的Master节点能够经过全局的信息精肯定位Chunk的位置以及进行复制决策。另外，咱们必须减小对Master节点的读写，避免Master节点成为系统的瓶颈。客户端并不经过Master节点读写文件数据。反之，客户端向 Master节点询问它应该联系的Chunk服务器。客户端将这些元数据信息缓存一段时间，后续的操做将直接和Chunk服务器进行数据读写操做。

咱们利用图1解释一下一次简单读取的流程。首先，客户端把文件名和程序指定的字节偏移，根据固定的Chunk大小，转换成文件的Chunk索引。而后，它把文件名和Chunk索引起送给Master节点。Master节点将相应的Chunk标识和副本的位置信息发还给客户端。客户端用文件名和 Chunk索引做为key缓存这些信息。

以后客户端发送请求到其中的一个副本处，通常会选择最近的。请求信息包含了Chunk的标识和字节范围。在对这个Chunk的后续读取操做中，客户端没必要再和Master节点通信了，除非缓存的元数据信息过时或者文件被从新打开。实际上，客户端一般会在一次请求中查询多个Chunk信息，Master节点的回应也可能包含了紧跟着这些被请求的Chunk后面的Chunk的信息。在实际应用中，这些额外的信息在没有任何代价的状况下，避免了客户端和Master节点将来可能会发生的几回通信。

2.5 Chunk尺寸

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

选择较大的Chunk尺寸有几个重要的优势。首先，它减小了客户端和Master节点通信的需求，由于只须要一次和Mater节点的通信就能够获取Chunk的位置信息，以后就能够对同一个Chunk进行屡次的读写操做。这种方式对下降咱们的工做负载来讲效果显著，由于咱们的应用程序通常是连续读写大文件。即便是小规模的随机读取，采用较大的Chunk尺寸也带来明显的好处，客户端能够轻松的缓存一个数TB的工做数据集全部的Chunk 位置信息。其次，采用较大的Chunk尺寸，客户端可以对一个块进行屡次操做，这样就能够经过与Chunk服务器保持较长时间的TCP链接来减小网络负载。第三，选用较大的Chunk尺寸减小了Master节点须要保存的元数据的数量。这就容许咱们把元数据所有放在内存中，在2.6.1节咱们会讨论元数据所有放在内存中带来的额外的好处。

另外一方面，即便配合惰性空间分配，采用较大的Chunk尺寸也有其缺陷。小文件包含较少的Chunk，甚至只有一个Chunk。当有许多的客户端对同一个小文件进行屡次的访问时，存储这些Chunk的Chunk服务器就会变成热点。在实际应用中，因为咱们的程序一般是连续的读取包含多个 Chunk的大文件，热点还不是主要的问题。

然而，当咱们第一次把GFS用于批处理队列系统的时候，热点的问题仍是产生了：一个可执行文件在GFS上保存为single-chunk文件，以后这个可执行文件在数百台机器上同时启动。存放这个可执行文件的几个Chunk服务器被数百个客户端的并发请求访问致使系统局部过载。咱们经过使用更大的复制参数来保存可执行文件，以及错开批处理队列系统程序的启动时间的方法解决了这个问题。一个可能的长效解决方案是，在这种的状况下，容许客户端从其它客户端读取数据。

2.6 元数据

Master服务器（alex注：注意逻辑的 Master节点和物理的Master服务器的区别。后续咱们谈的是每一个Master服务器的行为，如存储、内存等等，所以咱们将所有使用物理名称）存储3种主要类型的元数据，包括：文件和Chunk的命名空间、文件和Chunk的对应关系、每一个Chunk副本的存放地点。全部的元数据都保存在 Master服务器的内存中。前两种类型的元数据（命名空间、文件和Chunk的对应关系）同时也会以记录变动日志的方式记录在操做系统的系统日志文件中，日志文件存储在本地磁盘上，同时日志会被复制到其它的远程Master服务器上。采用保存变动日志的方式，咱们可以简单可靠的更新Master服务器的状态，而且不用担忧Master服务器崩溃致使数据不一致的风险。Master服务器不会持久保存Chunk位置信息。Master服务器在启动时，或者有新的Chunk服务器加入时，向各个Chunk服务器轮询它们所存储的Chunk的信息。

2.6.1 内存中的数据结构

由于元数据保存在内存中，因此Master服务器的操做速度很是快。而且，Master服务器能够在后台简单而高效的周期性扫描本身保存的所有状态信息。这种周期性的状态扫描也用于实现Chunk垃圾收集、在Chunk服务器失效的时从新复制数据、经过Chunk的迁移实现跨Chunk服务器的负载均衡以及磁盘使用情况统计等功能。4.3和4.4章节将深刻讨论这些行为。

将元数据所有保存在内存中的方法有潜在问题：Chunk的数量以及整个系统的承载能力都受限于Master服务器所拥有的内存大小。可是在实际应用中，这并非一个严重的问题。Master服务器只须要不到64个字节的元数据就可以管理一个64MB的Chunk。因为大多数文件都包含多个 Chunk，所以绝大多数Chunk都是满的，除了文件的最后一个Chunk是部分填充的。一样的，每一个文件的在命名空间中的数据大小一般在64字节以下，由于保存的文件名是用前缀压缩算法压缩过的。

即使是须要支持更大的文件系统，为Master服务器增长额外内存的费用是不多的，而经过增长有限的费用，咱们就可以把元数据所有保存在内存里，加强了系统的简洁性、可靠性、高性能和灵活性。

2.6.2 Chunk位置信息

Master服务器并不保存持久化保存哪一个Chunk服务器存有指定Chunk的副本的信息。Master服务器只是在启动的时候轮询Chunk服务器以获取这些信息。Master服务器可以保证它持有的信息始终是最新的，由于它控制了全部的Chunk位置的分配，并且经过周期性的心跳信息监控 Chunk服务器的状态。

最初设计时，咱们试图把Chunk的位置信息持久的保存在Master服务器上，可是后来咱们发如今启动的时候轮询Chunk服务器，以后按期轮询更新的方式更简单。这种设计简化了在有Chunk服务器加入集群、离开集群、改名、失效、以及重启的时候，Master服务器和Chunk服务器数据同步的问题。在一个拥有数百台服务器的集群中，这类事件会频繁的发生。

能够从另一个角度去理解这个设计决策：只有Chunk服务器才能最终肯定一个Chunk是否在它的硬盘上。咱们从没有考虑过在Master服务器上维护一个这些信息的全局视图，由于Chunk服务器的错误可能会致使Chunk自动消失(好比，硬盘损坏了或者没法访问了)，亦或者操做人员可能会重命名一个Chunk服务器。

2.6.3 操做日志

操做日志包含了关键的元数据变动历史记录。这对GFS很是重要。这不只仅是由于操做日志是元数据惟一的持久化存储记录，它也做为判断同步操做顺序的逻辑时间基线（alex注：也就是经过逻辑日志的序号做为操做发生的逻辑时间，相似于事务系统中的LSN）。文件和Chunk，连同它们的版本(参考4.5节)，都由它们建立的逻辑时间惟一的、永久的标识。

操做日志很是重要，咱们必须确保日志文件的完整，确保只有在元数据的变化被持久化后，日志才对客户端是可见的。不然，即便Chunk自己没有出现任何问题，咱们仍有可能丢失整个文件系统，或者丢失客户端最近的操做。因此，咱们会把日志复制到多台远程机器，而且只有把相应的日志记录写入到本地以及远程机器的硬盘后，才会响应客户端的操做请求。Master服务器会收集多个日志记录后批量处理，以减小写入磁盘和复制对系统总体性能的影响。

Master服务器在灾难恢复时，经过重演操做日志把文件系统恢复到最近的状态。为了缩短Master启动的时间，咱们必须使日志足够小（alex注：即重演系统操做的日志量尽可能的少）。Master 服务器在日志增加到必定量时对系统状态作一次Checkpoint(alex注：Checkpoint是一种行为，一种对数据库状态做一次快照的行为)，将全部的状态数据写入一个Checkpoint文件（alex注：并删除以前的日志文件）。在灾难恢复的时候，Master服务器就经过从磁盘上读取这个Checkpoint文件，以及重演Checkpoint以后的有限个日志文件就可以恢复系统。Checkpoint文件以压缩B-树形势的数据结构存储，能够直接映射到内存，在用于命名空间查询时无需额外的解析。这大大提升了恢复速度，加强了可用性。

因为建立一个Checkpoint文件须要必定的时间，因此Master服务器的内部状态被组织为一种格式，这种格式要确保在Checkpoint 过程当中不会阻塞正在进行的修改操做。Master服务器使用独立的线程切换到新的日志文件和建立新的Checkpoint文件。新的Checkpoint 文件包括切换前全部的修改。对于一个包含数百万个文件的集群，建立一个Checkpoint文件须要1分钟左右的时间。建立完成后，Checkpoint 文件会被写入在本地和远程的硬盘里。

Master服务器恢复只须要最新的Checkpoint文件和后续的日志文件。旧的Checkpoint文件和日志文件能够被删除，可是为了应对灾难性的故障（alex注：catastrophes，数据备份相关文档中常常会遇到这个词，表示一种超出预期范围的灾难性事件），咱们一般会多保存一些历史文件。Checkpoint失败不会对正确性产生任何影响，由于恢复功能的代码能够检测并跳过没有完成的Checkpoint文件。

2.7 一致性模型

GFS支持一个宽松的一致性模型，这个模型可以很好的支撑咱们的高度分布的应用，同时还保持了相对简单且容易实现的优势。本节咱们讨论GFS的一致性的保障机制，以及对应用程序的意义。咱们也着重描述了GFS如何管理这些一致性保障机制，可是实现的细节将在本论文的其它部分讨论。

2.7.1 GFS一致性保障机制

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

数据修改后文件region（alex注：region这个词用中文很是难以表达，我认为应该是修改操做所涉及的文件中的某个范围）的状态取决于操做的类型、成功与否、以及是否同步修改。表1总结了各类操做的结果。若是全部客户端，不管从哪个副本读取，读到的数据都同样，那么咱们认为文件region是“一致的”；若是对文件的数据修改以后，region是一致的，而且客户端可以看到写入操做所有的内容，那么这个region是“已定义的”。当一个数据修改操做成功执行，而且没有受到同时执行的其它写入操做的干扰，那么影响的region就是已定义的（隐含了一致性）：全部的客户端均可以看到写入的内容。并行修改操做成功完成以后，region处于一致的、未定义的状态：全部的客户端看到同样的数据，可是没法读到任何一次写入操做写入的数据。一般状况下，文件region内包含了来自多个修改操做的、混杂的数据片断。失败的修改操做致使一个 region处于不一致状态（同时也是未定义的）：不一样的客户在不一样的时间会看到不一样的数据。后面咱们将描述应用如何区分已定义和未定义的region。应用程序没有必要再去细分未定义region的不一样类型。

数据修改操做分为写入或者记录追加两种。写入操做把数据写在应用程序指定的文件偏移位置上。即便有多个修改操做并行执行时，记录追加操做至少可以把数据原子性的追加到文件中一次，可是偏移位置是由GFS选择的（3.3章）（alex注：这句话有点费解，其含义是全部的追加写入都会成功，可是有可能被执行了屡次，并且每次追加的文件偏移量由GFS本身计算）。（相比而言，一般说的追加操做写的偏移位置是文件的尾部。）GFS返回给客户端一个偏移量，表示了包含了写入记录的、已定义的region的起点。另外，GFS可能会在文件中间插入填充数据或者重复记录。这些数据占据的文件region被认定是不一致的，这些数据一般比用户数据小的多。

通过了一系列的成功的修改操做以后，GFS确保被修改的文件region是已定义的，而且包含最后一次修改操做写入的数据。GFS经过如下措施确保上述行为：（a）对Chunk的全部副本的修改操做顺序一致（3.1章），（b）使用Chunk的版本号来检测副本是否由于它所在的Chunk服务器宕机（4.5章）而错过了修改操做而致使其失效。失效的副本不会再进行任何修改操做，Master服务器也再也不返回这个Chunk副本的位置信息给客户端。它们会被垃圾收集系统尽快回收。

因为Chunk位置信息会被客户端缓存，因此在信息刷新前，客户端有可能从一个失效的副本读取了数据。在缓存的超时时间和文件下一次被打开的时间之间存在一个时间窗，文件再次被打开后会清除缓存中与该文件有关的全部Chunk位置信息。并且，因为咱们的文件大多数都是只进行追加操做的，因此，一个失效的副本一般返回一个提早结束的Chunk而不是过时的数据。当一个Reader（alex注：本文中将用到两个专有名词，Reader和Writer，分别表示执行GFS读取和写入操做的程序）重新尝试并联络Master服务器时，它就会马上获得最新的Chunk位置信息。

即便在修改操做成功执行很长时间以后，组件的失效也可能损坏或者删除数据。GFS经过Master服务器和全部Chunk服务器的按期“握手” 来找到失效的Chunk服务器，而且使用Checksum来校验数据是否损坏（5.2章）。一旦发现问题，数据要尽快利用有效的副本进行恢复（4.3 章）。只有当一个Chunk的全部副本在GFS检测到错误并采起应对措施以前所有丢失，这个Chunk才会不可逆转的丢失。在通常状况下GFS的反应时间（alex注：指Master节点检测到错误并采起应对措施）是几分钟。即便在这种状况下，Chunk也只是不可用了，而不是损坏了：应用程序会收到明确的错误信息而不是损坏的数据。

2.7.2 程序的实现

使用GFS的应用程序能够利用一些简单技术实现这个宽松的一致性模型，这些技术也用来实现一些其它的目标功能，包括：尽可能采用追加写入而不是覆盖，Checkpoint，自验证的写入操做，自标识的记录。

在实际应用中，咱们全部的应用程序对文件的写入操做都是尽可能采用数据追加方式，而不是覆盖方式。一种典型的应用，应用程序从头至尾写入数据，生成了一个文件。写入全部数据以后，应用程序自动将文件更名为一个永久保存的文件名，或者周期性的做Checkpoint，记录成功写入了多少数据。 Checkpoint文件能够包含程序级别的校验和。Readers仅校验并处理上个Checkpoint以后产生的文件region，这些文件 region的状态必定是已定义的。这个方法知足了咱们一致性和并发处理的要求。追加写入比随机位置写入更加有效率，对应用程序的失败处理更具备弹性。 Checkpoint可让Writer以渐进的方式从新开始，而且能够防止Reader处理已经被成功写入，可是从应用程序的角度来看还并未完成的数据。

咱们再来分析另外一种典型的应用。许多应用程序并行的追加数据到同一个文件，好比进行结果的合并或者是一个生产者-消费者队列。记录追加方式的 “至少一次追加”的特性保证了Writer的输出。Readers使用下面的方法来处理偶然性的填充数据和重复内容。Writers在每条写入的记录中都包含了额外的信息，例如Checksum，用来验证它的有效性。Reader能够利用Checksum识别和抛弃额外的填充数据和记录片断。若是应用不能容忍偶尔的重复内容(好比，若是这些重复数据触发了非幂等操做)，能够用记录的惟一标识符来过滤它们，这些惟一标识符一般用于命名程序中处理的实体对象，例如web文档。这些记录I/O功能（alex注：These functionalities for record I/O）（除了剔除重复数据）都包含在咱们的程序共享的库中，而且适用于Google内部的其它的文件接口实现。因此，相同序列的记录，加上一些偶尔出现的重复数据，都被分发到Reader了。

3. 系统交互

咱们在设计这个系统时，一个重要的原则是最小化全部操做和Master节点的交互。带着这样的设计理念，咱们如今描述一下客户机、Master 服务器和Chunk服务器如何进行交互，以实现数据修改操做、原子的记录追加操做以及快照功能。

3.1 租约（lease）和变动顺序

（alex注：lease是数据库中的一个术语）

变动是一个会改变Chunk内容或者元数据的操做，好比写入操做或者记录追加操做。变动操做会在Chunk的全部副本上执行。咱们使用租约（lease）机制来保持多个副本间变动顺序的一致性。Master节点为Chunk的一个副本创建一个租约，咱们把这个副本叫作主Chunk。主 Chunk对Chunk的全部更改操做进行序列化。全部的副本都听从这个序列进行修改操做。所以，修改操做全局的顺序首先由Master节点选择的租约的顺序决定，而后由租约中主Chunk分配的序列号决定。

设计租约机制的目的是为了最小化Master节点的管理负担。租约的初始超时设置为60秒。不过，只要Chunk被修改了，主Chunk就能够申请更长的租期，一般会获得Master节点的确认并收到租约延长的时间。这些租约延长请求和批准的信息一般都是附加在Master节点和Chunk服务器之间的心跳消息中来传递。有时Master节点会试图提早取消租约（例如，Master节点想取消在一个已经被更名的文件上的修改操做）。即便 Master节点和主Chunk失去联系，它仍然能够安全地在旧的租约到期后和另一个Chunk副本签定新的租约。

在图2中，咱们依据步骤编号，展示写入操做的控制流程。

客户机向Master节点询问哪个Chunk服务器持有当前的租约，以及其它副本的位置。若是没有一个Chunk持有租约，Master节点就选择其中一个副本创建一个租约（这个步骤在图上没有显示）。
Master节点将主Chunk的标识符以及其它副本（又称为secondary副本、二级副本）的位置返回给客户机。客户机缓存这些数据以便后续的操做。只有在主Chunk不可用，或者主Chunk回复信息代表它已再也不持有租约的时候，客户机才须要从新跟Master节点联系。
客户机把数据推送到全部的副本上。客户机能够以任意的顺序推送数据。Chunk服务器接收到数据并保存在它的内部LRU缓存中，一直到数据被使用或者过时交换出去。因为数据流的网络传输负载很是高，经过分离数据流和控制流，咱们能够基于网络拓扑状况对数据流进行规划，提升系统性能，而不用去理会哪一个Chunk服务器保存了主Chunk。3.2章节会进一步讨论这点。
当全部的副本都确认接收到了数据，客户机发送写请求到主Chunk服务器。这个请求标识了早前推送到全部副本的数据。主Chunk为接收到的所有操做分配连续的序列号，这些操做可能来自不一样的客户机，序列号保证了操做顺序执行。它以序列号的顺序把操做应用到它本身的本地状态中（alex注：也就是在本地执行这些操做，这句话按字面翻译有点费解，也许应该翻译为 “它顺序执行这些操做，并更新本身的状态”）。
主Chunk把写请求传递到全部的二级副本。每一个二级副本依照主Chunk分配的序列号以相同的顺序执行这些操做。
全部的二级副本回复主Chunk，它们已经完成了操做。
主Chunk服务器（alex注：即主Chunk所在的 Chunk服务器）回复客户机。任何副本产生的任何错误都会返回给客户机。在出现错误的状况下，写入操做可能在主Chunk和一些二级副本执行成功。（若是操做在主Chunk上失败了，操做就不会被分配序列号，也不会被传递。）客户端的请求被确认为失败，被修改的region处于不一致的状态。咱们的客户机代码经过重复执行失败的操做来处理这样的错误。在从头开始重复执行以前，客户机会先从步骤（3）到步骤（7）作几回尝试。

若是应用程序一次写入的数据量很大，或者数据跨越了多个Chunk，GFS客户机代码会把它们分红多个写操做。这些操做都遵循前面描述的控制流程，可是可能会被其它客户机上同时进行的操做打断或者覆盖。所以，共享的文件region的尾部可能包含来自不一样客户机的数据片断，尽管如此，因为这些分解后的写入操做在全部的副本上都以相同的顺序执行完成，Chunk的全部副本都是一致的。这使文件region处于2.7节描述的一致的、可是未定义的状态。

3.2 数据流

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

为了充分利用每台机器的带宽，数据沿着一个Chunk服务器链顺序的推送，而不是以其它拓扑形式分散推送（例如，树型拓扑结构）。线性推送模式下，每台机器全部的出口带宽都用于以最快的速度传输数据，而不是在多个接受者之间分配带宽。

为了尽量的避免出现网络瓶颈和高延迟的连接（eg，inter-switch最有可能出现相似问题），每台机器都尽可能的在网络拓扑中选择一台尚未接收到数据的、离本身最近的机器做为目标推送数据。假设客户机把数据从Chunk服务器 S1推送到S4。它把数据推送到最近的Chunk服务器S1。S1把数据推送到S2，由于S2和S4中最接近的机器是S2。一样的，S2把数据传递给S3 和S4之间更近的机器，依次类推推送下去。咱们的网络拓扑很是简单，经过IP地址就能够计算出节点的“距离”。

最后，咱们利用基于TCP连接的、管道式数据推送方式来最小化延迟。Chunk服务器接收到数据后，立刻开始向前推送。管道方式的数据推送对咱们帮助很大，由于咱们采用全双工的交换网络。接收到数据后马上向前推送不会下降接收的速度。在没有网络拥塞的状况下，传送B字节的数据到R个副本的理想时间是 B/T+RL ，T是网络的吞吐量，L是在两台机器数据传输的延迟。一般状况下，咱们的网络链接速度是100Mbps（T），L将远小于1ms。所以，1MB的数据在理想状况下80ms左右就能分发出去。

3.3 原子的记录追加

GFS提供了一种原子的数据追加操做–记录追加。传统方式的写入操做，客户程序会指定数据写入的偏移量。对同一个region的并行写入操做不是串行的：region尾部可能会包含多个不一样客户机写入的数据片断。使用记录追加，客户机只须要指定要写入的数据。GFS保证至少有一次原子的写入操做成功执行（即写入一个顺序的byte流），写入的数据追加到GFS指定的偏移位置上，以后GFS返回这个偏移量给客户机。这相似于在Unix操做系统编程环境中，对以O_APPEND模式打开的文件，多个并发写操做在没有竞态条件时的行为。

记录追加在咱们的分布应用中很是频繁的使用，在这些分布式应用中，一般有不少的客户机并行地对同一个文件追加写入数据。若是咱们采用传统方式的文件写入操做，客户机须要额外的复杂、昂贵的同步机制，例如使用一个分布式的锁管理器。在咱们的工做中，这样的文件一般用于多个生产者/单一消费者的队列系统，或者是合并了来自多个客户机的数据的结果文件。

记录追加是一种修改操做，它也遵循3.1节描述的控制流程，除了在主Chunk有些额外的控制逻辑。客户机把数据推送给文件最后一个Chunk 的全部副本，以后发送请求给主Chunk。主Chunk会检查此次记录追加操做是否会使Chunk超过最大尺寸（64MB）。若是超过了最大尺寸，主 Chunk首先将当前Chunk填充到最大尺寸，以后通知全部二级副本作一样的操做，而后回复客户机要求其对下一个Chunk从新进行记录追加操做。（记录追加的数据大小严格控制在Chunk最大尺寸的1/4，这样即便在最坏状况下，数据碎片的数量仍然在可控的范围。）一般状况下追加的记录不超过 Chunk的最大尺寸，主Chunk把数据追加到本身的副本内，而后通知二级副本把数据写在跟主Chunk同样的位置上，最后回复客户机操做成功。

若是记录追加操做在任何一个副本上失败了，客户端就须要从新进行操做。从新进行记录追加的结果是，同一个Chunk的不一样副本可能包含不一样的数据–重复包含一个记录所有或者部分的数据。GFS并不保证Chunk的全部副本在字节级别是彻底一致的。它只保证数据做为一个总体原子的被至少写入一次。这个特性能够经过简单观察推导出来：若是操做成功执行，数据必定已经写入到Chunk的全部副本的相同偏移位置上。这以后，全部的副本至少都到了记录尾部的长度，任何后续的记录都会追加到更大的偏移地址，或者是不一样的Chunk上，即便其它的Chunk副本被Master节点选为了主Chunk。就咱们的一致性保障模型而言，记录追加操做成功写入数据的region是已定义的（所以也是一致的），反之则是不一致的（所以也就是未定义的）。正如咱们在 2.7.2节讨论的，咱们的程序能够处理不一致的区域。

3.4 快照

(alex注：这一节很是难以理解，总的来讲依次讲述了什么是快照、快照使用的COW技术、快照如何不干扰当前操做)

快照操做几乎能够瞬间完成对一个文件或者目录树（“源”）作一个拷贝，而且几乎不会对正在进行的其它操做形成任何干扰。咱们的用户能够使用快照迅速的建立一个巨大的数据集的分支拷贝（并且常常是递归的拷贝拷贝），或者是在作实验性的数据操做以前，使用快照操做备份当前状态，这样以后就能够轻松的提交或者回滚到备份时的状态。

就像AFS（alex注：AFS，即Andrew File System，一种分布式文件系统），咱们用标准的copy-on-write技术实现快照。当Master节点收到一个快照请求，它首先取消做快照的文件的全部Chunk的租约。这个措施保证了后续对这些Chunk的写操做都必须与Master交互交互以找到租约持有者。这就给 Master节点一个率先建立Chunk的新拷贝的机会。

租约取消或者过时以后，Master节点把这个操做以日志的方式记录到硬盘上。而后，Master节点经过复制源文件或者目录的元数据的方式，把这条日志记录的变化反映到保存在内存的状态中。新建立的快照文件和源文件指向彻底相同的Chunk地址。

在快照操做以后，当客户机第一次想写入数据到Chunk C，它首先会发送一个请求到Master节点查询当前的租约持有者。Master节点注意到Chunke C的引用计数超过了1(alex注：不太明白为何会大于1.难道是Snapshot没有释放引用计数？)。 Master节点不会立刻回复客户机的请求，而是选择一个新的Chunk句柄C`。以后，Master节点要求每一个拥有Chunk C当前副本的Chunk服务器建立一个叫作C`的新Chunk。经过在源Chunk所在Chunk服务器上建立新的Chunk，咱们确保数据在本地而不是经过网络复制（咱们的硬盘比咱们的100Mb以太网大约快3倍）。从这点来说，请求的处理方式和任何其它Chunk没什么不一样：Master节点确保新 Chunk C`的一个副本拥有租约，以后回复客户机，客户机获得回复后就能够正常的写这个Chunk，而没必要理会它是从一个已存在的Chunk克隆出来的。

4. Master节点的操做

Master节点执行全部的名称空间操做。此外，它还管理着整个系统里全部Chunk的副本：它决定Chunk的存储位置，建立新Chunk和它的副本，协调各类各样的系统活动以保证Chunk被彻底复制，在全部的Chunk服务器之间的进行负载均衡，回收再也不使用的存储空间。本节咱们讨论上述的主题。

4.1 名称空间管理和锁

Master节点的不少操做会花费很长的时间：好比，快照操做必须取消Chunk服务器上快照所涉及的全部的Chunk的租约。咱们不但愿在这些操做的运行时，延缓了其它的Master节点的操做。所以，咱们容许多个操做同时进行，使用名称空间的region上的锁来保证执行的正确顺序。

不一样于许多传统文件系统，GFS没有针对每一个目录实现可以列出目录下全部文件的数据结构。GFS也不支持文件或者目录的连接（即Unix术语中的硬连接或者符号连接）。在逻辑上，GFS的名称空间就是一个全路径和元数据映射关系的查找表。利用前缀压缩，这个表能够高效的存储在内存中。在存储名称空间的树型结构上，每一个节点（绝对路径的文件名或绝对路径的目录名）都有一个关联的读写锁。

每一个Master节点的操做在开始以前都要得到一系列的锁。一般状况下，若是一个操做涉及/d1/d2/…/dn/leaf，那么操做首先要获得目录/d1，/d1/d2，…，/d1/d2/…/dn的读锁，以及/d1/d2/…/dn/leaf的读写锁。注意，根据操做的不一样，leaf能够是一个文件，也能够是一个目录。

如今，咱们演示一下在/home/user 被快照到/save/user的时候，锁机制如何防止建立文件/home/user/foo。快照操做获取/home和/save的读取锁，以及 /home/user和/save/user的写入锁。文件建立操做得到/home和/home/user的读取锁，以及/home/user/foo的写入锁。这两个操做要顺序执行，由于它们试图获取的/home/user的锁是相互冲突。文件建立操做不须要获取父目录的写入锁，由于这里没有”目录”，或者相似inode等用来禁止修改的数据结构。文件名的读取锁足以防止父目录被删除。

采用这种锁方案的优势是支持对同一目录的并行操做。好比，能够再同一个目录下同时建立多个文件：每个操做都获取一个目录名的上的读取锁和文件名上的写入锁。目录名的读取锁足以的防止目录被删除、更名以及被快照。文件名的写入锁序列化文件建立操做，确保不会屡次建立同名的文件。

由于名称空间可能有不少节点，读写锁采用惰性分配策略，在再也不使用的时候马上被删除。一样，锁的获取也要依据一个全局一致的顺序来避免死锁：首先按名称空间的层次排序，在同一个层次内按字典顺序排序。

4.2 副本的位置

GFS集群是高度分布的多层布局结构，而不是平面结构。典型的拓扑结构是有数百个Chunk服务器安装在许多机架上。Chunk服务器被来自同一或者不一样机架上的数百个客户机轮流访问。不一样机架上的两台机器间的通信可能跨越一个或多个网络交换机。另外，机架的出入带宽可能比机架内全部机器加和在一块儿的带宽要小。多层分布架构对数据的灵活性、可靠性以及可用性方面提出特有的挑战。

Chunk副本位置选择的策略服务两大目标：最大化数据可靠性和可用性，最大化网络带宽利用率。为了实现这两个目的，仅仅是在多台机器上分别存储这些副本是不够的，这只能预防硬盘损坏或者机器失效带来的影响，以及最大化每台机器的网络带宽利用率。咱们必须在多个机架间分布储存Chunk的副本。这保证Chunk的一些副本在整个机架被破坏或掉线（好比，共享资源，如电源或者网络交换机形成的问题）的状况下依然存在且保持可用状态。这还意味着在网络流量方面，尤为是针对Chunk的读操做，可以有效利用多个机架的整合带宽。另外一方面，写操做必须和多个机架上的设备进行网络通讯，可是这个代价是咱们愿意付出的。

4.3 建立，从新复制，从新负载均衡

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

当Master节点建立一个Chunk时，它会选择在哪里放置初始的空的副本。Master节点会考虑几个因素。（1）咱们但愿在低于平均硬盘使用率的Chunk服务器上存储新的副本。这样的作法最终可以平衡Chunk服务器之间的硬盘使用率。（2）咱们但愿限制在每一个Chunk服务器上”最近”的Chunk建立操做的次数。虽然建立操做自己是廉价的，可是建立操做也意味着随之会有大量的写入数据的操做，由于Chunk在Writer真正写入数据的时候才被建立，而在咱们的”追加一次，读取屡次”的工做模式下，Chunk一旦写入成功以后就会变为只读的了。（3）如上所述，咱们但愿把 Chunk的副本分布在多个机架之间。

当Chunk的有效副本数量少于用户指定的复制因数的时候，Master节点会从新复制它。这多是由几个缘由引发的：一个Chunk服务器不可用了，Chunk服务器报告它所存储的一个副本损坏了，Chunk服务器的一个磁盘由于错误不可用了，或者Chunk副本的复制因数提升了。每一个须要被从新复制的Chunk都会根据几个因素进行排序。一个因素是Chunk现有副本数量和复制因数相差多少。例如，丢失两个副本的Chunk比丢失一个副本的 Chunk有更高的优先级。另外，咱们优先从新复制活跃（live）文件的Chunk而不是最近刚被删除的文件的Chunk（查看4.4节）。最后，为了最小化失效的Chunk对正在运行的应用程序的影响，咱们提升会阻塞客户机程序处理流程的Chunk的优先级。

Master节点选择优先级最高的Chunk，而后命令某个Chunk服务器直接从可用的副本”克隆”一个副本出来。选择新副本的位置的策略和建立时相似：平衡硬盘使用率、限制同一台Chunk服务器上的正在进行的克隆操做的数量、在机架间分布副本。为了防止克隆产生的网络流量大大超过客户机的流量，Master节点对整个集群和每一个Chunk服务器上的同时进行的克隆操做的数量都进行了限制。另外，Chunk服务器经过调节它对源Chunk服务器读请求的频率来限制它用于克隆操做的带宽。

最后，Master服务器周期性地对副本进行从新负载均衡：它检查当前的副本分布状况，而后移动副本以便更好的利用硬盘空间、更有效的进行负载均衡。并且在这个过程当中，Master服务器逐渐的填满一个新的Chunk服务器，而不是在短期内用新的Chunk填满它，以致于过载。新副本的存储位置选择策略和上面讨论的相同。另外，Master节点必须选择哪一个副本要被移走。一般状况，Master节点移走那些剩余空间低于平均值的Chunk服务器上的副本，从而平衡系统总体的硬盘使用率。

4.4 垃圾回收

GFS在文件删除后不会马上回收可用的物理空间。GFS空间回收采用惰性的策略，只在文件和Chunk级的常规垃圾收集时进行。咱们发现这个方法使系统更简单、更可靠。

4.4.1 机制

当一个文件被应用程序删除时，Master节点象对待其它修改操做同样，马上把删除操做以日志的方式记录下来。可是，Master节点并不立刻回收资源，而是把文件名改成一个包含删除时间戳的、隐藏的名字。当Master节点对文件系统命名空间作常规扫描的时候，它会删除全部三天前的隐藏文件（这个时间间隔是能够设置的）。直到文件被真正删除，它们仍旧能够用新的特殊的名字读取，也能够经过把隐藏文件更名为正常显示的文件名的方式“反删除”。当隐藏文件被从名称空间中删除，Master服务器内存中保存的这个文件的相关元数据才会被删除。这也有效的切断了文件和它包含的全部Chunk的链接（alex注：原文是This effectively severs its links to all its chunks）。

在对Chunk名字空间作相似的常规扫描时，Master节点找到孤儿Chunk（不被任何文件包含的Chunk）并删除它们的元数据。 Chunk服务器在和Master节点交互的心跳信息中，报告它拥有的Chunk子集的信息，Master节点回复Chunk服务器哪些Chunk在 Master节点保存的元数据中已经不存在了。Chunk服务器能够任意删除这些Chunk的副本。

4.4.2 讨论

虽然分布式垃圾回收在编程语言领域是一个须要复杂的方案才能解决的难题，可是在GFS系统中是很是简单的。咱们能够轻易的获得Chunk的全部引用：它们都只存储在Master服务器上的文件到块的映射表中。咱们也能够很轻易的获得全部Chunk的副本：它们都以Linux文件的形式存储在 Chunk服务器的指定目录下。全部Master节点不能识别的副本都是”垃圾”。

垃圾回收在空间回收方面相比直接删除有几个优点。首先，对于组件失效是常态的大规模分布式系统，垃圾回收方式简单可靠。Chunk可能在某些 Chunk服务器建立成功，某些Chunk服务器上建立失败，失败的副本处于没法被Master节点识别的状态。副本删除消息可能丢失，Master节点必须从新发送失败的删除消息，包括自身的和Chunk服务器的（alex 注：自身的指删除metadata的消息）。垃圾回收提供了一致的、可靠的清除无用副本的方法。第二，垃圾回收把存储空间的回收操做合并到Master节点规律性的后台活动中，好比，例行扫描和与Chunk服务器握手等。所以，操做被批量的执行，开销会被分散。另外，垃圾回收在 Master节点相对空闲的时候完成。这样Master节点就能够给那些须要快速反应的客户机请求提供更快捷的响应。第三，延缓存储空间回收为意外的、不可逆转的删除操做提供了安全保障。

根据咱们的使用经验，延迟回收空间的主要问题是，延迟回收会阻碍用户调优存储空间的使用，特别是当存储空间比较紧缺的时候。当应用程序重复建立和删除临时文件时，释放的存储空间不能立刻重用。咱们经过显式的再次删除一个已经被删除的文件的方式加速空间回收的速度。咱们容许用户为命名空间的不一样部分设定不一样的复制和回收策略。例如，用户能够指定某些目录树下面的文件不作复制，删除的文件被即时的、不可恢复的从文件系统移除。

4.5 过时失效的副本检测

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

不管什么时候，只要Master节点和Chunk签定一个新的租约，它就增长Chunk的版本号，而后通知最新的副本。Master节点和这些副本都把新的版本号记录在它们持久化存储的状态信息中。这个动做发生在任何客户机获得通知之前，所以也是对这个Chunk开始写以前。若是某个副本所在的 Chunk服务器正好处于失效状态，那么副本的版本号就不会被增长。Master节点在这个Chunk服务器从新启动，而且向Master节点报告它拥有的Chunk的集合以及相应的版本号的时候，就会检测出它包含过时的Chunk。若是Master节点看到一个比它记录的版本号更高的版本号，Master节点会认为它和Chunk服务器签定租约的操做失败了，所以会选择更高的版本号做为当前的版本号。

Master节点在例行的垃圾回收过程当中移除全部的过时失效副本。在此以前，Master节点在回复客户机的Chunk信息请求的时候，简单的认为那些过时的块根本就不存在。另一重保障措施是，Master节点在通知客户机哪一个Chunk服务器持有租约、或者指示Chunk服务器从哪一个 Chunk服务器进行克隆时，消息中都附带了Chunk的版本号。客户机或者Chunk服务器在执行操做时都会验证版本号以确保老是访问当前版本的数据。

5. 容错和诊断

咱们在设计GFS时遇到的最大挑战之一是如何处理频繁发生的组件失效。组件的数量和质量让这些问题出现的频率远远超过通常系统意外发生的频率：咱们不能彻底依赖机器的稳定性，也不能彻底相信硬盘的可靠性。组件的失效可能形成系统不可用，更糟糕的是，还可能产生不完整的数据。咱们讨论咱们如何面对这些挑战，以及当组件失效不可避免的发生时，用GFS自带工具诊断系统故障。

5.1 高可用性

在GFS集群的数百个服务器之中，在任何给定的时间一定会有些服务器是不可用的。咱们使用两条简单可是有效的策略保证整个系统的高可用性：快速恢复和复制。

5.1.1 快速恢复

无论Master服务器和Chunk服务器是如何关闭的，它们都被设计为能够在数秒钟内恢复它们的状态并从新启动。事实上，咱们并不区分正常关闭和异常关闭；一般，咱们经过直接kill掉进程来关闭服务器。客户机和其它的服务器会感受到系统有点颠簸(alex注：a minor hiccup)，正在发出的请求会超时，须要从新链接到重启后的服务器，而后重试这个请求。6.6.2章节记录了实测的启动时间。

5.1.2 Chunk复制

正如以前讨论的，每一个Chunk都被复制到不一样机架上的不一样的Chunk服务器上。用户能够为文件命名空间的不一样部分设定不一样的复制级别。缺省是 3。当有Chunk服务器离线了，或者经过Chksum校验（参考5.2节）发现了已经损坏的数据，Master节点经过克隆已有的副本保证每一个 Chunk都被完整复制（alex注：即每一个Chunk都有复制因子制定的个数个副本，缺省是3）。虽然Chunk复制策略对咱们很是有效，可是咱们也在寻找其它形式的跨服务器的冗余解决方案，好比使用奇偶校验、或者Erasure codes（alex注：Erasure codes用来解决连接层中不相关的错误，以及网络拥塞和buffer限制形成的丢包错误）来解决咱们日益增加的只读存储需求。咱们的系统主要的工做负载是追加方式的写入和读取操做，不多有随机的写入操做，所以，咱们认为在咱们这个高度解耦合的系统架构下实现这些复杂的冗余方案很有挑战性，但并不是不可实现。

5.1.3 Master服务器的复制

为了保证Master服务器的可靠性，Master服务器的状态也要复制。Master服务器全部的操做日志和checkpoint文件都被复制到多台机器上。对Master服务器状态的修改操做可以提交成功的前提是，操做日志写入到Master服务器的备节点和本机的磁盘。简单说来，一个 Master服务进程负责全部的修改操做，包括后台的服务，好比垃圾回收等改变系统内部状态活动。当它失效的时，几乎能够马上从新启动。若是Master 进程所在的机器或者磁盘失效了，处于GFS系统外部的监控进程会在其它的存有完整操做日志的机器上启动一个新的Master进程。客户端使用规范的名字访问Master（好比gfs-test）节点，这个名字相似DNS别名，所以也就能够在Master进程转到别的机器上执行时，经过更改别名的实际指向访问新的Master节点。

此外，GFS中还有些“影子”Master服务器，这些“影子”服务器在“主”Master服务器宕机的时候提供文件系统的只读访问。它们是影子，而不是镜像，因此它们的数据可能比“主”Master服务器更新要慢，一般是不到1秒。对于那些不常常改变的文件、或者那些容许获取的数据有少许过时的应用程序，“影子”Master服务器可以提升读取的效率。事实上，由于文件内容是从Chunk服务器上读取的，所以，应用程序不会发现过时的文件内容。在这个短暂的时间窗内，过时的多是文件的元数据，好比目录的内容或者访问控制信息。

“影子”Master服务器为了保持自身状态是最新的，它会读取一份当前正在进行的操做的日志副本，而且依照和主Master服务器彻底相同的顺序来更改内部的数据结构。和主Master服务器同样，“影子”Master服务器在启动的时候也会从Chunk服务器轮询数据（以后按期拉数据），数据中包括了Chunk副本的位置信息；“影子”Master服务器也会按期和Chunk服务器“握手”来肯定它们的状态。在主Master服务器因建立和删除副本致使副本位置信息更新时，“影子”Master服务器才和主Master服务器通讯来更新自身状态。

5.2 数据完整性

每一个Chunk服务器都使用Checksum来检查保存的数据是否损坏。考虑到一个GFS集群一般都有好几百台机器、几千块硬盘，磁盘损坏致使数据在读写过程当中损坏或者丢失是很是常见的（第7节讲了一个缘由）。咱们能够经过别的Chunk副原本解决数据损坏问题，可是跨越Chunk服务器比较副原本检查数据是否损坏很不实际。另外，GFS容许有歧义的副本存在：GFS修改操做的语义，特别是早先讨论过的原子纪录追加的操做，并不保证副本彻底相同(alex注：副本不是byte-wise 彻底一致的)。所以，每一个Chunk服务器必须独立维护Checksum来校验本身的副本的完整性。

咱们把每一个Chunk都分红64KB大小的块。每一个块都对应一个32位的Checksum。和其它元数据同样，Checksum与其它的用户数据是分开的，而且保存在内存和硬盘上，同时也记录操做日志。

对于读操做来讲，在把数据返回给客户端或者其它的Chunk服务器以前，Chunk服务器会校验读取操做涉及的范围内的块的Checksum。所以 Chunk服务器不会把错误数据传递到其它的机器上。若是发生某个块的Checksum不正确，Chunk服务器返回给请求者一个错误信息，而且通知 Master服务器这个错误。做为回应，请求者应当从其它副本读取数据，Master服务器也会从其它副本克隆数据进行恢复。当一个新的副本就绪后，Master服务器通知副本错误的Chunk服务器删掉错误的副本。

Checksum对读操做的性能影响很小，能够基于几个缘由来分析一下。由于大部分的读操做都至少要读取几个块，而咱们只须要读取一小部分额外的相关数据进行校验。GFS客户端代码经过每次把读取操做都对齐在Checksum block的边界上，进一步减小了这些额外的读取操做的负面影响。另外，在Chunk服务器上，Chunksum的查找和比较不须要I/O操做，Checksum的计算能够和I/O操做同时进行。

Checksum的计算针对在Chunk尾部的追加写入操做做了高度优化（与之对应的是覆盖现有数据的写入操做），由于这类操做在咱们的工做中占了很大比例。咱们只增量更新最后一个不完整的块的Checksum，而且用全部的追加来的新Checksum块来计算新的Checksum。即便是最后一个不完整的Checksum块已经损坏了，并且咱们不可以立刻检查出来，因为新的Checksum和已有数据不吻合，在下次对这个块进行读取操做的时候，会检查出数据已经损坏了。

相比之下，若是写操做覆盖已经存在的一个范围内的Chunk，咱们必须读取和校验被覆盖的第一个和最后一个块，而后再执行写操做；操做完成以后再重新计算和写入新的Checksum。若是咱们不校验第一个和最后一个被写的块，那么新的Checksum可能会隐藏没有被覆盖区域内的数据错误。

在Chunk服务器空闲的时候，它会扫描和校验每一个不活动的Chunk的内容。这使得咱们可以发现不多被读取的Chunk是否完整。一旦发现有 Chunk的数据损坏，Master能够建立一个新的、正确的副本，而后把损坏的副本删除掉。这个机制也避免了非活动的、已损坏的Chunk欺骗 Master节点，使Master节点认为它们已经有了足够多的副本了。

5.3 诊断工具

详尽的、深刻细节的诊断日志，在问题隔离、调试、以及性能分析等方面给咱们带来没法估量的帮助，同时也只须要很小的开销。没有日志的帮助，咱们很难理解短暂的、不重复的机器之间的消息交互。GFS的服务器会产生大量的日志，记录了大量关键的事件（好比，Chunk服务器启动和关闭）以及全部的RPC的请求和回复。这些诊断日志能够随意删除，对系统的正确运行不形成任何影响。然而，咱们在存储空间容许的状况下会尽可能的保存这些日志。

RPC日志包含了网络上发生的全部请求和响应的详细记录，可是不包括读写的文件数据。经过匹配请求与回应，以及收集不一样机器上的RPC日志记录，我们能够重演全部的消息交互来诊断问题。日志还用来跟踪负载测试和性能分析。

日志对性能的影响很小（远小于它带来的好处），由于这些日志的写入方式是顺序的、异步的。最近发生的事件日志保存在内存中，可用于持续不断的在线监控。

6. 度量

本节中，咱们将使用一些小规模基准测试来展示GFS系统架构和实现上的一些固有瓶颈，还有些来自Google内部使用的真实的GFS集群的基准数据。

6.1 小规模基准测试

咱们在一个包含1台Master服务器，2台Master服务器复制节点，16台Chunk服务器和16个客户机组成的GFS集群上测量性能。注意，采用这样的集群配置方案只是为了易于测试。典型的GFS集群有数百个Chunk服务器和数百个客户机。

全部机器的配置都同样：两个PIII 1.4GHz处理器，2GB内存，两个80G/5400rpm的硬盘，以及100Mbps全双工以太网链接到一个HP2524交换机。GFS集群中全部的 19台服务器都链接在一个交换机，全部16台客户机链接到另外一个交换机上。两个交换机之间使用1Gbps的线路链接。

6.1.1 读取

N个客户机从GFS文件系统同步读取数据。每一个客户机从320GB的文件集合中随机读取4MB region的内容。读取操做重复执行256次，所以，每一个客户机最终都读取1GB的数据。全部的Chunk服务器加起来总共只有32GB的内存，所以，咱们预期只有最多10%的读取请求命中Linux的文件系统缓冲。咱们的测试结果应该和一个在没有文件系统缓存的状况下读取测试的结果接近。

图三：合计吞吐量：上边的曲线显示了咱们网络拓扑下的合计理论吞吐量上限。下边的曲线显示了观测到的吞吐量。这个曲线有着95%的可靠性，由于有时候测量会不够精确。

图3（a）显示了N个客户机总体的读取速度以及这个速度的理论极限。当链接两个交换机的1Gbps的链路饱和时，总体读取速度达到理论的极限值是125MB/S，或者说每一个客户机配置的100Mbps网卡达到饱和时，每一个客户机读取速度的理论极限值是12.5MB/s。实测结果是，当一个客户机读取的时候，读取的速度是10MB/s，也就是说达到客户机理论读取速度极限值的80%。对于16个客户机，总体的读取速度达到了94MB/s，大约是理论总体读取速度极限值的75%，也就是说每一个客户机的读取速度是6MB/s。读取效率从80%下降到了75%，主要的缘由是当读取的客户机增长时，多个客户机同时读取一个Chunk服务器的概率也增长了，致使总体的读取效率降低。

6.1.2 写入

N个客户机同时向N个不一样的文件中写入数据。每一个客户机以每次1MB的速度连续写入1GB的数据。图3（b）显示了总体的写入速度和它们理论上的极限值。理论上的极限值是67MB/s，由于咱们须要把每一byte写入到16个Chunk服务器中的3个上，而每一个Chunk服务器的输入链接速度是 12.5MB/s。

一个客户机的写入速度是6.3MB，大概是理论极限值的一半。致使这个结果的主要缘由是咱们的网络协议栈。它与咱们推送数据到Chunk服务器时采用的管道模式不相适应。从一个副本到另外一个副本的数据传输延迟下降了整个的写入速度。

16个客户机总体的写入速度达到了35MB/s（即每一个客户机2.2MB/s），大约只是理论极限值的一半。和多个客户机读取的情形很类型，随着客户机数量的增长，多个客户机同时写入同一个Chunk服务器的概率也增长了。并且，16个客户机并行写入可能引发的冲突比16个客户机并行读取要大得多，由于每一个写入都会涉及三个不一样的副本。

写入的速度比咱们想象的要慢。在实际应用中，这没有成为咱们的主要问题，由于即便在单个客户机上可以感觉到延时，它也不会在有大量客户机的时候对总体的写入带宽形成显著的影响。

6.1.3 记录追加

图3（c）显示了记录追加操做的性能。N个客户机同时追加数据到一个文件。记录追加操做的性能受限于保存文件最后一个Chunk的Chunk服务器的带宽，而与客户机的数量无关。记录追加的速度由一个客户机的6.0MB/s开始，降低到16个客户机的4.8MB/s为止，速度的降低主要是因为不一样客户端的网络拥塞以及网络传输速度的不一样而致使的。

咱们的程序倾向于同时处理多个这样的文件。换句话说，即N个客户机同时追加数据到M个共享文件中，这里N和M都是数十或者数百以上。因此，在咱们的实际应用中，Chunk服务器的网络拥塞并无成为一个严重问题，若是Chunk服务器的某个文件正在写入，客户机会去写另一个文件。

6.2 实际应用中的集群

咱们如今来仔细评估一下Google内部正在使用的两个集群，它们具备必定的表明性。集群A一般被上百个工程师用于研究和开发。典型的任务是被人工初始化后连续运行数个小时。它一般读取数MB到数TB的数据，以后进行转化或者分析，最后把结果写回到集群中。集群B主要用于处理当前的生产数据。集群B的任务持续的时间更长，在不多人工干预的状况下，持续的生成和处理数TB的数据集。在这两个案例中，一个单独的”任务”都是指运行在多个机器上的多个进程，它们同时读取和写入多个文件。

6.2.1 存储

如上表前五行所描述的，两个集群都由上百台Chunk服务器组成，支持数TB的硬盘空间；两个集群虽然都存储了大量的数据，可是还有剩余的空间。 “已用空间”包含了全部的Chunk副本。实际上全部的文件都复制了三份。所以，集群实际上各存储了18TB和52TB的文件数据。

两个集群存储的文件数量都差很少，可是集群B上有大量的死文件。所谓“死文件”是指文件被删除了或者是被新版本的文件替换了，可是存储空间尚未来得及被回收。因为集群B存储的文件较大，所以它的Chunk数量也比较多。

6.2.2 元数据

Chunk服务器总共保存了十几GB的元数据，大多数是来自用户数据的、64KB大小的块的Checksum。保存在Chunk服务器上其它的元数据是Chunk的版本号信息，咱们在4.5节描述过。

在Master服务器上保存的元数据就小的多了，大约只有数十MB，或者说平均每一个文件100字节的元数据。这和咱们设想的是同样的，Master 服务器的内存大小在实际应用中并不会成为GFS系统容量的瓶颈。大多数文件的元数据都是之前缀压缩模式存放的文件名。Master服务器上存放的其它元数据包括了文件的全部者和权限、文件到Chunk的映射关系，以及每个Chunk的当前版本号。此外，针对每个Chunk，咱们都保存了当前的副本位置以及对它的引用计数，这个引用计数用于实现写时拷贝（alex注：即COW，copy-on-write）。

对于每个单独的服务器，不管是Chunk服务器仍是Master服务器，都只保存了50MB到100MB的元数据。所以，恢复服务器是很是快速的：在服务器响应客户请求以前，只须要花几秒钟时间从磁盘上读取这些数据就能够了。不过，Master服务器会持续颠簸一段时间–一般是30到60秒–直到它完成轮询全部的Chunk服务器，并获取到全部Chunk的位置信息。

6.2.3 读写速率

表三显示了不一样时段的读写速率。在测试的时候，这两个集群都运行了一周左右的时间。（这两个集群最近都由于升级新版本的GFS从新启动过了）。

集群从新启动后，平均写入速率小于30MB/s。当咱们提取性能数据的时候，集群B正进行大量的写入操做，写入速度达到了100MB/s，而且由于每一个Chunk都有三个副本的缘由，网络负载达到了300MB/s。

读取速率要比写入速率高的多。正如咱们设想的那样，总的工做负载中，读取的比例远远高于写入的比例。两个集群都进行着繁重的读取操做。特别是，集群A在一周时间内都维持了580MB/s的读取速度。集群A的网络配置能够支持750MB/s的速度，显然，它有效的利用了资源。集群B支持的峰值读取速度是 1300MB/s，可是它的应用只用到了380MB/s。

6.2.4 Master服务器的负载

表3的数据显示了发送到Master服务器的操做请求大概是每秒钟200到500个。Master服务器能够轻松的应付这个请求速度，因此 Master服务器的处理能力不是系统的瓶颈。

在早期版本的GFS中，Master服务器偶尔会成为瓶颈。它大多数时间里都在顺序扫描某个很大的目录（包含数万个文件）去查找某个特定的文件。所以咱们修改了Master服务器的数据结构，经过对名字空间进行二分查找来提升效率。如今Master服务器能够轻松的每秒钟进行数千次文件访问。若是有须要的话，咱们能够经过在名称空间数据结构以前设置名称查询缓冲的方式进一步提升速度。

6.2.5 恢复时间

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

在另一个测试中，咱们Kill掉了两个Chunk服务器，每一个Chunk服务器大约有16000个Chunk，共计660GB的数据。这两个故障致使了266个Chunk只有单个副本。这266个Chunk被GFS优先调度进行复制，在2分钟内恢复到至少有两个副本；如今集群被带入到另一个状态，在这个状态下，系统能够容忍另一个Chunk服务器失效而不丢失数据。

6.3 工做负荷分析(Workload Breakdown)

本节中，咱们展现了对两个GFS集群工做负载状况的详细分析，这两个集群和6.2节中的相似，可是不彻底相同。集群X用于研究和开发，集群Y用于生产数据处理。

6.3.1 方法论和注意事项

本章节列出的这些结果数据只包括客户机发起的原始请求，所以，这些结果可以反映咱们的应用程序对GFS文件系统产生的所有工做负载。它们不包含那些为了实现客户端请求而在服务器间交互的请求，也不包含GFS内部的后台活动相关的请求，好比前向转发的写操做，或者从新负载均衡等操做。

咱们从GFS服务器记录的真实的RPC请求日志中推导重建出关于IO操做的统计信息。例如，GFS客户程序可能会把一个读操做分红几个RPC请求来提升并行度，咱们能够经过这些RPC请求推导出原始的读操做。由于咱们的访问模式是高度程式化，因此咱们认为任何不符合的数据都是偏差(alex注：Since our access patterns are highly stylized, we expect any error to be in the noise)。应用程序若是可以记录更详尽的日志，就有可能提供更准确的诊断数据；可是为了这个目的去从新编译和从新启动数千个正在运行的客户机是不现实的，并且从那么多客户机上收集结果也是个繁重的工做。

应该避免从咱们的工做负荷数据中过分的概括出广泛的结论(alex 注：即不要把本节的数据做为基础的指导性数据)。由于Google彻底控制着GFS和使用GFS的应用程序，因此，应用程序都针对GFS作了优化，同时，GFS也是为了这些应用程序而设计的。这样的相互做用也可能存在于通常程序和文件系统中，可是在咱们的案例中这样的做用影响可能更显著。

6.3.2 Chunk服务器工做负荷

表4显示了操做按涉及的数据量大小的分布状况。读取操做按操做涉及的数据量大小呈现了双峰分布。小的读取操做（小于64KB）通常是由查找操做的客户端发起的，目的在于从巨大的文件中查找小块的数据。大的读取操做（大于512KB）通常是从头至尾顺序的读取整个文件。

在集群Y上，有至关数量的读操做没有返回任何的数据。在咱们的应用中，尤为是在生产系统中，常用文件做为生产者-消费者队列。生产者并行的向文件中追加数据，同时，消费者从文件的尾部读取数据。某些状况下，消费者读取的速度超过了生产者写入的速度，这就会致使没有读到任何数据的状况。集群X一般用于短暂的数据分析任务，而不是长时间运行的分布式应用，所以，集群X不多出现这种状况。

写操做按数据量大小也一样呈现为双峰分布。大的写操做（超过256KB）一般是因为Writer使用了缓存机制致使的。Writer缓存较小的数据，经过频繁的Checkpoint或者同步操做，或者只是简单的统计小的写入（小于64KB）的数据量(alex注：即聚集屡次小的写入操做，当数据量达到一个阈值，一次写入)，以后批量写入。

再来观察一下记录追加操做。咱们能够看到集群Y中大的记录追加操做所占比例比集群X多的多，这是由于集群Y用于咱们的生产系统，针对GFS作了更全面的调优。

表5显示了按操做涉及的数据量的大小统计出来的总数据传输量。在全部的操做中，大的操做（超过256KB）占据了主要的传输量。小的读取（小于 64KB）虽然传输的数据量比较少，可是在读取的数据量中仍占了至关的比例，这是由于在文件中随机Seek的工做负荷而致使的。

6.3.3 记录追加 vs. 写操做

记录追加操做在咱们的生产系统中大量使用。对于集群X，记录追加操做和普通写操做的比例按照字节比是108:1，按照操做次数比是8:1。对于做为咱们的生产系统的集群Y来讲，这两个比例分别是3.7:1和2.5:1。更进一步，这一组数听说明在咱们的两个集群上，记录追加操做所占比例都要比写操做要大。对于集群X，在整个测量过程当中，记录追加操做所占比率都比较低，所以结果会受到一两个使用某些特定大小的buffer的应用程序的影响。

如同咱们所预期的，咱们的数据修改操做主要是记录追加操做而不是覆盖方式的写操做。咱们测量了第一个副本的数据覆盖写的状况。这近似于一个客户机故意覆盖刚刚写入的数据，而不是增长新的数据。对于集群X，覆盖写操做在写操做所占据字节上的比例小于0.0001%，在所占据操做数量上的比例小于 0.0003%。对于集群Y，这两个比率都是0.05%。虽然这只是某一片段的状况，可是仍然高于咱们的预期。这是因为这些覆盖写的操做，大部分是因为客户端在发生错误或者超时之后重试的状况。这在本质上应该不算做工做负荷的一部分，而是重试机制产生的结果。

6.3.4 Master的工做负荷

表6显示了Master服务器上的请求按类型区分的明细表。大部分的请求都是读取操做查询Chunk位置信息（FindLocation）、以及修改操做查询lease持有者的信息（FindLease-Locker）。

集群X和Y在删除请求的数量上有着明显的不一样，由于集群Y存储了生产数据，通常会从新生成数据以及用新版本的数据替换旧有的数据。数量上的差别也被隐藏在了Open请求中，由于旧版本的文件可能在以从新写入的模式打开时，隐式的被删除了（相似UNIX的open函数中的“w”模式）。

FindMatchingFiles是一个模式匹配请求，支持“ls”以及其它相似的文件系统操做。不一样于Master服务器的其它请求，它可能会检索namespace的大部份内容，所以是很是昂贵的操做。集群Y的这类请求要多一些，由于自动化数据处理的任务进程须要检查文件系统的各个部分，以便从全局上了解应用程序的状态。与之不一样的是，集群X的应用程序更加倾向于由单独的用户控制，一般预先知道本身所须要使用的所有文件的名称。

7. 经验

在建造和部署GFS的过程当中，咱们经历了各类各样的问题，有些是操做上的，有些是技术上的。

起初，GFS被设想为咱们的生产系统的后端文件系统。随着时间推移，在GFS的使用中逐步的增长了对研究和开发任务的支持。咱们开始增长一些小的功能，好比权限和配额，到了如今，GFS已经初步支持了这些功能。虽然咱们生产系统是严格受控的，可是用户层却不老是这样的。须要更多的基础架构来防止用户间的相互干扰。

咱们最大的问题是磁盘以及和Linux相关的问题。不少磁盘都声称它们支持某个范围内的Linux IDE硬盘驱动程序，可是实际应用中反映出来的状况却不是这样，它们只支持最新的驱动。由于协议版本很接近，因此大部分磁盘均可以用，可是偶尔也会有因为协议不匹配，致使驱动和内核对于驱动器的状态判断失误。这会致使数据由于内核中的问题意外的被破坏了。这个问题促使咱们使用Checksum来校验数据，同时咱们也修改内核来处理这些由于协议不匹配带来的问题。

较早的时候，咱们在使用Linux 2.2内核时遇到了些问题，主要是fsync()的效率问题。它的效率与文件的大小而不是文件修改部分的大小有关。这在咱们的操做日志文件过大时给出了难题，尤为是在咱们还没有实现Checkpoint的时候。咱们费了很大的力气用同步写来解决这个问题，可是最后仍是移植到了Linux2.4内核上。

另外一个和Linux相关的问题是单个读写锁的问题，也就是说，在某一个地址空间的任意一个线程都必须在从磁盘page in（读锁）的时候先hold住，或者在mmap()调用（写锁）的时候改写地址空间。咱们发现即便咱们的系统负载很轻的状况下也会有偶尔的超时，咱们花费了不少的精力去查找资源的瓶颈或者硬件的问题。最后咱们终于发现这个单个锁在磁盘线程交换之前映射的数据到磁盘的时候，锁住了当前的网络线程，阻止它把新数据映射到内存。因为咱们的性能主要受限于网络接口，而不是内存copy的带宽，所以，咱们用pread()替代mmap()，用了一个额外的copy 动做来解决这个问题。

尽管偶尔仍是有其它的问题，Linux的开放源代码仍是使咱们可以快速探究和理解系统的行为。在适当的时候，咱们会改进内核而且和公开源码组织共享这些改动。

8. 相关工做

和其它的大型分布式文件系统，好比AFS[5]相似，GFS提供了一个与位置无关的名字空间，这使得数据能够为了负载均衡或者灾难冗余等目的在不一样位置透明的迁移。不一样于AFS的是，GFS把文件分布存储到不一样的服务器上，这种方式更相似Xfs[1]和Swift[3]，这是为了提升总体性能以及灾难冗余的能力。

因为磁盘相对来讲比较便宜，而且复制的方式比RAID[9]方法简单的多，GFS目前只使用复制的方式来进行冗余，所以要比 xFS或者Swift占用更多的裸存储空间(alex注：Raw storage，裸盘的空间)。

与AFS、xFS、Frangipani[12]以及Intermezzo[6]等文件系统不一样的是，GFS并无在文件系统层面提供任何 Cache机制。咱们主要的工做在单个应用程序执行的时候几乎不会重复读取数据，由于它们的工做方式要么是流式的读取一个大型的数据集，要么是在大型的数据集中随机Seek到某个位置，以后每次读取少许的数据。

某些分布式文件系统，好比Frangipani、xFS、Minnesota’s GFS[11]、GPFS[10]，去掉了中心服务器，只依赖于分布式算法来保证一致性和可管理性。咱们选择了中心服务器的方法，目的是为了简化设计，增加可靠性，可以灵活扩展。特别值得一提的是，因为处于中心位置的Master服务器保存有几乎全部的Chunk相关信息，而且控制着Chunk的全部变更，所以，它极大地简化了本来很是复杂的Chunk分配和复制策略的实现方法。咱们经过减小Master服务器保存的状态信息的数量，以及将Master 服务器的状态复制到其它节点来保证系统的灾难冗余能力。扩展能力和高可用性（对于读取）目前是经过咱们的影子Master服务器机制来保证的。对 Master服务器状态更改是经过预写日志的方式实现持久化。为此，咱们能够调整为使用相似Harp[7]中的primary-copy方案，从而提供比咱们如今的方案更严格的一致性保证。

咱们解决了一个难题，这个难题相似Lustre[8]在如何在有大量客户端时保障系统总体性能遇到的问题。不过，咱们经过只关注咱们的应用程序的需求，而不是提供一个兼容POSIX的文件系统，从而达到了简化问题的目的。此外，GFS设计预期是使用大量的不可靠节点组建集群，所以，灾难冗余方案是咱们设计的核心。

GFS很相似NASD架构[4]。NASD架构是基于网络磁盘的，而GFS使用的是普通计算机做为Chunk服务器，就像NASD原形中方案一样。所不一样的是，咱们的Chunk服务器采用惰性分配固定大小的Chunk的方式，而不是分配变长的对象存储空间。此外，GFS实现了诸如从新负载均衡、复制、恢复机制等等在生产环境中须要的特性。

不一样于与Minnesota’s GFS和NASD，咱们并不改变存储设备的Model(alex注：对这两个文件系统不了解，由于不太明白改变存储设备的Model用来作什么，这不明白这个model是模型、仍是型号)。咱们只关注用普通的设备来解决很是复杂的分布式系统平常的数据处理。

咱们经过原子的记录追加操做实现了生产者-消费者队列，这个问题相似River[2]中的分布式队列。River使用的是跨主机的、基于内存的分布式队列，为了实现这个队列，必须仔细控制数据流；而GFS采用能够被生产者并发追加记录的持久化的文件的方式实现。River模式支持m-到-n的分布式队列，可是缺乏由持久化存储提供的容错机制，GFS只支持m-到-1的队列。多个消费者能够同时读取一个文件，可是它们输入流的区间必须是对齐的。

9. 结束语

Google文件系统展现了一个使用普通硬件支持大规模数据处理的系统的特质。虽然一些设计要点都是针对咱们的特殊的须要定制的，可是仍是有不少特性适用于相似规模的和成本的数据处理任务。

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

咱们系统经过持续监控，复制关键数据，快速和自动恢复提供灾难冗余。 Chunk复制使得咱们能够对Chunk服务器的失效进行容错。高频率的组件失效要求系统具有在线修复机制，可以周期性的、透明的修复损坏的数据，也可以第一时间从新创建丢失的副本。此外，咱们使用Checksum在磁盘或者IDE子系统级别检测数据损坏，在这样磁盘数量惊人的大系统中，损坏率是至关高的。

咱们的设计保证了在有大量的并发读写操做时可以提供很高的合计吞吐量。咱们经过分离控制流和数据流来实现这个目标，控制流在Master服务器处理，而数据流在Chunk服务器和客户端处理。当通常的操做涉及到Master 服务器时，因为GFS选择的Chunk尺寸较大(alex注：从而减少了元数据的大小)，以及经过Chunk Lease将控制权限移交给主副本，这些措施将Master服务器的负担降到最低。这使得一个简单、中心的Master不会成为成为瓶颈。咱们相信咱们对网络协议栈的优化能够提高当前对于每客户端的写入吞吐量限制。

GFS成功的实现了咱们对存储的需求，在Google内部，不管是做为研究和开发的存储平台，仍是做为生产系统的数据处理平台，都获得了普遍的应用。它是咱们持续创新和处理整个WEB范围内的难题的一个重要工具。

致谢

We wish to thankt he following people for their contributions to the system or the paper. Brain Bershad (our shepherd) and the anonymous reviewers gave us valuable comments and suggestions. Anurag Acharya, Jeff Dean, and David des-Jardins contributed to the early design. Fay Chang worked on comparison of replicas across chunkservers. Guy Edjlali worked on storage quota. Markus Gutschke worked on a testing frameworkan d security enhancements. David

Kramer worked on performance enhancements. Fay Chang, Urs Hoelzle, Max Ibel, Sharon Perl, Rob Pike, and Debby Wallach commented on earlier drafts of the paper. Many of our colleagues at Google bravely trusted their data to a new file system and gave us useful feedback. Yoshka helped with early testing.

参考

[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. http://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. http://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