CN104461865A - 云环境下分布式文件系统可靠性测试套件 - Google Patents

Abstract

云环境下分布式文件系统可靠性测试套件，涉及云计算领域。本发明是为了解决现有的分布式系统中缺少对分布式文件系统可靠性测试的套件，不能对分布式系统中出现的问题提前做准备，使得系统可靠性低的问题。本发明所述的管理模块用于根据测试人员的操作命令调用相应的节点故障注入模块、数据操作失效故障注入模块和数据效验故障注入模块，并收集节点故障注入模块、数据操作失效故障注入模块和数据效验故障注入模块的故障注入结果通过用户主界面反馈给测试人员，用户主界面用于处在测试人员和管理模块之间，提供人机交互界面、接收使用者命令和反馈故障注入结果。它可用于云环境下分布式文件系统的故障注入。

Description

云环境下分布式文件系统可靠性测试套件

技术领域

本发明涉及云环境下分布式文件系统测试套件。属于云计算领域。 

背景技术

随着云计算技术的不断发展和普及，云存储的概念也应运而生，而分布式文件系统是云存储的核心基础，承载着数据存储的重任。另外一方面，随着社会信息化程度的提高，对于信息和数据的依赖性也越来越大，也就是说数据的可靠性越来越重要。而容错能力是衡量一个系统可靠性的重要标准，系统的容错能力越强，所能提供的服务也就越可靠。因此，对云环境下分布式文件系统的容错能力进行评测具有重要的研究意义。 

基于对HDFS(Hadoop Distributed File System)和TFS(Taobao File System)这两种典型的云环境下分布式文件系统的体系架构、读写流程和内部的容错机制进行深入的研究，通过对比它们的相同点，提出了一套云环境下分布式文件系统容错能力测试方法，设计并实现了一套故障注入工具，分别针对云环境下分布式文件系统的节点和进程、文件和目录、数据校验机制、内部互联的网络进行故障注入，模拟现实应用中可能出现的各种类型的故障。 

发明内容

本发明是为了解决现有的分布式系统中缺少对分布式文件系统可靠性测试的套件，不能对分布式系统中出现的问题提前做准备，使得系统可靠性低的问题。现提供云环境下分布式文件系统可靠性测试套件。 

云环境下分布式文件系统可靠性测试套件，它还包括节点故障注入模块、数据操作失效故障注入模块、数据效验故障注入模块、管理模块和用户主界面， 

所述节点故障注入模块用于模拟节点出现的CPU寄存器故障，并根据管理模块的命令将故障注入分布式文件系统中，同时采集节点出现的CPU寄存器故障注入结果 

数据操作失效故障注入模块用于模拟各种类型的节点的关键文件出现数据操作失败故障，并根据管理模块的命令将故障注入分布式文件系统中，同时采集各种类型的节点的关键文件出现数据操作失败故障注入结果， 

数据效验故障注入模块用于模拟各种不同类型节点的校验文件无法访问、校验内容错误的故障，并根据管理模块的命令将故障注入分布式文件系统中，同时采集各种不同类型节点的校验文件无法访问、校验内容错误的故障注入结果， 

管理模块用于根据测试人员的操作命令调用相应的故障注入模块，并接收相应故障注入模块的故障注入结果通过用户主界面反馈给测试人员， 

用户主界面用于提供人机交互界面、接收使用者命令和反馈故障注入结果。 

本发明的有益效果为：本发明根据使用者的操作命令调用节点故障注入模块、数据操作失效故障注入模块和数据效验故障注入模块，并收集节点故障注入模块、数据操作失效故障注入模块和数据效验故障注入模块的故障注入结果通过用户主界面反馈给使用者，为分布式文件系统中可能出现的问题做准备，保证了系统的可靠性。 

附图说明

图1为具体实施方式一所述的云环境下分布式文件系统可靠性测试套件的总体结构图， 

图2为具体实施方式二所述的基于内核态的寄存器软件故障注入工具结构图， 

图3为Kprobe内核调试机制工作原理图， 

图4为基于内核态的寄存器软件故障注入流程图， 

图5为HDFS文件操作失效故障注入原理图， 

图6为数据操作失效故障注入工具流程图， 

图7为Hadoop故障注入框架整体结构图， 

图8为校验文件异常故障注入流程图， 

图9为HDFS工作原理图， 

图10为TFS体系架构图， 

图11为TFS读数据流程图。 

具体实施方式

具体实施方式一：参照图1具体说明本实施方式，本实施方式所述的云环境下分布式文件系统可靠性测试套件，它包括分布式文件系统，分布式式文件系统包括HDFS分布式文件系统和TFS分布式文件系统，其特征在于，它还包括节点故障注入模块1、数据操作失效故障注入模块2、数据效验故障注入模块3、管理模块4和用户主界面5， 

所述节点故障注入模块1用于模拟节点出现的CPU寄存器故障，并根据管理模块4的命令将故障注入分布式文件系统中，同时采集节点出现的CPU寄存器故障注入结果 

数据操作失效故障注入模块2用于模拟各种类型的节点的关键文件出现数据操作失败故障，并根据管理模块4的命令将故障注入分布式文件系统中，同时采集各种类型的节点的关键文件出现数据操作失败故障注入结果， 

