Google File System谷歌文件系统基本简述

思维导图

 设计理念

首先我们要了解Google File System（GFS）的目的性，以及相关的设计理念与需求。

基本目的：为了满足Google迅速增长的数据处理需求。

伴随着Google日益增长的数据流量，为了使Google能够满足相对应的数据处理，便着手设计GFS，GFS与传统的分布式文件系统有很多的相同设计目标，比如性能、可伸缩性、可靠性以及可用性。但是GFS的设计必须要基于Google自己的应用所带来的负载情况和设计环境的观察的影响，故而在不断重新审视传统的文件系统与设计上折衷选择后，衍生出不同的设计思路。

设计思路

1.确立组件失效是常态事件，而不是意外事件

GFS当被大量用户使用时，会产生许许多多的问题，比如应用程序错误、系统BUG、人为失误等问题。所以在GFS中，必须集成持续的监控、错误侦测、灾难冗余以及自动恢复等机制的存在。

2.系统存储大文件十分普遍

GFS要明确存储文件大小，以TB为数据集成。设计的假设条件以及参数如I/O操作和Block的尺寸要考虑明确。

3.系统的工作负载的读操作主要有两种：大规模的流式读取和小规模的随机读取

大规模的流式读取是通常一次读取1MB甚至更大的数据。小规模的随机读取是通常在文件的某个随机位置读取KB大小的数据。要明确规划读取模式并规划读取规则，避免在文件前后移动读取位置。

4.文件修改是采用文件尾部追加数据，不是覆盖原有数据

Google应用中针对的是海量文件的访问模式，客户端对数据块缓存没有任何意义。所以要在数据的追加操作中考虑性能优化和原子性保证。

5.系统必须实现多客户端并行追加数据到同一文件里的语义

GFS中的文件通常被用于“生产者-消费者”队列，或者其它多路文件合并操作。通常会有数百个生产者，每个生产者进程运行在同一电脑上，同时对一个文件进行追踪修改操作。因此GFS引入原子性的记录追加操作，保证多个客户能够同时进行追加操作，不需要额外进行同步操作来保证数据的一致性。

6.高性能的稳定网络带宽比低延迟重要

在GFS中，目标程序绝大部分都是要求高速率的、大批量的处理数据，极少有程序对于单一的读写操作有严格的响应时间要求。

7.GFS快照操作

GFS要十分快速的对文件或者目录进行拷贝等操作， 并且要求不能影响当前进行的操作（读/写/复制）。因此快照功能是十分必要的。

GFS架构

一个GFS集群包含一个单独的Master节点、多台Chunk服务器(Chunkserver)，并且能够同时被多个客户端访问（Client)。 

Master:维护元数据，元数据包括命名空间、访问权限、文件和Chunk的映射、Chunk的当前位置；系统级别的操作有lease管理、垃圾回收、Chunk管理，获取Chunkserver的状态。

Chunkserver：保存Chunk，用心跳包向Master报告状态，接受Master和Clinet的控制信息。

Clinet：从Master获取元数据，操作Chunkserver上的Chunk，支持open，close，create，delete，read，write，append，snapshot操作。

GFS架构简介

1.GFS文件的存储方法

GFS存储的文件都被分割成固定的大小块（Chunk），之后Master服务器会给每个Chunk分配一个不变的、全球唯一的64位的Chunk标识。Chunk服务器把Chunk以Linux文件的形式保持在本地硬盘上，并根据指定的Chunk标识来读写相对应的Chunk数据。出于可靠性考虑，每个Chunk都会复制到多个Chunk服务器上面（缺省时3个）。

2.Master节点职责

（1）管理所有的文件系统的元数据，如名字空间（namespace）、访问控制信息、文件和Chunk的映射信息、以及当前的Chunk位置信息。

（2）管理系统范围内的活动，如Chunk租用（lease）管理、孤儿Chunk的回收、以及Chunk在Chunk服务器之间的移动。

（3）使用心跳信息周期地和每个Chunk服务器通讯，发送指令到各个Chunk服务器并接收Chunk服务器的状态信息。

3.客户端

（1）GFS客户端和Master节点的通信只获取元数据，所有的数据操作都是由客户端直接和Chunk服务器进行交互。

