这就是搜索引擎(4) 云存储之Google文件系统(GFS)

1. 背景

之前说过，搜索引擎需要将互联网上百亿级别的网页内容存到本地磁盘上，基于这一存储海量数据的需求，Google开发了GFS。GFS（Google File System）为了能够存储百亿级的海量网页信息专门开发的文件系统。在Google整个云存储与云计算技术框架中，GFS是其他相关技术的基石。
而GFS的本质是一个分布式文件系统(DFS)，同类型的HDFS，阿里云的OSS都是类似的功能。

2. 分布式文件系统(DFS)

2.1 概念与定义

文件系统是计算机存储和管理数据的基本方式，当数据量足够大的时候，单台服务器无法支撑完整的信息存储，就需要多个文件系统组成文件系统网络，通过网络进行节点之间的通信，这就形成了DFS。
DFS(Distributed File System)意为分布式文件系统，指的是文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连或者使用若干个不同逻辑的磁盘分区组合在一起形成的完整的有层次的文件系统。DFS可以为分布在网络上的任意位置的资源提供逻辑上的树形文件结构，使得用户能够简便的访问网络上的共享文件。

2.2 种类

DFS根据其架构可以分为三种

1. 中间控制节点架构：代表为GFS和HDFS，部分命名节点存放管理数据，另一部分数据节点存放业务数据
2. 完全无中心架构——计算模式：代表为Ceph，客户端通过设备的映射关系通过计算方式找到写入的位置，达到客户端和存储节点直接通信
3. 完全无中心架构——一致性哈希：代表为Swift，将设备指定为哈希环，通过数据名称计算出对应的哈希值，从而映射到哈希环上实现数据定位

3. GFS

3.1 GFS设计原则

分布式文件系统多种多样，每种都根据其使用场景进行了不同的设计与开发，GFS也是在搜索引擎这个应用环境的背景下进行开发的，所以在设计之初就定下了几个基本原则。

1. GFS使用了大量商业PC来构建存储集群，因此机器的故障和死机是常态，因此设计时必须要考虑到冗余备份、自动检测、故障自动恢复等容灾手段来应对这些可能出现的问题。
2. GFS文件系统存储的绝大多数文件是大文件，在100MB到几个GB之间，因此设计系统的时候需要对这样的大文件读写做出优化
3. 系统中的文件存在大量的追加写操作，很少对已写入的内容进行更改
4. 大多数文件都是顺序读，少数是随机读

3.2 GFS整体架构

3.2.1 GFS的文件系统

在应用开发者视角下，GFS的文件系统类似于Linux文件系统，目录和目录下的文件形成树形结构。在GFS系统中，这称之为GFS命名空间。
在实际存储中，由于GFS系统存储的文件很多是大文件，因此GFS会将不同大小的文件切割为固定大小的数据块，每个数块被称为一个Chunk，Chunk的大小通常是64MB，如下图所示，大文件会由若干个固定大小的Chunk组成。
Chunk是GFS的基本存储单位，同一个文件的不同Chunk也可能存储在不同服务器中，每个Chunk服务器也可以存储多个来自于不同服务器的Chunk，在服务器内部，每个Chunk又会被切分为更小的数据块，成为Block，Block是文件读取的基本单位，一次读取至少读取一个Block。

• 为什么需要64MB的Chunk？

优势：较大的Chunk尺寸可以减少master和chunk服务器的通信，同时客户端可以对一个块多次操作，通过与Chunk服务器保持长连接来减少网络负载，同时Chunk减少可以减轻元数据的信息量，让Master能将其都放在内存中。
缺点：64MB的Chunk远大于一般文件系统的块大小，可能会产生很多的内部碎片。同时小文件只包含1个或多个Chunk，如果多个用户访问这个小文件，对应的Chunk就会成为热点，需要使用负载均衡对chunk进行复制和转移。

3.2.2 GFS的整体流程

GFS系统主要由三部分组成： GFS客户端、GFS主控服务器(Master)、众多的GFS Chunk服务器。
Maser服务器不实际存储业务数据，而是存储了文件系统的目录结构（File NameSpace）以及每个文件对应的Chunk分别存储在哪台Chunk服务器上，而Chunk服务器负责存储实际的业务数据。

1. 当应用程序对GFS客户端发起读文件请求的时候，告诉客户端需要读取的文件和数据在文件中的位置，由于Chunk大小固定为64MB，GFS客户端通过文件位置就可以获知需要读的数据处于文件的第几个Chunk
2. GFS客户端通过发送文件名与Chunk索引到Master服务器，Master服务器中存储了GFS的命名空间和文件对应的Chunk句柄与位置，因此Master可以通过映射来返回对应Chunk的句柄与ChunkServer的位置给客户端
3. GFS客户端得到需要读取的Chunk句柄与位置，直接向对应的Chunkserver发起请求，获取对应的业务数据。
4. 当GFS客户端依上述流程获取完文件的全部Chunk之后返回调用，从应用程序的视角看就是读取了一整个完整的文件。

3.2.3 GFS Master

Google的云存储平台大量的使用了主从结构，即单一主控服务器和众多存储服务器，主控服务器主要负责系统元数据的存储和管理以及整个分布式系统的管理，包括负载均衡、数据迁移、机器检测等工作。

• 这么做的好处是整个系统都存在一个全局的主控节点，管理相对简单，
• 缺点则是由于主控节点的唯一，主控服务器很容易成为整个系统的瓶颈，同时如果主控服务器失效，则整个系统都不可用

在GFS系统中，Master服务器需要维护三类元数据来维持整个系统的正常运转

1. GFS命名空间和Chunk命名空间
2. 文件到所属的Chunk之间的映射关系
3. 每个Chunk在哪台Chunk服务器之间的存储关系，特别的，由于之前提到的GFS系统由大量PC组成而导致的不稳定问题，每个Chunk都必须要有多个备份以防止因为某台机器损坏带来的数据丢失。如下图所示，每个数据都必须被保留3个备份，Chunk1/Chunk1'/Chunk1'', 他们需要存储在不同的服务器之中

这三类数据非常重要，必须要保证安全性，这三类数据的丢失会导致整个系统不可用。GFS将前两类数据保存在系统日志，而系统日志分别存储在多台机器上来避免信息丢失的问题。第三类数据保存在各自的Chunk服务器上，而主控服务器会通过定期轮询Chunk服务器来获取最新的信息。
除了存储信息之外，主控服务器还承担了系统管理的工作，例如创建新Chunk、负载均衡、在备份丢失时及时重新备份等任务。

3.2.4 系统交互行为

这里通过介绍如何进行写操作里介绍系统交互行为。
由于GFS为每个Chunk做了至少三备份，因此在用户进行写操作时，需要将操作应用到所有备份才能保证数据的一致性，GFS将其中一个备份作为主备份，其余两个作为次级备份。
GFS执行写操作的流程如下

1. GFS和主控服务器通信，来获取哪些Chunk服务器存储了需要写入的Chunk（包括主备份和次级备份）
2. GPFS客户端将需要写入的数据推送给三个Chunk Server，Chunk Serverd将数据写在缓存中并返回
3. 如果所有备份都返回成功，则GFS客户端通知主备份执行写入操作，主备份将缓存中的数据写入Chunk，成功后通知次级备份
4. 次级备份接收到来自主备份的消息之后将缓存数据写入Chunk，写入完成之后答复主备份
5. 主备份通知GFS客户端

上述步骤每一步都可能会出现问题，GFS根据每个问题都做了相应措施，以保证数据的完整性和可用性。