Hadoop系统中的单点故障解决方案总结

相较与Hadoop1.0，Hadoop2.0提供了比较完整的单点故障解决方案（Hadoop HA）

Hadoop2.0内核由三个分支组成：HDFS、MapReduce和YARN，其他的Hadoop生态系统组件比如：HBase、Hive、Pig等，均是基于这三个系统开发的。

因此在Hadoop2.0，存在着三个子系统的单点故障问题。

正式介绍解决方案之前，先简要回顾这三个子系统：

（1）HDFS：即分布式存储系统。由NameNode和DataNode组成，其中NameNode存储了元数据信息和操作日志，由于它是唯一的，其可用性直接决定了整个存储系统的可用性。

（2）YARN：Hadoop2.0中新引入的资源管理系统，它的引入使得Hadoop不再局限于只进行MapReduce这一类的计算，从而支持了多样化的计算框架。它由ResourceManager和NodeManager组成，其中ResourceManager作为整个系统的唯一组件，存在单点故障问题。

（3）MapReduce：目前存在两种MapReduce实现：一种是可独立运行的MapReduce，它由JobTracker和TaskTracker两部分组成，其中JobTracker存在单点故障问题；另一种是MapReduce On YARN，在这种实现中，每个作业独立使用一个作业跟踪器（ApplicationMaster），彼此之间不再相互影响，不存在单点故障问题。因此，本文的单点故障问题是针对第一种MapReduce实现提出的。

总体上说，Hadoop中HDFS、MapReduce和YARN的单点故障解决方案是一致的（采用Hadoop HA）。分为手动模式和自动模式。

手动模式是指由管理员通过命令进行主备切换，这通常在服务升级时有用。

自动模式可降低运维成本，但存在潜在危险。

两种模式架构如下：

【手动模式】

【自动模式】

在Hadoop HA中，主要由以下组件构成：

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

（2）Shared Storage：共享存储系统，active master将信息写入共享存储系统，而standby master则读取该信息以保持与active master的同步，从而减少切换时间。常用的共享存储系统有zookeeper（被YARN HA采用）、NFS（被HDFS HA采用）、HDFS（被MapReduce HA采用）和类bookeeper系统（被HDFS HA采用）

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

（4）Zookeeper集群：核心功能通过维护一把全局锁，控制整个集群使得有且仅有一个active master。

在使用Hadoop HA解决单点故障问题时，还需考虑以下几个问题：

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

    ①共享存储隔离：确保只有一个Master往共享存储中写数据

    ②客户端隔离：确保只有一个Master可以响应客户端的请求

    ③Slave隔离：确保只有一个Master可以向Slave下发命令

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

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