联邦
当说起联邦，很容易想起例如美国这样的国家，由州组成了一个联合统一的国家，每个州都有各自的宪法和法律，自己行使自己的权利。我们这里的联邦也是类似这种，有了这种机制HDFS集群中可以使用多个独立的NameNode来进行管理以满足HDFS命名空间的水平扩展，这些NameNode分别管理一部分数据，且共享所有的DataNode的存储资源。
通俗的讲就是，一个NameNode管理文件系统命名空间的一部分。例如NameNode1管理/usr目录下的所有文件，NameNode2管理/share目录下的所有文件。
在联邦的环境下，每一个NameNode都维护着一个命名空间卷，由命名空间的元数据和一个数据块池组成。数据块池包含该命名空间下所有文件的所有数据块。其中一个NameNode的失效也不会影响其他NameNode维护命名空间的可用性，且数据块池不再进行划分，因此集群中的DataNode需要注册到每个NameNode中去，并存储着来自多个数据块池中的数据块。
引入联邦机制可以帮我们解决单个NameNode存在的以下问题：
1）HDFS集群的可扩展性。元数据都存储在NameNode的内存中，因此很容易会受到NameNode内存上限的限制。因此使用多个NameNode来管理一部分NameSpace。
2）隔离性。一个程序可能会影响到其他运行的程序，如一个程序消耗过多资源导致其他程序无法顺利运行。在2.0中用户可根据需要将不同业务数据交互由不同的NameNode管理，这样不同业务之间影响很小。
3）性能更高效。多个NameNode同时对外提供服务，提供了更高的读写吞吐率。
高可用
在文件系统中备份NameNode的元数据和通过SecondaryNameNode创建监测点能防止数据丢失，但是依然无法避免文件系统的高可用，因为NameNode依旧存在单点失效的问题。
这种情况下，要想从一个失效的NameNode恢复，系统管理员需要启动一个拥有文件系统元数据副本的NameNode，并配置DataNode和客户端以便使用新的NameNode。但是这样系统的恢复时间就会太长，也会严重的影响到日常维护（重启NameNode会去加载Fsimage和edits，然后接受足够多的来自DataNode的数据块报告【安全模式下进行】，这个启动过程需要30分钟，甚至更长的时间）。
为了解决这一个问题，Hadoop2对HDFS高可用提供了支持，实现方式是配置了一对活动-备用(Active-StandBy) NameNode。当ActiveNameNode失效时，StandByNameNode就会接管它的任务并开始服务于来自客户端的请求，不会有任何明显中断。
1）NameNode之间需要通过高可用共享存储实现编辑日志的共享。当StandByNameNode接管工作之后，它将通读共享编辑日志直到文件的末尾，以实现ActiveNameNode的状态同步，并继续读取由ActiveNameNode写入的新条目。
2）DataNode需要同时向两个NameNode发送数据块处理报告，因为数据块的映射信息存储在NameNode中的内存中，并不是在磁盘中，因此需要两个NameNode发送数据块处理报告。
3）客户端需要使用特定的机制处理NameNode的失效问题，这一机制对用户来说是透明的。
4）SecondaryNameNode的角色被StandByNameNode所包含，StandByNameNode为ActiveNameNode命名空间周期性检查，因此就不需要运行SecondaryNameNode、CheckPointNode、BackupNode来实现容错机制。
5）在ActiveNameNode失效后，StandByNameNode能够快速实现任务接管，是因为最新的状态都存储在StandByNameNode的内存中：包括最新的编辑日志条目和最新的数据块映射信息。实际观察到失效时间略长一点，这是因为系统需要保守确定ActiveNameNode是否真的失效。
高可用的实现方式
群体日志管理器QJM——是为了提供一个高可用的编辑日志而设计的，被推荐用于大多数HDFS部署上。QJM以一组日志节点JN（Journal Node）的形式运行，每一次编辑必须写入日志节点JN上。默认是三个JN，所以系统能忍受其中任何一个的丢失。同一时间QJM只允许一个NameNode向编辑日志中写入数据，因此需要设置一个SHH规避命令杀死先前活动的NameNode(先前活动的NameNode仍有可能在处理和响应客户过时的读请求)。
在系统中有一个称为故障转移控制器（Failover Controller）的实体，管理着将ActiveNameNode转移为StandByNameNode的转换过程。有多种故障转移控制器，但默认的是一种使用了ZooKeeper来确保有且仅有一个ActiveNameNode。每一个NameNode都运行着这个轻量级的故障转移器，其工作就是监视宿主NameNode是否失效,如果失效时就进行故障的切换。
NameNode的主备切换主要是由ZKFailoverController、HealthMonitor和ActiveStandByElector这三个组件来协同实现。
ZkFailoverController:作为NameNode机器上一个独立的进程启动，启动的时候会创建HealMonitor和ActiveStandByElector两个内部组件。HealMonitor主要负责检测NameNode的健康状态，ActiveStandByElector主要负责完成自动的主备选举，内部封装了ZooKeeper的处理逻辑。
NameNode的切换流程：
① HealthMonitor会定时对NameNode的健康状态进行检查。
② HealthMonitor如果检测到NameNode的健康状态发生变化，会回调ZkFailoverController进行相应的处理。
③ 如果ZkFailoverController判断需要进行主备切换，会首先调用ActiveStandByElector来进行自动的主备选举。
④ ActiveStandByElector与ZooKeeper进行交互完成自动的主备选举，选举完成后会通知ZkFailoverController当前NameNode成为ActiveNameNode或StandByNameNode。
⑤ ZkFailoverController将当前NameNode的状态改为Active或者Standby状态。