1、适合读者如果您是一位Hadoop集群管理维护人员,请阅读本书,它将向您展示当前主流的HDFS HA解决方案,通过文字说明和视频展示这些方案的实现机制和操作细节,使您能够在最短的时间内消化和吸收这些技术,您可以根据自己的需要选择和部署实施最合适的HA方案。如果您是一位Hadoop应用开发者,请阅读本书,您将会在此找到如何结合HDFS的HA,编写出更为健壮的应用程序。如果您是一位分布式文件系统研发人员,请阅读本书,它将向您深入剖析HDFS这一最有影响力的开源云计算分布式存储系统的各种HA方案及其实现机制。 如果您是一位云计算技术的爱好者,请阅读本书,本书会从零开始,一步一步地带您掌握云计算相关技术
2、,并加深概念的理解,为您日后深入接触云计算技术打下基础。本书由文艾和王磊共同编著而成。文艾负责总体设计、内容把握以及写作组织,独立完成第1、2、3、8章,并与王磊共同完成第4、5、6、7以及实验的视频设计和制作。感谢中国电子学会云计算专家委员会专家刘鹏教授的大力支持;感谢我的家人,你们是我奋斗前进的最大动力;最后,希望大家从书中找到需要的东西。时间紧,任务急,错误在所难免,敬请各位批评指正。请发送邮件到hdfsha。第1章 HDFS HA及解决方案HDFS(Hadoop Distributed File System)即Hadoop分布式文件系统,它为Hadoop这个分布式计算框架提供高性能、
3、高可靠、高可扩展的存储服务。1.1 HDFS系统架构HDFS的系统架构如图1.1所示,它是一个典型的主/从架构,包括一个NameNode节点(主节点)和多个DataNode节点(从节点),并提供应用程序访问接口。NameNode是整个文件系统的管理节点,它负责文件系统名字空间(Namespace)的管理与维护,同时负责客户端文件操作的控制以及具体存储任务的管理与分配;DataNode提供真实文件数据的存储服务。图1.1 HDFS系统架构HDFS有两种数据:文件数据和元数据。1文件数据文件数据是指用户保存在HDFS上的文件的具体内容,HDFS将用户保存的文件按照固定大小(用户可设置,通常是64M
4、B)进行分块(每一块简称为一个Block),保存在各个DataNode上,每一个块可能会有多个副本(Replica),具体个数可以由用户指定(通常是3个),相同块对应的副本通常保存在不同的DataNode上,通过副本机制,可以有效保证文件数据的可靠性。2元数据所谓元数据(Metadata)是指数据的数据,HDFS与传统的文件系统一样,提供了一个分级的文件组织形式,维护这个文件系统所需的信息(除了文件的真实内容)就称之为HDFS的元数据。元数据由NameNode进行维护和管理,NameNode在启动时,会从磁盘加载元数据文件到内存,并且等待Data Node上报其他元数据信息,形成最终的元数据结
5、构。由于NameNode是单节点,一旦NameNode无法正常服务,将导致整个HDFS无法正常服务。1.2 HA定义HA的英文全称是High Availability,中文翻译为高可用性。什么是HA?HA与我们平时常说的高可靠性又有什么关系,下面我们一起来看下HA的定义。HA的定义为系统对外正常提供服务时间的百分比。具体来说,HDFS的可靠性可用平均无故障时间(MTTF)来度量,即HDFS正常服务的平均运行时间,HDFS的可维护性用平均维修时间(MTTR2)来度量,即HDFS从不能正常服务到重新正常服务所需要的平均维修时间。因此HDFS的HA可精确定义为:MTTF/(MTTF+MTTR) *
6、100%由上面的定义我们可以很清楚地将HA与高可靠性区分开来,高可靠性更多的是对于系统自身而言,它是系统可靠程度的一个指标。而HA则更多地是从系统对外的角度来说的,除了包含系统正常工作的能力,它还强调系统中止服务后迅速恢复的能力:一个可靠性很高的系统,如果其中止服务后,修复时间很长,那么它的可用性也不会很高,而一个可靠性不是特别高的系统,如果发生中止服务后,可迅速恢复,那么其可用性也可能会很高。因此只有HA才能准确度量系统对外正常服务的能力。HDFS HA的应用场景有很多,我们可以从正常和异常两种情况来分析HDFS对外无法正常服务的情景: 首先是正常使用情况,最常见的应用场景就是NameNod
7、e节点软、硬件的升级与维护,由于NameNode只有一个,当NameNode节点软、硬件的升级与维护操作需要NameNode进行重启时,HDFS将无法服务。 其次是异常情况,常见的场景有:用户的误操作导致NameNode系统崩溃或HDFS发生故障、或者是硬件故障等。在实际使用过程中,软硬件维护、软件故障、错误操作等因素是造成HDFS无法提供正常服务的主要原因,而大家普遍关注的硬件故障并不是主要原因。雅虎的数据表明:在雅虎运行的15个集群中,三年时间内,只有3次NameNode的故障与硬件问题有关。此外,由于HDFS处于Hadoop的底层,上层的其他分布式处理框架如Mapreduce、HBase
8、、Hive、Pig等都依赖于HDFS提供的基础服务,因此HDFS的HA将对这些分布式处理框架的HA构成直接影响,并最终影响到最上层分布式应用的HA。因此对于一个实用的系统来说,在大多数情况下都需要考虑HDFS的HA问题。1.3 HDFS HA原因分析及应对措施根据定义,影响HDFS HA的因素从可靠性和可维护性两方面进行分析。1.3.1 可靠性我们知道,HDFS由NameNode和Data Node两类节点组成,由于NameNode只有个,且负责整个HDFS文件系统的管理和控制,因此当NameNode不能提供正常服务时,会直接导致HDFS不能对外正常服务,因此NameNode的可靠性是影响HD
9、FS可靠性的重要因素。由于NameNode只有一个,它的正常运行与否直接决定了HDFS能否正常服务,因此它也就成为了HDFS系统的一个单一故障点(single point of failure SPOF),DataNode负责存储真实文件数据,每个文件可以指定副本个数,因此同一个文件可在多个DataNode上进行存储,当有DataNode发生故障时,客户端可以访问其他DataNode上的副本,因此DataNode发生故障并不会影响HDFS对外正常服务。1.3.2 可维护性当NameNode不能正常服务时,通常需要重新启动NameNode来恢复服务,NameNode启动时需要加载磁盘上的元数据文
10、件:如果此时元数据没有损坏,那么直接启动NameNode就可以恢复HDFS对外正常服务;如果元数据损坏,将导致NameNode无法启动,无法再对外正常服务,也就是说平均维护时间是无限大。因此元数据的可靠性决定了HDFS的可维护时间。当DataNode无法正常工作时,HDFS会自动启动该DataNode上所有数据的复制任务,将丢失的数据重新分布到其他DataNode上,因此DataNode并不影响HDFS的可维护性。综上所述,HDFS的HA主要由NameNode的HA决定,NameNode的可靠性主要取决于自身计算机硬件系统的可靠性、系统软件以及HDFS软件的可靠性;NameNode的可维护性则
11、取决于元数据的可靠性以及NameNode服务恢复时间。1.4 现有HDFS HA解决方案HDFS的HA的解决方案,主要是从使用者的角度出发,提高元数据的可靠性,减少NameNode服务恢复时间。提高元数据的可靠性措施主要是对元数据进行备份,HDFS自身就具有多种机制来确保元数据的可靠性。减少NameNode服务恢复时间的措施有两种思路: 第1种基于NameNode重启恢复服务的方式,对NameNode自身的启动过程进行分析,优化加载过程,减少启动时间; 第2种则是启动一个NameNode的热备(Warm standby)节点,当主节点不能正常服务时,由热备节点进行接替,此时主备切换时间成为服务
12、恢复时间。从效率上分析,第1种思路尽管进行了优化,但NameNode的启动时间仍受文件系统规模的限制,第2种则突破了这种限制。现有比较成熟的HA解决方案有: Hadoop的元数据备份方案 Hadoop的Secondary NameNode方案3 Hadoop的Checkpoint Node方案4 Hadoop的Backup Node方案5 DRDB方案6 Facebook的Avatarnode方案7下面将依次介绍。1.4.1 Hadoop的元数据备份方案该方案利用Hadoop自身的Failover措施(通过配置dfs.name.dir),NameNode可以将元数据信息保存到多个目录。通常的做
13、法,选择一个本地目录、一个远程目录(通过NFS进行共享),当NameNode发生故障时,可以启动备用机器的NameNode,加载远程目录中的元数据信息,提供服务。优点 Hadoop自带机制,成熟可靠,使用简单方便,无需开发,配置即可。 元数据有多个备份,可有效保证元数据的可靠性,并且内容保持最新状态。 元数据需要同步写入多个备份目录,效率低于单个NameNode。缺点 该方案主要是解决元数据保存的可靠性问题,但没有做到热备,HDFS恢复服务时,需要重新启动NameNode,恢复时间与文件系统规模成正比。 NFS共享的可靠性问题,如果配置的多个目录中有任何一个目录的保存因为异常而阻塞,将会导致整
14、个HDFS的操作阻塞,无法对外提供正常服务。1.4.2 Hadoop的Secondary NameNode方案该方案启动一个Secondary NameNode节点,该节点定期从NameNode节点上下载元数据信息(元数据镜像fsimage 和元数据库操作日志edits),然后将fsimage和edits进行合并,生成新的fsimage(该fsimage就是Secondary NameNode下载时刻的元数据的Checkpoint),在本地保存,并将其推送到NameNode,同时重置NameNode上的edits。 Secondaryary NameNode定期做Checkpoint,可保证各
15、个Checkpoint阶段的元数据的可靠性,同时,进行fsimage与edits的合并,可以有效限制edits的大小,防止其无限制增长。 没有做到热备,当NameNode无法提供服务时,需要重启NameNode,服务恢复时间与文件系统规模大小成正比。 Secondary NameNode保存的只是Checkpoint时刻的元数据,因此,一旦NameNode上的元数据损坏,通过Checkpoint恢复的元数据并不是HDFS此刻的最新数据,存在一致性问题。1.4.3 Hadoop的Checkpoint Node方案Checkpoint Node方案与Secondary NameNode的原理基本相
16、同,只是实现方式不同。该方案利用Hadoop的Checkpoint机制进行备份,配置一个Checkpoint Node。该节点会定期从Primary NameNode中下载元数据信息(fsimage+edits),将edits与fsimage进行合并,在本地形成最新的Checkpoint,并上传到Primary NameNode进行更新。当NameNode发生故障时,极端情况下(NameNode彻底无法恢复),可以在备用节点上启动一个NameNode,读取Checkpoint信息,提供服务。 使用简单方便、无需开发、配置即可。 元数据有多个备份。 没有做到热备、备份节点切换时间长。 Check
17、point Node所做的备份,只是最后一次Check时的元数据信息,并不是发生故障时最新的元数据信息,有可能造成数据的不一致。1.4.4 Hadoop的Backup Node方案利用新版本Hadoop自身的Failover措施,配置一个Backup Node,Backup Node在内存和本地磁盘均保存了HDFS系统最新的名字空间元数据信息。如果NameNode发生故障,可用使用Backup Node中最新的元数据信息。 简单方便、无需开发、配置即可使用。 Backup Node的内存中对当前最新元数据信息进行了备份(Namespace),避免了通过NFS挂载进行备份所带来的风险。 Back
18、up Node可以直接利用内存中的元数据信息进行Checkpoint,保存到本地,与从NameNode下载元数据进行Checkpoint的方式相比效率更高。 NameNode 会将元数据操作的日志记录同步到Backup Node,Backup Node会将收到的日志记录在内存中更新元数据状态,同时更新磁盘上的edits,只有当两者操作成功,整个操作才成功。这样即便NameNode上的元数据发生损坏,Backup Node的磁盘上也保存了HDFS最新的元数据,从而保证了一致性。 高版本(0.21以上)才支持。 许多特性还处于开发之中,例如:当NameNode无法工作时,Backup Node目前
19、还无法直接接替NameNode提供服务,因此当前版本的Backup Node还不具有热备功能,也就是说,当NameNode发生故障,目前还只能通过重启NameNode的方式来恢复服务。 Backup Node的内存中未保存Block的位置信息,仍然需要等待下面的DataNode进行上报,因此,即便在后续的版本中实现了热备,仍然需要一定的切换时间。 当前版本只允许1个Backup Node连接到NameNode。1.4.5 DRDB方案利用DRDB机制进行元数据备份。当NameNode发生故障时,可以启动备用机器的NameNode,读取DRDB备份的元数据信息,提供服务。 DRDB是一种较为成熟
20、的备份机制。 元数据有多个备份、并且保持最新状态。 由于备份的工作交由DRDB完成,对于一条新的日志记录,NameNode无需同步写入多个备份目录,因而NameNode在效率上优于Hadoop的元数据备份方案。 需要引入新的机制、由此带来一定的可靠性问题。1.4.6 FaceBook的AvatarNode方案利用FaceBook提出的Avatar Node机制。Active Node作为Primary NameNode对外提供服务。Standby Node处于Safe mode模式,在内存中保存Primary NameNode最新的元数据信息。Active Node和Standby Node通
21、过NFS共享存储进行交互。DataNode同时向Active Node和Standby Node发送Block location信息。当管理员确定Primary NameNode发生故障后,将Standby Node切换为Primary NameNode。由于Standby Node内存中保存了所有元数据的最新信息,因此可直接对外提供服务,大大缩短了切换时间。 提供热备、切换时间大大缩短。 FaceBook已将其集成到自己维护的Hadoop代码中,并部署到了自己的集群使用。 修改了部分源码、增加了一定的复杂性,并在软件的维护性上带来一定问题。 参考资料较少。 只提供一个备份节点。1.5 方案优
22、缺点比较综上所述,HDFS HA方案比较如表1.1所示。表1.1 HDFS HA方案比较方案名称切换时间元数据一致性是否做checkpoint使用复杂度成熟度相关资料元数据备份长一致否低高较多Secondary NameNode不一定是中Checkpoint Node较少Backup NodeDRDB多AvatarNode短少其中“元数据备份方案”不能单独使用,因为在系统运行期间,没有相应的Checkpoint机制,会造成日志的无限制增长,因此需要和Secondary NameNode、Checkpoint Node或Backup Node配合使用。“DRDB方案”同样如此。而对于Second
23、ary NameNode、Checkpoint Node机制,它们只有Checkpoint的功能,而不能保存实时的元数据,因此需要在Namenode上配置元数据备份路径来保存实时元数据。对于Backup Node,虽然它可以实时保存元数据,但为防止Backup Node成为一个单点,也需要在NameNode上配置元数据备份路径,保存在本地进行备份。总结 元数据备份方案使用简单方便,在功能上可替代DRDB; Backup Node是 Checkpoint Node的升级版,效率更高; Secondary NameNode在低版本的Hadoop中就已存在。因此用户实际上可选择的HA组合方案为:(1
24、)元数据备份+ Secondary NameNode这种方案适用于目前Hadoop 的所有版本,属于冷备,切换时间长。由于Secondary NameNode自身并不实时保存元数据,一旦NameNode上的元数据损坏,将无法恢复到最新的元数据,因此采用元数据备份机制,在NameNode上需要配置多个目录进行备份,常见的做法是再配置一个NFS节点,共享一个目录进行备份。(2)元数据备份+ Backup Node这种方案只有在0.21.0以上版本才支持,目前的实现只支持冷备,切换时间长,自身实时保存元数据,不需要NFS节点。(3)元数据备份+ AvatarNode这种方案需要打Patch(补丁包)
25、,而且只支持特定的版本(0.20)或者使用FaceBook自身的Hadoop版本,切换时间短,需要一个NFS节点作为Active节点和Standby节点的数据交互节点。总之,如果当前Hadoop的版本较低,同时也不允许升级版本的话,可以选择第1种方案;如果版本较新(在0.21.0以上),第2种方案优于第1种;如果对HA切换时间有严格要求的话,则需要选择第3种方案。第1种方案比较简单,资料较多,本书将不再说明,后面着重讲述第2种和第3种方案。第2章 HDFS元数据解析前面已经说过,HDFS中的HA主要解决NameNode的HA,NameNode的HA最重要的目的就是维护元数据的高可用性,因此,有
26、必要对HDFS的元数据进行深入了解。2.1 概 述所谓元数据1(Metadata)就是指数据的数据。HDFS的元数据就是指维护HDFS文件系统中的文件和目录所需要的信息。需要注意的是,具体的文件内容不是元数据,元数据是用于描述和组织具体的文件内容,如果没有元数据,具体的文件内容将变得没有意义。元数据的作用十分重要,它的可用性直接决定了HDFS的可用性。从形式上讲,元数据可分为内存元数据和元数据文件两种。其中NameNode在内存中维护整个文件系统的元数据镜像,用于HDFS的管理;元数据文件则用于持久化存储。从类型上讲,元数据有三类重要信息: 第1类是文件和目录自身的属性信息,例如文件名、目录名
27、、父目录信息、文件大小、创建时间、修改时间等; 第2类记录文件内容存储相关信息,例如文件分块情况、副本个数、每个副本所在的Data Node信息等; 第3类用来记录HDFS中所有Data Node的信息,用于Data Node管理。从来源上讲,元数据主要来源于NameNode磁盘上的元数据文件(它包括元数据镜像fsimage和元数据操作日志edits两个文件)以及各个Data Node的上报信息。下面我们结合源码进行分析,源码的版本为0.21.0。2.2 内存元数据结构从HDFS自身实现的角度来看,文件和目录是文件系统的基本元素,HDFS将这些元素抽象成INode,每一个文件或目录都对应一个唯一的INode,INode存储了名字信息(分别对应文件或目录的名字)同时还存储了创建时间、修改时间、
copyright@ 2008-2022 冰豆网网站版权所有
经营许可证编号:鄂ICP备2022015515号-1