高可用性的HDFS清华大学出版社.docx

资源描述

高可用性的HDFS清华大学出版社.docx

《高可用性的HDFS清华大学出版社.docx》由会员分享，可在线阅读，更多相关《高可用性的HDFS清华大学出版社.docx（18页珍藏版）》请在冰豆网上搜索。

高可用性的HDFS清华大学出版社.docx

高可用性的HDFS清华大学出版社

前言

Hadoop是目前主流的开源云计算系统，它实现了一个高可扩展的分布式文件系统——HDFS（HadoopDistributedFileSystem），HDFS作为Hadoop底层基础设施，为云计算提供高可靠、高性能的存储服务。

HDFS在很大程度上借鉴了GoogleGFS文件系统的设计思想，具有高度容错、支持大数据集等诸多特性。

这些特性曾让我们欢欣鼓舞，一度以为HDFS是一个可以解决数据密集型应用的海量数据存储难题的完美方案。

随着研究的深入，我们在不断叹服HDFS设计构思巧妙的同时，也深深地认识到仅有以上的特性还不足以构建一个实用的分布式文件系统，还需要一些其他特性进行支撑，高可用性则是其中最为关键的一点。

高可用性是指系统正常服务时间所占的百分比，它是衡量系统对外正常服务能力的重要指标。

对于HDFS来说，每一份数据可以有多个副本，因此文件数据的可靠性可以由副本来解决。

然而，对于元数据管理来说，只有一个节点NameNode，它的好坏直接决定了HDFS能否正常服务，因此NameNode的高可用性决定了整个HDFS系统的高可用性。

不同应用对HDFS高可用性有不同要求，目前Hadoop自身包括其他一些开源组织提供了一些相应的高可用性机制以满足不同的需要，如BackupNode方案以及AvatarNode方案等。

根据我们的实践经验，在使用以上方案解决实际问题时，需要具备以下几点基础：

●首先是对NameNode元数据机制有较深的理解和把握；

●其次要对各种解决方案的运行机制及使用方法有个全面掌握；

●再次就是要有较强的实践操作经验。

然而，就现实情况而言，要在以上任何一点取得一点进展都需要付出相当大的努力，回顾我们的团队在接触HDFS的高可用性之初，由于资料和经验的匮乏，每掌握一个知识点，都需经历资料查找、邮件列表搜索、邮件请教、代码查看、实验验证等多个环节，其间的付出可想而知，正是基于这点，我们也深切地感觉有必要将我们前期的经验和心得与大家分享，姑且也算做是我们团队对于开源软件事业的一点小小的回馈吧。

本书内容

本书一共8章，分为4个部分。

其中第1部分为第１章，主要介绍当前HDFS主流的HA方案以及相关概念，使读者能够有一个宏观上的认识，同时通过方案的比较，遴选出3种具有代表性的HA方案。

第2部分为第2章，围绕HDFSHA的重点关注对象元数据，对内存元数据结构、磁盘元数据文件、文件系统格式化场景以及元数据在HA中的应用场景进行了深入剖析。

第3部一共5章（3、4、5、6、7），主要介绍３种经典的HA解决方案：

Hadoop元数据备份方案、BackupNode方案以及AvatarNode方案，从代码入手，分别从运行机制、使用方法等方面进行说明，每种方案都有详细的使用说明并配以视频，便于读者掌握。

第4部分为第8章，介绍目前最新HA解决方案CloudreaHANameNode。

适合读者

如果您是一位Hadoop集群管理维护人员，请阅读本书，它将向您展示当前主流的HDFSHA解决方案，通过文字说明和视频展示这些方案的实现机制和操作细节，使您能够在最短的时间内消化和吸收这些技术，您可以根据自己的需要选择和部署实施最合适的HA方案。

如果您是一位Hadoop应用开发者，请阅读本书，您将会在此找到如何结合HDFS的HA，编写出更为健壮的应用程序。

如果您是一位分布式文件系统研发人员，请阅读本书，它将向您深入剖析HDFS这一最有影响力的开源云计算分布式存储系统的各种HA方案及其实现机制。

如果您是一位云计算技术的爱好者，请阅读本书，本书会从零开始，一步一步地带您掌握云计算相关技术，并加深概念的理解，为您日后深入接触云计算技术打下基础。

本书由文艾和王磊共同编著而成。

文艾负责总体设计、内容把握以及写作组织，独立完成第1、2、3、8章，并与王磊共同完成第4、5、6、7以及实验的视频设计和制作。

感谢中国电子学会云计算专家委员会专家刘鹏教授的大力支持；感谢我的家人，你们是我奋斗前进的最大动力；

