金融行业数据容灾架构中的数据复制技术

作者：赵海  大连农商银行  架构师

擅长主机、存储、数据库架构及方案设计及实施技术。曾参与过保险、航空以及银行等多个数据中心基础架构规划及实施项目，对Oracle及虚拟化存储网关容灾技术有过深刻研究和具体实施经验。目前在社区关注排行榜中排行第3。

 

随着全球IT产业的飞速发展，金融行业的IT建设逐步成为主导金融企业业务发展的核心驱动力，基于金融行业IT系统容灾建设的各种行业标准以及监管标准也相应提高。而决定容灾架构健壮与否的最关键因素就是数据复制技术，它是实现高标准RTO和RPO的前提条件。本文基于业界主流数据复制技术的原理、复杂度、关键因素以及复制效果等多个维度进行分析及论述，旨在为同业在此类项目规划和建设过程中提供一些启示和帮助。

 

1.背景及综述

在金融行业内，众所周知其对业务连续性的要求以及对各种IT风险的应对能力的要求都是非常高，尤其是对容灾能力的要求，这是由它的业务特殊性以及集中式架构所决定的。

在金融企业容灾架构中，所谓的数据复制技术主要是指能够将结构化数据进行复制，从而保证数据具备双副本或者多副本的技术。

目前业界发展来看，可以实现数据复制的技术多种多样，有基于数据库层面的数据复制技术，例如Oracle公司的Active Data Gurad、IBM公司的 db2 HADR等；有基于系统层面的数据复制技术，例如赛门铁克的vxvm、传统的逻辑卷管理（LVM）、Oracle公司的自动存储管理（ASM）冗余技术、IBM公司的GPFS等；有基于存储虚拟化实现的数据复制技术，例如EMC公司Vplex Stretch Cluster、IBM公司SVC Split Cluster、NetAPP公司Metro Cluster等； 也有基于存储底层实现的数据复制技术，例如IBM公司的DS8000 PPRC技术、EMC公司的SRDF技术、HP公司的CA技术等等。

每一种技术都有其实现的前提条件，也有各自的技术特点和实现的不同效果。本文将从复制技术的原理、特点、复杂程度以及复制效果等多方面展开分析及论述，并从多个维度进行对比分析，将业界主流数据复制技术的发展现状以及技术优劣给予一个清晰的展示，并就数据复制技术发展的未来以及趋势予以展望。

 

2.数据复制技术价值分析

2.1 数据复制在容灾中的必要性

一、RPO保障

如果没有数据复制技术，那么容灾也就无从谈起。当面临站点及故障时，由于没有数据复制技术的支撑，我们的数据无法在其他站点再现，这将意味着RPO将无法保障。对于一个金融企业来讲，最终要的就是客户的数据，它是企业的生命。从这个意义上来讲，金融企业不能没有容灾体系，容灾体系的前提条件是能够实现数据复制。那么数据复制的效率如何，复制的效果如何，复制技术的先进与否也就决定了金融企业生命线的稳固与否。

二、RTO保障

所谓RTO就是在容灾系统在面临站点级故障时，多长时间能够恢复业务。假设站点故障恢复的时间不可容忍或者根本没有可能，那么业务必须能够切到另外一个数据中心，从数据、应用以及网络层都需要具备这个切换能力。但是最终的目的就是要保障业务能正常恢复，而业务恢复的前提条件就是数据，没有数据的应用切换和网络切换没有任何意义。也就是说数据恢复是应用切换以及网络切换的前提条件，从这个意义上讲，数据复制效率和效果直接决定了一些列切换，也就是它使得RTO成为可能。

2.2 评价数据复制技术的维度分析

对于数据复制来讲，我们可以从多个层面、多种技术去实现。各有各的特点，那么究竟哪一种数据复制技术更适合我们？活着说哪一种复制技术更科学合理？这需要一系列从不同纬度进行的科学评估。本文认为应该从以下几个方面来展开分析，并结合我们自己的需求来选择合理的数据复制方案。

一、投资成本分析

