收藏 分享(赏)

面向大数据分析的分布式文件系统关键技术.doc

上传人:无敌 文档编号:204696 上传时间:2018-03-23 格式:DOC 页数:16 大小:152KB
下载 相关 举报
面向大数据分析的分布式文件系统关键技术.doc_第1页
第1页 / 共16页
面向大数据分析的分布式文件系统关键技术.doc_第2页
第2页 / 共16页
面向大数据分析的分布式文件系统关键技术.doc_第3页
第3页 / 共16页
面向大数据分析的分布式文件系统关键技术.doc_第4页
第4页 / 共16页
面向大数据分析的分布式文件系统关键技术.doc_第5页
第5页 / 共16页
点击查看更多>>
资源描述

1、面向大数据分析的分布式文件系统关键技术 周江 王伟平 孟丹 马灿 古晓艳 蒋杰 中国科学院计算技术研究所计算机应用研究中心 中国科学院大学 中国科学院信息工程研究所 腾讯公司数据平台部 摘 要: 大数据时代的来临使数据分析和处理能力成为数据中心和互联网公司日益倚重的技术手段.信息规模的扩大和数据结构的多样化,使海量数据存储成为大数据分析研究的热点.传统的分布式文件系统在扩展性、可靠性和数据访问性能等方面难以满足新形势下的需求.设计并实现了一个面向大数据分析、专为大规模集群应用的分布式文件系统 Clover.该系统采用基于目录划分和一致性 Hash 映射的名字空间管理方法,解决了元数据扩展性问题

2、;通过改进的两阶段提交协议,保证了多元数据服务器下分布式元数据操作的一致性;提出了基于共享存储池的高可用机制,通过热备和全局状态恢复机制提高了元数据的可靠性.评测结果表明,Clover 的元数据处理能力随服务器的数量线性增长,增加单个服务器的元数据操作性能平均提升了 5.13%159.32%.由于名字空间管理和分布式事务的开销,多元数据服务器会导致复杂操作的性能下降,但是这种下降的幅度很小(小于 10%).与 HDFS 相比,Clover 的文件读写带宽与之接近,并能够保证在元数据服务器失效后文件系统快速恢复,适合于构建高可扩展和高可用的存储系统.关键词: 大数据; 海量数据存储; 分布式文件

3、系统; 元数据可扩展性; 高可用性; 作者简介:周江 作者简介:Wang Weiping,born in 1975.Received his BSc,MSc and PhD degrees from Harbin Institute of Technology in 1997,2001and 2006respectively.Associate professor in the Institute of Information Engineering,Chinese Academy of Sciences.His research interests include database,mass

4、 data management and parallel processing().作者简介:Meng Dan,born in 1965.Professor and PhD supervisor.His research interests include high performance computer architecture,operation system,high performance communication protocol,distributed file system and storage system().作者简介:Ma Can,born in 1984.Rece

5、ived his bachelor degree from Nankai University in 2006,PhD degree from the Institute of Computing Technology,Chinese Academy of Sciences in 2012.His major research interests include distributed file system and dependable computing().作者简介:Gu Xiaoyan,born in 1987.PhD candidate in the University of Ch

6、inese Academy of Sciences.Her main research interests include cloud data management,big data,etc().作者简介:Jiang Jie,born in 1979.Assistant manager of data platform department,Tencent,Inc.His research interests include distributed system,mass data management and parallel computing().收稿日期:2012-09-28基金:国

7、家“八六三”高技术研究发展计划基金项目(2013AA013204)Key Technology in Distributed File System Towards Big Data AnalysisZhou Jiang Wang Weiping Meng Dan Ma Can Gu Xiaoyan Jiang Jie Computer Application Research Center,Institute of Computing Technology,Chinese Academy of Sciences; Institute of Information Engineering,Ch

8、inese Academy of Sciences; Data Platform Department,Tencent Inc.; Abstract: With the arrival of big data period,data analysis and processing are becoming a more important technology which the data center and Internet companies depend on.Mass data storage is a hotspot topic in big data analysis with

