在Hadoop 2.0.0之前，NameNode在HDFS集群中容易形成单点故障（SPOF）。每个群集都只有一个NameNode，如果该机器或进程变得不可用，整个群集将无法使用，直到NameNode重新启动或在单独的计算机上启动。
这在两个主要方面影响了HDFS集群的总体可用性：
1. 对于计划外事件（例如计算机崩溃），在操作员重新启动NameNode之前，群集将不可用。
2. 计划维护事件（如NameNode计算机上的软件或硬件升级）将导致群集停机。
HDFS高可用性功能通过提供在具有热备用的主动/被动配置中的同一群集中运行两个冗余NameNode的方法来解决上述问题。这允许在机器崩溃的情况下快速故障转移到新的NameNode，或者为了计划维护而优雅地管理员启动的故障转移。
High Availability With QJM 架构图
Active NameNode—Standby NameNode
在典型的HA群集中，有两台独立的计算机配置为NameNode。在任何时间点，其中一个NameNode处于活动状态，另一个处于待机状态。Active NameNode负责集群中的所有客户端操作，而Standby只是充当从属服务器，维持足够的状态以在必要时提供快速故障转移。而且在HA群集中，备用NameNode还会执行命名空间状态的检查点，因此无需在HA群集中运行Secondary NameNode，CheckpointNode或BackupNode。
Active NameNode—DataNode—Standby NameNode
为了提供快速故障转移，备用节点还必须具有关于群集中块的位置的最新信息。为了实现这一点，DataNode配置了两个NameNode的位置，并向两者发送块位置信息和心跳。
Active NameNode—JN—Standby NameNode
“JournalNodes”JN节点同步两台NameNode的日志信息，使两台节点同步。一般又多台机器，Active节点执行任何名称空间修改时，它会将修改记录持久地记录到大多数这些JN中，这里有过半机制，过半数的JN节点得到更新。JN的个数应该为3、5、7这种单数，系统最多允许（N-1）/ 2个JN节点故障。待机节点能够从JN读取编辑，并且不断观察它们对编辑日志的更改。当备用节点看到编辑时，它会将它们应用到自己的命名空间。如果发生故障转移，Standby将确保在将自身升级为Active状态之前已读取JounalNodes的所有编辑内容。这可确保在发生故障转移之前完全同步命名空间状态。
对于HA群集的正确操作而言，一次只有一个NameNode处于活动状态至关重要。因此JournalNodes只允许一个NameNode编辑。
配置细节
先做免秘钥（namenode可以控制其他节点，zkfc可以控制namenode），启动zookeeper，顺序启动JN，格式化namenode，格式化zookeeper
zookeeper
#解压zookeeper安装包，将bin目录添加到环境变量中。
#修改conf文件夹下的zoo.cfg文件，由zoo_sample.cfg复制得到
#添加
dataDir=/var/sxt/hadoop/zk
server.1=192.168.112.12:2888:3888
server.2=192.168.112.13:2888:3888
server.3=192.168.112.14:2888:3888
#保存退出
将本机的zookeeper序号存入zookeeper数据文件夹下的myid文件
[root@node02 conf]# mkdir -p /var/sxt/hadoop/zk
[root@node02 conf]# echo 1> /var/sxt/hadoop/zk/myid
#将编辑好的包scp到其他zookeeper节点中，并修改myid和环境变量
#启动zookeeper（先关闭防火墙）
#启动
zkServer.sh start
#查看状态
zkServer.sh status
#半数以上的zookeeper节点启动才会真正启动，且序号最大的先有一个成为leader 其他的是follow Node
Hadoop
修改hdfs-site.xml(先去掉第二名称节点的配置)
<configuration>
<!--副本数-->
<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<!--namenode的物理和逻辑映射-->
<property>
<name>dfs.nameservices</name>
<value>mycluster</value>
</property>
<property>
<name>dfs.ha.namenodes.mycluster</name>
<value>nn1,nn2</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>node01:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>node02:8020</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn1</name>
<value>node01:50070</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn2</name>
<value>node02:50070</value>
</property>
<!--JN节点配置-->
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://node01:8485;node02:8485;node03:8485/mycluster</value>
</property>
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/var/sxt/hadoop/ha/jn</value>
</property>
<!--故障切换的实现和代理-->
<property>
<name>dfs.client.failover.proxy.provider.mycluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/root/.ssh/id_dsa</value>
</property>
<!--故障转移开关-->
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
</configuration>
修改 core-site.xml
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/var/sxt/hadoop/ha</value>
</property>
<property>
<name>ha.zookeeper.quorum</name>
<value>node02:2181,node03:2181,node04:2181</value>
</property>
</configuration>
将修改的两个配置文件scp给其他节点
[root@node01 hadoop]# scp core-site.xml hdfs-site.xml node02:`pwd`
core-site.xml 100% 1089 630.3KB/s 00:00
hdfs-site.xml 100% 2187 2.0MB/s 00:00
[root@node01 hadoop]# scp core-site.xml hdfs-site.xml node03:`pwd`
core-site.xml 100% 1089 115.4KB/s 00:00
hdfs-site.xml 100% 2187 2.0MB/s 00:00
[root@node01 hadoop]# scp core-site.xml hdfs-site.xml node04:`pwd`
core-site.xml 100% 1089 215.7KB/s 00:00
hdfs-site.xml 100% 2187 997.5KB/s 00:00
启动
启动三台JN
[root@node01 .ssh]# hadoop-daemon.sh start journalnode
starting journalnode, logging to /opt/sxt/hadoop-2.6.5/logs/hadoop-root-journalnode-node01.out
#格式化一台想成为active节点的nameNode
[root@node01 .ssh]# hdfs namenode -format
#启动namenode
[root@node01 .ssh]# hadoop-daemon.sh start namenode
#在另一台启动Standby节点
hdfs namenode -bootstrapStandby
#格式化zookeeper
[root@node01 .ssh]# hdfs zkfc -formatZK
#启动某zookeeper
[root@node04 .ssh]# zkCli.sh
#启动nameNode
[root@node01 .ssh]# start-dfs.sh
Starting namenodes on [node01 node02]
node02: starting namenode, logging to /opt/sxt/hadoop-2.6.5/logs/hadoop-root-namenode-node02.out
node01: namenode running as process 94463. Stop it first.
node02: starting datanode, logging to /opt/sxt/hadoop-2.6.5/logs/hadoop-root-datanode-node02.out
node03: starting datanode, logging to /opt/sxt/hadoop-2.6.5/logs/hadoop-root-datanode-node03.out
node04: starting datanode, logging to /opt/sxt/hadoop-2.6.5/logs/hadoop-root-datanode-node04.out
Starting journal nodes [node01 node02 node03]
node01: journalnode running as process 94079. Stop it first.
node02: journalnode running as process 46571. Stop it first.
node03: journalnode running as process 45678. Stop it first.
Starting ZK Failover Controllers on NN hosts [node01 node02]
node01: starting zkfc, logging to /opt/sxt/hadoop-2.6.5/logs/hadoop-root-zkfc-node01.out
node02: starting zkfc, logging to /opt/sxt/hadoop-2.6.5/logs/hadoop-root-zkfc-node02.out