建设任何一个项目，投资成本的分析都是必不可少的分析维度。对数据复制技术的投资成本分析来讲，我们需要从它的首次建设成本、持续维护成本以及容灾管理成本等多方面去考虑。

二、技术成熟度及健壮性分析

对于数据复制技术的成熟度和健壮性分析来讲，一方面我们要从技术本身的原理上来分析，另外我们还需要从技术的发展以及应用范围以及应用的持久稳定性等方面来考虑。

三、风险评估分析

数据复制技术本身来讲是要帮助我们解决站点级故障带给我们的IT风险，但是对于技术应用本身来讲，它也会存在一些技术风险。比如说特殊场合下的一些技术风险、容灾管理过程中的一些风险、极端场合下的一些技术风险等等。

四、功能拓展性分析

对于数据复制技术本身来讲，其主要功能就是完成数据的复制。但是在完成数据复制的同时，由于其架构的特点以及技术特点等因素有可能对于我们的应用产生积极的拓展性作用，也有可能限制了我们的应用架构模式，还有可能对我们的基础架构扩展性以及灵活性造成一定的限制。

 

3.数据复制技术原理分析

3.1 基于应用事务日志回放技术

图3.1是Oracle数据库层面的数据复制技术（ADG）的架构原理图。

对于该架构原理图，本文从其实现的基本条件、数据复制原理、数据复制的模式以及数据复制的关键因素等几个方面来进行深度剖析。

图3.1-1 Oracle Active Data Guard

3.1.1前提条件

容灾站点之间需要有三层以太网连通，软件层面需要数据库的集群软件模块（Oracle Active Data Gurard）或者是db2 purscale hadr。服务器层面需要至少两套服务器系统分别部署于两个数据中心。存储层面需要两套存储空间分别部署于两个站点作为主库存储和备库存储，他们互相之间独立。

3.1.2复制原理

对于主站点的数据库来讲，客户端的数据更新请求首先要由日志写入进程写到重做日志当中，然后由数据写进程再周期性地写入数据文件当中。重做日志当中以SCN为数据库独有的时间搓序列来记录所有数据库更新的先后顺序，从而保障数据库恢复能够按照正确的顺序执行保障数据一致性和完整性。那么对于配置了Active Data Guard的数据库读写的完成在以上所述过程中，日志写进程在本地日志文件写入过程的同时，日志传输进程会将缓存里面的重做日志通过ADG传输给灾备站点的备库实例，备库实例的日志接收进程根据接受到的重做日志在备库上重新执行数据库的更新操作，从而保证主库和备库的事务性更新行为一致性，最终保证数据的一致。当然也有一个前提条件，那就是在ADG作用之前，必须保证备库的数据保持与主库的某一固定时间点的完整副本，这需要靠传统数据备份技术来实现备库的初始数据复制。因为事务复制的本质是行为复制，那么行为作用的初始数据副本必须保持一致，才能保证最终两副本的一致性。

对于事务日志的复制技术，本文根据主库IO周期特点可以分为绝对同步模式、近似同步模式和异步模式三种。绝对同步模式是指主库的一个完整更新事务的结束既要包括主库的重做日志落盘也要包括备库的重做日志落盘，也就是说备库重做日志落盘之后返回给主库，主库才能执行下一个事务。近似同步模式是指在传输正常情况下保持与绝对同步模式一样的模式，在网络传输超时的情况下，就会剥离备库重做日志的过程，只要保证主库重做日志落盘就可以了。异步模式是指主库只保证本地重做日志落盘，并不会等待备库重做日志落盘的返回信号。在后两种模式下，当主备库传输管理剥离之后，主库会主动通过以下两种方式探测并尝试重新和备库建立联系，第一是归档日志进程会周期性ping备库，成功情况下，它会根据获得的备库控制文件的记录的最后归档点和自己的归档日志决定向备库推送哪些归档日志。第二是日志发送进程会在重做日志准备发生归档的时刻点主动去ping备库日志接受进程并把剩余的重做条目发送给备库接受进程。

3.1.3关键因素

