1　研究背景

    基于数据复制的容灾系统是在已有的Windows操作系统内核中嵌入远程复制和灾难恢复机制，通过TCP/IP网络在远程维护应用数据的一个或多个一致性副本，在异地建立一套完整的与本地生产系统相当的备份应用系统（可以互为备份），一旦本地的数据中心（主端）遭到破坏，则某个远程数据中心（从端）的应用数据可立刻投入运行，并可在适当时机由远程数据中心实现本地数据中心的有效恢复，在灾难情况下，远程系统迅速接管业务运行。系统架构如图 1所示。

    由于备份数据的最根本目标就是可恢复性，而数据一致性就是容灾系统保证可恢复性的根本保证[2]，[7]。如果从端不能保持数据更新顺序，则造成主从端数据不一致，主端上的数据是不可恢复的。根据应用环境的不同，从端的数据可能和主端的数据存在一定的差距，但是为了保证在任意时刻从端数据的一致性，必须保证从端上数据的更新顺序和主端上数据的更新顺序相同[1]，[4]。

图 1　数据复制系统示意图

    2　数据复制的日志机制

    日志是一组记录所构成的序列，既是本地设备写请求的记录者，也是进行远程复制的数据源，为在将来查阅或者恢复系统所用，设计成循环使用的一块存储空间，在整个设备复制系统占有十分重要的地位。主端首先根据用户写请求，更新复制主端日志，而后将用户写请求写入本地主设备，同时从主端日志中依次读出写请求发送到从端，从端得到请求后写入从设备，向主端返回确认，最后标记用户请求完成。

    2.1　日志的结构

    采用一个单独的设备（物理分区或者磁盘设备）作为专用日志设备，以保障系统的独立性和可靠性。日志在专用设备上的组织结构包括两大部分，一部分是控制信息区，用于存放容灾系统的控制信息；一部分是写请求数据区，由一系列数据单元（Data Unit）组成，每个数据单元存放一个写请求的描述信息和数据内容，参见图 2。

图 2　日志组织结构图

    写请求数据区的数据单元中描述信息大小通常是固定的，而数据内容大小则根据写请求的数据大小来确定，这样使得同一写请求的数据内容连续存放，以便统一提交进行写入和复制操作。同时，为了标记写请求数据区的几个关键位置，在写请求数据区设有#1、#2、#3和#4共4个标记（Index），标记的信息则存放在控制信息区。

    AckIndex（#1）：确认标记，标记等待从端确认的下一个数据单元位置；RepIndex（#2）：复制标记，标记等待复制的下一个数据单元位置；DvIndex（#3）：主设备标记，标记与即将写入主设备的数据单元对应的下一个数据单元位置；LvIndex（#4）：日志标记，标记日志设备下一个数据单元的写入位置。由于写请求数据区组织成循环队列，那么标记AckIndex相当于队首，标记LvIndex相当于队尾，而标记RepIndex 和DvIndex相应地位于标记AckIndex和LvIndex之间，必须满足位置次序要求。

    2.2　日志数据处理

    控制信息主要是各个主设备的描述信息和图 2中所示的4个标记信息。主设备的描述信息通常只有在主设备发生变化（包括添加、删除、改变容量等）时才进行更新，而4个标记信息则采用缓写机制，即只有标记位置变化在内存中累计到一定数量时才对控制信息区更新一次。如标记LvIndex可以在日志累计写入50个数据单元的时候才在控制信息区进行更新，大大降低了频繁写盘对系统性能的影响。本文若非特别说明，所指标记均是内存中信息。

    数据单元包括描述信息和数据内容，描述信息包括数据内容的大小和写入主设备的物理位置等信息，数据内容则是写请求实际更新的一组数据块序列，对不同写请求可能生成的数据内容的大小不同。数据单元先在内存中进行组织，然后一起写入数据区，只有当描述信息和数据内容都写入数据区后才算成功。

    可以通过用户命令或者GUI的方式直接访问日志队列，获取所需信息；也可以由容灾系统中负责进行复制的模块通过标记RepIndex依次访问各个数据单元，读出其描述信息和数据内容，而后组织成报文发送到从端，完成复制功能，而标记RepIndex每次相应地沿正向移动一个数据单元。若收到从端确认，则标记AckIndex相应沿正向移动一个数据单元。

    2.3　溢出处理

    写请求数据区循环使用，但由于4个标记有位置次序要求，各个标记不得超越其前一标记位置，例如LvIndex循环位于AckIndex之后时不得超越 AckIndex。当LvIndex和AckIndex重合时会出现写请求数据区不足的情况，称为写请求数据区溢出，也称为日志溢出。

    在控制信息区预留一个位图区，该位图区由若干位图表构成，每张位图表对应一个主设备，表中的每一位都对应了主设备的一个数据块，该位图表称为日志位图表（DCM表）。当出现日志溢出时，首先暂停用户写请求直至标记DvIndex和LvIndex重合，即主端日志和主设备均已写完；然后将标记 AckIndex和LvIndex之间的所有数据单元中数据内容对应的主设备数据块所映射的位图表中的位标记为“1”，即表明日志和主设备均已进行了更新，构建日志位图表；最后将标记AckIndex、RepIndex调至标记DvIndex、LvIndex所在位置，从而可以继续接受上层用户写请求。图3以一个数据单元为例给出了生成日志位图表的构造关系，图中的数据单元对应主设备的两个数据块。

