编辑推荐

网易数帆开源API网关与容器云项目，让云原生生产落地“多快好

网易汪源：统一负载与多云环境的“开放姿态”，才是云原生

网易数帆如何用 Kubernetes“原语”搞定云原生中间件

快手打新挤爆券商系统，网易数帆推出券商稳定性保障方案

探索智慧校园新模式，网易有数在教育行业的实践分享

金融行业大数据治理之路——数据模型篇

GFS文件系统剖析（上）-系统架构及设计要点

阿凡达2018-07-04 13:29

在测试NEFS（网易分布式文件系统）的过程中，经常会将之前的设计文档再拿出来反复的看一看，过程中就会不断地去琢磨有些既定的设计，为什么要这么设计，比如block块大小的选定，mds中partitioninfo信息为什么是定期去ps上获取，主从mds为什么要这样设计等等。虽然经常会问开发人员一些设计的思路，但是有些根因我认为还是要通过自己去挖掘才能知道更深层次的原因。从设计角度而言，一般来说都是先会去分析下业界有什么比较成熟的文件系统，并且评估下是否符合当前我们的应用场景，不符合的点如何优化。作为一个完全自研的分布式文件系统而言，业界优秀的分布式文件系统的经验肯定也不可或缺。从这个角度来说，作为一个分布式文件系统的QA，也需要去深入学习一下业界成熟的分布式文件系统的一些架构及设计思路，扩展广度，从而发现我们自身的一些设计出发点，或者一些优化点的起源，从而更加深入的了解我们自研的分布式文件系统设计原理，发掘潜藏的隐患，提出优化点。业界的比较成熟的分布式文件系统有很多，经过筛选以及开发同学的建议，选取了GFS（谷歌分布式文件系统），HDFS（Hadoop分布式文件系统），ceph（开源分布式文件系统）三个作为今年的研究点去学习。每一个分布式文件系统不管从架构、设计思路、实现细节各方面来说水都很深，因此也需要花费很多业余的精力去学习和不断地提出疑问。好在这几个前人的经验也相对比较丰富，踩在巨人的肩膀上就没那么难了。本篇首先对GFS（谷歌分布式文件系统）做一个初步的简析，初步分为上，中，下三篇，本篇内容重点介绍GFS系统架构以及设计要点，让读者有一个初步认识，在中下篇中继续对GFS的一些原理及流程进行深入分析，对高可用、数据完整性、可靠性等设计点进行阐述。

一、GFS简介

GFS（谷歌分布式文件系统）为google提供基础的海量数据存储服务。它是一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。GFS虽然运行在廉价的普遍硬件设备上，但是它依然了提供灾难冗余的能力，为大量客户机提供了高性能的服务。

二、GFS设计思路

GFS是针对谷歌应用的特点按照以下思路去设计：

1. 组件/机器失效是常态，而不是意外（容错性） ： GFS包括几百甚至几千台普通的廉价设备组装的存储机器，同时被相当数量的客户机访问。GFS组件的数量和质量导致在事实上，任何给定时间内都有可能发生某些组件无法工作，某些组件无法从它们目前的失效状态中恢复。例如谷歌遇到过各种各样的问题，比如应用程序bug、操作系统的bug、人为失误，甚至还有硬盘、内存、连接器、网络以及电源失效等造成的问题。所以，持续的监控、错误侦测、灾难冗余以及自动恢复的机制必须集成在GFS中。
2. 谷歌处理的文件都非常巨大。（大数据）：
这点跟NEFS的场景既有相似性又不完全一致，NEFS上层对接的是NOS对象存储，基本都是大量的小文件（100MB以下），总体量比较大，对象个数比较多，因此也需要考虑元数据管理的成本，因此NEFS采用了小文件合并的设计思路（不详细展开）。
谷歌系统中数GB的文件非常普遍。每个文件通常都包含许多应用程序对象，比如web文档。当我们经常需要处理快速增长的、并且由数亿个对象构成的、数以TB的数据集时，采用管理数亿个KB大小的小文件的方式是非常不明智的，尽管有些文件系统支持这样的管理方式。因此，设计的假设条件和参数，比如I/O操作和Block的尺寸都需要重新考虑。
3. 绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。（读写模型：顺序写，大部分顺序读，小部分随机读）：
对文件的随机写入操作在实际中几乎不存在。一旦写完之后，对文件的操作就只有读，而且通常是按顺序读。大量的数据符合这些特性，比如：数据分析程序扫描的超大的数据集；正在运行的应用程序生成的连续的数据流；存档的数据；由一台机器生成、另外一台机器处理的中间数据，这些中间数据的处理可能是同时进行的、也可能是后续才处理的。对于这种针对海量文件的访问模式，客户端对数据块缓存是没有意义的，数据的追加操作是性能优化和原子性保证的主要考量因素。
4. 应用程序和文件系统API协同设计，简化对GFS的要求（灵活性）：
例如一致性模型要求放松了，这样就减轻了文件系统对应用程序的苛刻要求，大大简化了GFS的设计。并且引入了原子性的记录追加操作，从而保证多个客户端能够同时进行追加操作，不需要额外的同步操作来保证数据的一致性。