基于事务日志回放技术的数据复制架构，从技术规划上以及运维管理层面上有几个关键因素需要把握才能将这种数据复制技术运用自如，才能帮我们真正实现高标准的容灾体系建设。

一、重做日志管理策略设计

我们知道对于数据库来讲，我们是靠其在线重做日志和离线重做日志来进行数据恢复的。对于离线重做日志也就是归档日志，我们是需要周期性备份并删除的，否则离线重做日志就会无限占用数据库有限的存储资源。那么对于事务日志型数据复制架构来讲，无论是主库还是备库，都需要有合理的日志管理策略来配合才能正常运行。策略的规划和设计需要把握以下几个原则：

1．完成应用的日志要及时转储，包括主库传输完毕的归档日志和备库应用完毕的归档日志。

2．没有完成应用的日志必须能够保留，主库没有传输到备库的归档日志如果被提前转储会造成备库数据丢失，备库没有被应用的日志如果转储，备库同样会丢失数据。

3．存储资源的科学规划，如果主备库暂时中断，又因为原则2导致归档日志堆积，那么势必造成存储资源的需求超过正常时刻的存储需求量，如果存储资源不够，又会造成数据库发生宕机事故。

以上各个原则的科学设计既需要依赖于数据库参数的合理设置，又需要依赖于备份工具的转储策略合理配合，同时更需要根据不同的业务系统以及负载特点，通过历史数据评估以及仿真测试数据来设计合理的数值并进行动态评估和优化。

二、架构扩展性及灵活性

在今天的互联网线上时代，系统架构的扩展性和灵活性显得尤为重要。对于容灾架构来讲，它的扩展性和灵活性同样非常重要。对于业务型的数据复制架构来讲，它有两种基本架构：级联架构和串联架构。级联架构是指一点为主多点为备，串联架构是指主备模式依次类推。级联架构更有利于主库的多点保障，串联架构更有利于主库的性能保障。具体采用什么样的架构组合，是要根据主库数据的具体业务需求进行合理评估和设计。

三、容灾切换管理

主备库的切换，包括两种类型的切换：Fail Over & Switch Over。

Fail Over是指故障情况下的强制切换，Switch Over是指计划性的切换。无论是哪种切换首先是要保障备库数据和主库数据一致或者可容忍范围内的近似一致。其次当数据发生切换时，实际上主库的服务IP地址就会转化成备库的服务地址，无论是通过域名转换还是通过应用重连的方式都需要保障上层的服务地址能够无缝切换。最后切换之后，原来的主库如果没有时间戳恢复功能的话，那么原主库里面的数据就会变成无效数据，需要重新初始化数据副本。但是如果保持时间戳恢复功能的化，就会巨大的存储空间消耗。

3.2 基于系统级逻辑卷镜像技术

下面三张图都是基于系统级逻辑卷镜像技术实现的数据双重复制。图3.2-1是基于ORACLE自动存储卷管理技术实现的ASM磁盘卷镜像复制技术；图3.2-2是基于UNIX存储卷管理（LVM）实现的逻辑卷镜像技术；图3.2-3是基于IBM GPFS分布式文件系统底层逻辑磁盘镜像实现的数据复制。三种技术虽然依赖的具体技术不同，但是其底层原理都是基于系统层面的双写实现的数据复制。

图3.2-1 ORACLE ASM复制镜像架构

图3.2-2 LVM镜像复制架构

图3.2-3分布式文件系统GPFS镜像复制架构

3.2.1 前提条件

容灾站点之间需要SAN环境联通。软件层面，架构一需要具备ORACLE集群软件当中的自动存储卷管理模块，架构二需要借助UNIX操作系统层的逻辑卷管理器，架构三需要借助GPFS或者类似的分布式文件系统软件。存储层面需要两套存储空间分别部署于两个站点作为主库存储和备库存储，他们互相之间独立。

3.2.2 复制原理

