hdfs的高可用

最新推荐文章于 2024-05-28 22:39:53 发布

Se_cure

最新推荐文章于 2024-05-28 22:39:53 发布

阅读量607

点赞数

HDFS的架构体系

HDFS采用了主从模式(集中式管理)

主:

1. Namenode 只有一个,它存在一个缺陷(单点故障).

2. 它是记录集群情况和集群文件存储的元数据

3. 解决缺陷方式:

a. 高可用方式,制作一个副Namenode ,这个副Namenode可不是SecondNamenode,

b. 俩个namenode的功能一样在高可用中没有SecondNamenode.只有俩个namenode

c. 当一个namenode挂掉后另一个namenode上位

从:

1. Datanode 有N个

2. 它存储的是数据块(真实数据)

若名称节点(namenode)发生磁盘故障，如何挽救集群以及数据？

具体步骤:

        这个需要提前单独准备一台主机，专门用于部署辅助名称节点（2NN）。同时，name node(NN)和2NN的工作目录存储结构完全相同，这样一来，一旦NN服务器挂掉，可以从2NN的工作目录中将fsimage拷贝到NN的工作目录，以恢复元数据。注意：这种补救措施是事后的，不能保证内存中的元数据是最新的，因为2NN不能充当name node使用(只有name node才能及时更新元数据)。要想让HDFS集群持续对外提供服务，需要引入高可用(HA)配置，HDFS高可用的原理可继续阅读下文。

        实际上2NN是用来备份NN中的元数据，备份的内容包括NN服务器上最新的fsimage文件以及全部的日志文件（edit log），备份的过程叫做checkpoint(检查点)，过程概要：每隔一段时间，会由2NN将NN上积累的所有edits和一个最新的fsimage下载到2NN本地，并加载到内存进行merge（融合），再把融合后的文件上传给NN。具体checkpoint流程如下：

        在做检查点之前，先让NN上正在写的日志文件滚动一下，以供2NN拷贝。日志文件和fsimage的路径可从配置文件hdfs-site.xml的dfs.namenode.name.dir属性中找到，例如我的元数据存放的路径是/home/centos/namemeta

       <property>

              <name>dfs.namenode.name.dir</name>

              <value>/home/centos/namemeta</value>

       </property>

        下面有个子目录current存放所有的fsimage和edit log文件

        在HDFS集群首次做检查点时才会从NN下载最新的fsimage文件，以后做检查点时只需下载NN上的edit log(因为editlog比fsimage要小)。2NN有了fsimage和editlog，就可以在2NN服务器的内存中对二者进行融合，生成一个检查点文件fsimage.checkpoint，再把此文件上传到NN并重命名为fsimage文件

        NN根据刚才2NN传来的最新fsimage更新内存中的元数据

        默认是间隔30分钟做一次checkpoint

2 如何实现HDFS高可用

HDFS的高可用指的是HDFS持续对各类客户端提供读、写服务的能力，因为客户端对HDFS的读、写操作之前都要访问name node服务器，客户端只有从name node获取元数据之后才能继续进行读、写。所以HDFS的高可用的关键在于name node上的元数据持续可用。

前面说过2NN的功能是checkpoint，把NN的fsimage和edit log做定期融合，融合后传给NN, 以确保备份到的元数据是最新的，这一点类似于做了一个元数据的快照。Hadoop官方提供了一种quorum journal manager来实现高可用，那么就没必要配置2NN了。

在高可用配置下，edit log不再存放在名称节点，而是存放在一个共享存储的地方，这个共享存储由奇数个Journal Node组成，一般是3个节点(JN小集群)，每个JN专门用于存放来自NN的编辑日志，编辑日志由活跃状态的名称节点写入JN小集群。

那么要有2个NN，而且二者之中只能有一个NN处于活跃状态（active），另一个是待命状态（standby），只有active的NN节点才能对外提供读写HDFS服务，也只有active态的NN才能向JN写入编辑日志；standby状态的NN负责从JN小集群中拷贝数据到本地。另外，各个DATA NODE也要同时向两个名称节点报告状态(心跳信息、块信息)。

2个NN与3个JN构成的组保持通信，活跃的名称节点负责往JN集群写入编辑日志，待命的名称节点负责观察JN集群中的编辑日志,并且把日志拉取到待命节点，再加上两个NN各自的fsimage镜像文件，这样一来就能确保两个NN的元数据保持同步。一旦active NN不可用，提前配置的zookeeper会把standby节点自动变为active状态,继续对外提供读写服务。详见下文的 2.2如何通过自动容灾而不是手动容灾？