猛设计-完成部分实验

1、性本人郑重：所呈交的是本人在导师的指导下独立进行取得的成果。除了文中特别加以标注的内容外，本不包括任何其他个人或集体已经或撰写的成果作品。本人完全本的法律由本人承担。作者签名：年月日使用书本作者完全了解学校有关保障、使用的规定，同意学校保留并向有关管理部门或机构送交的复印件和，允许被查阅和借阅。本人省级优秀学士评选机构将本的全部或部分内容编入有关数据进行检索，可以采用影印、缩印或扫描等保存和汇编本学位。属于 1、囗，在本年后适用本书2、不囗。（请在以上相应方框内打“”）作者签名：年月日导师签名：年月日摘要Abstract目录摘 要IAbstractII1 绪论12 课题目的22.1传统策略22

2、.2混合 RAID22.3方案优化23 相关背景3Hadoop3RAID43.3 Hadoop-. 54 设计与实现84.1 Hadoop 部署错误!未定义书签。4.2 In_rack 编码恢复84.2.1Block 丢失84.2.2关闭恢复94.2.3 Corrupt file 获取104.2.4 Job 提交124.2.5 数据块的获取124.2.6 Decode144.2.7 生成块的分发154.2.8 Parity 块的恢复154.3 优化执行 Job 的分发策略154.4 优化文件恢复策略165 实验与分析195.1 测试环境搭建195.1.1 集群拓扑结构195.1.2 Datan

3、ode 故障模拟195.1.3 网络带宽限制205.2 恢复时间的计算215.3 单Block 丢失恢复225.4 Datanode 故障恢复265.4.1 Block 大小为 64MB275.4.2 Block 大小为 4MB276 结论28致谢29参考文献30附录311 绪论现代的发展极大方便了的日常生活，各种设备和服务无时无刻不在为提供着服务，随之带来的就是数据的增长，而且根据机构IDC 的预计，未来的数据总量增长率将在 50%左右，也就是说，到两年后的 2020年，全球的数据总量将会达到 40ZB(1ZB=270Byte)，这也就解释了大数据，云计算等成为了当下的热门领域。大数据对技术

4、领域的首要考验是，Apache的 Hadoop 就是一个，主要由 Hadoop框架中的分布式文件系统 HDFS(Hadoop海量数据的Distributed File System)提供数据服务。但是光光并不能满足需求，因为Hadoop 大都是部署在相对廉价的机器上，而这些机器出故障的概率是很大的，尤其是在机器数目众多的情况下，必然会有某个机器出现故障，导致其的数据丢失，所以大数据的还需要考虑数据容错。容错的目标是，一旦发生故障，能够在最短的时间内恢复出故障节点的数据，保证整个系统中的数据安全。容错方案可以是副本，也可以是 RAID 容错，不管采用那种容错，恢复速度都是非常重要的，而且在繁忙的

5、数据下，网络带宽也成为了一个恢复的瓶颈。本文在总结已有方案的基础上，采用一种混合 RAID 的容错方案，实现了基于Hadoop 的Rack 数据恢复混合RAID 容错系统 HRIR(Hybrid Raid In_rack Recover)，测试其实际的恢复性能并与其他容错方案作比较。2 课题目的2.1 传统策略传统的 Hadoop 提供的是一种三备份的方案，这种方案可以有效提供数据容错，该方案至少可以2 个块的丢失，且大多数情况下可以数据块的丢失，但是首先对于三备份来说，数据冗余过大，冗余度达到了 200%，在海量数据的时候，因为提供容错而浪费的资源过以大规模实施；其次，三备份容错方案在进行数

6、据恢复的时候，因其数据分发的策略不同，会出现 1/3的概率要从其他机架(Rack)内数据块，这在 Rack 的 IO 耗时比较长，并且Rack 之间网络传输繁忙的时候会影响恢复性能。2.2 混合 RAID对于RAID 编码提供容错的方案，RAID1 的方案是一种简单的双备份，分别在两个 Rack 中建立备份，而 RAID5 则是将源数据进行编码生成编码块提供容错，可以考虑混合RAID 容错方案，即在 RAID1 实现的双备份中，在 Rack 内进行编码，产生的两个编码块存放在各自的 Rack 内，与原数据的备份一起提供容错。2.3 方案优化之前有提到，在实际的集群系统中，Rack 内部(In_

7、rack)的数据传输速度要比Rack 之间(across_rack)的快很多，所以恢复，减少对 Rack 间网络带宽的占用，就考虑能不能在 Rack 内部进行数据恢复性能。对于三备份方案来说，有 2/3 的可能是可以实现其 Rack 的恢复的，只要损坏的这个数据块所在的Rack恰好有另一个备份，但是还有 1/3 的情况则不得不跨Rack 进行数据恢复，而且，三备份策略的数据冗余度过大，并不适合大规模的部署。于是考虑混合Raid的，在 Block 损坏的时候，不去跨 Rack 进行数据的发送，而是在 Rack 内部进行RAID 修复，提高 20%以上。的目标是采用优化后的恢复方案，可以比恢复的性