对于ASM和LVM模式来讲，都是将底层来自不同站点的两个物理存储卷作为镜像对组合成一个可用的逻辑存储卷提供给上层应用来存放数据，本地物理卷和远程物理卷分别是由存储经过本地SAN环境以及跨数据中心SAN环境提供给服务器操作系统层。LVM是对操作系统的PP写入进行实时双向复制，而ASM是对Oracle数据文件AU写入进行实时双向复制。本地写完并且远端写完才能算是一个完整的写入，假设远端存储卷写入超时就会被标为故障或者是离线状态，当远端存储写入恢复之后，对于LVM来讲需要重新进行手动同步实现镜像副本完全一致。而对于ASM来讲，会有一个短时间内的日志记录会帮助恢复离线镜像恢复数据，但是如果超过这个时间，同样需要一个全新的同步来保证数据的一致性。二者的区别在于LVM的逻辑卷与物理卷的映射关系在创建逻辑卷的时候就已经定义好了，所以对于坏块儿问题，LVM无法完成块儿指针的动态转移。而ASM是在数据写入时才会分配具体的AU，完全可以做到通过指针转移的方式避免坏块儿导致的数据写入失败问题。

对于GPFS模式来讲，它是通过将底层来自不同站点的两个物理存储卷归属到不同的Failure Group当中，然后由这些物理存储卷经过文件系统格式化形成分布式文件系统，提供给上层应用以文件的形式写入数据。文件本身会被GPFS文件系统打散形成若干文件碎片，这些碎片在落盘时分别落入不同Failure Group当中的物理磁盘，从而保证底层数据的双副本。这种模式与前两种模式的最大区别在于它的数据落盘是根据NSD磁盘定义的服务实例顺序来决定的，正常情况下我们需要定义本站点的服务节点为磁盘的主服务节点，这样的话两个镜像写入的时候是靠GPFS位于不同中心的两个服务实例节点分别写入，两个服务实例之间也需要私有协议的交互，相当于数据的双写多了一个环节。

3.2.3 关键因素

基于系统级逻辑卷镜像技术实现的数据复制，相对于其他类型的数据复制技术来讲风险性较高，主要表现为以下几个方面：

一、性能方面的问题

对于LVM和GPFS方式来讲，对于数据库的结构化数据复制性能会有较大损耗。因为数据库的读写需要经过数据库本身的存储映射以及操作系统层的存储映射之后才能真正写入存储缓存。纵向的路劲很长，性能损耗会比较大。而ASM本身是将数据库的映射和系统级的映射做到了一起，相对性能损耗会低很多。所以如果利用这类型数据复制技术的话，数据库层的存储块儿参数和操作系统层的存储块儿参数设置要经过一系列优化。

二、容错性问题

如果我们用做本地存储高可用实现这种方式的镜像，那么容错性就不会有问题。因为两个镜像副本的链路指标可以认为是同质的，镜像之前的IO读写不会有差异。但是如果用在容灾场合下，由于两个镜像副本的链路指标完全不同，那么就要求系统层能对正常场合下、故障场合下以及故障恢复后场合下的读写差异有很好的容错性。比如说故障场合下的IO超时反馈速度、故障恢复之后的数据再同步问题。再有就是关于应用数据的容错性，对于纯粹操作系统层面的复制，完全无法避免应用逻辑错误。

三、负担过载问题

其实这种技术在设计之初并没有过多考虑过其在容灾中的数据复制问题，设计初衷还是系统层的存储卷的虚拟化管理。所以其灵活性以及扩展性优于其在容灾数据复制中的作用。如果非要把这类技术应用到容灾场合的数据复制当中，那么操作系统层一方面要完成应用功能载体作用，另外一方面要完成本地存储卷虚拟化作用，还要一个重量级的容灾数据复制作用。这种负担会直接影响到其承载的数据库应用。

3.3 基于存储网关双写复制技术

所谓存储网关双写复制技术，就是在物理存储层之上增加一层网关技术用以实现存储底层的虚拟化以及高可用镜像，并且由存储网关来控制镜像写入的策略和模式。IBM、EMC、NETAPP等公司都有相应技术的产品方案。基于写入原理及策略的不同，又各有区别。图3.3-1、图3.3-2、图3.3-3分别是IBM SVC Split Cluster、EMC Vplex Stretch Cluster、Netapp Metro Cluster。下面我们就其图示、从原理上分别进行分析和论述。

