HDFS Federation
NameNode在内存中保存文件系统中每个文件和每个数据块的引用关系，这意味着对于一个拥有大量文件的超大集群来说，内存将成为限制系统横向扩展的瓶颈。在2.0发行版本系列中引入的Federation HDFS允许
系统通过添加NameNode实现扩展，其中每个NameNode管理文件系统命名空间的一部分。在Federation环境下，每个NameNode维护一个命名空间卷（NameSpace Volume），包括命名空间的元数据和在该命名空
间下的文件的所有的数据块的数据块池。命名空间卷是相互独立的，且互不通信，甚至其中一个NameNode失效也不会影响由其他NameNode维护的命名空间的可用性。数据块池不在进行切分，因此集群中的DataNode
需要注册到每个NameNode，并且存储来自多个数据块池中的数据块。
采用Federation的最主要原因是简单，Federation能够快速的解决了大部分单NameNode的问题。Federation 整个核心设计实现大概用了4个月。大部分改变是在Datanode、Config和Tools，而NameNode本身的
改动非常少，这样 Namenode原先的鲁棒性不会受到影响。这使得该方案与之前的HDFS版本兼容。为了水平扩展NameNode，Federation使用了多个独立的NameNode/namespace。这些NameNode之间是联合的，
也就是说，他们之间相互独立且不需要互相协调，各自分工，管理自己的区域。分布式的DataNode被用作通用的数据块存储存储设备。每个DataNode要向集群中所有的NameNode注册，且周期性地向所有NameNode
发送心跳和块报告，并执行来自所有NameNode的命令。一个block pool由属于同一个namespace的数据块组成，每个DataNode可能会存储集群中所有block pool的数据块。每个block pool内部自治，也就是说各自管
理各自的block，不会与其他block pool交流。一个NameNode挂掉了，不会影响其他NameNode。某个NameNode上的namespace和它对应的block pool一起被称为namespace volume。它是管理的基本单位。当一
个NameNode/nodespace被删除后，其所有DataNode上对应的block pool也会被删除。当集群升级时，每个namespace volume作为一个基本单元进行升级。
HDFS High Availability
通过联合使用在多个文件系统中备份NameNode的元数据和通过备用NameNode创建监测点能防止数据丢失，但是依旧无法实现文件系统的高可用性。NameNode依旧存在单点故障（SPOF）问题。如果NameNode
失效了，那么所有的客户端包括MapReduce作业均无法读、写或列（list）文件，因为NameNode是唯一存储元数据与文件到数据块映射的地方，在这一情况下，Hadoop系统无法提供服务直到有新的NameNode上线。
在这样的情况下，要想从一个失效的NameNode恢复，系统管理员得启动一个拥有文件系统元数据的副本的新的NameNode，并配置DataNode和客户端以便使用这个新的NameNode。新的NameNode直到满足以
下情形才能响应服务：1）将命名空间的镜像导入到内存中；2）重做编辑日志；3）接收到足够多的来自DataNode的数据库报告并推出安全模式。对于一个大型并拥有大量文件和数据块的集群，NameNode的冷启动需要
至少30分钟甚至更长时间。如果系统恢复时间太长，也会影响到日常维护。事实上，NameNode失效的可能性非常低，所以在实际应用中计划系统失效时间就显得尤为重要。
在Hadoop-2.x系列发行版本中对上述问题提供了高可用性（High Availability）的支持。在这一实现中，配置了一对活动-备用（Active-Standby）的NameNode。当活动的NameNode失效，备用NameNode则会
接管已失效NameNode的任务并开始服务于来自客户端的请求，不会有任何明显的中断。1：NameNode之间需要通过高可用的共享存储实现编辑日志的共享。在早期的高可用实现版本中需要一个NFS
（Network File System）过滤器来辅助实现，但是在后续版本中提供了更多的选择，如构建于ZooKeeper之上的BookKeeper这样的系统。当备用的NameNode接管工作后，它将通过读取共享编辑日志直至末尾，以实现
与活动的NameNode的状态同步，并继续读取由活动的NameNode写入的新条目；2：DataNode需要同时向两个NameNode发送数据块处理报告，因为数据块的映射信息存储在NameNode的内存中，而非磁盘。3：客
户端需要使用特定的机制来处理NameNode的失效问题，这一机制对用户是透明的。
在活动的NameNode失效之后，备用NameNode能快速（几十秒的时间）实现任务接管，因为最新的状态存储在内存中：包括最新的编辑日志条目和最新的数据块映射信息。实际观察到的失效时间会长一点（需要1分
钟左右），这是因为系统需要保守确定活动NameNode是否真的失效了。
在活动的NameNode失效且备用NameNode也失效的情况下，管理员依旧可以申明一个备用NameNode实现冷启动。这类情况并不会比非高可用（no-HA）的情况更差，并且从操作的角度讲这是一个进步，因为上述
处理已经是一个标准的处理过程并植入Hadoop中。
故障转移与规避：一个称为故障转移控制器（failover_controller）的系统中有一个新实体管理着将将活动NameNode转移为备用NameNode的转换过程。故障转移控制器是可插拔的，但其最初的实现是基于
ZooKeeper的并由此确保且仅有一个活动的NameNode。每一个NameNode运行着一个轻量级的的故障转移控制器（DFSZKFailoverController），其工作就是监视宿主NameNode是否失效（通过一个简单的心跳机制实
现）并在NameNode失效时进行故障切换。管理员也可以手动发起故障转移，例如在进行日常维护时。这称为“平稳的故障转移”（故障转移控制器会组织两个NameNode有序切换）。在非平稳的故障转移时，无法确切知
道失效NameNode是否已经停止运行。例如在网络非常慢或网络被分割的情况下，同样也可能激发故障转移，但是先前活动的NameNode依然运行着并依旧是活动的NameNode。高可用实现做了更进一步的优化以用来确
保先前活动NameNode不会执行危害系统并导致系统崩溃的操作，该方法称为“规避”（fencing）。系统引入了一系列的规避机制，包括杀死NameNode进程，收回访问共享存储目录的权限（通常使用供应商指定的NFS
命令），通过远程管理命令以屏蔽相应网络端口。诉诸最后的手段是先前活动NameNode可以通过一个相当形象的成为STONITH（shoot the node in the head）的技术进行规避，该方法主要通过一个特定的供电单元对相
应的主机进行断电操作。客户端的故障切换通过客户端类库实现透明处理。最简单的实现是通过客户端的配置文件实现故障切换的控制。HDFS URI使用一个逻辑主机名，该主机名映射到一对NameNode地址（在配置文件中
设置），客户端类库会访问每一个NameNode地址，直至处理完成。