在Hadoop2.0之前，NameNode只有一个，存在单点问题（虽然Hadoop1.0有SecondaryNameNode，CheckPointNode，BackupNode这些，但是单点问题依然存在），在hadoop2.0引入了HA机制。Hadoop2.0的HA机制官方介绍了有2种方式，一种是NFS（Network File System）方式，另外一种是QJM（Quorum Journal Manager）方式。
一、SecondaryNameNode介绍
Secondary NameNode名字给人感觉像是NameNode的备份，实际不是。在深入了解Secondary NameNode之前，我们先来看看NameNode是做什么的。
NameNode
NameNode主要用来保存HDFS的元数据信息，比如命名空间信息，块信息等。当它运行的时候，这些信息在内存，也可以持久化到磁盘上。
上图展示了NameNode怎么把元数据保存到磁盘上。这里有两个不同的文件：
1、fsimage：它是在NameNode启动时，对整个文件系统的快照。
2、edit logs：它是在NameNode启动后，对文件系统的改动序列。
只有在NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在产品集群（比如Ambari或ClouderManager）中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。
在这种情况下就会出现下面一些问题：
1、edit logs文件会变的很大，怎么去管理这个文件是一个挑战。
2、NameNode的重启会花费很长时间，因为有很多改动（在edit logs中）要合并到fsimage文件上。
3、如果NameNode挂掉了，那我们就丢失了很多改动，因为此时的fsimage文件非常旧。
因此为了克服这个问题，我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小在NameNode上的压力。这跟Windows的恢复点是非常像的，Windows的恢复点机制允许我们对OS进行快照，这样当系统发生问题时，我们能够回滚到最新的一次恢复点上。
现在我们明白了NameNode的功能和所面临的挑战 ：保持文件系统最新的元数据。那么，这些跟Secondary NameNode又有什么关系呢？
Secondary NameNode
SecondaryNameNode就是来帮助解决上述问题的，它的职责是合并NameNode的edit logs到fsimage文件中。
上图展示了Secondary NameNode是怎么工作的：
1、首先，它定时到NameNode去获取edit logs，并更新到fsimage上。（Secondary NameNode自己的fsimage）
2、一旦它有了新的fsimage文件，它将其拷贝回NameNode中。
3、NameNode在下次重启时会使用这个新的fsimage文件，从而减少重启的时间。
Secondary NameNode的整个目的是在HDFS中提供一个检查点，它只是NameNode的一个助手节点，帮助NameNode更好的工作，这也是它在社区内被认为是检查点节点的原因。它不是要取代掉NameNode也不是NameNode的备份。所以从现在起，让我们养成一个习惯，称呼它为检查点节点吧。
二、HA（高可用）介绍
Hadoop2.0的HA 机制有两个NameNode，一个是Active状态，另一个是Standby状态。两者的状态可以切换，但同时最多只有1个是Active状态。只有Active 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，BackupNode的功能：合并edits文件和fsimage文件，使fsimage文件一直保持更新。所以启动了hadoop2.0的HA机制之后，SecondaryNameNode，CheckpointNode，BackupNode这些都不需要了。
数据同步方式：NFS与 QJM（Quorum Journal Manager ）
1、NFS
NFS作为Active NameNode和Standby NameNode之间数据共享的存储。Active NameNode会把最近的edits文件写到NFS，而Standby NameNode从NFS中把数据读过来。这个方式的缺点是，如果Active NameNode或者Standby Namenode有一个和NFS之间网络有问题，则会造成他们之前数据的同步出问题。
2、 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的失败。
Active和Standby两个NameNode之间的数据交互流程为：
1）NameNode在启动后，会先加载FSImage文件和共享目录上的EditLog Segment文件；
2）Standby NameNode会启动EditLogTailer线程和StandbyCheckpointer线程，正式进入Standby模式；
3）Active NameNode把EditLog提交到JournalNode集群；
4）Standby NameNode上的EditLogTailer 线程定时从JournalNode集群上同步EditLog；
5）Standby NameNode上的StandbyCheckpointer线程定时进行Checkpoint，并将Checkpoint之后的FSImage文件上传到Active NameNode。（在Hadoop 2.0中不再有Secondary NameNode这个角色了，StandbyCheckpointer线程的作用其实是为了替代 Hadoop 1.0版本中的Secondary NameNode的功能。）
QJM方式有明显的优点，一是本身就有fencing的功能，二是通过多个Journal节点增强了系统的健壮性，所以建议在生产环境中采用QJM的方式。JournalNode消耗的资源很少，不需要额外的机器专门来启动JournalNode，可以从Hadoop集群中选几台机器同时作为JournalNode。
主备NameNode切换
Active NameNode和Standby NameNode可以随时切换，可以人工和自动。人工切换是通过执行HA管理命令来改变NameNode的状态，从Standby到Active，或从Active到Standby。自动切换则在Active NameNode挂掉的时候，Standby NameNode自动切换成Active状态。
主备NameNode的自动切换需要配置Zookeeper。Active NameNode和Standby NameNode把他们的状态实时记录到Zookeeper中，Zookeeper监视他们的状态变化。当Zookeeper发现Active NameNode挂掉后，会自动把Standby NameNode切换成Active NameNode。
完毕。
原文链接：https://blog.csdn.net/weixin_45202377/article/details/93831839