9、the expansion of information and variety of data structure.Traditional distributed file systems are lack of the new demands in scalability,reliability and performance.In this paper,a cluster file system towards big data analysis is designed,which is named Clover.Clover uses the namespace management

10、based on directory sharding and consistent hashing to solve the problem of metadata extension.It provides metadata consistency for distributed transactions through a modified two-phase commit protocol.Moreover,Clover presents a highly available mechanism based on the shared storage pool.It achieves

11、metadata reliability with hot standby and global state recovery mechanism.The evaluation results reveal that Clover could improve metadata performance linearly with the average value from 5.13%to 159.32% by adding one metadata server.Namespace management and distributed transactions would cause the

12、degradation of performance on multiple metadata servers,but the influence is negligible(less than 10%).Comparing with HDFS,Clover could keep the similar throughput and quickly recover from metadata server failures.Practical application tests show that Clover is suitable for building high scalable an

13、d high available storage system.Keyword: big data; mass data storage; distributed file system; metadata scalability; high availability; Received: 2012-09-28随着数据中心数据信息的增加和互联网应用的多样化,大量半结构化和非结构化数据涌现,大数据时代来临.在大数据分析和处理技术吸引了越来越多关注的同时,作为其底层支持的海量数据存储系统成为研究的热点.大数据时代的海量数据存储呈现出新的特点:1)数据规模不断扩大,文件数量急剧增长,一些大型的互联网

14、公司如 Google,腾讯等的数据规模已突破 PB 量级,需要管理的文件数达到亿级;2)访问并发度高.互联网信息服务通常面对大量的用户,同时在线人数也达数千万.大量的用户并发访问造成大量的随机读写,对存储系统的元数据性能和文件访问延迟带来很大的挑战;3)数据结构和处理需求呈现多样化,包括离线数据分析类应用和在线并发访问类应用,经常需要 247h 不间断服务,对系统的可靠性要求越来越高.典型的分布式文件系统,如 NFS 和 HDFS,元数据采用的是集中式管理,其元数据都存储在一个服务器中.HDFS 是 Apache 基金项目 Hadoop 项目中提供的一个分布式存储系统,提供了高效的海量数据存储

15、解决方案.HDFS 借鉴了 Google 的 GFS文件系统,是设计运行在通用硬件上的分布式文件系统,适合于大数据的读写,且在设计上考虑了系统的容错性.HDFS 不仅是一个分布式存储系统,同时结合了Hadoop 的 MapReduce 编程框架,为大数据分析提供了存储支持,满足互联网的访问需求和分布式计算等应用.但由于 HDFS 是针对单个元数据服务器而设计的,当文件和目录规模扩大时,面临内存不足的情况,单点的元数据请求负载的压力也随之增加,可扩展性受到限制.近年推出的分布式文件系统,像 GPFS,Ceph 和 Farsite 等,利用一组服务器集群来管理元数据信息,在一定程度上缓解了单元数据

16、服务器的限制.GPFS 是定义在多个节点上的集群文件系统,为应用提供并发的、高速的文件访问,适合于大数据量的顺序操作,其扩展性和故障处理能力有限.Ceph 是基于对象存储、采用元数据和数据分开管理的方式,元数据服务器集群通过缓存和分布式元数据服务器管理文件系统的名字空间,实际的文件数据传输在客户端和对象服务器之间进行.Ceph 具有良好的性能和扩展性,其在异构元数据服务器和网络延迟较大时存在问题,不适合于生产环境.大数据时代下的海量存储系统要满足数据分析和处理的需求,支持数据中心和互联网应用的不同服务,需要满足以下几点:1)由于文件数量庞大,元数据操作不断增加,需要存储系统有较好的可扩展性和并

