Google三大论文(二)GFS:大规模分布式文件系统

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/weixin_40535323/article/details/81738620

一.什么是GFS

GFS(Google File System )是一个大规模分布式文件系统。GFS与传统的分布式文件系统有着很多相同的设计目标,比如,性能、可伸缩性、可靠性以及可用性。而不同之处主要在于一下几点:

  • 因组件数目庞大,用户访问量大,组件失效被认为是常态事件。所以,持续的监控、错误侦测、灾难冗余以及自动恢复的机制必须集成在GFS中。
  • 以通常的标准衡量,我们的文件非常巨大。数GB的文件非常普遍。每个文件通常都包含许多应用程 序对象,比如web文档。当我们经常需要处理快速增长的、并且由数亿个对象构成的、数以TB的数据集 时,采用管理数亿个KB大小的小文件的方式是非常不明智的,尽管有些文件系统支持这样的管理方式。因 此,设计的假设条件和参数,比如I/O操作和Block的尺寸都需要重新考虑。
  • 绝大部分文件的修改是采用在文件尾部追加数据,而不是覆盖原有数据的方式。对文件的随机写入 操作在实际中几乎不存在。一旦写完之后,对文件的操作就只有读,而且通常是按顺序读。对于这种针对海量文件的访问模式,客户端对数据块缓存是没有意义的,数据的追加 操作是性能优化和原子性保证的主要考量因素。
     
  • 应用程序和文件系统API的协同设计提高了整个系统的灵活性

二.GFS的预期设计

  • 系统由许多廉价的普通组件组成,组件失效是一种常态。系统必须持续监控自身的状态,它必须将组 件失效作为一种常态,能够迅速地侦测、冗余并恢复失效的组件。
  • 系统存储一定数量的大文件。我们预期会有几百万文件,文件的大小通常在100MB或者以上。数个 GB大小的文件也是普遍存在,并且要能够被有效的管理。系统也必须支持小文件,但是不需要针对 小文件做专门的优化。
  • 系统的工作负载主要由两种读操作组成:大规模的流式读取和小规模的随机读取。大规模的流式读取 通常一次读取数百KB的数据,更常见的是一次读取1MB甚至更多的数据。来自同一个客户机的连续 操作通常是读取同一个文件中连续的一个区域。小规模的随机读取通常是在文件某个随机的位置读取 几个KB数据。如果应用程序对性能非常关注,通常的做法是把小规模的随机读取操作合并并排序, 之后按顺序批量读取,这样就避免了在文件中前后来回的移动读取位置。
  • 系统的工作负载还包括许多大规模的、顺序的、数据追加方式的写操作。一般情况下,每次写入的数 据的大小和大规模读类似。数据一旦被写入后,文件就很少会被修改了。系统支持小规模的随机位置 写入操作,但是可能效率不彰。
  • 系统必须高效的、行为定义明确的实现多客户端并行追加数据到同一个文件里的语意。我们的文件通常被用于”生产者-消费者“队列,或者其它多路文件合并操作。通常会有 数百个生产者,每个生产者进程运行在一台机器上,同时对一个文件进行追加操作。使用最小的同步 开销来实现的原子的多路追加数据操作是必不可少的。文件可以在稍后读取,或者是消费者在追加的 操作的同时读取文件。
  • 高性能的稳定网络带宽远比低延迟重要。我们的目标程序绝大部分要求能够高速率的、大批量的处理 数据,极少有程序对单一的读写操作有严格的响应时间要求。 

 三.GFS架构

一个GFS集群包含三个角色:一个单独的GFS Master总控制服务器,多台GFS Chunkserver(数据块服务器,简称CS)和多个GFS Client客户端.GFS存储的文件都被分割成固定大小的Chunk。 Chunk服务器把Chunk以linux文件的形式保存在本地硬盘上,并且根据指定的Chunk标识和字节范围来读写块数据。为了保证可靠性,Chunk在不同的机器中复制多份,缺省情况下,使用3个存储复制节点,不过用户可以为不同的文件命名空间设定不同的复制级别。

