数据容灾备份中心建设实施方案设计书

./WORD格式下载可编辑×××单位数据容灾备份中心建设方案书〔DSG－Realsync数据复制容灾技术迪思杰〔北京数码技术有限公司DSGdataInc..目录第一部需求分析71容灾项目建设需要注意的几大问题81.1为什么要建容灾系统81.2容灾不能替换备份81.3容灾项目需要多大的投资？101.4容灾项目如何解决投资回收问题111.5容灾项目对生产系统性能的影响121.6选择什么容灾技术能保证项目实施成功？122容灾项目的建设原则"平战结合"132.1变成本中心为利润中心132.2核心业务的灾备平台132.3业务负载分担132.4容灾技术的推荐"DSGRealSync"14DSG-RealSync数据同步复制容灾产品应用案例14DSG-SnapAssure高速备份产品应用案例152.5DSGRealSync数据库复制产品的特点163容灾技术对比和分析193.1容灾产品概述193.2基于异地备份技术实现容灾的分析193.3基于应用层容灾技术的分析203.4基于磁盘阵列复制容灾技术的分析203.5基于存储卷复制容灾技术的分析223.6基于虚拟化存储技术的分析233.7基于OracleDataGuard容灾技术的分析243.8DSGRealsync容灾技术的分析26第二部整体方案设计294方案设计<案例：西部证券>304.1需求分析304.2DSG灾备一体化产品线304.3Snapassure与Realsync的关系304.4容灾技术的推荐314.5系统结构324.6实时复制软件realsync配置334.7定时备份软件snapassure配置334.8功能实现334.9性能和资源需求估算34网络需求34日志分析速度34每秒钟复制的操作数34复制数据延迟35CPU资源占用35源端的缓存空间35业务切换35RTO,RPO指标规划354.10备份和灾难恢复策略设计36本地和异地的数据实时备份36本地数据定时备份36灾难恢复策略375方案设计的要点385.1OPS/RAC的支持385.2数据完整性保证395.3数据初始化装载395.4选择性复制支持415.5支持的复制结构415.6产品规格425.7其他关键问题〔DSG－RealSync的关键答复426DSG-RealSync解决方案的特点446.1业务功能实现44主备系统数据库处于双活状态44以数据保护为中心,侧重于保护业务数据安全44数据延迟44数据损失446.2性能和稳定性45对源系统性能的影响45对网络资源的使用45数据延迟45对主中心的影响46复制环境的健壮性46事物的完整性和可用性466.3配置和实施47开放性47对源系统的修改工作476.4可扩展性47对系统扩容的影响47业务扩展的影响47对双机集群的支持477DSG-RealSync产品工作原理487.1日志抓取〔DataCapture487.2日志分析〔Analyze497.3交易合成〔Synthesize507.4交易传输517.5数据装载51用DXF数据格式的装载：52Rowmapping实现快速定位528DSGSnapAssure备份产品〔可选548.1DSGSnapAssure备份技术概述54选型原则54DSGSnapAssure概述54DSGSnapAssure特点558.2SnapAssure备份产品工作原理56数据抽取57数据压缩57备份数据的组织58备份数据的访问58恢复功能59对非归档日志模式的支持608.3SnapAssure的模块组成618.4SnapAssure支持的备份策略62SnapAssure支持的备份类型62备份策略的设计63恢复策略638.5SnapAssure对Oracle备份系统的特殊优势648.6SnapAssure的案例66SnapAssure在XX联通的应用：67SnapAssure在新疆电信IBSS系统中的集中备份应用67第三部项目实施及售后服务719项目实施规划729.1项目管理729.2实施策略规划739.3测试739.4生产系统实施749.5验收支持759.6验收方式759.7验收小组构成769.8验收工作流程图779.9培训78DSG—RealSync复制容灾系统培训78DSG—SnapAssure备份系统培训799.10知识转移809.11项目文档809.12项目小组8110项目的具体实施步骤8210.1容灾项目整体实施阶段概述8210.2数据复制软件本身实施步骤和周期8210.3容灾系统状态定义8210.4环境准备8310.5安装和配置概述8410.6初始化复制环境、进行初始数据同步84首次全同步分析84全同步实施步骤86时间估算8610.7开始实时复制8710.8灾难恢复8710.9数据一致性检查8710.10容灾中心的使用8811容灾演习、容灾切换和回切8911.1容灾演习8911.2切换的方式8911.3数据库的切换过程90数据库切换方式：90数据库切换的步骤9111.4应用服务器切换9211.5网络切换9211.6系统回切9411.7切换自动化管理工具9412容灾系统的维护和人员配置需求9512.1容灾管理规划9512.2复制软件的日常维护9512.3人员组织结构规划95容灾项目领导小组95容灾项目经理96系统专家96网络专家9613售后服务内容及承诺9713.1服务宗旨与策略9713.2服务体系9813.3技术服务流程9813.4行业战略级售后服务计划99工程实施阶段的服务99系统售后运行期间的服务内容10013.5服务联系方式10114附：容灾系统术语与定义10314.1灾难10314.2灾备站点10314.3恢复时间目标〔RTO与恢复点目标〔RPO10314.4业务持续计划〔BCP与灾难恢复计划〔DRP10314.5系统灾难级别定义10414.6灾难恢复过程10514.7灾难备份技术10614.8灾难备份中心10714.9RPO与RTO108第四部DSG公司简介及案例11015DSG公司简介11115.1DSG成立和组成11115.2DSG业务范围11115.3DSG核心技术11215.4DSG公司的业务方向11215.5DSG在国内的主要应用客户11316附：DSG在类似项目的成功范例和相关经验11416.1成功案例的列表11416.2成功案例的概况11516.3广西移动营业和客服数据库数据复制应急查询平台11816.4XX电信的计费查询平台应用12116.5XX地税11地市本地复制和数据集中上收和容灾应用12316.6长江证券集中交易系统灾备应用12516.7西北证券灾备一体化方案12816.8XX联通的复制应用13116.9XX联通业务复制应用13316.10XX网通数据复制应用案例13516.11上海松江财政容灾系统应用案例13816.12XX联通计费系统容灾及查询平台应用14116.13SnapAssure在新疆移动BOSS系统备份的应用14316.14容灾异构平台的经验14516.15性能指标占用参考145需求分析为什么要建容灾系统随着业务的飞速发展使其单位时间内的业务量、相关的资金密度不断提高,因此,业务的间断直接意味着经济上的损失；另一方面,提供高可靠性、高水准的客户服务也是保持良好形象的重要手段；随着IT系统建设的不断发展,我们在享受IT支撑系统带来的高效率、高服务的优势的同时,其业务运作也更加依赖于IT系统的稳定运行,其结果是,一旦发生IT系统停止运行,那么关键业务系统将受到严重影响,用户信息、征收记录等也随之丢失。随着应用系统的不断发展完善,信息化对工商系统的业务影响也越来越明显,为了更好地保护已有的数据资料,保证信息系统的正常运行,对一些关键业务的实时保护就变得异常重要,同时对关键数据的保护也变得十分重要。灾难恢复就是在这样的背景下提出的。本方案是根据***单位提出的容灾需求,所设计的方案。如有欠缺或遗漏之处,敬请谅解！容灾项目建设需要注意的几大问题为什么要建容灾系统随着业务的飞速发展使其单位时间内的业务量、相关的资金密度不断提高,因此,业务的间断直接意味着经济上的损失；另一方面,提供高可靠性、高水准的客户服务也是保持良好形象的重要手段；随着IT系统建设的不断发展,我们在享受IT支撑系统带来的高效率、高服务的优势的同时,其业务运作也更加依赖于IT系统的稳定运行,其结果是,一旦发生IT系统停止运行,那么关键业务系统将受到严重影响,用户信息、征收记录等也随之丢失。因此,小至一般性的硬件故障,大到区域性的自然灾害,从物理的设备不可用,到逻辑的人为失误和破坏,都可能造成整个信息系统的全面瘫痪,导致业务运营的停顿。灾难的定义也从过去的大面积自然灾害,转变为可造成IT系统应用不可用,产生的任何故障和灾害。如何才能保证尽量减少企业数据的丢失、将危险与灾难的损失降低到最小程度呢？这就需要建立容灾系统,包括数据容灾以及应用容灾。容灾系统的核心就在于使用各种技术和管理手段将灾难化解,在实践中主要表现为两个方面：一是保证企业数据的安全；二是保证业务的连续性。通过在工作站点和灾难恢复站点运行同样的系统,包括操作系统、基础数据库和应用软件,并通过数据复制完成数据复制。假如工作站点发生灾难,不能再继续工作,这时容灾中心会将业务数据及时恢复到备用服务器上,并自动将业务切换到备用服务器,然后实现业务的远程切换,恢复系统不间断的运行,在容灾中心实现应用级容灾,这个过程只需要很短的时间；在此基础上,在灾难过后,再将业务系统切换回正常的生产系统,实现业务的灾难恢复。因此,业务连续性和容灾建设的总体目标是：为关键业务系统提供风险预防机制和灾难恢复措施,在确保数据安全的基础上提高业务连续运行能力,降低企业运营风险,将业务损失降低到可接受的程度,提升管理和服务质量,增强企业竞争力。容灾不能替换备份1．容灾和备份的目的不同容灾系统的目的在于保证系统数据和服务的"在线性",即当系统发生故障时,仍然能够正常地向网络系统提供数据和服务,以使系统不致停顿。而备份技术的目的与此并不相同,备份是"将在线数据转移成离线数据的过程",其目的在于应付系统数据中的逻辑错误和历史数据保存。所以,在各种容错技术非常丰富的今天,备份系统仍然是不可替代的。2．备份是基石备份是指为防止系统出现操作失误或系统故障导致数据丢失,而将全系统或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。备份是数据高可用的最后一道防线,其目的是为了系统数据崩溃时能够恢复数据。3．容灾不可少那么建设了备份系统,是否就不需要容灾系统？这还要看业务部门对RTO〔恢复所需的时间指标/RPO〔能够恢复到的最新状态指标的期望值,如果允许1TB的数据库RTO＝8小时,RPO＝1天,那备份系统就能满足要求。同时,备份的目的在于应付系统数据中的逻辑错误和历史数据保存。只能够满足数据丢失、数据破坏时的数据恢复目的,而不能提供实时的业务接管功能。因此容灾系统对于某些关键业务而言也是必不可少的。人们谈及容灾往往是针对当生产系统,不能正常工作时,其业务可由容灾系统接替这些业务,继续进行正常的工作。能够提供很好的RTO和RPO指标。同时远程容灾系统具备应付各种灾难,特别是区域性与毁灭性灾难的能力,具备较为完善的数据保护与灾难恢复功能,保证灾难降临时数据的完整性及业务的连续性,并在最短时间内恢复业务系统的正常运行,将损失降到最小。4．容灾不能替换备份容灾系统会完整地把生产系统的任何变化复制到容灾端去,包括不想让它复制的工作,比如不小心把计费系统内的用户信息表删除了,同时容灾端的用户信息表也会被完整地删除。如果是同步容灾,那容灾端同时就删除了；如果是异步容灾,那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统中取出最新备份,来恢复被错误删除的信息。因此容灾系统的建设不能替代备份系统的建设。5．规划企业安全保障体系考虑的因素对于企业而言到底应该如何建设自己的灾备系统,是只建设备份系统、还是只建设容灾系统、还是需要二者同时建设、或者是分步骤的建设,谁先谁后等问题,主要根据业务的需求而定：〔1需要防范的灾难类型：企业信息系统可能遇到的灾难类型及其发生的比例如下：对于"人为错误"、"软件损坏和程序错误"加上"病毒"等这些都称为逻辑错误,占总故障的56%,这些错误只能通过备份系统才能防范；对于"硬件和系统故障"以及"自然灾难"等故障可以通过在容灾系统〔或者异地备份来防范,占总故障率的44%。〔2允许的RTO和RPO指标从技术上看,衡量容灾系统有两个主要指标：RPO〔RecoveryPointObject和RTO〔RecoveryTimeObject,其中RPO代表了当灾难发生时允许丢失的数据量；而RTO则代表了系统恢复的时间。一般而言：容灾系统能够提供较好的RTO和RPO指标。〔3系统投资总的说来,建设备份系统的投资远比建设标准意义的容灾系统的投资小得多：备份系统的投资规模一般在几百万；而最节省的一套容灾系统投资都将上千万；因为建设备份系统所需的资源在以下几个方面的投资都远远小于容灾系统：备份系统容灾系统传输链路TCP/IP网络带宽一般<1GBSAN网络独占光纤资源带宽要求10GB盘阵需求容量小只需要中档阵列容量大必需高端阵列系统维护成本几乎无需维护需建一个团队维护6．常用的灾备组合方式基于以上原因,业界在灾备系统的建设上一般按照以下几种方式：建设机房内的本地备份系统建设异地的备份系统该方式可以备份系统的价格满足备份和异地容灾功能,能够避免主生产中心由于地震、火灾或其他灾害造成的数据丢失备份系统＋异地容灾系统这是一个较为理想化的灾备一体化解决方案,能够在很大程度上避免各种可能的错误。容灾项目需要多大的投资？其实这个问题也可以被反问为：你希望容灾系统能达到什么效果？要想阐述清楚此问题,首先要明白两个指标：RTO和RPO。RTO,RecoverTimeObject,恢复时间指标〔业务接管时间,是指当灾难发生后,生产系统需要多长时间能够恢复生产,它是衡量企业在灾难发生后多长时间能重新开始运转的指标。RPO,RecoverPointObject,恢复点指标〔数据丢失量,是指灾难发生后,容灾系统能把数据恢复到灾难发生前的哪一个时间点的数据,它是衡量企业在灾难发生后会丢失多少生产数据的指标。理想状态下,我们希望RTO=0,RPO=0,即灾难发生对企业生产毫无影响,既不会导致生产停顿,也不会导致生产数据丢失。从当前计算机技术水平来说,我们可以为用户建设这种类型的容灾系统,其中最著名的例子当属VISA和Master的结算系统,由于这两个银行结算组织占据了全球银行结算业务的重要地位,他们的结算系统不允许发生任何停顿和数据丢失的情况,即使在"911"这种极端情况下。但实现这样的容灾系统的投资巨大,它结合了存储数据复制技术、服务器操作系统镜像技术、集群技术、数据库高可用性设计、应用系统高可用性设计、同步容灾技术、异步容灾技术、同城容灾方案、异地容灾方案,以及相应的管理流程和意外事件反映处理流程等详细的规章制度,和人员配备、行政保障手段〔通信、交通等,综合在一起完成一个完整的容灾方案〔实际是双生产中心或多生产中心方案,并没有单纯的容灾中心。但是这种方案的投资过于巨大,目前中国可能除了中国银联等这种特殊性质的企业外,不会有太多的企业会去实现这个系统。目前,在电信等企业的关键业务系统容灾项目建设中,投资规模为多少是合理的？如果业务部门能确认RTO/RPO指标,那技术部门选择了合适的容灾技术以及配套的管理流程就可以确定投资规模了。例如,如果业务部门确认,灾难发生后,3个小时内营业厅恢复生产就可以满足用户需求,且营业系统数据不能丢失,那RTO＝3小时,RPO＝0,那就必须选择基于存储平台数据复制技术的同步容灾方案；如果业务部门确认,灾难发生后,3天能恢复经营分析系统工作,且以前的数据丢失可以忽略不计,那RTO=3天,RPO无,那选择ATA磁盘实现异地备份,就能满足要求。容灾项目如何解决投资回收问题从系统安全性角度考虑,我们必须为关键的业务支撑系统建设最有效的灾难恢复解决方案。但是在大部分情况下,当未出现灾难时,我们的容灾端系统总是处于空闲状态,花费大量投资买来的系统根本无法有效利用。这个问题一直困扰着用户。为了百年不遇的灾难投入巨资建设一个容灾中心,容灾中心的设备在灾难发生前不能给企业带来效益,这是企业决策者很难接受的,因此如何合理分配投资,将容灾中心建设成为第二生产中心,与生产中心成为企业支持企业正常运行的双中心,并实现互为容灾,是降低总体拥有成本〔TCO,TotalCostofOwnership,提高投资回报率〔ROI,ReturnOfInvestment的一个重要措施,应该得到企业的高度重视。因此,我们建议在容灾系统建设中,需要考虑的第一个问题是如何保证容灾端的系统可以得到充分利用,使容灾端系统的数据实现共享,能够利用容灾系统提供的高性能主机资源、存储资源为企业带来更大的处理能力。目前建设容灾方案的原则都是"平战结合",容灾数据在平时能够方便的利用〔查询统计报表等业务分担、实验系统数据来源、数据仓库中数据抽取,突出容灾数据的价值,保证容灾系统建设的合理性。目前能支持容灾数据实时再利用的解决方案不是很多,如DSG的RealSync产品,目标系统的数据库一直处于打开状态,甚至在复制过程中。因此,RealSync技术除用于容灾外,还可以将不同的业务模块分布在源系统和容灾系统上,实现负载分担。因为RealSync的目标数据库在被实时更新时可以被访问,还可以被用于决策支持类应用。为决策分析和报表系统提供快速的数据抽取功能提供准实时脱机查询,提高查询效率为试验系统提供真实的生产数据将以上本来需要在主系统上运行的业务与生产系统完全隔离,充分利用容灾系统的资源,实现企业应用负载分担,减少对生产系统的影响,提高服务系统响应效率；从而将容灾系统这个成本中心转化为利润中心。容灾项目对生产系统性能的影响容灾系统的本质是将生产系统的数据以及这些数据的变化,完整地复制到容灾系统中,并通过相关技术手段,确保容灾系统中数据的完整性和一致性。容灾系统对生产数据和生产数据的变化的复制操作,必然需要与完成这些操作相对应的CPU资源〔存储的CPU、或服务器的CPU、内存资源〔存储的Cache、或服务器的RAM、网络资源〔TCP/IP、FC或FICON,如果这些资源不能独立分配给容灾系统〔实际上不可能独立,则必然会影响生产系统的性能。因此更准确的问题是,如何确保容灾系统上线后,在可以实现既定的RTO/RPO指标的同时,不会影响生产系统的正常运行？答案是可以通过技术手段实现的。要想实现,则必须对现有生产系统进行详细的性能分析,包括系统I/O特性〔IOPS,RespondTime,读写比,I/O块大小,I/O峰值、均值,时间特性等等、系统内各子系统业务特点、存储空间分配、服务器CPU和RAM资源的使用状况、SAN网络情况〔端口使用状况、Zoning划分状况、端口IOPS等、能够使用的数据复制链路〔FC、TCP/IP、ATM、E1/E3以及链路的QoS保障等。获得这些数据后,通过对容灾系统I/O分布的详细设计,将I/O均匀分布到更多的设备上,从而确保生产系统实现容灾后,不会造成性能下降影响正常生产的情况出现。选择什么容灾技术能保证项目实施成功？容灾项目实施成功,与技术关系不大。能举出成功案例的容灾技术,则必有它的可行性。但作为一个工程师,除了考虑项目的可行性外,还要考虑项目的不可行性。任何技术的实现,都有它的制约条件。在自己的生产环境中,能否避免这些制约条件的出现？或者出现后,是否有资源可以解决它？比如ORACLE在中国实施了一个基于DataGuard的容灾方案,但在实施过程中出现了大量意想不到的问题和BUG,作为对该特殊客户的重视,ORACLE甚至从国外派遣R&D人员到现场编制PATCH以保证项目能实施,但这种资源,是否每个客户都能向ORACLE索取？因此,选择一个简单的容灾方案,并选择一个曾经成功实施过该方案的工程团队,才是确保容灾项目实施成功的关键。容灾项目的建设原则"平战结合"变成本中心为利润中心容灾与其他任何保险策略一样,当没有灾难出现时,我们根本无法意识到容灾系统所起到的作用,无法回收容灾系统建设所需的大量投资。但从系统安全性角度考虑,我们又必须为关键的业务支撑系统建设最有效的灾难恢复解决方案。但是在大部分情况下,当未出现灾难时,我们的容灾端系统总是处于空闲状态,花费大量投资买来的系统根本无法有效利用。这个问题一直困扰着用户。因此,我们建议在容灾系统建设中,需要考虑的第一个问题是如何保证容灾端的系统可以得到充分利用,使容灾端系统的数据实现共享,能够利用容灾系统提供的高性能主机资源、存储资源为企业带来更大的处理能力。因为对于容灾系统而言还有一套整体的规划,未来的统一容灾系统对于数据的异地保护将起到非常关键的作用,将来的容灾系统无论在数据的实时性上,还是安全可靠性性上都会非常完善,只不过在业务的接管方面无法满足业务需求。因次本次建设容灾系统目的是提供一个能够快速接管的系统,能够充分利用投资的方案。为此我们强烈建议采用双active的结构,让容灾系统的数据库也处于OPEN状态,这样实际上关键系统就拥有了第二数据中心,而不仅仅是一个灾难备份系统,通过第二数据中心可以实现如下功能：核心业务的灾备平台通过数据同步建立的第二数据中心可以实现对业务关键数据的容灾及保护,在不影响生产数据库性能的同时为生产数据库在本地或异地建立一份准实时镜像,以保证在生产数据库发生灾难时可使用容灾数据库进行业务接管和数据恢复。业务负载分担这里要求第二数据中心的数据必需处于实时可读取状态,数据库必需处于OPEN状态,实现系统业务模块的重新部署。通过第二数据中心实现对核心系统的业务模块进行负载分担,将那些只对数据进行读取操作的模块都迁移到第二数据中心上来,主要包括：提供帐务和话单实时查询；提供统计报表运行；提供经营分析数据抽取；提供其他系统的数据访问接口；这样作将达到两个好处：提高数据访问的效率,提高外围系统部署的灵活性；提高核心系统的运行效率,提高核心系统运行的稳定和可靠性；容灾技术的推荐"DSGRealSync"我们建议采用DSGRealSync软件作为关键系统的数据备份方案。这个方案能够很好的解决灾备的难点：第一：网络带宽要求低：交易级复制软件需要在网络上传输的量为oracleredolog的1/3。一方面比oracleDG的带宽要求低,当然更远远低于磁盘阵列复制所需要的带宽。第二：可支持不同硬件环境之间的异构环境容灾,使得关键系统的集中容灾方案不仅能够满足多个IT系统的需求,同时更能满足用户IT系统的五花八门的硬件环境的需求。第三：容灾数据库更可靠：因为容灾数据库是OPEN状态的,所以不会存在容灾数据库无法启动的风险。同时这种方式可避免生产库上出现坏块等物理错误。第四：容灾数据库处于OPEN状态,可在容灾数据库上进行查询、统计报表等功能,实现业务负载分担。DSG从2002年在中国成立以来,在RealSync这个数据库复制产品的项目实施方面也经过了很长的一段路。DSG始终以"客户需求为导向"的原则发展自己的产品,到目前为止,DSGRealSync产品已经在电信、政府、政券和企业采用,主要包括〔详见方案后案例：DSG-RealSync数据同步复制容灾产品应用案例电信行业广西移动BOSS容灾及查询平台建设系统；北京移动告警数据同步、备份及容灾系统广西电信数据灾备中心应用XX电信BOSS数据复制应用XX电信计费系统数据复制应用XX网通支撑系统复制/查询统计平台项目XX联通大客户系统数据复制项目XX联通业务支撑系统数据复制应用XX联通计费系统容灾项目XX联通综合营帐数据复制XX联通BOSS系统数据复制/查询平台应用XX联通数据复制/查询平台应用XX电信Oracle数据异构复制迁移项目XX电信支撑系统容灾及备份应用XX电信支撑系统容灾及备份应用XX电信支撑系统容灾及备份应用……其他行业XX省地税数据集中及容灾系统；上海松江财政异地容灾XX财政异地容灾备份项目XX省交通厅征稽局征费系统"数据同步复制软件"容灾项目中国金融期货交易所异地容灾济钢Oracle-ERP数据同步复制项目XX神州通集团数据复制异地容灾应用长江证券数据集中的容灾应用华泰证券数据集中的容灾应用国联证券数据集中的容灾应用民族证券数据集中的容灾应用西南证券数据集中的容灾应用XX证券数据集中的容灾应用金通证券数据集中的容灾应用中原证券数据集中的容灾应用西南证券数据集中的容灾应用XX证券异地容灾项目银河证券数据容灾备份综合管理应用西部证券数据容灾备份一体化综合管理应用…………DSG-SnapAssure高速备份产品应用案例电信行业中国电信总部结算中心备份系统中国联通总部CRM备份系统中国电信全国九省结算中心备份系统〔XX、XX、广西、XX、XX、新疆、XX、XX、XX北方电信九省结算系统备份〔XX、XX、XX、XX、XX、XX、XX、天津、XX信息产业部全国十省互连互通和网间结算备份系统〔含XX、XX、XX、XX、XX、XX、XX、XX、XX和XX信产厅XX移动BOSS系统异地备份系统XX移动BOSS系统集中备份XX移动BOSS灾备系统新疆移动结算系统灾备项目天津联通固网计费备份系统XX联通综合结算备份系统；XX联通全省数据库集中备份XX联通业务支撑系统集中备份XX联通数据备份系统升级应用XX联通业务支撑系统的集中备份XX联通业务支撑系统的集中备份XX、XX、XX联通支撑系统的集中备份新疆电信BSS/OSS系统备份项目XX电信数据集中备份系统XX电信业务支撑系统集中备份XX通信、XX通信计费系统备份项目……其他行业银河证券全国数据中心集中备份系统XX社保数据备份项目广西公安备份系统XX公安备份及查询应用项目XX公安户籍系统备份应用新疆电力数据备份系统XX电力数据备份系统江汉油田数据备份系统……DSGRealSync数据库复制产品的特点DSGRealSync产品通过在逻辑级,通过传输和运行数据库事务〔Transaction,来提供实时数据复制功能,支持对生产系统数据库生成多个副本,用以作为灾难备份、和信息系统优化部署应用。RealSync对ORACLE的日志进行监控,发现改变的块及时对目标数据库进行更新,当应用系统向数据库中进行任何操作时时,这些信息都将在在线日志中存储,RealSync通过对实时获取的数据库在线日志进行分析,获得本次操作的交易指令和交易数据,然后将这些交易指令和交易数据经过格式转化并实时压缩后通过网络传送到目标系统。目标系统的RealSync代理接收数据库包,经过校验码检查,确认正确的数据库包后,将包解压进行格式转化后按照交易的先后顺序在容灾系统中重新执行该交易。〔1Transaction-Based的复制机制：该产品的实现不是通过数据库底层存储复制、也不是将生产系统的Log复制到目标系统上重新应用的模式。而是在源系统上通过Log分析出系统的交易指令〔Transaction,然后将交易指令在目标端装载的原理实现的。因此,目标端的数据库必须处于Open状态,并且两端的操作系统、数据库平台等都可以属于不同版本。〔2快速的TransactionLoad技术：基于主机的复制软件最大的问题在于性能是否满足大容量业务需求,如果复制软件在采用标准的SQL语句进行复制的话,势必要求目标系统与源系统具有相同的处理性能,从而导致投资成本大幅度上升。DSGRealSync独创DXF〔DSGExtendFormat数据表达格式,通过应用该格式实现数据的传输和装载能够达到数据库装载速度的极限,满足大容量应用系统的性能需求。该产品在支持作为灾难备份时具有如下特点：异构的系统平台,开放的硬件选择：RealSync技术在逻辑级的数据复制技术,因此对于生产系统和容灾系统来说,其硬件平台可以属于不同的厂商、不同的型号,可采用不同的操作系统等。零时间数据库切换的热容灾：系统恢复时间是指当主系统出现故障不能在短期内恢复,而需要启动容灾端系统时,容灾端系统启动的时间。该时间不仅仅是指容灾端的硬件系统启动,更主要的、也是更耗费时间的是容灾端数据库系统的启动、业务系统的启动和外部接口的切换等。其中又以数据库的启动最为耗费时间,因为容灾端数据库不属于正常下线,因此重起时需要作许多检查和恢复,花费的时间非常长。RealSync维护的容灾数据库系统在数据复制过程中也始终处于打开状态,保证数据复制在逻辑上的完整性,RealSync技术为源系统提供了永远可用的后备数据库系统。在源系统出现故障时,应用系统可实现实时访问备用数据库系统。达到数据库系统的零切换目的。可靠的数据复制技术：RealSync维护的容灾数据库系统始终处于打开状态,保证数据复制在逻辑上的完整性和可靠性,保证容灾站点数据库系统可用的系统。投资回报分析〔ROI：容灾系统始终处于打开状态,可提供数据抽取、报表系统、试验系统等实现数据共享,为信息系统提供更多的可利用资源。支持从高到中低端应用需求：由于RealSync在建设容灾系统时,对服务器、存储阵列和传输带宽要求都无特殊要求,而不同于传统容灾技术要求高端磁盘阵列、高端服务器、数GB的传输带宽,所以该系统适应于高端的电信、金融客户、也适合中端的政府机构、大型企业、同时也适合于运行PC平台的中小型企业应用。该产品在支持作为系统优化部署应用时具有如下特点：按需复制查询和统计系统往往不需要所有的原始数据,因此完全可以按需要复制数据。RealSync系统支持对指定信息的按需复制,如指定需要复制的表、字段和条件等,减少存储和网络带宽的成本。实时数据更新实时更新保证副本系统快速反映源系统的变化,提供账单查询、话单查询等的及时性。经过大量的测试,实时数据复制技术使源系统和目的系统的数据延迟<10秒。对生产系统的低干扰性DSG实时数据复制技术不需要通过任何数据库的引擎来获取变更数据,而是通过数据库自身的信息获取源系统上的改变并传送给目的系统,不会对生产系统造成性能影响。系统异构,可提供更多的优化空间源数据库系统和目的数据库系统的可异构,主要包括索引规则和存储参数〔如数据块大小、回滚段等。因此可以在目标数据库上根据业务特点进行调整和优化,完全不受源系统的限制。容灾技术对比和分析容灾产品概述在选择容灾系统的构造时,首先要考虑的就是选择采用合理的异地数据复制技术。数据的远程复制技术是容灾系统的核心技术,它对于数据系统的一致性和可靠性以及系统的应变能力具有举足轻重的作用,通过有效的数据复制,远程的业务数据中心与本地的业务数据实现同步,确保一旦本地系统故障,远程的容灾中心迅速进行完整的接管。一般说,在容灾系统方案的数据复制技术上存在两种主流模式：第一种方式是基于智能存储的数据镜像技术。该技术是将数据复制通过磁盘阵列控制器在进行写入操作的同时通过高速网络向容灾系统的阵列上发送相同的I/O指令来实现,因此该方案对主机的资源占用很小；稳定性好；同步性强。该技术主要由各存储设备生产厂家所推荐,如EMC,IBM,HP等都提供了相应的解决方案。第二种方式是基于主机系统的数据复制,该方式是把数据定期、在线地复制到目的地的机器上去。这种方案大部分由存储管理软件厂家提供,尤其是VERITAS推出了一系列基于该方案的存储管理软件解决方案。实现这些功能的业界常用解决方案主要包括以下几类：磁盘阵列复制技术：主要由一些磁盘阵列厂商提供,如EMCSRDF、IBMPPRC、HPBusinessCopy、HDSTrueCopy等；存储卷复制技术：由一些卷管理软件厂商提供,如VERITASVVR；数据库复制技术：由数据库厂商以及一些第三方厂商提供,如DSGRealSync/SmartE等；应用层复制技术：由各系统的应用厂商自己提供；DSGRealSync属于数据库复制技术。因此下面就该技术与其他几类复制技术的优缺点作一个归纳：基于异地备份技术实现容灾的分析基于数据备份方式,通过磁带数据传输是最早使用的容灾方式,尽管现在有很多新技术出现,该容灾方式仍在使用。备份类厂商VeritasNetbackupLegatoNetworkerIBMTSMDSGSnapassure基于数据备份技术的容灾使用此方式的优点是：成本较低,简单可行容灾端可以异构存储如是文件系统应用,容灾端可以异构主机平台此方式的缺点是：实时性差,发生问题,数据丢失量大磁带不可靠磁带恢复慢,RTO长数据库应用通常不能跨平台。基于应用层容灾技术的分析应用层复制技术DSGRealSync/SmartE适合对象：只适合那些在应用中提供了该技术的应用,而非常少。优点：与应用集成紧密,可按照应用的需求作调整。从理论上讲能够解决所有的应用需求缺点：非标准化：不同应用软件的复制方式不同；开发和维护工作量大,任何应用的变动都可能导致复制技术的变动；应用不成熟、不普遍。无法实现大量应用案例之间的知识共享。适合对象：适合于构建在ORACLE系统上的所有应用系统和应用类型优点：无需二次开发；标准的工业化软件,成熟度远远高于应用复制；专业厂商支持和维护；应用案例远多于应用层复制技术；缺点：与应用的关系比较松散,无法完全按照应用需求定制基于磁盘阵列复制容灾技术的分析采用基于存储的容灾方案的技术核心是利用存储阵列自身的盘阵对盘阵的数据块复制技术实现对生产数据的远程拷贝,从而实现生产数据的灾难保护。在主数据中心发生灾难时,可以利用灾备中心的数据在灾备中心建立运营支撑环境,为业务继续运营提供IT支持。同时,也可以利用灾备中心的数据恢复主数据中心的业务系统,从而能够让企业的业务运营快速回复到灾难发生前的正常运营状态。采用基于存储的数据复制技术建设容灾系统是目前金融、电信采用较多的容灾方案,有较多的应用案例。采用基于存储数据复制技术建设容灾方案的必要前提是：缺点通常必须采用同一厂家的存储平台,通常也必须是同一系列的存储产品,给用户的存储平台选择带来一定的限制。容灾中心的主机平台也需要和生产中心为相同类型。采用同步方式可能对生产系统性能产生影响,而且对通信链路要求较高,有距离限制,通常在近距离范围内实现〔同城容灾或园区容灾方案采用异步方式与其他种类的异步容灾方案一样,存在数据丢失的风险,通常在远距离通信链路带宽有限的情况下实施。如果容灾数据需要使用,可以为"目标数据"建立一个BCV卷,需要多投入一倍的存储空间,即整个架构需要生产系统的4倍存储容量才可支撑,且获得的数据不是实时的,一般都是隔天。磁盘阵列复制技术DSGRealSync适合对象：主要适用于数据中心级的海量数据复制。用户必需采用支持该功能的磁盘阵列型号,而这些阵列大都为高端阵列,投资昂贵。优点：支持阵列上的所有数据类型复制。可支持同步方式复制不占用主机CPU资源缺点：目标端数据不可用：目标端数据库在复制过程中不能被打开,造成大量投资浪费；必需同构：源和目标必需要求相同的磁盘阵列、相同的操作系统、相同的数据库版本；只能全库复制：复制的对象是整个数据库不能实现数据整合和数据分发；带宽高：要求独占的光纤网络,动辄需要上GB的带宽。适合对象：适合从工作组级、企业级到数据中心级的复制需求。无论系统采用什么样的服务器平台、什么样的存储平台,只要是ORACLE系统之间的复制即可适用。优点：目标端数据可用：目标端数据库在复制过程中出于可用状态,可用作数据查询、报表、数据抽取等任务分担；异构系统复制：源端系统和目标端系统可以采用异构的操作系统平台、存储平台；支持选择性复制：支持只复制指定的user、指定的Table、指定的行和列。节省存储空间,提高应用灵活性；支持1对多,多对1的复制结构：能够将多个数据库中的数据复制到一个数据库中；能够将一个数据库中的不同数据分发到不同的数据库中。节约带宽和网络资源：所需带宽一般在几Mbps,几十Mbps。缺点：只支持ORACLE数据库系统。只支持异步复制,不支持同步方式。只支持ORACLE系统中的DML复制和常用的DDL复制,对存储的变化不复制。占用主机的CPU资源；基于存储卷复制容灾技术的分析采用基于主机系统的容灾方式的核心是利用主、备中心主机系统通过IP网络建立数据传输通道,通过主机数据管理软件实现数据的远程复制,当主数据中心的数据遭到破坏时,可以随时从备份中心恢复应用或从备份中心恢复数据,从而给企业提供了应用系统容灾的能力。实现远程数据复制的数据管理软件有很多产品,主机厂商和一些第三方软件公司<如Veritas>提供基于主机的数据复制方案,如Sun公司的AvailabilitySuite软件和VeritasVolumeReplicator<VVR>等软件可实现基于主机的远程数据复制,从而构建基于主机的容灾系统。采用基于主机的数据复制技术建设容灾方案有以下优点：基于主机的方案最主要的优点是只对服务器平台和主机软件有要求,完全不依赖于底层存储平台,生产数据中心和后备数据中心可以采用不同的存储平台；既有针对数据库的容灾保护方案,也有针对文件系统的容灾保护方案。有很多不同的基于主机的方案,可以满足用户的不同数据保护要求,提供多种不同数据保护模式；基于IP网络,没有距离限制同时,采用主机的数据复制技术建设容灾方案有以下缺点：基于主机的方案通常需要同种主机平台；基于主机的数据复制方案由于生产主机既要处理生产请求,又要处理远程数据复制,必须消耗生产主机的计算资源,因而对生产主机性能产生较大的影响,甚至是产生严重影响；灾备中心的数据一般不可用,如果用户需要在远程数据中心使用生产数据给开发测试、DW/BI应用使用将非常困难；利用主机数据复制软件的方案比较复杂,尤其是和数据库应用结合的时候需要很复杂的机制或多种软件的结合,从而对生产系统的稳定性、可靠性、性能带来显著影响；如果有多个系统、多种应用需要灾难保护,采用基于主机的方案将无法有统一的技术方案来实现。管理复杂,需要大量的人工干预过程,容易发生错误。目前,企业采用基于主机的数据复制技术建设容灾方案相对比较少,通常适合单一应用或系统在I/O规模不大的情况下局部使用。在应用I/O负载比较大,需要灾难保护的应用及应用类型比较多的时候,基于主机方案将不适用。VeritasvvrDSGRealSync/SmartE适合对象：主要适用于工作组级的数据复制。因为对CPU资源占用高优点：支持存储卷上的所有数据类型复制。可支持同步方式复制缺点：目标端数据不可用：目标端数据库在复制过程中不能被打开,造成大量投资浪费；操作系统必需同构：源和目标必需要求相同的操作系统和相同的数据库版本,但不要求相同的存储设备只能全库复制：复制的对象是整个数据库不能实现数据整合和数据分发；带宽高：传输数据量比DSGRealSync/SmartE高5倍以上。适合对象：适合从工作组级、企业级到数据中心级的复制需求。无论系统采用什么样的服务器平台、什么样的存储平台,只要是ORACLE系统之间的复制即可适用。优点：目标端数据可用：目标端数据库在复制过程中出于可用状态,可用作数据查询、报表、数据抽取等任务分担；异构系统复制：源端系统和目标端系统可以采用异构的操作系统平台、存储平台；支持选择性复制：支持只复制指定的user、指定的Table、指定的行和列。节省存储空间,提高应用灵活性；支持1对多,多对1的复制结构：能够将多个数据库中的数据复制到一个数据库中；能够将一个数据库中的不同数据分发到不同的数据库中。节约带宽和网络资源：所需带宽一般在几Mbps,几十Mbps。缺点：只支持ORACLE数据库系统。只支持异步复制,不支持同步方式。只支持ORACLE系统中的DML复制和常用的DDL复制,对存储的变化不复制。占用主机的CPU资源；基于虚拟化存储技术的分析存储虚拟化的技术方法,是将系统中各种异构的存储设备映射为一个单一的存储资源,对用户完全透明,达到屏蔽存储设备的异构和主机的异构的目的。通过虚拟化技术,用户可以利用已有的硬件资源,把SAN内部的各种异构的存储资源统一成对用户来说是单一视图的存储资源〔StoragePool,而且采用Striping、LUNMasking、Zoning等技术,用户可以根据自己的需求对这个大的存储池进行方便的分割、分配,保护了用户的已有投资,减少了总体拥有成本〔TCO。另外也可以根据业务的需要,实现存储池对服务器的动态而透明的增长与缩减。通过存储虚拟化技术可实现数据的远程复制,以确保容灾中心与主站点的数据保持同步以实现数据容灾。目前各存储厂商分别有不同的存储虚拟化技术<如EMCStorageRouter和RecoverPoint,IBMSanVolumeController,HDSTagmaStor存储平台提供的UniversalReplicator,SVM技术都是虚拟化技术>,利用各厂家的存储虚拟化技术能够实现异构存储平台之间的数据复制〔同步或异步方式。存储虚拟化技术可以在不同层面实现,如在智能交换机层面、存储层面或增加第三方设备来实现。采用虚拟存储技术进行数据复制同样也可以有同步复制方案和异步复制方案,需要根据具体的需求选择合适的产品。采用虚拟存储化技术建设容灾方案有以下优点：主生产中心和容灾中心的存储阵列可以是不同厂家的产品,存储平台选择不受现有存储平台厂商的厂商限制〔但主机必须是同种平台。对不同厂家的存储阵列提供统一的管理界面。在虚拟存储环境下,无论后端物理存储是什么设备,服务器及其应用系统看到的都是其熟悉的存储设备的逻辑镜像。即便物理存储发生变化,这种逻辑镜像也永远不变,系统管理员不必再关心后端存储,只需专注于管理存储空间,所有的存储管理操作,如系统升级、建立和分配虚拟磁盘、改变RAID级别、扩充存储空间等比从前的任何产品都容易,存储管理变得轻松简单。采用虚拟存储化技术建设容灾方案需要考虑以下缺点：虚拟存储技术比较新,虽然为异构环境设计,但在异构环境种保证兼容性和数据的完整性依然可能存在风险；采用虚拟存储技术,尤其是增加第三方硬件的方式将需要评估对整个系统的高可用性和性能的影响。需要验证选择的产品和技术的成熟性以及和现有设备、未来设备的兼容性能力,尤其是需要在复杂环境、大规模容灾要求重的实际适用情况。在当前阶段,建议暂不在关键业务系统的容灾上选择虚拟化存储技术,该技术还有待时间和实际应用的验证,尚无法胜任核心、关键业务系统的容灾保护。基于OracleDataGuard容灾技术的分析OracleDataGuard技术是Oracle数据库系统特有的灾难备份和恢复技术,利用了Oracle数据库系统的日志备份和恢复机制。DataGuard的基本原理是在与主系统完全一致的硬件和操作系统平台上建立后备数据库系统,同时对主数据库的数据库日志<Log>和控制文件等关键文件进行备份。在主系统正常工作的同时将主系统产生归档日志文件<ArchivedLog>不断的传送到后备数据库系统,并且利用这些日志文件在后备数据库系统上连续进行恢复<Recover>操作,以保持后备系统与运行系统的一致。当主系统发生故障时,使用备份的数据库日志文件在后备数据库上恢复主数据库内的数据。图表13采用OracleDataGuard的容灾方案OracleDataGuard提供了三种模式：最大保护模式最大可用模式最大性能模式OracleDataGuard最大保护模式提供了对于主数据库最高级别的数据可用度,是一种保证零数据丢失的容灾解决方案。当运行最大保护模式时,Redo纪录以同步的方式从主数据库发送到后备数据库,而且,在主数据库方的事务,一定要等到至少有一个后备数据库确认接收到事务数据,该事务才被提交。在这种模式下,一般配置至少两个后备数据库,以提供双重容错保护。如果后备数据库不可用,则主数据库方会自动挂起处理进程。最大可用性模式提供了对于主数据库次高级别的数据可用度,保证零数据丢失,并对单个组件的失败提供保护。与最大保护模式一样,redo数据被同步地从主数据库发送到后备数据库。在主数据库方的事务,一定要等到后备数据库确认接收事务数据,该事务才被提交。然而,如果后备数据库因为诸如网络连接之类的问题而不可用时,主数据库方的处理会继续执行。这样,会出现后备数据库暂时与主数据库不一致的情况,但是一旦后备数据库恢复可用,数据库会自动同步,不会有数据丢失。最大性能模式是缺省的保护模式。与最大可用性模式相比,它对于主数据库提供稍弱一点的保护,但是性能更高。在这种模式下,当主数据库对事务进行处理时,日志数据被以异步的方式传送到后备数据库。在主数据库方,提交操作在完成写的动作前、无需等待后备数据库的接收确认。在任何时候,如果后备方不可用,主数据库方的处理继续执行,这样对性能不会有什么影响。采用OracleDataGuard技术进行灾难备份需要满足以下前提条件：后备系统与主系统的硬件平台、操作系统、操作系统版本等保持一致；后备系统与主系统上Oracle用户的权限一致；后备系统与主系统的Oracle数据库版本一致；后备系统与主系统的Oracle数据库配置文件一致。采用OracleDataGuard建设容灾方案有以下优点：完全通过Oracle数据库机制来实现,完全不依赖于其它软件和底层存储平台；可以满足用户的不同性能、数据保护要求,提供多种不同数据保护模式；可以实现一对多的数据复制,提供多重保护；后备数据库可以在很短的时间内提升到生产状态〔因为数据库已经在运行基于IP网络,没有距离限制同时,采用OracleDataGuard建设容灾方案有以下缺点：OracleDataGuard的三种模式都将对生产数据库系统的性能产生影响,因而需要更多的处理资源；后备数据库不可用,如果用户需要在远程数据中心使用生产数据给开发测试、DW/BI应用使用将非常困难。只能对Oracle数据库数据提供保护,不能对其它应用数据—如文件应用等提供灾难保护。管理复杂,需要大量的人工干预过程,容易发生错误。只能保护Oracle数据库,无法保护其他应用数据。业界其它基于应用的容灾方案的优点和局限性与OracleDataGuard模式基本相同。ORACLEDGDSGRealSync适合对象：主要适用于几十GB的小型数据库的容灾使用。优点：Free可实现同步复制模式。缺点：目标端数据不可用：目标端数据库在复制过程中处于RECOVER状态,不能被用来使用；操作系统必需同构：源和目标必需要求相同的操作系统和相同的数据库版本；只能全库复制：复制的对象是整个数据库不能实现数据整合和数据分发；性能低下,目前的应用案例多在几十GB的小型数据库上使用。重新同步一次非常复杂,需要通过备份恢复的方式来进行首次初始化,并且最好很死停止业务。logicalstandby模式的性能低下logicalstandby方式支持的数据类型有限,例如对longraw,rowid等数据类型不支持。适合对象：适合从工作组级、企业级到数据中心级的复制需求。无论系统采用什么样的服务器平台、什么样的存储平台,只要是ORACLE系统之间的复制即可适用。优点：目标端数据可用：目标端数据库在复制过程中出于可用状态,可用作数据查询、报表、数据抽取等任务分担；异构系统复制：源端系统和目标端系统可以采用异构的操作系统平台、存储平台；支持选择性复制：支持只复制指定的user、指定的Table、指定的行和列。节省存储空间,提高应用灵活性；支持1对多,多对1的复制结构：能够将多个数据库中的数据复制到一个数据库中；能够将一个数据库中的不同数据分发到不同的数据库中。节约带宽和网络资源：所需带宽一般在几Mbps,几十Mbps。性能高于ORACLEDG,DSGRealSync软件已经应用于广西移动的营帐系统的环境,数据容量达到2TB,每天产生的日志量最大能够处理到600GB/天缺点：需要单独购买只支持异步复制,不支持同步方式。DSGRealsync容灾技术的分析DSG是全球领先的数据与存储管理软件提供商,提供优秀的数据管理软件和数据备份、灾难恢复、数据抽取共享、数据归档检索和一体化管理平台在内的解决方案。DSG公司拥有对Oracle数据库复制的核心技术掌握,其推出的复制产品家族RealSync是通过对OracleLog日志进行分析获取跟踪源系统的交易指令。该软件成功应用在长江证券、华泰证券、国联证券、金通证券、民族证券、银河证券、XX地税、XX电信、XX联通、XX联通、XX联通、XX联通、XX联通、XX联通、广西移动、XX网通、上海松江财政、XX钢铁集团公司…等单位的关键业务系统上该软件在生产系统上的每个oracle系统和dc系统上安装一个agent,该agent通过对oraclelog的分析抽取实时增量数据,并将这些增量数据传送到灾备中心上。灾备中心的每个服务器上也需要安装agent,用于接收从生产中心传输来的交易指令,并将这些交易指令装载到灾备中心的数据库上复制系统包括两个部分组成：－DS:DataSource端,即源系统端；－DT：DataTarget端,即目标系统端。〔1源端和目标端各安装一套DSG的realsync软件,只要进行一些简单的配置就可以完成从首次初始化到实时增量同步的整个过程,并且实现无需停掉生产系统业务而完成整个实时数据复制容灾功能。〔2DSGReal实时分析oracle的OnlineRedoLog生成压缩的xf1文件自动发送到目标端等待装载。〔3通过的定制filter功能,来根据用户需要不复制一些危险的DDL操作比如droptabletruncatetable。〔4目标系统收到xf1指令后保存到目标系统的缓存队列,由于RealSync只分析onlineredolog中的有用信息,所以一般需要传输的xf1文件只是oracleredolog的1/5,这样大大降低了网络的负载,从而更好的减少了数据延迟。〔5目标系统的loader进程从本地队列中读取数据装载到目标端oracle系统上,装载过程中通过DSG独有Rowmapping技术进行数据一致性的检测,从而部分保证生产端和容灾端数据的一致性。〔6整个延迟在OracleRAC模式下正常情况下为3－5秒中,最长延迟不超过10秒,即RPO<10。〔7目标端数据库处于实时打开状态,如果源端出现灾难,整个RTO时间只是应用准备的时间。而且在没有接管生产系统业务的情况下容灾端数据库不仅可以用来容灾还可以用来将OLTP应用、报表和查询应用分离；提高每个系统效率,降低资源争用和消耗,从而更有效的利用现有设备。〔8整个分析、传输、装载过程全程监控,如果出现错误及时提示用户,方便用户及时发现问题解决问题。正因为该技术原因,DSGRealsync在满足容灾系统的过程中具有如下几个优势：异构环境支持RealSync技术是逻辑级的数据复制技术,因此对于生产系统和容灾系统来说,其硬件平台可以属于不同的厂商、不同的型号,可采用不同的操作系统等。它的优点在于：一方面为用户提供容灾系统建设时,硬件平台的可灵活选择空间；同时提供了在同一容灾解决方案架构下,实现企业不同平台上的多个信息系统的统一容灾支持。容灾数据库处于OPEN状态,提供及时、可靠的容灾切换RealSync维护的容灾数据库在数据复制过程中始终处于打开状态,为保证灾难切换的时效性和可靠性：打开的备份数据库保证数据复制在逻辑上的完整性,为源系统提供了永远可用的后备数据库系统,确保容灾系统的可靠性。当源系统出现故障时,应用系统可实现实时访问备用数据库系统,无需重新启动备用数据库,达到数据库的秒级切换目的。容灾数据库可提供实时数据共享,支持企业应用负载分担和投资回收采用RealSync容灾技术,容灾数据库始终处于打开状态,不同于其他模式下容灾数据库系统不可用的状态。因此,可以通过RealSync维护的容灾系统,提供数据共享服务：为决策分析和报表系统提供快速的数据抽取功能提供准实时脱机查询,提高查询效率为试验系统提供真实的生产数据将以上本来需要在主系统上运行的业务与生产系统完全隔离,充分利用容灾系统的资源,实现企业应用负载分担,减少对生产系统的影响,提高服务系统响应效率；从而将容灾系统这个成本中心转化为利润中心。灵活的组网结构和低带宽资源需求RealSync采用交易〔Transaction传输方式,极大的减少了复制过程中需要传输的数据量。使得在网络上传输的数据量大大减少,要求更低的网络带宽。Realsync支持标准的TCP/IP网络传输,用户可灵活布建容灾网络架构。系统可支持1:1、N:1、1:N和双向容灾结构支持,提高企业容灾结构的灵活性。整体方案设计方案设计<案例：西部证券>需求分析西北某证券集中交易系统在2005年实现交易集中并升级到Unix+Oracle平台,系统稳定运行。2006年以来,随着中国股市转牛,交易活跃,系统所承受的压力越来越大。一旦集中交易系统出现故障,将导致严重的后果。因此,西北某证券考虑升级以往的应用级容灾系统,采用专业的灾备软件对集中交易系统进行完善的保护,包括:实现灾、备一体化的数据保护对集中交易系统实现灾、备一体化保护,即在出现地震、火灾、存储故障、大面积电力中断、网络中断等情况下使用容灾系统实现业务快速接管；在出现诸如表数据丢失、数据逻辑错误、软件BUG等情况下可以通过备份系统快速在线修复系统。同时整合两种灾备模式,做到全方位保护。实现本、异地结合,查询、容灾结合的数据同步在中心机房和异地机房之间各保留一份同步数据。中心机房的同步数据用于历史查询、数据分析等,作为"温备"数据。异地同步数据用于容灾切换,作为"灾备"数据。强调应急处理及演习体制的建设,实现灾备制度保证在关键时刻容灾切换是否能够成功,不但取决于灾备软件,而且和平时的灾备演练、系统维护以及应急体制息息相关。因此,西北某证券要求灾备系统的建设同时应建设应急处理制度、演习制度并形成规范文档和应急指导手册,切实提高容灾系统的应用效果。DSG灾备一体化产品线DSG公司针对业界的数据保护需求,推出了两类数据保护产品：实时备份<realsync>和定时备份<snapAssure>。实时备份产品<realsync>：该产品是通过交易实时同步的方式实现数据备份。其目的是保护证券系统的业务连续性,当生产系统出现因为硬件故障、数据库故障、以及环境故障等而不能正常提供服务时,可在备份系统上快速接管。确保业务的连续性。定时备份产品<snapassure>：该产品是每天进行一次数据备份〔日常作归档日志的备份。其目的是保护证券系统的数据安全性。当生产系统出现因为人为误操作,应用程序错误、或者其他故障导致数据丢失时,可从备份系统上找回这些数据。而且可以找回一段时间以前的数据。Snapassure与Realsync的关系snapassure与realsync都是将生产系统的数据备份到备份系统上来,表面上看二者都是实现数据的备份和恢复,但在实质上二者有着本质的差别,主要差别在于：realsync目的在于保证系统的可用性：当生产系统发生故障时,可在短时间内〔分钟级通过备份系统对外提供业务服务,以使交易不致停顿。snapassure的目的在于对数据的保护：当生产系统发生数据损坏时,可以通过备份系统上的数据进行恢复。备份数系统上保存了多个备份时间点的多个版本,当生产系统的数据被破坏时,可通过备份系统的数据将系统回溯到错误发生之前的时刻。该技术能够应付交易数据库中的逻辑错误〔比如误删除表,表记录改错了等。所以,虽然我们可以采用realsync软件来达到实时备份的目的,当生产系统不能对外提供业务的时候,能够在备份系统上快速的接管业务。但是snapassure仍然是不可替代的：realsync无法解决生产系统的带病运行情况：例如realsync无法避免truncatetable,droptable以及错误导入数据等逻辑错误,realsync无法识别这些错误是正常操作还是错误操作,当生产系统的数据被破坏后,备份系统上的数据也是被破坏的。snapassure却能够避免这些数据的错误,保护数据不被破坏。当生产数据被破坏时,我们可以通过snapassure系统的多个时间点的备份数据来将系统回溯到发生错误之前的状态。因此,业界都将realsync和snapassure两种技术配合使用,以达到系统保护和数据保护的双重目的。在证券集中交易系统中,已经有几个证券公司采用snapassure和realsync并存的方式来达到最佳的保护效果。因此我们建议在条件允许的情况下,尽量能采用两种技术相结合的数据保护方式。容灾技术的推荐我们建议采用DSGRealSync软件作为关键系统的数据备份方案。这个方案能够很好的解决灾备的难点：第一：网络带宽要求低：交易级复制软件需要在网络上传输的量为oracleredolog的1/3。一方面比oracleDG的带宽要求低,当然更远远低于磁盘阵列复制所需要的带宽。第二：可支持不同硬件环境之间的异构环境容灾,使得关键系统的集中容灾方案不仅能够满足多个IT系统的需求,同时更能满足用户IT系统的五花八门的硬件环境的需求。第三：容灾数据库更可靠：因为容灾数据库是OPEN状态的,所以不会存在容灾数据库无法启动的风险。同时这种方式可避免生产库上出现坏块等物理错误。第四：容灾数据库处于OPEN状态,可在容灾数据库上进行查询、统计报表等功能,实现业务负载分担。系统结构目前集中交易系统由两台UNIX服务器组成OracleRAC结构。数据量为200GB左右,每天产生的ArchiveLog量约在30G左右。DSG公司针对证券业界的数据保护需求,推出了两类数据保护产品：容灾产品<RealSync>和备份产品<SnapAssure>。容灾产品<RealSync>：该产品是通过交易实时同步的方式实现数据备份,其目的是保护证券系统的业务连续性。当生产系统出现硬件故障、数据库故障、以及环境故障等而不能正常提供服务时,可在备份系统上快速接管,以确保业务的连续性。备份产品<SnapAssure>：该产品是每天进行一次数据备份〔日常作归档日志的备份,其目的是保护证券系统的数据安全性。当生产系统出现因人为误操作、应用程序错误、或者其他故障导致数据丢失时,可从备份系统上找回这些数据,而且可以找回一段时间以前的数据。在西部证券公司,实现了SnapAssure+RealSync的一体化系统保护架构：实时复制软件realsync配置为了实现该本地和异地的实时备份架构,我们采用DSGRealSync用于数据复制软件。该软件在集中交易的一个服务器上安装两个realsyncagent:一个realsyncagent用于用于同步到本地的服务器上；另一个realsyncagent同步到远程的备份服务器上。在本地实时备份服务器上安装一个realsyncagent；同时在异地备份服务器上安装一个realsyncagent。定时备份软件snapassure配置为了实现该本地定时备份功能,我们采用DSGsnapassure用于数据复制软件。该软件在集中交易的一个服务器上安装snapassureagent。在本地的pc服务器上安装snapassureserver；snapassureagent每天将备份的数据传给给server,经过压缩后保存到本地备份磁盘阵列上。功能实现采用DSGSnapAssure＋RealSync灾备一体化的模式,系统建设了本地备份系统、本地容灾查询平台系统和异地容灾系统三个部分。本地容灾查询平台系统采用DSGRealSync实时复制技术将交易系统的数据实时同步到本地容灾系统上。本地服务器上的数据延迟一般可控制在3秒左右。本地容灾系统用于集中交易系统因为硬件的问题,例如：服务器无法启动、磁盘阵列无法启动、数据库的性能问题、或者数据库无法启动时,快速接管集中交易业务。同时由于本地容灾系统的数据库处于OPEN状态,所以证券公司也将历史数据的查询迁移到本地容灾系统上来做。本地备份系统：本地备份系统采用DSGSnapAssure产品将集中交易的数据备份过来,形成2周的备份版本。通过这些备份版本,可以将数据恢复到14天内的任意一个时间点。该系统主要用于防范人为误操作造成的数据破坏,比如TruncateTable、DropTable等造成的数据破坏,尤其是历史数据的破坏,这时需要利用本地备份系统来恢复丢失的数据。异地容灾系统采用DSGRealSync实时复制技术将交易系统的数据实时同步到异地容灾系统上。网络带宽为2Mbps。异地容灾系统用于本地发生电力故障、网络故障、火灾、地震以及其他环境故障时,业务可以在短期内快速接管至异地的容灾系统上,以确保业务不间断。性能和资源需求估算在关键业务系统中的应用,性能和压力是复制软件的核心,是每天每时每刻都用到的,尤其是在业务高峰期情况下,能否跟得上日志的产生速度、能否不大量的占用系统资源、能否保证复制的及时性是整个数据库复制软件产品最为核心的内容。根据我们在各种国内的几十家应用情况显示来看DSGRealSync在实时复制方面的性能是同类产品中领先的。主要体现在：网络需求RealSync对数据传输采用TCP/IP网络传输。RealSync复制操作只是读取操作系统的日志文件,同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。RealSync只将日志的三分之一的内容通过网络进行传输。实际每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3.日志分析速度我们采取了积压日志分析的方式进行测试,利用rac环境下的两台服务器同时产生10GB的日志数据,然后启动realsync测试其在多长时间内能够分析完这些数据。测试结果表名,在rac模式下,由两个数据库节点同时工作,在5分钟内产生的10GB归档日志,共计800万条记录,realsync只需要2分钟40秒即能分析完累积的日志,约9分钟装载完成。日志分析的速度远远高于产生日志的速度。完全能够满足用户IT系统的业务需求,即使是在业务高峰期,也不会造成日志累积。每秒钟复制的操作数在测试过程中,我们采用PL/SQL方式在源端产生1万,10万,100万条记录,以及进行1万,10万,100万的update,delete操作等。按照统计结果,DSGRealSync达到平均18000条/s的复制速度。完全能够满足单系统上用户IT系统的业务要求。复制数据延迟RealSync是一种异步准实时的复制技术,其数据延迟非常小。数据延迟的周期可以设置,在生产系统中,数据延迟和源系统复制事物的多少,事物的处理方式有关,以及跟设置的log数据轮询周期有关。在复制数据量正常的OLTP系统中,数据延迟一般在几秒钟。如果每天产生30GB的日志量,在155Mb带宽的情况下,可确保数据的延迟在5秒钟左右。CPU资源占用DSGRealSync通过Oracle日志获得数据的变化信息,它独特的技术优势使得它对源系统的资源占用很小。在生产系统中,实际对源系统的影响和源系统复制事物的多少,事物的处理方式有关。在复制数据量正常的OLTP系统中,正常状态下对CPU资源的占用为<5%的CPU资源占用。根据我们在XX地税的使用情况来看,在XX地市征管高峰期每2分钟产生100MB的日志量,而REALSYNC的日志分析资源占用仅为2%〔4cpu,8Gram。源端的缓存空间当容灾中心暂停或传输异常中断导致复制停止时,RealSync会将数据库的变化内容存储在源系统或目标系统的队列中,当系统恢复后,RealSync会自动识别复制环境,自动从断点处开始复制工作。在上述过程中,主中心的业务不受任何影响。数据的一致性不会破坏。当复制环境停止的情况下,需要在源系统和目标系统上存储的空间和业务系统每天峰值的日志数有关。根据每天平均产生25GB的日志计算,我们建议在源端给REALSYNC预留的缓存空间能够满足一天的缓存量：按照1/3的比例计算并增加一定的富裕量,需予留10GB的缓存存储空间。业务切换RealSync是通过对OracleLog日志进行分析获取跟踪源系统的交易指令实时的将指令传输到目标端进行加载,且目标端数据库始终在OPEN状态,可实时在目标端进行查询和统计,所以当灾难发生时或在主机源端发生故障以后,可直接将生产端数据库切换到容灾端,目标端数据库不需要重新启动,确保目标端数据的可用性,并大大提高了RTO、RPO指标。RTO,RPO指标规划采用交易级数据实时