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

1、高可用性的HDFS 清华大学出版社前 言Hadoop是目前主流的开源云计算系统，它实现了一个高可扩展的分布式文件系统HDFS（Hadoop Distributed File System），HDFS作为Hadoop底层基础设施，为云计算提供高可靠、高性能的存储服务。HDFS在很大程度上借鉴了Google GFS文件系统的设计思想，具有高度容错、支持大数据集等诸多特性。这些特性曾让我们欢欣鼓舞，一度以为HDFS是一个可以解决数据密集型应用的海量数据存储难题的完美方案。随着研究的深入，我们在不断叹服HDFS设计构思巧妙的同时，也深深地认识到仅有以上的特性还不足以构建一个实用的分布式文件系统，还需要

2、一些其他特性进行支撑，高可用性则是其中最为关键的一点。高可用性是指系统正常服务时间所占的百分比，它是衡量系统对外正常服务能力的重要指标。对于HDFS来说，每一份数据可以有多个副本，因此文件数据的可靠性可以由副本来解决。然而，对于元数据管理来说，只有一个节点NameNode，它的好坏直接决定了HDFS能否正常服务，因此NameNode的高可用性决定了整个HDFS系统的高可用性。不同应用对HDFS高可用性有不同要求，目前Hadoop自身包括其他一些开源组织提供了一些相应的高可用性机制以满足不同的需要，如Backup Node方案以及AvatarNode方案等。根据我们的实践经验，在使用以上方案解决

3、实际问题时，需要具备以下几点基础： 首先是对NameNode元数据机制有较深的理解和把握； 其次要对各种解决方案的运行机制及使用方法有个全面掌握； 再次就是要有较强的实践操作经验。然而，就现实情况而言，要在以上任何一点取得一点进展都需要付出相当大的努力，回顾我们的团队在接触HDFS的高可用性之初，由于资料和经验的匮乏，每掌握一个知识点，都需经历资料查找、邮件列表搜索、邮件请教、代码查看、实验验证等多个环节，其间的付出可想而知，正是基于这点，我们也深切地感觉有必要将我们前期的经验和心得与大家分享，姑且也算做是我们团队对于开源软件事业的一点小小的回馈吧。本书内容本书一共8章，分为4个部分。其中第1

4、部分为第章，主要介绍当前HDFS主流的HA方案以及相关概念，使读者能够有一个宏观上的认识，同时通过方案的比较，遴选出3种具有代表性的HA方案。第2部分为第2章，围绕HDFS HA的重点关注对象元数据，对内存元数据结构、磁盘元数据文件、文件系统格式化场景以及元数据在HA中的应用场景进行了深入剖析。第3部一共5章（3、4、5、6、7），主要介绍种经典的HA解决方案：Hadoop元数据备份方案、BackupNode方案以及AvatarNode方案，从代码入手，分别从运行机制、使用方法等方面进行说明，每种方案都有详细的使用说明并配以视频，便于读者掌握。第4部分为第8章，介绍目前最新HA解决方案Clou

5、drea HA NameNode。适合读者如果您是一位Hadoop集群管理维护人员，请阅读本书，它将向您展示当前主流的HDFS HA解决方案，通过文字说明和视频展示这些方案的实现机制和操作细节，使您能够在最短的时间内消化和吸收这些技术，您可以根据自己的需要选择和部署实施最合适的HA方案。如果您是一位Hadoop应用开发者，请阅读本书，您将会在此找到如何结合HDFS的HA，编写出更为健壮的应用程序。如果您是一位分布式文件系统研发人员，请阅读本书，它将向您深入剖析HDFS这一最有影响力的开源云计算分布式存储系统的各种HA方案及其实现机制。 如果您是一位云计算技术的爱好者，请阅读本书，本书会从零开始