数据效验故障注入模块3用于模拟各种不同类型节点的校验文件无法访问、校验内容错误 的故障，并根据管理模块4的命令将故障注入分布式文件系统中，同时采集各种不同类型节点的校验文件无法访问、校验内容错误的故障注入结果， 

管理模块4用于根据测试人员的操作命令调用相应的故障注入模块，并接收相应故障注入模块的故障注入结果通过用户主界面反馈给测试人员， 

用户主界面5用于提供人机交互界面、接收使用者命令和反馈故障注入结果。 

本实施方式中，节点失效故障可能是由系统断电、硬件故障、软件错误等多种原因造成的，进程失效故障多是由于数据流、控制流错误等引起的。而对于这两种实际应用中具有代表性的故障，均可由系统内的CPU寄存器内容错误直接引发。 

具体实施方式二：参照图2具体说明本实施方式，本实施方式是对具体实施方式一所述的云环境下分布式文件系统可靠性测试套件作进一步说明，本实施方式中，节点故障注入模块1包括信息交互模块1-1、故障信息配置模块1-2、故障注入模块1-3、故障触发模块(1-4)和故障结果回收模块1-5， 

所述信息交互模块1-1用于实现与管理模块4的信息交互，信息交互模块1-1接收管理模块4发送的用户配置参数，然后发送给故障信息配置模块1-2，同时还将故障结果回收模块1-5接收的故障结果发送给管理模块4， 

故障信息配置模块1-2用于解析从交互模块接收的用户配置参数，并将所述用户配置参数发送给故障触发模块1-4，同时根据所述用户配置参数设定相应的故障注入参数，然后将设定的故障注入参数传送给故障注入模块1-3； 

故障注入模块1-3用于接收故障注入参数，并根所述故障注入参数完成相应的故障注入操作； 

故障触发模块1-4用于根据用户配置参数检测时钟中断信号，当所述时钟中断信号满足用户设定的故障触发条件时，则触发故障注入模块进行故障注入； 

故障结果回收模块1-5用于采集被注入故障的分布式平台所产生的故障注入结果，并将结果以内核日志的方式保存到交互模块1-1中的系统日志文件系统中。 

本实施方式中，节点和进程故障注入工具的实现：基于内核态的寄存器故障注入工具实现的节点和进程故障注入工具中的故障信息数据结构： 

其中，target_pid定义了故障注入的目标进程；fault_location定义了故障注入的位置集合；fault_type定义了故障注入的类型；fault_interval定义了故障触发经过的整数倍数的时钟中断请求；fault_inject_control定义了故障注入的控制标志，包括：“START”、“STOP”和“CLEAR”三种控制标识，分别代表了故障注入的开始、停止和清理的操作。 

在基于内核态的寄存器故障注入工具设计与实现时，选用了内核时钟函数do_timer作为探针关联的内核API。利用Kprobe探针注册流程在do_timer处完成探针注册，将自定义的故障注入代码关联到Kprobe的pre_handler处。同时，我们在内核中启动一个守护线程时刻监测故障触发的条件：如果满足触发条件，执行预先定义的故障注入函数；否则，继续进行监测直到满足条件或者退出。 

我们通过大量的实验发现，基于内核态的寄存器故障多会导致目标进程收到异常信号异常终止或者目标系统宕机现象。对于故障注入的结果回收，本文采用了基于信号的结果采集和分析机制。故障注入结果的监控在force_sig_info内核API处关联一个探针。该内核API记录操作系统内核对于出现错误的进程发送异常信号的信息。我们通过这种方式检测故障注入对于目标进程和系统的影响，从而评测目标系统对于此类故障的容错能力。 

基于内核态的寄存器故障注入流程如图4所示： 

1、用户配置故障参数，包括故障注入的目标进程、故障注入位置、故障类型和触发的时钟中断间隔四个部分。 

2、测试人员通过proc接口将故障参数传递到内核态的故障注入模块。 

3、故障注入模块完成对于故障的解析，并启动守护线程判断故障触发条件。如果满足故障触发条件，则开始进行故障注入；否则，继续进行等待。 

4、故障注入模块查找内核态进程列表，找到故障参数指定的目标进程，获取对应的pt_regs寄存器内核堆栈信息结构体。 

5、故障注入模块根据配置的故障类型，向pt_regs中注入相应类型的故障，并将该结构体内容恢复到目标进程中。 

6、恢复目标系统的继续运行，完成故障注入操作。 

HDFS节点级故障注入类型包括：NameNode节点故障、Secondary NameNode节点故障、DataNode节点故障。 

HDFS在启动过程中，会在不同类型的节点分别启动一个主java进程，使用jps命令可以查看的到。因此，进程级故障注入包括：NameNode节点上的NameNode进程故障、Secondary  NameNode节点上的Secondary NameNode进程故障、DataNode上的DataNode进程故障。 

节点进程级故障注入工具能够模拟HDFS出现的各种类型的节点宕机故障以及HDFS的各节点java主进程失效故障。 

研究HDFS对于节点和进程失效故障的容错能力，单纯依靠故障注入并不能有效地得出结果。在真实的测试过程中，我们结合Hadoop性能基准测试程序—HiBench，研究故障注入前后HDFS读写性能下降情况，评测HDFS平台针对节点和进程失效故障的容错能力。 

