google 公司的很多业务具有数据量巨大的特点，为此，google 公司研发了云计算技术。google 云计 算结构中的 google 文件系统是其云计算技术中的三大法宝之一。本文主要介绍了 google 公司根据自己公司应 用对文件系统的要求设计的 GFS 的体系结构，首先简单介绍了 google 云计算平台，然后介绍了 google 公司 设计的 GFS 框架，对其中的三类组件的功能、组件之间的交互和框架的特点进行了说明，接着通过介绍基于 GFS 框架构建的 google 文件系统，说明了 GFS 的框架中的组件是如何合作来完成 GFS 中的一些操作，最后 分析了 GFS 的质量属性，从中可以看到 GFS 框架很好的满足了 google 应用对文件系统的要求。
1 Google 云计算平台
1.1 云计算
云计算是一种利用互联网实现随时随地、按需、便捷地访问共享资源池的计算模式。“云”指的是一些可 以自我维护和管理的虚拟计算机资源，计算机群，通常是一些大型服务器集群，包括计算服务器、存储服务 器和宽带资源等。在云计算环境中，用户不需要了解“云”中基础设施的细节，也不需要知道“云”的相应专业知识，只需要关注自己真正需要什么资源，如何通过网络得到服务。从用户的角度来看，“云”中的资源 是可以无限扩展的，只要通过网络接入数据中心，就能随时获取、实时使用、按需扩展计算和存储资源。它 具有资源共享、无多余功能开发、资源共享、系统延续性好等特点。
1.2 google云计算
Google 是最大的云计算技术的使用者，它拥有全球最大的搜索引擎。为了解决搜索引擎以及其它的大规 模业务的海量数据存储和快速处理问题，它研发出了让百万台计算机协同工作的技术。Google 云计算平台体 系架构包括 4 个相互独立又紧密结合在一起的系统：Google 建立在集群之上的 Google File System 分布式操 作系统，针对 google 应用程序的特点提出的 Map/Reduce 编程模式，分布式的锁机制 Chubby 以及 google 开 发的模型简化的大规模分布式数据库 BigTable。 Google 已发表的论文，认为其云计算的三大法宝是：体系架构中的 Google File System(GFS)、MapReduce 和 Bigtable。其中，Google File System，即 google 文件系统，是一种分布式的文件系统。
2 GFS 体系架构
GFS 架构中有三类角色：客户（client）、主服务器（master server）和数据块服务器（chunk server）。这 三类角色的节点会构成一个 GFS 群，这个群包含一个单个的 Master 节点、多台 Chunk 服务器，多个客户端， 下面对这三类角色进行介绍。
图片待整理
2.1 各组件的介绍
2.1.1 Client
所谓的 client，是一套类似于传统文件系统的 API 接口函数，是一组专用接口，不遵守 POSIX 规范，应 用程序通过访问这些接口来实现操作，支持常用的操作，如创建新文件、删除文件、打开文件、关闭文件、 读和写文件，另外，还提供了快照和记录追加操作。根据 google 应用程序的具体情况，提供记录追加操作是 因为对文件的随机写入操作几乎不存在，读操作也通常是按顺序的，绝大部分文件的修改是采用在文件尾部 追加数据，这样的记录追加操作允许多个客户端同时对一个文件进行数据追加，对于实现多路结果合并，以 及“生产者-消费者”队列非常有用。并且记录追加操作要保证每个客户端的追加操作都是原子性的，多个客 户端可以在不需要额外的同步锁定的情况下，同时对一个文件追加数据。快照以很低的成本，几乎瞬间完成 创建一个文件或者目录树的拷贝。提供快照操作可以迅速创建一个巨大的数据集的分支拷贝，或备份当前的操作状态从而以后能够轻松的提交或者回滚到备份时的状态。客户端代码封装为库函数，以库函数的方式提 供给客户程序，被链接到客户程序里，它实现了文件系统的接口函数，应用程序与 master 节点和 chunk 服务 器通讯，以及对数据进行读写操作。
2.1.2 Chunk 服务器
Chunk 服务器负责具体的存储工作，它要做的是把 chunk 保存在本地硬盘上、读写块数据。存储的文件 都被分成固定大小的 chunk，每一个 chunk 在创建时会被 master 分配一个不变的、全球唯一的 64 位 chunk 标 识，chunk 服务器要根据这个标识和字节范围来读写块数据，chunk 在保存时是以本地文件形式保存的。为了 保证可靠性，Chunk 在不同的机器中复制多份，默认为三份，副本的有三个用途：Chunk 创建，重新复制和 重新负载均衡。Chunk 的复制是由 master 负责的。 2.1.3 Master 节点 Master 节点管理所有的文件系统元数据、管理系统范围内的活动。master 服务器存储的元数据有三类： 文件和 chunk 的命名空间、文件和 chunk 的对应关系、每个 chunk 副本的存放地点。这些信息存储在 master 服务器的内存中，保证了 master 服务器的操作速度。前两种类型的元数据也会以记录变更日志的方式记录在 操作系统的系统日志文件中，而日志文件存储在本地磁盘上，同时日志会被复制到其他的远程 master 服务器 上。第三种元数据 chunk 的存放地点不会被持久保存，只是在 master 服务启动或者有新的 chunk 服务器加入 时，由 master 向各个 chunk 服务器轮询他们所存储的 chunk 信息。master 管理的系统范围内的活动，比如， 管理整个系统内所有 chunk 的副本，决定 chunk 的存储位置，创建新 chunk 和它的副本，协调各种各样的系 统活动以保证 chunk 被完全复制，在所有的 chunk 服务器之间进行负载均衡，回收不再使用的存储空间等。
2.2 各组件之间的交互
2.2.1 Client 与 master 节点
Client 在访问文件系统时，首先访问 master 节点，获取与之进行交互的 chunk 服务器信息，然后直接访 问这些 chunk 服务器，完成数据存取工作，client 并不通过 master 节点读写文件数据，通过这样减少对 master 节点的读写，可以避免大量的读写操作造成的 master 节点成为系统的瓶颈，并且客户端通常会在一次请求中 查询多个 chunk 信息，避免了客户端和 master 节点的多次通讯。在客户端上的应用程序需要向主服务器发送 要操作的文件名和 chunk 索引，向主服务器查询所要操作的文件的具体的 chunk 位置。主服务器在收到客户 端的信息后返回给客户端 chunk 句柄和 chunk 的位置。 2.2.2 Client 与 chunk 服务器 客户端在得到主服务器的 chunk 句柄和 chunk 位置后，可以根据这些信息访问具体的 chunk 服务器，即 GFS 数据块服务器，获得文件数据。client 可以直接访问 chunk 服务器，从 chunk 服务器中得到 chunk 数据。 2.2.3 Master 与 chunk 服务器 Master 节点使用心跳信息周期地和每个 chunk 服务器通讯、发送指令到各个 chunk 服务器并接受 chunk 服务器的状态信息，这样也能保证 master 服务器持有的信息始终是最新的。在 master 服务启动或者有新的 chunk 服务器加入时，master 要向各个 chunk 服务器轮询他们所存储的 chunk 信息。Master 与 chunk 服务器之 间，master 想 chunk 服务器发送指令，chunk 服务器向 master 发送数据块服务器状态。
2.3 GFS架构的特点
(1)采用单一的 master 节点策略。单一的 master 节点策略能够简化分布式文件系统的设计，可以通过 全局的信息精确定位 chunk 的位置以及进行复制策略，由于只有一个 master，所有的云数据只有一 份，因而不存在元数据的一致性问题。
(2) 采用中心服务器模式。某些分布式文件系统的架构，比如 xFS、GPFS，去掉了中心服务器，只依赖 于分布式算法来保证一致性和关联性。选择中心服务器的方法能够简化设计，增加可靠性，能够灵 活扩展，可以方便的增加 chunk 服务器，并且由于中心服务器可以获知所有子服务器的状态，因而可以很方便的得知各个子服务器的负载状况等。但是中心服务器模式也有一个比较致命的缺点，那 就是单点故障，当单点故障发生在中心服务器时，将导致整个系统的不可用。另外，通过一些具体 的设计能够使分布式文件系统的性能得到保证：
(a)通过由处于中心位置的 Master 服务器保存几乎所有的 Chunk 相关信息、控制 Chunk 的所有变 更记录，能够极大地简化原本非常复杂的 Chunk 分配和复制策略的实现方法，并且方便进行 负载均衡。所谓负载均衡是 master 在所有 chunk 服务期间进行的负载均衡，master 检查副本 的分布情况，然后移走那些剩余空间低于平均值的 chunk 服务器上的副本，从而更好的利用硬 盘空间，平衡系统整体的硬盘使用率。
(b)通过减少 Master 服务器保存的状态信息的数量，将 Master 服务器的状态复制到其它节点，能 够保证了系统的灾难冗余能力。对 Master 服务器状态的更改可以通过预写日志的方式实现持 久化。
(c) 通过影子 Master 服务器机制保证了系统的扩展能力和高可用性。影子服务器在主 Master 服务 器宕机的时候提供文件系统的只读访问。对于那些不经常改变的文件、或者那些允许获取的 数据有少量过期的应用程序，影子 Master 服务器能够提高读取的效率。
(3)client 和 master 之间只有控制流，而没有数据流，由于控制流只需传送指令和状态，数据量小，这 点能够降低了 master 的负载，提高 master 的速度。
(4)client 与 chunk 服务器之间能够直接传输数据流，同时由于文件被分成多个 chunk 进行分布式存储， 因此 client 可以同时并行访问多个 chunk 服务器，从而提高了系统的 I/O 并行度。
3 GFS 架构应用
GFS 的框架是 google 公司针对自身应用程序的情况设计的，在这个框架上搭建了 GFS，即 google 文件系 统。
3.1 GFS
GFS 是 Google 云存储的基石，其它存储系统，如 Google Bigtable，Google Megastore，Google Percolator 均直接或者间接地构建在 GFS 之上。另外，Google 大规模批处理系统 MapReduce 也需要利用 GFS 作为海量 数据的输入输出。GFS 除了拥有过去的分布式文件系统的可伸缩性、可靠性、可用性等特点外，它的设计还 受到 Google 应用负载和技术环境的影响，GFS 在设计上的特点有以下几点：
服务器集群中个别服务器的故障是一种正常现象，而不是意外事件。由于 google 集群的节点数目非 常庞大，使用上千个服务器进行共同计算，每时每刻总会有服务器处于出故障状态，它通过软件程 序模块，监视系统的动态运行状况，侦测错误，将容错以及自动回复系统集成在系统中。
Google 系统中的文件大小通常以 G 字节计，这一点与通常文件系统中的文件大小概念不一样，并 且一个大文件可能包含大量数目的通常意义上的小文件。这一点会影响设计预期和参数，比如块尺 寸和 I/O 操作。
绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。
应用程序和文件系统 API 协同设计，提高了整个系统的灵活性。
3.2 基于GFS框架的GFS实现
Google 针对不同的应用部署多套 GFS 集群，一个 GFS 集群包含一个单个的 Master 节点、多台 Chunk 服 务器，并且被多个客户端访问。所有的作为 master、chunk、client 的节点机器通常都是普通的 linux 机器。
Google 文件系统的所有操作的实现都是通过 Master、client 与 chunk 服务器之间的交互来完成的，包括创 建新文件、删除文件、打开文件、关闭文件、读写文件、追加记录和快照功能。这里介绍这三类组件通过交 互实现的简单的读操作、写操作。
3.2.1 读操作
客户端请求读操作时，主要是向 master 节点询问应联系的 chunk 服务器，得到相关的元数据信息后，直 接和 chunk 服务器进行数据读操作。
具体的交互过程如下： 首先，客户端与 master 的交互。客户根据固定的 chunk 大小，把文件名和程序制定的字节偏移转换成文 件的 chunk 索引，再把文件名和转换得到的 chunk 索引发送给 master 节点。master 节点根据保存在内存中的 元数据，将相应的 chunk 标识和副本的位置信息发还给客户端。客户端用文件名和 chunk 索引作为关键字缓 存得到的 chunk 标识和副本位置信息。
然后是客户端与 chunk 服务器的交互。客户端从副本中选择一个最近的副本发送读操作请求。请求信息 包括 chunk 标识和字节范围。
3.2.2 写操作
客户端请求写操作时，主要是向 master 节点询问应联系的 chunk 服务器，得到相关的元数据信息后，直接对 chunk 服务器和所有的副本进行数据写操作。
在介绍写操作的交互前要引入 GFS 中的租约机制。所谓租约机制就是设定一个主 chunk，由主 chunk 来 对所有的更改操作进行序列化，从而保证多个副本间变更顺序的一致性。持有租约的 chunk 副本为主 chunk， chunk 的租约是由 Master 节点建立的。
具体的交互过程如下： 首先，客户端与 master 的交互。客户机询问 master 节点哪一个 chunk 服务器持有租约，以及其它副本的 位置。若 master 没有找打持有租约的 chunk，则为其中一个副本建立一个租约。Master 返回给客户端 Chunk 的标识符和其它副本的位置。客户机缓存 chunk 的标示符和其他副本位置。
然后是客户端和 chunk 服务器的交互。客户端以任意的顺序把数据推送到所有的副本上。Chunk 服务器 将接受到的数据保存在它的内部 LRU 缓存中。所有的副本确认接收到了数据后，客户机主 Chunk 服务器发 送写请求。这个请求标识了早前推送到所有副本的数据。
最后是主 chunk 和其他副本之间的交互。主 Chunk 为接收到的所有操作分配连续的序列号，然后以序列 号的顺序把操作应用到它自己的本地状态中。主 Chunk 把写请求传递到所有的副本。每个副本依照序列号的 顺序执行这些操作。在完成操作后，所有的副本回复主 Chunk 它们已经完成了操作。
主 Chunk 服务器回复客户机。在这个过程中，任何副本产生的任何错误都会返回给客户端。
4 GFS 质量属性
4.1 可靠性
GFS 具有高可靠性，虽然 GFS 集群中的节点采用的是可靠性较差的普通 PC，但是 GFS 针对节点失效的 问题提供了 master 容错和 master 备份。另外有提供了数据校验、负载均衡和心跳消息机制来保证 GFS 的高 可靠性。
Master 服务器内存中保存着元数据，其中文件和 chunk 的命名空间和映射表的变更记录在操作日志中， 通过这种方式，对两种元数据提供了容错功能，而 chunk 副本位置信息保存在各个 chunk 服务器上，因此如 果磁盘数据保存完好的话，在 master 发生故障时能够迅速恢复以上元数据。
Master 备份了 master 的状态、操作记录和检查点，这样，master 或硬盘失败的话，系统监视器会发现并 通过改变域名启动它的一个备份机，而由于客户端仅仅是使用名称来当问，因此不会发现 master 服务器的改 变。
在读取 chunk 副本时，chunk 服务器会将读取的数据和检验和进行比较，如果不匹配就会返回错误，然 后使客户端选择其他 chunk 服务器上的副本。
Master 通过定期重新进行均衡，把副本调整到更好的磁盘和负载分布，不会导致 chunk 服务器的过载。
Chunk 服务器会周期性的主动想 master 报告运行状态和数据状态，如果一定时间内 master 没有收到这些 信息，就认为 chunk 服务器已经宕机，然后进行复制来保证设置的副本数。
4.2 可用性
系统的可用性定义系统正常运行的时间比例，系统的可用性关注以下几个方面：如何检测系统故障，出 现故障时会发生什么情况，什么时候可以安全地出现故障，如何防止故障的发生，发生故障时要求进行哪些 通知等。
GFS 在设计时采取个别服务器的故障是一种正常现象的策略，为了保证系统的正常运行，GFS 通过软件 程序模块，监视系统的动态运行状况，侦测错误，并将容错以及自动恢复系统集成在系统中。这一点是通过 两种策略来实现的：快速恢复和复制。快速恢复是指在 master 服务器或 chunk 服务器发生故障时，他们可以 在数秒内恢复他们的状态并重新启动。复制包括 chunk 的复制和 master 服务器的复制。
当有 chunk 服务器离线，或发现损坏的数据时，master 节点会克隆已有的副本，保证每个 chunk 都被完 整复制。这样的复制使得可以对 chunk 服务器的失效进行容错。在主服务器宕机时，影子 master 服务器会提 供系统的只读访问。
另外，在系统故障的检测方面，GFS 通过持续监控来检测系统中是否有故障。
4.3 性能
性能这一质量属性经常用在单位时间内所能完成的处理数量或系统为完成一个处理所要消耗的时间来表 示。在 GFS 的性能方面，主要通过两种途径来保证系统的性能。一方面是避免 master 成为系统性能的瓶颈， 保证系统能快速的响应，处理请求。另一方面是通过缓存机制的应用使用来提高访问速度。
防止 master 成为系统性能的瓶颈。GFS 通过控制元数据的规模、对 Master 进行远程备份、控制信息和 数据分流等机制来实现的。
缓存机制的合理应用。GFS 在 chunk 服务器中不提供缓存机制，而对于 master 中存储的元数据采用了缓 存策略。虽然缓存机制是提升文件系统性能的一个手段，但是对于 GFS 的应用场景，客户端大部分是流式顺 序读写，并不存在大量的重复读写，缓存数据对系统性能提高作用不大。另一方面，master 需要对其元数据 进行频繁操作，通过缓存机制能够提高操作的效率。因此对于系统性能的提升有帮助。
5 结论
通过上述调研，针对 google 公司具体情况而设计的 GFS 框架将一个计算机群分为三类角色：客户、主 服务器和数据块服务器，客户提供一系列操作的接口，数据块服务器存放文件的数据块，主服务器管理所有 的文件系统元数据、管理系统范围内的活动，这个框架的设计不仅具有可伸缩性、可靠性、可用性等特点， 还满足了 google 的应用负载和技术环境。其中的一些思想，也可以应用在其他分布式文件系统的设计中。
文中参考:
史强. GFS云存储技术可靠性简介[J]. 福建电脑, 2012, 28(1): 76-77.
刘鹏. 云计算[M]. 北京:电子工业出版社. 2011.
万川梅. 云计算应用技术[M]. 成都:西南交通大学出版社. 2013.
李天目，韩进. 云计算技术架构与实践[M]. 北京:清华大学出版社. 2014.
蔡键, 王树梅. 基于 Google 的云计算实例分析[J]. 电脑知识与技术: 学术交流, 2009, 5(9): 7093-7095.