三、GFS接口：

GFS提供了一套类似传统文件系统的API接口函数，文件以分层目录的形式组织，用路径名来标识。GFS支持常用的操作，如创建新文件、删除文件、打开文件、关闭文件、读和写文件。但是要理解一点：文件块被存储在linux硬盘上，GFS只是一个管理器而已，这些文件操作API也只是个对这些抽象文件的管理而已。也就是说GFS层级比底层文件系统以及虚拟文件系统层次要高。注：这点跟NEFS也比较像，NEFS也是对文件粒度进行管理的，而不是针对块设备，因此也是在底层文件系统及虚拟文件系统之上。

四、GFS设计架构：

使用论文中的原图如下：如图所示，GFS主要由以下三个系统模块组成： • Master：管理元数据、整体协调系统活动。 • ChunkServer：存储维护数据块（Chunk），读写文件数据。 • Client：向Master请求元数据，并根据元数据访问对应ChunkServer的Chunk。

五、GFS设计要点：

1.chunk机制 chunk是GFS中管理数据的最小单元（数据块），每一个chunk被一个64位的handle唯一标识，chunk被当做普通的文件存储在linux系统中。每个chunk至少会在另一个chunkserver上有备份，而默认会为每个chunk做三个备份。chunk大小默认为64MB，比一般的文件系统的4kb的块要大的多得多。 Chunkserver一般不会缓存数据，因为chunk都是存储在本地，故而linux已经将经常被访问的数据缓存在内存中了。
chunk块设置比较大（一般文件系统的块为4kb）的优缺点如下：
优点： 1.减少元数据量，方便客户端预读缓存（filename+chunkindex->chunk handle+ chunkserver location）,减少客户端访问的次数，减少master负载。 2.减少元数据量，master可以将元数据放在内存中。 3.客户端取一次元数据就能读到更多数据，减少客户端访问不同chunkserver建立tcp连接的次数，从而减少网络负载。
缺点： 1.对于小文件的场景，容易产生数据碎片。 2.小文件占用chunk少，对小文件频繁访问会集中在少数chunkserver上，从而产生小文件访问热点（这个问题在后续的可靠性篇章中有相关的解决方案）。
2.元数据管理
系统中三种元数据类型： • 文件和chunk的名称（命名空间）。 • 文件和chunk之间的映射关系，比如说每个文件是由哪些chunk共同组成。 • 每个chunk备份的位置。命名空间、文件和Chunk的对应关系的存储方式： • 内存：真实数据； • 磁盘：定期Checkpoint（压缩B树）和上次CheckPoint后的操作日志； • 多机备份：Checkpoint文件和操作日志。 Chunk位置信息的存储方式： • 内存：真实数据 • 磁盘：不持久存储系统启动和新Chunk服务器加入时从Chunk服务器获取。避免了Master与ChunkServer之间的数据同步，只有Chunk服务器才能最终确定Chunk是否在它的硬盘上。
3.Master单一性 单一的Master节点的策略大大简化了FGS的设计。单一的Master节点可以通过全局的信息精确定位Chunk的位置以及进行复制决策。针对master宕机的处理和恢复在后续的高可用篇中详细介绍。
4.操作日志 操作日志包含了关键的元数据变更历史记录。这对GFS非常重要。这不仅仅是因为操作日志是元数据唯一的持久化存储记录，它也作为判断同步操作顺序的逻辑时间基线。文件和Chunk，连同它们的版本(可以看做是更新次数，以判断chunk是否过期，低版本的认为过期)，都由它们创建的逻辑时间唯一的、永久的标识。操作日志和chunk数据一样，都需要复制到多台机器，使用多副本保存。关于使用日志来进行数据恢复（例如某个副本宕机，master服务器宕机的场景）也在后续的高可用篇中详细介绍。

小结

GFS的设计思路决定了它的主体框架及设计要点，例如文件非常大并且大部分是顺序写和读取，这样就可以设置chunk大小为一个比较大的值，因为小文件的场景本身就偏少，因此chunk中的由于小文件带来的数据碎片就可以相对忽略不计。另外chunkserver是不缓存chunk数据的，因为linux系统级缓存对于顺序读取来说效果已经很好了。针对于GFS大部分都是顺序读取的场景来说，不需要做进一步的优化。针对数据追加的优化才是针对顺序写的目标场景进行的好的优化设计点。 NEFS的目标场景跟GFS有一定的差别，NEFS上层对接的是NOS对象存储，基本都是大量的小文件（100MB以下），总体量比较大，对象个数比较多。而且大部分是顺序写，随机读场景，因此目标场景不一致导致结构和设计会有一定的差异。