HDFS Federation

在Hadoop 2.0之前，也有若干技术试图解决单点故障的问题:

Secondary NameNode。

它不是HA，它只是阶段性的合并edits和fsimage，以缩短集群启动的时间。

当NameNode失效的时候，Secondary NN并无法立刻提供服务，Secondary NN甚至无法保证数据完整性：

如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失。

Backup NameNode 。

它在内存中复制了NN的当前状态，算是Warm Standby，可也就仅限于此，并没有failover等。

它同样是阶段性的做checkpoint，也无法保证数据完整性。

手动把name.dir指向NFS。安全的Cold Standby，可以保证元数据不丢失，但集群的恢复则完全靠手动。

单NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，常用的估算公式为1G对应1百万个块，按缺省块大小计算的话，大概是64T。同时，所有的元数据信息的读取和操作都需要与NN进行通信，譬如客户端的addBlock、getBlockLocations，还有DataNode的blockRecieved、sendHeartbeat、blockReport，在集群规模变大后，NN成为了性能的瓶颈。

HDFS Federation是为解决HDFS单点故障而提出的NameNode水平扩展方案。

允许HDFS创建多个NameSpace以提高集群扩展性和隔离性。

当前HDFS包含两层结构：

(1) Namespace 管理目录，文件和数据块。它支持常见的文件系统操作，如创建文件，修改文件，删除文件等。

(2)Block Storage有两部分组成： Block Management维护集群中datanode的基本关系，它支持数据块相关的操作，如：创建数据块，删除数据块等，同时，它也会管理副本的复制和存放。 Physical Storage存储实际的数据块并提供针对数据块的读写服务。

HDFS架构只允许整个集群中存在一个namespace，而该namespace被仅有的一个namenode管理。这个架构使得HDFS非常容易实现，但是，它（见上图）在具体实现过程中会出现一些模糊点，进而导致了很多局限性



参考文献：

[0] HDFS Federation

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/Federation.html

[1] An Introduction to HDFS Federation

http://zh.hortonworks.com/blog/an-introduction-to-hdfs-federation/