【IT168 资讯】浪擎带您从投入成本、运维工作量、容灾技术指标、容灾可靠性、方案配备这些方面来选择适合自己的容灾技术或方案。本文所述的灾难是广义的，是一些常常发生的、导致生产系统停止运转的故障，而非重大自然灾害;一般而言，最需要保护的数据是结构化数据，即存储在数据库的数据。这是本文探讨的出发点。

　　一、 选择容灾技术或方案需要考虑的问题

　　1.建设目标必需适合实际需求

　　容灾建设需要符合实际需求。如果完全按照国标规定的七个要素来建设，资金、人力投入太大。在实际的建设过程中，不必好高骛远，而应根据自身的实际需求来定义容灾建设目的。仅就大部分的用户而言，建设容灾的目的就是防范一些常见故障，如防备软硬件故障、机房停电、感染病毒、黑客入侵、人为故障等破坏因素，或者准备一套备用系统用于例行维护使用，或者实现生产、查询相分离的业务建设。这样的目的是合适的、实惠的。因此，用户选择不同机房、不同楼层或楼宇的本地容灾。

　　容灾建设量力而为。对于银行、电信运营商、医疗、证券、电力、交通等行业而言，核心业务系统的数据对于企业的正常运行至关重要，一旦数据大量丢失或业务长时间中断，造成的影响是无可估量的。而对于一般行业(例如中小企业)，一方面受到资金投入、技术门槛、人员素质、管理及维护复杂度等因素的制约，另一方面发生灾难所带来的损失也不那么大，因此完全没有必要一味追求高的容灾建设等级，而是结合自身条件来选择符合RTO、RPO需求的容灾等级。

　　考虑投入产出比。除RTO和RPO两个技术指标外，用户还必需关注容灾方案的投入产出ROI(投入产出比)，衡量用户的投入与从中所获得的收益的比率。表明上看，容灾系统不像其它业务系统那样会给用户带来直接的产出收益。但事实上，容灾系统确实是有收益的。容灾系统的收益主要来源于发生故障时为用户所挽回的损失，这种损失不只包括收入方面的，信誉、客户忠诚度、法律风险等方面的损失也包含在内。如果容灾系统能够把由于故障而导致的业务停止时间显著缩短，也就间接为客户创造了收益。

　　因此，从这些角度讲，选择合适的容灾技术路线，例如基于主机的应用层复制容灾方案显得更有优势，因为这类方案不仅能大幅降低容灾系统的初始部署成本，而且管理成本也相对要低很多。

　　2.不同业务系统采用不同的容灾技术、打组合拳

　　不同业务系统采用不同的技术。故障给不同类型的业务所带来的损失是不同的，因此不能采用一刀切的方式进行灾备系统建设，而是需要细致分析业务单位信息系统的重要程度，有效区分核心业务和非核心业务，并平衡业务系统的实际需求和总体成本的关系。核心业务采用等级很高的容灾技术，例如医院的HIS、银行的“核心、授信、网银等交易系统、证券的核心交易系统等等，可采用实时复制、零恢复的技术等级;而另外一些非核心业务，如OA、报表统计等等，可暂缓考虑，或选择较低一个等级的技术。因此，用户在容灾建设时，需要根据业务系统重要性的不同，采用不同的容灾等级。

　　总而言之，在进行容灾建设规划时，单靠一种方案或一种技术是行不通的，为了实现多种等级容灾，需要有一个完整的容灾方案和技术体系作支撑。

　　3.按照“先本地、再异地”的由近及远原则建设

　　从投入成本和故障发生概率来考虑，可以先建设本地的容灾，在同一个机房不同的主机和存储上建设，或在不同的楼层建设一个备份中心，或在不同的楼宇建设一个备份中心。经济条件具备的，考虑同城建设一个备份机房。在实际的操作中，很多企业基本都会在本地建设一个高等级的、投入也不大的容灾，然后在分部或者同城其他地方再做一个异地备份。这样的建设方案投入不大、比较实惠。

　　4.“平战结合”、充分发挥容灾系统的作用

　　投入上百万的资金建设一套容灾，仅在自然灾难或其他软硬故障时发挥作用，或者软硬件放置在机房折旧贬值，没有几家公司的老板愿意这样做。