具体实施方式三：本实施方式是对具体实施方式一所述的云环境下分布式文件系统可靠性测试套件作进一步说明，本实施方式中，数据操作失效故障注入模块2包括分布式文件系统故障参数配置模块、控制模块、故障注入模块、监控模块和结果回收模块， 

分布式文件系统故障参数配置模块用于根据管理模块4的命令设定分布式文件系统故障注入参数，故障注入参数包括故障注入的目标节点、目标文件位置、故障类型和故障类型的相关参数； 

控制模块用于完成接收分布式文件系统故障数配置模块和监控模块的信息，控制故障注入模块向分布式文件系统中注入相应的数据操作故障的功能； 

故障注入模块用于接收控制模块传递的信息，从故障库中选取对应的故障类型进行注入； 

监控模块用于检测分布式文件系统的日志信息，将检测的分布式文件系统的日志信息提交 

给控制模块； 

结果回收模块用于收集分布式文件系统故障条件下的测试结果，并将结果提交给管理模块4。 

本实施方式中，数据操作失效故障注入模块2的目标是做到能够对系统中指定目标节点指定目标文件注入指定类型的数据操作失效故障。该故障注入工具能够实现的故障集定义如下表所示。 

表3-1 Hadoop数据操作失效故障注入位置 

故障注入工具实现的故障类型定义如下表所示。 

表3-2 文件操作失效故障类型 

本文向HDFS各种类型节点中的关键文件注入常见的数据操作失效故障，将故障注入的文件位置与文件操作异常类型进行笛卡尔积组合，构造大量的数据操作失效类型。 

Hadoop会将需要存储的数据分割成多个小的块数据文件并分别存储在HDFS中的不同数据节点中，数据节点中的块数据存储最终依然是依赖于数据节点的本地文件系统。在本地文件系统的存储过程中，多是依赖于类Unix操作系统下的本地文件系统。 

数据操作失效故障注入原理：类Unix操作系统引入了一种通用统一的文件系统模型--VFS(Virtual File System)。VFS是一种位于具体的文件系统之上的抽象层次。如图5所示，本文提出了在本地文件系统的VFS文件系统层进行故障注入的方法，不依赖于具体的文件系统结构，又可以很好地覆盖文件操作异常类故障，具有很强的通用性和可移植性。 

每种具体的文件系统都有自己的文件操作函数。文件系统的索引节点、目录项、文件对象分别包含一个函数跳转表，对应于struct file_operations、struct inode_operations和struct dentry_operations三个结构体之中，构成了VFS层的界面。这三个结构体在具体的文件系统创建目录项、文件对象和索引节点的时候初始化，与具体文件系统的操作函数相关联。文件操作从VFS层通过这三个函数跳转表将文件操作执行流程转发到具体的文件系统进行操作。 

本文在本地文件系统的VFS文件系统层注入故障能够直接地影响到对HDFS中数据的操作。在VFS层截获与本地文件系统相关的文件操作，将其修改成故障库中对应的文件操作异常类型，然后将文件操作转发到下层具体的文件系统运行并获取返回结果。 

数据操作失效故障注入工具的实现：数据操作失效故障注入工具采用基于VFS层的文件操作跳转表修改的方法实现故障注入操作。本工具实现中用到的主要数据结构包括： 

故障配置参数的数据结构struct FAULT_CONFIG如表3-3所示。 

故障注入命令类型包括：START_FAULT(注入故障)、STOP_FAULT(停止注入)和CLEAR_FAULT(清除故障)。 

表3-3 故障配置参数结构字段 

故障触发信息的数据结构struct FAULT_INFO如表3-4所示，故障触发信息包含触发故障的故障名称、故障类型、故障位置、延迟时间。 

表3-4 故障触发信息结构字段 

为了方便测试人员控制故障注入流程，通过proc文件系统将故障配置信息和控制信息传递到内核空间中，从而在用户空间上实现对故障注入过程的控制和管理。 

为了分析HDFS对于数据操作失效故障的处理能力，在对HDFS进行读写操作时，使用故障注入的手段注入数据操作失效故障，模拟故障发生时HDFS对于数据操作故障的容错处理能力。 

具体实施方式四：本实施方式是对具体实施方式一所述的云环境下分布式文件系统可靠性测试套件作进一步说明，本实施方式中，数据效验故障注入模块包括校验文件的异常故障注入模块和校验值异常的故障注入模块， 

数据效验故障注入模块包括校验文件的异常故障注入模块和校验值异常的故障注入模块， 

校验文件的异常故障注入模块用于根据管理模块4的命令选定的故障注入的校验文件，对校验文件进行位置移动、文件权限修改和文件内容修改操作，模拟分布式文件系统中的校验文件由于某些原因造成校验文件无法访问或校验内容错误故障， 

校验值异常的故障注入模块用于根据校验值计算对应的API处插入故障代码，当满足故障触发条件时，对相关API应用程序编程接口计算返回的校验值进行数据位翻转，从而构造错误的校验值模拟故障的发生，将校验值模拟故障注入结果给管理模块4。 

本实施方式中，Hadoop在进行数据完整性校验时，会将校验结果以文件形式保存到系统中。在对HDFS中的数据进行操作时，无论是读操作还是写操作均需要对数据进行完 整性校验。根据Hadoop数据存储的这一特性，我们设计了数据校验故障注入工具，针对Hadoop数据校验操作进行故障注入测试。数据校验故障集定义如表3-5所示。 

