Hadoop2.0中单点故障解决方案剖析.docx

Hadoop 2.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，最终