目的：

本指南提供了HDFS HA 特征，以及通过 QJM如何配置和管理 一个HA的HDF 集群的一个概览。本指南嘉定读者已经有了一个对HDFS 集群中 基本组件和节点类型的基本理解。具体的可以参考 HDFS 架构指南。

注意：使用QJM 或者传统的共享存储。

本指南讨论了如何配置以及使用HDFS HA 通过使用QJM在Active 和Standbyt NameNodes 之间 共享edti logs 。通过NFS配置和使用HA的晴参考另一篇指南。

背景

在Hadoop 2.0.0 之前，在HDFS集群中，NameNode是一个单点故障（SPOF）。每个集群只有一个NomeNode, 如果这个机器或者进程不可用，整个集群都会不可用。除非这个机器重启或者在一个其他机器上重启。
这会在以下两种方式下影响HDFS 集群的整体可用性。

• 计划外的事件， 比如机器宕机。这个时候只能通过运维人员重启NameNode 集群才能恢复。
• 计划内的运维， 比如NameNode软件和硬件的升级会导致一段时间集群的不可以用。
  HDFS 的HA 特征 通过提供一个在同一个集群内运行两个冗余的NameNode 的方法来解决上面的问题。其中一个Active 一个是 Standby.这样当一台机器宕机的时候，将会快速恢复到一个新的NanmeNode。或者当进行计划内的维护的时候，优雅的切换。

架构

一个典型的HA的集群，两个分开的NameNode.在任何时刻，有且仅有一个NameNode 是Active状态，并且另一个是Standby状态.Active的节点负责集群内所有client的操作，而Standby 节点则简单扮演一个slave ，保持足够的同步状态用来在必要的时候提供快速的故障恢复。
为了使得StandBy 节点能能够和Active节点保持状态的同步，两个节点通过一组 独立的 JournalNodes(JNs) 通讯。当Active节点上的任何namespace的变更发生，它就会向JNs中的大多数记录一条这个变更的日志。Standby 节点可以读JNs上的edits 日志，并且持续的监控edits long的变化。一旦监测到edits，它就会将edits 应用到自己的namespace中。在故障恢复的时候, Standby 在提升自己成为Active状态之前，需要保证她已经读到了所有来自Journal 节点的edits。这就保证了在故障切换发生前namespace的状态已经完全同步了。
为了提供一个快速的故障切换，Standby节点必须有集群中所有block的位置的实时信息，这很必要。为了达到这个功能，DataNode 需要配置两个NameNode的位置，并且发送block的位置信息和心跳给两个NameNode.
对于一个HA的集群正确操作来说，一个时刻只有一个节点处于Active状态是至关重要的。否则的话，namespace的状态将会在两者之间快速变化，这将会导致数据丢失和其他不正确的结果。为了保证这个属性以及防止 所谓的脑裂的场景，Journal节点在一个时刻只会允许一个NameNode节点写入。在故障切换的时候，即将成为Active的NameNode将会负责写入JournalNode角色,这将会有效的组织其他的NameNode 继续成为Active状态，使得新的Active节点能够安全的处理故障切换。

硬件资源

为了部署一个HA的集群，你需要如下的准备

• NameNode 机器 运行 Active和Standby NameNode机器必须要有相同的硬件，非ha的集群也需要相同的硬件。
• JournalNode 机器 运行Journal节点的机器。JournalNode的守护进程是相对轻量的，因此可以很合适的有其他Hadoop的守护进程搭配运行在机器上，比如 NameNode,JobTracker,和Yarn ResourceManager .注意 ：至少需要3个JounalNode 的节点，因为edit的log 的修改必须写入到JNs中的大部分。这样单台故障对系统无影响。你也可以运行多于3个以上的JournalNode,但是为了增加系统可以忍受的失败数，你可以运行奇数个 JNs(比如，3，5，7) 注意 ，当运行N个JournalNode时候，系统能够承受 最多 （N-1）/2个失败，并持续保持正常运作。
  注意，在HA的集群中，Standby节点也运行着namespace 状态的checkpoint。因此并不需要运行一个Secondary NameNode,CheckPointNode, 或者BackupNode.实际上，这样做会出错。这对于那些想从非HA的集群配置成HA集群的人来说，可以重复使用那些用于Secondary Namenode 硬件。