图3　日志位图表构造关系图

    日志位图表作为在日志溢出情况下的一种日志记录形式，其访问方式比较特殊。复制模块首先读出日志位图表，而后逐行扫描位图表各个位，若某位被标记为 “1”，则读出其对应的主设备数据块，在内存中组织成报文发送到从端，完成复制功能。若收到从端确认，则将日志位图表中对应位标记为“0”。根据日志位图表进行设备复制时，从端按照位图表中标记为“1”的位依次进行更新，不能保证WOF原则[7]，所以主从端数据不一致，只有当整个日志位图表被扫描一遍即从端按照日志位图表的所有标记为“1”的位进行更新后才能与主端达到数据一致。

    2.4　日志修正

    当系统非正常重启后，则可能导致日志数据不一致：控制信息和写请求数据区不一致，前者比后者“旧”；由于主设备是在日志设备之后写入数据，导致主设备的数据与对应的日志数据单元不一致，前者比后者“旧”。此时，就需要对日志做修正处理，类似于数据库系统根据undo日志进行事务的回滚操作。修正处理分三个步骤进行：

    （1）对日志的控制信息和写请求数据区不一致的情况，需要修正日志的控制信息。主要是根据数据区来修正标记LvIndex，即根据标记LvIndex当前所指示位置沿正向扫描，若下一个数据单元的描述信息可以说明其是有效的单元，则继续沿正向扫描直到所得数据单元的描述信息无效，此时标记LvIndex所指示位置就为其对应数据区的最新位置，而对标记AckIndex、RepIndex、DvIndex暂不作修改。

    （2）对主设备的数据和数据单元不一致的情况，需要修正数据单元的描述信息和数据内容，称为日志重建。在前一步修正标记LvIndex的基础上，根据主设备的数据对标记DvIndex和LvIndex之间的数据区进行重建，即此区间内的各个数据单元根据其描述信息依次读出对应主设备的数据，对自身的数据内容进行覆盖，而后再将标记DvIndex沿正向移动至标记LvIndex位置，从而实现主设备数据和数据单元的一致。

    （3）在完成日志的修正后，主端日志和主设备达到一致，但由于标记AckIndex和RepIndex被缓写而未作修正，所以可能从端已经更新而主端未知，这就需要从标记AckIndex位置开始重新进行复制操作。为了避免重新复制过程中的数据不一致现象，需要将标记AckIndex和LvIndex之间的数据单元一次性发往从端，并对从设备做一次性更新，对从端而言也可以看作是一个redo操作。复制完成后，主从端达到数据一致，将标记 AckIndex和RepIndex沿正向移动至标记DvIndex和LvIndex所在位置，开始正常的数据复制操作。

    2.5　从端的日志技术

    当主端瘫痪时，容灾系统将选择一个从端作为新主端对外提供服务，原主端将作为一个新从端备份数据。为实现此过程，我们基于从端的日志队列提出灾难后回迁机制，通过灾难后回迁，达到恢复主端数据和角色的目的。

    （1）预恢复：原主端将日志中记录的灾难发生前未能成功发往新主端的数据信息的DCM表发往新主端，新主端将接收到的DCM表和本地更新数据信息的DCM表异或操作，从而标记出原主端宕机后新主端的所有需要更新数据。

    （2）恢复：原主端根据新主端的DCM表所对应的写请求数据块发往新主端，新主端对相应的数据进行更新，实现数据同步。

    3　结束语

    日志机制是实现远程复制的核心和基础，在借鉴文件系统和数据库系统日志[3][5]的设计经验的基础上结合容灾系统自身的特点，提出了相应的设计要求，而后重点围绕日志机制的组织结构、工作方式以及特殊情况的处理等几个方面，进行了较为深入的分析，最终实现远程复制的日志机制，为同类系统的设计提供参考。