Master中维护了系统的元数据(SQL中的说法是:数据的数据),这些元数据包括Chunk名字空间、访问控制信息、文件和Chunk的映射信息、以及当前Chunk的位置信息.。Master还管理着系统范围内的活动,比如, Chunk租用管理无用Chunk的回收、以及Chunk在Chunk服务器之间的迁移。 Master节点使用心跳信息周期地和每个Chunk服务器通讯,发送指令到各个Chunk服务器并接收Chunk服务器的状态信息。

Client代码实现了GFS文件系统的API接口函数以及应用程序的访问接口。应用程序从Master获取元数据,根据元数据提供的信息与Chunk服务器直接进行交互。从架构图可以看出,Client和Master之间的交互只有控制流(指令信息),没有数据流,因此降低了Master的负载 (因为控制流只需传送指令和状态,数据量小)。

四.一致性模型

1.什么是一致性

理解起来很好理解,在分布式系统中,数据会往往会复制成多个副本,当对其中一个副本的数据进行修改时,其他多个副本也应进行相应的改动以保证分布式系统中数据的一致。

2.影响一致性的操作:

  • 修改元数据
  • 写数据:向一个文件块中写数据,客户端指定要写的数据和要写的数据在一个文件中的偏移量。
  • 追加数据:客户端指定要将哪些数据追加到哪个文件后,系统返回追加成功的数据的起始位置。

3.GFS中的一致性

元数据的一致性

元数据只有一份(不考虑hidden master和日志),不存在副本一致性问题,只考虑传统数据库中的内部一致性问题,即符合数据库的内部约束,GFS对元数据的修改都要加锁,隔离各个操作。

修改元数据+无并发

操作只有成功和不成功两情况,元数据永远是一致的。

修改元数据+并发

GFS存在锁机制,会将各个操作依次执行,与无并发一样。只不过并发的修改后值是多少不确定(是我不确定,不是GFS不确定,也许有一定的机制来对操作排序,也许是自由竞争)。元数据还是一致的。

可以看到,如果数据只有一份,总是一致的。只有并发会产生语义的问题,需要根据应用逻辑进行并发处理。

一个文件块(chunk)的一致性

这里只讨论 一个chunk ,也就是 一个文件块 的写操作,不涉及整个文件的写流程中数据和元数据的流程,原论文里好像也没介绍文件的写流程。

每个chunk默认有3个副本,不同副本会存在不同节点上,master会设置1个主副本(primary),2个二级(secondary)副本。

当写操作和追加操作失败,数据会出现部分被修改的情况,于是肯定会出现副本不一致的情况,这时就依赖master的重备份来将好的副本备份成N份。以下只考虑操作成功的情况。

写一个chunk+无并发

写一个chunk时,客户端向primary发送写请求(一个chunk对应几个写请求不确定,这里不影响理解,当做一个看就可以了)。primary确定写操作的顺序,由于没有并发,只有一个写请求,直接执行这个写请求,然后再命令secondary副本执行这个写请求。其他secondary都按照这个顺序执行写操作,保证了全局有序,并且只有当所有副本都写成功,才返回成功,用系统延迟保证了数据强一致,即 consistent(所有副本的值都一样) 。

这个强一致指每个写成功后,所有客户端都能看到这个修改。即论文中说的 defined 。defined 的意思是知道这个文件是谁写的(那么谁知道呢?肯定是自己知道,其他客户端看不到文件的创建者)。也就是当前客户端在写完之后,再读数据,肯定能读到刚才自己写的。

写一个chunk+并发

这时primary可能同时接受到多个客户端对自己的写操作。举个例子,两个客户端同时写一个chunk。w1或w2代表(写操作+数据)。下边表示client1想将这个chunk写成w1,client2想将这个chunk写成w2。

  • client1:w1

  • client2:w2

于是primary要将这些写操作按某个机制排个顺序:

  • primary:w2,w1

然后在primary本地执行,于是这个chunk首先被写成w2,之后被覆盖成w1。

之后所有secondary副本都会按照这个顺序来执行操作,于是所有副本都是w1,这时数据是 consistent 的,也就是副本一致的。因为所有操作都正确执行了,所以两个client都收到写成功了。但是谁也不能保证数据一定是自己刚才写的,也就是 undefined 。这与最终一致性有点像(系统保证所有副本最终都一样,但是不保证是什么值)。