　　“平战”并不是狭窄的指在和平或战争条件，更广义的指在发生各种常见故障或者正常运行。那么，“平战结合”就是要充分发挥一套投入较大的容灾系统的额外价值。在容灾系统上部署一些供用户内部使用的业务系统，例如报表系统可以利用容灾数据库实现查询统计功能。

　　5.传统备份技术和实时复制容灾技术需并存

　　传统的数据备份难于满足高等级容灾的技术要求。虽说定时备份在一定程度上可以保证数据安全，但应用于容灾时却面临备份窗口大、备份间隔大、数据可恢复性差和恢复时间长、性能影响剧烈等众多问题，也不能满足RTO和RPO趋于0的要求。因此，传统的数据备份技术作为一种廉价的、成熟的技术，在整体的解决方案中，为容灾系统提供一种补充，或者为一些比较小的、不太重要的业务建设定时备份系统。

　　备份技术可弥补实时数据复制自身可能存在故障，或弥补实时复制技术不能克服数据逻辑错误的缺陷。

　　因此，在完整的容灾方案中，这两种技术是并存的。

　　6.定期的验证和演练是确保容灾系统可靠性的一种手段

　　需要定期的验证和演练对容灾系统而言是必需的，校验出可能导致数据不一致的因素。由于存在两端数据不一致，理论上也无法确保故障发生时容灾端数据就是好的。这就需要容灾系统提供一个可供验证和演练的方法和界面。

　　应用层的复制可以随时、直接的提供一个校验手段。因为容灾端的应用程序处于运行状态，直接查询数据就可校验数据了。也可以用自己的业务系统来连接容灾端数据来校验，例如医疗行业的用户可以用HIS软件去连接容灾端数据库。

　　7.选择懂得数据库的厂商或集成商来提供容灾方案

　　除了上述技术性选择外，还必须考量厂商或集成商的技术实力。做容灾，最主要一点就是保障数据库的稳定性和可靠性。因为，在每个企业内部存在结构化数据和非结构化数据两类数据，尤以结构化为主，就是以存在数据库的数据为主。数据库是极其复杂的应用程序，如Oracle、SQLServer等大型关系数据库，正常使用很简单，但是维护却需要极其全面和深厚的技术功底，还需要懂得操作系统和存储。不懂得数据库的存储原理和内部逻辑架构是很难做得好容灾的。这也是应用层的优势，也是浪擎科技的优势。

　　二、 四种容灾复制方案的说明

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

　　1.基于应用层事务复制的双活容灾

　　双活容灾采用应用层事务复制技术。双活容灾复制对象为应用事务，实时捕获生产数据库的变化事务，例如SQLServer或Oracle数据库的事务，经由传输组件传输到容灾服务器，然后装载进程按照数据库的关系原理排序事务，将变化事务保存到容灾数据库。容灾数据库处于在线运行状态，因此这样的容灾叫双活容灾。双活容灾代表厂商：浪擎、DSG、Goldengate、Quest、Oracle、微软等。

　　双活容灾严格保障数据库一致性，是最可靠的容灾，是最适合数据库的容灾。当生产数据库发生故障时，直接使用容灾数据库即可恢复业务运行，其容灾的RTO指标趋于零。

　　但双活容灾支持的应用有限，仅支持有限的数据库，一般为SQLServer、 Oracle、Sybase、DB2、MySQL等数据库。

　　双活容灾方案的硬件配置，需要添置容灾服务器、容灾存储等设备，但无需架设专门的光纤传输网络。当然也可以采用现有的或旧的的服务器来作为容灾服务器。如果数据量不大则无需购置容灾存储设备，直接使用容灾服务器的硬盘。

　　2.基于磁盘阵列复制的容灾

　　基于磁盘阵列的复制是磁盘阵列厂商提供的复制技术。其复制磁盘阵列上变化的数据块，经过专门的光纤传输到容灾磁盘阵列，然后保存到相应的位置。磁盘阵列层代表厂商：IBM、HP、EMC、HDS等。

　　基于磁盘阵列复制的容灾不能完全保障数据库一致性，目标数据库处于脱机状态。当生产数据库发生故障时，需要启动数据库才能恢复业务，正是由于不能保障数据库一致性，很可能数据库不能正常启动。尽管存在这样的缺陷，但这一层的复制对主机的影响极其轻微，所以还是可应用在一些非常大型、繁忙的数据库容灾，作为一种补充保护手段。

