GFS

前言：Google大数据处理的3篇核心论文

《The Google File System》：http://research.google.com/archive/gfs.html

《MapReduce: Simplified Data Processing on Large Clusters 》：http://research.google.com/archive/mapreduce.html

《Bigtable: A Distributed Storage System for Structured Data》：http://research.google.com/archive/bigtable.html

GFS（Google文件系统）作为一个分布式文件系统，为Google提供基础的海量数据存储服务。虽然GFS并没有开源，但Google在其04年发表的论文《The Google File System》里面做了详细的介绍，很多设计思路都很有学习的价值。由于论文很长，这里对这篇论文做个学习笔记，总结一下。

-----------------------------------------------------------------------------------------------------------------------------------

一、简介

重新审视传统文件系统在设计上的折忠选择，衍生了GFS不同的设计思路：

*、组件/机器失效是常态，而不是意外事件（容错性）

*、处理的文件巨大（大数据）

*、绝大多数文件写操作都是尾部追加数据，而不是随机写（读写模型）

*、应用程序和文件系统API协同设计，简化对GFS的要求（灵活性）

二、设计概述

1、架构：

* GFS Master（即NameNode）：单独节点，管理GFS所有元数据（如名字空间、访问控制权限等）

* GFS ChunkServer（即DataNode）：数据存储节点，文件被分割为固定大小的Chunk，每个Chunk被唯一标识，默认情况下，Chunk存储为3个副本。

* GFS Client：实现GFS的API接口函数（不是POSIX标准，因为API只需在用户空间调用）

2、单一的Master节点

* 单一的Master简化了设计，使架构能变得简单

* 缺点是有可能成为系统瓶颈，故需减少对Master的读写 => Client只询问Master相关文件的元数据信息，后面的具体读写操作均在ChunkServer上

* Master一般会返回离Client最近的文件副本（减少网络IO）

3、Chunk的大小选择

* 是一个关键的设计参数，默认为64MB。每个Chunk都以普通Linux文件存储在ChunkServer上

* 较大Chunk尺寸的优点：1 减少Client和Master通讯。2、减少Master存储元数据的大小 3 Client对一个Chunk能进行多次操作，减少网络IO。

* 较大Chunk尺寸的缺点：小文件会存储为一个Chunk，多个Client同时对单个小文件多次操作时，存放这个Chunk的ChunkServer会成为热点

4、元数据

* 均存储于Master服务器的内存中（性能优势），缺点为受限于内存的大小=>一些可能的压缩，如文件名等

* 主要有3类：1、命名空间。2、文件和Chunk的映射关系（文件包含哪些Chunk）。3、每个Chunk副本的存放信息

* 命名空间及文件和Chunk的映射关系，均以记录变更日志的方式落地为系统日志文件，并复制到远程Master备机上。

* Chunk副本的位置信息为Master周期性向各个ChunkServer轮询获得 => 没有落地，避免了ChunkServer变更时的Master和ChunkServer的数据同步问题

* 操作日志记录了关键元数据变更历史，对Master的容灾非常重要，故只有在元数据变更持久化到日志后，才会对Client可见。为了避免操作日志过长，GFS定期会对当前操作日志做一次Checkpoint，以压缩B+树形式存储为一个CheckPoint文件。

* 故Master的恢复只需最新的CheckPoint文件和后续的操作日志。

5、一致性模型

* 命名空间修改为原子性的，由Master的命名空间锁保障

三、系统交互

* 设计原则：最小化所有操作和Master的交互

1、租约（lease）机制和数据变更顺序

  

* 租约机制：Master确定一个Chunk副本为主Chunk，给其建立租约，然后主Chunk对更改操作序列化，所有Chunk副本遵循这个序列执行更改操作

* 使用租约机制来保障数据多个副本变更（写/修改操作）顺序的一致性，租约序列由主Chunk产生，最小化Master管理负担

2、数据流