最后，希望大家从书中找到需要的东西。

时间紧，任务急，错误在所难免，敬请各位批评指正。

请发送邮件到hdfsha@。

第1章HDFSHA及解决方案

HDFS[]（HadoopDistributedFileSystem）即Hadoop分布式文件系统，它为Hadoop这个分布式计算框架提供高性能、高可靠、高可扩展的存储服务。

1.1HDFS系统架构

HDFS的系统架构如图1.1所示，它是一个典型的主/从架构，包括一个NameNode节点（主节点）和多个DataNode节点（从节点），并提供应用程序访问接口。

NameNode是整个文件系统的管理节点，它负责文件系统名字空间（Namespace）的管理与维护，同时负责客户端文件操作的控制以及具体存储任务的管理与分配；DataNode提供真实文件数据的存储服务。

图1.1HDFS系统架构

HDFS有两种数据：

文件数据和元数据。

1．文件数据

文件数据是指用户保存在HDFS上的文件的具体内容，HDFS将用户保存的文件按照固定大小（用户可设置，通常是64MB）进行分块（每一块简称为一个Block），保存在各个DataNode上，每一个块可能会有多个副本（Replica），具体个数可以由用户指定（通常是3个），相同块对应的副本通常保存在不同的DataNode上，通过副本机制，可以有效保证文件数据的可靠性。

2．元数据

所谓元数据（Metadata）是指数据的数据，HDFS与传统的文件系统一样，提供了一个分级的文件组织形式，维护这个文件系统所需的信息（除了文件的真实内容）就称之为HDFS的元数据。

元数据由NameNode进行维护和管理，NameNode在启动时，会从磁盘加载元数据文件到内存，并且等待DataNode上报其他元数据信息，形成最终的元数据结构。

由于NameNode是单节点，一旦NameNode无法正常服务，将导致整个HDFS无法正常服务。

1.2HA定义

HA的英文全称是HighAvailability，中文翻译为高可用性。

什么是HA？

HA与我们平时常说的高可靠性又有什么关系，下面我们一起来看下HA的定义。

HA的定义为系统对外正常提供服务时间的百分比。

具体来说，HDFS的可靠性可用平均无故障时间（MTTF[]）来度量，即HDFS正常服务的平均运行时间，HDFS的可维护性用平均维修时间（MTTR[2]）来度量，即HDFS从不能正常服务到重新正常服务所需要的平均维修时间。

因此HDFS的HA可精确定义为：

MTTF/（MTTF+MTTR）*100%

由上面的定义我们可以很清楚地将HA与高可靠性区分开来，高可靠性更多的是对于系统自身而言，它是系统可靠程度的一个指标。

而HA则更多地是从系统对外的角度来说的，除了包含系统正常工作的能力，它还强调系统中止服务后迅速恢复的能力：

一个可靠性很高的系统，如果其中止服务后，修复时间很长，那么它的可用性也不会很高，而一个可靠性不是特别高的系统，如果发生中止服务后，可迅速恢复，那么其可用性也可能会很高。

因此只有HA才能准确度量系统对外正常服务的能力。

HDFSHA的应用场景有很多，我们可以从正常和异常两种情况来分析HDFS对外无法正常服务的情景：

▪首先是正常使用情况，最常见的应用场景就是NameNode节点软、硬件的升级与维护，由于NameNode只有一个，当NameNode节点软、硬件的升级与维护操作需要NameNode进行重启时，HDFS将无法服务。

▪其次是异常情况，常见的场景有：

用户的误操作导致NameNode系统崩溃或HDFS发生故障、或者是硬件故障等。

在实际使用过程中，软硬件维护、软件故障、错误操作等因素是造成HDFS无法提供正常服务的主要原因，而大家普遍关注的硬件故障并不是主要原因。

雅虎的数据表明：

在雅虎运行的15个集群中，三年时间内，只有3次NameNode的故障与硬件问题有关。

此外，由于HDFS处于Hadoop的底层，上层的其他分布式处理框架如Mapreduce、HBase、Hive、Pig等都依赖于HDFS提供的基础服务，因此HDFS的HA将对这些分布式处理框架的HA构成直接影响，并最终影响到最上层分布式应用的HA。

因此对于一个实用的系统来说，在大多数情况下都需要考虑HDFS的HA问题。

1.3HDFSHA原因分析及应对措施

根据定义，影响HDFSHA的因素从可靠性和可维护性两方面进行分析。

1.3.1可靠性