17、发处理能力;2)提供多种访问方式以支持不同应用,对元数据操作的一致性要求较高;3)数据共享与数据安全的保障越来越重要,需要存储系统提供高可用的文件系统服务.针对以上问题,本文提出了面向大数据分析,用于满足数据中心和互联网应用服务的分布式文件系统 Clover.它是一个虚拟文件系统,采用多元数据服务器架构,为系统客户提供高可扩展和高可用的存储服务.它采用基于目录划分和一致性Hash 算法的两级映射机制来管理名字空间,提高了系统的可扩展性,同时引入分布式全局目录表,减少了元数据迁移带来的开销.它基于共享存储池设计,利用改进的两阶段提交协议,解决了扩展元数据服务所带来的分布式元数据操作一致性问题.C

18、lover 还提出了基于共享存储池的高可用机制,提高了元数据的可靠性.评测结果表明,Clover 适合于构建大容量、高可扩展和高可用的存储系统,并能够支持 MapReduce 框架下的大数据分析及其应用.1 相关研究当前的分布式文件系统提出了集群系统上的存储解决方案.经过多年发展,分布式文件系统结构发展为以专有服务器系统占主流,通过专门的服务器分别提供元数据访问和数据存储的方式来提供服务.分布式文件系统通常采用多元数据服务器,通过增加服务器节点的数量,满足集群应用对文件系统的容量、性能和规模等日益增长的需求.名字空间管理是分布式文件系统在多元数据服务器下面临的重要问题,即采取何种方式将文件和目

19、录映射到服务器节点上.最常用的方法是静态划分目录树结构,将每个子树分配到指定的服务器上,如 Sprite,StorageTank 和 PanFS.Sprite 将名字空间区分为不同的域,对文件系统进行分区并映射到不同的服务器上.这种方式简单方便,然而不能满足目录和文件的增长带来的元数据扩张,需要系统管理员来进行子树的重新划分.StorageTank 和 PanFS 划分文件集合的粒度较小,且能够在服务器之间进行迁移,但迁移的子树大小是固定的,负载均衡能力较弱.基于 Hash 的划分方式在 Lustre,zFS,GIGA+等文件系统中使用.为了改变静态子树划分带来的负载不均衡问题,Lustre

20、通过 Hash 方式将目录元数据组织成索引节点组,以组为单位分配给元数据服务器.它提供了一个细粒度的划分方式,动态地将元数据划分到不同的服务器.GIGA+ 通过可扩展 Hash 算法对目录进行分片,利用位图缓存文件的索引和映射信息,避免同步开销,提高了元数据的并发访问性能,适合于单目录下大量文件的访问.某些分布式文件系统也采用了类似 Hash 的划分方式,如 Vesta 和 RAMA 通过对文件路径名或其他的唯一标识符来决定元数据的存放位置.还有一些文件系统采用了动态子树划分的元数据管理策略,如Ceph 和 Farsite,根据文件系统的负载来动态的将目录分布到集群中.Farsite通过自定义

21、的文件标识符将目录层次结构以子树为粒度分布到不同的节点上,它基于 Windows 系统实现,且不支持硬链接.Ceph 采用分布式的动态元数据管理方法,通过对目录子树的复制和迁移实现负载均衡,避免增加或减少服务器产生的错误和数据搬迁.动态子树划分方法能够较好地适应不同的负载,对服务器进行负载均衡,但元数据迁移开销较大,实现起来较为复杂.分布式文件系统通过多元数据服务器来处理元数据信息,提高文件系统的可扩展性.在元数据服务器集群中,有些元数据操作需要多个节点协同完成.由此带来的问题是如果网络出错或服务器节点失效,会导致各元数据服务器上的状态不一致.当前大部分分布式文件系统都直接利用日志文件系统或与

22、日志相关的技术来解决元数据一致性问题.Sprite 和 Lustre 等只有单个元数据服务器,元数据信息保存在本地文件系统,通常依赖于服务器的本地文件系统日志恢复机制,来保证元数据的一致性.GPFS 没有专门的服务器,采用与日志文件系统类似的技术来恢复元数据的一致性.StorageTank 各服务器之间是独立的,只需在本地恢复出错的服务器上的元数据一致性即可.DCFS2 借鉴分布式事务处理中的分布式日志技术和两阶段提交协议,来解决分布式元数据处理的元数据一致性问题.针对两阶段提交协议的缺陷,还出现了一些改进的协议,如 3PC 和 D2PC 协议,但这些协议实现起来复杂,且影响系统性能.分布式文

