Google文件系统GFS
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
G o o g l e文件系统G F S
当前主流分布式文件系统有R e d H a t的G F S[[33]](G l o b a l F i l e S y s t e m)、I B M的G P F S[[44]]、S u n的L u s t r e[[55]]等。
这些系统通常用于高性能计算或大型数据中心,对硬件设施条件要求较高。
以L u s t r e文件系统为例,它只对元数据管理器M D S提供容错解决方案,而对于具体的数据存储节点O S T来说,则依赖其自身来解决容错的问题。
例如,L u s t r e推荐O S T节点采用
R A I D技术或S A N存储区域网来容错,但由于L u s t r e自身不能提供数据存储的容错,一旦O S T发生故障就无法恢复,因此对O S T的稳定性就提出了相当高的要求,从而大大增加了存储的成本,而且成本会随着规模的扩大线性增长。
正如李开复所说的那样,创新固然重要,但有用的创新更重要。
创新的价值,取决于一项创新在新颖、有用和可行性这三个方面的综合表现。
G o o g l e G F S的新颖之处并不在于它采用了多么令人惊讶的技术,而在于它采用廉价的商用机器构建分布式文件系统,同时将G F S的设计与G o o g l e应用的特点紧密结合,并简化其实现,使之可行,最终达到创意新颖、有用、可行的完美组合。
G F S使用廉价的商用机器构建分布式文件系统,将容错的任务交由文件系统来完成,利用软件的方法解决系统可靠性问题,这样可以使得存储的成本成倍下降。
由于G F S中服务器数目众多,在G F S中服务器死机是经常发生的事情,甚至都不应当将其视为异常现象,那么如何在频繁的故障中确保数据存储的安全、保证提供不间断的数据存储服务是G F S最核心的问题。
G F S的精彩在于它采用了多种方法,从多个角度,使用不同的容错措施来确保整个系统的可靠性。
2.1.1系统架构
G F S的系统架构如图2-1[[11]]所示。
G F S将整个系统的节点分为三类角色:C l i e n t(客户端)、M a s t e r(主服务器)和C h u n k S e r v e r (数据块服务器)。
C l i e n t是G F S提供给应用程序的访问接口,它是一组专用接口,不遵守P O S I X规范,以库文件的形式提供。
应用程序直接调用这些库函数,并与该库链接在一起。
M a s t e r是G F S的管理节点,在逻辑上只有一个,它保存系统的元数据,负责整个文件系统的管理,是G F S文件系统中的“大脑”。
C h u n k S e r v e r负责具体的存储工作。
数据以文件的
形式存储在C h u n k S e r v e r上,C h u n k S e r v e r的个数可以有多个,它的数目直接决定了G F S的规模。
G F S将文件按照固定大小进行分块,默认是64M B,每一块称为一个C h u n k(数据块),每个C h u n k都有一个对应的索引号
(I n d e x)。
图2-1G F S体系结构
客户端在访问G F S时,首先访问M a s t e r节点,获取将
要与之进行交互的C h u n k S e r v e r信息,然后直接访问这些C h u n k S e r v e r
完成数据存取。
G F S的这种设计方法实现了控制流和数据流的分离。
C l i e n t 与M a s t e r之间只有控制流,而无数据流,这样就极大地降低了M a s t e r的负载,使之不成为系统性能的一个瓶颈。
C l i e n t与C h u n k S e r v e r之间直
接传输数据流,同时由于文件被分成多个C h u n k进行分布式存储,C l i e n t 可以同时访问多个C h u n k S e r v e r,从而使得整个系统的I/O高度并行,系统整体性能得到提升。
相对于传统的分布式文件系统,G F S针对G o o g l e应用的特点从多个方面进行了简化,从而在一定规模下达到成本、可靠性和性能的最佳平衡。
具体来说,它具有以下几个特点。
1.采用中心服务器模式
G F S采用中心服务器模式来管理整个文件系统,可以大大简化设计,从而降低实现难度。
M a s t e r管理了分布式文件系统中的所有元数据。
文件划分为C h u n k进行存储,对于M a s t e r来说,每个C h u n k S e r v e r 只是一个存储空间。
C l i e n t发起的所有操作都需要先通过M a s t e r才能执行。
这样做有许多好处,增加新的C h u n k S e r v e r是一件十分容易的事情,C h u n k S e r v e r只需要注册到M a s t e r上即可,C h u n k S e r v e r之间无任何关系。
如果采用完全对等的、无中心的模式,那么如何将C h u n k S e r v e r的更新信息通知到每一个C h u n k S e r v e r,会是设计的一个难点,而这也将在一定程度上影响系统的扩展性。
M a s t e r维护了一个统一的命名空间,同时掌握整个系统内C h u n k S e r v e r的情况,据此可以实现整个系统范围内数据存储的负载均衡。
由于只有一个中心服务器,元数据的一致性问题自然解决。
当然,中心服务器模式也带来一些固有的缺点,比如极易成为整个系统的瓶颈等。
G F S采用多种机制来避免M a s t e r成为系统性能和可靠性上的瓶颈,如尽量控制元数据的规模、对M a s t e r进行远程备份、控制信息和数据分流等。
2.不缓存数据
缓存(C a c h e)机制是提升文件系统性能的一个重要手段,通用文件系统为了提升性能,一般需要实现复杂的缓存机制。
G F S文
件系统根据应用的特点,没有实现缓存,这是从必要性和可行性两方面考虑的。
从必要性上讲,客户端大部分是流式顺序读写,并不存在大量的重复读写,缓存这部分数据对系统整体性能的提升作用不大;而对于C h u n k S e r v e r,由于G F S的数据在C h u n k S e r v e r上以文件的形式存储,如果对某块数据读取频繁,本地的文件系统自然会将其缓存。
从可行性上讲,如何维护缓存与实际数据之间的一致性是一个极其复杂的问题,在G F S中各个C h u n k S e r v e r的稳定性都无法确保,加之网络等多种不确定因素,一致性问题尤为复杂。
此外由于读取的数据量巨大,以当前的内存容量无法完全缓存。
对于存储在M a s t e r中的元数据,G F S采取了缓存策略,G F S中C l i e n t发起的所有操作都需要先经过M a s t e r。
M a s t e r需要对其元数据进行频繁操作,为了提升操作的效率,M a s t e r的元数据都是直接保存在内存中进行操作。
同时采用相应的压缩机制降低元数据占用空间的大小,提升内存的利用率。
3.在用户态下实现
文件系统作为操作系统的重要组成部分,其实现通常位于操作系统底层。
以L i n u x为例,无论是本地文件系统如E x t3文件系统,还是分布式文件系统如L u s t r e等,都是在内核态实现的。
在内核态实现文件系统,可以更好地和操作系统本身结合,向上提供兼容的P O S I X接口。
然而,G F S却选择在用户态下实现,主要基于以下考虑。
1)在用户态下实现,直接利用操作系统提供的P O S I X 编程接口就可以存取数据,无需了解操作系统的内部实现机制和接口,从而降低了实现的难度,并提升了通用性。
2)P O S I X接口提供的功能更为丰富,在实现过程中可以利用更多的特性,而不像内核编程那样受限。
3)用户态下有多种调试工具,而在内核态中调试相对比较困难。
4)用户态下,M a s t e r和C h u n k S e r v e r都以进程的方式运行,单个进程不会影响到整个操作系统,从而可以对其进行充分优化。
在内核态下,如果不能很好地掌握其特性,效率不但不会高,甚至还会影响到整个系统运行的稳定性。
5)用户态下,G F S和操作系统运行在不同的空间,两者耦合性降低,从而方便G F S自身和内核的单独升级。
4.只提供专用接口
通常的分布式文件系统一般都会提供一组与P O S I X规范兼容的接口。
其优点是应用程序可以通过操作系统的统一接口来透明地访问文件系统,而不需要重新编译程序。
G F S在设计之初,是完全面向G o o g l e 的应用的,采用了专用的文件系统访问接口。
接口以库文件的形式提供,应用程序与库文件一起编译,G o o g l e应用程序在代码中通过调用这些库文件的A P I,完成对G F S文件系统的访问。
采用专用接口有以下好处。
1)降低了实现的难度。
通常与P O S I X兼容的接口需要在操作系统内核一级实现,而G F S是在应用层实现的。
2)采用专用接口可以根据应用的特点对应用提供一些特殊支持,如支持多个文件并发追加的接口等。
3)专用接口直接和C l i e n t、M a s t e r、C h u n k S e r v e r交互,减少了操作系统之间上下文的切换,降低了复杂度,提升了效率。
2.1.2容错机制
1.M a s t e r容错
具体来说,M a s t e r上保存了G F S文件系统的三种元数据。
1)命名空间(N a m e S p a c e),也就是整个文件系统的目录结构。
2)C h u n k与文件名的映射表。
3)C h u n k副本的位置信息,每一个C h u n k默认有三个副本。
首先就单个M a s t e r来说,对于前两种元数据,G F S通过操作日志来提供容错功能。
第三种元数据信息则直接保存在各个C h u n k
S e r v e r上,当M a s t e r启动或C h u n k S e r v e r向M a s t e r注册时自动生成。
因此当M a s t e r发生故障时,在磁盘数据保存完好的情况下,可以迅速恢复以上元数据。
为了防止M a s t e r彻底死机的情况,G F S还提供了M a s t e r 远程的实时备份,这样在当前的G F S M a s t e r出现故障无法工作的时候,另外一台G F S M a s t e r可以迅速接替其工作。
2.C h u n k S e r v e r容错
G F S采用副本的方式实现C h u n k S e r v e r的容错。
每一个C h u n k有多个存储副本(默认为三个),分布存储在不同的C h u n k S e r v e r 上。
副本的分布策略需要考虑多种因素,如网络的拓扑、机架的分布、磁
盘的利用率等。
对于每一个C h u n k,必须将所有的副本全部写入成功,才视为成功写入。
在其后的过程中,如果相关的副本出现丢失或不可恢复等状况,M a s t e r会自动将该副本复制到其他C h u n k S e r v e r,从而确保副本保持一定的个数。
尽管一份数据需要存储三份,好像磁盘空间的利用率不高,但综合比较多种因素,加之磁盘的成本不断下降,采用副本无疑是最简单、最可靠、最有效,而且实现的难度也最小的一种方法。
G F S中的每一个文件被划分成多个C h u n k,C h u n k的默认大小是64M B,这是因为G o o g l e应用中处理的文件都比较大,以64M B为单位进行划分,是一个较为合理的选择。
C h u n k S e r v e r存储的是C h u n k的副本,副本以文件的形式进行存储。
每一个C h u n k以B l o c k为单位进行划分,大小为64K B,每一个B l o c k对应一个32b i t的校验和。
当读取一个C h u n k 副本时,C h u n k S e r v e r会将读取的数据和校验和进行比较,如果不匹配,就会返回错误,从而使C l i e n t选择其他C h u n k S e r v e r上的副本。
2.1.3系统管理技术
严格意义上来说,G F S是一个分布式文件系统,包含从硬件到软件的整套解决方案。
除了上面提到的G F S的一些关键技术外,还有相应的系统管理技术来支持整个G F S的应用,这些技术可能并不一定为G F S所独有。
1.大规模集群安装技术
安装G F S的集群中通常有非常多的节点,文献[1]中最大的集群超过1000个节点,而现在的G o o g l e数据中心动辄有万台以上的机器在运行。
因此
迅速地安装、部署一个G F S的系统,以及迅速地进行节点的系统升级等,都需要相应的技术支撑。
2.故障检测技术
G F S是构建在不可靠的廉价计算机之上的文件系统,由于节点数目众多,故障发生十分频繁,如何在最短的时间内发现并确定发生故障的C h u n k
S e r v e r,需要相关的集群监控技术。
3.节点动态加入技术
当有新的C h u n k S e r v e r加入时,如果需要事先安装好系统,那么系统扩展将是一件十分烦琐的事情。
如果能够做到只需将裸机加入,就会自动获取系统并安装运行,那么将会大大减少G F S维护的工作量。
4.节能技术
有关数据表明,服务器的耗电成本大于当初的购买成本,因此G o o g l e采用了多种机制来降低服务器的能耗,例如对服务器主板进行修改,采用蓄电池代替昂贵的U P S(不间断电源系统),提升能量的利用率。
R i c h M i l l e r 在一篇关于数据中心的博客文章中表示,这个设计让G o o g l e的U P S利用率达到99.9%,而一般数据中心只能达到92%~95%。