6、，一步一步地带您掌握云计算相关技术，并加深概念的理解，为您日后深入接触云计算技术打下基础。本书由文艾和王磊共同编著而成。文艾负责总体设计、内容把握以及写作组织，独立完成第1、2、3、8章，并与王磊共同完成第4、5、6、7以及实验的视频设计和制作。感谢中国电子学会云计算专家委员会专家刘鹏教授的大力支持；感谢我的家人，你们是我奋斗前进的最大动力；最后，希望大家从书中找到需要的东西。时间紧，任务急，错误在所难免，敬请各位批评指正。请发送邮件到hdfsha。第1章 HDFS HA及解决方案HDFS（Hadoop Distributed File System）即Hadoop分布式文件系统，它为Hado

7、op这个分布式计算框架提供高性能、高可靠、高可扩展的存储服务。1.1 HDFS系统架构HDFS的系统架构如图1.1所示，它是一个典型的主/从架构，包括一个NameNode节点（主节点）和多个DataNode节点（从节点），并提供应用程序访问接口。NameNode是整个文件系统的管理节点，它负责文件系统名字空间（Namespace）的管理与维护，同时负责客户端文件操作的控制以及具体存储任务的管理与分配；DataNode提供真实文件数据的存储服务。图1.1 HDFS系统架构HDFS有两种数据：文件数据和元数据。1文件数据文件数据是指用户保存在HDFS上的文件的具体内容，HDFS将用户保存的文件按照

8、固定大小（用户可设置，通常是64MB）进行分块（每一块简称为一个Block），保存在各个DataNode上，每一个块可能会有多个副本（Replica），具体个数可以由用户指定（通常是3个），相同块对应的副本通常保存在不同的DataNode上，通过副本机制，可以有效保证文件数据的可靠性。2元数据所谓元数据（Metadata）是指数据的数据，HDFS与传统的文件系统一样，提供了一个分级的文件组织形式，维护这个文件系统所需的信息（除了文件的真实内容）就称之为HDFS的元数据。元数据由NameNode进行维护和管理，NameNode在启动时，会从磁盘加载元数据文件到内存，并且等待Data Node上报

9、其他元数据信息，形成最终的元数据结构。由于NameNode是单节点，一旦NameNode无法正常服务，将导致整个HDFS无法正常服务。1.2 HA定义HA的英文全称是High Availability，中文翻译为高可用性。什么是HA？HA与我们平时常说的高可靠性又有什么关系，下面我们一起来看下HA的定义。HA的定义为系统对外正常提供服务时间的百分比。具体来说，HDFS的可靠性可用平均无故障时间（MTTF）来度量，即HDFS正常服务的平均运行时间，HDFS的可维护性用平均维修时间（MTTR2）来度量，即HDFS从不能正常服务到重新正常服务所需要的平均维修时间。因此HDFS的HA可精确定义为：MT

10、TF/(MTTF+MTTR) * 100%由上面的定义我们可以很清楚地将HA与高可靠性区分开来，高可靠性更多的是对于系统自身而言，它是系统可靠程度的一个指标。而HA则更多地是从系统对外的角度来说的，除了包含系统正常工作的能力，它还强调系统中止服务后迅速恢复的能力：一个可靠性很高的系统，如果其中止服务后，修复时间很长，那么它的可用性也不会很高，而一个可靠性不是特别高的系统，如果发生中止服务后，可迅速恢复，那么其可用性也可能会很高。因此只有HA才能准确度量系统对外正常服务的能力。HDFS HA的应用场景有很多，我们可以从正常和异常两种情况来分析HDFS对外无法正常服务的情景： 首先是正常使用情况，

11、最常见的应用场景就是NameNode节点软、硬件的升级与维护，由于NameNode只有一个，当NameNode节点软、硬件的升级与维护操作需要NameNode进行重启时，HDFS将无法服务。 其次是异常情况，常见的场景有：用户的误操作导致NameNode系统崩溃或HDFS发生故障、或者是硬件故障等。在实际使用过程中，软硬件维护、软件故障、错误操作等因素是造成HDFS无法提供正常服务的主要原因，而大家普遍关注的硬件故障并不是主要原因。雅虎的数据表明：在雅虎运行的15个集群中，三年时间内，只有3次NameNode的故障与硬件问题有关。此外，由于HDFS处于Hadoop的底层，上层的其他分布式处理框