8、能3 相关背景3.1 HadoopApach Hadoop 是一个支持分布式 计算和大数据处理的系统架构，其可以由廉价的设备组集群中心，通过高速网络进行相互之间的通信。它的设计是为了将单服务器扩展为数以千计的节点，每个节点都提供本地的数据和计算能力，这样可以避免单服务器所带来的巨大硬件开销，同时能够保证提供高可靠性的服务。Hadoop 的兴在 2005 年前后的三篇，分别介绍了 GFS，的技术。Hadoop 项目主要包括于MapReduce 和BigTable 三种大数据时代几个模块：Hadoop Common:通用模块，用于支撑其他模块的运行Hadoop Distributed File S

9、ystem()HDFS:分布式文件系统，提供高效的文件读写，这是的混合Raid 方案需要重点的部分Hadoop YARN:Job 调度框架和集群资源管理Hadoop MapReduce:基于 YARN 系统，用于并行处理大数据Hadoop 最的部分是 HDFS 和 MapReduce，的实验系统 HRIR 采用的混合Raid 容错机制的设计就是基于 HDFS 的，而容错的实现，包括 Raid 编码过Decode机上去执行的。过程，提交的 Job 都是通过 MapReduce 计算框架提交到 Task正是因为 Hadoop 的设计中所体现出来的高可靠性(Hadoop 提供了数据容错，计算任务失败

10、再提交等机制)，高可扩展性(集群点个数可以动态增删)和高效性(MapReduce 的计算框架对于大数据的计算有着得天独厚的优势，计算效率可以大大提高，而且，分布式的也可以很方便地实现数据的并行，提高读写效率)，更为重要的是其开源的特性，技术可以在其基础上进行二次开发，后面的 Hadoop-就是公司在 Hadoop1.0 的基础上增加了 Raid方案而开发出的适合其公司特性的 Hadoop 系统，Hadoop 在当前这个大数据的时代得到了广泛的应用，Yahoo 作为著名的互联网门户，它使用了包含 4000个节点的 Hadoop 集群来支撑其搜索业务；国内的公司如也使用 Hadoop 系统进行搜索

11、日志的分析和定点推送等服务；阿里巴巴的淘宝每天需要处理大量的网络订单，事关金钱交易，而且数据量又巨大，高可靠性的 Hadoop 系统在系统数据，作业调度，安全性方面都为其提供了巨大的支持，尤其是双十一期间，爆发式的交易订单增长并没有对阿里巴巴的业务造成破坏性影响。如今，Hadoop 还在不断发展之中，各个公司基于 Hadoop 开发的适合自己的分布式、计算系统正在不断补充 Hadoop 的内容，社区的也在解决代码中的Bug，优化方案，在大数据时代的推动下，Hadoop 框架将会越来越完善。3.2 RAID独立冗余磁盘阵列RAID(Redundant Array of Independent D

12、isk)技术是加州大学分校(University of California, Berkeley)在 1987 年提出，本质上的愿望是通过多块比较廉价的小磁盘组装成磁盘阵列，在效果上可以和昂贵的大磁盘相近，而且对在磁盘上的数据提供容错。RAID 的出现，可以作为计算机磁盘的替代，以其多硬盘的优势，实现并行，提高读写效率，并且组长而成的磁盘阵列可以极大提高设备的容量，同时，通过镜像备份或是编码，还可以提供较好的容错，在其中某一块磁盘出现问题之后，并不会影响整个磁盘阵列的数据读写。RAID 有多种工作模式，不同工作模式的效率，容错能力有一定差异，比较流行的工作模式有RAID0，RAID1，RAID

