Hadoop-2.0中单点故障解决方案总结.docxVIP

Hadoop-2.0中单点故障解决方案总结

【自动模式】

在HadoopHA中，主要由以下几个组件构成：

（1）MasterHADaemon：与Master服务运行在同一个进程中，可接收外部RPC命令，以控制Master服务的启动和停止；

（2）SharedStorage：共享存储系统，activemaster将信息写入共享存储系统，而standbymaster则读取该信息以保持与activemaster的同步，从而减少切换时间。常用的共享存储系统有zookeeper（被YARNHA采用）、NFS（被HDFSHA采用）、HDFS（被MapReduceHA采用）和类bookeeper系统（被HDFSHA采用）。

（3）ZKFailoverController：基于Zookeeper实现的切换控制器，主要由两个核心组件构成：ActiveStandbyElector和HealthMonitor，其中，ActiveStandbyElector负责与zookeeper集群交互，通过尝试获取全局锁，以判断所管理的master进入active还是standby状态；HealthMonitor负责监控各个活动master的状态，以根据它们状态进行状态切换。。

（4）Zookeeper集群：核心功能通过维护一把全局锁控制整个集群有且仅有一个activemaster。当然，如果ShardStorge采用了zookeeper，则还会记录一些其他状态和运行时信息。

尤其需要注意的是，解决HA问题需考虑以下几个问题：

（1）脑裂（brain-split）：脑裂是指在主备切换时，由于切换不彻底或其他原因，导致客户端和Slave误以为出现两个activemaster，最终使得整个集群处于混乱状态。解决脑裂问题，通常采用隔离(Fencing)机制，包括三个方面：

共享存储fencing：确保只有一个Master往共享存储中写数据。

客户端fencing：确保只有一个Master可以响应客户端的请求。

Slavefencing：确保只有一个Master可以向Slave下发命令。

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

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

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

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

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

总体上讲，HA解决的难度取决于Master自身记录信息的多少和信息可重构性，如