图3.3-1 IBM SVC Split Cluster

图3.3-2 EMC Vplex Stretch Cluster

图3.3-3 NetaApp Metro Cluster

3.3.1 前提条件

容灾站点之间需要SAN环境联通，TCP/IP实现三层可达。两个站点分别要部署各自的存储集群节点，共同组成存储网关集群。假设要实现双中心的自动化仲裁及切换，那么第三个仲裁站点以及站点中承载仲裁软件的计算及存储载体也是必须的。

3.3.2 复制原理

对于Vplex Stretch Cluster来讲，首先两个存储网关节点是一对类似ORACLE RAC模式的AA模式集群节点。如图3.3.2-2所示，两个节点都可以接受来自上层应用的读写请求。假设来A和B分别是来自底层存储的两个物理卷，那么经过Vplex集群化之后，这两个物理卷被虚拟化集成为一个分布式共享卷C，对于C来讲，两边的应用节点都可以看得到，都可以读写，它的底层又是有A和B两个物理镜像组成。两个站点在写请求到来时，首先要完成本地A或B的写入，然后需要把写入请求传送给另外一个VPLEX节点来完成镜像盘B或A的写入。很显然，两边同时写入就有可能带来同一个数据块儿的访问竞争，这个时候Vplex节点靠他们共同维护的分布式一致性缓存目录来对竞争数据块儿进行加锁以及释放等协同操作，最终完成对数据块儿的最后更新。当发生链路故障而导致一边节点无法写入时，那么节点会保存相应存储日志用以故障恢复之后的数据同步。我们可以理解该同步模式类似于Oracle的最大可用模式，正常情况下保证镜像数据写入的同步完成，当故障时刻会有timeout时间阈值来决定是否暂时切断其中一个镜像的写。

对于IBM SVC和NETAPP MCC架构来讲，它们同样在存储网关节点上实现对底层两个物理卷的镜像绑定，但是这个卷并不是一个分布式共享卷的模式，仅仅是一个实现了镜像绑定的虚拟卷，对于卷的读写只能以其中一侧节点为主，另外一侧节点为备。节点发生故障场合下实现节点主备切换，它比传统HA模式的切换先进在哪里呢？它的备节点是要从主节点上同步缓存的，所以一旦切换发生，时间仅仅耗费在虚拟卷的Ownership转换上，缓存不需要重新读入，从切换的时间上来讲要比传统HA快很多，从而保障了容灾的RTO。

那么MCC和SVC的区别在于什么地方呢？对于SVC的Split Cluster的两个节点来讲，它们是两个控制器节点组成的一个IO组，这个IO组意味着故障切换只能发生在这两个控制器节点之间，而且对于一个物理卷来讲只能归属于一个IO组，当这个IO组不可用时，那么这个卷也就无法读写了。对于MCC来讲，承载虚拟卷读写的载体是SVM虚拟机，这个虚拟机是一个资源的组合体，可以动态组合网络、存储以及存储操作系统等资源，所以它能在组成集群的四个控制器节点上进行动态切换，理论上可以切换到任何一个控制器节点上，只不过其切换本身有一个故障优先级控制其切换的顺序。如图，SVM可以首先切换到A2节点上，当A2节点也发生故障时，可以切换到B1节点上，当B1节点也发生故障时可以切换到B2节点上。

3.3.3 关键因素

基于存储网关双写技术实现的容灾数据复制，可以将数据容灾管理功能从应用及系统层剥离，从而对上层影响相对很小，而且容灾针对性设计保障其功能实现上会更优。但是其实施的复杂度相对较高，而且对于以上不同架构来讲，其所承担的风险也是不一样的，所以在这类技术的应用上，我们需要特别关注以下几个方面：

一、架构复杂性