13、5 和RAID10 这四种。RAID0RAID0 就是数据分条技术，在多块磁盘组成的磁盘阵列中，将数据分别存放到不同的磁盘上，因为每一块磁盘都有磁盘驱动可以同时进行数据的读写，所以采用 RAID0 工作模式，可以提高磁盘阵列的读写性能，且成本比较低廉，有两块磁盘即可以组成RAID0 磁盘阵列。但是 RAID0 工作模式并不提供容错，所以当数据损坏的时候不能进行修复，比较适合那些对数据安全性要求不高，成本预算比较小的情况。RAID1RAID1 提供了一种最直观的容错方案，即冗余备份，将磁盘上的所有数据作一个镜像备份到另一个磁盘上，因此 RAID1 又被称为磁盘镜像，两块磁盘同时进行数据读写，所以

14、读写的效率和普通磁盘几乎是一样的，不会因为存在备份而降低读写效率，但是 RAID1 所具有的数据容错能力是最强的，完全的数据备份可以保证系统的高可靠性和可修复性，在其中一块磁盘发生故障的时候，可以从镜像中数据，并不会影响数据，之后可以在空闲的时候进行磁盘恢复。但是 RAID1 高可靠性的代价就是较低的效率，只有 50%，在数据量巨大的情况为镜像设备的磁盘将会是一笔比较大的开销。比较适合那些要求数据高可靠性的场合，比如，RAID5，企业信息等。考虑到RAID0 高效率但不提供容错，RAID1 提供高容错但是较低的效率，RAID5 工作模式可以说是二者的折衷，即 Hybrid，综合二者之长，减弱二

15、者的短板。RAID5 的工作模式改变了 RAID1 的完全备份，而是采用奇偶校验信息作为容错方案，选取一定长度的源数据进行计算，将得出的奇偶校验信息一同以提供容错，并且奇偶校验信息不在同一个磁盘上以避免该磁盘出现故障所导致的整体失效。在写入的性能上会有一定程度的降低，因为需要计算奇偶校验块，效率上不会有很大的减弱，只是多了一个奇偶校验块而已。在发生磁盘故障的时候，可以用剩下的磁盘中的数据和奇偶校验信息计算得出丢失的数据，虽然数据容错能力不如 RAID1，但是其 RAID0 所不具有的容错能力，比较适合部署使用。RAID10RAID10 又写成 RADI0+1，称为镜像阵列条带，和 RAID0

16、一样采用数据分条技术，又和 RAID1 一样采用 100%的完全备份，是一种高性能，同时也高开销的效率较高，而且提供了RAID 工作模式，在读的时候支持多磁盘并行，写入的时候和 RAID1 相同，都是写入两个镜像的磁盘中，而且容错能力更好，即使两个磁盘出现故障，如果不是相同的镜像磁盘的话，依然可以提供正常的数据服务。集合了 RAID0效率依然只有 50%。和RAID1 的优点，也完全继承了RAID1 的缺点，即3.3 Hadoop-对于用户总数超过 20 亿，占全球总人口 1/3 强的数据都已经不算什么，很早之前的一份数据显示，2011 年公司，PB 级别的公司所拥有的压缩数据已经达到了 25

17、PB，还未压缩数据则有 150PB，这仅仅是 6 年前的数据，在移动网络飞速发展，全球数据增长的情况下，所需要处理的数据或以称之为全球最大的大数据了。HDFS-RAID 是l 基于第一代的 Hadoop 分支所开发的 Raid 方案，对Hadoop 自带的 HDFS 修改不大，用设计者的话来说，就是“Hadoop 本身已经够复杂了，不想让它更复杂”，主要是在现有的 HDFS 上增加了一个包装contrib，并不是将修改的代码嵌入到 Hadoop 中。常用的编码方式有RS(Reed-Solomon)编码和 XOR 编码，本质上他们都是对 N额数据块进行运算，产生K 个校验块，然后在 N+K 个块