12、架如Mapreduce、HBase、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不能对外正常服务，因此

13、NameNode的可靠性是影响HDFS可靠性的重要因素。由于NameNode只有一个，它的正常运行与否直接决定了HDFS能否正常服务，因此它也就成为了HDFS系统的一个单一故障点（single point of failure SPOF），DataNode负责存储真实文件数据，每个文件可以指定副本个数，因此同一个文件可在多个DataNode上进行存储，当有DataNode发生故障时，客户端可以访问其他DataNode上的副本，因此DataNode发生故障并不会影响HDFS对外正常服务。1.3.2 可维护性当NameNode不能正常服务时，通常需要重新启动NameNode来恢复服务，NameNo

14、de启动时需要加载磁盘上的元数据文件：如果此时元数据没有损坏，那么直接启动NameNode就可以恢复HDFS对外正常服务；如果元数据损坏，将导致NameNode无法启动，无法再对外正常服务，也就是说平均维护时间是无限大。因此元数据的可靠性决定了HDFS的可维护时间。当DataNode无法正常工作时，HDFS会自动启动该DataNode上所有数据的复制任务，将丢失的数据重新分布到其他DataNode上，因此DataNode并不影响HDFS的可维护性。综上所述，HDFS的HA主要由NameNode的HA决定，NameNode的可靠性主要取决于自身计算机硬件系统的可靠性、系统软件以及HDFS软件的可

15、靠性；NameNode的可维护性则取决于元数据的可靠性以及NameNode服务恢复时间。1.4 现有HDFS HA解决方案HDFS的HA的解决方案，主要是从使用者的角度出发，提高元数据的可靠性，减少NameNode服务恢复时间。提高元数据的可靠性措施主要是对元数据进行备份，HDFS自身就具有多种机制来确保元数据的可靠性。减少NameNode服务恢复时间的措施有两种思路： 第1种基于NameNode重启恢复服务的方式，对NameNode自身的启动过程进行分析，优化加载过程，减少启动时间； 第2种则是启动一个NameNode的热备（Warm standby）节点，当主节点不能正常服务时，由热备节点

16、进行接替，此时主备切换时间成为服务恢复时间。从效率上分析，第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可以将

17、元数据信息保存到多个目录。通常的做法，选择一个本地目录、一个远程目录（通过NFS进行共享），当NameNode发生故障时，可以启动备用机器的NameNode，加载远程目录中的元数据信息，提供服务。优点 Hadoop自带机制，成熟可靠，使用简单方便，无需开发，配置即可。 元数据有多个备份，可有效保证元数据的可靠性，并且内容保持最新状态。 元数据需要同步写入多个备份目录，效率低于单个NameNode。缺点 该方案主要是解决元数据保存的可靠性问题，但没有做到热备，HDFS恢复服务时，需要重新启动NameNode，恢复时间与文件系统规模成正比。 NFS共享的可靠性问题，如果配置的多个目录中有任何一个目

18、录的保存因为异常而阻塞，将会导致整个HDFS的操作阻塞，无法对外提供正常服务。1.4.2 Hadoop的Secondary NameNode方案该方案启动一个Secondary NameNode节点，该节点定期从NameNode节点上下载元数据信息（元数据镜像fsimage 和元数据库操作日志edits），然后将fsimage和edits进行合并，生成新的fsimage（该fsimage就是Secondary NameNode下载时刻的元数据的Checkpoint），在本地保存，并将其推送到NameNode，同时重置NameNode上的edits。优点 Hadoop自带机制，成熟可靠，使用简单

19、方便，无需开发，配置即可。 Secondaryary NameNode定期做Checkpoint，可保证各个Checkpoint阶段的元数据的可靠性，同时，进行fsimage与edits的合并，可以有效限制edits的大小，防止其无限制增长。缺点 没有做到热备，当NameNode无法提供服务时，需要重启NameNode，服务恢复时间与文件系统规模大小成正比。 Secondary NameNode保存的只是Checkpoint时刻的元数据，因此，一旦NameNode上的元数据损坏，通过Checkpoint恢复的元数据并不是HDFS此刻的最新数据，存在一致性问题。1.4.3 Hadoop的Chec

