你好,游客 登录
背景:
阅读新闻

Hadoop的SecondaryNameNode、CheckpointNode、BackupNode、HA、Federation

[日期:2016-07-07] 来源:快乐成长  作者: [字体: ]

来源:http://www.mamicode.com/info-detail-670006.html

一、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定期合并流程,如下图所示。

Hadoop
[root@master 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的配置改动对应用透明。





收藏 推荐 打印 | 录入: | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款