Hadoop 1.0内核主要包括两个分支： MapReduce和HDFS，众所周知，这两个系统的设计缺陷是单点故障。 这意味着MR的JobTracker和HDFS的NameNode这两个核心服务存在单点问题，这个问题很久没有解决，Hadoop在相当长的一段时间内只适合离线存储和离线
幸运的是，这些问题在Hadoop 2.0中得到了非常完全的解决。 Hadoop 2.0内核由三个分支： HDFS、MapReduce和YARN，Hadoop生态系统中的HBase、Hive、Pig等其他系统就是基于这三个系统开发的。 截至本文发表，Hadoop 2.0三个子系统的单点故障已经或正在解决。 本文介绍了当前的进展情况和具体的解决方案。
在正式讨论单点故障解决方案之前，请先简要了解三个系统。 所有三个系统都采用简单的主/镜像体系结构，其中主故障。
)1)HDFS)仿照谷歌GFS实现的分布式存储系统，由NameNode和DataNode两种服务构成。 其中，NameNode存储了元数据信息(fsimage )和操作记录(edits )。 因为这是唯一的
)2)YARN:Hadoop 2.0中新引入的资源管理系统。 由于它的引入，Hadoop不再局限于MapReduce这样的计算，而是支持各种各样的计算框架。 由两种服务组成：资源管理器和节点管理器，资源管理器是整个系统的唯一组件，存在单点故障问题。
)3)MapReduce)目前存在两种MapReduce实现，分别是可以独立运行的MapReduce。 它由两种服务组成，分别是JobTracker和TaskTraker，其中JobTracker存在单点故障问题，另一个是MapReduce，通过对每个作业独立使用作业跟踪器，相互影响本文中描述的单点故障实际上是JobTracker在初始实现中的单点故障。
首先，说明当前Hadoop单点故障的解决进展情况。 截至本文发表时，HDFS的单点故障已经解决，提供了两种可行的方案。 MapReduce的单点故障(JobTracker )是CDH4 ) CDH4是MRv1和MRv2的封装(这里的单点故障指的是MRv1的单点问题)解决的，已经发行； YARN单点故障还没有解决，但已经提出了解决方案。 因为解决方案参考了HDFS HA和MapReduce HA的实现，所以很快就会解决。
一般来说，Hadoop的HDFS、MapReduce和YARN单点故障解决方案体系结构完全一致，分为手动模式和自动模式。 其中，手动模式是指管理员通过命令在主备份之间切换，通常在服务器升级时很有用。 自动模式降低运输成本，但具有潜在的危险。 这两种模式的体系结构如下。
【手动模式】
【自动模式】
在Hadoop HA中，主要由以下组件组成：
)1)MasterHADaemon:运行在与主服务器相同的进程中，可以接收用于控制主服务器的启动和停止的外部RPC命令；
)2)SharedStorage:共享存储系统。 active master会将信息写入共享存储系统，而standby master会读取该信息以保持与active master的同步，从而缩短切换时间。 典型的共享存储系统包括bookeeper (与yarn ha一起使用)、NFS ) HDFS HA中使用)、HDFS ) MapReduce HA中使用)、bookeeper类) HDFS HA中使用)。
)3)基于3358www.Sina.com/:zookeeper实现的交换控制器主要由ActiveStandbyElector和HealthMonitor两个核心组件组成，其中ActiveStandbyElector是zookector，其负责的HealthMonitor监视每个活动主服务器的状态，并根据状态切换状态。 请参阅。
)4)ZKFailoverController)通过维护单个全局锁，整个集群中存在http://核心功能，并且只控制一个active master。 当然，如果ShardStorge采用zookeeper，则会记录其他状态和运行时信息。
特别是，要解决HA问题，必须考虑以下事项：
Zookeeper集群脑裂是指主备切换时，由于切换不完全或其他原因，客户端和Slave误认为出现了两个active master，最终导致整个集群陷入混乱状态解决脑裂问题，沟通
常采用隔离(Fencing)机制，包括三个方面： 共享存储fencing：确保只有一个Master往共享存储中写数据。客户端fencing：确保只有一个Master可以响应客户端的请求。Slave fencing：确保只有一个Master可以向Slave下发命令。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（lgdyc），它的基本原理就是用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设计难度远低于存储类系统。
Hadoop HA配置方法：
（1）HDFS HA：Hadoop 2.0 NameNode HA和Federation实践
（2）MapReduce HA：Configuring JobTracker High Availability
转载自董的博客