Hadoop2.0中单点故障解决方案总结---老董

      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的这三个子系统的单点故障均已经解决或者正在解决（Hadoop HA），本文将为你们介绍当前的进度和具体的解决方案。

在正式介绍单点故障解决方案以前，先简要回顾一下这三个系统（三个系统均采用简单的master/slaves架构，其中master是单点故障）。

（1） HDFS：仿照google GFS实现的分布式存储系统，由NameNode和DataNode两种服务组成，其中NameNode是存储了元数据信息（fsimage）和操做日志（edits），因为它是惟一的，其可用性直接决定了整个存储系统的可用性；

（2）YARN：Hadoop 2.0中新引入的资源管理系统，它的引入使得Hadoop再也不局限于MapReduce一类计算，而是支持多样化的计算框架。它由两类服务组成，分别是 ResourceManager和NodeManager，其中，ResourceManager做为整个系统的惟一组件，存在单点故障问题；

（3）MapReduce： 目前存在两种MapReduce实现，分别是可独立运行的MapReduce，它由两类服务组成，分别是JobTracker和TaskTraker，其 中JobTracker存在单点故障问题，另外一个是MapReduce On YARN，在这种实现中，每一个做业独立使用一个做业跟踪器（ApplicationMaster），彼此之间再也不相互影响，不存在单点故障问题。本文提到 的单点故障其实是第一种实现中JobTracker的单点故障。

先说当前Hadoop单点故障的解决进度，截止本文发布时，HDFS单点故障已经解 决，且提供了两套可行方案；MapReduce单点故障（JobTracker）由CDH4（CDH4同时打包了MRv1和MRv2，这里的单点故障指的 是MRv1的单点问题）解决，且已经发布；YARN单点故障还没有解决，但方案已经提出，因为解决方案借鉴了HDFS HA和MapReduce HA的实现，由于将会很快获得解决。

整体上说，Hadoop中的HDFS、MapReduce和YARN的单点故障解决方案架构是彻底一致的，分为手动模式和自动模式，其中手动模式是 指由管理员经过命令进行主备切换，这一般在服务升级时有用，自动模式可下降运维成本，但存在潜在危险。这两种模式下的架构以下。

【手动模式】

【自动模式】

在Hadoop HA中，主要由如下几个组件构成：

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

（2）SharedStorage：共享存储系统，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。固然，若是ShardStorge采用了zookeeper，则还会记录一些其余状态和运行时信息。

尤为须要注意的是，解决HA问题需考虑如下几个问题：

（1）脑裂（brain-split）：脑裂是指在主备切换时，因为切换不完全或其余缘由，致使客户端和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（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设计难度远低于存储类系统。

Hadoop HA配置方法：

（1）HDFS HA：Hadoop 2.0 NameNode HA和Federation实践

（2）MapReduce HA：Configuring JobTracker High Availabili