Nameode的容错
第一种方式是将持久化存储在本地硬盘的文件系统元数据备份。Hadoop可以通过配置来让Namenode将他的持久化状态文件写到不同的文件系统中，这种写操作是同步并且是原子化的。比较常见的配置是将持久化状态写到本地硬盘的同时，也写入到一个远程挂载的网络文件系统。
第二种方式是运行一个辅助的NameNode（Secondary Namenode）。不过 Secondary并不能被用作Namenode，它的主要作用是定期将NameSpace镜像与操作日志文件（editslog）合并，以防止操作日志文件（editslog）变得过大。通常，Secondary Namenode 运行在一个单独的物理机上，因为合并操作需要占用大量cpu时间以及和Namenode相当的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份，当Namenode发生故障时启用。但是辅助namenode保存的状态总是滞后于主节点，所以在主节点全部失效的时候，难免是会丢失部分数据。我们一般采取的方案是，把存储在远程挂载的网络文件系统中的namenode元数据复制到辅助namenode，并作为新的namenode运行，或者，也可以运行热备份namenode代替运行辅助namenode。
第三种 zookeeper提供的高可用（ha）机制。Ha配置来一对活动备用（active-standby）namenode，当活动namenode失效时，备用的namenode就会接管他的任务并开始服务于来自客户端的请求，不会有明显的中断。
HA实现架构修改：
1，namenode之间需要通过高可用共享存储实现编辑日志的共享。当备用的namenode接管工作滞后，他将通读共享编辑日志直到末尾，已实现与活动namenode的状态同步，并继续读取由活动namenode写入的新条目。
2，datanode需要同时向两个namenode发送数据块处理报告，因为数据的映射信息存储在namenode的内部中，而非磁盘。
3，客户端需要使用特定的机制来处理namenode的失效问题，这一机制对用户是透明的。
4，辅助namenode的角色被备用namenode所包含，备用的namenode为活动的namenode命名空间设置周期性检查点。
当活动的namenode失效，备用的namenode也失效（这种概率极低），管理员依旧可以声明一个备用namenode并实现冷启动。