表3-5数据校验故障集定义 

基于Hadoop-FI接口的故障注入是Hadoop官方提供的故障注入框架。Hadoop故障注入框架的基础奠定在AspectJ实现的交叉概念之上。它的整体结构如图7所示。 

Hadoop故障注入框架是通过在Hadoop源代码中插入探针的方式来进行故障注入。在特定的Hadoop API被调用时，它将通过故障发生可能性模型判断是否满足故障发生条件。若满足故障触发条件，进行故障注入；否则，进行正常操作。根据Hadoop故障注入框架中AspectJ提供的接口，该故障注入工具可以进行的故障注入位置如下表所示。 

表3-6 Hadoop内部实现的探针位置列表 

本项测试通过修改相关的校验文件以及在HDFS中与校验和计算相关的API处插入探针两种方式来模拟故障的发生，在故障触发时插入相关的故障代码，从而实现针对HDFS数据校验的故障注入。 

针对Hadoop校验文件的异常故障注入流程如图8所示。 

Hadoop平台在众多的关键点进行校验和计算来保证数据的完整性。HDFS文件系统为固定大小的字节块进行校验和计算，大小可以通过io.bytes.per.checksum进行设定，系统默认是512bytes。DataNode负责在存储数据和数据的校验和之前校验数据。当客户端读取数据的时候同样也要验证校验值。DataNode后台也将周期性地验证块数据文件和它对应的校验和文件的一致性。Hadoop在诸如此类情况下都将进行数据校验的校验， 但它们依赖的技术手段都是Hadoop中的DataChecksum类。DataChecksum中与校验值计算相关的API主要有以下几个： 

●newDataChecksum()：创建一个新的DataChecksum 

●writeHeader()：将checksum header写到输出流 

●getHeader()：将checksum header存到一个byte数组中，并返回 

●writeValue()：将checksum计算结果写到输出流或缓冲区中 

●getValue()：返回checksum计算结果 

●reset()：重置checksum 

●update()：更新checksum 

针对校验值异常的故障注入利用了Hadoop提供的故障注入框架，通过在Hadoop源代码中插入故障代码的手段实现故障注入。具体来说，本工具是在Hadoop的校验值计算相关的以上几个API处插入故障代码，当满足故障触发条件时，对相关API计算返回的校验值进行数据位翻转，从而构造错误的校验值模拟故障的发生。在实际的测试中，需要结合相应的HDFS工作负载来触发故障，检测故障注入后HDFS的反映结果，评测HDFS对于校验错误故障的容错能力。 

具体实施方式五：本实施方式是对具体实施方式一所述的云环境下分布式文件系统可靠性测试套件作进一步说明，本实施方式中，节点故障注入模块1用于模拟分布式文件系统中节点出现的CPU寄存器故障导致的应用进程失效或者节点整体宕机的故障情况的过程为： 

在系统时钟中断发生时修改Hadoop平台相关进程的当前寄存器状态的方法进行故障注入，使用时钟中断作为故障注入触发的条件，当设定的整数倍的时钟中断请求发生时，通过在内核态修改Hadoop平台相关进程寄存器内容映射在内存中的镜像来对寄存器硬件故障进行模拟，当中断请求返回时，操作系统内核在恢复进程上下文现场时，将改写的内核堆栈寄存器内容恢复给Hadoop平台相关进程，从而实现寄存器故障的注入。 

本实施方式中，类Unix操作系统中提供了一种简单而强大的内核调试工具—Kprobe。Kropbe允许测试人员能够不对操作系统源代码进行修改，而以动态内核模块加载的方式自由灵活地对内核态的API进行跟踪和调试。如图3所示，它提供了一种探针机制，开发人员可以指定一个内核API作为跟踪目标。Kprobe能够将开发人员编写的自定义函数关联到指定的内核API处。当操作系统的该内核API被调用时，将会优先执行该内核API所关联的探针函数，然后才会进行正常的内核API处理执行流程。 

基于内核态的寄存器软件故障注入工具是基于Kprobe内核调试模块的寄存器内容修改技术实现的，通过对不同类型的进程进行故障注入操作，可以有效地模拟Hadoop平台现实应用中出现的应用进程失效和节点整体宕机故障类型。基于内核态的寄存器软件故障注入通过在时钟中断的内核响应函数处插入故障代码来完成相应的故障注入操作。在故障注入测试时，可以 设定任意整数倍的时钟节拍作为触发条件。 

本实施方式中，数据操作故障注入工具的工作流程为： 

步骤一、加载故障注入工具的内核模块，并对相关参数进行初始化； 

步骤二、配置故障注入参数，； 

步骤三、按照步骤二配置的故障信息，从故障库选择对应的故障类型，针对指定的位置进行故障注入并启动分布式文件系统工作负载； 

步骤四、内核监控模块监控VFS层文件操作跳转表，在满足故障注入触发条件时，触发步骤三注入的故障； 

步骤五、重复执行步骤四直到分布式文件系统工作负载运行结束，结果回收模块收集工作负载的测试结果，并进行具体的结果分析。 

具体实施方式五：本实施方式是对具体实施方式一所述的云环境下分布式文件系统可靠性测试套件作进一步说明，本实施方式中，节点故障注入模块1用于模拟分布式文件系统中节点整体宕机故障的过程为： 

