Hadoop 20中单点故障解决方案总结.docx
- 文档编号:24294694
- 上传时间:2023-05-26
- 格式:DOCX
- 页数:25
- 大小:440.23KB
Hadoop 20中单点故障解决方案总结.docx
《Hadoop 20中单点故障解决方案总结.docx》由会员分享,可在线阅读,更多相关《Hadoop 20中单点故障解决方案总结.docx(25页珍藏版)》请在冰豆网上搜索。
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解决方案,该方案已经文档化,正在规范和开发中,具体可参考:
https:
//issues.apache.org/jira/browse/YARN-149,总体上看,它的整体架构与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:
ConfiguringJobTrackerHighAvailability
Hadoop2.0NameNodeHA和Federation实践
Postedon 2012/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和Federation
1.单点故障
在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又sharestorage,这样其实是转移了单点故障的位置,但中高端的存储设备内部都有各种RAID以及冗余硬件包括电源以及网卡等,比服务器的可靠性还是略有提高。
通过NN内部每次元数据变动后的flush操作,加上NFS的close-to-open,数据的一致性得到了保证。
社区现在也试图把元数据存储放到BookKeeper上,以去除对共享存储的依赖,Cloudera也提供了QuorumJournalManager的实现和代码,这篇中文的blog有详尽分析:
基于QJM/QuromJournalManager/Paxos的HDFSHA原理及代码分析
▪DataNode(以下简称DN)同时向两个NN汇报块信息。
这是让StandbyNN保持集群最新状态的必需步骤,不赘述。
▪用于监视和控制NN进程的FailoverController进程
显然,我们不能在NN进程内进行心跳等信息同步,最简单的原因,一次FullGC就可以让NN挂起十几分钟,所以,必须要有一个独立的短小精悍的watchdog来专门负责监控。
这也是一个松耦合的设计,便于扩展或更改,目前版本里是用ZooKeeper(以下简称ZK)来做同步锁,但用户可以方便的把这个ZooKeeperFailoverController(以下简称ZKFC)替换为其他的HA方案或leader选举方案。
▪隔离(Fencing),防止脑裂,就是保证在任何时候只有一个主NN,包括三个方面:
▪共享存储fencing,确保只有一个NN可以写入edits。
▪客户端fencing,确保只有一个NN可以响应客户端的请求。
▪DataNodefencing,确保只有一个NN可以向DN下发命令,譬如删除块,复制块,等等。
四、Hadoop2.0里Federation的实现方式
图片来源:
HDFS-1052 设计文档
图片作者:
SanjayRadia,SureshSrinivas
这个图过于简明,许多设计上的考虑并不那么直观,我们稍微总结一下
▪多个NN共用一个集群里DN上的存储资源,每个NN都可以单独对外提供服务
▪每个NN都会定义一个存储池,有单独的id,每个DN都为所有存储池提供存储
▪DN会按照存储池id向其对应的NN汇报块信息,同时,DN会向所有NN汇报本地存储可用资源情况
▪如果需要在客户端方便的访问若干个NN上的资源,可以使用客户端挂载表,把不同的目录映射到不同的NN,但NN上必须存在相应的目录
这样设计的好处大致有:
▪改动最小,向前兼容
▪现有的NN无需任何配置改动.
▪如果现有的客户端只连某台NN的话,代码和配置也无需改动。
▪分离命名空间管理和块存储管理
▪提供良好扩展性的同时允许其他文件系统或应用直接使用块存储池
▪统一的块存储管理保证了资源利用率
▪可以只通过防火墙配置达到一定的文件访问隔离,而无需使用复杂的Kerberos认证
▪客户端挂载表
▪通过路径自动对应NN
▪使Federation的配置改动对应用透明
五、测试环境
以上是HA和Federation的简介,对于已经比较熟悉HDFS的朋友,这些信息应该已经可以帮助你快速理解其架构和实现,如果还需要深入了解细节的话,可以去详细阅读设计文档或是代码。
这篇文章的主要目的是总结我们的测试结果,所以现在才算是正文开始。
为了彻底搞清HA和Federation的配置,我们直接一步到位,选择了如下的测试场景,结合了HA和Federation:
这张图里有个概念是前面没有说明的,就是NameService。
Hadoop2.0里对NN进行了一层抽象,提供服务的不再是NN本身,而是NameService(以下简称NS)。
Federation是由多个NS组成的,每个NS又是由一个或两个(HA)NN组成的。
在接下里的测试配置里会有更直观的例子。
图中DN-1到DN-6是六个DataNode,NN-1到NN-4是四个NameNode,分别组成两个HA的NS,再通过Federation组合对外提供服务。
StoragePool1和StoragePool2分别对应这两个NS。
我们在客户端进行了挂载表的映射,把/share映射到NS1,把/user映射到NS2,这个映射其实不光是要指定NS,还需要指定到其上的某个目录,稍后的配置中大家可以看到。
下面我们来看看配置文件里需要做哪些改动,为了便于理解,我们先把HA和Federation分别介绍,然后再介绍同时使用HA和Federation时的配置方式,首先我们来看HA的配置:
对于HA中的所有节点,包括NN和DN和客户端,需要做如下更改:
HA,所有节点,hdfs-site.xml
9000
50070
以上的示例里,我们用了${}来表示变量值,其展开后的内容大致如下:
9000
50070
9000
50070
与此同时,在HA集群的NameNode或客户端还需要做如下配置的改动:
HA,NameNode,hdfs-site.xml
///nfs/ha-edits
2181,host-zk2:
2181,host-zk3:
2181,
HA,客户端,hdfs-site.xml
以上示例为Hadoop2.0自带的缺省代理类
最后,为了方便使用相对路径,而不是每次都使用hdfs:
//ns1作为文件路径的前缀,我们还需要在各角色节点上修改core-site.xml:
HA,所有节点,core-site.xml
//ns1
此配置替代了1.0里的fs.default.name
接下来我们看一下如果单独使用Federation,应该如何配置,这里我们假设没有使用HA,而是直接使用nn1和nn2组成了Federation集群,他们对应的NS的逻辑名称分别是ns1和ns2。
为了便于理解,我们从客户端使用的core-site.xml和挂载表入手:
Federation,所有节点,core-site.xml
includehref=“cmt.xml"/> //nsX<
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Hadoop 20中单点故障解决方案总结 20 单点 故障 解决方案 总结