程校猛-设计-完成部分实验

摘 绪 课题目 传统策 混合 方案优 相关背 Hadoop-...................................................................................................设计与实 Hadoop部 In_rack编码恢 报告Block丢 关闭恢 Corruptfile获 Job提 数据块的获 生成块的分 Parity块的恢 优化执行Job的分发策 优化文件恢复策 实验与分 测试环境搭 集群拓扑结 Datanode故障模 网络带宽限 恢复时间的计 单Block丢失恢 Datanode故障恢 Block大小为 Block大小为 结 致 参考文 附 绪现代的发展极大方便了的日常生活各种设备和服务无时无刻不在为提供着服务随之带来的就是数据的增长而且根据机构IC50%202040Z(1Z270yte)，这也就解释了大数据，云计算等成为了当下的热门研究领域。大数据对技术领域的首要考验是，Apache的Hadoop就是一个海量数据的平台，主要由Hadoop框架中的分布式文件系统HDFS(HadoopDistributedFileSystem)提供数据服务。但是光光并不能满足需求，因为Hadoop大都是部署在相对廉价的机器上，而这些机器出故障的概率是很大的，尤其是在机器数目众多的情况下，必然会有某个机器出现故障，导致其的数据丢失所以大数据的还需要考虑数据容错容错的目标是一旦发生故障，方案可以是副本，也可以是RAID容错，不管采用那种容错，恢复速度都是非常重要的，而且在繁忙的数据下，网络带宽也成为了一个恢复的瓶颈。本文在总结已有方案的基础上，采用一种混合RAID的容错方案，实现了基于Hadoop的Rack数据恢复混合RAIDHRIR(HybridRaidIn_rackRecover)，课题目传统策Hadoop该方案至少可以2个块的丢失，且大多数情况下可以数据块的丢失，但是首先对于三备份来说，数据冗余过大，冗余度达到了200%，在海量数据的时候，因为提供容错而浪费的资源过以大规模实施；其次，三备份容错方案在进行数据恢复的时候，因其数据分发的策略不同，会出现1/3的概率要从其他机架(Rack)内数据块，这在Rack的IO耗时比较长，并且Rack之间网络传输繁忙的时候会影响恢复性能。对于RAID编码提供容错的方案，RAID1RackRAID5方案优，之前有提到，在实际的集群系统中，Rack(In_rack)的数据传输速度要比Rack之间(across_rack)的快很多，所以就考虑能不能在Rack进行数据Rack间网络带宽的占用，提升恢复性能。对于三备份方案来说，有2/3的可能是可以实现其Rack的恢复的，只要损坏的这个数据块所在的Rack1/3的情况则不得不跨Rack三备份策略的数据冗余度过大并不适合大规模的部署于是考虑混合Raid进行RAID修复的目标是采用优化后的恢复方案，可以比恢复的性能20%以上。，相关背ApachHadoop是一个支持分布式计算和大数据处理的系统架构，其可以由廉价的设备组集群中心，通过高速网络进行相互之间的通信。它的设计是为了将单服务器扩展为数以千计的节点每个节点都提供本地的数据和计算能力，Hadoop的兴于在2005年前后的三篇分别介绍了GFS，MapReduce和BigTable三种大数据时代至关重要的技术。Hadoop项目主要包括HadoopCommon:HadoopDistributedFileSystem()HDFS:分布式文件系统，提供高效的文件读写，这是的混合Raid方案需要重点研究的部分Hadoop最的部分是HDFS和MapReduce，的实验系统HRIR采用的混合Raid容错机制的设计就是基于HDFS的，而容错的实现，包括Raid编码过Decode过程，提交的Job都是通过MapReduce计算框架提交到TaskHadoop的设计中所体现出来的高可靠性(Hadoop提供了数据容错，性(MapReduce的计算框架对于大数据的计算有着得天独厚的优势，计算效率可后面的Hadoop-就是公司在Hadoop1.0的基础上增加了RaidHadoop系统，Hadoop在当前这个大数据的时代得到了广泛的应用，Yahoo作为著名的互联网门户它使用了包含4000个节点的Hadoop集群来支撑其搜索业务；国内的公司如也使用Hadoop统进行搜索日志的分析和定点推送等服务阿里巴巴的淘宝每天需要处理大布式、计算系统正在不断补充Hadoop的内容，社区的也在解决代独立冗余磁盘阵列RAID(RedundantArrayofIndependentDisk)技术是加州大学过多块比较廉价的小磁盘组装成磁盘阵列在效果上可以和昂贵的大磁盘相近，而且对在磁盘上的数据提供容错。RAID的出现，可以作为计算机磁盘RAID有多种工作模式，不同工作模式的效率，容错能力有一定差异，比较流行的工作模式有RAID0，RAID1，RAID5和RAID10这四种。RAID0RAID0工作模式，可以提高磁盘阵列的读写性能，且成本比较低廉，有两块RAID1RAID1又被称为磁盘镜像，两块磁盘同时进RAID1所具有的数据容错能力是最强的，完全的数据备份可况为镜像设备的磁盘将会是一笔比较大的开销比较适合那些要求数据高可靠性的场合，比如银行，，企业信息等。考虑到RAID0高效率但不提供容错，RAID1提供高容错但是较低的效率，RAID5Hybrid思想，综合二者之长，减弱二者的短板。RAID5RAID1的完全备份，而是采用奇偶息一同以提供容错并且奇偶校验信息不在同一个磁盘上以避免该磁盘算奇偶校验块，效率上不会有很大的减弱，只是多了一个奇偶校验块而已。失的数据，虽然数据容错能力不如RAID1，但是其效率较高，而且提供了RAID0所不具有的容错能力，比较适合部署使用。RAID10RADI0+1RAID0一样采用数据分条技术，又和RAID1一样采用100%的完全备份，是一种高性能，同时也高开销的RAID工作模式在读的时候支持多磁盘并行写入的时候和RAID1相同，不是相同的镜像磁盘的话，依然可以提供正常的数据服务。集合了RAID0和RAID1的优点，也完全继承了RAID1的缺点，即效率依然只有50%。，对于用户总数超过20亿，占全球总人口1/3强的公司，PB级别的数据都已经不算什么，很早之前的一份数据显示，2011年公司所拥的压缩数据已经达到了25PB，还未压缩数据则有150PB，这仅仅是6年前的数据，在移动网络飞速发展，全球数据增长的情况下，今天所需，处理的数据或以称之为全球最大的大数据了HDFS-RAID是l基于第一代的Hadoop分支所开发的Raid方案，对HDFS上增加了一个包装contribHadoop中。常用的编码方式有RS(Reed-Solomon)编码和XOR编码，本质上他们都是对N额数据块进行运算，产生K个校验块，然后在N+K个块中，就可以最多K额块的丢失，丢失的块可以由剩下的块通过计算恢复出来，NK都是可以自由设定的，一般称N为StripeLength，称KParityLength。数据的idRprity两个备份，源数据块从三备份减少为双备份，在StripeLnght3PrityLnght1rplite32.67减弱，然而得到了一定程度的加强(在情况下，三备份只能两个块的丢失但是id方案能够至少三个块的丢失)对于非常冷的数据则可以采S编码，StripeLngth10，Prityngth4，这样子理论上的rplicte1.4据。HDFS-RAIDDistributeFileSystemHDFS-RAID方RaidNode会启动RPCServer，接收通过RaidS发送过来的指令，进行编码RaidS给RaidNode发送指令进行操HDFS-RAID周期性检查配置信息，根据配置进行数据的RaidRaid化的数据，检测是否有损坏或者丢失的文件，如果有，则通过构建BlockFixerBlockCopier线程进行修复，其中BlockFixer负责损坏文件的修复，BlockCopier负责丢失文件的修复。负载均衡线程PlacementMonitorHadoop集群中各个节点的负载情ParityorphanfileParity文件的源文件已经被删除了，如果有，那么删除该orphanfile。归档线程，Hadoop比较适合处理大文件，如果过多的小文件上传到系统中，会极大占用NameNode上的内存空间，所以一段时间后Hadoop会将小文件进行NameNode的负担。设计与实Hadoop部In_rack编码恢报告Block丢Datanode会通过DataBlockScanner类定期检查本地的数据，当在Datanode上手动删除Block的时候，Datanode检测到文件丢失，通过reportBadBlocks()LocateBlock对象(该对象了包含丢失的Block和其DatanodeInfo)NameNode的meode的rportdlockInternl()LotelockLotlock对象的下列两个函数获得lock信息和DtanodInfo数组信息：Blockblk=locatedBlock.getBlock();DatanodeInfo[]nodes=之后通过amesysstem的markBlockAsCorrupt()函数，在确认node非nullblknullnodesnode上丢失的的该blk标记为corruptcorruptupdateNeededReplicationQueue()函数更新neededReplications对象，这是在恢复过非常重要的一个对象，其UnderReplicatedBlocksBlocks信息。Raid修复，为了避免在修复过的分发阶段出现问题，需要在updateNeededReplicationQueue(storedBlockInfo,updateNeededReplicationQueue(storedBlockInfo,-1,numCurrentReplicas,missionedReplicas,node,blockReplication);//modifybyduroper因为进行raid修复了，所以直接invalidate掉这个invalidateBlock(storedBlockInfo,node,true);原本invalidateBlock()函数是用于恢复成功后因为丢失Block的上还存有该Block的信息，加上新生成的副本，该Block的副本数就超过了所定义的需要的副本数，所以需要将此Datanode上的Block无效，也就是在invalidateBlock函数内执行removeStoredBlock()BlockDatanode上移除。但是现在需要进行Raid恢复，因为节点有限，分发数据的时候如果恰好又选择到了丢失Block的节点，那么发送的时候会出现报错，所以在检测到BlockDatanodeBlock无效。为此，还需要去修改invalidateBlock()函数的判断条件，原本的策略是在们定义的副本数为2，因此在只有一个副本的情况下也需要将该Block从Datanode上移除。修改的代码如下：//modify//modifyby 2017-04- if(count>=1)//if(count>1)//deletewithACKaddToInvalidates(blk,dn,ackRequired);removeStoredBlock(blk,node);}至此，丢失Block的report任务修改完毕，丢失信息成功保存到neededReplications关闭恢在混合Raid的方案中，发生Block丢失的时候，由于在另一个Rack内一定有这个Block的备份所以默认采用的是恢复为了实现In_rack的编码恢复，需要关闭原本其恢复功能。hadoopdfsadmin–blockReplication来进hadoopdfsadmin–blockReplicationCorruptfile获BlockIntegrityMonitor系统中，采用的是第二种Dist模式，其实现线程为DistBlockIntegrityMonitor，将计算任务分发到Task机上去执行，减少RaidNode上的计算开销。DistBlockIntegrityMonitor线程在运行的时候通过DFSck(DistributeFileSystemCheck)RaidBlock的情况下，默认恢复，需要修改Corruptfile的获取代码。首先定位获取损坏文件的代码，在DistBlockIntegrityMonitor线，每隔一段时间就调用一次checkAndReconstructBlocks()，而此函数则是调用了CorruptionWorkergetLostFiles()Block数目的HashMap对象。而最终要调用的，是位于amesystem中的listCorruptFileBlocks()函数，在该函数中通过迭代之前提到过的neededReplicationsblock，根据优先级获取其中需要进行修复BlockCorruptFileBlockInfo的对象队列，CorruptFileBlockInfo保存了损坏的Block和其对应的文件Path信息。Raid3Block，但是对于混合Raid容错机制下副本2，且已经有一个Block损坏的情况下Block的优先级为0，所以需要修改源码，使之在单Block损坏的时候也提交给Raid进行blockReplicationEnabled就是前文中进行动态设置的恢复开关。BlockIteratorBlockIteratorblkIterator=null;if( missioningOnly){blkIterator=}else//modifyby ifif(blockReplicationEnabled)blkIterator=}blkIterator=}//blkIterator=//blkIterator=}NumberReplicasNumberReplicasnum=//modifybyif(blockReplicationEnabled){if(num.liveReplicas==0){if missioningOnlymissioningOnlymissionedReplicas>0missionedReplicas==0)corruptFiles.add(newCorruptFileBlockInfo(src,blk));if(count>=maxCorruptFilesReturned)}}}elseif(num.liveReplicas()<2)corruptFiles.add(newCorruptFileBlockInfo(src,blk));if(count>=maxCorruptFilesReturned)}}在getLostFiles()LOG.info("ListCorruptFileBlocksLOG.info("ListCorruptFileBlocksreturned"+lostFiles.size()+"//modifybyduroper取消过滤掉Trash中的文件，因为Radi产生的parity在TrashLOG.info("getLostFilesreturning"+lostFiles.size()+"至此，corruptfileJob提调用computePrioritiesAndStartJobs(fslostFilesdetectTime)数包括文件系统fs，丢失Block的文件列表lostFiles以及当前时间。corruptBlock数目越将计算好优先级的文件列表按优先级排序，作为参数构建修复Jobjobpath的sequencefile。会根据raid.blockfix.filespertasksyncjobsplit阶段会按照该值设置的进行split20JobMapper主要是通过Reconstruter在task执行JobMap任务的类为继承自Mapper类的ReconstructionMapper类，其map函数是恢复的主要过程，其调用了BlockReconstruct类中的reconstructFile()数据块的获恢复，通过新建的Decode对象，调用其中的恢复函数。恢复过需要源In_rackRack内进行读lostblockblockFSDataInputStream输入流，根据偏移地址对该block进行在恢复的时候实现多个Block的并行。修改的策略是在getBlockLocations()返回一系列LocateBlocks之后，因为之后的时候默认是从某个Block所对应的DatanodeInfo[]数组中的第一个Datanode进行，所以在得到LocateBlocks后进行排序处理，将离当前执行现在某些情况下还是经常会从比较远的另一个Rack内进行Block，这样一来，本身Block所需要的传输时间已经和恢复相等了，那么Raid恢复In_rack恢复了。obk(存在本地节点)ort策略可以保证在存在In_rk节点的情况下，一定是从ack内进行lock，进而实现In_rk的恢复。//modify//modifybyduroperinttempIndex=0;if(reader!=null){intlocalRackNode=-//scanthearraytofindthelocalnode&localracknodefor(inti=0;i<nodes.length;i++){if(tempIndex==0&&reader==nodes[i]){//local//swapthelocalnodeandthenodeatposition0if(i!=0){swap(nodes,tempIndex,}if(localRackNode!=-1){if(localRackNode==0)localRackNodelocalRackNode=}}}elseif(localRackNode==-1&&isOnSameRack(reader,nodes[i]))//localracklocalRackNode=i;if(tempIndex!=0)break;}}//swapthelocalracknodeandthenodeatpositiontempIndexif(localRackNode!=-1&&localRackNode!=tempIndex){swap(nodes,tempIndex,localRackNode);}}//当遇到blk_- [139][141]在140上执行的时候，会发生将任意node前移的//putarandomnodeatposition0ifitisnotalocal/local-racknodeif(tempIndex==0&&nodes.length!=0){swap(nodes,0,}StripeBlockDecode的过程了，这一步与传统的Raid恢复一致，都是通过纠删码进行lostBlock的恢复。Block生成块的分在成功生成丢失Block分发策略比较简单，只要找到需要分发的Block所幸存的Datanode，将其列入AdvoidingDatanodeRackDatanode同一Rack的Datanode，方便再次出现故障的时候依然能够进行有效的In_rackParity块的Hadoop在Raid成功后莫名其妙地会将Parity文件移动到Trash回收站中，而进行编码恢复的时候，在返回corruptfile之后会进行一次文件的过滤，导致实验过不能对Parityfile进行Raid恢复。所以需要找到删除Parityfile的源码位置，即PurgeMonitor类中的duPurge()函parityfile后，才进行判断是否源文件经历了修改，如果修改过了，则重新进行编码生成parityfile，实验中并没有动到判断之后，即先进行判断，是否进行重新编码，然后决定是否删除该sourcefile的parityfile，个人觉得这才是正确的逻辑。优化执行JobIn_rackblockfixerTaskRack内的，否则若在另一个Rack的机器进行了Raid修复，生成的Block还是需RackRaid的过程，性能上得不到一点点的提Hadoop系统的Job分发策略，即进行Raid修复的时候，将blockfixer任务发送到lostblock节点所在的Rack节点(实验中如果没有关闭Datanode的话，甚至可以就是该节点)。HadoopJobJobJob行Task机，而是生成的Job交由任务调度器，最主要使用的是Hadoop默认的JobQueueTaskScheduleerFIFO( Out)调度器，Datanode上的进程tasktrakcer会定期向Jobtracker发送心跳信息，Jobtracker在接受到任意tasktracer的心跳信息后，综合考虑其内容，计算力等因素，为其分配相应的task，在的HRIR系统中，涉及到的只有两种Job，即Raidjob和Reconstructjob。需要在分发Reconstructjob的时候，掉其他Rack内的节点，为此，我们找到处理该逻辑的相关代码，修改Job分发策略。，，源码中分发给tasktracker的tasklist由assignTasks()函数分发。为此在该函数中添加一个判断，因为只是为了满足实验要求判断Job类型是否为修blockblockfixertasktasktrackerblock丢datanodeRackRackTask，，，//modifybyduroper//modifybyduroper }JobIn_rack优化文件恢复策实验过，囿于搭建的Hadoop集群节点数不多，当条带长度设置过长的时候会出现在put文件的blockstripe的两个或者以上block分发到了同一个Datanode上，这样一来，当手动使该Datanode失效，某些条带就会出现多BlockRaid下的In_rack恢复已经没有太大的意义了因为如果是采用Raid5的编码方案产生一个ParityBlock的情况下，同一Rack只能一个Block的错误。需要考虑这种情况的出现，此在Replicate和Raid编码获取corruptfile的时候进行一个判断，In_rack的RaidBlock丢失的文件(BlockStripe条带内的损坏数是因为RaidJob恢复整个文件中的Block)。RaidBlock//modify//modifybyintcorruptBlockInFile=0;NumberReplicasmyrepl=null;BlockInfoblocksinode.getBlocks可以由此得到该文件的BlockLOG.info("blocks'ssize="+blocks.length);for(BlockInfoblockinfo:blocks){myrepl=countNodes(blockinfo); }if(corruptBlockInFile==1){corruptFiles.add(newCorruptFileBlockInfo(src,blk));if(count>=maxCorruptFilesReturned)}Replication恢复考虑两个及两个以上的Block故障恢复//modify//modifyby//进行文件corruptblockINodeFile =intcorruptBlockInFile=0;NumberReplicasmyrepl=null;BlockInfo[]intcorruptBlockInFile=0;NumberReplicasmyrepl=null;BlockInfo[]blocks=myinode.getBlocks();LOG.info("replicate:blocks'ssize="+blocks.length);for(BlockInfoblockinfo:blocks){myrepl= }if(corruptBlockInFile>1Stringsrc=FSDirectory.getFullPathName(myinode);LOG.info("duropin:Replication>>addsrcfile"+src);}}catch(IOExceptionioe)//thenodemayhavealreadybeendeleted;ingoreitLOG.info("Invalidinode",ioe);}实验与分测试环境搭集群拓扑结启五台虚拟机，分别作为NameNode节点和四个DataNode节点，RaidNode部署Slave1Slave2Slave4存放在Rack2内。Datanode故障模实际的集群系统中，运行Datanode的机器上的某个文件发生丢失或者损Datanode发生宕机，断电等故障，因此，实验中应Datanode的故障。DatanodeNamenodeBlock丢失需要的时间比较长(超过了十分钟)DatanodeDatanode故障。所以通过实验，验证是否可以仅仅删除相应的Block来模拟此故障。HadoopDatanodeNamenodeheartbeat的丢失来完成的，因为检测的周期比较长，Block的话，Datanode在本地数据检测的时候发现Block丢失，会立即调用reportBadBlock()函数，该函数的具体功能文Block丢失。调用了updateNeedReplicationQueue()Block添加到待恢复的队列，唯一corruptBlock移除(Datanodenode移除了)。这并不会影响的恢复过程，所以可以使用rm命令删除Block的方法来模拟单Block的丢失。Datanoderm命令删除lost网络带宽限HRIR系统采用的是In_rack的Raid恢复，相比较于直接的恢复，所需要的Block个数一定是的，在最好的情况下，即stripeLenghth(条带长度为2，parityLength(编码块长度)为1的时候，至少需要2个Block才能完成恢复而In_rack恢复能达到更好的恢复效率一个重要的原因是Rack内的速度要远快于跨Rack的速度，因此在实验过要模拟出实际Rack的拓Rack2Slave4Slave4和其他Slaves之间网络传输的带宽，Rack内传输和跨Rack传输的速率比参考相关资1:51:201:200。式，使用恢复确定大小的Block，更改Slave4的网络带宽，多次实验，记录实际传输Block所花费的时间，得出相关的记录如下所示：Slave464MBBlock的实际发送时间(350Mbps左右，为了确保带宽限制的效果，设定虚拟机中逻辑Rack内的网络带宽为300Mbps，并且按照1:5或者1:10的带宽比，分别可以设置Slave4的网络带宽为60Mbps或30MbpsVMware中点击虚拟机->设置->网络适配器->高级，，比较In_rack和across_rack在恢复性能的差异，最主要的参数就是故障的恢复时间，对于In_rack的Raid恢复，分别计算其实际恢复的时间DT(DecodeTime)JobScheduleST(ScheduleTime)Joblog日志输出恢复的时间也包括两部分，一个是发送请求开始到目标节点收到该Block的时间TT(TransferTime)，还有一个是Block源节点在与目标节点完RT(ReplicateTime)，这两个时间可以通过NameNodeDatanode的logBlock恢复的时候，主要计算的是实际恢复的时间DT和TT，这样能够最直接反映处In_rack恢复在RackDatanode故障的时候，计算的是所有时间的累NamenodelostheartbeatBlock，Block丢失恢单BlockHadoop启动RaidNode设置Slave4关闭Hadoop系统的功删除Slave2上的等待In_rack开启Hadoop系统的功删除Slave1上的等待across_rack的恢复完成，测试出恢复时修改Slave4设置StripeLength2ParityLength1这样在实验中的Block分布比较直观。一般情况下实际Hadoop系统的Block设置以64MB为主并且进行多次实验，Block大小In_rack编码恢复across_rac恢复123In_rack编码恢复across_rac恢复3Block大小In_rack编码恢复across_rac恢复123In_rack编码恢复across_rac恢复3Block大小In_