对系统关键进程进行故障注入操作，导致操作系统崩溃，从而导致计算系统的不可用，这种故障类型能够模拟Hadoop平台集群中节点宕机故障的发生，达到节点失效故障注入的目的。 

本发明中，分布式文件系统简介： 

HDFS分布式文件系统 

HDFS是Hadoop自己实现的分布式文件系统(Hadoop Distributed File System)，是Google分布式文件系统GFS的开源实现。HDFS设计的初衷是基于廉价的硬件集群环境，创建一种使用流式数据访问方式进行存储的分布式文件系统。它具备目前已经存在的分布式文件系统的众多特点。与此同时，它在架构设计和实现上与这些文件系统又存在着巨大的差异。Hadoop分布式文件系统在设计之初，就定位到具有高容错能力，认定集群中单个节点故障是常发事件而不是一个偶发事件。HDFS部署在廉价的集群中，必然面临这样的问题。因此，有效的故障检测机制和自动化迅速的恢复机制将变得至关重要。在保证高可靠性的前提下，还要保证文件系统的高吞吐量的数据访问性能，流式数据访问有效地解决了这一问题，满足部署在集群环境中的各项条件。HDFS是由一组具有特定功能的不同类型的节点构成的，HDFS工作原理图如图9所示。这些节点包括一个NameNode，一个Secondary NameNode以及大量的DataNode所组成的。 

HDFS中各个不同类型节点的基本功能如下所述： 

1.HDFS：Hadoop Distributed File System，Hadoop分布式文件系统 

2.Rack：机架 

3.Client：客户端 

4.NameNode：名字节点 

5.Secondary NameNode：从名字节点 

6.DataNode：数据节点 

7.FSImage：存储硬盘元数据检查点的文件 

8.EditLog：存储每个文件操作的文件 

9.ReadRequest：读请求 

WriteRequest：写请求 

●NameNode 

NameNode是整个HDFS的元数据节点，HDFS中所有文件的元数据信息都保存在NameNode的某个特定的目录下。同时，它还管理着文件系统的名称空间，调节和控制外部用户的访问情况。FSImage和EditLog是NameNode中最重要的两个系统文件，分别存储着HDFS命名空间的基本信息以及执行操作的日志文件。NameNode中还存在块数据文件与其所在DataNode的对应存储关系的映射文件。 

●Secondary NameNode(从名字节点) 

Secondary NameNode是整个HDFS的从元数据节点，但它和NameNode并不是一种互备的节点关系。它不能替代NameNode作为HDFS的元数据节点提供服务，而仅仅是定期地保存从NameNode备份的FSImage和EditLog文件到自身的一个临时目录下。目的是为了能够在NameNode上的元数据发生损坏时，能够通过从元数据节点的备份数据快速地恢复数据节点的运行。 

●DataNode 

DataNode是整个HDFS的数据节点，在一个集群中可能具有众多的数据节点用于数据的存储。DataNode将HDFS分割分配的块数据文件保存到本地的文件系统。同时，DataNode还会周期性地检测块数据校验一致性并通过心跳信息向NameNode发送其上存储的块数据的信息，方便主节点对于整个数据节点的块数据的管理和多副本存储的保证。 

1.2 HDFS的容错机制分析 

HDFS设计实现了多种有效的容错机制来保证文件系统的可用性，主要包括以下几个方面。 

1.2.1心跳检测恢复机制 

HDFS中的节点类型可以分为NameNode、Secondary NameNode和DataNode三种。为了保证HDFS的稳定运行，HDFS采用了心跳检测的机制来定期进行DataNode在线情况检测。在HDFS运行过程中，每个DataNode会周期性地向NameNode发送心跳信号。当由于节点失效、进程失 效、网络故障等原因造成DataNode不可用时，心跳数据包将会缺失。NameNode在与该DataNode的连接失败时，会采用标记的方式将这样的DataNode标记为宕机状态，并且操作请求不再被发送到它们上进行处理。同时，存储在该数据节点上的块数据副本处于失效状态。这样就会造成某些块数据的副本数量低于设定值。NameNode会不断地检测这样的块数据，一旦检测到这样的块数据存在，会将其他保存完好的块数据副本进行复制，从而保证块数据副本数量。 

在NameNode上保存着整个文件系统的名字空间和文件块数据映射两个重要的元数据文件。如果NameNode出现故障，将导致整个HDFS集群系统瘫痪，因而成为整个HDFS的单节点故障瓶颈。在后来的Hadoop版本中，出现了一种NameNode HA方法来解决NameNode的单节点故障瓶颈。 

Hadoop中的心跳检测恢复机制能够保证HDFS的可靠性。为了验证这种容错机制的有效性，我们有必要设计节点层、进程层和网络层故障注入手段来模拟对应的真实故障的发生对于HDFS运行产生的影响。 

1.2.2 多副本冗余备份机制 

HDFS是一个能够在大规模集群中跨节点地分布式存储大数据的文件系统。其中，每个大文件被分割存储成一系列的块数据。为了容错，每个文件块数据都会保存有副本。其中，块数据大小和副本数量都是可以由用户配置的。 