18、中，就可以最多K额块的丢失，丢失的块可以由剩下的块通过计算恢复出来，N 和 K 都是可以自由设定的，一般称N 为StripeLength，称K 为 ParityLength。数据的Raid 有几种不同的方案，对于不太冷的数据，需要保存比较多的备份，但是又不能是完全的三备份，这时候可以采用 XOR 编码，生成的 parity 块保留两个备份，源数据块从三备份减少为双备份，在StripeLenght 为 3，ParityLenght为 1 的情况下，理论上 replicate 系数可以从 3 减少到 2.67，但是容错能力并没有减弱，然而得到了一定程度的加强(在情况下，三备份只能两个块的丢失，但是

19、Raid 方案能够至少三个块的丢失)。对于非常冷的数据，则可以采用 RS 编码，StripeLength 设置为 10，ParityLength 设置为 4，这样子理论上的replicate 系数为 1.4，已经大大小于三备份方案了，而且依然提供容错，只是恢复的计算开销会比较大，所以适合比较冷的数据。HDFS-RAID 主要三个模块组成，分别是：DistributedRaidFileSystem这是包装了 DistributeFileSystem 的分布式文件系统类，提供了 HDFS-RAID 方案中的相关支持。RaidNodeRaidNode 会启动RPC Server，接收通过RaidS发

20、送过来的指令，进行编码或者恢复或者负载均衡等，这些操作是由各自的进程来完成的。RaidS提供了一个命令窗口，集群管理员通过 RaidS作。给RaidNode 发送指令进行操HDFS-RAID 中的主要线程有TriggerMonitor周期性检查配置信息，根据配置进行数据的Raid 等操作。BlockegrityMonitor负责检查已经 Raid 化的数据，检测是否有损坏或者丢失的文件，如果有，则通过构建BlockFixer 或者 BlockCopier 线程进行修复，其中BlockFixer 负责损坏文件的修复，BlockCopier 负责丢失文件的修复。PlacementMonitor负载

21、均衡线程PlacementMonitor 周期性检查 Hadoop 集群中各个节点的负载情况，将负载过重的节点上的数据转移发送到其他节点。PurgeThread定期扫描 Parity 文件，查看其中是否有 orphan file，即该 Parity 文件的源文件已经被删除了，如果有，那么删除该orphan file。HarThread:归档线程，Hadoop 比较适合处理大文件，如果过多的小文件上传到系统中，会极大占用 NameNode 上的内存空间，所以一段时间后 Hadoop 会将小文件进行归档处理，减轻 NameNode 的负担。4 设计与实现4.1 混合 Raid 容错4.2 In_r

22、ack 编码恢复4.2.1Block 丢失Datanode 会通过 DataBlockScanner 类定期检查本地的数据目录，当在Datanode 上手动删除 Block 的时候， Datanode 检测到文件丢失， 通过reportBadBlocks()函数经过一系列调用，将一系列 LocateBlock 对象(该对象了包含丢失的 Block 和其 DatanodeInfo 数 组 信 息 ) 传 递 给 NameNode 的reportBadBlocksernal()函数。在 NameNode 的reportBadBlocksernal()函数中，处理的逻辑就是循环处理传递过来的每一个

23、LocateBlock 对象，通过 LocateBlock 对象的下列两个函数获得Block 信息和DatanodeInfo 数组信息：Block blk = locatedBlock.getBlock(); DatanodeInfo nodes = locatedBlock.getLocations();之后通过amesysstem 的 markBlockAsCorrupt()函数，在确认 node 非 null和 blk 所属的文件非 null 之后，将属于 nodes 数组上内每一个 node 上丢失的的该blk 标记为corrupt。标记为corrupt 后，通过调用updateNee

24、dedReplicationQueue()函数更新 neededReplications 对象，这是在恢复过非常重要的一个对象，其定义类为 UnderReplicatedBlocks，用于保存需要进行备份的 Blocks 信息。Block 的丢失到这儿也就可以了，但是因为要进行在恢复的情况下，Raid 修复， 为了避免在修复过的分发阶段出现问题，需要在updateNeededReplicationQueue()函数后面添加一段代码，即：updateNeededReplicationQueue(storedBlockInfo, -1, numCurrentReplicas, misedRepli

25、cas, node, blockReplication);/modify by duroper 因为进行raid 修复了，所以直接invalidate 掉这个block原本invalidateBlock()函数是用于上还存有该Block 的信息，加上新恢复成功后，因为丢失 Block 的 Datanode生成的副本，该Block 的副本数就超过了所定义的需要的副本数，所以需要将此 Datanode 上的 Block 无效，也就是在invalidateBlock 函数内执行removeStoredBlock()函数，将该 Block 从 Datanode 上需要进行 Raid 恢复，因为节点有限