　　基于磁盘阵列复制的容灾方案成本高昂，且实施复杂。需要购置与生产存储相同规格的容灾存储、容灾服务器、光纤交换机等设备，还需要专门的专门的光纤传输网络。

　　3.基于逻辑卷复制的容灾

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

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

　　基于逻辑卷复制的容灾方案成本高昂，且实施复杂。需要购置与生产存储相同规格的容灾存储、容灾服务器等设备。实施时，还需改造生产系统的卷存储格式使之与容灾软件所需的存储格式一样。

　　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数据库写对其他三种的容灾技术来说，简直就是灾难，或许同步复制能保障，但是异步复制，例如文件复制，却是不能保障容灾端数据库的一致性。所以，文件复制容灾不能确保容灾数据库是好的，只能通过其他机制来补偿缺陷，例如通过回滚重试每个I/O来验证容灾数据库的好坏。

　　正因如此，象医院、证券、海关、税务、电力、公安、社保、电商、交通、银行、电信等提供公共服务的业务系统在工作时间都非常繁忙，这样的数据库采用文件复制来实现容灾是不可行的，更好的方法是采用双活容灾或基于磁盘阵列复制的容灾。

　　四、 四种容灾技术或方案的对比

　　就综合复制技术原理与优缺点、投入成本、资源消耗、实施工作量、维护工作量等等方面来说，双活容灾和基于磁盘阵列复制的容灾是主要的容灾技术，占据很大的容灾市场份额，且应用于关键的、重要的应用系统。浪擎科技正是双活容灾的杰出代表，围绕应用事务复制这个核心，结合文件层的快速复制，采用直接的原始数据装载技术，克服了双活容灾复制速度慢的问题，是目前应用层里面做得最好的一种技术路线。基于磁盘阵列复制的容灾很难克服数据不一致的问题，需结合定时备份技术来防备此类问题的发生。

　　基于文件复制的容灾主要用于一些非常低端的应用，并且文件复制不能支持AIX、HPUX等UNIX操作系统。

　　下面从技术原理、实施、维护、资源消耗、适应场合等总结四种容灾。

　　五、 浪擎的双活容灾

　　1.浪擎双活容灾──在线式应用级容灾

　　浪擎AgileMirror镜像系统(以下简称镜像系统)是数据库级别的实时复制容灾产品，将生产端的业务数据实时复制到容灾端服务器上，当生产端业务系统发生故障时，容灾端的备用系统可以无需恢复直接接替生产端的业务系统使用，以保证业务连续运行。

　　镜像系统支持SQLServer数据库、Oracle数据库、文件系统等应用系统的容灾;支持主流操作系统;支持单机、双机高可用等环境。

　　镜像系统为用户提供更高附加值的容灾产品。镜像系统的“容灾、容错、查询”三大核心功能，超越容灾这个技术范畴，能盘活用户的容灾投资，从而为用户带来增值的效益。查询功能为用户带来了一个极为实在的用处——创建备用数据库可以用来实现查询统计功能，分流主数据库的性能压力。

　　容错功能防止数据被损坏，保护业务数据这一最核心的资产。

　　2.双活容灾原理概述

　　镜像系统不依赖DataGaurd、LogMinor、DBCC LOG等数据库自带的日志工具来实现数据复制，完全依靠自身研发的数据库实时捕获引擎ACA和数据组装两大核心技术来实现全量复制和实时增量复制。其实时增量复制过程为：生产端代理进程实时捕捉数据库在线或归档日志的变化数据，然后传输到容灾数据库端;容灾端的装载进程按照数据库标准格式组装这些变化数据块，然后提交给数据库的存储引擎保存到容灾数据库。

　　容灾端数据库处于在线运行状态，具备最高的可靠性，且用户可以随时查询业务数据来检验容灾结果。这是双活容灾最大的优势。

　　3.主要功能

　　1)追逐式全量复制

　　在第一次部署时，且在不停止生产业务的要求下，自动的将生产端业务系统的存量数据和活动数据全部复制到备用端的数据库。无需停止生产数据库和无需停止业务系统;无需改变生产数据库的现有配置。

　　2)实时增量复制

　　在生产系统正常工作期间，实时的将业务数据复制到容灾端的备用系统。

　　复制数据库的一切变化，自适应业务调整;容灾数据库处于可读可查询状态;用户随时校验容灾数据库数据的可靠性。

