1、介绍
gfs是构建在廉价服务器之上的大型分布式文件系统。
设计原则：
- gfs组件失效是常态事件，而不是意外事件。gfs构建在普通商业PC之上，这些PC的稳定性并没有很高的保障，任何时间都可能发生组件无法工作。
- gfs文件系统中存储的文件大部分是数GB的大文件。
- 绝大部分文件的修改是在文件末尾追加数据，而不是覆盖原有数据的方式。文件随机写入在实际中几乎不存在。一旦写完之后，对文件的操作就只有读，而且通常是顺序读。
2、整体架构
gfs文件系统的整体架构如图所示：
gfs文件系统一共包含四个部分：
- gfs主控服务器（master）
- chunk server
- gfs客户端
(2.1)主控服务器（master）
gfs的主控服务器是一个主从结构。有点是整个存储系统存在一个全局的主控节点，管理相对简单。缺点是很多的服务请求都需要经过主控服务器，所以很容易成为整个系统的瓶颈。
master的作用包括以下几个方面：
i、维护系统中的元数据：命名空间（文件及chunk命名空间）、文件到chunk的映射关系、chunk的存储位置信息。其中前两种需要持久化存储到磁盘，第三种可以通过chunkserver汇报获取（master服务器只需要不到64个字节的元数据就能够管理一个64M的chunk）
ii、负载均衡：包括chunk的创建、复制以及负载均衡
其中chunk的创建会根据以下因素来选择chunk副本的存放位置：
1）新副本所在的chunkserver的磁盘利用率低于平均水平；
2）限制每个chunkserver最近创建的数量。因为创建chunk往往意味着后续有大量的写入操作。
3）为了提高系统的可用性，gfs会尽量将同一个chunk的不通副本放在不同的机架上
iii、垃圾回收：gfd采用延时回收策略。当要删除文件时，gfs只是在元数据中将文件改为一个隐藏的名字，并且包含一个删除时间。master定期检查，如果发现文件删除超过一定时间，就会从内存中将元数据删除。在chunkserver通过心跳汇报chunk信息时，master会回复master元数据中已经不存在的的chunk信息，然后chunkserver会释放这些chunk副本。
iv、快照（可以瞬间完成，几乎不会对正在进行其它操作造成任何干扰）
写时复制生成快照。步骤如下：
1）通过租约机制收回对文件的每个chunk的写操作权限（master把这个操作以日志的方式记录到硬盘上），停止对文件的写操作
2）master拷贝文件名等元数据生成一个新的快照文件
3）对执行快照的文件的所有chunk增加引用计数
在快照操作之后，客户端向快照中涉及到的chunk写数据步骤：
1）询问master当前持有租约者
2）master发现当前chunk的引用大于1，通知chunkserver复制该chunk，客户端的所有追加操作转向新复制出来的chunk
（2.2）chunkserver
gfs中文件都是以固定大小(64M)来存储的，每一个chunk通过全局唯一的64位chunk handle来标识。默认情况下，每个chunk会存储3份。
3、关键问题
3.1、chunk size
对于gfs系统来说，chunk size 的默认大小是64M，比一般系统的block（4K?）要大
优点：
- 可以减少GFS client和GFS master的交互次数，chunk size比较大的时候，多次读可能是一块chunk的数据，这样，可以减少GFS client向GFS master请求chunk位置信息的请求次数。
- 对于同一个chunk，GFS client可以和GFS chunkserver之间保持持久连接，提升读的性能
- chunk size越大，chunk的metadata的总大小就越小，使得chunk相关的metadata可以存储在GFS master的内存中
缺点：
- chunk size越大时，可能对部分文件来讲只有1个chunk，那么这个时候对该文件的读写就会落到一个GFS chunkserver上，成为热点
对于热点问题，google给出的解决方案是应用层避免高频地同时读写同一个chunk。还提出了一个可能的解决方案是，GFS client找其他的GFS client来读数据
3.2、租约机制
gfs系统采用单一master节点设计，如果所有读写操作都通过master，那么master将成为系统瓶颈。因此在gfs中，master通过租约机制将chunk的写权限交给chunkserver。拥有写权限的chunkserver为主chunkserver，其他为备份。租约针对单个chunk。租约时长为60秒，且在租约结束后如果不出问题，master尽量将租约付给原持有租约的chunkserver。
3.3、一致性：gfs保证至少追加成功一次
1）出现异常：客户端会重新请求追加，因此可能出现记录在某些副本中被追加了多次，即重复记录；也可能出现一些可识别的填充记录。
2）gfs客户端支持并发追加。多个客户端之间的顺序无法保证，同一客户端连续追加成功的多个记录也可能被打断
3.4、容错机制
1）master容错机制：
i、操作日志和checkpoint。master服务器的所有操作日志和checkpoint文件都被复制到多台机器上。
ii、“影子”master服务器，非master的镜像，它们比主服务器的更新要慢，通常不到1秒
iii、持久化命名空间和文件到chunk映射的元数据
2）chunserver容错机制
i、存储多个chunk副本
ii、对存储数据进行checksum。gfs的每个chunk都分成一定大小的block，每个block都有对应的checksum。当读取一个chunk副本时，chunkserver会将读取的数据和校验和进行比较。如果比匹配，则返回客户端错误，并报告master服务器。客户端收到错误后会请求其它副本读取数据。同时master服务器也会从其它副本克隆数据进行恢复。当一个新副本就绪后，master服务器通知副本错误的chunkserver删除错误的副本
3.5、追加流程
gfs系统的追加流程特点是流水线和分离数据流和控制流。流水线操作减少延时。分离数据流和控制流可以优化数据传输（数据流可以通过精心安排的数据传输线路进行传输，每次都传到距离最近的一个chunkserver）。
3.6、过期失效的副本检测
当 Chunk 服务器失效时， Chunk 的副本有可能因错失了一些修改操作而过期失效。 Master 节点保存了每个 Chunk 的版本号，用来区分当前的副本和过期副本。
无论何时，只要 Master 节点和 Chunk 签订一个新的租约，它就增加 Chunk 的版本号，然后通知最新的副本