我们知道，HDFS由NameNode和DataNode两类节点组成，由于NameNode只有１个，且负责整个HDFS文件系统的管理和控制，因此当NameNode不能提供正常服务时，会直接导致HDFS不能对外正常服务，因此NameNode的可靠性是影响HDFS可靠性的重要因素。

由于NameNode只有一个，它的正常运行与否直接决定了HDFS能否正常服务，因此它也就成为了HDFS系统的一个单一故障点（singlepointoffailure——SPOF），DataNode负责存储真实文件数据，每个文件可以指定副本个数，因此同一个文件可在多个DataNode上进行存储，当有DataNode发生故障时，客户端可以访问其他DataNode上的副本，因此DataNode发生故障并不会影响HDFS对外正常服务。

1.3.2可维护性

当NameNode不能正常服务时，通常需要重新启动NameNode来恢复服务，NameNode启动时需要加载磁盘上的元数据文件：

如果此时元数据没有损坏，那么直接启动NameNode就可以恢复HDFS对外正常服务；如果元数据损坏，将导致NameNode无法启动，无法再对外正常服务，也就是说平均维护时间是无限大。

因此元数据的可靠性决定了HDFS的可维护时间。

当DataNode无法正常工作时，HDFS会自动启动该DataNode上所有数据的复制任务，将丢失的数据重新分布到其他DataNode上，因此DataNode并不影响HDFS的可维护性。

综上所述，HDFS的HA主要由NameNode的HA决定，NameNode的可靠性主要取决于自身计算机硬件系统的可靠性、系统软件以及HDFS软件的可靠性；NameNode的可维护性则取决于元数据的可靠性以及NameNode服务恢复时间。

1.4现有HDFSHA解决方案

HDFS的HA的解决方案，主要是从使用者的角度出发，提高元数据的可靠性，减少NameNode服务恢复时间。

提高元数据的可靠性措施主要是对元数据进行备份，HDFS自身就具有多种机制来确保元数据的可靠性。

减少NameNode服务恢复时间的措施有两种思路：

▪第1种基于NameNode重启恢复服务的方式，对NameNode自身的启动过程进行分析，优化加载过程，减少启动时间；

▪第2种则是启动一个NameNode的热备（Warmstandby）节点，当主节点不能正常服务时，由热备节点进行接替，此时主备切换时间成为服务恢复时间。

从效率上分析，第1种思路尽管进行了优化，但NameNode的启动时间仍受文件系统规模的限制，第2种则突破了这种限制。

现有比较成熟的HA解决方案有：

▪Hadoop的元数据备份方案

▪Hadoop的SecondaryNameNode方案[3]

▪Hadoop的CheckpointNode方案[4]

▪Hadoop的BackupNode方案[5]

▪DRDB方案[6]

▪Facebook的Avatarnode方案[7]

下面将依次介绍。

1.4.1Hadoop的元数据备份方案

该方案利用Hadoop自身的Failover措施（通过配置dfs.name.dir），NameNode可以将元数据信息保存到多个目录。

通常的做法，选择一个本地目录、一个远程目录（通过NFS进行共享），当NameNode发生故障时，可以启动备用机器的NameNode，加载远程目录中的元数据信息，提供服务。

优点

▪Hadoop自带机制，成熟可靠，使用简单方便，无需开发，配置即可。

▪元数据有多个备份，可有效保证元数据的可靠性，并且内容保持最新状态。

▪元数据需要同步写入多个备份目录，效率低于单个NameNode。

缺点

▪该方案主要是解决元数据保存的可靠性问题，但没有做到热备，HDFS恢复服务时，需要重新启动NameNode，恢复时间与文件系统规模成正比。

▪NFS共享的可靠性问题，如果配置的多个目录中有任何一个目录的保存因为异常而阻塞，将会导致整个HDFS的操作阻塞，无法对外提供正常服务。

1.4.2Hadoop的SecondaryNameNode方案

该方案启动一个SecondaryNameNode节点，该节点定期从NameNode节点上下载元数据信息（元数据镜像fsimage和元数据库操作日志edits），然后将fsimage和edits进行合并，生成新的fsimage（该fsimage就是SecondaryNameNode下载时刻的元数据的Checkpoint），在本地保存，并将其推送到NameNode，同时重置NameNode上的edits。

优点

▪Hadoop自带机制，成熟可靠，使用简单方便，无需开发，配置即可。

▪SecondaryaryNameNode定期做Checkpoint，可保证各个Checkpoint阶段的元数据的可靠性，同时，进行fsimage与edits的合并，可以有效限制edits的大小，防止其无限制增长。

缺点

▪没有做到热备，当NameNode无法提供服务时，需要重启NameNode，服务恢复时间与文件系统规模大小成正比。