副本存放是HDFS容错能力的关键。它采用了一种称为机架感知的优化副本存放策略在保证网络带宽利用率的基础上改进数据的可靠性。通过机架感知过程，NameNode确定每一个DataNode所属机架的ID。在大多数情况下，设定HDFS的副本数量是3。它采用的存放策略是将一个副本存放在本地机架的节点上，一个副本存放在同一机架的另外一个节点上，第三个副本保存在不同机架的另一个节点上。由于机架的故障概率远比节点的故障概率低，所以这个策略能够在很大程度上提高数据的容错能力。与此同时，因为数据只存放在两个机架上而不是更多个，减少了数据访问的性能开销。 

在对副本进行操作时，为了降低整体的带宽消耗和读取延迟，HDFS会尽量让客户端操作距离它最近的副本。如果客户端和副本在同一个机架上，那么优先选择本地机架的数据副本；如果是跨越多个数据中心地访问HDFS集群，那么客户端会优先操作与本地数据中心距离最近的副本存储点。 

可以明显地看出，数据多副本冗余备份机制的设计与实现能够有效地保证在DataNode的上由于硬盘扇区故障、操作系统层软件错误等故障导致的存储在该节点上的块数据副本出现失效时，不会影响客户端对该文件整体的访问情况。为了验证容错机制的有效性，有必要设计相应的故障注入手段，模拟块数据副本失效情况发生，观察HDFS的反映结果。 

1.2.3 数据完整性校验机制 

在系统或者软件的设计过程中，一般采用校验和(checksum)的方式来检查数据的完整性。但是，从可靠性角度来讲，它们仅能检查完整性，而不具备修复和容错能力。显然地，校验和的值也是有可能出现错误的。针对Hadoop实现的数据完整性校验错误恢复机制，设计了相应的故障注入手段进行测试。 

为了保证正确性，HDFS在每次进行数据的读写操作前都会进行数据校验。当客户端在HDFS中创建一个新的文件时，会对这个文件分割出来的每个块数据进行校验和计算，并将该校验和结果作为一个独立的隐藏文件保存在块数据文件的同一位置。当客户端需要操作HDFS中存储的文件时，它不仅会得到对应的文件内容，还会获得相应的数据校验文件内容。当检验数据校验结果与获得的数据校验文件内容一致时，客户端才可以进行相应的操作；否则，HDFS会认为该块数据文件损坏，将从其他的DataNode上获取该块数据的副本，并重新执行校验操作。 

数据完整性校验机制能够有效地保证客户端获取HDFS中文件内容的准确性，防止块数据文件被意外修改导致的数据错误情况的出现。为此，我们有必要设计相应的数据校验故障注入实验来验证该机制的有效性。 

1.3 TFS分布式文件系统 

TFS(Taobao File System)是淘宝内部使用的分布式文件系统，承载着淘宝主站上所有的图片、商品描述等数据存储。TFS的设计初衷就是要面向海量小文件的，故而在设计上对海量小文件的随机读写访问性能做了特殊优化[32]。 

与HDFS类似，TFS也是采用的主从式架构，包含1个Master节点和多个Slave节点。为了保证数据的可靠性，也是以Block的形式复制多分，并且分别保存在不同的数据节点上。 

但是TFS内部的存储机制与HDFS有很大的不同，TFS的每个block是由大量的小文件组成的，每一个block在集群内都有唯一的blockid(逻辑块号)，实际block都是保存在数据节点上的，逻辑块号到物理块的映射由主节点负责完成。每个block又分为“主块+扩展块”的形式(一个主块+多个扩展块)。在block内部，每个小文件都会用fileid来标识，通过blockid+fileid的形式就能访问到文件内容。 

1.3.1 TFS文件系统体系架构 

TFS采用主从式架构，一个TFS集群由两个主节点(NmaeServer，一主一备)和多个从节点(DataServer)组成。其体系架构如图10所示， 

1.TFS：Taobao File System，淘宝文件系统 

2.Disk：硬盘 

3.Client/Application：客户端/应用程序 

4.block：逻辑块 

5.blockid：逻辑块号 

6.filename：文件名 

7.fileid：文件号 

8.Nameserver：名字服务器 

9.Slave NameServer：从名字服务器 

10.Dataserver：数据服务器 

11.Dataserver(Replicate)：副本数据服务器 

12.Sync data：同步数据 

13.Control message：控制信号 

14.Heartbeat message：心跳检测信号 

15.Heart Agent：心跳代理 

monitor：监控信号 

NameServer节点负责管理和维护block和DataServer的相关信息，包括DataServer加入、退出、心跳信息，block和DataServer对应关系的建立和解除。同时也负责block的创建、删除、复制、整理、均衡，并不负责实际数据的存储和读写。 

DataServer节点负责实际数据的存储和读写，正常情况下，每一个block都会在多个DataServer节点上存在，也就是说每一个文件都有多个备份，确保了数据的可靠性。在DataServer节点上，block都是以主块+扩展块的形式存在的，一个block对应一个主块和多个扩展块。扩展块的应用是为了在文件大小发生变化时，如果主块的存储空间不够的话可以将数据放到扩展块里面。DataServer内部为每一个block保存了一个与该block对应的索引文件(index)，在DataServer启动时会把自身所拥有的block和对应的index加载到内存。 

