浅析SecondaryNameNode,CheckpointNode,BackupNode,HA,Federation

一、SecondaryNameNode

Secondary NameNode不是NameNode的备份。它的作用是:定期合并fsimage与edits文件,并推送给NameNode,以及辅助恢复NameNode。

SNN的作用现在(Hadoop2.x)可以被两个节点替换CheckpointNode和BackupNode。

CheckpointNode可以理解为与Secondary NameNode的作用一致。

BackupNode:NameNode的完全备份。

配置文件:core-site.xml

fs.checkpoint.period、fs.checkpoint,size、

fs.checkpoint.dir、fs.checkpoint.edits.dir

Secondary NameNode定期合并流程,如下图所示。

[[email protected] current]# more VERSION
#Mon May 04 15:06:37 CST 2015
namespaceID=1967523381
clusterID=CID-bdf70043-346a-439b-87de-cee402d13fa4
cTime=0
storageType=NAME_NODE
blockpoolID=BP-510666760-172.23.253.20-1430213820023
layoutVersion=-47

VERSION文件保存了HDFS的版本号

layoutVersion是一个负整数,保存了HDFS的持续化在硬盘上的数据

结构的格式版本号

namespaceID是文件系统的唯一标识符,在文件系统初次格式化时生成的。

cTime此处为0

storageType表示此文件夹中保存的是元数据节点的数据结构

NameNode进程死了,并且存放NameNode元数据信息目录下的数据丢失了,怎么恢复?

1、删除SNN存放数据目录下in_use.lock文件

2、执行恢复命令hadoop namenode -importCheckpoint

3、启动namenode hadoop-daemon.sh start namenode

4、进行校验检查根目录是否健康hadoop fsck /

5、查看数据 hadoop fs -lsr /

至此,NameNode元数据恢复成功。

二、CheckpointNode

CheckpointNode和SecondaryNameNode的作用以及配置完全相同。

启动命令:hdfs namenode -checkpoint

配置文件:core-site.xml

fs.checkpoint.period、fs.checkpoint,size、

fs.checkpoint.dir、fs.checkpoint.edits.dir

三、BackupNode

提供了一个真正意义上的备用节点。

BackupNode在内存中维护了一份从NameNode同步过来的fsimage,同时它还从namenode接收edits文件的日志流,并把它们持久化硬盘。

BackupNode在内存中维护与NameNode一样的Matadata数据。

启动命令:hdfs namenode -backup

配置文件:hdfs-site.xml

dfs.backup.address、dfs.backup.http.address

[[email protected] current]# hdfs namenode --help
Usage: java NameNode [-backup] | [-checkpoint] | [-format [-clusterid cid ] [-force] [-nonInteractive] ] | [-upgrade] | [-rollback] | [-finalize] | [-importCheckpoint] | [-initializeSharedEdits] | bootstrapStandby] | [-recover [ -force ] ]

四、HDFS HA的自动failover

HDFS的HA,指的是在一个集群中存在两个NameNode, 分别运行在独立的物理节点上。在任何时间点, 只有一个NameNodes是处于Active状态,另一种是在Standby状态。

Active NameNode负责所有的客户端的操作,而Standby NameNode用来同步Active NameNode的状态信息,以提供快速的故障恢复能力。

为了保证Active NN与Standby NN节点状态同步,即元数据保持一致。除了DataNode需要向两个NN发送block位置信息外,还构建了一组独立的守护进程”JournalNodes” ,用来同步FsEdits信息。当Active NN执行任何有关命名空间的修改,它需要持久化到一半以上的JournalNodes上。而Standby NN负责观察JNs的变化,读取从Active NN发送过来的FsEdits信息,并更新其内部的命名空间。

一旦Active NN遇到错误, Standby NN需要保证从JNs中读出了全部的

FsEdits, 然后切换成Active状态。

在这个图里,我们可以看出HA的大致架构,其设计上的考虑包括:

利用共享存储来在两个NN间同步edits信息。

以前的HDFS是share nothing but NN,现在NN又share storage,这样其实是转移了单点故障的位置,但中高端的存储设备内部都有各种RAID以及冗余硬件包括电源以及网卡等,比服务器的可靠性还是略有提高。

