基于IPSAN的云存储服务系统设计与实现

《基于IPSAN的云存储服务系统设计与实现》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

大连理工大学学位论文独创性声明作者郑重声明：所呈交的学位论文，是本人在导师的指导下进行研究工作所取得的成果。尽我所知，除文中已经注明引用内容和致谢的地方外，本论文不包含其他个人或集体已经发表的研究成果，也不包含其他已申请学位或其他用途使用过的成果。与我一同工作的同志对本研究所做的贡献均已在论文中做了明确的说明并表示了谢意。若有不实之处，本人愿意承担相关法律责任。学位论文题目：二基丑匝五型里墨盈剁鼬筐疰函鎏选许型蓥温L—一作者签名：匙篮筮日期：盈!至年—上月旦L日 大连理工大学专业学位硕士学位论文摘要现如今网络技术己相当成熟，各种网络应用也层出不穷，网络应用受到了企业和个人用户的欢迎并得到了大量的应用。在这个环境下，云计算因其先进的理念和明显的优越性，被认为是网络服务发展的方向。基于云计算的网络服务成为了如今的一个热门。云存储就是这样的一个服务。目前的云存储服务提供了文件快速上传、文件历史版本回退，文件共享等服务，满足了移动办公，和数据备份等市场需求，吸引了大量的用户。但由于目前网络传输介质发展的滞后，限制了使用因特网作为数据传输通道的云存储技术的工作效率。为了规避网络数据传输慢而导致的用户无法接受的延迟，现有的云存储服务多少都要占用客户端机器上的磁盘存储空间，将部分数据存储在用户本地。这样就满足不了云存储资源只存在“云”端的特性。为了满足云存储的这个特性，本文设计并实现了一个为大型团体用户提供云存储服务的网络虚拟磁盘系统，可以在不占用用户本地存储资源的情况下保证用户能够使用一般云存储服务应用。该系统在客户端中使用了磁盘过滤驱动来实现块级别的数据传输。应用接口层使用了将应用服务器部署在局域网内的设计，来提供多个应用服务器的并行访问服务。存储层是用iSCSI协议实现的IPSAN。iSCSI作为业界的一个标准协议，其安全性和效率都由专业标准组织保证。本文详细介绍了以上技术的基础知识和实现过程，并对系统的优劣做了总结。关键词：云存储；因特网小型计算机系统接口；存储区域网络；虚拟磁盘 DesignandImplementationofCloudStorageServiceSystemBasedonIP．SANAbs仃actTodaynetworktechnologyhasbeenquiteapplicationswhicharewidelyusedbythemajoritymature，andplentykindsofnetworkofenterprisesandindividualshassprungup．BecauseofadvancedCOnC印tSandobviousadvantages，cloudcomputing1Sconsideredasthedevelopmentaldirectionofthenetworkservices．Networkservicesbasedondoudtechnologysuchascloudstoragearebeingmoreandmorepopular．Tomeetrequirementslikemobileofficeanddatabackingup，doudstoragewhichattractsalargenumberofusersprovidesmanyservicessuchasfiles’quicklyuploading，historyversionrollbacking，sharingandSOon．Duetodevelopmentallagofthecurrentnetworktransmissionmedium，internetbandwidthhasbeenthebiggestfactorlimitingtheefficiencyofdoudstorage·Thecurrentimplementationsarenottherealsenseofcloud，becausethesedoudstorageserveroccupiesbitsofspaceoftheclientmachinetostorepartsofdatainthelocalinordertoavoidthosenetworktransmissiondelaywhichCanresultinbadusers’experiences·Inordertomeetthequalificationofrealsenseofcloudstorage，thepaperdesignsandimplementsanetworksystemtoprovidevirtualdisksbasedoncloudstorageforlargecorporateusersandensureUSerScallget也egeneralcloudstorageSel"vleesnot撇gupuserSIlocalresource．Thesystemusesdiskfilterdrivertechnologyinclienttoachievetheblock．1eveldatatransferring．Inapplicationinterfacelayer,serversaredeployedinLANSOthatitCanprovideconcurrentaccessesformultipleapplicationservers．Instoragelayer，IPSANisimplementedusinganindustrialstandardprotocoliSCSlwhosesafetyandefficiencyCanbeguaranteedbyprofessionalstandardsorganizatiOIlS．nispaperdescribesthebasicinformationandimplementation’Sprocessoftheabovesystem，anddoesasummaryofthesystem’sprosandcons．KeyWords：CloudStorage；iSCSI；SAN；VirtualDisk—II 大连理工大学专业学位硕士学位论文目录摘要⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．IAbstract⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．!⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．II1绪论⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯11．1研究背景⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯11．2国内外研究现状⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯21．3本文的研究意义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯31．4本文的组织结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯42相关技术基础介绍⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．52．1iSCSI(IntemetSmallComputerSystemInterface)协议⋯⋯⋯⋯⋯⋯⋯．．52．1．1iSCSI原理概述⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．52．1．2iSCSI寻址和命名规则和安全策略⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．72．2IP—SAN(StorageAreaNetwork)⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯～72．2．1常见存储模式⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯72．2．2IPSAN⋯⋯⋯．⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．⋯．⋯．．．．⋯⋯⋯⋯⋯⋯．．．．⋯．⋯⋯．．．．．．．．．92．3存储虚拟化⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．102．3．1存储虚拟化⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．102．3．3SAN中的虚拟化技术⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．1l2．4数据划分算法⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．112．4．1现有哈希数据划分算法⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．1l2．4．3Dynamo划分算法的工作⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯142．5Windows过滤驱动⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．142．5．1Windows操作系统驱动层次结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一142．5．2Windows过滤驱动⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．163需求分析⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯183．1任务概述⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．183．1．1使用术语⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯～183．1．2系统定义⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．183．1．3系统特点⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．183．2需求规定⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．193．2．1系统功能⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．193．2．2对性能的一般性约定⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．20-III- 基于IP．SAN的云存储服务设计与实现453．3运行环境⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．203．3．1客户端运行环境⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．203．3．2应用服务器运行环境⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一203．4用户界面⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一203．4．1客户端GUI界面⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．203．4．2应用服务器管理员管理界面⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一21基于IPSAN的网络虚拟磁盘的设计⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．224．I网络虚拟磁盘的总体结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．224．2物理存储层⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．234．3基础管理层⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯234．3．1iSCSI的会话⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯234．3．2iSCSl序列⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯244．3．3发起端的结构⋯．⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．244．3．4目标端的结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．254．3．5目标端的的状态转化⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一264．4应用服务层⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．284．4．1应用服务器的结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．284．4．2应用服务器的逻辑处理程序⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．294．4．3应用服务器的iSCSI发起端⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．304．4．4应用服务器的心跳守护进程⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯～304．4．5应用服务器发现策略⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯～304．4．6多种文件系统解决方案⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．314．5访问层⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．324．5．1客户端的结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．324．5．2块级别的数据操作⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．324．5．3数据的并行存储／访问⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．344．5．4带有虚拟节点的一致性哈希数据划分算法⋯⋯⋯⋯⋯⋯⋯⋯⋯．．34系统实现⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯365．1客户端的实现⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．365．1．1IRP结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯365．1．2IOSTACKLOCATION结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．375．1．3处理流程图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．38IV— 大连理工大学专业学位硕士学位论文5．1．4TDI(TransportDriverInterface，传输驱动接口)⋯⋯⋯⋯⋯⋯．395．2应用服务器的实现⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．405．2．1应用服务器逻辑处理流程⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一405．2．2磁盘到镜像文件的映射⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．4l5．2．3数据库表设计⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．435．2．4数据的服务器发现技术、负载均衡算法和并行访问⋯⋯⋯⋯⋯一445．2．5负载均衡算法和并行访问的细节⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．445．3存储层的实现⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．445．3．1应用服务器与iSCSI发起端的通信⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．455．3。lIPSAN的配置⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯456性能测试⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯466．1负载均衡⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．466．1．1静态拓扑结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．466．1．2动态拓扑结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一476．1．3测试结论⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．476．2并行数据传输⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．486．2．1并行性能测试⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一486．2．2测试结论⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．49结{仑⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．50参考文献⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯5l致谢⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一53大连理工大学学位论文版权使用授权书⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．54 大连理工大学专业学位硕士学位论文1绪论随着计算机技术的发展和广泛应用，计算机所产生的数据呈现出井喷式的增长，计算机数据也在人们日常的生活和工作中扮演着越来越重要的角色。对于数据的移动性、跨平台性、安全性、共享性也都有了更高的要求。单纯的DAS(Direct．attachedStorage，直接附接存储)存储4模式已经不能满足当前的数据存储应用需求。新的存储模式成为计算机数据存储的一个重要的课题。SaaS(SoftwareasaService，软件最l】服务)和云计算的提出给计算机的数据存储带来了一个新的方案——云存储。本文在已经成熟的技术如：iSCSI(IntemetSmallCompmerSystemInterface，因特网小型计算机系统接口)协议、SAN(StorageAreaNetwork，存储区域网络)、存储虚拟化、访问负载均衡等技术上，设计并实现了一个网络虚拟磁盘，用来满足SaaS、数据的跨平台性、数据的共享性、服务器的优良扩展性和良好的性能。1．1研究背景现在越来越多的用户习惯将许多原本放在本地计算机的文件放到各种“网盘”、“云盘”上。这样可以用很低廉的开销、甚至免费使用到额外的存储空间、享受到云端服务器提供的容错、版本恢复、多人共享等服务。用户无需再携带U盘、移动硬盘等移动设备，甚至是沉重的笔记本电脑，或是通过网络对多个计算机进行重复的传输。也不需要当自己的硬盘因为意外情况丢失数据之后再来痛苦地恢复。只需要将文件简单地放到“云”端，只要在能上网的地方就能方便得使用到这些文件，而且不用担心文件丢失。云存储通过分布式技术、特殊的存储网络拓扑实现了SaaS的要求，用户只需要通过客户端或者浏览器就能够访问到在“云”端的数据。而不需要考虑数据管理、基础设施如：并行读／写、分布式存储、网络、存储设备等。云存储技术使得这些东西对于用户都是透明地。常规的NAS(Network．attachedStorage，网络附连存储)虽然能满足用户的大部分需求，但其弊病在于集中访问时的效率很低，并且扩展性很差。于是就有人提出了具备良好扩展性，高性能而且提供块级别而不是文件级别通信的SAN，但早期的SAN是建立在FC(FiberChannel，光纤通道)协议之上的，在光纤上需要较大的硬件资金投入，而且需要专业的管理人员，光纤本身也对数据的传输距离有了很大的限制(光纤的理论距离限制是一万米，但实际到达五百米之后传输效率就会急剧下降)。2003年由IBM和Cisco共同发起的iSCSI被IETF(IntemetEngineeringTaskFore因特网工程任务组) 基于IP-SAN的云存储服务设计与实现批准成为一种新的协议标准。iSCSI．SAN就是通过架设在TCP／IP之上的iSCSI协议来代替FC协议传输数据，减少了设备成本的同时还消除了数据传输距离的限制，而且管理也不再需要光纤通信的专业人士，减少了管理成本。正是因为这些优势，目前许多成功的商业项目是在基于iSCSI的IPSAN存储框架下实现的。1．2国内外研究现状云存储一般分为存储层、基础管理层、应用接口层和访问层11]。存储层很容易理解，就是最基础的存储结构，可以是最简单的SCS!的DAS，可以是NAS，可以是FCSAN，也可以是利用iSCSI实现的IPSAN。存储设备通常都是通过光纤通道或者广域网等串联在一起，在结构上形成一个统一的、互联的大型存储网络。基础管理层需要将这些串联在一起的设备在逻辑上组织成一个大型的存储设备，使它们能很好地协作工作，对外提供统一的服务。这其中涉及到分布式文件系统、网格计算、集群互联通信等技术。同时该层还需要对数据的完整性、安全性、时效性提供保障，是云存储的核心。该层将存储相关的技术都进行了封装、隐藏。使得和存储相关的操作对于其用户是透明的。应用接口层是云存储保存数据所要提供的服务的对外接口。针对不同的服务，组织这些数据的逻辑，封装成让用户直接调用的接口。如网络硬盘、灾难备份等服务。访问层是用户通过对应用接口层接口的调用获得所需要的服务。云存储脱离了简单的存储的概念，而是一种通过软件将不同类型的存储资源整合起来对外提供数据存储和访问业务的服务。云存储的发展已经成为了存储技术的一个发展趋势。现今SaaS再不仅仅是一个概念，大量的应用进入市场并取得了巨大的成功。卖产品不如卖服务这一概念也在IT行业得到了验证。在这个大背景下，加之各种传统技术无法比拟的优势，云存储也越来越得到业界的推崇。在诞生不过几年的时间内就有了一大批的追随者。各种云存储服务也如雨后春笋一样层出不穷。DropBox无疑是云存储应用中的佼佼者。DropBox其实就是云存储中应用接口层的实现。其底层的存储核心都是依赖于亚马逊公司的付费云存储服务。亚马逊作为最早提供云计算服务的公司，其“即插即用”的云计算服务已经得到了广泛的应用。其中S3【2J(SimpleStorageService，简单存储服务)就是DropBox的存储层和基础管理层的实现。S3从架构上了来讲是一个全球性的SAN，当然在具体技术细节实现上，加入了很多Amazon自身的研究成果，尤其是在可靠性、可扩展性、易使用性非常出色。 大连理工大学专业学位硕士学位论文其中使用了分布的百分位99．9作为衡量的SLA(ServiceLevelAgreement，服务水平协议)保证能够在限定的时间之内应用程序能完成数据的传输。简单易用的对外接口方便了在其之上的应用接口层的实现。使用了SAN架构也让S3有了非常好的扩展性，在理论上让S3有了无限的存储空间。这些特性也让DropBox成为了一款优秀的网络文件同步软件。类似的知名软件还有苹果的iCloud、微软的SkyDfive。国内的云存储网络存储软件有金山快盘、华为网盘、搜狐企业网盘、百度网盘等等。这其中的优秀软件都很好地解决了用户对数据存储的绝大部分需求。提供很好的容错机制，快速的文件读取／上传，数据备份、版本恢复功能，多用户共享，私人数据加密数据等功能。但受限于目前的网络带宽问题，这些软件都有一个数据传输速度的问题。这些软件对于这个问题都采取了回避或者绕过的策略。一部分是让数据全部放在云端，客户端要使用的时候去下载。另一部分为了保证数据的实时操作是在数据保存在云端的同时在客户端也同样保存一份，再每次做两处数据的同步。许多软件还要限制文件的大小(比如DropBox就限制文件大小不能超过300MB)。但不论采取哪种方法，和云存储的概念都有不符。云存储要求用户不需要有本地磁盘的开销，就能达到和操作存储在本地磁盘的文件同样的实时性，而不需要花额外的时间来等待下载。1．3本文的研究意义由于当前的成熟云存储软件都是非开源的商业软件，具体实现的技术细节都只掌握在各个企业。本文中设计与实现的系统是一个将技术理论转化为技术实践的产品。在只有云存储架构理论知识支撑的情况下，完成其他部分技术细节，最终实现一个完整的产品。更具意义的是，本文中设计与实现的网络虚拟磁盘针对前面提到的云存储软件的不足进行了改进。将所有数据都存储在“云”端，客户端本地不占用任何的存储资源【3】。减少带宽压力是利用引入了额外的技术和服务器框架来实现的。而不是像现有的大部分软件选择损失云存储的特性来避开该问题。首先通过磁盘过滤驱动使得对数据的操作由一般的文件级别变为了块级别。每次数据发生改变只需要访问相应的块，而不需要访问整个文件，大大减小了网络带宽的压力。同时由于的块级别的数据访问，很容易就将文件进行了划分，方便了文件的并行访问。 基于IP．SAN的云存储服务设计与实现在应用接口层，将最耗时、带宽压力最大的广域网数据传输部分由通常的一对一的服务结构改为多对多的并行存储／访问的服务结构。得益于块级别数据访问的文件易划分的特性，多个在同一局域网的服务器同时向SAN发出数据请求，由于SAN也是基于块级别数据存储／访问的，所以就能将广域网上的单一线路访问，变为并行访问，大大缓解了带宽带来的效率限制。1．4本文的组织结构第一章绪论，从研究背景和国内外相关软件现状出发，对云存储的技术特点、优势进行了简要的阐述，同时对行业的发展前景和现状进行了说明。以非常具有代表性的mlnazonS3云存储服务为例。指出了当前的市场上软件有待改进的地方。第二章相关技术介绍，主要介绍设计系统所使用到的iSCSI协议，SAN网络存储结构，存储虚拟化技术，数据分划算法和Windows过滤驱动这些系统使用到的技术的基础理论知识。第三章为该系统的需求分析，指出了该系统的系统定位，并详细列举了需要实现的功能，和希望达到的预期使用效果。第四章以云存储的框架为基础，依次阐述该系统的各个层次的系统设计细节。给出相应的设计处理流程。同时对于如何处理绪论中针对当前云存储瓶颈——带宽限制的设计方案进行了详细的解释。并针对多用户共享文件的并行读／写数据一致性，服务器负载的设计和技术实现单独做了阐述。第五章阐述了本系统的主要技术实现。包括客户端的磁盘驱动程序对磁盘驱动IRP截获，封装成网络数据包的过程。应用服务器的请求处理，负载均衡的细节要求和实现。存储层iSCSI的通信过程和IPSAN的配置。第六章对本文使用并实现的负载均衡和并行访问的性能进行了测试。最后对全文的工作进行总结，以指出及下一步工作的方向。 大连理工大学专业学位硕士学位论文2相关技术基础介绍2．1iSOSI(InternetSmaIComputerSystemInterface)协议2．1．1jSOSI原理概述传统的存储设备，如本地磁盘是通过SCSI(SmallComputerSystemInterface，小型计算机系统接口)和数据总线或FC(FiberChannel，光纤通道)连接到计算机上，并通过相应的协议进行数据的传输。但是随着数据量的快速增长和互联网技术的发展，本地数据存储已经不能满足人们的海量数据存储、数据共享、数据备份等需求。因此iSCSI孕育而生。由名字不难看出iSCSIN是Internet与SCSI结合的产物。事实也是如此，iSCSI沿用了已经很成熟的SCSI技术，并保留了其优点。因为SCSI是一个业界通用数据传输的标准协议，所以不用担心数据传输格式的兼容性，同时还有现成的各个操作系统为其实现的驱动程序，除了简单的数据读／写功能，还有在不停机的状态下扩充存储容量等高级功能都能在不重新开发的情况直接使用。而对于SCSI的短板则依靠引入同样已经很成熟的“Internet”通信技术来解决。其中的原理也相当简单，就是使用现有的成本低廉的因特网来代替原有的传输数据得介质。其代替过程是将SCSI块数据封装成网络数据包，用TCP／IP协议将数据包通过因特网发送到“云”端，由“云”端的服务器来解析该网络数据包，取出SCSI数据，再交给服务器的存储设备去解析该协议，最后通过同样的方式返回数据。这样使得iSCSI具备了因特网低廉成本，无距离限制和应用范围广的优先。iSCSI通过利用成熟技术的组合用最低廉的办法解决了存储协议的难题，并最大地保存了两种技术的优点。这项技术己被IETF(IntemetEngineeringTaskForce，互联网工程任务组)制定为一个网络数据存储的标准协议，其使用的周知端口号是5003。iSCSI协议分为initiator(发起端)和target(目标端)两个部分【5J。通常发起端是具有网络数据操作请求的客户端，目标端是具有实际网络数据存储设备的服务器端。iSCSI是一个应用层协议。同时由操作系统的驱动程序实现的。一个完整的iSCSI体系结构由SCSI协议层，iSCSI数据封装层，TCP运输层，IP网络层，和物理链路层五个部分组成。如图2．1。 基于IP．SAN的云存储服务设计与实现I／O请求图2．1发起端和目标端的通信Fig．2．1ConnectionbetweeninitiatorandtargetiSCSI协议作为一个应用层的协议是承载在TCP／IP协议之上的【6】。由于iSCSI是块级别的协议，一次对网络数据的操作可能涉及到多个块，所以一次操作往往是由一次或多次TCP连接组成的。例如，当客户端执行一次对一个块的读取操作时，发起端操作系统先接收到用户要对某个数据块进行读取操作的请求，然后通过SCSI协议层将该请求转化为存储设备能够识别的SCSI命令，之后iSCSI数据封装层将该SCSI请求命令封装成iSCSI协议的PDU(ProtocolDataUnit，协议数据单元)，经过TCP／IP协议打包成网络数据包通过因特网向目标端发送该数据。经过TCP会话，目标到收到该数据包之后，通过ISO7层模型得到iSCSI协议的PDU。通过iSCSI数据封装层解封SCSI命令，再把该命令交给目标端的SCSI协议层，然后将该SCSI命令交由目标端的存储设备处理。待存储设备处理完毕后，目标端的SCSI协议层将得到的SCSI命令和得到的块数据按相同的方式发回给发起端，最后发起端的SCSI协议层通过得到的命令将用户请求的块数据提交给用户。圈 大连理工大学专业学位硕士学位论文2．1．2iSCSI寻址和命名规则和安全策略iSCSI的发起端和目标端被合称为iSCSI节点，每个iSCSI节点的命名【7J都是使用可扩展至255字节的全球唯一标识来命名的。每个节点的寻址沿用了DNS(DommnNameSystem，域名系统)的方式，使用IP地址加上端口号来唯一标识iSCSI节点的网络地址。同时使用255字节的IQN(iSCSIQualifiername，iSCSI资格命名)或IEEEEUI规则来组成iSCSI节点名称。只要有网络地址就能使用IQN规则，IQN格式如下：iqn．2013·03．edu．Dlut．00．54dda3285ac460838a16bc673ca9e20c．targetl2．如果名称不包含网络地址就需要去IEEE注册一个全球唯一的字符串从而来保证能得到全球唯一的定位。这样的命名和寻址规则使得很容易寻到存储设备的具体网络地址，同时当存储设备移动时，只需要修改网络地址就行，由于唯一的设备名称没有改变，很容易实现了存储设备的物理迁移。而且让存储设备和网络设备分离，使得同一个网络地址可以同时存在多个存储设备而不相互干扰。不同于常规的FCSAN，FCSAN使用的是光纤通道专用网络，本身就具有很高的安全性。使用iSCSI是通过TCPHP协议，数据同时通过因特网传输，使得安全性大大地降低了。iSCSI自身提供的认证技术只提供了相当初级的安全保护，不能够满足因特网的安全需求。目前较常见的是在iSCSI底层使用诸如IPSec[8】的加密技术来保证网络传输数据的完整性和安全性。并且可以防止网络传输过程中被监听或者恶意的数据篡改。并且这类方法对于上层都是透明的。另外还可以使用高级认证的方法，比如公有／私有密钥交换技术(Public／PrivateKeyExchange)。在iSCSI的注册过程会有iSCSI节点之间的协商，协商之后，在PDUs传输的时候就会选择提供的安全认证方式来保护数据的安全。2．2IP-SAN(StorageAreaNetwork)2．2．1常见存储模式最为常见也是产生时间最长的就是DAS，已有40多年的历史了。即使使用数据总线直接将存储设备，如磁盘、磁带等连接在计算机上，成为计算机的组成部分。使用SCSI协议在计算机和存储设备之间使用I／O通信的模式来对存储设备进行访问／存储操作。 基于IP-SAN的云存储服务设计与实现这种方式具有很多的局限。比如在如今流行的C／S和B／S框架下，许多的数据都要存储在服务器端，采用传统的DAS存储模式，服务器不但要处理逻辑业务还需要控制数据的存储和访问。随着数据量的增大给服务器的维护带来了巨大的挑战。同时，当需要扩大存储容量时，由于硬件接口的限制，容量有上限，当需要更多存储空间的时候只有添加更多的服务器，增加的额外的硬件成本。再者由于是使用数据总线进行直接连接，要求存储设备必须在计算机附近。由于这些限制，DAS的使用范围有很大的局限性。目前的使用范围是个人用户和存储规模很小的小型网络。针对DAS的局限性和网络的快速发展。NASl8】被提出来在大型网络中使用。首先NAS将业务逻辑与数据存储逻辑分离，简历专用的文件系统服务器来处理数据的存储和访问。将数据统一管理，释放了带宽。这样既减少了服务器维护的成本，数据的统一管理还使得对数据操作的效率远远高于DAS模式。NAS将NAS文件系统服务器和存储设备放置在同一个局域网内，方便互联。通过局域网来维护文件系统服务器和存储节点之间的连接只需要使用通常的局域网管理技术，管理成本很低。NAS对各种协议有良好的支持性，如CIFS(CommonInternetFileSystem，通用因特网文件系统)、NFS(NetworkFileSystem，网络文件系统)、FTP(FileTransportProtocol，文件传输协议)、HTTP(HypertextTransportProtocol，超文本传输协议)等。这使得其具有良好的跨平台性。例如Windows用户可以使用CIFS，Linux用户使用NFS就能访问同一个NAS文件系统服务器。此外用户也可以通过浏览器直接访问NAS文件系统服务器。然而，NAS也有其局限性，局域网的网络拓扑结构下需要巨型存储空间的时候，由于局域网中加入了过多的存储节点，会降低局域网的效率。所以，NAS不具备无限的扩展性。存储区域网络不在是一台计算机或者一个服务器架构，而是一个特殊的、专门用于数据存储的网络。传统的SAN存储网络，使用FC(FiberChannel，光纤通道)和交换机将存储节点互联起来形成光纤通信网络，将连接好各个光纤通信网络与各个业务服务器连接起来，最后将业务服务器和企业的局域网连接起来就搭建起了一个存储区域网络。SAN的网络拓扑结构如图2．2。 大连理工大学专业学位硕士学位论文冒胃豳目一I’胄粤目自幽2．2存储区域网络结构图Fig．2．2SANstructure这样的网络拓扑结构让每台业务服务器都能访问到所有的存储节点。并且当需要扩展存储空间的时候，只需要添加一组光纤通信网络，并使之与各个业务服务器互联即可。实现了无限扩展空间的功能，更加适应于目前海量数据存储的要求。2．2．2IPSANFCSAN的光纤通信网络的设备成本高，维护技术要求高，传输距离有限。这些因素都限制了SAN的发展。为了解决这些问题出现了IPSAN技术。IPSAN的核心就是用因特网的TCP／IP传输技术取代了光纤通道。其具体优势为：(1)使用廉价的因特网取代了成本高昂的光纤通道，降低了设备成本。(2)消除了使用光纤通道带来的数据传输距离限制。理论传输距离为无限远。(3)因特网的TCP／IP传输技术维护成本低，TCP／IP协议传输数据易于实现。但这样的设计也带来了一些问题：(1)因特网的带宽是IPSANt9】的性能瓶颈，因特网的数据传输速度和光纤通道的数据传输速度有较大的差距。(2)原本使用专用的光纤网络具有很好的安全性。现在让数据和命令通过TCP／IP协议在公开度高的因特网上传输增加了系统的安全隐患。(3)要使用额外的技术将SCSI命令和数据封装成网络消息包和从网络消息包获得SCSI命令和数据。增加了存储网络实现的工作量，且在存储网络工作时要产生额外的性能消耗来封装和处理网络消息包。 基于IP．SAN的云存储服务设计与实现虽然IPSAN带来了一些新的问题，但是这些问题可以通过现有的许多成熟技术来解决，如网络数据加密技术、负载均衡算法等。目前已有许多成熟的基于IPSAN的系统，这些项目的成功也证明了IPSAN的可行性。IPSAN也是现在云存储的一个主流技术。2．3存储虚拟化2．3．1存储虚拟化简单来说存储虚拟化【10】就是对存储设备就行抽象化处理，来屏蔽一些与逻辑无关的存储细节如存储节点个数、数据分布，或整合一些为逻辑业务服务的新功能如数据分类。存储虚拟化技术将所有存储资源整合起来成为一个大的“存储池”，并能将其中的数据按照不同的逻辑分门别类，在上层逻辑业务看来，这些数据都存在同一个巨大的存储设备上，并且按照一定的逻辑分类管理，呈现出一个简单，有逻辑的存储视图。使逻辑层只需要关注于数据的逻辑处理，而不需要关心数据的存储／访问细节。首先是基于主机的存储虚拟化技术⋯】。该虚拟化技术是通过安装在主机上的软件来对存储数据进行虚拟化的。因为将虚拟化软件安装在主机上，就不需要新的硬件投入。在成本上和系统结构简单度上都有很明显的优势。但将虚拟化的任务交给主机必然会消耗主机的CPU时钟，降低主机处理业务任务的能力。同时还可能因为不同软硬件导致各个主机之间产生额外的通信来达到虚拟化的一致性。受限制于不同的操作平台对虚拟化软件的兼容性。但是在使用成本上的优势也非常明显。另一种虚拟化技术是基于存储设备的。该技术同样不需要添加新的设备。是在各个存储设备上实现虚拟化软件。这样能带来很好地运行效率。因为在存储设备上开发软件更能结合硬件的特性进行开发。同时主机不再有额外的运行开销。且虚拟化软件由硬件厂商负责开发，让虚拟化过程对用户和业务逻辑开发人员都是透明的。这种技术由于在大型存储网络中存储设备种类繁多，且很可能来自多个硬件厂商。让多个厂商都按照统一标准来实现虚拟化是难以实现的。且由于将开发的任务交给了硬件厂商，没有办法定制完全适用于各个存储网络的虚拟化且维护相对麻烦。还有一种虚拟化技术是以存储网络为中心的。目前主要是用在NAS和SAN中。在SAN中实现虚拟化可以在发起端和目标端之间任意位置，所以又可以分为基于交换机的虚拟化、基于路由器的虚拟化和基于存储服务器的虚拟化。虽然使得存储网络复杂化，但使得管理更加容易，更容易定制逻辑业务需要的虚拟化方案。 大连理工大学专业学位硕士学位论文2．3．3SAN中的虚拟化技术目前SAN中的虚拟化技术结构主要分为对称和非对称两种u引。对称虚拟化技术是指数据和指令都公用相同的通道。非对称虚拟化技术是指两者用不同的通道。对称虚拟化即使包含基于交换机的虚拟化、基于路由器的虚拟化和基于专用存储服务器的虚拟化。前两种虚拟化技术是将虚拟化技术放在存储网络原有的硬件设备中实现，这种贴近硬件的设计能提高硬件处理数据和命令时的效率。另外一种是专门提供存储虚拟化的服务器。由在该服务器上实现数据的虚拟化。这样使得虚拟化技术更容易实现，且灵活度高。但相对于基于交换机和路由器的虚拟化技术增加了额外的硬件设各。且存储虚拟化服务器本身可能成为整个系统的性能瓶颈。非对称的虚拟化技术将数据与命令进行了分流处理。该技术需要一个专用的元数据服务器。虚拟化实现的软件也要分为两个部分。一部分布置在元数据服务器上，用来将整个存储网络的存储空间虚拟成为一个“存储池”，同时产生一个全局统一的数据视图。另一部分虚拟化软件布置在应用服务器上，成为虚拟化代理软件。服务与元数据服务器通信。应用服务器采用二级缓存技术，缓存一部分数据视同和元数据，当请求的数据在缓存中时直接提出数据。当数据不在缓存中时，依靠虚拟化代理软件向元数据服务器请求需要的元数据和相应的数据视图。这种方式虽然在结构设计上较为复杂，但却具有很好的扩展性，也不会引入新的性能瓶颈。2．4数据划分算法负载均衡就是需要将对服务器的请求尽可能地平均地发送给所有的服务器。从而不会出现有的服务器负载过大，有的服务器却只有很小的工作量。数据划分算法就行通过请求的某些特征来决定请求应该被派发到哪个服务器才能达到较好负载均衡效果的算法。2．4．1现有哈希数据划分算法最为常见的、也是最容易实现的是简单哈希算法。对于每一个存储数据的key取其哈希值。根据取模运算的结果决定数据最终存储在哪个存储节点或者从哪个数据节点获取。采用这种算法的最大缺陷就是当需要增加或移除存储节点的时，由于存储节点总数量的改变，原来计算的哈希值产生了改变，为了能正确取得存储节点总数改变之前的数据，需要全部重新计算哈希值。例如原来一共有8个节点，有一个存储数据的key值为14，14％8=6通过取模运算得到哈希值为6，那么该数据会被存储到编号为6的存储节点。当加入一个存储节点之 基于IP．SAN的云存储服务设计与实现后，当用户需要访问该数据时，由于存储节点的总数增加了，所以计算式变为了14％9=7，计算结果的哈希值是7，系统会到编号为7的存储节点去寻找需要的数据。这样使得存储网络的规模改变变得十分困难。显而易见这种方法保证不了哈希算法的单调性，不是一个好的哈希算法。后来由麻省理工学院针对简单哈希数据划分算法的以上缺陷提出了一种新的数据划分算法，一致性哈希数据划分算法【13】。该算法不在单一地去计算数据key值的哈希值。而是去计算整个存储网络中存储节点和存储数据的哈希值。其目的在于当存储节点数量改变时尽可能小改变已有的哈希值映射关系。Ob幽2．3哈希环Fig．2．3HashcircleObject3如图2-3，在一致性哈希数据划分算法中，哈希值的值域被视为一个“环”状结构。所有的数据节点都经过计算后，按照其哈希值分布在这个“环”上。存储数据也由其key计算一个哈希值。将存储数据的哈希值也放到这个“环”上，按照顺时针的顺序，第一个遇到的存储节点就是该数据的存储位置。同样讨论加入存储节点的情况。如果有一个数据在“环”上的位置位于相邻的存储节点A、B之间，B在“环”中位于A的顺时针方向。当新加入的存储节点的哈希值不在该数据与数据节点B的哈希值之间，即在“环”中，新加入的节点不在该数据和B之间。按照顺时针寻找存储节点的原则，该算法还是将该数据定位在存储节点B上。一致性哈希算法，在存储节点变化时只影响前后邻近的两个存储节点，将对系统的影响降至0了很／J、。如图2．4。 大连理工大学专业学位硕士学位论文图2．4一致性哈希算法Fig．2．4Consistenthashing一致性哈希算法的一个最为重要的缺陷就是数据节点负载均衡需要依赖于数据的哈希值分布的均匀程度。所以该算的在处理不可预见数据的负载均衡上效果不好。例如，在简单的只有3个存储节点A、B、C的情况下，A、B、C在“环”上按顺时针顺序排列。当存储数据的哈希值分布不很不均匀的时候，如大部分数据都在A、B之间，那么大部分的数据都存储在了存储节点B上，而存储节点A和C只存储少部分数据。如图2．5。图2．5一致性哈希算法的负载Fig．2．5Loadofconsistenthashing一嗽 基于IP．SAN的云存储服务设计与实现2．4．3Dynamo划分算法的工作由于存储网络中存在大量的存储节点，且随着时间的推移，可能会存在因为需要增加存储空间而增加存储节点、存储节点故障失效等情况。Amazon的Dynamo{21就是在节点动态加入、移除时，保证各个存储节点负载均衡的一种划分算法。它是在一致性哈希数据划分算法的基础上增加了虚拟节点来实现这种效果的。2．5Windows过滤驱动2．5．1Windows操作系统驱动层次结构Windows的操作系统总体上可分为用户模式和内核模式，内核模式的接口给用户模式的应用程序提供相应的服务。现代操作系统都是基于分层结构设计的，每层都有若干组件构成，整个操作系统的运行基于上层对下层组件的调用，越是靠近底层的组件其操作权限越高。Windows操作系统设计的主要思想是小内核，各组件之间通过消息通信ll4|。下面通过操作系统的构成简图来反映其整体的架构。如图2．6。用户模式应用程序Win32子系统卜卜—叫其他子系统内核模式I系统服务函数执行体组件IO管理器l对象管理器|进程管理嚣虚拟内存理嚣l配置管理嚣l其他组件驱动程序内核—————L硬件抽象层具体硬件图2．6Windows驱动结构Fig．2．6Windowsdriverstructure 大连理工大学专业学位硕士学位论文在Windows操作系统的组成中驱动程序占有至关重要的地位，在IO管理器接收应用程序的请求后创建相应的IPR并将其传送给驱动程序处理。其主要的处理有以下几种：(1)根据IRP请求直接操作具体硬件，然后完成IRP并返回；(2)转发此IRP到更底层的驱动，等待该驱动的返回；(3)将该IRP分配新的IRP到其他驱动程序中，等待返回；以上三种处理操作经常是混合使用而不是单独操作。这里以系统最常用的CreateFile为例概述从应用程序到驱动程序比较详细的流程：首先应用程序调用Win32子系统的APICreateFile。接着在CreateFile中会调用Ntdll．dll模块中创建文件的接口NtCreateFile，通过调用该接口，此次调用过程从用户级别转为了内核级别入到内核模式。进入内核级别后NtCreateFile会调用名为NeCreateFile的系统服务函数，通过调用该函数系统函数通知IO管理器创建IRP(10RequestPackage，I／O请求包)。IRP是驱动程序中的重要数据结构，驱动程序的运行就是靠IRP驱动的。随后将IRP传输到设备的驱动程序，驱动程序根据IRP进行相应的操作，比如对端口的读操作，根据不同的硬件平台有不同的硬件抽象层来解析操作。图2．7是Windows的驱动流程图：应用程序I回r+-Yp)Ii调用cre抛孙¨，-iti￡t10管理嚣创l建并发送lRPVin32子系统(kemeEl2．dlI)询田审1=：墨耐她0NativeAPl系统服务咖哦INat¨eAPI(ntdll．dH)内核模式7I糸珑职艿喇鳅图2．7Windows驱动流程图Fig．2．7Windowsdriverflowchart在了解设备的层次结构之前，我们需要先了解几个名词：(1)PDO(PhysicDeviceObject，物理设备对象)：也被称为底层驱动，即接近物理设备的地方，一般由总线驱动程序创建。子域AttachedDevice会记录FDO的位置。 基于IP．SAN的云存储服务设计与实现(2)FDO(FoundationalDeviceObject功能设备对象)：被称为高层驱动，即接近于发出IO请求的地方。(3)过滤驱动：存在于FDO和PDO之间的驱动，是可以多个嵌套的，不是必须的驱动。Windows驱动中设备的高层次一般是针对具体功能的功能设备对象，用于对应具体软件操作到设备指令的转化，如FAT、NTFS等文件系统的驱动程序。最底层是对应真实物理设备的物理设备对象，调用硬件厂商提供的操作硬件接口，和硬件直接通信。在这之间还可能会存在中间的中级驱动程序，如过滤驱动程序、类驱动程序等。现实一些特殊的功能编程。设备的层次结构如图2．8。图2．8设备层次结构图Fig．2．8Devicelayerstructure2．5．2Windows过滤驱动在Windows系统中与安全相关的驱动开发中，过滤是很重要的概念，是指在不影响上下层接口的情况下，在Windows系统内核中加入的新层，即实现了在不影响上层软件和下层真实驱动程序的前提下，加入了所需要的新功能。对于一般的I／O请求包，过滤驱动程序不对其做任何处理，直接将该请求转发给底层驱动程序，对于底层驱动该过滤驱动是透明地，当拦截到的I／O请求包的请求类型在 大连理工大学专业学位硕士学位论文驱动程序的派遣函数中注册了相应的处理例程时，这时过滤驱动程序才对其进行处理。下面介绍一个最简单的过滤驱动程序的模型，它主要是让FDO和PDO之间的请求完全通过不加干涉。进行过滤是使用的最主要方法是对一个Windows中已存在设备对象进行绑定，即通过编程可以生成一个虚拟的设备对象，绑定在一个真实的设备上，经过绑定后操作系统原本发给真实设备的请求，就会首先发送到这个虚拟设备上。过滤驱动程序的主要功能如下：(1)驱动程序可以修改原本IRP请求的行为，且该过程是对上下层次都是透明地，不需要对原有的体系进行编码。(2)可以增加附加的驱动功能。(3)可以屏蔽一些原有驱动程序提供的代价昂贵但是不实用的功能。 基于IP．SAN的云存储服务设计与实现3需求分析随着企业数据信息化的快速增长和数据网络传输的快速发展。多终端数据共享、数据安全备份、数据实时处理、海量数据的存储在日常的工作生活中扮演了越来越重要的角色。云存储技术就是针对这些问题解决方案。目前也有许多云存储的软件在市面上流行，但由于网络传输介质的带宽限制，在使用客户端软件的终端上都要占用存储资源来达到数据的实时处理。这违背了云存储所有数据存储在“云”端服务器，不占用用户任何存储资源的特性相违背。针对这种情况，本文通过使用目前成熟的IPSAN技术，Windows驱动编程等技术，并自行设计了并行数据存储／访问的客户端——应用服务器机制。在针对局域网多用户的使用环境中达到不占用任何客户端存储资源提供云存储服务的需求。3．1任务概述3．1．1使用术语客户端：指安装了该虚拟磁盘客户端软件的计算机终端。应用服务器：布置于客户端群体局域网内的专用服务器，为客户端提供数据镜像，为客户端提供可选的并行从SAN存储网络读／写数据的功能。挂载：指用于通过客户端软件向应用服务器发出加载用户指定网络磁盘的命令，应用服务器返回相关数据，并在客户端计算中如Windows系统的“我的电脑”中出现相应的供用户操作的磁盘。从用户视角上看，与本地磁盘没有区别。3．1．2系统定义该基于IPSAN实现的网络虚拟磁盘提供的是网络云存储服务。该虚拟磁盘有使用的限定范围，针对的是同局域网存储大量用户的使用团体，如：企业、学校等。不适用于一般的个人用户。该系统在不占用客户端任何存储资源的情况下提供常规的数据即时存储／访问功能，共享文件并行写入的文件冲突解决功能，多人文件共享功能，文件版本回退功能(版本控制功能有版本控制模块实现)。3．1．3系统特点该系统的特点如下：(1)该系统不需要占用客户端任何的存储资源。 大连理工大学专业学位硕士学位论文(2)该系统的用户为同局域网存储大量用户的使用团体。不适用于一般的个人用户。(3)该系统提供多人文件共享的功能。，(4)该系统提供专用的版本控制器，用于解决共享文件并行写的文件冲突和版本回退等功能。3．2需求规定3．2．1系统功能该系统为用户提供的功能如下：(1)安装了客户端软件并配置完成之后，用户可以通过客户端软件申请用户账号。(2)应用服务器提供账号、密码验证，保护数据隐私。(3)用于通过客户端软件申请网络磁盘空间，并能直接挂载，挂载后再本地显示为本地磁盘，但实际并不占用用户的本地磁盘空间。(4)每个用户可拥有多块网络磁盘。并可以同时挂载。同时挂载网络磁盘的数量受限于本地操作系统磁盘管理数量的限制。(5)挂载磁盘后，在磁盘内可以进行如本地磁盘一样的所有文件读、写、创建、删除等操作。(6)提供“群组磁盘”功能，即该网络磁盘可由其所对应用户组的任何成员挂载、使用。达到文件共享的目的。(7)当共享文件发生并行写入操作时，系统能智能合并写入数据，如有冲突可提示、引导用户解决冲突。(8)提供文件的历史版本，具有文件数据的回退功能。(9)没有理论上的文件大小限制。(10)保证用户数据在网络传输和存储过程中的正确性。(11)管理员无法获取用户文件。(以上7、8项需求的设计与实现不在本论文范围之内。)该系统为管理员提供的功能如下：(1)可从账号可由客户端申请的方式修改为管理员分配得方式，方便管理。(2)管理员能控制用户申请磁盘空间大小。(3)管理员可以修改账号所属群组。(4)管理员通过在局域网中配置多台应用服务器来并行存储／访问“云”端数据。(5)保证应用服务器的负载均衡。19一 ＼基于IP-SAN的云存储服务设计与实现(6)提供应用服务器的动态扩充。3．2．2对性能的一般性约定(1)用户只需要第一次申请磁盘对磁盘进行格式化，以后都挂载后直接使用。(2)挂载过程只需要一般U盘加载的时间或更短，实现“即插即用”。(3)对于小数据量的文件操作能实现与本地文件操作没有用户体验上的差别。(4)对于部分数据量特大，且需要一次加载完成再运行的数据允许网络磁盘有一定延迟，但保证在用户可接受范围内。具体延迟取决于局域网配置应用服务器的数量，即并行程度和具体网络带宽的拥塞情况。(5)应用服务器的动态扩充和移入不需要停止已有应用服务器对用户进行中的服务，扩充完整后所有应用服务器能获得动态的负载均衡。3．3运行环境3．3．1客户端运行环境客户端计算机对于硬件没有特殊的要求。需要有10／100M自适应的网络接口卡接入应用服务器所在的局域网，具备正常的网络通信能力。客户端需要安装兼容客户端软件操作系统。该论文默认客户端使用的是Windows操作系统。3．3．2应用服务器运行环境CentOS6．0，或相同Linux核心的操作系统。具备正常的因特网通信能力。安装MySQL数据库。2GB或更高的运行内存。安装iSCSI发起端软件。3．4用户界面3。4。1客户端GUl界面用户客户端GUI界面的使用Windows单文档结构的图形化界面。提供用户注册、登录、登出功能集合；群组磁盘管理功能集合；个人磁盘管理功能集合；文件系统磁盘情况；和文件目录结构。客户端的软件设计如图3。1。 大连理工大学专业学位硕士学位论文Fig．3．1ClientGUI3．4．2应用服务器管理员管理界面虽然最简单的实现是让管理员直接操作应用服务器的数据库，这样同时能让管理员得到最佳的操作灵活度。但由于需要将用户数据对管理员隐藏，所以需要限制管理员的权限。不能让管理员直接操作数据库，因此需要给管理员实现一个管理工具，限制其对数据库的操作。该系统中使用B／S结构实现。 基于IP．SAN的云存储服务设计与实现4基于IPSAN的网络虚拟磁盘的设计本论文中设计与实现的网络虚拟磁盘是云存储服务的一个实现。遵循云存储服务结构模型。在详细技术设计中先介绍系统整体的架构，再按照云存储的4层结构依次介绍。4．1网络虚拟磁盘的总体结构在云存储服务的结构模型中，最上层的是用户访问层。在该系统中可理解为安装有客户端程序的终端计算机。在每个用户的局域网内都至少需要一台应用服务器来支撑网络虚拟磁盘的业务逻辑。应用服务器也就是云存储服务结构模型中的应用接口层。这样就形成了一个拥有若干台用户终端和若干台应用服务器组成的局域网。该系统中的应用层级就是有这样的局域网络组成，也是交由客户使用、维护的部分。若干个这样的应用层的局域网络通过因特网连接到提供存储服务的存储区域网络来获得存储服务存储区域网络就包括云存储服务结构模型的基础管理层和存储层。如图41．图4．1网络虚拟磁盘总体结构图Fig．4．1Networkvirtualdiskstructure其中，所有的基础管理层服务器对应用层级中的应用服务器都应该是可见的，而且能够进行网络通信。存储区域网络由所有的基础管理服务器都通过交换机和所有的存储设备相连组成。 大连理工大学专业学位硕士学位论文4．2物理存储层物理存储层就是真实的存储设备，如磁盘、磁带等设备。由于SAN只关注数据本身在不关注存储数据的物理介质，而且对于物理存储设备的数量没有理论上的限制。所以可以使大量的普通廉价存储设备连入存储区域网络来组成物理存储层。物理层只与基础管理层通信，其通信，数据的一致性，分布式存储都是由SAN管理软件来实现的。4．3基础管理层SAN技术如今己非常成熟，基础管理服务器上的SAN管理软件也有许多的成熟可选产品。该系统中对于该层的主要设计与实现是iSCSI完成应用服务器与基础管理服务器的通信。在使用iSCSI的IPSAN结构中，依靠安装在SAN的直接服务用户终端上的initiator(发起端)程序和SAN基础管理服务器上的target(目标端)程序通信。4．3．1iSCSl的会话由于iSCSI是一个网络的应用层协议，其发起端和目标端的一次单元操作不是以传输层的一个iSCSI连接作为基础单位的。由于iSCSI协议承载在TCP／IP协议之上，一次iSCSI连接就是一次TCP连接。而是以一次iSCSI会话来计算。所以一次iSCSI会话可能包含一个或多个iSCSI连接。iSCSI的会话通过会话ID来标识。这个ID是一个二元组，包含ISID(InitiatorSessionID，发起端会话ID)和TSID(TargetSessionID，目标端会话ID)。属于同一个I-TNexus(I．T联结)会话的iSCSI连接都具有相同的二元组来标识。iSCSI会话分为：发现会话，用于发起端探测发现可用的目标端。普通会话，用户一般的命令、数据、参数的传输。每种会话都是由发起端发起的。且包含三个阶段：登陆会话阶段、完全功能阶段和登出会话阶段。具体流程是：发起端先与目标端进行TCP三次握手，建立网络连接。然后向目标端发出登录会话请求和协议版本、SSID等参数。目标端对其安全身份进行验证。之后再进行会话的参数协商。如果成功就返回一个登录会话接受信息，并进入完全功能阶段。如果安全身份认证或参数协商过程产生错误，则进入登出会话阶段，结束会话。进入完全功能阶段后就是发起端将SCSI命令、数据等信息封装到PDU中并通过连接发送到目标端，目标端处理完成之后再返回结果。当一次会话的操作完成后双方进入登出会员阶段，结束会话。 ＼基于IP．SAN的云存储服务设计与实现4．3．2iSCSI序列由于使用的是因特网来充当传输介质，iSCSI数据包到达目标端的顺序和发起端的发送顺序是不一样的。其要求序列化的信息有：数据操作命令序列化，操作数据序列化和执行所处状态的序列化【17】。所以需要提供一些数据来为参数下这些网络包来提供依据。对于数据操作命令序列。用CmdSN(CommandSequenceNumber，命令序列编号)来作为序列化的依据。当一次iSCSI会话开始的时候就CmdSN就开始计算，以后的每次iSCSI命令都将该值递增。在数据操作命令的序列化中，发起端需要有一个缓冲区来保存已发送但还没有被确认的命令包，目标端需要一个缓冲区来保存已经接收到但尚未序列化的数据操作命令。这就类似于TCP／IP协议的网络数据包按序到达大的机制类似。用缓冲区“窗口”移动来进行序列化过程。最终目标端依靠CmdSN将所有数据序列化，在将命令传送给SCSI层进行处理。iSCSI的PDU(ProtocolDataUnit，协议数据单元)可以分为数据PDU和R2T(RequesttoTransfer，请求传输)PDU两种。两种PDU分别使用DataSN(DataSequenceNumber，数据序列编号)和R．2TSN(RequemToTransferSequenceNumber，请求传输序列编号)；来作为序列化的依据，其序列化的过程与命令序列化类似。同理，对于iSCSI的执行所处状态消息的序列化原理也是一样。依靠一个称为StatSN(StarSequenceNumber，状态序列编号)的参数来保证序列的正确性。4．3．3发起端的结构传统的SCSI主要使用的是操作系统的多层驱动技术来实现的。首先是文件系统通过I／O请求将对文件的操作信息发送到类驱动程序中，类驱动程序处理该信息，将逻辑上的文件信息转化为磁盘上的块信息，并生成所请求文件操作的响应SCSI请求，该SCSI请求在转发到SCSI的中间驱动程序，该程序负责对该次SCSI请求进行资源确认，生成SCSICDB(CommandDescriptorBlock，SCSI命令表示块)，再讲所有的SCSICDB排队发送到真是的物理设备。在iSCSI中，中间驱动程序处理之后需要将SCSI命令和数据发送到发起端的SCSICDB处理程序。如果使用的硬件处理方式，如使用现有的SCSIHBA驱动或TCP卸载引擎网卡来进行命令、数据封装的过程。就不需要自行编程实现软件来达到这个目的。之中，由该程序将SCSI命令和数据封装成iSCSI协议的PDU，在经由网络发送到目标端。 大连理工大学专业学位硕士学位论文在发起端Il5J的SCSICDB处理程序中，需要一个守护线程用来发送SCSI命令，该线程有三个命令队列SCSI命令队列，立即SCSI命令队列和R2T(RequestToTransfer，请求发送)命令队列。三个队列的优先级从高到低是：立即命令队列，R2T命令队列，SCSI命令队列。当三个队列中存在待发送的命令时，该线程出于激活状态并行送这些命令。还需要一个守护线程来接收iSCSI命令，当有iSCSI命令到达时，该线程被唤醒并处理到达iSCSI命令的PDU，如果是iSCSI控制命令则由该处理程序产生相应的处理，如收到的是会话登录确认消息，那么该次会话就开始进入完全功能阶段，处理程序向目标到发送具体操作的SCSI命令和数据。如果是普通的SCSI命令和数据，则将这些信息交给上层的SCSI中间驱动程序处理，并等待响应。4．3．4目标端的结构本论文中实现的网络虚拟磁盘的目标端程序【16】使用的是纯软件方式实现的。只需要NIC(NetworkInterfaceCard，网络接口卡)，相对于TOC(TCPOffioadEngine，TCP卸载引擎)网卡实现方式和iSCSIHBA卡实现方式减少了设备成本。由存软件来封装和解析iSCSI协议的PDU(ProtocolDataUnit，协议数据单元)，并将其打包为TCP／IP协议的网络数据包。目标端程序除了基本的网络数据收发功能，还有核心的FETD(Front—endTargetDriver，前段目标驱动)和STML(SCSITargetMiddleLevel，SCSI目标中间层)。FETD负责从网络数据包中提取出iSCSI的PDU，并将其解释为SCSI命令和数据。STML则用来处理命令和数据，当然还包括SCSI的错误处理和维持SCSI的状态信息。FETD和STML通过操作系统的API进行通信。STML包含两个线程，一个STT(SCSITargetThread，SCSI目标线程)用来处理SCSI命令。一个SSPT(SCSISignalProcessingThread，SCSI信号处理线程)来处理异步到达的信号。对于一次读数据的操作FETD负责接收来自发起端的网络数据包，并将解析之后的命令和数据交给SSPT处理。SSPT将数据取出并交给FETD，FETD将其封装成网络数据包然后放在发送队列中等待发送，数据发送成功后通知SSPT，该次读操作处理就完成了。对于一次写数据操作，FETD想将SCSI命令由网络数据包解析出来，再交给SSPT，SSPT发现是一个写数据请求时，其分配数据空间，并通过FETD向发起端发消息，请 ＼基于肚SAN的云存储服务设计与实现求要写的数据。待数据从发起端发送过来，再由FETD解析，再交给SSPT处理，写操作完成后，SSPT通知FETD在向发起端发送的消息队列里加入完成写操作的回应。最后消息发送给发起端，该过程结束。4．3．5目标端的的状态转化发起端和目标端的状态转化如图4．2，4．3：图4．2发起端的状态图Fig．4．2Thestatediagramoftheinitiator在iSCSI协议中需要有发起端和目标端之间的认真和参数协商，所以其状态较多。其具体状态有：FREE：初始化未连接或连接已经关闭。XPT_UP：发起端没有这种状态。目标端是连接成功等待登录。XPT—WAIT：发起端已发送连接请求并等待目标端响应。目标端没有这种状态。INLOGIN：正在登陆。LOGGEDIN：登陆成功，正处在完全功能阶段。IN—LOGOUT．．发起端没有这种状态。目标端执行登出的相关过程处理。LOGOUT_REQUEST：发出登出请求并等待回应。目标端没有这种状态。CLEANWAIT：等待清理会话中的连接资源和数据。对应各个状态转化的状态触发事件有： 大连理工大学专业学位硕士学位论文CONNECTREQUEST：发起端发送连接请求。CONNECTTIMEOUT：发起端请求连接超时。INCONNECT：目标端接收到连接请求并开始连接。CONNECTEDIN．发起端连接建立成功，进入登录LOGININ状态。LOGINREQUEST：目标端接收登录请求LOGINSUCCESS：发起端收到登录请求的响应；目标端完成登录响应。LOGINTIMEOUT：发起端登录请求超时，目标端断开连接。LOGINFAIL：发起端登录请求失败，收到返回消息；目标端拒绝登录请求。CLOSE—SESSION：发起端中因相同会话多个连接中，任意一个连接提出了结束会话请求；目标端收到某次会话中的结束会话请求。LOGOUTINITIATORREQUEST：发起端发送登出请求。LOGOUT—INITIATOR_-ASYNCHRONOUS：目标器接收到异步登出消息。LOGOUT．TARGETRECEIVE：目标端收到登出请求响应。LOGOUT—TARGET—ASYNCHRONOUS：目标端发送异步登出消息。LOGOUTINITIATORRECEWE：发起端收到登出请求。LOGOUT—TARGET_REQUEST：目标端发送登出请求。CLEANUP：数据发送、接收超时。需要放弃本次数据传输，断开连接。清理连接数据。图4．3目标端的状态图Fig．4．3Thestatediagramofthetarget 基于IP-SAN的云存储服务设计与实现4．4应用服务层应用服务层是该系统设计与实现的主要工作所在，也是系统设计的核心。该系统的业务逻辑实现都是由该层中的服务器提供。将应用服务器安置在客户端所在的局域网内，虽然增加了用户的设备成本和管理成本，由于这个限制也使得该系统的用户群体中流失了一般的个人用户，而主要适用于同局域网有大量用户的企业、学校等单位。但这样这设计是因为目前因特网传输介质发展的速度较慢，不能满足于云存储的网络带宽要求，所以只能退而求其次将应用服务器架设在客户端所在的局域网，用局域网的带宽来达到该系统中数据实时传输的效果。同时，因为应用服务器和客户端在同一个局域网，客户端和应用服务器的连接不暴露在安全隐患大并且不稳定的因特网上，形成了一个类似专用网络的结果，大大增加了数据传输的安全性、完整性和一致性。4．4．1应用服务器的结构在该论文中设计和实现的网络虚拟磁盘的应用服务器是存在在客户端程序所在的局域网内的。应用服务器主要分为三个模块：逻辑处理程序、心跳守护进程和iSCSI发起端程序。其应用服务器结构如图4．4。应用服务器图4．4应用服务器的结构图Fig．4．4Applicationserverstructure 大连理工大学专业学位硕士学位论文4．4．2应用服务器的逻辑处理程序逻辑处理程序是实现网络虚拟磁盘逻辑业务的。其主要功能是接收从同局域网内的客户端发送来的请求，对这些请求处理并返回处理结果或数据。主要的请求有：(1)注册请求：应用服务器接收到客户端发来的注册请求和相关注册数据，经过定制的审核后将新用户数据写入数据库。(2)登录请求：服务器从数据库取得用户数据，经密码验证后返回登录结果。(3)申请磁盘请求：经过定制的审核，应用服务器不为用户开辟空间，只是简单的简历一个空的镜像文件，镜像文件的大小要求与客户申请的磁盘空间大小相同，然后再在数据库里面加入用户、网络磁盘和该镜像文件大的对应关系。申请群组磁盘过程与此类似，在原有基础上还需要记录群组名称。(4)邀请用户加入群组：某群组的建立人可以邀请其他用户加入其建立的群组从而能挂载该群组的网络磁盘，访问里面的文件。该请求应用服务器只需要在通过验证后将群组信息加入到被邀请者的用户信息中即可。(5)挂载个人网络磁盘申请：当用户登录之后申请挂载网络磁盘，应用服务器到数据库的个人网络磁盘表中找到该用户建立的所有的磁盘信息。然后返回给用户，用户从返回的数据中选择了要挂载的网络磁盘之后，服务器通过该网络磁盘与应用服务器本地镜像文件的对应关系，找到相应的镜像文件，然后为用户提供数据服务。(6)挂载群组磁盘申请：当用户登录后并申请挂载磁盘时，应用服务器先从数据库的用户表中取出该用户对应的群组。再到群组磁盘表中，通过已获得的群组名找到所有的群组磁盘信息并返回给用户，之后的操作和挂载个人网络磁盘相同。(7)用户对网络磁盘的读操作：由于每个磁盘的存储空间都是连续的。所以客户端可以将对磁盘某个块的操作转化为对磁盘起始地址多少偏移量的数据块的操作。所以用户对个偏移量数据块的操作可以很容易转化为“对应用服务器上该网络磁盘对应的镜像文件的多少偏移量开始的多长的数据进行操作”。因为应用服务器实际上是不存储数据的，镜像文件只是在逻辑上存在与应用服务器，真实的数据是存储在“云”端的SAN上，逻辑服务器需要将对该镜像文件的“多少偏移量开始的多长的数据”的请求，通过驱动程序交由iSCSI发起端程序，并将其转化为PDU通过因特网发送给iSCSI目标端处理并返回请求的数据。最后数据再原路返回给用户。(8)用户对网络磁盘的写操作：与对网络磁盘的读操作的流程类似。 基于IP．SAN的云存储服务设计与实现4．4．3应用服务器的iSCSI发起端应用服务器的iSCSI的发起端主要负责应用服务器的底层数据存储功能。通过将SCSI请求转化为iSCSIPDU通过因特网将数据存储在“云”端的SAN中，从而不需要应用服务器对存储设备的成本投入，减少了维护存储设备的环节，消除了DAS的存储空间扩展大小的限制，还提供了SAN带有的数据一致性、共享性等特性。4．4．4应用服务器的心跳守护进程如果让每个客户端都手动配置局域网内提供服务的应用服务器，不但给用户带来了额外操作。还在更改局域网内应用服务器的地址或数量时候需要所有用户再次修改配置。当一个应用服务器意外失效的时候，客户端也不能察觉，仍然向该应用服务器发送请求，会导致局域网网络效率降低，用户数据处理延迟大大增大。针对这些问题，本论文中的网络虚拟磁盘系统采用了自己设计的一种轮询的广播心跳发现策略(该策略在下一节介绍)。该策略在应用服务器上已一个独立的心跳守护进程的形式存在。让客户端能动态地发现应用服务器的地址修改、数量改变、和意外失效的情况。保证在这些情况下，客户端能动态知道当前局域网内所有提供正常服务器的应用服务器的地址。4．4．5应用服务器发现策略当管理员在局域网内开启或停止一个应用服务器的服务时，怎么让正在使用网络虚拟磁盘的用户得知道该消息是一个很重要的问题。当有应用服务器加入局域网并开始提供服务，如果客户端没有被告知该消息，那么该应用服务器对于所有客户端是透明的，会导致没有客服端向该服务器请求服务。这种情况由广播消息来解决，由于客户端和应用服务器都在同一个局域网，当有新的应用服务器加入局域网并提供服务之前可以简单发送一个广播消息让所有客户端都得知这一消息。很容易就解决了前面的问题。但当一个应用服务器突然失效这种广播的方法就失效了。此时由于客户端不知道该应用服务器已经失效，仍然会向这个失效的应用服务器发送请求会严重影响系统工作效率。另一种方案是加入一个专用的服务器来管理所有的应用服务器的IP地址，并将服务的应用服务器地址告知客户端。这样的设计不但增加了带宽负担和成本投入，还引入了单点失效。不是一种可取的方式。该系统设计了一种基于轮询的广播心跳发现策略。(1)应用服务器中每过一定时间有一个应用服务器在局域网中广播一次心跳消息。(2)所有收到该消息的应用服务器都返回一个心跳相应消息。发起心跳消息的应用服务器将收到回复的所有应用服务器的地址保存起来。 大连理工大学专业学位硕士学位论文(3)然后该应用服务器将收集的地址列表广播给所有的客户端和应用服务器。(4)收到该列表的所有终端都使用新的IP地址列表替换旧的地址列表。(5)各个应用服务器从收到该地址列表开始计时，一次心跳时间间隔后，由下一个应用服务器重复开始广播心跳。“下一个应用服务器”是将新的应用服务器列表按地址排序，按序列在刚才发起心跳消息的服务器之后的应用服务器。下面来模拟一下应用服务器发现过程。最初只有一个应用服务器，该服务器每次都发送心跳消息但是没有回应，于是每次都只广播自己的地址，局域网内的客户端收到广播的地址列表后就知道目前局域网只有该地址提供应用服务。当有一个新的应用服务器加入的时候，当其收到一个心跳发起消息后对发起的应用服务器发出一个相应消息。发起者知道了该有新的应用服务器加入，将新的地址列表广播出去，此时所有的局域网内的客户端和其他的应用服务器都知道有新的应用服务器加入。并且新加入的应用服务器也知道了其他所有的应用服务器。由于应用服务器只对一个局域网内的客户端提供服务，考虑到一个局域网的客户端的数量有限，应用服务器的数量不会很大，所以每次心跳发送一次地址列表的数据量很小，对带宽和应用服务器的处理效率的影响很小。4．4．6多种文件系统解决方案除了客户端软件的兼容性限制了用户使用该系统的操作系统平台。对于应用服务器来说是没有数据文件所属文件系统的限制的。设计实现的网络虚拟磁盘不但要保存文件本身，还要保存文件之间的相对位置信息。不同的文件系统对文件的位置寻址的数据保存位置，和寻址方式都是不同的。加之访问层和应用服务层对数据的操作都是块级别的，即本地要求是“在哪个块写什么数据”或“从哪个块读什么数据”。将其映射到应用服务器存储的磁盘块来存储和访问数据。这里指的是数据的一个视图，真实的数据是存储在“云”端，SAN中的存储设备上的。要将这些数据解析并存储需要先识别这些文件是属于什么文件系统，然后再解析，再存储，还要自行设计一套数据模型来存储这些信息，相当麻烦。在该系统的设计中，使用了最简单的方式来解决了兼容多个文件系统的问题。这里使用的处理方法就是——不处理。由于在应用服务器并不需要知道文件的内容，也不需要知道文件的组织结构，即不需要知道文件的位置信息。所以客户端需要存储和读取什么数据，这些数据是干什么的对于应用服务器的业务逻辑处理是没有用处的。应用服务器只关注数据的存储／访问本身和其他应用级别的逻辑。在该系统中，使用了每个客户端中挂载的网络磁盘在服务器端都映射为一个镜像文件的策略来达到多种文件系统不相干的效果。即将用户申请的网络磁盘看为一个数据 基于IP．SAN的云存储服务设计与实现流，其在应用服务器上呈现出来的就是一个镜像文件。在客户端本地的磁盘操作命令写什么数据，就直接将这些数据流写到这个镜像文件相应的位置。这样唯一要做的事情就只有做好网络磁盘数据块与镜像文件什么偏移量的数据块对应的映射。客户端要写什么数据就原封不动的写到镜像文件中，要读什么数据就从相应的镜像文件偏移量中去读取。至于这些数据是什么含义，应用服务器并不处理，而是将数据交给客户端后，由客户端计算机所带的文件系统去解析。这样不论客户端是什么文件系统的磁盘，都能使用本系统实现的应用服务器来为其提供服务。4．5访问层4．5．1客户端的结构客户端的最上层是提供给用户操作的GUI界面。除了对数据的读写外，其他的操作都是直接由应用程序通过socket直接与应用服务器通信，发送消息完成，和一般的网络应用程序的结构相同。在磁盘读驱动程序上有一个磁盘驱动过滤程序来负责拦截所对磁盘的操作(网络虚拟磁盘再客户端本地没有对应的物理设备)，由驱动程序将向发往磁盘的读／写命令封装为网络数据包，通过TCP／IP发送给应用服务器，由应用服务器返回结果后再按原路径返回，最后在应用层表现出来。图4．5是客户端的结构图。一l应用屡!．．．．一阵i=，，o，，一_函墨，一，●冒◆7_一图4．5客户端的结构图Fig．4．5Clientstructure4．5．2块级别的数据操作客户端一种最简单是实现是文件级别的数据操作。对于一个文件的数据操作时，在服务器端将这个文件的所有数据全部获取在发送给客户端，客户端将这些数据加载到本一言 大连理工大学专业学位硕士学位论文地的内存中在操作文件，待文件使用完成后再将整个文件从内存中发回到应用服务器，应用服务器在将整个文件的数据通过iSCSI发送给SAN保存。这样的设计容易实现但是有许多缺点。首先这种设计的客户端与应用服务器的数据是文件级别的，在使用整个文件的情况下，不难看出性能差别。讨论一个应用服务器，即没有提供并行服务的情况。但当文件是数据流，且最上层对数据的使用并不需要等待整个文件的数据都加载进内存才能进行时差别就非常明显了。举一个很常见的例子：当我们要使用视频播放器播放一个网络虚拟磁盘中的一部电影时。如果客户端与应用服务器间是使用文件级的数据传输的话，那么客户端需要先等待应用服务器需要通过多次读数据请求将该电影文件的所有数据全部接收，并组织成一个完整的文件。然后再等待应用服务器将这个文件的数据发送给客户端。至此客户端才能开始使用视频播放器观看这部电影。这期间的延迟和本地电影文件的播放延迟差别是成千上万倍的。那么当采用客户端与应用服务器间数据传输的块级别的时候，同样的这种情况中。客户端对于这个电影文件是分块请求的。理论上一定是从该电影文件的第一个数据块依次开始请求，电影文件的组织也会是先播放的数据放在该文件的相对前面部分。一个数据块由于其体积小，在网络的传输很快技能完成，即客户端只需要很短的时间就很收到这个块的数据，视频播放软件也就能播放这个数据块所对应的电影片段了。这个原理就类似于现在的许多网络视频播放器，一边下载电影文件一边播放。在最大限度下减少了用户的等待时间，提高了用户体验。采用客户端与应用服务器间使用块级别的数据传输还有一个好处就是由于块的大小一般都是固定的，所以每次数据请求的数据颗粒大小都是一样的，这样能使负载均衡算法的效率达到最好。如果数据的颗粒大小不一样，比如一个文件为1GB，另一个文件只有1K，虽然负载均衡算法把两个请求分别让两个不用的应用服务器来处理，但实际中两台应用服务器的运行压力是天差地别的。再者使用块级别的传输，在客户端数据块的分割的功能是可以依靠客户端计算机上的操作系统来完成的。所有文件的操作都会有下层的驱动将其分解为对数据块的操作，来适应于磁盘的结构。应用服务器使用的iSCSI是实现的块级别的数据传输。这样就可以直接把客户端的请求很容易的转化为iSCSI的PDU来适应IPSAN的工作机制。如果是客户端和应用服务器之间是文件级别的数据传输，那么这个分割的过程是需要应用服务器来做的，并且在数据返回之后需要将数据组装起来。这两个过程会消耗应用服务器大量的CPU时钟， 基于IP．SAN的云存储服务设计与实现想比较客户端服务器需要承担多个用户的请求运行的负载本来就很大，再将CPU时钟大量消耗在文件的分割与组装之上会使得整个系统效率十分低下。使用块级别的传输还能帮助实现应用服务器的并行访问IPSAN，在4．5．3节介绍。4．5．3数据的并行存储／访问例如，当用户需要一次性加载网络虚拟磁盘中的一个文件，客户端将数据请求任务分为许多的小块，用负载均衡的算法将这些小任务发送的不同的应用服务器上，让这些应用服务器同时去取这些数据，应为这个系统的效率瓶颈就是因特网的数据传输延迟。将这个部分的数据传输采用并行的方式，能大大地提高整个系统的性能。其设计是：(1)客户端与应用服务器的数据传输是块级别的，这也是为什么即使增加客户端编码实现难度也要使用块级别传输的另一个原因。客户端把文件请求分割为数据块请求本身就实现一种数据均匀分割，将大任务切割成了许多小的任务，再通过负载均衡算法将任务分发到应用服务器实现并行的数据存储和访问。(2)采用了IPSAN作来存储数据：使用所有应用服务器与IPSAN互联，使得所有的应用服务器都能访问到IPSAN上所有的数据，保证分解后的任务都能得到完成。4．5．4带有虚拟节点的一致性哈希数据划分算法Dynamo的数据划分算法是在一致性哈希算法的基础上引入了“虚拟节点”【2J的概念来优化数据倾斜的问题。其实现原理是，一个真实的存储节点可以对应多个“虚拟节点”。将一个真实存储节点在“环”上表现为若干个“虚拟节点”。其映射过程如图4．6。图4．6加入虚拟节点的一致性哈希算法Fig．4．6Consistenthashingwithvirtualnode 大连理工大学专业学位硕士学位论文当然该自定义的映射规则要尽可能的让多个真实存储节点在“环”上对应的“虚拟节点”相互交错。Object4图4．7加入虚拟节点的一致性哈希算法的负载Fig．4．7Loadonconsistenthashingwithvirtualnode假设如今只有2个存储节点A、B，且映射的倍数为2，则在“环”上即排列着4个“虚拟节点”A1、A2、B1、B2。假设系统自定义的映射规则足够好，A1、A2、B1、B2按照A1、B1、A2、B2这样的顺时针排序，即“虚拟节点”相互交错。那么按照顺时针寻找存储节点的原则在区间[A1，B1]的数据存储在节点B上，区间[B1，A2]的数据存储在节点A上，区间[A2，B2】的数据存储在节点B上，区间[B2，A1】的数据存储在节点A上。通过提高映射倍数来细化存储节点区间可以使数据的分布更加平均。由图4．7可以很容易看出，虽然在[A2，B2]之间没有任何的数据节点分布，但是实际存储中，存储设备A和B的负载是相同的。所以加入了虚拟节点概念的一直性哈希算法提高了数据的分布性，具有较好的负载均衡的能力。 基于IP．SAN的云存储服务设计与实现5系统实现5．1客户端的实现客户端主要的技术实现是在Windows驱动层，通过编写Windows磁盘过滤驱动对磁盘驱动的读／写请求进行过滤来达到数据分块的效果。其他的请求，类似用户注册、磁盘挂载等功能就是使用socket与应用服务器通信，很易于实现，这些简单实现在论文中不做阐述。图5．1为客户端的实现界面。Fig．5．1ClientGUI5．1．1JRP结构Windows的过滤驱动程序【181都会生成一个设备对象，过滤驱动程序的原理就是通过将该设备绑定到磁盘驱动设备栈的上层来截获由文件系统传来的驱动消息IRP(I／ORequestPackage，输入／输出请求包)，通过结果的请求的不同来执行相应的数据处理。处理结束后可直接返回操作结束，或继续向下层传输当前IRP，甚至可以由过滤驱动生成一个IRP发给底层设备。在该系统中，因为没有真实的底层设备，使用的是第一种情况，将后续的处理交给应用服务器来完成。过滤驱动设备截获上层设备传来的IRP请求，根据不同的请求调用注册好的派遣函数来进行相应的处理。在本系统中主要处理IRP—MJ—READ和IRP—MJ—wRITE即对磁盘的读／写请求。IRP结构如图5．2。 大连理工大学专业学位硕士学位论文TypeSlzeI谓dlAddressi；ii!!!ii丹ags。_iAssociatel晒誊ThreadListEntryIoStatu$RequestorModePendingReturnedStackCountCurrentLocationCanceICanceIIrqIApcEnvironmentAIIocationFIagsUSerIosbUSerEvent0MerIayCaneelRoutitieUserBufferi。Taj|幽5．2IRP数据结构Fig．5．2IRPstructureMdlAddress：向一个内存描述符表(MDL)，描述了一个用户缓冲区。当设备对象的Flags标志为DO—DIRECT—IO时，该缓冲区为信息交互存储数据。Associatelrp：该共用体也是描述了一个驱动程序和用户程序进行信息交互的缓冲区。当设备对象的Flags标志为DO—BUFFERED—IO时，该缓冲区为信息交互存储数据。IoStatus(IO_STATUS_BLOCK)：IO状态。一般请求完成之后的返回状态。UserBuffer：使用“其他方式”读写设备设备对象的时候，即Flags标志既不为DO—BUFFERED—IO和DO—DIRECT—10，该缓冲区为信息交互存储数据。5．1．2IO_STACK—LOOATl0N结构每一个Windows驱动设备栈都有一个I／O堆栈与之相对应。I／O堆栈是为设备栈中每个设备保存的IO—STACK_LOCATION[19】结构，保存IRP执行情况，IRP附带数据等信息。IOSTACKLOCATION结构如图5．3。M．j甜f‘m咖lM轴。粕斌蝮mFlagsControI阳—I拜心懈强脚；cI娟愀黼埘蝌。：，c‘嘲函‰陬N铀棒¨)Ca't鳅图5．3IO—STACK—LOCATION数据结构Fig．5．3IO_STACK_LOCATIONstructure 基于IP．SAN的云存储服务设计与实现MajorFunction：该字段保存的是当前I／O请求包的主功能码。该功能码的数据主要用来识别此次请求的类型，派遣函数需要通过请求的类型来调用相应的处理函数来对请求进行处理。MinorFunction：该字段保存的是当前I／O请求包的副功能码。该功能码的数据主要是用来辅助主功能码，将两个功能码合并起来以定位更加详细的请求。例IRPMJPNP的请求包含很多的副功能码：IRPMNSURPRISEREMOVAL、IRP—MN—CANCEL—REMOVE—DEVICE、IRP—MN—QUERY_REMOVE_DEVICE等。Parameters：该字段保存的是I／O请求附带的参数，来帮助驱动程序完成其功能。对不同的请求在该字段提供的参数是不同的。DeviceObject：该字段保存的是驱动设备栈中与当前IOSTACKLOCATION结构对应的设备对象的地址。FileObject：该字段保存的是与该堆栈单元对应的驱动程序内核文件的地址。I／O请求的目的地就是这个文件对象。CompletionRoutine：该字段保存的是一个I／O完成例程的地址，当一个I／O请求结束后，其结束消息通常会按照原路径返回，当到达某个驱动设备的时候，该驱动设备会调用该完成例程进行一些操作。用loSetCompletionRoufine函数设置完成例程的入口地址。Context：该字段保存的是完成例程的一个参数。也是由IoSetCompletionRoutine函数设置。5．1．3处理流程图客户端的过滤驱动程序是处理针对网络虚拟磁盘的操作，将其封装成网络消息包发送给应用服务器。当有IRP发送到磁盘驱动的设备栈【20】的时候，附加在设备栈最顶端的过滤驱动设备最先获得该I／O请求消息。过滤驱动程序判断该请求是否是针对网络虚拟磁盘发起的，如果不是则将该请求直接转发给底层的设备，执行本地磁盘操作的处理。当该请求是针对网络虚拟磁盘的操作时，过滤驱动程序根据I／O堆栈【21】中与该设备对应的IO—STACK—LOCATION结构中保存的主功能码和副功能码来识别IRP请求类型。接收到IRP请求后再通过事先注册好的处理函数来将IRP转化为相应命令和数据的网络消息包发送给应用服务器。 大连理工大学专业学位硕士学位论文该打包和发送的过程主要使用Windows提供的TDI(TransportDriverInterface，传输驱动接口)[221来完成的。当应用服务器收到消息包并处理后会通过网络消息的形式向客户端发回请求处理结果。消息的接受同样是使用TDI完成的，之后再把完成的结果返还给文件系统，文件系统做相应的处理。整个客户端过滤驱动的流程结束。图5．4就是客户端过滤驱动程序拦截I／O请求的简单流程图。@图5．4客户端驱动流程图Fig．5．4Io-STACKLOCATIONflowchart5．1．4TDl(TransportDriverInterface，传输驱动接口)TDI[23】为客户端提供了驱动层与网络通信的接口。首先需要打开一个本地的传输地址，设置本地地址的原因是因为一台计算机可能有多个NIC(NetworkInterfaceCard，网络接口卡)，需要制定一个来为驱动程序发送／接收网络消息包，地址和一些参数设置好之后，使用内核函数ZwCreateFile打开一个传输地址句柄。并得到其对应的FILEOBJECT文件对象。之后使用IoGetRelatedDeviceObiect得到文件对象对应的设备对象，然后需要打开一个上下文句柄，同样是使用内核函数ZwCreateFile。设置一些参数后再使用 基于IP．SAN的云存储服务设计与实现TdiBuildIntemalDeviceControlIrp来发送一个IOCTL(YOControl，170控制)来关联传输地址对象和上下文句柄。再创建一个TDISEND的IRP并将其并将其发送到网络设备对象的驱动。申请一份空间将要发送的数据放进去，然后再调用TdiBuildSendDatagram函数发送数据，TdiBuildSendDatagram的参数列表如下：TdiBuildSendDatagram(plrp，／／指向IRP的指针pDeviceObject，／／指向设备对象的指针pTransportObject，／／指向设备对象的指针NULL，／／完成例程NULL，／／完成上下文pMdl，／／指向设备对象的指针dBufferSize，／／数据大小pConnectlnfo)；／／连接信息其中pMdl是存放要发送的数据的指针。之后由网络设备服务完成数据的发送。5．2应用服务器的实现应用服务器将客户端发来的请求分为功能请求和数据请求两种。功能请求是指完成功能处理不需要“云”端存储的数据参与的请求，例如：用户注册、用户登录验证、加入群组等功能。数据请求是指要完成功能的处理需要“云”端存储的数据参与的请求，例如：需要读数据或写数据，或者是挂载磁盘。5．2．1应用服务器逻辑处理流程应用服务器有一个守护线程来监听网络，用于接收来自客户端的请求。当一个请求到达的时候，应用服务器开一个新的线程来处理这个请求，该线程先判断该请求的类别，如果是功能请求的话，由于不用“云”端存储的数据，服务器只需要结合数据库的数据信息，来完成客户端的请求并向客户端返回请求的结果，然后结束线程。当是一个数据请求的时候，应用服务器会通过IPSAN发起端的接口将命令封装成网络消息包并行送给IPSAN的目标端，待SAN处理后返回请求响应，应用服务器通过发起端获得该响应然后再发送给客户端，线程结束，释放系统资源。图5．5为应用服务器的处理流程图。 大连理工大学专业学位硕士学位论文图5．5应用服务器流程图Fig．5．5Applicationserverflowchart5．2．2磁盘到镜像文件的映射在该系统中，每个客户端中挂载的网络磁盘在应用服务器都是以一个镜像文件的形式存在的。每次客户端都磁盘的操作“对该磁盘的某某位置的读／写”都会被转化成“对相应镜像文件某某偏移量的读／写”的命令发送到应用服务器。因为镜像文件的数据和磁盘的数据的完全对应的，所以其操作数据在两者中的偏移量是完全相同的。表5．1mmap的参数Tab．5．1Parametersofmmap 基于IP．SAN的云存储服务设计与实现对镜像文件进行读写操作时，需要先将文件映射到内存中，再直接对内存操作，这样的方式比使用open函数打开镜像文件再seek到操作数据的偏移位置，再对数据进行读写操作的方式高效很多。具体镜像文件的数据从磁盘映射到内存的过程是使用mmap函数来实现的。函数参数介绍如表5．1。直接使用mmap是不行的。因为很多时候虚拟磁盘的磁盘分块大小和应用mmap调用者即应用服务器的操作系统分页大小是不同的。mmap是以内存分页大小为单位进行内存映射的。当客户端的磁盘分块大小和应用服务器操作系统分页大小不同时，需要做偏移量的修正。目前操作系统的内存分页大小基本是为4096字节。而磁盘分块大小有512字节、1024字节、2048字节、4096字节、8192字节、16KB、32KB、64KB。当磁盘分块大于等于4096字节时，磁盘分块大小是4096字节的整倍数即请求读写数据的偏移位置一定是4096字节的整倍数。可以不做偏移量修正就是用mmap得到正确的操作数据的地址。当磁盘分块大小小于应用服务器内存分页大小的时候，当请求的数据起始偏移量不为4096字节的倍数时就需要做偏移量修正。以磁盘大小是2048字节为例。如图5．6。+一调整到4069整倍数——offset=6144／4096ptr=mmap(⋯，offset)；——修正到操作数据—专ptr=ptr+6144％4096操作呻r{卖写数据图5．6偏移量修正Fig．5．6Offsetcorrection当一次命令的偏移量为6144字节的时候，需要将偏移量修正到4096字节才能正常使用mmap，使用mmap之后得到的返回值是只想从镜像文件开头偏移4096个字节的数据的在内存中的地址。由于内存中数据是连续的。将指针向后移动2048个字节后指针就是只向要操作的数据了。 大连理工大学专业学位硕士学位论文5．2．3数据库表设计应用服务器用Usrlnfo、Disklnfo、Grouplnfo三张表来维护业务逻辑所需的数据。Usrlnfo用来保存注册用户的登录信息，主键是usrlD。如表5．2。表5．2用户信息表Tab．5．2Userinforrnationtable字段名描述usrlDusrNamepasswd用户ID用户名用户密码Disklnfo用来保存所有的磁盘的信息。网络磁盘和镜像文件是靠表中对的imgPath建立关联的。diskType是用来区分磁盘类型是个人磁盘还是群组磁盘。主键是disklD。如表5．3。表5．3磁盘信息表Tab．5．3Diskinforrnationtable字段名描述disklDdiskNamediskSizeownerlDimgPathdiskType磁盘ID磁盘名磁盘大小创建者ID镜像文件路径磁盘类型GroupInfo是用来保存群组信息的。当用户需要挂载群组磁盘的时候，需要用这个表中的信息来验证用户的权限。主键是disklD和usrlD。如表5．4。表5．4群组信息表Tab．5．6Groupinformationtable字段名描述磁盘ID群组成员ID磁盘创建者IDDD眦删州～ 基于IP．SAN的云存储服务设计与实现5．2．4数据的服务器发现技术、负载均衡算法和并行访问之所以将这三个技术实现写在一节，是应为这三个技术是有依赖关系的。负载均衡需要通过服务器发现技术知道局域网内有哪些应用服务器在提供服务。而由于客户端和应用服务器之间的数据传输是块级别的，所以实现了负载均衡，其实就等于实现了数据的并行访问。一次对数据的请求会在客户端被分解为许多对块级别的数据的请求，这些请求被客户端按照负载均衡的算法分布到不同的应用服务器上，这就等价于一次数据的请求由多个应用服务器为其提供-yJ]侵务。理想情况是局域网内有多少个应用服务器就会产生几倍的并行效果。首先是服务器发现技术，其技术细节已经(在4．4．5节阐述)。客户端在实现的时候，只需要使用分配一个存储空间，然在再提供一个网络监听程序，监听局域网内应用服务器广播的应用服务器列表消息，并从中得到正常工作的应用服务器信息即可。当客户端有了应用服务器列表之后，每次需要向应用服务器发送请求之前，通过负载均衡算法(在2．4节中有算法说明)将分解后的任务分配到不同的应用服务器上实现负载均衡和并行服务。5．2．5负载均衡算法和并行访问的细节为了达到最好的负载均衡效率，同时也达到最好的并行效果。每一个客户端的数据块会使用一个。会采取一个均差为1的升序的序列作为哈希算法的Key值，由于一次操作分解的多个数据块的请求都是连续的命令，这样的序列产生策略能保证数据请求的最大分散度。应用服务器的哈希算法的Key值采用了应用服务器在局域网内的IP地址。为了保证负载均衡和并行效果最好，不出现因哈希值分布的“环”中服务器的分布不均匀而引起了某些服务器接收请求多，有些服务器接收请求少的情况。要求应用服务器管理员在分配应用服务器的IP地址的时候，按照应用服务器哈希值分布最均匀的情况来提供配置。对于管理员，这个维护成本是可以忽略不计的。IP地址列表广播一个方案是一种自适应的策略。每次发起心跳的应用服务器将获得心跳相应的地址和自身原来保存的一份地址做比较，每次只发送变动的部分，如“增加某服务器”或“某服务器消失”，这样来减少网络中的数据传输量。当新加入一个应用服务器，它得到广播的地址消息只是简单地告诉它，它自己加入了这个局域网。5．3存储层的实现在存储层的实现中，主要是要实现应用服务器的数据存储／访问操作到iSCSI协议的PDU的转化。之后的任务就可以通过因特网将SCSI命令和数据交给IPSAN中的目标端去处理。 大连理工大学专业学位硕士学位论文考虑到目前有许多的成熟的iSCSI协议的实现，目标端完全可以直接使用免费软件或在开源项目上做二次开发，本系统中这部分主要做的工作是配置SAN网络，并使用命令对其进行管理。5．3．1应用服务器与iSOSI发起端的通信应用服务器收到的客户端的数据请求，即用户需要对挂载的网络磁盘中的数据要进行操作。该概念对于应用服务器来说就是对响应的服务器端的镜像文件某个偏移量的数据块要进行操作。应用服务器需要先访问数据库，通过网络磁盘表找到该镜像文件的位置，并对其操作。应用服务器并不知道，该镜像文件不存在本地。该镜像文件的虚拟工作时iSCSI的发起端来实现的。其过程与客户端的驱动过程类似。由于应用服务器认为该镜像文件存在与服务器本次磁盘。应用服务器会向本地请求镜像文件的数据。该请求最终会被文件系统转化为I／O请求再顺着磁盘的驱动程序的层次向底层传输。在传输过程中会被iSCSI的发起端截获并转化为iSCSI的PDU，最后通过因特网发送到目标端进行处理。5．3．1IPSAN的配置Target配置：先安装target软件，然后修改配置文件iedt．confo主要设置target名称和映射磁盘的设置。其设置格式如下：Targetiqn．2013—03．tom．dlut：target．test．zjqLun0Path=／dev／sdal，Type=blockioTarget在名称含义在2．1．3节描述。后面一行是指定映射的磁盘和磁盘类型。之后使用[#]serviceiscsi．targetstart启动服务。Initiator配置：使用『#]serviceopen．iscsistart启动服务。之后使用iscsiadm命令来发现和登录目标端例如：[#]iscsiadm～modenode—targetnameiqn．2013-03．tom．dlut：target．test．zjq—portal127．0．0．1：3260一login就是登录的命令，其中127．0．0．1是目标端的口地址，3260是iSCSI服务的周知端口号。iqn．2013—03．tom．dlut：target．test．zjq是目标端target名称。 基于IP-SAN的云存储服务设计与实现6性能测试6．1负载均衡负载均衡在两种情况下进行测试。一种是应用服务器网络拓扑结构不变的情况。一种是在测试过程中加入一个应用服务器的情况。该次测试是为了测试负载均衡算法和应用服务器发现策略的执行性能。6．1．1静态拓扑结构在一个局域网内部署四台应用服务器，一个客户端，客户端对本地挂载的网络虚拟磁盘进行随机的数据读写操作。运行30分钟，分别在5分钟、10分钟、15分钟、20分钟、25分钟、30分钟6个时间点统计各个应用服务器1分钟处理的数据块的数量。测试用例如表6．1，测试结果如图6．1。表6．1静态负载均衡测试Tab．6．1Staticloadbalancingtesting项目内容测试用例编号测试标题预设条件输入操作步骤预期输出VirtualDisktesting1静态负载均衡测试一个客户端，四台应用服务器，应用服务器网络拓扑结构不变客户端自由操作在6个时间点统计各个服务器1分钟处理数据块数量每次统计出的各个服务器1分钟处理数据块数量相近3502-300篓250巅娶20015051015202530时间(m)图6．1静态测试图Fig．6．1Statictestingchart 大连理工大学专业学位硕士学位论文6．1．2动态拓扑结构在一个局域网内部署三台应用服务器，一个客户端，客户端对本地挂载的网络虚拟磁盘进行随机的数据读写操作。在第20分钟加入一个新的应用服务器，运行40分钟在4个时间点取样各个应用服务器1分钟处理的数据块计数。测试用例如表6．2，测试结果如图6．2。表6．2动态负载均衡测试Tab．6．2Dynamicloadbalancingtesting项目内容测试用例编号测试标题预设条件输入操作步骤预期输出VirtualDisktesting2动态负载均衡测试一个客户端，三台应用服务器，第十五分钟加入一台应用服务器客户端自由操作在6个时间点统计各个服务器1分钟处理数据块数量每次统计出的各个服务器1分钟处理数据块数量相近350，、3204-姜290噻260割裂23020051015202530时间(m)图6．2动态测试图Fig．6．2Dynamictestingchart6．1．3测试结论从静态测试的结果来看，该系统使用的优化后的一致性哈希算法能达到较好的负载均衡并且较为稳定。 基于IP．SAN的云存储服务设计与实现要达到更好的负载均衡可以优化哈希函数或选择更好的计算哈希的数据块Key值或应用服务器的Key值，更好的Key值能让数据块分布得更加均匀，达到更好的负载均衡。在动态测试中，当加入一个新应用服务器节点的时候，当前分钟，由于应用服务器发现策略有几秒钟的延迟，所以新加入的节点负载相对较轻，但之后，各个应用服务器负载情况良好并且稳定。综上，本系统使用的优化后的一致性哈希算法和动态应用服务器发现策略让本系统具有较好的负载均衡，且支持应用服务器的动态拓扑结构改变。由于发现策略中应用服务器的移入和移除的策略是相同的，其测试结果也是相同的，所以论文略去移除应用服务器的测试阐述。6．2并行数据传输目前的网盘占用用户本地存储资源的主要原因就是网络带宽的限制导致数据传输的速率不能满足客户对数据实时操作的要求。本论文设计与实现的系统就是用并行来解决带宽限制的问题。6．2．1并行性能测试该测试使用一个客户端对同一个足够大的文件进行读操作，保持数据的最大传输量。分别使用l台、2台、4台、6台应用服务器提供服务，测试各种情况下每个请求的平均完成时间即每个数据块从请求到完成的平均耗时。测试用例如表6．2表6．3并行性能测试Tab．6．2Parallelismperformancetesting项目内容测试用例编号测试标题预设条件输入操作步骤预期输出VirtualDisktesting3并行性能测试一个客户端，一直发送读请求，客户端磁盘分块为4096字节分别由1台、2台、4台、6台应用服务器提供服务统计各种情况下每个请求的平均完成时间应用服务器成倍增加使耗时成倍减少测试结果如图6．3。当使用l、2、4台应用服务器时，效率曲线基本是线性的，后面使用6台的时候效率增加不明显是因为受限于整个局域网与因特网连接的带宽限制和本地执行的耗时。 大连理工大学专业学位硕士学位论文／‘、∞暑、一，厘蓄毯口E：霹1斗书∈蝗305O弋＼＼一-l-1246应用服务器数量(台)图6．3并行测试图Fig．6．3Parallelismtestingchart6．2．2测试结论由6．2．1的测试结果来看，当服务器数量加倍时，效率曲线是基本成线性的，说明该系统提供了较好的并行访问能力。同时具有较好的扩展性。当数据进行最大量读请求的时候，几乎全部的数据块请求都是4096字节。当只有1台应用服务器的时候，平均一个请求的完成时间是24ms即每秒中完成传输166KB。当使用6台应用服务器的时候，平均每个请求的耗时是5ms即每秒中完成传输800KB。在不改变带宽的情况下，读取效率提供了很多。本次测试由于客观条件的限制，应用服务器没有分配额外的带宽。在实际应用中，由于数据传输的延迟主要产生在因特网，局域网的延时可以忽略。网络管理员只需要为应用服务器配置额外的带宽。例如分配20Mb专用带宽，理论的单应用服务器传输速率就能达到2．5MB／s。这样可以在用最低代价提升数据的传输效率的同时不影响管理员对普通用户的管理。 基于m-SAN的云存储服务设计与实现结论由于目前网络硬件发展滞后，因特网的带宽限制很大，网络的数据传输速率大大低于本地磁盘的数据传送速率。用户文件完全存储在“云”端服务器上，当用户需要使用的时候在通过网络传输数据产生的延迟，是用户不能接受的。所以目前的云存储软件都在用户的磁盘保存了一定的数据，“云”端服务器保存这些数据的备份。当客户端操作文件的时候，其本质是操作本地的文件，然后客户端软件在将本地数据与服务器上的数据同步。违背了云存储不需要用户提供存储空间，所有的服务都是由“云”端提供的特性。针对这种情况，本论文设计并实现了一种基于IPSAN的网络虚拟磁盘，能提供用户的对于云存储服务的应用需求，同时不需要占用用户的存储空间。该系统为了将网络带宽的限制减到最小。在因特网传输的过程采用了并行的策略。这也是本系统设计的起点。为了并行的实现，数据的传输采用了块级别的数据传输，这样的设计不仅很好地切合了并行的要求同时也使数据的负载均衡创造了条件。所以块级别数据传输是本系统的核心。此外在本系统中采用了一种基于轮询的广播心跳发现策论。这种自适应的策论使得系统的配置最为简单，维护成本最低，应用服务器的动态配置，能自识别应用服务器的失效。本系统为了在因特网数据的传输过程中使用并行的策略。将云存储服务的应用接口层做到了客户端的局域网中，且需要多台服务器才能提供并行服务。由于设备投入的原因，本系统难以被普通个人用户使用，使用的用户被限制为同局域网存在大量用户，存在维护系统的管理员，且能提供独立的服务器的企业或学校等。这个限制也是本系统有待改进的地方。后续研究需要设计另外一种策略来优化网络传输的效率，消除需要局域网布置应用服务器的限制，将用户群体扩展到所有用户。 大连理工大学专业学位硕士学位论文参考文献[1]Zengw，ZhaoY，OuK，eta1．Researchoncloudstoragearchitectureandkeytechnologies[C]．Proceedingsofthe2ndInternationalConferenceonInteractionSciences：InformationTechnology，CultureandHuman．ACM，2009：1044—1048．[2]DeCandiaG，HastorunD，JampaniM，eta1．Dynamo：flmazon’shighlyavailablekey-valuestore[C]．ACMSIGOPSOperatingSystemsReview．ACM，2007，41(6)：205—220．[3]ArmbrustM，FoxA，GriffithR．Aviewofcloudcomputing[J]．CommunicationsoftheACM，2010，53(4)：50—58．[4]MethKZ，SatranJ．DesignoftheiSCSIProtocol[C]．MassStorageSystemsandTechn0109ies，2003．(MSST2003)．Proceedingson20thIEEEGoddardConference．IE雎，2003：116-122．[5]ChadalapakaM，SatranJ，BlackD．iSCSIProtocol(consolidated)[J]．2013．[6]WangP，GiiiiganRE，GreenH．IPSAN—fromiSCSItoIP—addressableethernetdisks[C]．MassStorageSystemsandTechnologies，2003．(MSST2003)．Proceedingson20thIEEEGoddardConference．IEEE．2003：189—193．[7]MethKZ，SatranJ．FeaturesoftheiSCSIProtocol[J]．CommunicationsMagazine，IEEE，2003．41(8)：72—75．[8]LIUw，CAlw．ResearchonGratedSecurityiSCSIBasedonIPSecProtocol[J]．ComputerEngineering，2006，9：059．[9]ZhouW．optimizingInstitutenetworkstoragebuildingbaseoniSCSIforIP—SAN[C]．InformationManagementandEngineering(ICIME)，2010The2ndIEEEInternationa]Conferenceon．IEEE，2010：98—100．[10]ParmeleeRP，PetersonTI，TillmanCC．Virtualstorageandvirtualmachineconcepts[J]．IBMSystemsJournal，1972，1l(2)：99—130．[11]ChadalapakaMB．Systemandmethodforstoragevirtualization：U．S．Patent6，845，403[P]．2005—1—18．[12]JingliVGZ．ResearchandimplementationofiSCSIbasedstoragevirtualization[J]．JournalofHuazhongUniversityofScienceandTechnology(NaturalScienceEdition)，2010，6：015．[13]KargerD，LehmanE，LeightonT．Consistenthashingandrandomtrees：DistributedcachingprotocolsforrelievinghotspotsontheWorldWideWeb[C]．Proceedingsofthe29thannualACMsymposiumonTheoryofcomputing．ACM，1997：654—663．[14]张帆，史彩成．Windows驱动开发技术详解[M]．电子工业出版社，2008．[15]MethKZ．iSCSIinitiatordesignandimplementationexperience[C]．NASACONFERENCEPtJBl。ICATION．NASA．2002：297—304．一5l一 基于IP．SAN的云存储服务设计与实现[16]石磊．磁盘阵列控制器中iSCSI目标器的设计与实现[D]．武汉：华中科技大学，2007．[17]MethKZ，SatranJ．FeaturesoftheiSCSIProtocol[J]．CommunicationsMagazine，IEEE，2003，41(8)：72—75．[18]谭文，杨潇，邵坚磊，等．寒江独钓：Windows内核安全编程[M]．北京：电子工业出版社，2009[19]武安河，邰铭，于洪涛．Windows2000／XP1|lrDM设备驱动程序开发[M]．电子工业出版社，2003．[20]RussinovichME，SolomonDA，IonescuA．WindowsInternals[M]．0’ReillyMedia，Inc．，2012．[21]Oneyw．ProgrammingtheMicrosoftWindowsDriverModel[M]．MicrosoftPress，2010．[22]LIUL，LIJ，ZHUL．ResearchandRealizationofTDI—BasedNetworkVirtualDiskDriver[J]．ComputerTechnologyandDevelopment，2006，8：067．[23]FANGF，LIB．MajorTechnologiesforWindowsTDIDriver[J]．CommunicationsTechnology，2010，7：034．52— 大连理工大学专业学位硕士学位论文致谢在大连理工大学软件学院的两年学习就要结束了。首先得感谢我的研究生导师，本篇论文从选题，系统设计到最后的实现都是在老师的指导之下完成的。毕业设计的顺利完成离不开老师的指点和督促。在平时的学习和科研中老师不仅从专业知识上给出了大量指导，在研究方向、研究方法等方面也提出了许多建议。老师的严谨的治学态度和敬业的精神也给我树立了良好的榜样。同时要感谢和我一起工作和学习的同学。在研究生的生活和学习中都给我提供了不少的帮助。还要感谢我的父母多年来的养育和教育，还有对我的学业的大力支持。毕业设计为我的大学学习生活画上了一个句号。也是我下一段学习生活的起点。我会继续保持刻苦的学习精神和积极上进的生活态度，去接受新的挑战。 大连理工大学专业学位硕士学位论文大连理工大学学位论文版权使用授权书本人完全了解学校有关学位论文知识产权的规定，在校攻读学位期间论文工作的知识产权属于大连理工大学，允许论文被查阅和借阅。学校有权保留论文并向国家有关部门或机构送交论文的复印件和电子版，可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印、或扫描等复制手段保存和汇编本学位论文。学位论文题目：作者签名：导师签名：．粒珲二麴型坠幽睦垒歪盎遂茸叁睦邋日期：泣l三年—量月』LEt日期：趋!王年—上月j三日