译自The Google File System
作者：Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung
摘要
我们设计并实现了面向大规模资料密集型应用的可扩充套件档案系统GFS。 GFS虽然执行在普遍硬件装置上，但依然具备灾难冗余能力，为大量客户机提供高效能服务。
GFS的设计目标虽然与传统的分散式档案系统有很多相同之处，但我们的设计是基于对Google应用当前和未来负载情况和技术环境的分析，因此与早期的分散式档案系统的设想存在明显的差异。所以我们重新审视了传统档案系统，最后得出了完全不同的设计思路。
GFS完全满足了我们的储存需求。作为储存平台，GFS已经在Google内部得到广泛部署，用于储存服务产生和处理的资料，同时还支援需要大规模资料集的研究和开发工作。目前为止，最大的丛集利用数千台机器的数千个硬盘提供了数百TB的储存空间，同时服务数百个客户机。
本文介绍了能够支援分散式应用的档案系统界面的扩充套件、GFS的设计、小规模效能测试结果及真实生产系统中的效能相关资料。
1 引言
我们设计并实现了适用于大规模资料密集型应用的可扩充套件档案系统GFS，满足Google不断提高的资料处理需求。GFS在效能、可扩充套件性、可靠性和可用性方面的设计目标与很多传统的分散式档案系统相似。 但GFS的设计主要还是基于对Google当前和未来应用负载情况和技术环境的观察和分析，因而与早期档案系统的设计存在显著不同。基于对传统档案系统的分析，我们设计出了全新的分散式档案系统。
第一，元件失效时常态而非异常。档案系统由数百台甚至上千台配置较低的储存机器构成，每台客户机的访问量很大。元件的数量和质量决定了机器可能会出现故障，且可能无法恢复。我们遇到过应用程序bug、操作系统bug、人为失误以及硬盘、内存、联结器、网络及电源故障引起的各种问题。因此，GFS必须含有不间断的监控、错误监测、灾难冗余以及自动恢复机制。
第二，档案很大。数GB的档案非常常见。每个档案一般都包含很多应用程序物件，如web文件。处理数亿个物件构成且快速增长的TB级资料集时，传统的管理数亿个KB级小档案的方式并不适用。 因此，设计时必须重新考虑假设条件和引数，如I/O操作和Block的大小。
第三，对绝大部分档案的修改是采用在档案尾部追加资料而非覆盖原有资料的方式。现实中几乎不存在对档案的随机写。写入之后，只能按顺序读取档案。 很多资料都具备这类特征，比如资料分析程式扫描的大型资料集，正在执行的应用程序连续生成的资料流，存档资料，以及在一台机器上生成、另一台机器上同步或异步处理的中间资料。对于海量资料的访问，客户端的快取资料块是没有用武之地的，资料追加操作才是效能优化和原子性保证重点。
第四，应用程序与档案系统API的协同设计降低了对GFS一致性模型的要求，在不对应用程序造成负担的前提下简化了档案系统。通过原子性追加操作，保证了多个客户端能够同时进行追加操作，不需要额外的同步操作。下文将对这些问题展开详细讨论。
Google已针对不同的应用部署了多套GFS丛集。最大的丛集有1000多个储存节点，300多TB的硬盘空间，被多台机器上的数百个客户端连续频繁访问。
2 设计概述
2.1 设计目标
档案系统的设计要有一定的挑战性和创新空间。之前我们已经提到了一些关键点，现在来详细讨论设计目标。
系统由很多普通商用元件构成，元件失效是常态。系统必须持续监控自身的状态，迅速侦测、冗余并恢复失效元件。系统储存一定数量的大档案，预期约为几百万，档案的大小通常为100MB及以上。数GB大小的档案也很常见，且需进行有效管理。系统也需要支援小档案，但不需要对此进行专门的优化。 系统的工作负载主要由两类读操作组成：大规模的流式读取和小规模的随机读取。大规模的流式读取通常一次读取几百KB的资料，多位1MB甚至更多的资料。来自同一个客户机的连续操作通常是读取同一个档案中的一个连续区域。小规模的随机读取通常是从档案的某个随机位置读取几KB资料。 如果应用程序对效能要求非常高，一般会合并并排序小规模的随机读取操作，之后按顺序批量读取，从而避免在档案中来回读取。系统的工作负载还包括许多大规模的顺序追加写操作。一般情况下，每次写入的资料大小与大规模读相近。一旦写入后，档案就很少会被修改了。系统支援小规模的随机位置写入操作，但效率一般。系统必须高效地将多个客户端的资料并行追加到同一个档案里。我们的档案通常用于“生产者-消费者”伫列或多路档案合并。通常情况下，执行在不同机器上的数百个生产者会同时对一个档案进行追加操作，因此，以最小的同步开销实现原子性多路资料追加操作非常重要。消费者可稍后读取档案，也可以在追加的同时读取。高效能的稳定网络带宽比低延迟更重要。我们绝大多数目标程式要求能够快速大批量地处理资料，很少有程式对单一的读写操作有严格的响应时间要求。2.2 界面
GFS提供了一套类似传统档案系统的API界面函式，但界面并不是严格按照POSIX等标准API的形式实现的。档案以分层目录的形式组织，用路径名来标识。我们支援常用的操作，包括建立、删除、开启、关闭以及读写档案。
另外，GFS能够快照并记录追加操作。快照能以较低的成本建立档案或目录树副本。记录追加操作支援多个客户端同时对一个档案进行资料追加操作，保证每个客户端的追加操作都是原子性的。这对于实现多路结果合并及“生产者-消费者”伫列非常有用，多个客户端可以在不需要额外同步锁定的情况下，同时对一个档案追加资料。我们发现这类档案对于构建大型分布应用非常重要。快照和记录追加操作的功能将在第3.4和3.3节分别讨论。
2.3 架构
一个GFS丛集包含一个Master节点和多台资料块服务器，同时被多个客户端访问，如图1所示。这些机器一般是商用Linux机器，执行着使用者级的服务程序。只要机器资源允许，且能够接受不可靠应用程序程式码对稳定性的影响，便可以把资料块服务器和客户端部署在同一台机器上。
图1 GFS架构
GFS储存的档案都被分割成固定大小的资料块。建立资料块时，Master服务器会给每个资料块分配不变且唯一的64位标识。资料块服务器以Linux档案的形式把资料块储存在本地硬盘上，根据指定的资料块标识和字节范围读写资料块。为了提高可靠性，每个资料块都会复制到多个数据块服务器上。预设条件下，我们使用3个储存复制节点，不过使用者可以为不同的档案名称空间设定不同的复制级别。
Master节点管理所有档案系统的元资料，包括名称空间、访问控制资讯、档案和资料块的对映资讯以及当前资料块的位置资讯。Master节点还管理著系统范围内的相关活动，如资料块租用管理、孤立资料块回收以及资料块在资料块服务器之间的迁移。 Master节点定期使用心跳资讯与每个资料块服务器通讯，向各个资料块服务器传送指令，并接收资料块服务器的状态资讯。
GFS客户端程式码以库的形式连结到客户程式中，客户端程式码实现了GFS档案系统的API界面函式，并与Master节点和资料块服务器通讯，完成应用程序对资料的读写操作。客户端和Master节点的通讯只获取元资料，所有的资料操作都是由客户端与资料块服务器直接互动完成的。我们不提供POSIX标准的API功 能，因此GFS API呼叫不需要深入到Linux vnode级别。
客户端和Chunk服务器均不快取档案资料。客户端快取资料几乎没有什么用处，因为大部分程式要么以流的方式读取大型档案，要么工作集太大根本无法被快取。不考虑快取问题也简化了客户端和整个系统的设计和实现。（但客户端会快取元资料。）资料块服务器不需要快取档案资料，因为资料块以本地档案的形式储存，Linux操作系统的档案系统快取会把经常访问的资料快取在内存中。
参考资料
1.Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Google File System
2. Yan Wei. The Google File System中文版
