1.简单介绍
The Google File System发表于2003年，是分布式文件系统的奠基性文章，之后很多实际的系统以此为基础进行了实现。文章可以在网上免费获得。这篇博客的内容是本人对文章的简要分享，参考了清华大学大数据系统的分布式文件的课程。
Google设计GFS（谷歌文件系统）的出发点是为了满足Google快速增长的数据存储和处理需求。GFS与之前的分布式文件系统不同之处在于：GFS的设计主要是以Google应用的工作负载和对Google技术环境的观察为驱动（包括当前的和预期的），简单来说就是GFS是针对Google的需求开发的专用平台，而不是适合所有应用的通用平台。GFS适用于大型、分布式、数据密集型的应用程序。在普通的商用硬件上运行，提供容错功能。
实际的效果就是：GFS成功满足了公司的存储需求。GFS作为存储平台，广泛的部署在Google中，用以产生和处理数据，以供服务和研究使用。最大的集群在超过一千台计算机的数千个磁盘上提供了数百TB的存储，可以由数百个客户端并发访问。
2.设计概览
- 设计假设：
（1）系统构筑在普通的商用计算机之上，而这些计算机出现故障是常态。分布式文件系统包括数百乃至上千的普通商用计算机，同时为相当数量的客户机提供服务。文章中展示的故障有：应用的bug、操作系统bug、人为失误、磁盘失效、内存失效、连接失效、网络失效和停电。因此，必须为系统提供完整的：持续监控、错误诊断、自动恢复功能。
（2）系统存储大量文件，预期为数百万量级，典型的是100MB大小或更大，多GB大小文件也很常见，同时GFS要支持小文件。
（3）工作量主要包括两种read（读）操作：大量顺序读和少量随机读。
（4）工作量也包括顺序写（write），文件一旦写好，就很少进行修改。 - 设计架构：
GFS架构图如下：
（1）文件：文件分为固定大小的块（chunk）。 每个块由master在创建块时分配不可变且全局唯一的64位块句柄（chunk handle）识别。 Chunk servers将块作为Linux文件存储在本地磁盘上，并通过明确块句柄（chunk handle）和字节范围来读写块数据。为了可靠性，每个块都在多个hunkserver上复制。 默认情况下，存储三个副本。
（2）单一的master：单一的master简化设计、便于管理。通过将控制流和数据流分开，降低单一master的压力。Clients不通过master读写文件，而只是询问master应该与哪一个chunkserver通讯，进而与文件进行交互。维护所有文件系统元数据。 这包括命名空间，访问控制信息，从文件到块的映射以及块的当前位置。 它还控制系统范围的活动，例如块租约管理，孤立块的垃圾回收以及块服务器之间的块迁移。master定期与HeartBeat消息中的每个chunkserver通信，以便为其提供指令并收集其状态。
（3）chunk大小：chunk大小是关键设计参数之一。Google选择了64 MB，这比典型的文件系统块大小要大得多。加上惰性空间分配。
（4）chunkserver：是典型的Linux机器。文章之后提到，Linux源码的可获得性帮助工程师来理解和探索系统行为，适当的时候，对内核进行修改。最开始选择的是Linux 2.2 内核版本，后来又迁移到Linux 2.4。chunkserver将chunk保存在本地，如同普通的linux文件，可通过chunk handle和字节范围进行读和写。
（5）Metadata（元数据）：Master存储三种主要的元数据：文件和块命名空间，从文件到块的映射，以及每个块的副本的位置。所有元数据都保存在master的内存中。由于元数据存储在内存中，因此master操作很快。此外，master在后台周期性地扫描其整个状态是容易和高效的。定期扫描用于实现块垃圾回收，在chunkserver故障时重新复制，以及块迁移以平衡块服务器之间的负载和磁盘空间使用。元数据存在内存的方法的一个潜在问题是，块的数量以及整个系统的容量受到master具有多少内存的限制。这在实践中不是严重的问题。master为每个64 MB的块维护少于64个字节的元数据。例如，在文章后面可以看到在两个集群中master元数据只占内存48MB和60MB，这对于普通服务器是可以轻易达到的。如果需要支持更大的文件系统，为主机添加额外内存的成本也很小。因此，通过将元数据存储在内存中来可以获得简单性，可靠性，性能和灵活性。
（6）操作日志：操作日志包含关键元数据更改的历史记录。它是GFS的核心。它不仅是元数据的唯一持久记录，而且还充当了定义并发操作顺序的逻辑时间线。文件和块以及它们的版本都是由它们创建的逻辑时间唯一且永久地识别的。由于操作日志至关重要，因此必须可靠地存储它，并且在元数据更改持久之前不会对客户端进行更改。GFS在多台远程计算机上复制它，并且只有在本地和远程将相应的日志记录发送到磁盘后才响应客户端操作。master将多个日志记录一起批处理，从而减少了浮动和复制对整体系统吞吐量的影响。master通过重放（replaying）操作日志来恢复其文件系统状态。为了最大限度地缩短启动时间，我们必须保持日志不能过大。 只要日志超过一定大小，master就会检查其状态，以便通过从本地磁盘加载最新检查点（checkpoint）并在此之后仅重放（replaying）有限数量的日志记录来恢复。检查点（checkpoint）采用紧凑的B树形式，可以直接映射到内存中，用于命名空间查找而无需额外的解析。这进一步加快了恢复并提高了可用性。
3.一个简单的读操作
如GFS架构图所示，数据操作和控制操作分离。在一个简单的读操作中，首先，使用固定的chunk大小，client将文件名和由应用程序指定的字节转换为文件中的块索引（chunk index）。然后，它向master发送包含文件名和块索引的请求。master使用相应的块句柄（chunk handle）和副本的位置进行回复。client使用文件名和块索引作为key来缓存此信息。其次，client向其中一个副本发送请求，最大概率是距离最近的副本（根据系统网络拓扑结构，从IP地址信息进行精确估计）。该请求指定了块句柄和该块内的字节范围。在缓存的信息到期或文件重新打开之前，对同一块的进一步读取不再需要client-master交互。
4.系统交互：Leases 和 Mutation Order
Mutation是对块的内容或元数据的写入或追加操作。每个改变都在所有块的复制品上执行。Lease 中文叫租约，是一种广泛应用于分布式系统领域的协议，它是一种维护分布式系统一致性的有效工具。master将一个块租约（lease）授予其中三个存储中的一个副本，我们将其称为primary（主副本）。primary选择块的所有mutation的顺序。当数据写的顺序确定时，三个副本的储存内容就可以保持一致，因为所有副本都遵循此mutation顺序。lease机制旨在最大限度地减少master的管理开销。lease的初始设定为为60秒。如果时间到达仍然不能够完成操作，则可以进一步申请lease。
因此，全局mutation顺序首先由master选择哪一个副本作为primary确定，其次，在租约内由primary设备分配的***确定。
写入操作示意图：
写操作步骤如下所示：
- client询问master哪一个chunkserver持有当前块的lease（租约）和副本的位置。如果没有任何一个持有lease，master选择三个中的一个进行授权。
- master回复primary的位置和secondary位置，client缓存这些数据为之后的mutations做准备。
- client将数据发送给三个副本（即三个chunkserver，一个primary，两个secondary）。三个副本将数据存在LRU buffer中。通过将数据流和控制流分离，可以通过网络拓扑结构将数据以任何顺序快速发送给三个副本。
- 一旦三个副本都完全接收全部数据信息，client发送给primary写请求。primary将收到的mutation操作分配连续的***，然后将操作应用在自身的数据之上。
- primary将写请求发送给secondary，secondary将primary的mutation操作序列用于自身，则可以确保三个副本进行同样的mutation。
- secondary回复primary已经完成操作。
- primary回复client。
如果应用程序的写入内容很大或跨越块边界，client会将其分解为多个写入操作。
5.块副本
- 块副本创建
创建块副本有三个原因：块创建，重新复制和rebalancing。当master创建一个块时，选择放置位置，它考虑了几个因素：（1）GFS希望在具有低于平均磁盘空间利用率的chunkserver上放置新的副本。随着时间的推移，这将平衡chunkserver之间的磁盘利用率。（2）限制每个chunkserver上“最近”将要创建的数量，降低单个chunkserver的负载。 - 块数据完整性
每个chunkserver使用校验和来检测存储数据的损坏。chunk被分解为64 KB的block。 每个都有一个相应的32位校验和。 与其他元数据一样，校验和保存在内存中并持久存储日志记录，与用户数据分开。
6.实验
- Micro-benchmarks：
此集群由一个master，两个master副本，16个chunkserver和16个client组成。此配置是为便于测试而设置的。而更典型的集群有数百个chunkserver和数百个client。所有这些机器都配有双1.4 GHz PIII处理器，2 GB内存，两个80 GB 5400 rpm磁盘，以及与HP 2524交换机的100 Mbps全双工以太网连接。 所有19台GFS服务器机器都连接到一台交换机，所有16台client都连接到另一台交换机。两个交换机通过1 Gbps链路连接。
实验结果如下图所示，包括三个操作：read，write和record append操作：
根据图片可以看出此集群三项操作性能良好。
2.真实集群：
Google中使用的两个真实集群，这些集群代表了其他几个类似集群。集群A经常被100多名工程师用于研究和开发。典型的任务由人类用户发起并运行长达数小时。它读取几MB到几TB的数据，转换或分析数据，并将结果写回集群。集群B主要用于生产数据处理。这些任务持续时间更长，并且只需偶尔进行人为干预即可持续生成和处理多TB数据集。在这两种情况下，单个“任务”由许多机器上的许多过程组成，这些过程同时读取和写入许多文件。
下图显示两个集群的特点：
下图显示相关操作速率：
7.结论
（1）文中显示系统采取了LRU buffer和B tree等数据结构，面试中这两项也经常问到。
（2）GFS为执行各种任务的许多并发writer和read操作提供了高性能的吞吐量。GFS通过将通过文件系统控制（通过master）和数据传输（chunkserver和client直接传输）分离来实现这一点。数据和控制分离是GFS性能得到保证的关键一点。
（3）GFS是针对Google公司的专用平台，专有的设计即简洁又高效。不得不想起IBM360的例子。
（4）GFS从系统设计最底层考虑，与之前的文件系统大不相同。
（5）论文对系统的描述非常精细、准确。本人略过的描述有：chunk的定位，宽松的一致性模型，原子性Record Appends操作，snapshot，命名空间管理和锁机制，垃圾回收机制等。希望有时间的可以尝试读原文。
下一篇：MapReduce：Simplified Data Processing on Large Clusters