（2）GFS客户端代码以库的形式被链接到客户端程序里，客户端代码实现GFS文件系统的API接口函数、应用程序与Master节点和Chunk服务器的通讯、以及对数据进行读写的操作。

（3）客户端缓存数据几乎没有用处，因为大部分程序以流的方式读取一个巨大的文件，或者是工作集太大根本无法被缓存。

接口实现细节

读取接口

1.Client将发送（filename，chunk index）到master

2.master 返回 (chunk handler, chunk locations) 给 client

3.client 缓存以 (filename, chunk index) 为键的返回信息，缓存在过期或重新 open 的时候刷新

4.client选择最近的 chunkserver 发送 (chunk handler, byte range)

5.chunkserver 返回数据

写入

1.client 向 master 请求拥有想要写入的 chunk 的副本，其中一个拥有 lease

2.master 接收到请求，如果没有副本有 lease，master 就发一个。master 回复 client 拥有这个 chunk 的 primary 和其他副本。在 primary 不可达或者 lease 过期的时候，client 会重新向 master 请求

3.client 将数据推送到每一个副本，chunkserver 将数据放在 LRU缓存中(LRU：最近最少使用)。为了充分利用每台机器的网络，可以做出如下改进：副本收到数据之后，向没有这个数据的最近副本转发

4.client 向 primary 发送控制信息，要求写入数据。primary 为收到的所有写入请求编号，primary 在本地按照编号写入数据

5.primary 发送写入请求给副本，要求副本按照同样的顺序执行写入操作

6.副本回复 primary

7.primary 回复 client。如果有副本没有写入成功，那么修改区域将处于不一致状态，client 重新请求写入，执行 3~7 步

GFS各个模块分析

单一Master节点

单一的Master节点可以通过全局的信息来精确定位Chunk的位置以及进行复制等相关决策。必须要减少对Master节点的读写，避免Master节点成为系统的瓶颈。

客户端并不通过Master节点来读写文件数据。客户端向Master节点询问需要联系的Chunk服务器，客户端将这些元数据信息缓存一段时间，后续操作将直接和Chunk服务器进行数据读写操作。

Chunk尺寸的选择

选择较大的Chunk尺寸可以提供便利服务

（1）减少客户端与Master节点通讯的相关需求。

（2）客户端可以与一个Chunk进行多次的操作，这样可以保持较长的TCP连接，减少网络负载。

（3）可以减少Master节点需要保持的元数据数量。

Master服务器中的元数据

主要有三种元数据：文件和Chunk的命名空间、文件和Chunk的对应关系、每个Chunk副本的存放地点。

前面两种类型的元数据同时会以记录变更日志的方式来记录在操作系统的系统日志文件中，日志文件存储在本地磁盘上面，同时日志会被复制到其它的远程Master服务器上面（避免Master崩溃所带来数据不一致的风险）。

Master不会持久保持Chunk位置的信息，每次启动时或者新Chunk服务器的加入时，向各个Chunk服务器轮流询问它们所存储的Chunk信息。并且通过周期性的心跳信息来监控Chunk服务器的状态(保证数据同步问题）。

内存中的数据结构

所有的元数据保持在内存中，因此Master服务器的操作速度快速，并且Master服务器可以在后台简单且高效的周期性扫描自己保存的全部信息。

操作日志

操作日志包含关键的元数据变更历史记录，对于GFS来说是十分重要的，因为操作日志是元数据的持久化存储记录，也作为判断同步操作顺序的逻辑时间基线。

操作日志非常重要，必须确保日志文件的完整性，确保只有在元数据的变化被持久化后，日志才对客户端是可见的。Master服务器会收集多个日志记录后进行批量处理，以减少写入磁盘和复制对系统整体性能的影响。

当Master服务器在灾难恢复时，通过重演操作日志把文件系统恢复到最近的状态。

Master服务器在日志增长到一定量时对系统状态做一次Checkpoint，将所有的状态数据写入一个Checkpoint文件。

在灾难恢复的时候，Master服务器就通过从磁盘上读取Checkpoint文件（过旧的Checkpoint文件将会被删除）。