* GFS将数据流和控制流分离，数据流顺序沿着一个ChunkServer链推送，目的是为了充分利用机器带宽，最小化推送时延

* 基于TCP连接的，管道式数据推送方式。1MB数据理想状态下80ms左右能分发出去

* 每台ChunkServer会选取里离自己最近的机器做目标推送，Google的网络拓扑较简单，通过IP地址就可计算出节点“距离”

3、原子的记录追加

* GFS提供一种具有原子性的数据追加操作：记录追加。即Client只需指定要写入数据（而不用指定偏移值），GFS就保证至少有一次原子的写入操作执行成功，并返回偏移值的Client

* 记录追加的引入是为了在分布式应用中，减少很多Client并行对同份数据写入的同步机制开销

4、快照

* Client快照请求的理解：对一个文件或者目录树做一次拷贝

* GFS使用copy-on-write技术来实现快照：收到快照请求时，Master并没有立即对指定Chunk拷贝，而只拷贝其元数据并对指定Chunk的引用计数增1。等到Client需要修改指定Chunk时，再在本地复制，并却保新Chunk拥有租约

四、Master节点操作

1、命名空间管理和锁

* 名字空间的组织：全路径和元数据映射关系的查找表，利用前缀压缩，高效存储在内存中

* 名字空间树型结构每个节点都有一个读写锁，每个操作开始前都需获得路径上所有的读写锁 

    - 锁策略的设计与实现
* 避免死锁方法：锁的获取依据全局一致的顺序，先按名字空间层次排序，同一层次按字典序排序

2、Chunk副本的位置
* Chunk副本的位置选择策略两大目标：1 提高数据可靠性 2 提高网络带宽利用率
* 一个简单有效的策略：多个机架分布存储Chunk副本 
    - 可靠性：预防整个机架损坏
    - 带宽利用率：尤其对Chunk读操作，有效利用多个机架的整合带宽(同个机架内机器间会带宽竞争)
3、Chunk的创建，重新复制，重新负载均衡
* 创建：3个位置选择因素，1 平衡硬盘利用率 2 限制每个ChunkServer"近期"创建Chunk个数 3 分布在多机架间
* 重新复制：当Chunk有效副本数小于设置值，Master对Chunk副本重新复制
* 重新负载均衡：Master会周期性对Chunk副本重新负载均衡
4、垃圾回收机制
* 垃圾回收机制：GFS文件删除时并不立即释放物理空间，而是采用惰性策略，在周期性的常规垃圾扫描才回收物理空间。

* 优点：1 系统设计更简单 2 批量执行，节省开销 3 可靠性和容错性（防误删等）

* 缺点：存储的开销，阻碍用户调优存储空间使用

* 实现细节：Client提交文件删除操作，Master将删除操作记录到日志，并将对应文件名改为包含删除时间戳的隐藏文件名（改名字，并没有回收物理空间）。Master周期性对名字空间做常规垃圾扫描，会在名字空间中删除3天前（可设置）的隐藏文件及元数据。ChunkServer在与Master的心跳信息中，得知哪些Chunk的元数据不存在了，便可实际回收其物理空间

5、过期失效的Chunk副本检测

* Chunk副本失效的原因：ChunkServer出错或失效，导致Chunk副本因错失一些修改操作而失效

* 通过版本号标识：只要Master给Chunk签订新租约（修改操作），就会增加Chunk的版本号，如果ChunkServer出错或失效，其上面的Chunk副本的版本号就不会增加，不是最高版本号的Chunk副本就会被认为是失效的

* 在垃圾回收机制中会删除所有过期失效的Chunk副本

五、容错和诊断

* 高可用性的体现，如何处理频繁发生的组件失效

1、高可用性

* 遵循的2个简单策略：1 快速恢复 2 复制

* 快速恢复：Master或ChunkServer关闭（正常/异常），都被设计在数秒内可恢复状态并重启。Client和其他服务器发现请求超时，会重连重启的Server