追加数据+无并发

追加数据时,会追加到最后一个chunk,其实和写一个chunk+无并发基本一样。 
但由于追加操作和写文件不一样,追加操作不是幂等的,当一次追加操作没有成功,客户端重试时,不同副本可能被追加了不同次数。

假设追加了一个数据a

  • client:追加a。

第一次追加请求执行了一半失败了,这个chunk的所有副本现在是这样:

  • primary:原始数据,offset1:a
  • second1:原始数据,offset1:a
  • second2:原始数据

于是客户端重新发送追加请求,因为primary会先执行操作再将请求发给secondary,所以primary当前文件是最长的(先不考虑primary改变的情况)。primary继续往offset2(当前文件末尾)追加,并通知所有secondary往offset2追加,但是secondary2的offset2不是末尾,所以会先补空。如果这次追加操作成功,数据最终会是这样:

  • primary:原始数据,offset1:a,offset2:a
  • second1:原始数据,offset1:a,offset2:a
  • second2:原始数据,offset1:*,offset2:a

并且给客户端返回 offset2 。

于是数据中间一部分是 inconsistent。但是对于追加的数据是 defined 。客户端再读offset2,可以确定读到a。 
这就是追加操作的defined interspersed with inconsistent。

追加数据+并发

两个客户端分别向同一个文件追加数据a和b

  • client1:追加a
  • client2:追加b

最后一个文件块的primary接收到追加操作后进行序列化

  • primary:b,a

然后执行,b失败了一次,于是client2再发送一次追b。primary再追加一次。

  • primary:原始数据,off1:b,off2:a,off3:b
  • second1:原始数据,off1:b,off2:a,off3:b
  • second2:原始数据,off1: ,off2:a,off3:b

client1收到GFS返回的off2(表示a追加到了文件的off2位置),client2收到off3

也满足off2和off3是 defined ,off1是 inconsistent ,所以总体来说是 defined interspersed with inconsistent

可以看到,不管有没有并发,追加数据都不能保证数据全部 defined,只能保证有 defined ,但是可能会与 inconsistent相互交叉。