23、件系统的元数据服务器集群中,如果节点出错或网络故障,还会影响文件系统的可用性.随着集群规模的扩大,设备出错的概率增加,需要上层的软件系统提供高可靠保证,在出现故障时不影响文件系统的服务.现有的可靠性机制主要有文件副本、单点失效的避免与恢复、故障检测及处理等.GoogleFS 考虑集群规模扩大带来的易故障性,使用数据多副本及主备技术,当元数据服务器节点出错时启动备用节点,来实现文件系统的可用性.GPFS 通过提供块设备级的数据镜像和文件层拷贝来提高文件系统的可靠性,但需要专门的存储区域网络和双通道控制器等硬件设备来支持.Ceph 采用分布式服务器管理元数据,利用可靠的自动化对象存储和多级副本放置

24、算法来保证数据的可靠性.Realtime HDFS 针对实时在线系统,对 HDFS 进行改进,通过增加 avatar 节点,对元数据服务器进行热备,能够较好地避免单一元数据服务器带来的单点故障问题,但依赖于 NFS 文件系统支持,且开销较大.2 Clover 整体架构Clover 分布式文件系统采用多元数据服务器架构,将文件访问的数据流与控制流有效分离,在完全兼容 HDFS 接口的情况下,旨在提高元数据的可扩展性和可用性,保证元数据服务器集群下元数据操作的一致性,同时保持文件系统的性能.部署到一个集群中时,Clover 主要由若干元数据服务器(metadata server,MDS)、若干数据

25、服务器(datanode,DN)、一个共享存储池(shared storagepool,SSP)和众多客户端节点组成,如图 1 所示:Fig.1 The architecture of Clover.图 1 Clover 系统结构图 下载原图图 1 中,MDS 处理元数据请求,多个 MDS 构成一个全局的名字空间(namespace),提供文件系统服务.MDS 缓存了文件系统的元数据信息,包括文件索引节点号、文件属性、创建时间等,在逻辑上以树形结构组织,并以镜像文件(fsimage)和日志文件(fseditlog)的方式持久化到 SSP 中.MDS 节点在提供自身名字空间管理的同时,也作为 S

26、SP 中的共享存储节点,保存其他 MDS 镜像和日志文件的副本信息.MDS 在写镜像和日志文件时,首先将其写回本地磁盘,然后通过网络在 SSP 的共享存储节点中写多个副本.在 MDS 看来,SSP 就是一个虚拟的存储设备,其内部通过多副本机制,保证了镜像和日志文件的可靠性.文件以分块的形式存放在 DN 上,DN 对每个分块进行多副本放置,并进行块级别的数据校验.文件的块信息并不存放在 MDS 上,而是启动时由 DN 汇报上来,不同的块信息根据其文件所属的 MDS 发送到对应的节点上,以减少元数据的内存占用开销.为提高文件系统的可用性,定期对 MDS 做检查点(checkpoint),将内存元数

27、据信息和日志内容合并成一个新的镜像文件,并持久化到 SSP 中.检查点可以针对单个 MDS,也可以是全系统进行.由于故障的存在,引入备用节点(backup node)对元数据服务器进行热备,使其能够在主节点出错时快速的进行替换,恢复文件系统服务.3 高可扩展的元数据服务Clover 面向的是大数据分析下的 PB 级海量数据存储,采用多元数据服务器的主要目的是提高系统的可扩展性,同时解决由扩展性所带来的多元数据服务器分布式元数据操作的一致性问题.3.1 基于目录划分和一致性 Hash 映射的名字空间管理方法多元数据服务器的元数据管理的关键问题是如何划分和映射名字空间信息.名字空间的划分要具有自适