通过NN内部每次元数据变动后的flush操作,加上NFS的close-to-open,数据的一致性得到了保证。社区现在也试图把元数据存储放到BookKeeper上,以去除对共享存储的依赖, Cloudera也提供了Quorum Journal Manager(QJM)的实现和代码。

DataNode同时向两个NN汇报块信息。这是让Standby NN保持集群最新状态的必需步骤。

用于监视和控制NN进程的FailoverController进程,显然,我们不能在NN进程内进行心跳等信息同步,最简单的原因,一次FullGC就可以让NN挂起

十几分钟,所以,必须要有一个独立的短小精悍的watchdog来专门负责监控。这也是一个松耦合的设计,便于扩展或更改,目前版本里是用ZooKeeper(以下简称ZK)来做同步锁,但用户可以方便的把这个ZooKeeper FailoverController(以下简称ZKFC)替换为其他的HA方案或leader选举

方案。

隔离(Fencing),防止脑裂,就是保证在任何时候只有一个主NN,包括三个方面:

共享存储fencing,确保只有一个NN可以写入edits。

客户端fencing,确保只有一个NN可以响应客户端的请求。

DataNode fencing,确保只有一个NN可以向DN下发命令,譬如删除块,复制块等等。

五、HDFS2的Federation

HDFS Federation设计可解决单一命名空间存在的以下几个问题:

1 、HDFS集群扩展性。多个NameNode分管一部分目录,使得一个集群可以扩展到更多节点,不再像Hadoop1.x中那样由于内存的限制制约文件存储数目。

2、性能更高效。多个NameNode管理不同的数据,且同时对外提供服务,将为用户提供更高的读写吞吐率。

3、良好的隔离性。用户可根据需要将不同业务数据交由不同NameNode管理,这样不同业务之间影响很小。

由上图,我们可以看到多个NN共用一个集群里DN上的存储资源,每个NN都可以单独对外提供服务每个NN都会定义一个存储池,有单独的id,每个DN都为所有存储池提供存储。

DN会按照存储池id向其对应的NN汇报块信息,同时, DN会向所有NN汇报本地存储可用资源情况

如果需要在客户端方便的访问若干个NN上的资源,可以使用客户端挂载表,把不同的目录映射到不同的NN,但NN上必须存在相应的目录。

这样设计的好处有:

改动最小,向前兼容。

现有的NN无需任何配置改动。

如果现有的客户端只连某台NN的话,代码和配置也无需改动。

分离命名空间管理和块存储管理。

提供良好扩展性的同时允许其他文件系统或应用直接使用块存储池。

统一的块存储管理保证了资源利用率。

可以只通过防火墙配置达到一定的文件访问隔离,而无需使用复杂的Kerberos认证

客户端挂载表通过路径自动对应NN使Federation的配置改动对应用透明。

时间: 2024-10-06 06:45:17

浅析SecondaryNameNode,CheckpointNode,BackupNode,HA,Federation的相关文章

Hadoop2:HA+Federation+YARN的集群部署

1.机器准备,职责划分如下: 机器名称 IP地址 NameNode DataNode JournalNode ZooKeeper ZKFC HA-Cluster1 HA-Cluster2 Resource Manager Node Manager hadoop01 192.168.147.101 Active     √ √ nn1   √   hadoop02 192.168.147.102 Standy √ √ √ √ nn2     √ hadoop03 192.168.147.103 A

HDFS HA系列实验之四:HA+Federation

接触了Spark也快有半年了,版本从0.8.0到现在的1.0.0SNAPSHOT,从头到尾被spark这个优秀的框架深深吸引,也为scala的优雅所折服.4.19日"2014 中国Spark技术峰会"召开,可以看出随着Spark技术的完善,越来越多的企业已经开始使用或开始关注Spark的发展了.回顾学习过程,觉得很有必要整理一份学习路线,对所学的内容加以沉淀,同时也为同行作为参考. 因为Spark1.0.0即将发布,增加了很多特性,所以决定修改以前的博文,全都采用Spark1.0.0,

