The Google File System 论文解读

1. 前言

Google File System (GFS) 是由 Google 设计并实现的、一个面向大规模数据密集型应用的分布式文件系统，它满足所有分布式文件系统共有的 高性能 、伸缩性 、可靠性 、可用性 ，还以 Google 自身 应用程序 和 技术环境 为基础进行了特有的设计 ，主要包括：

• 因为 GFS 使用设备数多，将组件失效视为常态事件 。因此 持续监控 、错误检测 、灾难冗余 和 自动恢复 的机制必须包括在 GFS 中 。
• 数据增长，既要保证对小文件的管理，又要很好的对大文件进行管理，主要对大文件的管理进行了优化 。
• 主要应用于 对文件尾部追加数据的修改，而非覆盖原有数据的方式，如 “生产者-消费者” 队列，或者其他多路文件合并操作 。一旦写完后，对文件的操作通常是顺序读 。
• 采用了较弱的 一致性 要求，引用原子性的记录追加操作，保证多个客户端能够同时进行追加操作，不需要额外的同步操作来保证数据的一致性 。
• 目标程序绝大多数要求高速率、大批量地处理数据，极少要求对单一读写操作有严格的响应时间要求 。即高性能的稳定网络带宽 比 低延迟 更重要 。
• 两种比较常见的读取方式：大规模的数据流读取 和 小规模的随机读取
  • 大规模流失读取 通常读取1MB以上数据 ，应用程序通常通过文件中的连续区域读取，大多连续附加数据到尾部
  • 小随机读取通常只有几个 Kbs 在某些任意偏移，不必很高效
  • 一旦写入，很少修改

2. 架构

GFS 提供了一套类似传统文件系统的 API接口函数 ，不符合POSIX，文件以 分层目录的形式组织，用 路径名 来标识 。支持：创建新文件、删除文件、打开文件、关闭文件、读和写文件，以及**快照（以低成本创建文件或目录树的副本）和记录追加（允许多个客户端同时将数据附加到同一文件中，至少保证有一次有效的追加）**操作 。

2.1 架构设计

• 一个 GFS 集群包含：一个 master 、多台 chunkserver 、同时被多个 client 访问

• 每个文件被分为多个 chunk ，每个 chunk 大小为 64MB 。保证可靠性，每个 chunk 含有 3 个 副本，分别存于 3 个不同机架上的不同 chunkserver

• master上存储元信息：命名空间、访问控制信息、文件和chunks的映射、chunks的位置，master会让chunk server通过HeartBeat交换信息

• client和chunkserver都不缓存文件数据，易造成缓存一致性问题

• 控制和数据信息分离

  • Clients interact with the master for metadata operations
  • Clients interact directly with chunkservers for all files operations
  • This means performance can be improved by scheduling expensive data flow based on the network topology

3. Chunk

3.1 chunk 大小与数量

• chunk 大小为 64MB ，并被赋予一个独一无二的不可改变的chunk handle。之后会根据 chunk handle 和字节范围range来读写 chunk 。
• 每个 chunk 副本都以普通 Linux 文件的形式保存在 chunkserver ，使用 惰性分配 策略避免了因内部碎片造成的空间浪费，(惰性分配：指直到使用一个资源的时候再去给它分配空间 )
• 在master中用小于64bytes的元数据保存这块chunk，包括：
  • 当前chunk复制版本的位置
  • 引用计数，用于写时复制
  • 版本编号，用于检测陈旧的副本
• 出于可靠性的考虑，每个 chunk 都会复制到多个 chunksever 上(多个机架)，默认副本数为 3 。
• 选择较大 chunk 尺寸的优点：
  • 减少了客户端和 master 节点通信的需求
  • 用较大的 chunk 尺寸，客户端能够对一个块进行多次操作，这样就可以与 chunkserver 保持较长时间的 TCP 连接而减少网络负载
  • 减少了 master 节点需要的元数据的数量
• 缺点：
  • 由于内部碎片而浪费空间
  • 小型文件由几个块组成，然后从并发客户端获得大量流量可能导致失控，可以通过增加复制系数来缓解这种情况

3.2 副本的位置 与 放置

• GFS 集群是高度分布的 多层布局结构 。存储在多个 机架 上，可以：
  • 最大化数据可靠性和可用性：不仅可以预防硬盘损坏、服务器宕机引发的问题，还可以预防网络、电源故障失效，比仅部署在不同服务器上拥有更高的可靠性
  • 最大化网络带宽利用率：针对 chunk 的读操作，能够利用多个机架的整合带宽
• master 创建一个 chunk 时，会选择在哪里放置初始的空的副本，主要考虑几个因素：
  • 希望在低于平均硬盘使用率的 chunkserver 上存储新的副本
  • 希望限制在每个 chunkserver 上 最近 chunk 创建操作的次数
  • 希望把 chunk 分布在多个机架上
• 让master掌握块位置并评估整个系统的状态
• 重要： chunk servers对它自己的磁盘上哪些块或没有块有最终决定权 ，不是master

3.3 chunk 容错复制 和 负载均衡

• 当 chunk 的有效副本数量少于用户指定的复制因素的时候 或者 副本损坏 或者chunkserver不可用时，master 会重新复制它，master 选择优先级最高的 chunk ，然后命令 chunkserver 直接从可用的副本克隆一个副本出来，选择新副本位置的策略和创建时的策略相同 。

• 优先级因素：

  • 优先复制副本数量和复制因素相差多的
  • 优先复制活跃的文件而非刚被删除的文件
  • 优先复制会阻塞 client 程序的chunk