26、，分发数据的时候如果移除。但是现在恰好又选择到了丢失Block 的节点，那么发送的时候会出现报错，所以测到Block 丢失后，就使此 Datanode 上的 Block 无效。为此，还需要去修改 invalidateBlock()函数的判断条件，原本的策略是在在检有至少下两个副本的情况下才会 invalidateBlock 掉相应的 Block，实验中我们定义的副本数为 2，因此在只有一个副本的情况下也需要将该 Block 从Datanode 上移除。修改的代码如下：至此， 丢失 Block 的 report 任务修改完毕， 丢失信息成功保存到neededReplications 对象中。4.

27、2.2 关闭恢复在混合Raid 的方案中，发生 Block 丢失的时候，由于在另一个 Rack 内一定有这个Block 的备份，所以默认采用的是恢复，为了实现 In_rack 的编码恢复，需要关闭原本其恢复功能。经过探索，发现可以使用命令：/modify by duroper2017-04-21修改判断条件if (count = 1) /if (count 1) /end/ delete wiCK addToInvalidates(blk, dn, ackRequired); removeStoredBlock(blk, node);if(!blockReplicationEnabled) i

28、nvalidateBlock(storedBlockInfo, node, true);/end来进行功能的动态开启或者关闭。4.2.3 Corrupt file 获取Hadoop 在启动 RaidNode 后，会开启一个 BlockegrityMonitor 线程检查系统中的文件，BlockegrityMonitor 有两个实现，在部署的分布式计算的Hadoop系统中，采用的是第二种 Dist 模式，其实现线程为 DistBlockegrityMonitor，将计算任务分发到 Task 机上去执行，减少RaidNode 上的计算开销。DistBlockegrityMonitor 线程在运行的

29、时候，通过 DFSck(Distribute File SystemCheck)命令检查系统中已经 Raid 化的数据，在丢失一个 Block 的情况下，默认并不会将其作为Corrupt File 返回，而是进行恢复。为了实现In_rack 的编码恢复，需要修改Corrupt file 的获取代码。 首先定位获取损坏文件的代码，在 DistBlockegrityMonitor 线，每隔一段时间就调用一次 checkAndReconstructBlocks() ，而此函数则是调用了 CorruptionWorker 类中的 getLostFiles()来返回一个损坏文件名和其损坏 Block 数

30、 目的 HashMap 对象。 而最终要调用的，是位于amesystem 中的 listCorruptFilocks() 函数 ， 在 该函数中 通过迭代 之前 提到过的 neededReplications 对象中的所有损坏 block，根据优先级获取其中需要进行修复的 Block，然后返回一个 CorruptFilockInfo 的对象队列，CorruptFilockInfo保存了损坏的Block 和其对应的文件Path 信息。 默认在进行 Raid 修复的时候只会返回优先级为 3 的损坏 Block，但是对于混合 Raid 容错机制下副本数为 2，且已经有一个 Block 损坏的情况下，

31、该Block 的 优先级为 0，所以需要修改源码，使之在单Block 损坏的时候也提交给 Raid 进行修复。为了不影响正常恢复的过程，所以添加了一个判断，判断的条件blockReplicationEnabled 就是前文中进行动态设置的恢复开关。BlockIterator blkIterator = null; if (misingOnly) blkIterator = neededReplications.iterator(0); else /modify by duroperduropinhadoop dfsadmin blockReplication disable/enable 与之

32、对应，源码下方的判断条件也要进行相应的修改，同样需要设置判断条件。在getLostFiles()函数中获得了相应的损坏文件信息后，但是这其中会包括一些已经移动到回收站的文件，参照源码中的说明，先打印出损坏文件的个数，然后过NumberReplicas num = countNodes(blk);/modify by duroperif (blockReplicationEnabled) if (num.liveReplicas = 0) if (misingOnly &misedReplicas 0 |misingOnly &misedReplicas = 0) corruptFiles.ad

