远程复制系统的卷复制系统的优化设计.docxVIP

远程复制系统的卷复制系统的优化设计 0 复制技术的发展 近年来，记录灾难技术的应用越来越普及。远程恢复数据是实现数据容灾的重要技术手段。它通过将数据复制到遥远的边缘，恢复数据资源的副本，这可以防止因软件资源损坏或人为操作而造成的数据系统不可恢复的破坏。按照复制所在的层次可以将现有的复制技术分为3大类:基于应用的复制、基于文件的复制和基于卷的复制,其中,基于卷的复制由于其独特的优点而具有广泛的适用性。目前国外公开发表的关于基于卷的异步复制系统的研究成果有EMC的replicate(原legato公司的软件)、NetApp的SnapMirror、Veritas公司的VVR、HP实验室的Seneca等。本文将设计一种基于多线程和流水线工作模式的异步卷复制系统,并对传统的复制协议做一些改进,引入网络自适应的概念,并设计了对原子请求组的一种高效合并策略,可以有效利用复制带宽,显著提高复制软件的性能。 1 非均质分发系统的工作原理和性能分析 1.1 读取请求记录 异步卷复制系统的工作原理是:截获主端上对于主盘的写请求,将请求内容写入主盘日志区(日志区满时启用位图),写入日志区后即可确认写请求完成并返回上层应用(文件系统、数据库或其他直接访问设备的程序),将写请求的数据写入主盘。然后启动复制过程,从日志区或主盘(启用位图时)读取数据并通过网络发送至从端;从端如收到正确数据,即执行相应的写操作,并向主端发送确认;主端在收到从端的接受确认之后从日志区删除此请求记录,整个复制过程如图1所示。在整个复制过程中,须确保主端与从端写请求执行的顺序相同,以保证数据一致性。 1.2 写请求的完成 在异步复制的模式下,上层应用提交的写请求会在主端引发多个操作。主要包括:写主端日志、写主设备、向从端发送请求、标记请求完成、删除主端日志等,这些操作都直接影响了主端的I/O性能。一般情况下,在对主端的应用返回之前,并不要求向从端发送请求和删除主端日志的操作完成,这里有两种处理方式。即要求写主端日志和写主设备操作完成,或至少完成一项,即保证在请求返回之前至少有一个副本保存在了非易失存储中。由于要保证主端在发生一些重大故障之后能做到有效恢复,一般都要求写主端日志完成之后再进行写主盘的操作。故必须至少完成一项写主端日志的操作。后者虽然提高了I/O性能,缺点是在从返回写请求完成标志到在主设备上执行写请求期间,如果有读请求要读取写请求对应的块,就不能从主设备中读取到最新的数据,会引起应用数据的不一致。所以通常都采取前一种方式,即在写日志和写主盘全部完成后才返回上层应用。所以一般情况下,对于主端写请求的执行时间是写日志与写主盘时间之和。出于对性能的考虑,一般要求日志存储设备与主设备不是同一个设备,而且写日志与写主盘的内容几乎完全相同,两者时间也大致相等。在普通的未优化的系统中,复制系统将至少降低主端写性能一半左右。 2 基于生产线技术的渐进式复制系统 2.1 基于记录数据的复制流程 由于复制工作本身比较复杂,如果只用单一线程完成,将使复制系统效率低下,而且各种系统资源也不能得到有效利用。由于删除日志操作实际上就是更新超级块中的确认标签,该操作并不需要在每个请求确认(指收到从端确认)后执行,因此可以忽略该操作。本文设计了4个独立工作的线程完成整个复制流程。这4个线程分别是写日志线程、写主盘线程、预读日志线程和发送日志线程。下面将简述各个线程及其完成的工作内容。线程的名称与其所完成的工作如下所述: Rep＿writelog＿thread:该线程将截获上层应用下发的写请求,并将请求的内容组织成相应格式(日志记录)并写入日志盘。 Rep＿writemd＿thread:该线程在日志记录被写入日志盘完成后被触发,它将写请求内容写入相应主盘位置,并在写完成后返回应用请求。 Rep＿preread＿thread:该线程负责将已被写入主盘的数据从日志盘中读出,并组织为相应格式,提供给发送日志线程使用。 Rep＿tx＿thread:该线程负责将预读线程提供的数据发送到从端。 2.2 使用线条技术完成的复制工作 2.2.1 读存储/接证操作以完全并行 如上文所述,本文将复制过程分为4个步骤:写日志、写主盘、预读数据、请求发送。4个步骤之间存在一定依赖关系。写日志最先完成,而写主盘必须在写日志完成之后,显然发送日志也必须在预读日志完成之后。由于写日志和读日志都需要访问日志盘导致空间冲突,因此这两个操作是不能并行的。一般情况下,需要优先保证主端的性能,即有写日志请求执行时就不提交读日志的请求。上述的依赖性描述导致了两组依赖,第一组是写日志和写主盘,第二组是读日志和发送日志,每组内的操作是可以并行的,但是组间不能保证完全并行。4个线程之间的依赖关系如图2所示。 2.2.2 部分线索的性能分析 根据上文