一、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的配置改动对应用透明。