33、d(new CorruptFilockInfo(src, blk);count+;if (count = maxCorruptFilesReturned)break; else if (num.liveReplicas() = maxCorruptFilesReturned)break;blkIterator = getCorruptReplicaBlockIterator(); elseblkIterator = neededReplications.iterator(0); /blkIterator = neededReplications.iterator(0); /blkIterato

34、r = getCorruptReplicaBlockIterator(); /默认参数为 3 /end if (blockReplicationEnabled) 滤掉已经被删除的文件，再次打印文件个数。 至此，corrupt file 获取成功。4.2.4在 checkAndReconstructBlocks()函数中获取到损坏和丢失的文件后，然后就要调用computePrioritiesAndStartJobs(fs, lostFiles, detectTime)进行修复了，传入的参数包括文件系统fs，丢失Block 的文件列表lostFiles 以及当前时间。首先会进行计算文件的优先级，副

35、本数目越小，发生 corrupt 的 Block 数目越大，优先级就越高。将计算好优先级的文件列表按优先级排序，作为参数构建修复 Job。 job 的输入是所有需要修复的文件 path 的 sequence file 。会根据 raid.blockfix.filespertask 配置的值进行 sync，即在 job 的 split 阶段会按照该值设置的进行split，默认是 20Job 的 Mapper 主要是通过Reconstruter 在task 机上完成响应文件的恢复。执行 Job 的 Map 任务的类为继承自 Mapper 类的 ReconstructionMapper 类，其map

36、 函数是恢复的主要过程，其调用了 BlockReconstruct 类中的 reconstructFile()函数，完成恢复过程并计算时间开销。4.2.5 数据块的获取在进行文件恢复的时候，reconstructFile()函数根据其文件类型的不同分别进行恢复，通过新建的 Decode 对象，调用其中的恢复函数。恢复过需要源文件数据块或者是编码块，为了实现 In_rack 的恢复，必须是在 Rack 内进行读取，这样子在恢复性能上才可能会超过 across_rack 的block 的恢复。而过程比较复杂，先通过 lost block 获得其所属的文件地址，然后定位该 block 在Job 提交

37、LOG.info(ListCorruptFilocks returned + lostFiles.size() + files);/modify by duroper 取消过滤掉 Trash 中的文件，因为 Radi 产生的parity block在 Trash 中RaidUtils.filterTrash(getConf(), lostFiles.keySet().iterator();/end LOG.info(getLostFiles returning + lostFiles.size() + files);文件中的偏移地址，之后建立该文件地址下的 FSDataInputStream

38、输入流，根据偏移地址对该block 进行，在恢复的时候实现多个Block 的并行。修改的策略是在 getBlockLocations()返回一系列 LocateBlocks 之后，因为的时候默认是从某个 Block 所对应的 DatanodeInfo 数组中的第一个之后Datanode 进行，所以在得到 LocateBlocks 后进行排序处理，将离当前执行Job 的 Datanode 比较近的节点前移，保证 In_rack 的恢复。Hadoop 本身有一定的优化，可以在一定程度上保证尽量从比较近的地方进行，但是实验过发现在某些情况下还是经常会从比较远的另一个 Rack 内进行Block，这样

39、一Block 所需要的传输时间已经和恢复相等了，那么 Raid 恢复来，本身的效率并没有提高，反而有所降低，也不再是真正意义上的 In_rack 恢复了。 排序的策略是，扫描所有节点数组，如果找到本地节点，即当前执行 Job 的节点，那么无疑这个的距离是最近的，将其放置到数组的第一的位置；如果有同一Rack 的节点，在没有本地节点的情况下这个是最近的，于是将其放置到第一(不存在本地节点)或者本地节点之后的位置，如果既没有本地节点，也没有同 Rack内节点，那么可以不改变数组顺序，原样返回就行，修改后的 sort 策略可以保证在存在 In_rack 节点的情况下，一定是从 Rack 内进行 Bl

40、ockIn_rack 的恢复。，进而实现/modify by duroper tempIndex = 0;if (reader != null ) localRackNode = -1;/scan the array to find the local node & local rack node for(i=0; icount); myrepl = countNodes(blockinfo);LOG.info(duropinliveRep:+myrepl.liveReplicas()+and Rep:+inode.getReplication();if(myrepl.liveReplicas

41、()1) break;LOG.info(duropincorruptBlockInFile=+corruptBlockInFile); if(corruptBlockInFile = 1)corruptFiles.add(new CorruptFilockInfo(src, blk); count+;if (count = maxCorruptFilesReturned) break;corruptBlockInFile = 0; NumberReplicas myrepl = null; BlockInfo blocks = myinode.getBlocks();LOG.info(repl

42、icate:blockss size = +blocks.length); for(BlockInfo blockinfo : blocks)myrepl = countNodes(blockinfo);LOG.info(duropinreplicaiveRep:+myrepl.liveReplicas()+and Rep:+myinode.getReplication();if(myrepl.liveReplicas()1 )String src = FSDirectory.getFullPathName(myinode); LOG.info(duropin:Replicationadd s

43、rc file+src); blocksToReplicate.get(priority).add(block);catch (IOException ioe) / the node may have already been deleted; ingore it LOG.info(Invalid inode, ioe);/end5 实验与分析5.1 测试环境搭建5.1.1 集群拓扑结构实验选用 Ubuntu14.04 系统进行 Hadoop 集群部署，使用 VMware 开启五台虚拟机，分别作为 NameNode 节点和四个 DataNode 节点，RaidNode 部署在NameNode

44、上。虚拟机的硬件配置和版本如所示。(注：NameNode 的内存为 800MB，DataNode 的内存为 600MB)为了区分 In_rack 和 acorss_rack 的区别，需要建立逻辑 Rack 放置从节点，其中 Slave1，Slave2 和 Slave3 存放在逻辑机架 Rack1 内，Slave4 存放在逻辑机架Rack2 内，NameNode/RaidNode 独立于两个 Rack，其拓扑结构如所示。5.1.2 Datanode 故障模拟实际的集群系统中，运行 Datanode 的从节点机器发生的故障主要有两类，一类是由于断电，宕机等造成节点关闭，其硬盘上的数据全部丢失；还有

45、一类是磁盘的部分扇区出现坏道等问题，导致部分数据 Block 不能，在实验总需要模拟这两种故障发生时，测试 HRIR 系统的容错恢复能力。Hadoop 的源码中对于两种情况处理过程的不同，可以发现，Datanode通过项目配置信息内存800MB/600MB硬盘20GBCPU(宿主机)el Core i5-2450M 2.5GHz操作系统Ubunu 14.04kernelx86_64 Linux 3.13.0-32-genericGit 版本1.9.1Ant 版本1.9.3Jave 版本1.8.0_111故障是通过 Namenode 检测 heartbeat 的丢失来完成的，因为检测的周期比较长

46、，所以导致故障响应比较慢，而删除 Block 的话，Datanode 在本地数据检测的时候发现 Block 丢失，会立即调用 reportBadBlock()函数，该函数的具体功能中已经有完整叙述，总之，调用函数之后能够快速响应 Block 丢失。而在检测到相应故障的时候，两种情况下的最后的处理过程都是一样的，均是文调用了updateNeedReplicationQueue()函数将该 Block 添加到待恢复的队列，唯一不同的是 Datanode 故障发生之后的响应过，有一步操作是将该 Datanode 上的 corrupt Block 移除(因为检测到 Datanode 故障，集群也就将该

47、 node 移除了)。这并不会影响的恢复过程，所以可以使用 rm 命令删除 Block 的方法来模拟单Block 的丢失。5.1.3 网络带宽限制HRIR 系统采用的是 In_rack 的 Raid 恢复，相比较于直接的恢复，所需要的 Block 个数一定是的，在最好的情况下，即 stripeLenghth(条带长度)为 2，parityLength(编码块长度)为 1 的时候，至少需要2 个 Block 才能完成恢复。而 In_rack 恢复能达到更好的恢复效率，一个重要的原因是 Rack 内的速度要远快于跨 Rack的速度，因此在实验过要模拟出实际 Rack 的拓扑结构，部署的时候 Rac

48、k2 内只有一个节点 Slave4，所以可以限制 Slave4 和其他Slaves 之间网络传输的带宽，Rack 内传输和跨Rack 传输的速率比参考相关资料得知，在 1:5 到 1:20 之间，更差一点的情况甚至可以达到 1:200。因此，首先确定在 VMware 虚拟机之间的最大网络带宽是多少，采用实验的方式，使用恢复确定大小的Block，更改Slave4 的网络带宽，多次实验，实际传输Block 所花费的时间，得出相关的如下所示：Datanode 故障关闭rm 命令删除Block触发机制lost heartbeatreportBadBlock()相应时间超过十分钟一分钟以内故障处理upd

49、ateNeedReplicationQueue()updateNeedReplicationQueue()所以可以大致确定虚拟机之前的最大传输带宽在 350Mbps 左右，为了确保带宽限制的效果，设定虚拟机中逻辑 Rack 内的网络带宽为 300Mbps，并且按照 1:5 或者 1:10 的带宽比，分别可以设置 Slave4 的网络带宽为 60Mbps 或者 30Mbps。设置方法为在 VMware 中点击虚拟机-设置-网络适配器-高级，分别设置传入带宽和传出带宽为相应的数值。5.2 恢复时间的计算比较In_rack 和across_rack 在恢复性能的差异，最主要的参数就是故障的恢复时间，

50、对于 In_rack 的 Raid 恢复，分别计算其实际恢复的时间 DT(DecodeTime)和包含 Job Schedule 的时间 ST(Schedule Time)，结果通过该 Job 的 log 日志输出，恢复的时间也包括两部分，一个是发送请求开始到目标节点收到该Block 的时间TT(Transfer Time)，还有一个是Block 源节点在与目标节点完成连接，实际传输过程所花费的时间 RT(Replicate Time)，这两个时间可以通过 NameNode 和 Datanode 的log 日志输出。在进行单 Block 恢复的时候，主要计算的是实际恢复的时间，即 DT 和TT

51、，这样能够最直接反映处 In_rack 恢复在Rack内高速传输情况下的优势，而在 Datanode 故障的时候，计算的是所有时间的累加和，即包含所有时间的 ST 和 RT，Raid 编码修复和 Replicate修复开始的时间一样，都是从 Namenode 检测到 lost heartbeat 开始，到完成最后一个 BlockSlave4 网络适配器带宽传输 64MB 的 Block 的实际发送时间(单位：ms)不受限MbpsMbpsMbpsMbps27832721的修复为止。5.3 单 Block 丢失恢复单Block 丢失的主要实验步骤为：..9.10.上传测

52、试文件到 Hadoop 系统启动RaidNode 进行编码设置Slave4 网络适配器的带宽关闭 Hadoop 系统的功能删除Slave2 上的Block等待In_rack 的恢复完成，测试出恢复时间开启 Hadoop 系统的功能删除Slave1 上的Block等待across_rack 的恢复完成，测试出恢复时间修改Slave4 网络适配器的带宽，测试不同带宽限制下两种恢复的时间设置StripeLength 为 2，ParityLength 为 1，这样在实验中的 Block 分布比较直观。一般情况下实际 Hadoop 系统的Block 设置以 64MB 为主，并且进行多次实验，取平均值作为

53、最后的实验数据。5.3.1 Block 大小 1MB限速 60Mbps限速 30Mbps实验次数In_rack 编码恢复(ms)across_rac恢复(ms)1451213实验次数In_rack 编码恢复(ms)across_rac恢复(ms)184667289348387797平均值872715.3.2 Block 大小 4MB限速 60Mbps限速 30Mbps5.3.3 Block 大小 8MB限速 60Mbps限速 30Mbps实验次数In_rack 编码恢复(ms)across_rac恢复(ms)114561176212801023310771049平均值12711082实验次数I

54、n_rack 编码恢复(ms)across_rac恢复(ms)93639811006平均值938960实验次数In_rack 编码恢复(ms)across_rac恢复(ms)1103847128825173827465平均值91648424641993554199平均值4902045.3.4 Block 大小 16MB限速 60Mbps限速 30Mbps5.3.5 Block 大小 64MB限速 60Mbps实验次数In_rack 编码恢复(ms)across_rac恢复(ms)164659219254669726357929236平均值59079393实验次数In_rack 编码恢复(ms)

55、across_rac恢复(ms)119764476218234451318664464平均值18884463实验次数In_rack 编码恢复(ms)across_rac恢复(ms)118182216224352199314232221平均值18922212实验次数In_rack 编码恢复(ms)across_rac恢复(ms)116892204211202183313932137平均值14002174限速 30Mbps5.3.6 Block 大小 128MB限速 60Mbps限速 30Mbps通过实验可以发现，在限速 60Mbps，即 Rack 间网络带宽和Rack 网络带宽比大约为 1:5 的时候，In_rack 的编码恢复和 across_rack恢复的时间相差无几，但是随着网络带宽的进一步限制，In_rack 编码恢复的恢复时间并没有受到多大的影响，但是 acorss_rack 的恢复则随着网络带宽的减小，恢复时间大致成比例地增加，因为 1:5 的速度比已经是最保守的估计了，这说明在大多数的