▪SecondaryNameNode保存的只是Checkpoint时刻的元数据，因此，一旦NameNode上的元数据损坏，通过Checkpoint恢复的元数据并不是HDFS此刻的最新数据，存在一致性问题。

1.4.3Hadoop的CheckpointNode方案

CheckpointNode方案与SecondaryNameNode的原理基本相同，只是实现方式不同。

该方案利用Hadoop的Checkpoint机制进行备份，配置一个CheckpointNode。

该节点会定期从PrimaryNameNode中下载元数据信息（fsimage+edits），将edits与fsimage进行合并，在本地形成最新的Checkpoint，并上传到PrimaryNameNode进行更新。

当NameNode发生故障时，极端情况下（NameNode彻底无法恢复），可以在备用节点上启动一个NameNode，读取Checkpoint信息，提供服务。

优点

▪使用简单方便、无需开发、配置即可。

▪元数据有多个备份。

缺点

▪没有做到热备、备份节点切换时间长。

▪CheckpointNode所做的备份，只是最后一次Check时的元数据信息，并不是发生故障时最新的元数据信息，有可能造成数据的不一致。

1.4.4Hadoop的BackupNode方案

利用新版本Hadoop自身的Failover措施，配置一个BackupNode，BackupNode在内存和本地磁盘均保存了HDFS系统最新的名字空间元数据信息。

如果NameNode发生故障，可用使用BackupNode中最新的元数据信息。

优点

▪简单方便、无需开发、配置即可使用。

▪BackupNode的内存中对当前最新元数据信息进行了备份（Namespace），避免了通过NFS挂载进行备份所带来的风险。

▪BackupNode可以直接利用内存中的元数据信息进行Checkpoint，保存到本地，与从NameNode下载元数据进行Checkpoint的方式相比效率更高。

▪NameNode会将元数据操作的日志记录同步到BackupNode，BackupNode会将收到的日志记录在内存中更新元数据状态，同时更新磁盘上的edits，只有当两者操作成功，整个操作才成功。

这样即便NameNode上的元数据发生损坏，BackupNode的磁盘上也保存了HDFS最新的元数据，从而保证了一致性。

缺点

▪高版本（0.21以上）才支持。

▪许多特性还处于开发之中，例如：

当NameNode无法工作时，BackupNode目前还无法直接接替NameNode提供服务，因此当前版本的BackupNode还不具有热备功能，也就是说，当NameNode发生故障，目前还只能通过重启NameNode的方式来恢复服务。

▪BackupNode的内存中未保存Block的位置信息，仍然需要等待下面的DataNode进行上报，因此，即便在后续的版本中实现了热备，仍然需要一定的切换时间。

▪当前版本只允许1个BackupNode连接到NameNode。

1.4.5DRDB方案

利用DRDB机制进行元数据备份。

当NameNode发生故障时，可以启动备用机器的NameNode，读取DRDB备份的元数据信息，提供服务。

优点

▪DRDB是一种较为成熟的备份机制。

▪元数据有多个备份、并且保持最新状态。

▪由于备份的工作交由DRDB完成，对于一条新的日志记录，NameNode无需同步写入多个备份目录，因而NameNode在效率上优于Hadoop的元数据备份方案。

缺点

▪没有做到热备、备份节点切换时间长。

▪需要引入新的机制、由此带来一定的可靠性问题。

1.4.6FaceBook的AvatarNode方案

利用FaceBook提出的AvatarNode机制。

ActiveNode作为PrimaryNameNode对外提供服务。

StandbyNode处于Safemode模式，在内存中保存PrimaryNameNode最新的元数据信息。

ActiveNode和StandbyNode通过NFS共享存储进行交互。

DataNode同时向ActiveNode和StandbyNode发送Blocklocation信息。

当管理员确定PrimaryNameNode发生故障后，将StandbyNode切换为PrimaryNameNode。

由于StandbyNode内存中保存了所有元数据的最新信息，因此可直接对外提供服务，大大缩短了切换时间。

优点

▪提供热备、切换时间大大缩短。

▪FaceBook已将其集成到自己维护的Hadoop代码中，并部署到了自己的集群使用。

缺点

▪修改了部分源码、增加了一定的复杂性，并在软件的维护性上带来一定问题。

▪参考资料较少。

▪只提供一个备份节点。

1.5方案优缺点比较

综上所述，HDFSHA方案比较如表1.1所示。

表1.1HDFSHA方案比较

方案名称

切换时间

元数据

一致性

是否做checkpoint

使用复杂度

成熟度