无论是以上哪种存储网关复制技术，那么从硬件条件上来讲，存储这一层需要通过硬件节点组成一层统一存储集群。要想实现自动切换的话，那需要仲裁站点的参与。也就是说从存储这一层来讲，其实两个站点就是一个系统的整体了，底层的复杂性就很高了。如果数据库层、网络层以及应用层的架构再稍微复杂一些的话，那么整个容灾架构的复杂度就会直线上升。

二、架构扩展性问题

在这种容灾架构下，其实存储层不仅仅是作了一层虚拟化和集群化，更重要的是作了一层存储的集中化，存储网关成为存储的统一出口。那么存储网关集群的横向拉伸能力制约了整个存储系统的可扩展能力。当我们的业务出现快速膨胀的场合下，存储网关集群的最大扩展能力以及其本身的纵向性能扩展性就会是一个关键性问题，我们必须考虑。

3.4 基于存储底层块儿复制技术

基于物理存储层之间的软件复制技术是相对比较传统的存储复制技术，应用的时间也比较长。几乎每一个存储厂商都会有针对性的解决方案。图3.4-1是基于存储软件复制技术的基本原理图。

图3.4-1 存储层软件复制

3.4.1 前提条件

对于物理存储底层的块儿复制技术来讲，对于环境要求主要是存储层的要求。容灾站点之间需要SAN环境联通，两边的存储一般要求型号一致并且配置有专门的存储复制软件以及相关许可。

3.4.2 复制原理

其实对于存储存储底层的块儿复制技术来讲，它跟上层的应用层关系不大，主要是依靠存储层两个节点来完成源到目标的复制。当上层应用将数据写入存储的时候，那么由存储将这一IO请求再以块儿的方式传输到另外一个存储上，从而保证存储设备在块儿级别上的一致性副本。对于同步复制来讲，需要应用端的IO请求等到存储层的复制完毕之后才会正常返回，对于异步复制来讲，应用IO请求跟底层复制没有任何关系，不需要等待复制结果。对于这种复制技术来讲，两个数据副本仅仅是数据内容相同，在上层没有任何逻辑捆绑或者是虚拟化，所以上层应用也是完全隔离的两套应用，一旦存储发生故障，无论上层应用节点及网络节点是否可用都需要发生站点级切换实现业务连续性，存储本身不能隔离开应用发生切换。

3.4.3 关键因素

对于物理存储层面的块儿复制技术，它剥离了对上层应用的依赖，直接靠存储来完成数据复制。好的地方在于它的架构相对简单、相关影响面较小，不好的地方在于它的功能狭窄，功能仅仅在于数据的拷贝，对于上层应用的支撑面儿很窄。所以对于这种复制技术的把握需要注意以下几个点：

一、容灾的切换管理

对于容灾的切换管理，我们需要决定好几个问题：

1.切换的决策问题。如果故障集中在存储层面，而其他层面不受任何影响的场合下，那么是不是一定要执行容灾切换？这需要一个完善的决策体系来支撑各种场合下的故障应对。

2.切换的流程以及技术管理体系建设。由于这种数据复制技术对上层依赖的耦合性非常低，那么单纯的存储切换无法实现，这就需要从上到下的一系列技术措施和管理流程来应对容灾切换。

3.回切的流程及技术管理体系建设。同样当故障恢复之后，我们需要回切的时候，这个过程虽然是个计划内的事件，但是可能相对比容灾切换更要复杂、更需要关注。

二、技术兼容性

基于存储底层的块儿复制技术，其中最重要的软件依赖就是存储复制软件，但是这个存储复制软件一般都是基于特定的存储设备实现的，具有厂家或者设备壁垒。当我们的存储呈现五花八样的时候，那么这个核心的复制软件可能也会呈现五花八门。对于存储的升级换代或者更换品牌等事件更是有诸多限制。所以我们在应用此类技术的时候要充分考虑到这一点。

 

4.数据复制技术对比分析

4.1 关键维度的对比分析

4.1.1 投资成本对比分析

对于投资成本的分析，我们不仅仅要看建设成本更需要关注运维成本，不仅仅需要关注设备成本更需要关注管理成本。本文首先将成本划分为几个部分，然后根据每一个部分成本按照定性分为高中低三个指标，最终得出的综合分析如表4.1.1所示：