(以上关于一致性的描述摘抄自https://blog.csdn.net/qiaojialin/article/details/71574203

五.交互系统

1.租约机制

目的:最小化Master节点的管理负担。

简介:Master节点为 Chunk的一个副本建立一个租约,我们把这个副本叫做主Chunk。主Chunk对Chunk的所有更改操作进 行序列化。所有的副本都遵从这个序列进行修改操作。因此,修改操作全局的顺序首先由Master节点选择 的租约的顺序决定,然后由租约中主Chunk分配的序列号决定。 

流程:

  1. 客户机向Master节点询问哪一个Chunk服务器持有当前的租约,以及其它副本的位置。如果没有一 个Chunk持有租约,Master节点就选择其中一个副本建立一个租约。
  2. Master节点将主Chunk的标识符以及其它副本(又称为secondary副本、二级副本)的位置返回给 客户机。客户机缓存这些数据以便后续的操作。只有在主Chunk不可用,或者主Chunk回复信息表 明它已不再持有租约的时候,客户机才需要重新跟Master节点联系。
  3. 客户机把数据推送到所有的副本上。客户机可以以任意的顺序推送数据。Chunk服务器接收到数据 并保存在它的内部LRU缓存中,一直到数据被使用或者过期交换出去。由于数据流的网络传输负载非 常高,通过分离数据流和控制流,我们可以基于网络拓扑情况对数据流进行规划,提高系统性能,而 不用去理会哪个Chunk服务器保存了主Chunk。
  4. 当所有的副本都确认接收到了数据,客户机发送写请求到主Chunk服务器。这个请求标识了早前推 送到所有副本的数据。主Chunk为接收到的所有操作分配连续的序列号,这些操作可能来自不同的 客户机,序列号保证了操作顺序执行。它以序列号的顺序把操作应用到它自己的本地状态中 
  5. 主Chunk把写请求传递到所有的二级副本。每个二级副本依照主Chunk分配的序列号以相同的顺序执行这些操作。
  6. 所有的二级副本回复主Chunk,它们已经完成了操作。
  7. 主Chunk服务器回复客户机。任何副本产生的任何错 误都会返回给客户机。在出现错误的情况下,写入操作可能在主Chunk和一些二级副本执行成 功。(如果操作在主Chunk上失败了,操作就不会被分配序列号,也不会被传递。)客户端的请求 被确认为失败,被修改的region处于不一致的状态。我们的客户机代码通过重复执行失败的操作来 处理这样的错误。在从头开始重复执行之前,客户机会先从步骤(3)到步骤(7)做几次尝试

2. 数据流 

目的:提高网络传输的效率。充分利用每台机器的带宽,避免网络瓶颈和高延时的连接,最小化推送所有数据的延时。
简介:把数据流和控制流分开的措施。在控制流从客户机到主Chunk、然后再到 所有二级副本的同时,数据以管道的方式,顺序的沿着一个精心选择的Chunk服务器链推送。

3.原子的记录追加 

在上面解释一致性模型的时候其实已经对此略有提及,GFS提供了一种原子的数据追加操作–记录追加。传统方式的写入操作,客户程序会指定数据写入的偏移 量。对同一个region的并行写入操作不是串行的:region尾部可能会包含多个不同客户机写入的数据片段。使用记录追加,客户机只需要指定要写入的数据。GFS保证至少有一次原子的写入操作成功执行(即 写入一个顺序的byte流),写入的数据追加到GFS指定的偏移位置上,之后GFS返回这个偏移量给客户机。这类似于在Unix操作系统编程环境中,对以O_APPEND模式打开的文件,多个并发写操作在没有竞态条件时的行为。

如果记录追加操作在任何一个副本上失败了,客户端就需要重新进行操作。重新进行记录追加的结果是, 同一个Chunk的不同副本可能包含不同的数据–重复包含一个记录全部或者部分的数据。GFS并不保证 Chunk的所有副本在字节级别是完全一致的。它只保证数据作为一个整体原子的被至少写入一次。

六.Master节点的操作

  • 管理命名空间和锁
  • 选择Chunk副本的位置
  • 对Chunk副本进行创建,重新复制,重新负载均衡。
  • 进行垃圾回收
  • 进行过期失效的副本检测

七.容错机制

容错机制是GFS中比较重要的机制,因为在GFS中,组件失效是一种常态,还可能造成系统的不可用。我们讨论的是如何面对这些挑战,以及当组件失效不可避免的发生时,用GFS自带工具诊断系统故障。

 1.高可用性

在GFS集群的数百个服务器之中,在任何给定的时间必定会有些服务器是不可用的。我们使用两条简单但 是有效的策略保证整个系统的高可用性:快速恢复和复制。

  • 快速恢复:Master服务器和Chunk服务器可以在任何情况下快速恢复状态并重新启动
  • chunk复制:每个Chunk都被复制到不同机架上的不同的Chunk服务器上。用户可以为文件命名空间的不同部分设定不同的复制级别,缺省是3。
  • Master服务器的复制 :为了保证Master服务器的可靠性, Master服务器的状态也要复制。 Master服务器所有的操作日志和checkpoint文件都被复制到多台机器上。

2.数据完整性 

每个Chunk服务器都使用Checksum来检查保存的数据是否损坏。每个Chunk服务器必须独立维护Checksum来校验自己的副本的完整性

3.诊断工具

详尽的、深入细节的诊断日志,在问题隔离、调试、以及性能分析等方面给我们带来无法估量的帮助,同 时也只需要很小的开销。

八.总结

GFS是谷歌三大论文中个人认为较为理解的一篇,主要为我们介绍了由一个Mster服务器,多个Chunk服务器,多个客户端通过特殊的交互方式组成的大规模分布式文件系统。主要搞清楚GFS中每个板块的作用,交互模式,及其的容灾方式就可以了。

在这里附上谷歌三大论文中文翻译版的链接:https://pan.baidu.com/s/1SNP3S3USTwMhh83f-m_o-g 密码:skzv

感谢浏览

展开阅读全文

没有更多推荐了,返回首页