HDFS1.X的单点故障和内存受限问题

HDFS2.X提出的HA和Federation分别对应解决两个问题
–解决单点故障
HDFS HA：通过主备NameNode解决，当主NameNode出现故障时，快速切换到备NameNode上。
–解决内存受限
HDFS Federation（联邦），多个NameNode水平扩展，每一个分管一部分目录，所有的NameNode共享所有DataNode存储资源。

一、先说内存受限问题，这里主要讲的是元数据过大引起的内存受限，所以我们的第一反应就是加内存，但是，机器的可加内存是有上限的，所以行不通。那么加机器呢？也不行，因为一个HDFS集群只允许有一个NameNode节点。但是，通过加机器这个思路，我们想到了“加集群”这个思路，即：多个HDFS集群共同分担资源，这就是HDFS Federation的思想。

二、对于单点故障问题，下图是官网给出的HDFS2.X中HA的架构图：

使用两个NameNode：NN Active（活的）和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从而无法进行最后一轮（从上一次更新时到发生故障时）的更新。更新合并的过程都是在JN集群中完成的，两者分别从JN集群中取回合并后的fsimage文件。（有些类似SecondaryNameNode的功能）
3、启动时，DataNode会同时向Active和Standby汇报Block位置信息

所以，整体的流程为：Active格式化后会在磁盘中产生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对应一个FailoverController,通过远程命令切换NN的状态，并对NN进行健康检查，向Zookeeper汇报，若Active NN故障，则Zookeeper在其余的Standby NN中选举出一个新的Active NN。