表4.1.1-1 成本分析表

A = 基于数据库失误日志回放技术。

B.1 = 基于系统级逻辑卷镜像技术（数据库管理存储卷镜像）。

B.2 = 基于系统级逻辑卷镜像技术（系统层管理存储卷镜像）。

C.1 = 基于存储网关双写复制技术（Vplex模式）。

C.2 = 基于存储网关双写复制技术（SVC&MCC模式）。

D = 基于存储底层块儿复制技术。

对于以上成本分析，有几个需要说明的地方。

对于网络成本，以太网三层可达我们认为成本属于低指标，对于二层可达或者是需要FC协议环境的我们认为成本属于中指标，对于二层可达或者是FC环境的，而且对带宽要求非常苛刻的我们认为是高；对于设备成本，对于存储兼容性没有任何要求的而且不需要购置硬件设备的，我们认为属于低指标。对存储设备型号有关联性要求的我们认为属于中指标，对需要购置网关设备的我们认为是高指标；对于软件成本，如果有在数据库层、系统层以及存储层没有任何附带软件许可的我们认为属于低指标，如果既有附带软件模块儿而且还有容量许可等我们认为属于高指标；对于运维管理，不需要数据库层面做特殊运维的我们认为属于低指标，需要数据库维护的属于中指标，需要存储高度支持而且需要数据库应用等熟练实施整套切换的属于高指标；对于容灾管理来讲，可以实现自动化切换或半自动切换的我们认为低指标，需要人工切换的我们认为是中指标；需要组成专门的容灾决策管理体系并实施专家级切换的我们认为是高指标；对于风险管理成本完全取决于架构本身的风险程度高低。

4.1.2 技术健壮性对比分析

单就数据库层面的数据来讲，从复制有效性上来讲基于事务日志回放技术可以有效避开底层物理存储卷的物理视图，就数据库逻辑层面组成很好的逻辑视图，数据的复制可以很好避开底层发生的逻辑块儿错误等问题。而其他任何一项技术都无法避免存储块儿逻辑错误问题，因为它们在复制数据的过程中跟上层应用没有任何校验过程，那么当存储块儿上发生的配置性逻辑错误就会导致上层应用数据出现校验错误。

从技术的专有属性上来讲，基于系统级逻辑卷镜像技术的初衷在于数据的本地保护，并不是基于容灾需求所生的技术，所以在跨地域链路的容错技术上要弱于其他的专用容灾数据复制技术。

从数据传输的复杂性上来讲，除了上述C.1属于双向同步技术，其他技术全部属于单向同步技术，双向同步技术的稳定性和技术可靠性相对会低于单向同步技术。

4.1.3 技术风险对比分析

一、应用数据有效性风险

举一个极端的案例，假设一个系统层面的误操作把数据库卷的元数据清除掉了，那么主库在下次要访问到这个卷上数据的时候可能就要发生宕机。这个时候如果我们是基于事务回放技术做的数据复制，那么这部分误操作就不会被复制到备库，备库数据依然可用。但是如果从操作系统层或者是存储层做的数据复制，它是无法感知这一误操作的无效性，所以逻辑错误依然会被复制到灾备中心，那么最终的结果就是两个数据中心的数据库都无法工作。

二、远程链路抖动风险

容灾必然会涉及到远程链路，那么远程链路相对于本地链路来讲，抖动问题就是一个很难解决掉的问题。既然不能解决这个问题，那么就应该看到一旦这个问题发生了，带给我们的风险是什么：

首先我们来看事务日志回放技术，假设我们使用的是近似同步模式，那么链路一旦发生抖动，直接影响就是日志同步会随着发生不间断超时，主库缓存里的日志条目无法及时同步到备库。当链路恢复稳定之后，归档日志和在线日志分别发起同步请求将主备库数据追为同步，这期间主库不受任何影响。