hadoop2的automatic HA+Federation+Yarn配置的教程

前言 hadoop是分布式系统,运行在linux之上,配置起来相对复杂.对于hadoop1,很多同学就因为不能搭建正确的运行环境,导致学习兴趣锐减.不过,我有免费的学习视频下载,请点击这里. hadoop2出来后,解决了hadoop1的几个固有缺陷,比如单点故障.资源利用率低.支持作业类型少等问题,结构发生了很大变化,是hadoop未来使用的一个趋势.当然,配置也更加复杂,网上也没有一篇详细的教程来知道大家可以轻轻松松搭建起这个环境的.我应该算是第一个吧. hadoop2体系结构 要想理解本节内

Hadoop2.6分布式 automatic HA+Federation+Yarn教程

一.前言 与Hadoop1.x相比,Hadoop2.x中的NameNode不再是只有一个了,可以有多个(目前只支持2个).每一个都有相同的职能. 这两个NameNode的地位如何哪? 答:一个是active状态的,一个是standby状态的.当集群运行时,只有active状态的NameNode是正常工作的,standby状态的NameNode是处于待命状态的,时刻同步active状态NameNode的数据.一旦active状态的NameNode不能工作,通过手工或者自动切换,standby状态的

hadoop2的automatic HA+Federation+Yarn的教程

本文引自吴超博客:http://www.superwu.cn/2014/02/12/1094/ hadoop是分布式系统,运行在linux之上,配置起来相对复杂. hadoop2出来后,解决了hadoop1的几个固有缺陷,比如单点故障.资源利用率低.支持作业类型少等问题,结构发生了很大变化,是hadoop未来使用的一个趋势.当然,配置也更加复杂,网上也没有一篇详细的教程来知道大家可以轻轻松松搭建起这个环境的.本文绝对是国内互联网第一篇详细讲述这些配置的文章. hadoop2体系结构 要想理解本节

CentOS7+Hadoop2.7.2(HA高可用+Federation联邦)+Hive1.2.1+Spark2.1.0 完全分布式集群安装

1       VM网络配置... 3 2       CentOS配置... 5 2.1             下载地址... 5 2.2             激活网卡... 5 2.3             SecureCRT. 5 2.4             修改主机名... 6 2.5             yum代理上网... 7 2.6             安装ifconfig. 8 2.7             wget安装与代理... 8 2.8       

HDFS Federation和NameNode HA的搭建

1. HDFS Federation产生背景 在Hadoop 1.0中,HDFS的单NameNode设计带来诸多问题,包括单点故障.内存受限制约集群扩展性和缺乏隔离机制(不同业务使用同一个NameNode导致业务相互影响)等,为了解决这些问题,Hadoop 2.0引入了基于共享存储的HA解决方案和HDFS Federation,这里重点介绍HDFS Federation. HDFS Federation是指HDFS集群可同时存在多个NameNode,这些NameNode分别管理一部分数据,且共享

Hadoop生产环境搭建(含HA、Federation)

Hadoop生产环境搭建 1. 将安装包hadoop-2.x.x.tar.gz存放到某一目录下,并解压. 2. 修改解压后的目录中的文件夹etc/hadoop下的配置文件(若文件不存在,自己创建.) 包括hadoop-env.sh,mapred-site.xml,core-site.xml,hdfs-site.xml,yarn-site.xml 3. 格式化并启动HDFS 4. 启动YARN 以上整个过程与Hadoop单机Hadoop测试环境搭建基本一致,不同的是步骤2中配置文件设置内容以及步骤

Hadoop2.0NameNode HA和Federation实践

一.背景 天云趋势在2012年下半年开始为某大型国有银行的历史交易数据备份及查询提供基于Hadoop的技术解决方案,由于行业的特殊性,客户对服务的可 用性有着非常高的要求,而HDFS长久以来都被单点故障的问题所困扰,直到Apache Hadoop在2012年5月发布了2.0的alpha版本,其中MRv2还很不成熟,可HDFS的新功能已经基本可用,尤其是其中的的High Availability(以下简称HA)和Federation.Cloudera也于7月制作了CDH4.0.1,包含了Hadoo