Hadoop20中单点故障解决方案总结

Hadoop2.0中单点故障解决方案总结Hadoop1.0内核主要由两个分支组成：MapReduce和HDFS，众所周知，这两个系统的设计缺陷是单点故障，即MR的JobTracker和HDFS的NameNode两个核心服务均存在单点问题，该问题在很长时间内没有解决，这使得Hadoop在相当长时间内仅适合离线存储和离线计算。令人欣慰的是，这些问题在Hadoop2.0中得到了非常完整的解决。Hadoop2.0内核由三个分支组成，分别是HDFS、MapReduce和YARN，而Hadoop生态系统中的其他系统，比如HBase、Hive、Pig等，均是基于这三个系统开发的。截止本文发布，Hadoop2.0的这三个子系统的单点故障均已经解决或者正在解决（HadoopHA），本文将为大家介绍当前的进度和具体的解决方案。在正式介绍单点故障解决方案之前，先简要回顾一下这三个系统（三个系统均采用简单的master/slaves架构，其中master是单点故障）。（1）HDFS：仿照googleGFS实现的分布式存储系统，由NameNode和DataNode两种服务组成，其中NameNode是存储了元数据信息（fsimage）和操作日志（edits），由于它是唯一的，其可用性直接决定了整个存储系统的可用性；（2）YARN：Hadoop2.0中新引入的资源管理系统，它的引入使得Hadoop不再局限于MapReduce一类计算，而是支持多样化的计算框架。它由两类服务组成，分别是ResourceManager和NodeManager，其中，ResourceManager作为整个系统的唯一组件，存在单点故障问题；（3）MapReduce：目前存在两种MapReduce实现，分别是可独立运行的MapReduce，它由两类服务组成，分别是JobTracker和TaskTraker，其中JobTracker存在单点故障问题，另一个是MapReduceOnYARN，在这种实现中，每个作业独立使用一个作业跟踪器（ApplicationMaster），彼此之间不再相互影响，不存在单点故障问题。本文提到的单点故障实际上是第一种实现中JobTracker的单点故障。先说当前Hadoop单点故障的解决进度，截止本文发布时，HDFS单点故障已经解决，且提供了两套可行方案；MapReduce单点故障（JobTracker）由CDH4（CDH4同时打包了MRv1和MRv2，这里的单点故障指的是MRv1的单点问题）解决，且已经发布；YARN单点故障尚未解决，但方案已经提出，由于解决方案借鉴了HDFSHA和MapReduceHA的实现，因为将会很快得到解决。总体上说，Hadoop中的HDFS、MapReduce和YARN的单点故障解决方案架构是完全一致的，分为手动模式和自动模式，其中手动模式是指由管理员通过命令进行主备切换，这通常在服务升级时有用，自动模式可降低运维成本，但存在潜在危险。这两种模式下的架构如下。【手动模式】【自动模式】在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解决方案，该方案已经文档化，正在规范和开发中，具体可参考：，总体上看，它的整体架构与MapReduceHA和YARNHA的类似，但共享存储系统采用的是Zookeeper。之所以采用Zookeeper这种轻量级“存储系统”（需要注意的是，zookeeper设计目的并不是存储，而是提供分布式协调服务，但它的确可以安全可靠的存储少量数据以解决分布式环境下多个服务之间的数据共享问题），是由于YARN的大部分信息可以通过NodeManager和ApplicationMaster的心跳信息进行动态重构，而ResourceManager本身只需记录少量信息到Zookeeper上即可。总体上讲，HA解决的难度取决于Master自身记录信息的多少和信息可重构性，如果记录的信息非常庞大且不可动态重构，比如NameNode，则需要一个可靠性与性能均很高的共享存储系统，而如果Master保存有很多信息，但绝大多数可通过Slave动态重构，则HA解决方法则容易得多，典型代表是MapReduce和YARN。从另外一个角度看，由于计算框架对信息丢失不是非常敏感，比如一个已经完成的任务信息丢失，只需重算即可获取，使得计算框架的HA设计难度远低于存储类系统。HadoopHA配置方法：（1）HDFSHA：Hadoop2.0NameNodeHA和Federation实践（2）MapReduceHA：ConfiguringJobTrackerHighAvailabilityHadoop2.0NameNodeHA和Federation实践Postedon2012/12/10一、背景天云趋势在2012年下半年开始为某大型国有银行的历史交易数据备份及查询提供基于Hadoop的技术解决方案，由于行业的特殊性，客户对服务的可用性有着非常高的要求，而HDFS长久以来都被单点故障的问题所困扰，直到ApacheHadoop在2012年5月发布了2.0的alpha版本，其中MRv2还很不成熟，可HDFS的新功能已经基本可用，尤其是其中的的HighAvailability(以下简称HA)和Federation。Cloudera也于7月制作了CDH4.0.1，包含了Hadoop2.0的诸多新功能和组件，于是我们就基于CDH4.0.1进行了HA和Federation的测试。此工作由我和同事张军、钱兴会共同完成。二、为什么需要HA和Federation1.单点故障在Hadoop2.0之前，也有若干技术试图解决单点故障的问题，我们在这里做个简短的总结A.SecondaryNameNode。它不是HA，它只是阶段性的合并edits和fsimage，以缩短集群启动的时间。当NameNode(以下简称NN)失效的时候，SecondaryNN并无法立刻提供服务，SecondaryNN甚至无法保证数据完整性：如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失。B.BackupNameNode(HADOOP-4539)。它在内存中复制了NN的当前状态，算是WarmStandby，可也就仅限于此，并没有failover等。它同样是阶段性的做checkpoint，也无法保证数据完整性。C.手动把name.dir指向NFS。这是安全的ColdStandby，可以保证元数据不丢失，但集群的恢复则完全靠手动。D.FacebookAvatarNode。Facebook有强大的运维做后盾，所以Avatarnode只是HotStandby，并没有自动切换，当主NN失效的时候，需要管理员确认，然后手动把对外提供服务的虚拟IP映射到StandbyNN，这样做的好处是确保不会发生脑裂的场景。其某些设计思想和Hadoop2.0里的HA非常相似，从时间上来看，Hadoop2.0应该是借鉴了Facebook的做法。E.还有若干解决方案，基本都是依赖外部的HA机制，譬如DRBD，LinuxHA，VMware的FT等等。2.集群容量和集群性能单NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，常用的估算公式为1G对应1百万个块，按缺省块大小计算的话，大概是64T(这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)。同时，所有的元数据信息的读取和操作都需要与NN进行通信，譬如客户端的addBlock、getBlockLocations，还有DataNode的blockRecieved、sendHeartbeat、blockReport，在集群规模变大后，NN成为了性能的瓶颈。Hadoop2.0里的HDFSFederation就是为了解决这两个问题而开发的。三、Hadoop2.0里HA的实现方式图片来源：HDFS-1623设计文档图片作者：SanjayRadia,SureshSrinivas在这个图里，我们可以看出HA的大致架构，其设计上的考虑包括：利用共享存储来在两个NN间同步edits信息。以前的HDFS是sharenothingbutNN，现在NN又sharesto