　　3)CDP数据容错功能

　　将数据库恢复到符合要求的某一历史状态。容灾端容错进程采用循环写机制一一保存生产端传输来的数据。当需要容错时，容错代理接收用户选定的恢复时间或事务条件，容错进程将符合条件的一段日志数据恢复到容错数据库。

　　4)故障切换

　　当生产端发生故障时，可手动或自动切换至容灾端备用系统。浪擎科技是一家大型的容灾产品和解决方案供应商，产品种类很多。做业务容灾切换时，浪擎的Y系Mcenter产品可以提供监控、报警、切换、回切等功能，可提供完整的业务容灾解决方案。

　　5)构建生产、查询相分离的业务应用

　　容灾端备用数据库可以用来实现查询统计功能，分流生产数据库的性能压力。如，极其消耗性能的报表统计就可部署在备用数据库上。

　　这是双活容灾的附加值，超越了容灾的范畴。

　　6)实施全程无需停机

　　实施无需停顿业务系统，适合7X24小时连续运行的业务系统，这一点非常关键。

　　4.典型应用

　　1)为重要业务构建双活容灾

　　不同重要性的业务系统采用不同技术等级的产品，保护全部业务环境，整体方案性价也非常高，这得益于浪擎科技全面的产品线。

　　关键业务采用镜像系统，实现备端在线的、双活的、可自动切换的容灾，保障关键业务不停顿;一般业务系统采用D实时备份系统，实现数据的实时备份。双活容灾可以结合VMWare或HYPER-V等虚拟化软件，将备用端构建在虚拟服务器内。

　构建双活容灾示意图

　　mCenter提供统一的监控、管理功能。当主、备系统发生异常或故障时即刻发出短信报警，通知到相关技术人员，还可实现手工切换或自动延时切换业务服务。浪擎提供镜像双活、DX备份存储一体柜、EX磁盘阵列、容灾服务器等软件或设备，构建双活容灾、一体柜数据备份的整体方案。

　　2)构建两地三中心容灾方案

　　浪擎设计的备端在线两地三中心整体灾难恢复解决方案，可以满足不同灾难场景下的业务连续性要求。本地机房的容灾主要是用于防范生产生产服务器发生的故障，异地灾备中心用于防范大规模区域性灾难。本地机房的容灾由于其与生产中心处于同一个机房，可通过局域网进行连接，因此数据复制和应用切换比较容易实现，可实现生产与灾备服务器之间数据的实时复制和应用的快速切换。异地灾备中心由于其与生产中心不在同一机房，灾备端与生产端连接的网络线路带宽和质量存在一定的限制，应用系统的切换也需要一定的时间，因此异地灾备中心可以实现在业务限定的时间内进行恢复和可容忍丢失范围内的数据恢复。

　两地三中心的容灾方案

　　为关键业务系统构建容灾机制;实现异地和本地容灾相结合的一对二容灾;持续保护核心数据;增量复制减少对生产系统的影响;无需主备服务器的硬件规格完全一致;备用数据库可见可查询，保证容灾效果实时可见;实施过程无需停止主服务器和数据库，保证主系统7X24小时不间断正常运行。

　　浪擎为用户设计了采用异地和本地数据复制容灾相结合的一对二容灾的容灾方式，实现了北京本地和从北京到上海的远程异地容灾。

　　3)构建容灾、查询方案

　　除满足业务系统的灾备需求外，还可将业务查询或统计功能部署在查询服务器上，不但能减轻主系统的性能压力，还可提升灾备系统的增值效益和盘活灾备的投入。镜像系统的备端在线、双活的技术特点正是满足这样的需求。

构建查询系统示意图

　　在生产中心数据库服务器上部署镜像系统的客户端代理软件，在备份中心部署两台数据库服务器。通过客户端代理软件将主服务器的业务数据实时复制到容灾服务器上，在备用服务器上安装镜像系统恢复端软件再将数据恢复到查询服务器上，实时恢复实现查询等功能。上图中采用了镜像系统级联能力，实现三层的、多对一的容灾、查询功能。也可采用两层架构，即主服务器、容灾服务器，省去存储服务器中间层，将查询功能直接部署在容灾服务器上。

　　业务系统可能需要做一些调整，将查询或统计功能模块的数据库连接设置到查询数据库服务器上。这需视具体业务环境来做调整。