GFS系统架构及设计要点.docx

?

?

GFS系统架构及设计要点

?

?

孙伟

摘要：本文主要阐述关于分布式文件系统GFS，它是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。通过详细介绍其一致性模块以及读写流程，针对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-chunkhandle+chunkserverlocation），减少客户端访问的次数，减少master负载。

2.减少元数据量，master可以将元数据放在内存中。

3.客户端取一次元数据就能读到更多数据，減少客户端访问不同chunkserver建立tcp连接的次数，从而减少网络负载。

缺点：

1.对于小文件的场景，容易产生数据碎片。

2