GFS主要是为了追加(Append)而不是改写(Overwrite)而设计的。一方面是因为是改写的需求比较少,或者可以通过追加来实现;另一方面是因为追加的一致性模型相比改写要更加简单有效。若出现某些副本追加成功而某些副本没有成功的情况,失败的副本可能会出现一些可识别的填充(padding)记录。GFS客户端追加失败将重试,只要返回用户追加成功,说明在所有副本中都至少追加成功了一次。当然,可能出现记录在某些chunk副本中被追加了多次,即重复记录;也可能出现一些可识别的填充记录,应用层需要能够处理这些问题。
另外,由于GFS支持多个客户端并发追加,那么多个客户端之间的顺序是无法保证的,同一个客户端连续追加成功的多个记录也可能被打断,比如客户端先后追加成功记录R1和R2,由于追加R1和R2这两条记录的过程不是原子的,中途可能被其它客户端打断,那么GFS的chunk中记录的R1和R2可能不连续,中间夹杂着其它客户端追加的数据。
GFS的这种一致性模型是追求性能导致的,这也增加了应用程序开发的难度。对于MapReduce应用,由于其批处理特性,可以先将数据追加到一个临时文件,在临时文件中维护索引记录每个追加成功的记录的偏移,等到文件关闭时一次性将临时文件改名为最终文件。
系统交互:
2. Master节点将主Chunk的标识符以及其它副本的位置返回给客户机。客户机缓存这些数据以便后续的操作。只有在主Chunk不可用,或者主Chunk回复信息表明它已不再持有租约的时候,客户机才需要重新跟Master节点联系。
3. 客户机可以以任意的顺序推送数据到所有的副本上。 Chunk服务器接收到数据并保存在它的内部LRU缓存中。通过分离数据流和控制流,GFS基于网络拓扑情况对数据流的网络传输负载进行规划,提高系统性能。
5. 主Chunk把写请求传递到所有的二级副本。每个二级副本依照主Chunk分配的序列号以相同的顺序执行这些操作。
6. 所有的二级副本回复主Chunk,它们已经完成了操作。
容错和诊断机制
Master服务器的复制
回应,以及收集不同机器上的RPC日志记录,重演所有的消息交互来诊断问题。RPC日志还用来跟踪负载测试和性能分析。
负载均衡
Master节点管理整个系统里所有Chunk副本,在制定Chunk副本的分布策略时需要考虑多种因素,如网络的拓扑,机架的分布,磁盘的利用率等等。
Chunk的副本有三个用途: Chunk创建,重新复制和重新负载均衡。
当Master创建了一个chunk,它会根据如下因素来选择chunk副本的初始位置:(1) 新副本所在的Chunk Server的磁盘利用率低于平均水平;(2) 限制每个Chunk Server”最近”创建的数量。(3)每个chunk的所有副本不能在同一个机架。第二点容易忽略但却很重要,因为创建完chunk以后通常需要马上写入数据,如果不限制”最近”创建的数量,当一台空的Chunk Server上线时,由于磁盘利用率低,可能导致大量的chunk瞬间迁移到这台机器从而将它压垮。
当Chunk的有效副本数量少于用户指定的复制因数的时候, Master节点会尝试重新复制一个chunk副本。这可能是由几个原因引起的:一个Chunk服务器不可用了, Chunk服务器报告它所存储的一个副本损坏了, Chunk服务器的一个磁盘因为错误不可用了,或者Chunk副本的复制因数提高了。每一个chunk复制任务都有一个优先级,按照优先级从高到低在Master排队等待执行,例如GFS提高会阻塞客户机程序处理流程的Chunk的优先级。
最后,Master会定期扫描当前副本的分布情况,如果发现磁盘使用量或者机器负载不均衡,将执行重新负载均衡操作。无论是chunk创建,chunk重新复制,还是重新平衡,它们选择chunk副本位置的策略都是相同的,并且需要限制重新复制和重新平衡任务的拷贝速度,否则可能影响系统正常的读写服务。
当文件被删除后,GFS不会马上回收其物理存储,而是立刻把删除操作以日志的方式记录下来。把文件名改为一个包含删除时间戳的、隐藏的名字。Master定时检查,如果发现文件删除超过一段时间(默认为3天,可配置),那么它会把文件从内存元数据中删除,回收物理存储资源。在文件被真正删除之前,它仍能够被Master以特殊的方式访问。为了减轻Master服务器的负担,回收文件物理资源的工作交由Chunk服务器完成:在Chunk 和Master的心跳消息中,Master会回复在Master元数据中已经不存在的chunk信息,Chunk服务器才会释放这些Chunk副本的资源。
另外,Chunk副本可能会因为Chunk服务器失效期间丢失了对Chunk的修改操作而导致过期。系统对每个Chunk都维护了版本号,过期的Chunk可以通过版本号检测出来。Master仍然通过正常的垃圾回收机制来删除过期的副本。
快照
快照(Snapshot)操作是对源文件/目录进行一个”快照”操作,生成该时刻源文件/目录的一个瞬间状态存放与目标文件/目录中。GFS中使用标准的copy-on-write机制生成快照,也就是说,”快照”只是增加GFS中chunk的引用计数,表示这个chunk被快照文件引用了,等到客户端修改这个chunk时,才需要在Chunk服务器中拷贝chunk的数据生成新的chunk,后续的修改操作落到新生成的chunk上。
为了对某个文件做Snapshot,首先需要停止这个文件的写服务,接着增加这个文件的所有chunk的引用计数,以后修改这些chunk时会拷贝生成新的chunk。对某个文件执行Snapshot的大致步骤如下:
1, 通过Lease机制收回对文件每一个chunk写权限,停止对文件的写服务;
2, Master拷贝文件名等元数据生成一个新的Snapshot文件;
3, 对执行Snapshot的文件的所有chunk增加引用计数;
例如,对文件foo执行快照操作生成foo_backup,foo在GFS中有三个chunk C1,C2和C3。Master首先需要收回C1,C2和C3的写Lease,从而保证文件foo处于一致的状态,接着Master复制foo文件的元数据生成foo_backup,foo_backup同样指向C1,C2和C3。快照前,C1,C2和C3只被一个文件foo引用,因此引用计数为1;执行快照操作后,这些chunk的引用计数增加为2。以后客户端再次往C3追加数据时,Master发现C3的引用计数大于1,通知C3所在的Chunk Server本次拷贝C3生成C3′,客户端的追加操作也相应地转向C3′。
ChunkServer
ChunkServer管理大小均为64MB的chunk,存储的时候需要保证chunk尽可能均匀地分布在不同的磁盘之中,可能考虑的因素包括磁盘空间,最近新建chunk数,等。另外,Linux文件系统删除64MB大文件消耗的时间太长,且没有必要,删除Chunk可以只将对应的chunk文件移动到每个磁盘中的回收站,以后新建chunk的时候可以重用。
小结:
GFS采用中心服务器的模式,该模式的最大优点是便于管理,因为中心服务器可以获知所有子服务器的状态,因而可以很方便的得知各个子服务器的负载状况等。但是这一模式也有一个比较致命的缺点,那就是单点故障。当单点故障发生在中心服务器时,将导致整个系统的不可用。不过,按照上述描述,GFS的中心服务器只是逻辑上是一个,可以知道,其实GFS的Manster还是有后备机制—shadow Master的,Master通过后备机制来应对中心服务器故障并且缩短其灾后恢复时间。
相关推荐
Google GFS架构分析.docx
这个架构是利用GFS文件系统分布式复制卷的容错性,结合KVM的虚拟化,把虚拟机的文件存储在GFS的分布式复制卷上,实现KVM上的虚拟机高可用 实验原理 利用Glusterfs的分布式复制卷,对KVM虚拟机进行分布存储和冗余功能...
Google文件系统(GoogleFileSystem,GFS)是构建在廉价的服务器之上的大型分布式系统。它将服务器故障视为正常现象,通过软件的方式自动容错,在保证系统可靠性和可用性的同时,大大减少了系统的成本。 GFS是Google...
Google分布式文件系统(GFS) Google分布式计算框架(MR) Google Bigtable Database 4.2大数据应用 对企业大数据应用的理解 大数据流式计算技术解析之一 大数据流式计算技术解析之二 延伸阅读 JamesHamilton...
Intel 和 AMD x86/x86-64 Intel Itanium2 IBM pSeries 标准支持 CGL 4.0 支持 LSB 4.0 支持 GB18030-2005 支持 文件系统支持 多种文件系统支持情况 EXT3、EXT4、XFS、VFAT、NFS4,GFS、OCFS2、 LVM2、 SOFT RAID等 ...
HDFS:类似Google GFS的分布式文件系统 MapRedce:并行计算架构,将计算任务拆分成大量可以独立运行的子任务,接着并行运算,另外会有一个系统调度的架构负责收集和汇总每个子任务的分析结果 HBase: 类似Google ...
如何从海量的数据中找到自己想要的信息 Google三大神器 具备海量数据存储和访问的分布式文件系统 GFS 简洁高效的并行计算编程模型 MapReduce 支持海量结构化数据管理的BigTable 大数据分析技术基础教学课件3-大数据...
本篇将主要介绍Google的十个核心技术,而且可以分为四大类:由于搜索引擎需要处理海量的数据,所以Google的两位创始人LarryPage和SergeyBrin在创业初期设计一套名为"BigFiles"的文件系统,而GFS
分而治之 大数据处理实现技术 —— 分布式储存系统GFS / HDFS 谷歌文件系统(GFS) 解决方案 大数据处理技术简介全文共52页,当前为第16页。 …….. 10G 1分30秒 100M/S 大数据处理实现技术 —— 分布式储存系统GFS...
12.6.5 管理和维护GFS2文件系统 12.7 RHCS集群功能测试 12.7.1 高可用集群测试 12.7.2 存储集群测试 12.8 本章小结 第13章 Oracle RAC集群 13.1 Oracle集群体系结构 13.2 Oracle ClusterWare体系结构...
HadoopHadoop 采用 Map Reduce 分布式计算框架,根据 GFS开发了 HDFS 分布式文件系统,根据 Big Table 开发了 HBase数据存储系统。Hadoop 的开源特性使其成为分布式计算系统的事实上的国际标准。Yahoo,Facebook,...
2.1 Google文件系统GFS 17 2.1.1 系统架构 18 2.1.2 容错机制 20 2.1.3 系统管理技术 20 2.2 分布式数据处理MapReduce 21 2.2.1 产生背景 21 2.2.2 编程模型 22 2.2.3 实现机制 22 2.2.4 案例分析 24 2.3 分布式锁...
考虑到系统由大量廉价易损的硬件组成,为了保证文件整体可靠性,大数据通常对同一份数据在不同节点上存储多份副本,同时,为了保障海量数据的读写能力,大数据借助分布式存储架构提供高吐量的数据访问. 超人学院...
大数据时代: 数据量大 数据种类繁多 数据增长速度快 大数据不同层面及技术: 大数据关键技术: 分布式存储 GFS/HDFS BigTable/HBase ...hadoop以分布式文件系统HDFS和MapReduce为核心进行海量数据的
MapReduce分布式方法最先由谷歌设计并实现,包括分布式文件系统GFS、MapReduce分布式编程环境以及分布式大规模数据库管理系统Bigrable。MapReduce是一套软件框架,包括Map和Reduce两个阶段,可以进行海量数据分割、...
主要包含NameNode(用来管理 文件系统的命名空间)和DataNode(文件系统中真正存储 数据的地方) MapReduce MapReduce是一个高性能的批处理分布式 计算框架,用于对海量数据进行并行分析和处 理。MapReduce采用"分而治之...
1.HDFS:存储、分布式文件系统 2.MapReduce:分布式编程框架(jar包) 3.Yarn:资源调度管理集群,管理分配硬件资源。 把Hadoop理解为: 1.当作框架(例如tensorflow),专用于大数据处理,而不是Web开发 2.当作服务软件...