4 HDFS High-Availability
虽然通过在多个文件系统备份namespace metadata和使用secondarynamenode来定期合并namespace image和editlog以产生新的checkpoint可以保护集群以免数据丢失。但这并没有提供集群的高可用性，因为namenode本身仍然是一个单点故障——如果namenode当掉了，所有的客户端，包括mapreduce作业都无法正常读、写以及查看文件了，因为namenode是维护namespace metadata和提供file-to-block映射的唯一库。
4.1 从失败恢复需完成的工作
要想从失败的namenode中恢复，管理员应启动一个新的namenode，同时配置datanode和用户使用这个新的namenode。这个新的namenode暂时还不能正常运作，直到它做完了以下几件事：
1）把namespace image备份加载入内存；
2）重放edit log中的操作；
3）从datanode中接受足够的blockreport（也就是记录各个datanode中block的信息以确定file-to-block映射），然后离开safemode。
在有很多节点和文件的大的集群中，这个操作可能要花费几十分钟的时间！！
4.2 HDFS High-Availabilty
Hadoop2.x发行版通过加入对HDFS High-Availabilty的支持而有效避免了长时间的downtime。在这种实现中，有一对namenode，它们分别配置为active和standby。当activenamenode当掉时，standbynamenode立即接手继续为client提供服务，期间的中断时间很小。为了实现HDFS High-Availabilty，结构上发生了以下变化：
1）两个namenode使用一个高可用的共享设备（最初HA实现使用的是NFS来共享editlog，不过在未来的版本中会提供更多的选项，如构建于ZooKeeper之上的基于BookKeeper的系统）来存储editlog，当standbynamenode接手运行时，它就会立即重放editlog中的操作（同时它也充当着secondarynamenode的角色，不停地合并老的namespaceimage和新的editlog以免editlog过大），从而很快达到与activenamenode当掉前的状态。
2）datanode需要向两个namenode发送blockreport，因为blockmapping是存放在内存，而不是磁盘中的。
3）用户端（client）必须被合适配置并采用一种对用户透明的方式处理namenode的失败恢复。综合起来，如下图所示：
ps：edit.log中都保存着哪些信息？
All mutations to the file system namespace,such as file renames, permission changes, file creations, blockallocations, etc, are written to a persistent write-ahead log bythe Name Node before returning success to a client call. Inaddition to this edit log, periodic checkpoints of the filesystem, called the fsimage, are also created and storedon-disk on the Name Node. Block locations, on the other hand,are stored only in memory. The locations of all blocks arereceived via “block reports” sent from the Data Nodes whenthe Name Node is started.
5 总结
HDFS是Apache Hadoop的一个子项目，此文介绍了HDFS的一些基本知识，以及Hadoop 2.x引进的两个新特性HDFS Fedoration和HDFS High Availability。后期将会深入到这两个特性的具体架构和实施、测试。