需求：
实现namenode元数据的备份，解决namenode单点宕机导致集群不可用的问题。
方案描述：
当namenode所在服务器宕机的时候，我们可以利用namenode备份的元数据迅速重构新的namenode来投入使用。
1. Hadoop本身提供了可利用secondarynamenode的备份数据来恢复namenode的元数据的方案，但因为checkpoint(在每次checkpoint的时候secondarynamenode才会合并并同步namenode的数据)的问题，secondarynamenode的备份数据并不能时刻保持与namenode同步，也就是说在namenode宕机的时候secondarynamenode可能会丢失一段时间的数据，这段时间取决于checkpoint的周期。我们可以减小checkpoint的周期来减少数据的丢失量，但由于每次checkpoint很耗性能，而且这种方案也不能从根本上解决数据丢失的问题。所以如果需求上不允许这种数据的丢失，这种方案可直接不予考虑。
2. Hadoop提供的另一种方案就是NFS，一种即时备份namenode元数据的方案， 设置多个data目录（包括NFS目录），让namenode在持久化元数据的时候同时写入多个目录，这种方案较第一种方案的优势是能避免数据的丢失（这里我们暂时不讨论NFS本身会丢失数据的可能性，毕竟这种几率很小很小）。既然可以解决数据丢失的问题，说明这套方案在原理上是可行的，以下是测试结果。
测试环境：
虚拟机5台（1G内存，40G硬盘，Ubuntu操作系统，Hadoop-0.20.2，Zookeeper-3.3.2，Hbase-0.20.6），一台namenode，3台datanode，一台NFS服务器（备用namenode）。
测试步骤：
1．部署好Hadoop，Zookeeper，Hbase集群环境及NFS服务器环境。在这里NFS服务器的目录结构应该和datanode的目录结构一样，在namenode宕机的时候，NFS将作为备用namenode启用。（当然这只是用作测试用，实际生产环境应该有专门的NFS服务器和备用namenode）。
2．在namenode上设置dfs.name.dir的目录为本地目录和NFS目录
3．启动集群并存储数据
4．关闭namenode所在机器（模拟namenode服务器宕机）
5．关闭datanode服务器上相关线程，分发集群配置文件，拷贝NFS目录上的备份数据到新namenode的name目录，启动新集群（这里可用工具统一分发配置分件和关闭datanode线程）
6．测试新集群，数据未丢失，集群正常使用
7．回到步骤3
8．关闭NFS服务器（模拟NFS服务器故障）
9．集群瘫痪
10．重启NFS服务器
11．集群恢复
问题及可行性分析：
1. namenode的IP映射及访问问题，重新构造namenode可能导致客户端访问IP不一致，可以在备用namenode投入使用的时候，配置其IP和原namenode一致，或者采取VIP的方案。
2. NFS服务器宕机导致集群瘫痪，可配置NFS集群来确保NFS的可用性。
3. 重新构造namenode的时延问题，不能确保故障发生时能立即投入使用，对于需要即时使用的项目建议采用namenode热备方案。