20、kpoint Node方案Checkpoint Node方案与Secondary NameNode的原理基本相同，只是实现方式不同。该方案利用Hadoop的Checkpoint机制进行备份，配置一个Checkpoint Node。该节点会定期从Primary NameNode中下载元数据信息（fsimage+edits），将edits与fsimage进行合并，在本地形成最新的Checkpoint，并上传到Primary NameNode进行更新。当NameNode发生故障时，极端情况下（NameNode彻底无法恢复），可以在备用节点上启动一个NameNode，读取Checkpoint信息，提供

21、服务。优点 使用简单方便、无需开发、配置即可。 元数据有多个备份。缺点 没有做到热备、备份节点切换时间长。 Checkpoint Node所做的备份，只是最后一次Check时的元数据信息，并不是发生故障时最新的元数据信息，有可能造成数据的不一致。1.4.4 Hadoop的Backup Node方案利用新版本Hadoop自身的Failover措施，配置一个Backup Node，Backup Node在内存和本地磁盘均保存了HDFS系统最新的名字空间元数据信息。如果NameNode发生故障，可用使用Backup Node中最新的元数据信息。优点 简单方便、无需开发、配置即可使用。 Backup

22、Node的内存中对当前最新元数据信息进行了备份（Namespace），避免了通过NFS挂载进行备份所带来的风险。 Backup Node可以直接利用内存中的元数据信息进行Checkpoint，保存到本地，与从NameNode下载元数据进行Checkpoint的方式相比效率更高。 NameNode 会将元数据操作的日志记录同步到Backup Node，Backup Node会将收到的日志记录在内存中更新元数据状态，同时更新磁盘上的edits，只有当两者操作成功，整个操作才成功。这样即便NameNode上的元数据发生损坏，Backup Node的磁盘上也保存了HDFS最新的元数据，从而保证了一致性

23、。缺点 高版本（0.21以上）才支持。 许多特性还处于开发之中，例如：当NameNode无法工作时，Backup Node目前还无法直接接替NameNode提供服务，因此当前版本的Backup Node还不具有热备功能，也就是说，当NameNode发生故障，目前还只能通过重启NameNode的方式来恢复服务。 Backup Node的内存中未保存Block的位置信息，仍然需要等待下面的DataNode进行上报，因此，即便在后续的版本中实现了热备，仍然需要一定的切换时间。 当前版本只允许1个Backup Node连接到NameNode。1.4.5 DRDB方案利用DRDB机制进行元数据备份。当N

24、ameNode发生故障时，可以启动备用机器的NameNode，读取DRDB备份的元数据信息，提供服务。优点 DRDB是一种较为成熟的备份机制。 元数据有多个备份、并且保持最新状态。 由于备份的工作交由DRDB完成，对于一条新的日志记录，NameNode无需同步写入多个备份目录，因而NameNode在效率上优于Hadoop的元数据备份方案。缺点 没有做到热备、备份节点切换时间长。 需要引入新的机制、由此带来一定的可靠性问题。1.4.6 FaceBook的AvatarNode方案利用FaceBook提出的Avatar Node机制。Active Node作为Primary NameNode对外提供

25、服务。Standby Node处于Safe mode模式，在内存中保存Primary NameNode最新的元数据信息。Active Node和Standby Node通过NFS共享存储进行交互。DataNode同时向Active Node和Standby Node发送Block location信息。当管理员确定Primary NameNode发生故障后，将Standby Node切换为Primary NameNode。由于Standby Node内存中保存了所有元数据的最新信息，因此可直接对外提供服务，大大缩短了切换时间。优点 提供热备、切换时间大大缩短。 FaceBook已将其集成到自己

26、维护的Hadoop代码中，并部署到了自己的集群使用。缺点 修改了部分源码、增加了一定的复杂性，并在软件的维护性上带来一定问题。 参考资料较少。 只提供一个备份节点。1.5 方案优缺点比较综上所述，HDFS HA方案比较如表1.1所示。表1.1 HDFS HA方案比较方案名称切换时间元数据一致性是否做checkpoint使用复杂度成熟度相关资料元数据备份长一致否低高较多Secondary NameNode长不一定是中高较多Checkpoint Node长不一定是中高较少Backup Node中一致是中中较少DRDB长一致否高高多AvatarNode短一致是高高少其中“元数据备份方案”不能单独使用

