一探究竟:Namenode、SecondaryNamenode、NamenodeHA关系

NameNode与Secondary NameNode

很多人都认为,Secondary NameNode是NameNode的备份,是为了防止NameNode的单点失败的,其实并不是在这样。文章Secondary Namenode - What it really do? (需FQ)写的很通俗易懂,现将其翻译如下:

Secondary NameNode:它究竟有什么作用?

在Hadoop中,有一些命名不好的模块,Secondary NameNode是其中之一。从它的名字上看,它给人的感觉就像是NameNode的备份。但它实际上却不是。

很多Hadoop的初学者都很疑惑,Secondary NameNode究竟是做什么的,而且它为什么会出现在HDFS中。

因此,在这篇文章中,我想要解释下Secondary NameNode在HDFS中所扮演的角色。

从它的名字来看,你可能认为它跟NameNode有点关系。没错,你猜对了。因此在我们深入了解Secondary NameNode之前,我们先来看看NameNode是做什么的。

NameNode

NameNode主要是用来保存HDFS的元数据信息,比如命名空间信息,块信息等。当它运行的时候,这些信息是存在内存中的。但是这些信息也可以持久化到磁盘上。

一探究竟:Namenode、SecondaryNamenode、NamenodeHA关系

上面的这张图片展示了NameNode怎么把元数据保存到磁盘上的。这里有两个不同的文件:

fsimage - 它是在NameNode启动时对整个文件系统的快照
edit logs - 它是在NameNode启动后,对文件系统的改动序列
只有在NameNode重启时,edit logs才会合并到fsimage文件中,从而得到一个文件系统的最新快照

但是在生产集群中NameNode是很少重启的,这也意味着当NameNode运行了很长时间后,edit logs文件会变得很大。

在这种情况下就会出现下面一些问题:

edit logs文件会变的很大,怎么去管理这个文件是一个挑战。
NameNode的重启会花费很长时间,因为有很多改动[笔者注:在edit logs中]要合并到fsimage文件上。
如果NameNode挂掉了,那我们就丢失了很多改动因为此时的fsimage文件非常旧。
因此为了克服这个问题,我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件,这样也会减小在NameNode上的压力。

这跟Windows的恢复点是非常像的,Windows的恢复点机制允许我们对OS进行快照,这样当系统发生问题时,我们能够回滚到最新的一次恢复点上。

现在我们明白了NameNode的功能和所面临的挑战 - 保持文件系统最新的元数据。那么,这些跟Secondary NameNode又有什么关系呢?

Secondary NameNode

SecondaryNameNode就是来帮助解决上述问题的,它的职责是合并NameNode的edit logs到fsimage文件中。

一探究竟:Namenode、SecondaryNamenode、NamenodeHA关系

上面的图片展示了Secondary NameNode是怎么工作的。

首先,它定时到NameNode去获取edit logs,并更新到fsimage上。[笔者注:Secondary NameNode自己的fsimage]
一旦它有了新的fsimage文件,它将其拷贝回NameNode中。
NameNode在下次重启时会使用这个新的fsimage文件,从而减少重启的时间。
Secondary NameNode的整个目的是在HDFS中提供一个检查点。它只是NameNode的一个助手节点。这也是它在社区内被认为是检查点节点的原因。

现在,我们明白了Secondary NameNode所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的备份。

所以从现在起,让我们养成一个习惯,称呼它为检查点节点吧。

这篇文章基本上已经清楚的介绍了Secondary NameNode的工作以及为什么要这么做。

最后补充一点细节,是关于NameNode是什么时候将改动写到edit logs中的?

这个操作实际上是由DataNode的写操作触发的,当我们往DataNode写文件时,DataNode会跟NameNode通信,告诉NameNode什么文件的第几个block放在它那里,NameNode这个时候会将这些元数据信息写到edit logs文件中。

NameNode HA与Secondary NameNode

在hadoop2.0之前,namenode只有一个,存在单点问题(虽然hadoop1.0有secondarynamenode,checkpointnode,buckcupnode这些,但是单点问题依然存在),在hadoop2.0引入了HA机制。

hadoop2.0的HA机制官方介绍了有2种方式,一种是NFS(Network File System)方式,另外一种是QJM(Quorum Journal Manager)方式。

2 基本原理

hadoop2.0的HA 机制有两个namenode,一个是active namenode,状态是active;另外一个是standby namenode,状态是standby。

两者的状态是可以切换的,但不能同时两个都是active状态,最多只有1个是active状态。只有active namenode提供对外的服务,standby namenode是不对外服务的。

active namenode和standby namenode之间通过NFS或者JN(journalnode,QJM方式)来同步数据。

active namenode会把最近的操作记录写到本地的一个edits文件中(edits file),并传输到NFS或者JN中。

standby namenode定期的检查,从NFS或者JN把最近的edit文件读过来,然后把edits文件和fsimage文件合并成一个新的fsimage,合并完成之后会通知active namenode获取这个新fsimage。

active namenode获得这个新的fsimage文件之后,替换原来旧的fsimage文件。

这样,保持了active namenode和standby namenode的数据的实时同步,standby namenode可以随时切换成active namenode(譬如active namenode挂了)。

而且还有一个原来hadoop1.0的secondarynamenode,checkpointnode,buckcupnode的功能:合并edits文件和fsimage文件,使fsimage文件一直保持更新。

所以启动了hadoop2.0的HA机制之后,secondarynamenode,checkpointnode,buckcupnode这些都不需要了。

3 NFS方式

NFS作为active namenode和standby namenode之间数据共享的存储。active namenode会把最近的edits文件写到NFS,而standby namenode从NFS中把数据读过来。

这个方式的缺点是,如果active namenode或者standby namenode有一个和NFS之间网络有问题,则会造成他们之前数据的同步出问题。

4 QJM(Quorum Journal Manager )方式

QJM的方式可以解决上述NFS容错机制不足的问题。active namenode和standby namenode之间是通过一组journalnode(数量是奇数,可以是3,5,7...,2n+1)来共享数据。

active namenode把最近的edits文件写到2n+1个journalnode上,只要有n+1个写入成功就认为这次写入操作成功了,然后standby namenode就可以从journalnode上读取了。

可以看到,QJM方式有容错的机制,可以容忍n个journalnode的失败。

5 主备节点的切换

active namenode和standby namenode可以随时切换。当active namenode挂掉后,也可以把standby namenode切换成active状态,成为active namenode。

可以人工切换和自动切换。人工切换是通过执行HA管理的命令来改变namenode的状态,从standby到active,或者从active到standby。

自动切换则在active namenode挂掉的时候,standby namenode自动切换成active状态,取代原来的active
namenode成为新的active namenode,HDFS继续正常工作。

主备节点的自动切换需要配置zookeeper。active namenode和standby namenode把他们的状态实时记录到zookeeper中,zookeeper监视他们的状态变化。

当zookeeper发现active namenode挂掉后,会自动把standby namenode切换成active namenode。

6 实战tips

  • QJM方式有明显的优点,一是本身就有fencing的功能,二是通过多个journal节点增强了系统的健壮性,所以建议在生成环境中采用QJM的方式。
  • journalnode消耗的资源很少,不需要额外的机器专门来启动journalnode,可以从hadoop集群中选几台机器同时作为journalnode。
上一篇:Step one : 熟悉Unix/Linux Shell 常见命令行 (三)


下一篇:DOM 操作技术【JavaScript高级程序设计第三版】