介绍几种容灾复制技术

    组建容灾的重要基础之一是数据复制技术。在操作上简单来讲就是通过复制软件实时地将数据从一个主机（或磁盘）复制到另一个主机（磁盘），生成一个数据副本。
    数据复制有多种分类方法，依据复制启动点的不同，可分为同步复制、异步复制。同步复制，数据复制是在向主机返回写请求确认信号之前实时进行的；对于异步复制，数据复制是在向主机返回写请求确认信号之后实时进行的。

一、四种容灾复制技术说明

    根据操作系统的I/O（读写操作）路径以及复制对象划分为四大种类：基于应用层事务复制、基于文件层复制、基于逻辑卷层复制、基于磁盘阵列复制。当然，目前出现了基于SAN交换机的复制，但是相对技术不太成熟，应用很少。

    按照数据复制软件或硬件安装的位置又可划分为主机型复制和非主机型复制。应用层、文件层、逻辑卷层的都属于主机型复制，主机型复制软件需安装在主机上，需要消耗一定的主机资源。存储层属于非主机型复制，复制直接由磁盘阵列的内部组件完成，理论上无需消耗应用所在主机的资源。
    一般而言，容灾要保护的数据是结构化数据，即存储在数据库的数据。以下都用复制数据库来说明。

1．基于应用层事务复制
基于应用层事务的复制，一般采用采用异步复制机制，复制对象为应用事务，其过程为：捕获应用系统的事务，例如SQLServer或Oracle数据库的事务，经由传输组件传输到目标服务器，然后目标装载进程按照数据库的关系原理排序事务，将事务保存到目标数据库。

    这层的复制完全能保障数据库的一致性，且目标数据库处于在线运行状态。当生产数据库发生故障时，直接使用目标数据库即可恢复业务，容灾的RTO指标趋于零。但是支持的应用有限，一般为SQLServer、 Oracle、Sybase、DB2、MySQL等等数据库。另外复制速度较慢，因为数据要通过数据库的装载接口才能写入数据库。
    应用层产品有很多包括：Goldengate、Quest、Oracle、微软等。

2．基于磁盘阵列复制
   基于磁盘阵列层的复制，磁盘阵列厂商的复制技术，其原理与逻辑卷层的相似，属于非主机型的复制。但与硬件绑定，成本高昂，实施复杂。
    基于磁盘阵列层的复制不能完全保障数据库一致性，目标数据库处于脱机状态。当生产数据库发生故障时，需要启动数据库才能恢复业务，正是由于不能保障数据库一致性，很可能数据库不能正常启动。尽管存在这样的缺陷，但这一层的复制对主机的影响极其轻微，所以还是可应用在一些非常大型、繁忙的数据库容灾，作为一种补充保护手段。
    磁盘阵列层厂商包括：IBM、HP、EMC、HDS等。

3．基于逻辑卷层复制
    基于逻辑卷层的复制，一般采用采用同步复制机制，复制对象为逻辑卷层的变化Block，其过程为：捕获变化块，同步写入目标存储，等于在一个主机上将同一数据写入两个不同的逻辑磁盘。这种复制方式对I/O性能影响很大。另外，在实施时可能需要改造生产环境，例如VVR需要自身的卷管理格式才能支持复制，所以如果用于非新部署的业务系统其实施非常复杂。

基于逻辑卷层的复制不能完全保障数据库一致性，目标数据库处于脱机状态。当生产数据库发生故障时，需要启动数据库才能恢复业务，正是由于不能保障数据库一致性，很可能数据库不能正常启动。因此，这层复制技术很少用于大型数据库的容灾。

     逻辑卷层的厂商包括：赛门铁克、Lexis等等。

4．文件层复制
    基于文件层的复制，一般采用采用异步复制机制，复制对象为文件I/O，其过程为：复制上层应用传递下来的I/O，然后缓存起来，再经由传输组件传输到目标服务器，再由目标服务器写入目标存储，完成一次复制。
基于文件层的复制不能保障数据库一致性，目标数据库处于脱机状态。当生产数据库发生故障时，需要启动数据库才能恢复业务，正是由于不能保障数据库一致性，很可能数据库不能正常启动。所以文件复制一般用于事务很少、数据量很小的数据库。
    文件层：赛门铁克的低端文件复制、国内一些小厂商。
 
    四种复制技术各有优缺点。一般而言，文件层复制技术主要采用异步复制原理，不能保障数据库的一致性，不能确保数据库是好的，很少用于大型数据库的容灾。国内很多厂商都采用文件层复制，主要用于中小企业，适用于数据量不大、投入很小的场合。

二、容灾面对的核心问题——数据一致性
1.保障容灾端数据一致性的意义
     容灾系统与生产系统的数据一致性考虑在容灾建设中极其重要。什么叫数据一致性，这是个非常专业的问题。简单的讲，就是要保证生产系统、容灾系统的数据相一致。可以这样讲，如果各层不能保障复制过去的数据的一致性，那么容灾端的数据就不完整，整个应用系统就不可用，容灾完全失去意义。
    而四种复制技术由于所属层次不一严，各层的数据一致性含义是不同的。