28、应性和可扩展性,能够适应目录和文件的动态增长,并带来较少的开销.在 Clover 中,名字空间划分的基本思想是根据文件路径名对文件系统的名字空间进行分拆,拆分的单位为名字空间的目录,单个目录是不可拆分的,并采用一致性 Hash 的方法,通过两级映射机制将其较为均衡的分布到多个节点上.当文件和目录分散到元数据服务器集群中时,对于有些操作,如 rename,可能影响到多个元数据服务器.为了避免跨节点操作造成的大量元数据迁移,引入一个全局的分布式目录 Hash 表(global Hash table,GDT),用于建立目录到元数据服务器的映射关系.因此,Clover 的名字空间通过两级映射机制来实现

29、.第 1 级采用文件或目录的路径名作 Hash 计算,得到其上级目录所在的 GDT 表分片.第 2 级根据路径名在 GDT 表中查找,得到唯一的标识符,然后通过一致性 Hash 算法,在元数据服务器所构成的一致 Hash 环上查找距离最近的节点,将其映射到某个元数据服务器上.如图 2 所示,对于文件或目录,首先通过其路径名来进行 Hash 计算,采用 :Hash(dirname(filename)=GDT(i),定位到文件或目录所在的 GDT 分片,从GDT 表中查找得到一个唯一的 UUID(universally unique identifier)值;然后根据该 UUID 值,采用 :Ha

30、sh(UUID)=vNode(i)进行计算,将其映射到虚拟节点vNode(i)上;最后,根据一致性 Hash 算法将虚拟节点 vNode(i)映射到实际的物理服务器 pNode(i)上.图 2 中,名字空间目录树中的根目录“/”,目录“/A”,目录“/B”及目录“/B/C”分别映射到 MDS0 到 MDS3 4 个元数据服务器上.同时,目录“/A”及目录“/B/C”下的所有文件,也分别映射到“/A”和“/B/C”目录所在的 MDS 上.Fig.2 Sharding and mapping of namespace in Clover.图 2 Clover 名字空间的划分与映射 下载原图GDT

31、是整个名字空间中所有目录组成的一张映射表,类似于一个分布式 Hash 表,以分片的方式存放在多个元数据服务器上.图 3 表示了利用 GDT 表进行 rename的过程,其中虚线表示需要删除的部分.图中,目录 “/bin/foo3”根据第 1 级Hash 算法,被映射到 MDS1 所在 GDT 分片上,并通过一个唯一的值 UUID3 来标识该项,该目录的实际元数据信息,根据第 2 级 Hash 算法映射到了 MDS2 上.当进行rename 操作时,如将 “/bin/foo3”重命名为“/bin/foo7”,则在 GDT 表中删除原目录项 “/bin/foo3”,增加新的目录项 “/bin/fo

32、o7”,同时保持其 UUID不变.根据第 1 级 Hash 算法,新的目录项“/bin/foo7”存放在 MDS2 上的 GDT分片中;由于其 UUID 与原来是一样的,根据第 2 级 Hash 算法,目录 “/bin/foo7”下的所有元数据信息还是保留在 MDS2 服务器上,可直接进行修改.因此,对于 rename 等操作,利用 GDT 表进行目录项的修改,不需要进行大量元数据的迁移,减少了额外的开销.Fig.3 Rename operation with GDT.图 3 利用 GDT 表进行 rename 操作 下载原图采用基于目录的名字空间划分和一致性 Hash 算法的两级映射机制的优

33、点是局部性较好,同一目录的所有文件都存放在一个元数据服务器上,对于 getlisting 等操作比较方便.一致 Hash 环有利于元数据服务器的透明扩展,分布式 Hash 表GDT 能够有效减少跨节点操作时带来的元数据迁移开销,有利于系统的负载均衡.3.2 基于共享存储池的元数据一致性策略Clover 的元数据一致性策略主要解决分布式元数据处理下元数据的一致性问题.Clover 采用基于目录的两级 Hash 映射机制,文件与其父目录是在同一个元数据服务器上,但目录之间的元数据可能不在同一个服务器上.有些元数据操作,如mkdir,rename 等涉及不同的目录,如果它们不在一个节点上,则需要多个

34、元数据服务器协同完成.为了保证文件系统元数据操作的一致性,Clover 借鉴用于处理分布式事务的两阶段提交协议,解决多元数据服务器中的元数据一致性问题.两阶段提交协议可以保证数据的强一致性,许多分布式关系数据库系统采用此协议来完成分布式事务.它分为准备阶段(prepare)和提交阶段(commit),通过协调分布式事务的协调者(coordinator)和参与者(cohort)来决定是否提交或取消(回滚)事务.该算法基于阻塞式协议能够解决一些临时性错误,但在故障处理等方面还存在不足.在分布式文件系统中利用两阶段提交协议进行事务处理,存在的主要问题是,当出现网络故障或节点失效时容易造成事务状态的不

35、确定.Clover 基于共享存储池提出了一种改进的两阶段提交协议,来保证出错时分布式事务状态的确定性.该协议以元数据服务器为主导,结合分布式日志和全局日志,在不影响性能的情况下,解决两阶段提交协议由于故障带来的状态不确定问题.为了能够在出错时确定分布式事务的状态,事务的参与者除了记录本地日志文件,还会记录预写式全局日志(global write aheadlog,GWAL),故障恢复通过本地日志和全局日志的内容来进行.本地日志记录分布式事务中与本地节点相关的元数据操作信息,包括操作类型、文件路径、服务器标识等,并通过分布式事务 ID 来进行标记.全局日志记录分布式事务 ID 和事务状态标记.每

36、个元数据服务器都有自己的本地日志文件,但全局日志文件在系统中只维护一份.图 4 示出了基于共享存储池的分布式事务处理过程,主要分为 4 个阶段.首先客户端提交操作请求,系统选择出相关的元数据服务器,并分配不同的角色.在图 4中,B 是协调者,A,C,D,E 是事务的参与者.在准备阶段,协调者发送命令给各参与者,通知其进行操作条件的检查,并等待参与者的应答.参与者在检查完自身是否满足事务的条件后,记录本地日志,并向协调者发送就绪或取消消息.协调者根据参与者的应答信息来决定是否能够执行事务:如果接收到所有参与者的就绪消息,协调者判断该事务为可执行,记录一条全局日志到共享存储池中,并设置其状态为成功

37、(success);如果某个参与者不满足条件并发送取消的消息,协调者判断该事务为不可执行,记录一条事务失败(fail)的全局日志到共享存储池中.在协调者按时接收到所有参与者的反馈信息情况下,事务的状态是确定的.由于在这个过程中会出现故障,容易导致协调者不能及时接收到参与者的信息.故障的原因有多种,如网络出错、节点失效等,为方便处理,将所有的故障都归结为超时错误,如果在指定的时间内协调者没有接收到所有参与者的就绪信息,则标记该事务为失败.Fig.4 Distributed transaction based on shared storage pool(SSP).图 4 基于共享存储池的分布式事

38、务 下载原图在准备阶段和判定阶段完毕后,事务进入到执行阶段,协调者广播执行或取消命令给参与者.在没有故障的情况下,参与者接收到执行命令后开始进行各自的元数据操作;如果接收到取消命令则不进行分布式事务操作.若在此阶段系统出现故障,容易导致事务进入不确定的状态,需要通过共享存储池的协调来进行容错处理.如果在指定的时间内,参与者没有接收到协调者发送的广播消息,则可能由于网络故障或协调者出错导致信息接收失败.此时,参与者访问共享存储池,通过事务 ID 号查找全局日志信息来判断是否执行事务:当事务标记为可执行时说明全局事务日志已经记录成功,参与者可以执行对应的元数据操作;当事务标记为失败时说明该事务不能

39、执行,参与者忽略其操作;当没有发现对应的全局事务日志时,可能是协调者出错或者还没有写入事务状态,在设定参与者的超时时间大于协调者超时时间的情形下可确定是协调者出错.此时该事务不能执行,并由参与者写入一条事务失败的全局日志.由于共享存储池是稳定可靠的,因而能够保证节点对全局日志的正确访问,避免由于出错而带来的事务状态不确定性.4 元数据高可用机制随着集群规模的扩大,在大数据分析和处理过程中,网络故障和节点失效等错误发生的概率增加,需要底层的分布式文件系统提供高可用保证,保持文件系统服务的连续性.4.1 元数据服务器状态恢复机制在 Clover 中,元数据服务器都是有状态的,缓存了文件和目录的元数

40、据信息.由于存在跨节点操作,各元数据服务器之间也经常进行通信,当节点失效或故障重启时需要重新恢复元数据信息.Clover 基于共享存储池,利用镜像和日志文件,进行元数据的状态恢复.文件系统运行时,服务器的内存元数据信息以镜像文件的形式保存到共享存储池中,同时,对于每次元数据操作都会记录日志信息.当服务器出错需要恢复状态时,通过从共享存储池中加载镜像文件和重放日志来进行.共享存储池作为一个可靠的虚拟存储池,负责元数据文件的存储和加载,并利用多副本提高文件的冗余度.元数据服务器故障重启时,首先根据共享存储池汇报的镜像和日志文件信息构建其逻辑卷视图.同时,服务器对汇报上来的副本进行数据一致性校验,如

41、果出现文件内容或长度不一致的情况,则进行副本的更新和修复.在元数据加载过程中,服务器首先尝试从本地磁盘读取镜像和日志文件信息,如果本地文件访问失败,则从共享存储池的远程节点中读取副本信息,重新恢复元数据服务器的状态.4.2 基于共享存储池的节点热备元数据服务器集群中,当某个元数据服务器出错时,就不能继续提供它所维护的名字空间服务,影响上层文件系统的访问.为了对服务器单点失效进行故障恢复,最简单的方式是等待出错的节点重启,但需要较长的时间等待其恢复元数据状态信息.还有一种方式是通过备用节点来进行备份,当主节点出错时启动备用节点,重新加载其元数据信息,恢复主节点一致的元数据状态,并替代主节点提供元

42、数据服务.但启动备用节点和重新加载元数据信息需要一定的时间,影响上层文件系统操作.Clover 基于共享存储池,对集群中每个元数据服务器利用影子节点(shadow node,SN)来进行热备,无需额外的文件系统或设备支持就能快速恢复故障.影子节点可以是集群中的元数据服务器,也可以是单独的节点.如果某个元数据服务器是另一个元数据服务器的影子节点,在正常情况下只提供本身所负责的名字空间服务.通常情况下影子节点不提供元数据服务,处于备用状态,但始终维护与元数据服务器一致的名字空间.影子节点在启动时,通过共享存储池读取对应元数据服务器的名字空间信息,将其加载到内存中,并接收数据服务器的块汇报信息.在进

43、行文件操作时,每当元数据服务器更新完元数据信息,写日志事务到日志文件中时,影子节点通过共享存储池,从日志副本文件中读取对应的日志,在内存中重放事务,同步元数据服务器的名字空间信息.当元数据服务器失效时故障检测机制发现其无法对外提供服务,自动进行元数据服务器和影子节点的切换,由影子节点接替元数据服务器,保证服务的连续性.图 5 示出了基于共享存储池的影子节点热备.共享存储池提供了元数据的复制和同步,元数据服务器之间相互进行热备,保证在单个服务器失效时由影子节点接替其名字空间服务,从而提高文件系统的可用性.Fig.5 Hot standby based on shared storage pool.图 5 基于共享存储池的节点热备 下载原图4.3 基于共享存储池的全局状态恢复机制元数据服务器集群的全局状态恢复是指由于有多个节点同时出错而导致文件系统不可用,即使采用热备的方式也不能保证每个服务器都能正常恢复状态.此时需要对全系统进行重启,并进行系统级的故障恢复.全局状态恢复过程中的主要问题是,各节点如何恢复到故障前的一致状态.如果元数据服务器恢复后的状态不同容易导致文件系统名字空间的不一致.

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 学术论文 > 期刊/会议论文

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报