Slave NameServer是NameServer的备份节点，它与NameServer互为热备，同时运行，并且NameServer上所有的操作，都会在Slave NameServer上重新执行一遍，这样当NameServer宕机后，HeartAgent可以迅速的切换至备份主节点，仍然能够正常的对外提供服务。 

一个DataServer服务器上一般会有多个DataServer进程存在，每个DataServer进程负责管理一个挂载点(一般是一个独立磁盘上的文件目录)，来降低磁盘损坏带来的影响。 

1.3.2 TFS写数据流程 

TFS写数据流程如下， 

其中，DataServer(master)：主数据服务器 

DataServer(Replocate2)：数据服务器(复本2) 

DataServer(Replocate3)：数据服务器(复本3) 

写入数据的步骤如下： 

1.客户端首先向NameServer发出创建文件请求 

2.NameServer收到请求后，根据各DataServer上的可写块的容量和负载加权平均来选择一个可写的block，并将blockid和包含该block的DataServer列表返回给客户端 

3.客户端从NameServer返回的DataServer列表中选择一个DataServer作为master，负责数据的写入 

4.master server写入完成后，同时将数据传输到其它的DataServer节点 

5.所有的DataServer节点都写入成功时，负责写数据的master节点才会向NameServer提交写请求 

6.NameServer更新block版本，确认写操作完成 

7.master节点向客户端返回写结果 

在写入文件时，客户端需要从NameServer返回的DataServer列表中选择一个DataServer作为master节点，这个选择过程需要根据DataServer的负载以及当前作为master的次数来计算，使得每个DataServer作为master的机会均等)，master一旦选定，则直到数据写入完成都不会再更换，除非master宕机，一旦master宕机则需要从剩余的DataServer中选择一个新的节点作为master，重新执行写操作。 

1.3.3 TFS读数据流程 

TFS的读数据流程如图11所示， 

其中，blockid：逻辑块号 

fieid：文件号 

DataServer：数据服务器 

NameServer：名字服务器 

值得注意的是，TFS抛弃了传统文件系统的目录结构，也就是说在TFS文件系统内，没有目录和路径一说，根据文件的块号(blockid)和文件号(fileid)就能定位到具体的文件。TFS的文件名由blockid和fileid通过某种对应关系编码组成，解码的时候，根据文件名就能解析出blockid和fileid。 

TFS读取数据的步骤如下： 

1.客户端根据TFS文件名，解析出该文件的块号(blockid)和文件号(fileid) 

2.根据blockid向NameServer查询该block所在的DataServer 

3.根据fileid和blockid向上一步所查询的DataServer节点发送读文件请求 

由于TFS是把大量的小文件放在一个block里面的，DataServer内部为每一个block维护了一个与该block对应的索引文件，通过fileid可以在索引文件中查到该文件在block中的偏移量，从而准确的读出文件内容。 

1.4 TFS文件系统容错机制分析 

TFS为了保证文件系统的可用性和可靠性，也实现了自己的一套容错机制，具体包括如下几个方面。 

1.4.1 NameServer备份机制 

NameServer采用了HA结构，一主一备，TFS运行时会同时启动两台服务器作为NameServer，这两台互为主备，其中主NameServer绑定对外服务IP，当主NameServer发生故障宕机，HeartAgent可以迅速的将IP绑定到备NameServer，同时将备NameServer切换为主NameServer继续对外提供服务。 

备NameServer在启动之后，会进入等待循环，开始接收主NameServer发送过来的元数据同步信息和心跳，但是并不对外提供任何，也不接收其它任何消息。 

1.4.2 多副本冗余备份机制 

与HDFS类似，TFS也采用了多副本冗余备份的机制，即每一个数据块在TFS中存在多份(一般为3份)，并且分布在不同网段的DataServer上。值得注意的是，TFS是以block的方式组织文件的存储，且一个block里包含很多个文件。因此，TFS文件的复制也是基于block的，不存在文件的复制，复制出来的block的blockid与原block的blockid应该是一致的。 

写文件时，对客户端的每一个写入请求，必须在所有的block里都写入成功才算写成功。读文件时，如果出现磁盘损坏或者DataServer宕机的情况，NameServer会通知客户端从具有该block的其它DataServer上读取数据。 

1.4.3 心跳检测机制 

TFS中DataServer与NameServer之间的通信也是通过心跳机制实现的，NameServer通过DataServer发送过来的心跳信息，对DataServer的加入或者退出进行监控，维护所在集群的DataServer信息列表(包括每个DataServer的总容量、已用容量、block数量、当前负载等信息)。同时通过心跳的返回值向DataServer发起对block的创建、删除、读取、复制等操作指令。 

当有服务器发生故障或者下线退出时，NameServer收不到来自其发送的心跳信息，默认存储在该节点上的数据块已经不可用，由于数据块的多副本冗余机制，客户端可以向其它拥有该数据块的节点读取数据，因此并不影响TFS提供正常的服务。同时，NameServer会检测到备份数减少的block，TFS会启动复制流程，将这些block尽快复制到其它DataServer上去，确保每一个block的备份数都不少于最小备份数。 

1.4.4 数据校验机制 

为了保证数据的一致性，TFS会对每一个文件记录其crc校验码，当客户端读取文件时，如果发现crc校验码和文件内容不匹配时，会放弃本次读取，并自动切换到一个好的block上读取数据。同时TFS会对损坏的block进行标记，并且能够自动修复单个文件损坏的情况。 

