hdfs namenode

 0.23和2.0分支支持federation，相当于将命名空间横向分片。
 
 2.0分支NameNode支持HA, 有基于NFS和QJM(Quorum Journal Manager)
 

NameNode的冷备：

Secondary Namenode和Backup Node都是NN的冷备，切换需要手工切换IP。

 Secondary Namenode定期地从Namenode上获取元数据。当它准备获取元数据的时候，就通知Namenode暂停写入edits文件。Namenode收到请求后停止写入edits文件，之后的log记录写入一个名为edits.new的文件。Scondary Namenode获取到元数据以后，把edits文件和fsimage文件在本机进行合并，创建出一个新的fsimage文件，然后把新的fsimage文件发送回Namenode。Namenode收到Secondary Namenode发回的fsimage后，就拿它覆盖掉原来的fsimage文件，并删除edits文件，把edits.new重命名为edits。
 通过这样一番操作，就避免了Namenode的edits日志的无限增长，加速Namenode的启动过程。
 但是Scondary Namenode有其自身的弱点，如checkpoint数据较旧，数据不一致等，新版本的hadoop已经把它放弃了，转而使用更加高效的Backup Node。
 
 0.21版本后支持Backup Node，在内存中维护了一份从Namenode同步过来的fsimage，同时它还从namenode接收edits文件的日志流，并把它们持久化硬盘，Backup Node把收到的这些edits文件和内存中的fsimage文件进行合并，创建一份元数据备份。Backup Node高效的秘密就在这儿，它不需要从Namenode下载fsimage和edit，把内存中的元数据持久化到磁盘然后进行合并即可。
 目前，hadoop集群只支持一个Backup Node，如果Backup Node出了问题，Hadoop元数据的备份机制也就失效了，所以hadoop计划在未来能支持多个Backup Node。