HDFSの高可用性
連邦HDFS
システムファイルとデータ・ブロック内のマッピング情報がこのように大規模なクラスタファイル用に、メモリ内に維持名前ノードので、メモリはシステム規模のボトルネックになります。クラスタ内の名前ノードを追加することによって達成連邦HDFS（HDFS連盟）で導入されたのHadoop 2.xのバージョン、。
アーキテクチャの連盟：
原則
図NS-X 1 - は、独立して各名前ノード、名前空間名前空間メタデータとデータブロックを維持する単一ロール（名前空間の体積）からなる（ブロックプール）をプール。
2、データブロックプールは、その名前空間のファイルのすべてのデータブロックが含まれています。名前空間の体積独立名前ノードハング、または他の名前ノードに影響を与える場合であっても、相互に二十から二通信、
。3、データノードは、各クラスタに登録された名前ノードのデータノードの全ては、定期的にハートビートを送信し、すべての名前ノードを報告し、すべての名前ノードからコマンドを実行するために、共通のデータ記憶装置として使用されます
ネームスペースが削除されると、図4に示すように、対応するブロックのプールデータノードのすべてが削除されます。クラスタをアップグレードする場合、ベースユニットなどの各アップグレードnamespacevolume。
連邦HDFSの欠点
より多くの名前ノードの導入にもかかわらず、複数の名前空間を管理しますが、名前ノードがハングアップした場合、単一の名前ノードのために、失敗（シングルポイント障害）のさらに一つのポイントは、すべてのクライアントがファイルを操作することはできません。
連邦HDFSは、まだセカンダリ名前ノードを導入する必要があります。すべてのセカンダリ名前ノードまではサービスを提供するために、以下の条件を満たしています。
図1に示すように、画像のインポート名前空間メモリ
2、繰り返し編集ログ
図3に示すように、十分なデータノードのレポート・マッピング及び出口セキュア受信モードからブロック。
HAのためのNASを使用します
クラスタの可用性を保証するには、NASの共有ストレージを使用することができます。NASによって同期スタンバイ・メタデータ間の名前ノード。しかし、欠陥についてがあります。
1、ハードウェアがサポートしている必要がありますNAS
2、複雑な、完全な展開名前ノードのNFSマウントの展開は、単一のポイントとスプリットブレインNFSに対処する必要があり、エラーが発生しやすいです
3、同時に一つだけ名前ノードの書き込みデータで達成することができません
QJMの可用性
Hadoop2は、上記の問題を解決する一般奇数として構成、複数のJNからなる、QJM（定足数ジャーナルマネージャ）増加しました。QJMの名前ノードは、アクティブ・スタンバイの一組を有しています。アクティブな場合名前ノードの障害、スタンバイ名前ノードは、それを引き継ぐためにサービスを提供していきます。
これは次のように動作します：
図1は、ログの編集のセットによって共有名前ノード・ジャーナル・ノードとの間に、STANDBY名前ノード引き継ぎ必要は同期名前ノードのアクティブ状態への全体の編集ログを読み、新しいアクティブ名前ノード書き込み読み出し動作を継続します。
図2に示すように、マッピング情報は、データブロックの名前ノードのメモリに格納されているため、アクティブ・スタンバイ名前ノードの送信データブロックのセットを処理するために必要にデータノードレポート。
アクティブ名前ノードを監視するハートビートが無効であるを通じて3、クライアントは、名前ノードの失敗を処理するために、各名前ノード上のプロセスの実行をZKFC（飼育係フェイルオーバコントローラ）を使用し
図4に示すように、二次名前ノードの役割はスタンバイ名前ノードを置換し、スタンバイ名前ノードのチェックポイントは、アクティブ名前ノードのために提供され
5、QJMの実装では、飼育係は使用しません。しかし、選挙HAアクティブな名前ノードには、飼育係を使用。
図6に示すように、ある特別な状況（例えばスマン）の下で、フェイルオーバーが発生する可能性があり、アクティブnamenode--名前ノード2つのスプリットブレインことが喜んであります。（回避）をフェンシングすることで、この現象を回避するためにQJM。
プライマリおよび選挙メカニズムの名前ノード
Namenode(包括 YARN ResourceManager) 的主备选举是通过 ActiveStandbyElector 来完成的，ActiveStandbyElector 主要是利用了 Zookeeper 的写一致性、 临时节点和观察者机制
主备选举实现如下
1、 创建锁节点： 如果 ZKFC 检测到对应的 NameNode 的状态正常，那么表示这个 NameNode有资格参加Zookeeper 的主备选举。如果目前还没有进行过主备选举的话，那么相应的会发起一次主备选举，尝试在 Zookeeper 上创建一个路径为/hadoopha/${dfs.nameservices}/ActiveStandbyElectorLock 的临时结点， Zookeeper 的写一致性会保证最终只会有一次结点创建成功，那么创建成功的 NameNode 就会成为主 NameNode， 进而切换为 Active 状态。而创建失败的 NameNode 则切换为 Standby 状态。
2、 注册 Watcher 监听： 不管创建/hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock 节点是否成功， ZKFC 随后都会向 Zookeeper 注册一个 Watcher 来监听这个节点的状态变化事件， ActiveStandbyElector 主要关注这个节点的 NodeDeleted 事件。
3、 自动触发主备选举： 如果 Active NameNode 状态异常时， ZKFailoverController 会主动删除临时结点/hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock，这样处于 Standby 状态的NameNode 会收到这个结点的 NodeDeleted 事件。收到这个事件之后，会马上再次进入到建/hadoopha/${dfs.nameservices}/ActiveStandbyElectorLock 结点的流程，如果创建成功，这个本来处于 Standby 状态的 NameNode 就选举为主 NameNode 并随后开始切换为 Active 状态。
4、 当然，如果是 Active 状态的 NameNode 所在的机器整个宕掉的话，那么根据 Zookeeper 的临时节点特性， /hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock 节点会自动被删除，从而也会自动进行一次主备切换。
Namenode 脑裂
脑裂的原因
如果 Zookeeper 客户端机器负载过高或者正在进行 JVM Full GC，那么可能会导致 Zookeeper 客户端到服务端的心跳不能正常发出，一旦这个时间持续较长，超过了配置的 Zookeeper Session Timeout 参数的话， Zookeeper 服务端就会认为客户端的 session 已经过期从而将客户端的 Session 关闭。“假死”有可能引起分布式系统常说的双主或脑裂(brain-split) 现象。具体到本文所述的 NameNode，假设 NameNode1 当前为 Active 状态，NameNode2 当前为 Standby 状态。如果某一时刻 NameNode1 对应的 ZKFC 进程发生了“假死”现象，那么 Zookeeper 服务端会认为 NameNode1 挂掉了，根据前面的主备切换逻辑， NameNode2 会替代 NameNode1 进入 Active 状态。但是此时 NameNode1 可能仍然处于 Active 状态正常运行，即使随后 NameNode1 对应的 ZKFailoverController 因为负载下降或者 Full GC 结束而恢复了正常，感知到自己和 Zookeeper 的 Session 已经关闭，但是由于网络的延迟以及 CPU 线程调度的不确定性，仍然有可能会在接下来的一段时间窗口内NameNode1 认为自己还是处于 Active 状态。这样 NameNode1 和 NameNode2 都处于Active 状态，都可以对外提供服务。这种情况对于 NameNode 这类对数据一致性要求非常高的系统来说是灾难性的，数据会发生错乱且无法恢复。
规避脑裂
Hadoop 的 fencing 机制防止脑裂： 中文翻译为隔离，也就是想办法把旧的 Active NameNode
隔离起来，使它不能正常对外提供服务。 ZKFC 为了实现 fencing，会在成功创建 Zookeeper临时结点 hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock 从而成为 ActiveNameNode 之后，创建另外一个路径为/hadoop-ha/${dfs.nameservices}/ActiveBreadCrumb 的持久节点，这个节点里面也保存了 Active NameNode 的地址信息。 正常关闭 Active NameNode时， ActiveStandbyElectorLock 临时结点会自动删除，同时， ZKFC 会删除 ActiveBreadCrumb结点。但是如果在异常的状态下 Zookeeper Session 关闭 (比如前述的 Zookeeper 假死)，那么由于 ActiveBreadCrumb 是持久节点，会一直保留下来。后面当另一个 NameNode 选主成功之后，会注意到上一个 Active NameNode 遗留下来的这个节点，从而会对旧的 ActiveNameNode 进行 fencing
Hadoop 的两种 fencing 机制：
1) sshfence：通过 SSH 登录到目标机器上，执行命令将对应的进程杀死；
2) shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离；
只有在成功地执行完成 fencing 之后，选主成功的 ActiveStandbyElector 才会回调ZKFailoverController 的 becomeActive 方法将对应的 NameNode 转换为 Active 状态，开始
对外提供服务。
NameNode 共享存储实现
基于 QJM 的共享存储系统的总体架构： 基于 QJM 的共享存储系统主要用于保存EditLog，并不保存 FSImage 文件。 FSImage 文件还是在 NameNode 的本地磁盘上。
QJM共享存储的基本思想来自于 Paxos 算法，采用多个称为 JournalNode 的节点组成的JournalNode 集群来存储 EditLog。每个 JournalNode 保存同样的 EditLog 副本。
每次NameNode 写 EditLog 的时候，除了向本地磁盘写入 EditLog 之外，也会并行地向JournalNode 集群之中的每一个 JournalNode 发送写请求，只要大多数 (majority) 的
JournalNode 节点返回成功就认为向 JournalNode 集群写入 EditLog 成功。如果有 N 台JournalNode，那么根据大多数的原则，最多可以容忍有 (N-1)/2 台 JournalNode 节点挂掉。 基于 QJM 的共享存储系统的数据同步机制： Active NameNode 和 StandbyNameNode 使用JouranlNode 集群来进行数据同步的过程如图所示， Active NameNode 首先把 EditLog 提交到 JournalNode 集群，然后 Standby NameNode 再从 JournalNode 集群定时同步 EditLog
1) Active NameNode 提交 EditLog 到 JournalNode 集群的过程实际上是同步阻塞的，但是并不需要所有的 JournalNode 都调用成功，只要大多数 JournalNode 调用成功就可以了。如果无法形成大多数，那么就认为提交 EditLog 失败， NameNode 停止服务退出进程。
2) 当 NameNode 进入 Standby 状态之后，会启动一个线程， 定期从 JournalNode 集群上同步 EditLog，然后把同步的 EditLog 回放到内存之中的文件系统镜像上 (并不会同时把EditLog 写入到本地磁盘上)。