2.应用层完全能保障容灾端的数据一致性
    应用层的数据一致性是指容灾业务数据和生产端业务数据相同，例如股票交易业务，生产端交易了10000笔，如果容灾端只复制了9999笔，那么就产生了数据不一致的问题。但是，应用层的数据不一致性相对应用程序而言是不致命的，甚至应用程序都无法感知，只有上层业务才能感知，就如同这个例子丢了一笔交易数据，那么此时需要人工干预补齐一下数据。从这个角度讲只有应用层的复制才能确保应用程序的完整性和一致性。

3.其他三层保障数据一致性的难题
    其他三层的数据不一致性对应用程序而言是致命的，很可能导致应用程序无法启动。其他三层的数据一致性比应用层的数据一致性含义复杂，这是由于复制所属层次和复制对象不一样导致的。其他三层的数据一致性包含两方面的含义：一是在磁盘上或文件上的应用程序的数据一致性，这是因为每个应用程序对存在磁盘上的数据都有一个内在的组织结构和秩序，如果这种结构和秩序不完整或被破坏，那应用程序很可能就无法启动了；二是两端的数据一致性。在I/O的路径上各层都有自己的缓存，很有可能会滞留一些I/O在自己的缓存中。

     如果在系统发生故障时，仍有部分I/O“滞留”在I/O操作中，真正写到磁盘中的数据就会少于应用程序实际写出的数据，造成数据的不一致，从而导致结构和秩序不完整或被破坏。异步复制顺序地将这些I/O复制到容灾端，故障发生时可能导致I/O复制不完整，从而也会导致这种情况发生，这就是文件层的复制不可靠的原因。
     逻辑卷层和磁盘层采用同步复制，关闭各层缓存，这样的情况一般不会发生，但是由于应用程序和操作系统的复杂性，这种复杂性本身可能导致I/O的坏块。同时，这两层还可能存在卷组一致性的问题，应用程序的数据存在多个逻辑卷或物理卷中，在这两层中很可能会出现应用程序串行写而这两层并行写的状况，从而导致磁盘上的数据的写秩序不一致，这是很可怕的。存在这样的问题，需要在调研阶段搞清楚应用程序的存储状况的，从而有针对性的实施方案。

4.非常繁忙的数据库的容灾挑战
     在一些容灾案例中我们可以看到，当SQLServer数据库面对大量的事务时，采用非顺序写日志，这与一个空闲的数据库线性写日志完全不同，颠覆了先前对数据库线性写日志的认识。有兴趣研究的同行，可以构造一个这样的测试场景，一直不断提交事务给数据库，然后监测数据库的日志I/O状况。我们猜想可能是这样的原因：当日志缓存剧烈消耗时，数据库进程采用了多线程并行写日志，这样的好处可能加快写的速度，但是采用这样的写机制会导致一个乱序的日志文件来，对数据库在磁盘上的状态来说却是一个灾难；或是，数据库发出串行的异步写调用，但操作系统内部并行写，回复状态按照调用顺序而已，这个猜想可能是错误的，这需要很懂Windows操作系统I/O管理机构的技术高手来解释。
     这样的SQLServer数据库写对其他三层的容灾技术来说，简直就是灾难，或许同步复制能保障，但是异步复制，例如文件层复制，却是不能保障容灾端数据库的一致性。所以，文件层的复制不能确保容灾数据库是好的，只能通过其他机制来补偿缺陷，例如通过回滚。
      正因如此，象医院、证券、海关、税务、电力、公安、社保、电商、交通、银行、电信等等提供公共服务的业务系统在工作时间都非常繁忙，这样的数据库采用文件复制来实现容灾是不可行的。

三、复制技术的发展趋势
     四层技术，各有优缺点。就综合复制技术原理与优缺点、投入成本、资源消耗、实施工作量、维护工作量等等方面来说，应用层的复制和磁盘阵列的复制会成为主要的容灾技术，占据很大的容灾市场份额，且应用于关键的、重要的应用系统；文件复制主要用于一些非常低端的应用。
     未来的复制技术发展不是依靠单一技术来解决自身的缺陷问题，应融合其他层的技术来发展。

      应用层要解决复制速度较慢的问题，就是要解决在目标数据库上的数据装载效率或装载方式的问题。解决了这一问题，应用层的复制还会得到更加广泛的应用。此类方案围绕应用层这个核心，结合文件层的快速复制，采用直接的原始数据装载技术，克服了应用层复制速度慢的问题，是目前应用层里面做得最好的一种技术路线。
     存储层要克服数据不一致的问题，不能单纯依靠存储的复制，要结合应用层与数据库进行一定的交互才能解决。

四、总结
从技术原理、实施、维护、资源消耗、适应场合等等总结四层技术。