HDFS2.X提出的HA和Federation分别对应解决两个问题
解决单点故障
HDFS HA在主NameNode上解决且主NameNode出现故障时，快速切换到备份NameNode。
解决内存限制
HDFS Federation，多个NameNode水平扩展，每个NameNode管理部分目录，所有NameNode共享所有DataNode存储资源。
一、先说内存限制的问题，这里主要是说元数据太大带来的内存限制，所以我们的第一反应是增加内存。 但是机器的可追加内存有上限，所以做不好。 那么把机器放进去吗？ 不，因为一个HDFS群集只允许一个NameNode节点。 但是，通过添加机器的想法，想到了“添加集群”的想法。 也就是说，HDFS Federation的思想是多个HDFS集群共同分担资源。
二、关于单点故障问题，下图是官方网站所示的HDFS2.X中的HA的结构图。
使用两个NameNode。 分别是nnactive和NN Standby。 NameNode的主要功能是获取客户端读/写服务和存储元数据。 另一方面，Active同时具有这两种功能。 Stanby的唯一区别在于它不接受来自客户端的读写请求。 为了在Active发生故障时立即在Standby上交接工作，Standby要求与Active的状态(元数据)实时匹配，以便能够立即交接。 为了实现这个目的，该体系结构图中所示的策略如下。
1 .对于fsimage，此元数据文件是在格式化时生成的，但格式化结果在不同的计算机上总是不同的，因为格式化会根据当前系统环境初始化fsimage。 因此，用Active NN格式化，将后来生成的fsimage文件复制到Standby NN即可，此时两者的初始元数据一致。
2、元数据中的另一个重要文件edits用于实时合并并更新fsimage。 此文件必须从Active中提取并存储在JN群集中，由Active和Standby共享，以便在Active出现故障时，Standby找不到edits，并且无法进行最后一次(从上次更新到故障)更新(还有类似SecondaryNameNode的功能)
3、启动时，DataNode同时向Active和Standby报告Block的位置信息
因此，格式化活动后，整个过程将在磁盘上生成fsimage文件，并复制到Standby磁盘中。 两个NN在启动时从各自的磁盘将fsimage文件加载到内存中。 这是元数据第一阶段的一致。 每个DataNode启动后，同时向Active和Standby内存中的元数据报告Block的位置信息。 这是元数据第二阶段的一致； 然后，Active和Standby会在一段时间内同时用JN的edits文件更新fsimage文件。 这是元数据第三阶段的一致。
如果Active发生故障，它会立即打开获取Standby客户端读写服务的功能，并通过以前的间隔从JN更新fsimage，使Standby顺利交接了Active的工作。 解决了HDFS1.X单点故障的问题。
Active NN和Standby NN由Zookeeper集群的选举机制决定。
每个NN对应一个故障控制器，通过远程命令切换NN状态，对NN进行健康检查并向Zookeeper报告，如果Active NN发生故障，Zookeeper将从剩下的Standby NN中提取新的action