分布式存储技术探讨系列：GFS

## 1. 什么是GFS？

首先，我们从 GFS 的定义： “Google File System (GFS) is a scalable distributed file system (DFS) created by Google Inc. and developed to accommodate Google’s expanding data processing requirements. GFS provides fault tolerance, reliability, scalability, availability and performance to large networks and connected nodes . ” 。 当中我们可以非常明确看到 GFS区别于Ceph和SWift的核心在于它是一个文件系统，但是这个文件系统又是区别于我们Linux操作系统上普通的EXT文件系统，它具有分布式架构，因此它被赋予了以下特性 ：

（1） 扩展性 （ Scalability ） ：它具备较强的架构扩展性，可以使得数据规模很容易扩展到PB级别；

（2） 高可用（ availability ）：它具备较强的集群高可用性，能解决节点故障对集群的可用性影响 ；

（3） 容错性 （ Fault Tolerance ）： 它具备很强的数据容错性，能解决数据错误的问题 ；

除此之外，我们还要知道它的来源，它是谷歌的杰出作品，是谷歌三驾马车（GFS、Big Table、Mapreduce）三个当中的一个，而且对应着谷歌著名的三篇论文当中的一篇，支持所有谷歌服务的基石。 接下来，我们 从各个维度来分析究竟是什么样的架构和原理使它具备了这样的分布式特性 。

2. GFS 架构原理

2.1 GFS物理架构

从 物理节点角度看GFS的架构，它主要分为三个部分：Client、Master Server、Chunk Server。应用的数据读写请求从Client端发起，先经过Master Server查询元数据信息，得到元数据信息之后再到Chunk Server寻找数据本身或者写入数据本身。如图2.1：

图2.1 GFS物理拓扑图

Client： 是GFS提供给应用程序的访问接口，它是一组专用接口，以库文件的形式提供。应用程序直接调用这些库函数来获取数据的访问。它的输入仅仅需要文件名称及其在GFS系统当中的全路径。

Master：是GFS的集群管理节点，可以是主备模式，当然也可以是AA模式的集群。但是它的数据空间只有一个。它主要负责保存GFS的元数据及集群的协调管理。

Chunk：它是存储数据的节点，它可以扩展为很多。它主要负责响应客户端的实际数据读写，数据以文件的形式存储在Chunk Server上，文件组织的粒度为Chunk（默认为64M）。既然是文件系统的存储管理方式，那必然是Chunk_ID+Chunk_Address的组织管理模式。

2.2 GFS Master

既然Master是GFS的核心管理节点，那么搞清楚Master里面的运作机制就是搞清楚GFS的必要条件，首先我们来看Master Server存储的元数据是什么样的？我们在文章前面内容当中曾经说过，GFS排除它的分布式而言，它就是一个文件系统。既然是文件系统就会遵循文件存取的基本规则：客户端按照全路径文件名称存放或者读取文件。如图2.2：

图2. 2 Master命名空间图

对于Master Server上保存的Metadata来讲，主要包含两个维度的数据，一个是文件的命名空间，它是一个树状的数据结构，也就是文件目录树。另外一方面，对于这个目录树的每一个叶子节点，也就是对应的每一个文件的元数据，它是一组Key-Value（Chunk标识，Chunk_Servers ）。还有一点非常重要，那就是以上所述的Metadata，会在Master节点的内存当中保留缓存，其主要目的是为了快速返回客户端的元数据请求。

除了元数据的管理，Master还有比较重要的工作就是对Chunk Server的管理。如图2.2.2：

图2. 2.1 GFS Master and Chunk

Master需要和Chunk Server进行交互，从而收集一些必要信息（Chunk Server上的文件映射关系更新版本、Chunk Server节点本身以及它的磁盘及数据副本健康状况）。另外，根据收集的信息决定其下一步对Chunk Server的控制操作，包括更新自己的元数据信息，告诉Chunk Server从别的Chunk Server副本来复制完成对损坏数据的恢复，定期对数据分布的平衡性进行评估并通知Chunk Server去做数据的再平衡，重新仲裁数据副本的主节点等。

2.3 GFS Chunk Server

对于Chunk Server来讲，其实它就是负责具体存储文件本身的服务器节点，它可以横向扩张其节点数量，有较强的伸缩性。对于它的理解，我们需要掌握以下几个点：

1. 每一个Chunk Server都是安装了Linux操作系统的服务器节点，文件系统都是普通Linux FS（例如ext3）；
2. 每一个存储块Chunk都是文件，遵守文件系统I节点映射的规则；
3. 每一个Chunk默认为64M；
4. GFS对Chunk Server里面的文件系统元数据不做缓存，它的缓存只是Linux操作系统自身的缓存。

3. GFS读写原理

3.1 GFS数据副本控制

对于分布式系统来讲，GFS采用的是中心化副本控制协议，即对于副本集的更新操作有一个中心节点来协调管理，将分布式的并发操作转化为单点的并发操作，从而保证副本集内各节点的一致性。在GFS中，中心节点称之为Primary，非中心节点成为Secondary。中心节点是GFS Master通过lease选举的 。

图 3.1 数据副本控制机制

从图 3 . 1 当中，我们可以看到 数据写的过程是三副本都正常返回才算一个完整的写完成。当Master节点通过与Chunk节点之间的探测之后，发现当中的主节点发生故障，Master节点会利用Lease选举机制重新选择新的主Chunk节点，并且通知Chunk发起数据复制恢复的操作，直到所有操作完成将Chunk映射元数据同步给Master。

虽然我们从图中可以看到完整有序的控制信息序列，但是在Chunk节点之间的数据复制同步过程当中，这个操作是动态的。GFS会赋予Chunk节点一种最优路径选择机制，让他们自己决定如何数据同步路由。

3.2 GFS Chunk数据分布算法

GFS中Chunk以多副本的形式存储以提高数据的高可用性。那么如何选择各Chunk数据的存放位置就显得直观重要，好的Chunk位置定义算法满足几个条件：

1. 保证足够的物理故障隔离性，将不同的Chunk数据副本存放于不同的故障隔离域；
2. 保证写入高效性，多副本位置尽量靠近，降低写入延迟，提高读写性能。

GFS在论文中并没有详细说明其数据的分布算法，但是基本说明了算法的基本原则：

1. 选择存储空间利用率最低的节点和磁盘；
2. 选择最近一段时间内新建Chunk数量较少的节点和磁盘；
3. 将多个副本分散在不同的Rack上。

4. 结语

总结来看，GFS作为分布式存储技术体系的一个分支，但是它与我们曾经介绍的Ceph、Swift都有很大的区别，首先、它的底层架构是基于文件系统实现的分布式存储系统，因此管理数据的方式也是传统的文件模式。其次、它是一个有中心状态的架构，需要借助于Master节点的元数据查询来实现数据的寻址，并不是通过哈希算法的来定位，因此它的扩展性会受到Master节点本身空间的限制。再次、从它的文件存储单元默认设计参数64M来看，它是一个适合于存储大文件的分布式文件系统。最后，GFS在数据读写的过程当中，仅对Append提供原子性，因此它更适合于顺序写的场景。