* Chunk的复制：当ChunkServer关闭或Chksum校验出损坏的Chunk副本，Master都会通过复制已有Chunk副本来保障副本个数

* Master的复制：CheckPoint文件+操作日志完成Master的恢复。此外，GFS还有些“影子”Master，在Master宕机时提供GFS的只读访问

2、数据完整性

* 每个ChunkServer独立维护Checksum来校验自己副本的完整性，每个Chunk块都对应一个32位的Checksum。

* 当Checksum校验到数据损坏，ChunkServer会做2件事：1 返回给Client错误信息，让Client操作其他Chunk副本 2 通知Master，请求Chunk副本复制

* 读操作的Checksum：只取Chunk小部分额外相关数据进行校验，对齐在Chunk块的边界上

* 记录追加操作的Checksum：只增量更新最后一个不完整Chunk块的Checksum

* 写操作的Checksum：先读取和校验被写操作覆盖的第一个和最后一个Chunk块，写操作完成后再重新计算和写入Chunksum

* 当ChunkServer空闲时，其会周期性扫描不活动的Chunk块，检验数据完整性

3、诊断工具

* 详细的、深入细节的诊断日志，记录GFS关键性事件，在问题隔离、调试及性能分析都有巨大的帮助

* RPC日志记录了网络上所有请求和响应的详细记录，方便重现GFS的消息交互来诊断问题

* 日志对系统性能影响很小，因为其写入方式为顺序的、异步的。最近的日志保存在内存中，用于更新系统的在线监控

六、度量

1、小规模基准测试

* 机器部署：1台Master，2台Master复制节点，16台ChunkServer， 16台Client（均为PIII 1.4GHz CPU，2GB内存，2个80G/5400rpm硬盘，100Mbps全双工以太网，GFS集群和Client集群各接入一个交换机，2个交换机用1GMbps线路连接），测试结果如下图所示：

* 读操作： N个Client同时从GFS同步读取数据。

    - 当N=16时，整体读取速度为94MB/s，理论极限为125MB/s（1Gbps线路），为理论极限值的75%。

    - 当N增大时，单Client的读取效率下降（N=5为80%，N=16为75%），原因为Client增多时，同时读单个ChunkServer的几率也增加

* 写操作：N个Client同时向GFS写入数据。

    - 当N=16时，整体写入速度为35MB/s，理论极限为67MB/s（要写入到16个ChunkServer中的3个副本，每个ChunkServer网卡12.5MB/s，故12.5*16/3=67MB/s），约为理论极限的50%

    - 当N增大时，单Client的读取效率基本持平（均约为50%）。在实际应用中，并没有成为主要问题

* 记录追加操作：N个Client同时追加数据到一个文件。

    - 性能受限于保存文件最后一个Chunk块的ChunkServer的带宽，与N大小无关。在实际应用中，ChunkServer的网络拥塞也不是一个严重问题

2、实际应用中的集群

* Google内部使用的2个具有代表性的集群（04年）：

    - 集群A：用于内部开发和研究，典型任务为读取数MB/TB数据，转化或分析后，结果写回集群

    - 集群B：用于处理当前生产数据，很少人工干预，持续生产和处理TB级别的数据集

* 存储相关的集群特性：

    

    - 集群B的“Dead files”比例更高（“Dead files”指物理存储空间还没回收的被删除文件，或者旧版本文件），是因为集群B的文件更大Chunk块数更多造成的

    - ChunkServer总共保存十多GB左右元数据，主要为Chunk块的Checksum，此外还有Chunk块版本号等

    - Master保存几十MB元数据（Master的内存并不会成为系统瓶颈），每个文件约100字节，主要为以前缀压缩存储的文件名，此外还有权限列表，Chunk映射关系等

    - Master和ChunkServer均单机只有约有50~100MB元数据，保证了恢复服务器是非常快速的

* 读写速率相关的集群特征：