当前位置:文档之家› 分布式文件系统架构设计

分布式文件系统架构设计

分布式文件系统架构设计目录1.前言 (3)2.HDFS1 (3)3.HDFS2 (5)4.HDFS3 (11)5.结语 (15)1.前言Hadoop是一个由Apache基金会所开发的分布式系统基础架构。

用户可以在不了解分布式底层细节的情况下,开发分布式程序。

充分利用集群的威力进行高速运算和存储。

Hadoop实现了一个分布式文件系统(Hadoop Distributed File System),简称HDFS,解决了海量数据存储的问题;实现了一个分布式计算引擎MapReduce,解决了海量数据如何计算的问题;实现了一个分布式资源调度框架YARN,解决了资源调度,任务管理的问题。

而我们今天重点给大家介绍的是Hadoop里享誉世界的优秀的分布式文件系统-HDFS。

Hadoop重要的比较大的版本有:Hadoop1,Hadoop2,hadoop3。

同时也相对应的有HDFS1,HDFS2,HDFS3三个大版本。

后面的HDFS的版本,都是对前一个版本的架构进行了调整优化,而在这个调整优化的过程当中都是解决上一个版本的架构缺陷,然而这些低版本的架构缺陷也是我们在平时工作当中会经常遇到的问题,所以这篇文章一个重要的目的就是通过给大家介绍HDFS不同版本的架构演进,通过学习高版本是如何解决低版本的架构问题从而来提升我们的系统架构能力。

2.HDFS1最早出来投入商业使用的的Hadoop的版本,我们称为Hadoop1,里面的HDFS就是HDFS1,当时刚出来HDFS1,大家都很兴奋,因为它解决了一个海量数据如何存储的问题。

HDFS1用的是主从式架构,主节点只有一个叫:Namenode,从节点有多个叫:DataNode。

我们往HDFS上上传一个大文件,HDFS会自动把文件划分成为大小固定的数据块(HDFS1的时候,默认块的大小是64M,可以配置),然后这些数据块会分散到存储的不同的服务器上面,为了保证数据安全,HDFS1里默认每个数据块都有3个副本。

Namenode是HDFS的主节点,里面维护了文件系统的目录树,存储了文件系统的元数据信息,用户上传文件,下载文件等操作都必须跟NameNode进行交互,因为它存储了元数据信息,Namenode为了能快速响应用户的操作,启动的时候就把元数据信息加载到了内存里面。

DataNode是HDFS的从节点,干的活就很简单,就是存储block文件块。

01 / HDFS1架构缺陷缺陷一:单点故障问题(高可用)我们很清楚的看到,HDFS1里面只有一个NameNode,那么也就是说如果这个Namenode 出问题以后,整个分布式文件系统就不能用了。

缺陷二:内存受限问题NameNode为了能快速响应用户的操作,把文件系统的元数据信息加载到了内存里面,那么如果一个集群里面存储的文件较多,产生的元数据量也很大,大到namenode所在的服务器撑不下去了,那么文件系统的寿命也就到尽头了,所以从这个角度说,之前的HDFS1的架构里Namenode有内存受限的问题。

我们大体能看得出来,在HDFS1架构设计中,DataNode是没有明显的问题的,主要的问题是在NameNode这儿。

3.HDFS2HDFS1明显感觉架构不太成熟,所以HDFS2就是对HDFS1的问题进行解决。

01 / 单点故障问题解决(高可用)大家先跟着我的思路走,现在我们要解决的是一个单点的问题,其实解决的思路很简单,因为之前是只有一个NameNode,所以有单点故障问题,那我们把设计成两个Namenode就可以了,如果其中一个namenode有问题,就切换到另外一个NameNode上。

所以现在我们想要实现的是:其中一个Namenode有问题,然后可以把服务切换到另外一个Namenode上。

如果是这样的话,首先需要解决一个问题:如何保证两个NameNode之间的元数据保持一致?因为只有这样才能保证服务切换以后还能正常干活。

保证两个NameNode之间元数据一致为了解决两个NameNode之间元数据一致的问题,引入了第三方的一个JournalNode集群。

JournalNode集群的特点:JournalNode守护进程是相对轻量级的,那么这些守护进程可与其它Hadoop守护进程,如NameNode,运行在相同的主机上。

由于元数据的改变必须写入大多数(一半以上)JNs,所以至少存在3个JournalNodes守护进程,这样系统能够容忍单个Journal Node故障。

当然也可以运行多于3个JournalNodes,但为了增加系统能够容忍的故障主机的数量,应该运行奇数个JNs。

当运行N个JNs时,系统最多可以接受(N-1)/2个主机故障并能继续正常运行,所以Jounal Node集群本身是没有单点故障问题的。

引入了Journal Node集群以后,Active状态的NameNode实时的往Journal Node集群写元数据,StandBy状态的NameNode实时从Journal Node集群同步元数据,这样就保证了两个NameNode之间的元数据是一致的。

