Google文件系统（一）

译自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中文版