由于目前的生产环境 namenode ha都只是配置了一块磁盘，如果磁盘坏了，估计就game over了。所以想着怎样做namenode的元数据容错。后来查阅hdfs的相关配置，发现一个恰好可以解决该问题的配置:
<property>
<name>dfs.namenode.name.dir</name>
<value>file://${hadoop.tmp.dir}/dfs/name</value>
<description>Determines where on the local filesystem the DFS name node should store the name table(fsimage). If this is a comma-delimited list of directories then the name table is replicated(复制) in all of the directories, for redundancy(冗余).在实际的生产环境中应该配置成多块磁盘 </description>
</property>
原来该配置是可以多块磁盘的，冗余元数据，达到元数据备份的目的。
既然知道了可以做，那下面就是记录一下本次的工作步骤：
a.修改hdfs-site.xml配置：
<!-- 这是原来的配置：
<property>
<name>dfs.namenode.name.dir</name>
<value>/data2/hadoop/hd_space/dfs/name</value>
</property>
-->
修改为下面的配置，也就是新增了一块磁盘：注意：/data1/hadoop/hd_space/dfs/name目录要事先创建好，否则会报错。
<property>
<name>dfs.namenode.name.dir</name>
<value>/data2/hadoop/hd_space/dfs/name,/data1/hadoop/hd_space/dfs/name</value>
</property>
修改完两个namenode节点的配置文件之后就可以开始进行操作了: 然后重启本来正常集群的两个namenode节点，然后观察active namenode节点的目录下的变化。大概一个小时之后，发现/data1/hadoop/hd_space/dfs/name目录正常生成了fsimage文件，且和先前磁盘的大小一致，所以估计是成功了。
这里有一个问题：为什么是一个小时呢？因为该配置dfs.namenode.checkpoint.period是3600
b.观察standby的namenode的/data1/hadoop/hd_space/dfs/name，发现也正常生成了fsimage文件，并且大小和原来的一致。说明正常。
c.操作一下HDFS的文件，看看增删改查是否，结论:正常。
d.为了进一步进行测试，于是做了以下步骤：
将active namenode下的先前的正常的磁盘目录：/data2/hadoop/hd_space/dfs/name的权限改成hadoop用户不可读写，这样做的目的是模仿磁盘坏掉。然后做如下观察：
(1) namenode进程是否正常。如果正常，就操作几个文件。然后进行下一步：
(2) 新的磁盘目录是否能够正常生成fsimage文件，这里又得是一个小时之后进行观察
(3) 观察文件是否正常
以上正常
(4) 将磁盘/data2/hadoop/hd_space/dfs/name恢复原样，看是否能够正常同步fsimage文件。发现不行。这就好比一块磁盘坏了，你后来又新加上去，肯定要重启才行，现在重启namenode再看效果。效果就是居然重新将该盘进行了格式化。。。。。。。好在后面会重新进行同步。。。。。。
发现一切正常，可以上线了。。。。。
因为刚刚的操作是在测试环境，所以随便重启都是可以的，但是生产不能这么干。上面仅仅是为了验证该方案的可行性。
生产环境的操作步骤:
1. 修改两个namenode节点的配置文件。上面已经说过了.
2. 重启standby节点,待fsimage正常同步后，然后重启active节点。这样就不会对生产造成影响。