Hadoop公共库中对外提供了两种fenching实现，分别是sshfence和shellfence（缺省实现），其中sshfence是指通过ssh登陆目标Master节点上，使用命令fuser将进程杀死（通过tcp端口号定位进程pid，该方法比jps命令更准确），shellfence是指执行一个用户事先定义的shell命令（脚本）完成隔离。

（2）切换对外透明：为了保证整个切换是对外透明的，Hadoop应保证所有客户端和Slave能自动重定向到新的active master上，这通常是通过若干次尝试连接旧master不成功后，再重新尝试链接新master完成的，整个过程有一定延迟。在新版本的Hadoop RPC中，用户可自行设置RPC客户端尝试机制、尝试次数和尝试超时时间等参数。

为了印证以上通用方案，以MapReduce HA为例进行说明，在CDH4中，HA方案介绍可参考我的这篇文章： “CDH中JobTracker HA方案介绍”，架构图如下：

Hadoop 2.0 中 HDFS HA解决方案可阅读文章： “Hadoop 2.0 NameNode HA和Federation实践”，目前HDFS2中提供了两种HA方案，一种是基于NFS共享存储的方案，一种基于Paxos算法的方案 Quorum Journal Manager（QJM），它的基本原理就是用2N+1台JournalNode存储EditLog，每次写数据操作有大多数（>=N+1）返回成功时即认为该次写成功，数据不会丢失了。目前社区正尝试 使用Bookeeper作为共享存储系统，具体可参考。 HDFS-1623给出的HDFS HA架构图如下所示：

目前进度最慢的是YARN HA解决方案，该方案已经文档化，正在规范和开发中，具体可参考： https://issues.apache.org/jira/browse/YARN-149，总体上看，它的整体架构与MapReduce HA和YARN HA的类似，但共享存储系统采用的是Zookeeper。之所以采用Zookeeper这种轻量级“存储系统”（需要注意的是，zookeeper设计目的并不是存储，而是提供分布式协调服务，但它的确可以安全可靠的存储少量数据以解决分布式环境下多个服务之间的数据共享问题），是由于YARN的大部分信息可以通过NodeManager和ApplicationMaster的心跳信息进行动态重构，而ResourceManager本身只需记录少量信息到Zookeeper上即可。

总体上讲，HA解决的难度取决于Master自身记录信息的多少和信息可重构性，如果记录的信息非常庞大且不可动态重构，比如NameNode，则需要一个可靠性与性能均很高的共享存储系统，而如果Master保存有很多信息，但绝大多数可通过Slave动态重构，则HA解决方法则容易得多，典型代表是MapReduce和YARN。从另外一个角度看，由于计算框架对信息丢失不是非常敏感，比如一个已经完成的任务信息丢失，只需重算即可获取，使得计算框架的HA设计难度远低于存储类系统。

原创文章，转载请注明： 转载自 董的博客

本文链接地址: http://dongxicheng.org/mapreduce-nextgen/hadoop-2-0-ha/

作者： Dong，作者介绍： http://dongxicheng.org/about/

本博客的文章集合: http://dongxicheng.org/recommend/

原文地址：Hadoop 2.0中单点故障解决方案总结, 感谢原作者分享。