接着我们来看系统级镜像技术，远程链路抖动导致远程镜像写入失败，当然这个失败会有一个从底层存储、光纤链路以及操作系统等多层的超时的传递效应，每一层都会有自己的超时策略，反应到数据库层之后，这就是一个不小的应用等待。当链路恢复稳定之后，会有一系列的镜像同步过程，这个镜像同步过程需要对主镜像进行扫描分析，会有很高的性能消耗。

然后我们再来看存储网关双写技术，链路抖动一旦超过仲裁阀值就会引起存储网关集群的仲裁，这个仲裁结果不确定，有可能会发生切换而且会频繁切换，一旦发生切换不仅仅要面对两边数据主备同步模式频繁变化，而且还会面对上层应用在面临链路抖动情况下的跨数据中心的频繁访问，相当于将不稳定问题又向上转嫁了一层。这样的复杂问题组合到一起，风险性相对较高。

最后我们再看物理存储层的块儿复制技术，其实他和事务日志回放技术面临的风险几乎相当，影响的仅仅是远程数据副本的继续同步，本地存储写入不受任何影响。链路稳定后，同样面临存储层底层数据追平问题，当然这个策略和模式根据不同厂商的设计原理会有优劣之分，这里就不再详细讨论。

三、容灾切换技术复杂度风险

探讨这个问题的前提条件是抛开一切其他类似链路抖动之类问题，仅仅探讨当发生站点级故障并且短时间无法恢复故障时刻，不同数据复制技术带给我们整个容灾切换的复杂度。基于存储网关双写技术基本上会有一套完善的存储层切换机制，依靠仲裁站点能够实现自动化切换，只要双中心之间的SAN环境相通，数据库应用层自然也是无缝切换。基于应用事务日志回放技术就完全要靠人工来实现数据库的切换以及应用访问的切换了，需要依靠数据库专家来判断主备库状态以及具体的切换策略。这个不仅仅是技术上的风险而且是管理决策上的风险。基于系统级镜像技术的切换需要依靠操作系统层的共享卷组或者共享文件系统或者是ORACLE集群来完成切换，属于自动化或者半自动化切换。而基于物理存储块儿复制技术的切换则是一系列的冷切换，数据库是一个全新数据库的重新初始化，只不过底层存储卷上的数据是主站点上的副本而已。

四、性能上的风险

对于性能上风险主要是指数据复制过程本身消耗的存储资源以及计算资源的性能对业务上的性能影响如何。我们希望的是数据复制过程本身对主业务没有任何性能影响，但是由于这两者的高度关联性，尤其是同步模式或者近似同步模式的场合。对此我们可以描述为下表（近似同步模式）：

表4.1.3-1 性能影响程度及范围

A = 基于数据库失误日志回放技术。

B.1 = 基于系统级逻辑卷镜像技术（ASM模式）。

B.2 = 基于系统级逻辑卷镜像技术（LVM模式）。

B.2 = 基于系统级逻辑卷镜像技术（GPFS模式）。

C.1 = 基于存储网关双写复制技术（Vplex模式）。

C.2 = 基于存储网关双写复制技术（SVC&MCC模式）。

D = 基于存储底层块儿复制技术。

4.1.4 功能扩展性对比分析

这一项的对比分析在于我们应用的数据复制技术对于应用层以及整个架构的扩展性和灵活性的影响程度，容灾架构固然重要，但是对于真个基础架构来讲，容灾指标是其中很重要的衡量指标之一，我们还有对架构扩展性、灵活性以及性能评估等多个方面。所以容灾架构的设计不能制约其他指标的发展。详细对比分析参照表4.1.4-1。

表4.1.4-1 功能扩展性对比分析汇总表

 

5.总结及展望

本文对企业容灾过程当中涉及到的各种数据复制技术进行深入调研分析，并且根据其实现的技术原理进行剖析，从原理底层来分析其在实际容灾应用过程中的技术优势和面临的风险劣势，同时根据企业容灾应用过程中所面临的具体需求来对比分析几类复制技术的差异，旨在为同行选型及实施提供技术参考。同时也希望有更多同业基于此提出更优化更科学的思路和想法。

转载：http://www.360doc.com/content/18/1209/10/61128821_800385199.shtml

欢迎关注

架构师成长营