在2.0版本中，Namenode可以部署两个：Active NN和Standly NN。在同一时间永远都是只有一个NN对外提供服务的，即Active NN。Active NN并不永远都是一个固定的状态，当Active NN出现故障后，Standly NN就会切换成Active NN提供服务，而之前的Active NN就会变成Standly NN停止位集群服务。Standly NN负责同步Active NN中的元数据信息，也会接收Active NN的块报告，所有的DN上的Block Pool块报告的信息会同时发送到Active NN和Standly NN，这样他们的信息就能够达到同步。Edits日志只有Active状态的NameNode节点可以做写操作；两个NameNode都可以读取Edits；

需要做HDFS HA的话，首先需要保证namenode中的fsimage和edits文件一致，需要产生的时候（格式化的时候）就保持一致。

1. fsImage保证一致做法：需要在一台NameNode上生成后，拷贝到另外的NameNode上。

2. 如何保证edits文件在所有NameNode一致？因为edits在HDFS文件发生变化时，edits文件就会发生变化，故需要借助第三方处理。

利用NFS,是FreeBSD支持的文件系统中的一种，它允许网络中的计算机之间通过TCP/IP网络共享资源，但是此种方式并不是真正意义上的高可用，在资源共享主机宕机后，就不可服务了。

采用QJM（Quorum Journal Manager）的方式进行高可用：所有的edits文件交由JN管理，即使NameNode挂了也没事。

在hadoop 1.x版本中,是没有ha的实现方式的,它只有可以看做是冷备份的Secondary NameNode来起到冷备份的作用的,当NameNode挂掉的时候,我们需要手工启动Secondary NameNode。

   那么为什么Secondary NameNode能够这样做，是因为SNN能够帮助NN做一些检查点的工作，会同步编辑日志和镜像文件，所以可以起到冷备的作用。在1.x版本中，当NN挂掉后，是没有办法立即启动起来继续为集群服务的。

    到了hadoop 2.x版本，基本都有了hdfs ha的功能（即热备功能），当主NN挂掉后，备NN会立即启动进而接管主NN为集群不间断的提供服务，保证集群对外是没有任何宕机的情况。

 接下来，我们根据上图来了解HA的方案是如何实现的？

 在2.0版本中，Namenode可以部署两个：Active NN和Standly NN。在同一时间永远都是只有一个NN对外提供服务的，即Active NN。Active NN并不永远都是一个固定的状态，当Active NN出现故障后，Standly NN就会切换成Active NN提供服务，而之前的Active NN就会变成Standly NN停止位集群服务。Standly NN负责同步Active NN中的元数据信息，也会接收Active NN的块报告，所有的DN上的Block Pool块报告的信息会同时发送到Active NN和Standly NN，这样他们的信息就能够达到同步。Edits日志只有Active状态的NameNode节点可以做写操作；两个NameNode都可以读取Edits；

元数据共享存储方案：

在NN中，最关键的元数据（镜像文件和编辑日志）是需要共享才能使ANN和SNN实现数据的同步，元数据共享有几种方案： NFS（Linux自带的网络文件系统）、QJM（Quorum Journal Manager）、zookeeper。

QJM的详细介绍请参考：https://blog.csdn.net/czz1141979570/article/details/86735695 

zookeeper：

    上图中也显示使用了zookeeper的方案来实现HA的高可用，在zookeeper中会有两个FailoverControlller进程,一个负责监控ANN状态,另一个负责监控SNN状态，FailoverControlller从ANN和SNN中获取监控状态，并将监控状态通过Heartbeat保存在zookeeper中的znode中,会占用一个znode保存这些监控信息。

   当ANN出现故障后，zookeeper会通过FailoverControlller感知到,这时候FailoverControlller Standly会让SNN占用znode，使SNN切换成ANN。

  所有zookeeper是实现HA自动切换的关键组成部分。如果没有zk，我们就没有办法实现HA的故障自动切换。

基于ZK的自动切换模式配置

HA的自动故障转移依赖于ZooKeeper的以下功能：

1）故障检测：集群中的每个NameNode在ZooKeeper中维护了一个持久会话，如果机器崩溃，ZooKeeper中的会话将终止，ZooKeeper通知另一个NameNode需要触发故障转移。

2）现役NameNode选择：ZooKeeper提供了一个简单的机制用于唯一的选择一个节点为active状态。如果目前现役NameNode崩溃，另一个节点可能从ZooKeeper获得特殊的排外锁以表明它应该成为现役NameNode。

ZKFC是自动故障转移中的另一个新组件，是ZooKeeper的客户端，也监视和管理NameNode的状态。每个运行NameNode的主机也运行了一个ZKFC进程，ZKFC负责：

1）健康监测：ZKFC使用一个健康检查命令定期地ping与之在相同主机的NameNode，只要该NameNode及时地回复健康状态，ZKFC认为该节点是健康的。如果该节点崩溃，冻结或进入不健康状态，健康监测器标识该节点为非健康的。

2）ZooKeeper会话管理：当本地NameNode是健康的，ZKFC保持一个在ZooKeeper中打开的会话。如果本地NameNode处于active状态，ZKFC也保持一个特殊的znode锁，该锁使用了ZooKeeper对短暂节点的支持，如果会话终止，锁节点将自动删除。

3）基于ZooKeeper的选择：如果本地NameNode是健康的，且ZKFC发现没有其它的节点当前持有znode锁，它将为自己获取该锁。如果成功，则它已经赢得了选择，并负责运行故障转移进程以使它的本地NameNode为Active。故障转移进程与前面描述的手动故障转移相似，首先如果必要保护之前的现役NameNode，然后本地NameNode转换为Active状态。

————————————————

版权声明：本文为CSDN博主「流一恩典」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/czz1141979570/article/details/86738013

————————————————

版权声明：本文为CSDN博主「流一恩典」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/czz1141979570/article/details/86738013