27、，因为在系统运行期间，没有相应的Checkpoint机制，会造成日志的无限制增长，因此需要和Secondary NameNode、Checkpoint Node或Backup Node配合使用。“DRDB方案”同样如此。而对于Secondary NameNode、Checkpoint Node机制，它们只有Checkpoint的功能，而不能保存实时的元数据，因此需要在Namenode上配置元数据备份路径来保存实时元数据。对于Backup Node，虽然它可以实时保存元数据，但为防止Backup Node成为一个单点，也需要在NameNode上配置元数据备份路径，保存在本地进行备份。总结 元数据

28、备份方案使用简单方便，在功能上可替代DRDB； Backup Node是 Checkpoint Node的升级版，效率更高； Secondary NameNode在低版本的Hadoop中就已存在。因此用户实际上可选择的HA组合方案为： （1）元数据备份+ Secondary NameNode这种方案适用于目前Hadoop 的所有版本，属于冷备，切换时间长。由于Secondary NameNode自身并不实时保存元数据，一旦NameNode上的元数据损坏，将无法恢复到最新的元数据，因此采用元数据备份机制，在NameNode上需要配置多个目录进行备份，常见的做法是再配置一个NFS节点，共享一个目录

29、进行备份。（2）元数据备份+ Backup Node这种方案只有在0.21.0以上版本才支持，目前的实现只支持冷备，切换时间长，自身实时保存元数据，不需要NFS节点。（3）元数据备份+ AvatarNode这种方案需要打Patch（补丁包），而且只支持特定的版本（0.20）或者使用FaceBook自身的Hadoop版本，切换时间短，需要一个NFS节点作为Active节点和Standby节点的数据交互节点。总之，如果当前Hadoop的版本较低，同时也不允许升级版本的话，可以选择第1种方案；如果版本较新（在0.21.0以上），第2种方案优于第1种；如果对HA切换时间有严格要求的话，则需要选择第3种

30、方案。第1种方案比较简单，资料较多，本书将不再说明，后面着重讲述第2种和第3种方案。第2章 HDFS元数据解析前面已经说过，HDFS中的HA主要解决NameNode的HA，NameNode的HA最重要的目的就是维护元数据的高可用性，因此，有必要对HDFS的元数据进行深入了解。2.1 概 述所谓元数据1（Metadata）就是指数据的数据。HDFS的元数据就是指维护HDFS文件系统中的文件和目录所需要的信息。需要注意的是，具体的文件内容不是元数据，元数据是用于描述和组织具体的文件内容，如果没有元数据，具体的文件内容将变得没有意义。元数据的作用十分重要，它的可用性直接决定了HDFS的可用性。从形式

31、上讲，元数据可分为内存元数据和元数据文件两种。其中NameNode在内存中维护整个文件系统的元数据镜像，用于HDFS的管理；元数据文件则用于持久化存储。从类型上讲，元数据有三类重要信息： 第1类是文件和目录自身的属性信息，例如文件名、目录名、父目录信息、文件大小、创建时间、修改时间等； 第2类记录文件内容存储相关信息，例如文件分块情况、副本个数、每个副本所在的Data Node信息等； 第3类用来记录HDFS中所有Data Node的信息，用于Data Node管理。从来源上讲，元数据主要来源于NameNode磁盘上的元数据文件（它包括元数据镜像fsimage和元数据操作日志edits两个文件）以及各个Data Node的上报信息。下面我们结合源码进行分析，源码的版本为0.21.0。 2.2 内存元数据结构从HDFS自身实现的角度来看，文件和目录是文件系统的基本元素，HDFS将这些元素抽象成INode，每一个文件或目录都对应一个唯一的INode，INode存储了名字信息（分别对应文件或目录的名字）同时还存储了创建时间、修改时间、