两个NameNode自动切换目前虽然解决了单点故障的问题,但是目前假如Active NameNode出了问题,还需要我们人工的参与把Standby N ameNode切换成为Active NameNode,这个过程并不是自动化的,但是很明显这个过程我们需要自动化,接下来我们看HDFS2是如何解决自动切换问题的。

为了解决自动切换问题,HDFS2引入了ZooKeeper集群和ZKFC进程。

ZKFC是DFSZKFailoverController的简称,这个服务跟NameNode的服务安装在同一台服务器上,主要的作用就是监控NameNode健康状态并向ZooKeeper注册NameNode,如果Active的NameNode挂掉后,ZKFC为StandBy的NameNode竞争锁(分布式锁),获得ZKFC锁的NameNode变为active,所以引入了ZooKeeper集群和ZKFC进程后就解决了NameNode自动切换的问题。

02 / 内存受限问题解决前面我们虽然解决了高可用的问题,但是如果NameNode的元数据量很大,大到当前NameNode所在的服务器存不下,这个时候集群就不可用了,换句话说就是NameNode的扩展性有问题。

为了解决这个问题,HDFS2引入了联邦的机制。

如上图所示这个是一个完整的集群,由多个namenode构成,namenode1和namenode2构成一套namenode,我们取名叫nn1,这两个namenode之间是高可用关系,管理的元数据是一模一样的;namenode3和namenode4构成一套namenode,假设我们取名叫nn2,这两个namenode之间也是高可用关系,管理的元数据也是一模一样的,但是nn1和nn2管理的元数据是不一样的,他们分别只是管理了整个集群元数据的一部分,引入了联邦机制以后,如果后面元数据又存不了,那继续扩nn3,nn4...就可以了。

所以这个时候NameNode就在存储元数据方面提升了可扩展性,解决了内存受限的问题。

联邦这个名字是国外翻译过来的,英文名是Federation,之所以叫联邦的管理方式是因为Hadoop的作者是Doug cutting,在美国上学,美国是联邦制的国家,作者从国家管理的方式上联想到元数据的管理方式,其实这个跟我们国家的管理方式也有点类似,就好比我们整个国家是一个完整的集群,但是如果所有的元数据都由北京来管理的话,内存肯定不够,所以中国分了34个省级行政区域,各个区域管理自己的元数据,这行就解决了单服务器内存受限的问题。

HDFS2引入了联邦机制以后,我们用户的使用方式不发生改变,联邦机制对于用户是透明的,因为我们会在上游做一层映射,HDFS2的不同目录的元数据就自动映射到不同的namenode 上。

03 / HDFS2的架构缺陷缺陷一:高可用只能有两个namenode为了解决单点故障问题,HDFS2设计了两个namenode,一个是active,另外一个是standby,但是这样的话,如果刚好两个NameNode连续出问题了,这个时候集群照样还是不可用,所以从这这个角度讲,NameNode的可扩展性还是有待提高的。

注意:这个时候不要跟联邦那儿混淆,联邦那儿是可以有无数个namenode的,咱们这儿说的只能支持两个namenode指的是是高可用方案。

缺陷二:副本为3,存储浪费了200%其实这个问题HDFS1的时候就存在,而且这个问题跟NameNode的设计没关系,主要是DataNode这儿的问题,DataNode为了保证数据安全,默认一个block都会有3个副本,这样存储就会浪费了200%。

4.HDFS3其实到了HDFS2,HDFS就已经比较成熟稳定了,但是HDFS3还是精益求精,再从架构设计上重新设计了一下。

01 / 高可用之解决只能有两个namenode当时在设计HDFS2的时候只是使用了两个NameNode去解决高可用问题,那这样的话,集群里就只有一个NameNode是Standby状态,这个时候假设同时两个NameNode都有问题的话,集群还是存在不可用的风险,所以在设计HDFS3的时候,使其可支持配置多个NameNode用来支持高可用,这样的话就保证了集群的稳定性。

02 / 解决存储浪费问题HDFS3之前的存储文件的方案是将一个文件切分成多个Block进行存储,通常一个Block 64MB或者128MB,每个Block有多个副本(replica),每个副本作为一个整体存储在一个DataNode上,这种方法在增加可用性的同时也增加了存储成本。

ErasureCode通过将M个数据block进行编码(Reed-Solomon,LRC),生成K个校验(parity)block, 这M+K个block 组成一个block group,可以同时容忍K个block失败,任何K个block都可以由其他M个block算出来. overhead是K/M。

以M=6,K=3为例,使用EC之前,假设block副本数为3,那么6个block一共18个副本,overhead是200%,使用EC后,9个block,每个block只需一个副本,一共9个副本,其中6个数据副本,3个校验副本,overhead是3/6=50%。

在存储系统中,纠删码技术主要是通过利用纠删码算法将原始的数据进行编码得到校验,并将数据和校验一并存储起来,以达到容错的目的。

其基本思想是将k块原始的数据元素通过一定的编码计算,得到m块校验元素。

对于这k+m块元素,当其中任意的m块元素出错(包括数据和校验出错),均可以通过对应的重构算法恢复出原来的k块数据。

相关主题