题记:初学分布式文件系统,写篇博客加深点印象。GFS的特点是使用一堆廉价的商用计算机支撑大规模数据处理。
虽然"The Google File System " 是03年发表的老文章了,但现在仍被广泛讨论,其对后来的分布式文件系统设计具有指导意义。然而,作者在设计GFS时,是基于过去很多实验观察的,并提出了很多假设作为前提,这等于给出了一个GFS的应用场景。所以我们自己在设计分布式系统时,一定要注意自己的应用场景是否和GFS相似,不能盲从GFS。
GFS的主要假设如下:
- GFS的服务器都是普通的商用计算机,并不那么可靠,集群出现结点故障是常态。因此必须时刻监控系统的结点状态,当结点失效时,必须能检测到,并恢复之。
- 系统存储适当数量的大文件。理想的负载是几百万个文件,文件一般都超过100MB,GB级别以上的文件是很常见的,必须进行有效管理。支持小文件,但不对其进行优化。
- 负载通常包含两种读:大型的流式读(顺序读),和小型的随机读。前者通常一次读数百KB以上,后者通常在随机位置读几个KB。
- 负载还包括很多连续的写操作,往文件追加数据(append)。文件很少会被修改,支持随机写操作,但不必进行优化。
- 系统必须实现良好定义的语义,用于多客户端并发写同一个文件。同步的开销必须保证最小。
- 高带宽比低延迟更重要,GFS的应用大多需要快速处理大量的数据,很少会严格要求单一操作的响应时间。
1 体系结构
GFS包括一个master结点(元数据服务器),多个chunkserver(数据服务器)和多个client(运行各种应用的客户端)。在可靠性要求不高的场景,client和chunkserver可以位于一个结点。图1是GFS的体系结构示意图,每一结点都是普通的Linux服务器,GFS的工作就是协调成百上千的服务器为各种应用提供服务。
- chunkserver提供存储。GFS会将文件划分为定长数据块,每个数据块都有一个全局唯一不可变的id(chunk_handle),数据块以普通Linux文件的形式存储在chunkserver上,出于可靠性考虑,每个数据块会存储多个副本,分布在不同chunkserver。
- GFS master就是GFS的元数据服务器,负责维护文件系统的元数据,包括命名空间、访问控制、文件-块映射、块地址等,以及控制系统级活动,如垃圾回收、负载均衡等。
- 应用需要链接client的代码,然后client作为代理与master和chunkserver交互。master会定期与chunkserver交流(心跳),以获取chunkserver的状态并发送指令。
2 数据的布局
GFS将文件条带化,按照类似RAID0的形式进行存储,可以提高聚合带宽。事实上,大多数分布式存储系统都会采取这种策略。GFS将文件按固定长度切分为数据块,master在创建一个新数据块时,会给每个数据块分配一个全局唯一且不可变的64位id。每个数据块以Linux文件的形式存储在chunkserver的本地文件系统里。