Claims (6)

1.云环境下分布式文件系统可靠性测试套件，其特征在于，它还包括节点故障注入模块(1)、数据操作失效故障注入模块(2)、数据效验故障注入模块(3)、管理模块(4)和用户主界面(5)，

所述节点故障注入模块(1)用于模拟节点出现的CPU寄存器故障，并根据管理模块(4)的命令将故障注入分布式文件系统中，同时采集节点出现的CPU寄存器故障注入结果，

数据操作失效故障注入模块(2)用于模拟各种类型的节点的关键文件出现数据操作失败故障，并根据管理模块(4)的命令将故障注入分布式文件系统中，同时采集各种类型的节点的关键文件出现数据操作失败故障注入结果，

数据效验故障注入模块(3)用于模拟各种不同类型节点的校验文件无法访问、校验内容错误的故障，并根据管理模块(4)的命令将故障注入分布式文件系统中，同时采集各种不同类型节点的校验文件无法访问、校验内容错误的故障注入结果，

管理模块(4)用于根据测试人员的操作命令调用相应的故障注入模块，并接收相应故障注入模块的故障注入结果通过用户主界面反馈给测试人员，

用户主界面(5)用于提供人机交互界面、接收使用者命令和反馈故障注入结果。

2.根据权利要求1所述的云环境下分布式文件系统可靠性测试套件，其特征在于，节点故障注入模块(1)包括信息交互模块(1-1)、故障信息配置模块(1-2)、故障注入模块(1-3)、故障触发模块(1-4)和故障结果回收模块(1-5)，

所述信息交互模块(1-1)用于实现与管理模块(4)的信息交互；

故障信息配置模块(1-2)用于解析从交互模块接收的用户配置参数，并将所述用户配置参数发送给故障触发模块(1-4)，同时根据所述用户配置参数设定相应的故障注入参数，然后将设定的故障注入参数传送给故障注入模块(1-3)；

故障注入模块(1-3)用于接收故障注入参数，并根所述故障注入参数完成相应的故障注入操作；

故障触发模块(1-4)用于根据用户配置参数检测时钟中断信号，当所述时钟中断信号满足用户设定的故障触发条件时，则触发故障注入模块进行故障注入；

故障结果回收模块(1-5)用于采集被注入故障的分布式平台所产生的故障注入结果，并将结果以内核日志的方式保存到交互模块(1-1)中的系统日志文件系统中。

3.根据权利要求1所述的云环境下分布式文件系统可靠性测试套件，其特征在于，数据操作失效故障注入模块包括分布式文件系统故障参数配置模块、控制模块、故障注入模块、监控模块和结果回收模块，

分布式文件系统故障参数配置模块用于根据管理模块(4)的命令设定分布式文件系统故障注入参数，故障注入参数包括故障注入的目标节点、目标文件位置、故障类型和故障类型的相关参数；

控制模块用于完成接收分布式文件系统故障数配置模块和监控模块的信息，控制故障注入模块向分布式文件系统中注入相应的数据操作故障的功能；

故障注入模块用于接收控制模块传递的信息，从故障库中选取对应的故障类型进行注入；

监控模块用于检测分布式文件系统的日志信息，将检测的分布式文件系统的日志信息提交

给控制模块；

结果回收模块用于收集分布式文件系统故障条件下的测试结果，并将结果提交给管理模块(4)。

4.根据权利要求1所述的云环境下分布式文件系统可靠性测试套件，其特征在于，数据效验故障注入模块包括校验文件的异常故障注入模块和校验值异常的故障注入模块，

校验文件的异常故障注入模块用于根据管理模块(4)的命令选定的故障注入的校验文件，对校验文件进行位置移动、文件权限修改和文件内容修改操作，模拟分布式文件系统中的校验文件由于某些原因造成校验文件无法访问或校验内容错误故障，

校验值异常的故障注入模块用于根据校验值计算对应的API处插入故障代码，当满足故障触发条件时，对相关API应用程序编程接口计算返回的校验值进行数据位翻转，从而构造错误的校验值模拟故障的发生，将校验值模拟故障注入结果给管理模块(4)。

5.根据权利要求1所述的云环境下分布式文件系统可靠性测试套件，其特征在于，节点故障注入模块(1)用于模拟分布式文件系统中节点出现的CPU寄存器故障导致的应用进程失效故障的过程为：

在系统时钟中断发生时修改Hadoop平台相关进程的当前寄存器状态的方法进行故障注入，使用时钟中断作为故障注入触发的条件，当设定的整数倍的时钟中断请求发生时，通过在内核态修改Hadoop平台相关进程寄存器内容映射在内存中的镜像来对寄存器硬件故障进行模拟，当中断请求返回时，操作系统内核在恢复进程上下文现场时，将改写的内核堆栈寄存器内容恢复给Hadoop平台相关进程，从而实现寄存器故障的注入。

6.根据权利要求1所述的云环境下分布式文件系统可靠性测试套件，其特征在于，节点故障注入模块(1)用于模拟分布式文件系统中节点整体宕机故障的过程为：

对系统关键进程进行故障注入操作，导致操作系统崩溃，从而导致计算系统的不可用，这种故障类型能够模拟Hadoop平台集群中节点宕机故障的发生，达到节点失效故障注入的目的。