《数据容灾备份中心建设方案书.doc》由会员分享,可在线阅读,更多相关《数据容灾备份中心建设方案书.doc(271页珍藏版)》请在三一办公上搜索。
1、数据容灾备份中心建设方案书单位数据容灾备份中心建设方案书(DSGRealsync数据复制容灾技术)迪思杰(北京)数码技术有限公司DSGdata Inc.目 录第一部需求分析71容灾项目建设需要注意的几大问题81.1为什么要建容灾系统81.2容灾不能替换备份81.3容灾项目需要多大的投资?101.4容灾项目如何解决投资回收问题111.5容灾项目对生产系统性能的影响121.6选择什么容灾技术能保证项目实施成功?122容灾项目的建设原则“平战结合”132.1变成本中心为利润中心132.2核心业务的灾备平台132.3业务负载分担132.4容灾技术的推荐“DSG RealSync”14DSG-RealS
2、ync数据同步复制容灾产品应用案例14DSG-SnapAssure高速备份产品应用案例152.5DSG RealSync数据库复制产品的特点163容灾技术对比和分析193.1容灾产品概述193.2基于异地备份技术实现容灾的分析193.3基于应用层容灾技术的分析203.4基于磁盘阵列复制容灾技术的分析203.5基于存储卷复制容灾技术的分析223.6基于虚拟化存储技术的分析233.7基于Oracle DataGuard容灾技术的分析243.8DSG Realsync容灾技术的分析26第二部整体方案设计294方案设计(案例:西部证券)304.1需求分析304.2DSG灾备一体化产品线304.3Sna
3、passure与Realsync的关系304.4容灾技术的推荐314.5系统结构324.6实时复制软件realsync配置334.7定时备份软件snapassure配置334.8功能实现334.9性能和资源需求估算344.9.1网络需求344.9.2日志分析速度344.9.3每秒钟复制的操作数344.9.4复制数据延迟354.9.5CPU资源占用354.9.6源端的缓存空间354.9.7业务切换354.9.8RTO,RPO指标规划354.10备份和灾难恢复策略设计364.10.1本地和异地的数据实时备份364.10.2本地数据定时备份364.10.3灾难恢复策略375方案设计的要点385.1O
4、PS/RAC的支持385.2数据完整性保证395.3数据初始化装载395.4选择性复制支持415.5支持的复制结构415.6产品规格425.7其它关键问题(DSGRealSync的关键答复)426DSG-RealSync解决方案的特点446.1业务功能实现446.1.1主备系统数据库处于双活状态446.1.2以数据保护为中心,侧重于保护业务数据安全446.1.3数据延迟446.1.4数据损失446.2性能和稳定性456.2.1对源系统性能的影响456.2.2对网络资源的使用456.2.3数据延迟456.2.4对主中心的影响466.2.5复制环境的健壮性466.2.6事物的完整性和可用性466.
5、3配置和实施476.3.1开放性476.3.2对源系统的修改工作476.4可扩展性476.4.1对系统扩容的影响476.4.2业务扩展的影响476.4.3对双机集群的支持477DSG-RealSync产品工作原理487.1日志抓取(Data Capture)487.2日志分析(Analyze)497.3交易合成(Synthesize)507.4交易传输517.5数据装载517.5.1用DXF数据格式的装载:527.5.2Row mapping实现快速定位528DSG SnapAssure备份产品(可选)548.1DSG SnapAssure备份技术概述548.1.1选型原则548.1.2DSG
6、 SnapAssure概述548.1.3DSG SnapAssure特点558.2SnapAssure备份产品工作原理568.2.1数据抽取578.2.2数据压缩578.2.3备份数据的组织588.2.4备份数据的访问588.2.5恢复功能598.2.6对非归档日志模式的支持608.3SnapAssure的模块组成618.4SnapAssure支持的备份策略628.4.1SnapAssure支持的备份类型628.4.2备份策略的设计638.4.3恢复策略638.5SnapAssure对Oracle备份系统的特殊优势648.6SnapAssure的案例668.6.1SnapAssure在广东联通
7、的应用:678.6.2SnapAssure在新疆电信IBSS系统中的集中备份应用67第三部项目实施及售后服务719项目实施规划729.1项目管理729.2实施策略规划739.3测试739.4生产系统实施749.5验收支持759.6验收方式759.7验收小组构成769.8验收工作流程图779.9培训789.9.1DSGRealSync复制容灾系统培训789.9.2DSGSnapAssure备份系统培训799.10知识转移809.11项目文档809.12项目小组8110项目的具体实施步骤8210.1容灾项目整体实施阶段概述8210.2数据复制软件本身实施步骤和周期8210.3容灾系统状态定义821
8、0.4环境准备8310.5安装和配置概述8410.6初始化复制环境、进行初始数据同步8410.6.1首次全同步分析8410.6.2全同步实施步骤8610.6.3时间估算8610.7开始实时复制8710.8灾难恢复8710.9数据一致性检查8710.10容灾中心的使用8811容灾演习、容灾切换和回切8911.1容灾演习8911.2切换的方式8911.3数据库的切换过程9011.3.1数据库切换方式:9011.3.2数据库切换的步骤9111.4应用服务器切换9211.5网络切换9211.6系统回切9411.7切换自动化管理工具9412容灾系统的维护和人员配置需求9512.1容灾管理规划9512.2
9、复制软件的日常维护9512.3人员组织结构规划9512.3.1容灾项目领导小组9512.3.2容灾项目经理9612.3.3系统专家9612.3.4网络专家9613售后服务内容及承诺9713.1服务宗旨与策略9713.2服务体系9813.3技术服务流程9813.4行业战略级售后服务计划9913.4.1工程实施阶段的服务9913.4.2系统售后运行期间的服务内容10013.5服务联系方式10114附:容灾系统术语与定义10314.1灾难10314.2灾备站点10314.3恢复时间目标(RTO)与恢复点目标(RPO)10314.4业务持续计划(BCP)与灾难恢复计划(DRP)10314.5系统灾难级
10、别定义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.4福建电信的计费查询平台应用12116.5河北地税11地市本地复制和数据集中上收和容灾应用123
11、16.6长江证券集中交易系统灾备应用12516.7西北证券灾备一体化方案12816.8湖北联通的复制应用13116.9江苏联通业务复制应用13316.10辽宁网通数据复制应用案例13516.11上海松江财政容灾系统应用案例13816.12山东联通计费系统容灾及查询平台应用14116.13SnapAssure在新疆移动BOSS系统备份的应用14316.14容灾异构平台的经验14516.15性能指标占用参考145第一部 需求分析1 为什么要建容灾系统随着业务的飞速发展使其单位时间内的业务量、相关的资金密度不断提高,因此,业务的间断直接意味着经济上的损失;另一方面,提供高可靠性、高水准的客户服务也是
12、保持良好形象的重要手段;随着IT系统建设的不断发展,我们在享受IT支撑系统带来的高效率、高服务的优势的同时,其业务运作也更加依赖于IT系统的稳定运行,其结果是,一旦发生IT系统停止运行,那么关键业务系统将受到严重影响,用户信息、征收记录等也随之丢失。随着应用系统的不断发展完善,信息化对工商系统的业务影响也越来越明显,为了更好地保护已有的数据资料,保证信息系统的正常运行,对一些关键业务的实时保护就变得异常重要,同时对关键数据的保护也变得十分重要。灾难恢复就是在这样的背景下提出的。本方案是根据*单位提出的容灾需求,所设计的方案。如有欠缺或遗漏之处,敬请谅解!2 容灾项目建设需要注意的几大问题2.1
13、 为什么要建容灾系统随着业务的飞速发展使其单位时间内的业务量、相关的资金密度不断提高,因此,业务的间断直接意味着经济上的损失;另一方面,提供高可靠性、高水准的客户服务也是保持良好形象的重要手段;随着IT系统建设的不断发展,我们在享受IT支撑系统带来的高效率、高服务的优势的同时,其业务运作也更加依赖于IT系统的稳定运行,其结果是,一旦发生IT系统停止运行,那么关键业务系统将受到严重影响,用户信息、征收记录等也随之丢失。因此,小至一般性的硬件故障,大到区域性的自然灾害,从物理的设备不可用,到逻辑的人为失误和破坏,都可能造成整个信息系统的全面瘫痪,导致业务运营的停顿。灾难的定义也从过去的大面积自然灾
14、害,转变为可造成IT系统应用不可用,产生的任何故障和灾害。 如何才能保证尽量减少企业数据的丢失、将危险与灾难的损失降低到最小程度呢?这就需要建立容灾系统,包括数据容灾以及应用容灾。容灾系统的核心就在于使用各种技术和管理手段将灾难化解,在实践中主要表现为两个方面:一是保证企业数据的安全;二是保证业务的连续性。经过在工作站点和灾难恢复站点运行同样的系统,包括操作系统、基础数据库和应用软件,并经过数据复制完成数据复制。假如工作站点发生灾难,不能再继续工作,这时容灾中心会将业务数据及时恢复到备用服务器上,并自动将业务切换到备用服务器,然后实现业务的远程切换,恢复系统不间断的运行,在容灾中心实现应用级容
15、灾,这个过程只需要很短的时间;在此基础上,在灾难过后,再将业务系统切换回正常的生产系统,实现业务的灾难恢复。因此,业务连续性和容灾建设的总体目标是:为关键业务系统提供风险预防机制和灾难恢复措施,在确保数据安全的基础上提高业务连续运行能力,降低企业运营风险,将业务损失降低到可接受的程度,提升管理和服务质量,增强企业竞争力。 2.2 容灾不能替换备份1容灾和备份的目的不同容灾系统的目的在于保证系统数据和服务的“在线性”,即当系统发生故障时,依然能够正常地向网络系统提供数据和服务,以使系统不致停顿。而备份技术的目的与此并不相同,备份是“将在线数据转移成离线数据的过程”,其目的在于应付系统数据中的逻辑
16、错误和历史数据保存。因此,在各种容错技术非常丰富的今天,备份系统依然是不可替代的。2备份是基石 备份是指为防止系统出现操作失误或系统故障导致数据丢失,而将全系统或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。备份是数据高可用的最后一道防线,其目的是为了系统数据崩溃时能够恢复数据。3容灾不可少 那么建设了备份系统,是否就不需要容灾系统?这还要看业务部门对RTO(恢复所需的时间指标)/RPO(能够恢复到的最新状态)指标的期望值,如果允许1TB的数据库RTO8小时,RPO1天,那备份系统就能满足要求。同时,备份的目的在于应付系统数据中的逻辑错误和历史数据保存。只能够满足数据丢失、数据
17、破坏时的数据恢复目的,而不能提供实时的业务接管功能。因此容灾系统对于某些关键业务而言也是必不可少的。人们谈及容灾往往是针对当生产系统,不能正常工作时,其业务可由容灾系统接替这些业务,继续进行正常的工作。 能够提供很好的RTO和RPO指标。同时远程容灾系统具备应付各种灾难,特别是区域性与毁灭性灾难的能力,具备较为完善的数据保护与灾难恢复功能,保证灾难降临时数据的完整性及业务的连续性,并在最短时间内恢复业务系统的正常运行,将损失降到最小。 4容灾不能替换备份容灾系统会完整地把生产系统的任何变化复制到容灾端去,包括不想让它复制的工作,比如不小心把计费系统内的用户信息表删除了,同时容灾端的用户信息表也
18、会被完整地删除。如果是同步容灾,那容灾端同时就删除了;如果是异步容灾,那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统中取出最新备份,来恢复被错误删除的信息。因此容灾系统的建设不能替代备份系统的建设。5规划企业安全保障体系考虑的因素对于企业而言到底应该如何建设自己的灾备系统,是只建设备份系统、还是只建设容灾系统、还是需要二者同时建设、或者是分步骤的建设,谁先谁后等问题,主要根据业务的需求而定:(1)需要防范的灾难类型:企业信息系统可能遇到的灾难类型及其发生的比例如下:对于“人为错误”、“软件损坏和程序错误”加上“病毒”等这些都称为逻辑错误,占总故障的 56%,这些错误只能经过备份
19、系统才能防范;对于 “硬件和系统故障”以及“自然灾难”等故障能够经过在容灾系统(或者异地备份)来防范,占总故障率的44%。(2)允许的RTO和RPO指标从技术上看,衡量容灾系统有两个主要指标:RPO(Recovery Point Object)和RTO(Recovery Time Object),其中RPO代表了当灾难发生时允许丢失的数据量;而RTO则代表了系统恢复的时间。一般而言:容灾系统能够提供较好的RTO和RPO指标。(3)系统投资总的说来,建设备份系统的投资远比建设标准意义的容灾系统的投资小得多:n 备份系统的投资规模一般在几百万;n 而最节省的一套容灾系统投资都将上千万;因为建设备份
20、系统所需的资源在以下几个方面的投资都远远小于容灾系统:备份系统容灾系统传输链路TCP/IP网络带宽一般1GBSAN网络独占光纤资源带宽要求10GB盘阵需求容量小只需要中档阵列容量大必须高端阵列系统维护成本几乎无需维护需建一个团队维护6常见的灾备组合方式基于以上原因,业界在灾备系统的建设上一般按照以下几种方式:n 建设机房内的本地备份系统n 建设异地的备份系统该方式能够备份系统的价格满足备份和异地容灾功能,能够避免主生产中心由于地震、火灾或其它灾害造成的数据丢失n 备份系统异地容灾系统这是一个较为理想化的灾备一体化解决方案,能够在很大程度上避免各种可能的错误。2.3 容灾项目需要多大的投资?其实
21、这个问题也能够被反问为:你希望容灾系统能达到什么效果?要想阐述清楚此问题,首先要明白两个指标:RTO和RPO。RTO,Recover Time Object,恢复时间指标(业务接管时间),是指当灾难发生后,生产系统需要多长时间能够恢复生产,它是衡量企业在灾难发生后多长时间能重新开始运转的指标。RPO,Recover Point Object,恢复点指标(数据丢失量),是指灾难发生后,容灾系统能把数据恢复到灾难发生前的哪一个时间点的数据,它是衡量企业在灾难发生后会丢失多少生产数据的指标。理想状态下,我们希望RTO=0,RPO=0,即灾难发生对企业生产毫无影响,既不会导致生产停顿,也不会导致生产数
22、据丢失。从当前计算机技术水平来说,我们能够为用户建设这种类型的容灾系统,其中最著名的例子当属VISA和Master的结算系统,由于这两个银行结算组织占据了全球银行结算业务的重要地位,她们的结算系统不允许发生任何停顿和数据丢失的情况,即使在911这种极端情况下。但实现这样的容灾系统的投资巨大,它结合了存储数据复制技术、服务器操作系统镜像技术、集群技术、数据库高可用性设计、应用系统高可用性设计、同步容灾技术、异步容灾技术、同城容灾方案、异地容灾方案,以及相应的管理流程和意外事件反映处理流程等详细的规章制度,和人员配备、行政保障手段(通信、交通等),综合在一起完成一个完整的容灾方案(实际是双生产中心
23、或多生产中心方案,并没有单纯的容灾中心)。可是这种方案的投资过于巨大,当前中国可能除了中国银联等这种特殊性质的企业外,不会有太多的企业会去实现这个系统。当前,在电信等企业的关键业务系统容灾项目建设中,投资规模为多少是合理的?如果业务部门能确认RTO/RPO指标,那技术部门选择了合适的容灾技术以及配套的管理流程就能够确定投资规模了。例如,如果业务部门确认,灾难发生后,3个小时内营业厅恢复生产就能够满足用户需求,且营业系统数据不能丢失,那RTO3小时,RPO0,那就必须选择基于存储平台数据复制技术的同步容灾方案;如果业务部门确认,灾难发生后,3天能恢复经营分析系统工作,且以前的数据丢失能够忽略不计
24、,那RTO=3天,RPO无,那选择ATA磁盘实现异地备份,就能满足要求。2.4 容灾项目如何解决投资回收问题从系统安全性角度考虑,我们必须为关键的业务支撑系统建设最有效的灾难恢复解决方案。可是在大部分情况下,当未出现灾难时,我们的容灾端系统总是处于空闲状态,花费大量投资买来的系统根本无法有效利用。这个问题一直困扰着用户。为了百年不遇的灾难投入巨资建设一个容灾中心,容灾中心的设备在灾难发生前不能给企业带来效益,这是企业决策者很难接受的,因此如何合理分配投资,将容灾中心建设成为第二生产中心,与生产中心成为企业支持企业正常运行的双中心,并实现互为容灾,是降低总体拥有成本(TCO,Total Cost
25、 of Ownership),提高投资回报率(ROI,Return Of Investment)的一个重要措施,应该得到企业的高度重视。因此,我们建议在容灾系统建设中,需要考虑的第一个问题是如何保证容灾端的系统能够得到充分利用,使容灾端系统的数据实现共享,能够利用容灾系统提供的高性能主机资源、存储资源为企业带来更大的处理能力。当前建设容灾方案的原则都是“平战结合”,容灾数据在平时能够方便的利用(查询统计报表等业务分担、实验系统数据来源、数据仓库中数据抽取),突出容灾数据的价值,保证容灾系统建设的合理性。当前能支持容灾数据实时再利用的解决方案不是很多,如DSG的RealSync产品,目标系统的数
26、据库一直处于打开状态,甚至在复制过程中。因此,RealSync技术除用于容灾外,还能够将不同的业务模块分布在源系统和容灾系统上,实现负载分担。因为RealSync的目标数据库在被实时更新时能够被访问,还能够被用于决策支持类应用。 为决策分析和报表系统提供快速的数据抽取功能 提供准实时脱机查询,提高查询效率 为试验系统提供真实的生产数据将以上原来需要在主系统上运行的业务与生产系统完全隔离,充分利用容灾系统的资源,实现企业应用负载分担,减少对生产系统的影响,提高服务系统响应效率;从而将容灾系统这个成本中心转化为利润中心。2.5 容灾项目对生产系统性能的影响容灾系统的本质是将生产系统的数据以及这些数
27、据的变化,完整地复制到容灾系统中,并经过相关技术手段,确保容灾系统中数据的完整性和一致性。容灾系统对生产数据和生产数据的变化的复制操作,必然需要与完成这些操作相对应的CPU资源(存储的CPU、或服务器的CPU)、内存资源(存储的Cache、或服务器的RAM)、网络资源(TCP/IP、FC或FICON),如果这些资源不能独立分配给容灾系统(实际上不可能独立),则必然会影响生产系统的性能。因此更准确的问题是,如何确保容灾系统上线后,在能够实现既定的RTO/RPO指标的同时,不会影响生产系统的正常运行?答案是能够经过技术手段实现的。要想实现,则必须对现有生产系统进行详细的性能分析,包括系统I/O特性
28、(IOPS,Respond Time,读写比,I/O块大小,I/O峰值、均值,时间特性等等)、系统内各子系统业务特点、存储空间分配、服务器CPU和RAM资源的使用状况、SAN网络情况(端口使用状况、Zoning划分状况、端口IOPS等)、能够使用的数据复制链路(FC、TCP/IP、ATM、E1/E3)以及链路的QoS保障等。获得这些数据后,经过对容灾系统I/O分布的详细设计,将I/O均匀分布到更多的设备上,从而确保生产系统实现容灾后,不会造成性能下降影响正常生产的情况出现。2.6 选择什么容灾技术能保证项目实施成功?容灾项目实施成功,与技术关系不大。能举出成功案例的容灾技术,则必有它的可行性。
29、但作为一个工程师,除了考虑项目的可行性外,还要考虑项目的不可行性。任何技术的实现,都有它的制约条件。在自己的生产环境中,能否避免这些制约条件的出现?或者出现后,是否有资源能够解决它?比如ORACLE在中国实施了一个基于DataGuard的容灾方案,但在实施过程中出现了大量意想不到的问题和BUG,作为对该特殊客户的重视,ORACLE甚至从国外派遣R&D人员到现场编制PATCH以保证项目能实施,但这种资源,是否每个客户都能向ORACLE索取?因此,选择一个简单的容灾方案,并选择一个曾经成功实施过该方案的工程团队,才是确保容灾项目实施成功的关键。3 容灾项目的建设原则“平战结合”3.1 变成本中心为
30、利润中心容灾与其它任何保险策略一样,当没有灾难出现时,我们根本无法意识到容灾系统所起到的作用,无法回收容灾系统建设所需的大量投资。但从系统安全性角度考虑,我们又必须为关键的业务支撑系统建设最有效的灾难恢复解决方案。可是在大部分情况下,当未出现灾难时,我们的容灾端系统总是处于空闲状态,花费大量投资买来的系统根本无法有效利用。这个问题一直困扰着用户。因此,我们建议在容灾系统建设中,需要考虑的第一个问题是如何保证容灾端的系统能够得到充分利用,使容灾端系统的数据实现共享,能够利用容灾系统提供的高性能主机资源、存储资源为企业带来更大的处理能力。因为对于容灾系统而言还有一套整体的规划,未来的统一容灾系统对
31、于数据的异地保护将起到非常关键的作用,将来的容灾系统无论在数据的实时性上,还是安全可靠性性上都会非常完善,只不过在业务的接管方面无法满足业务需求。因次本次建设容灾系统目的是提供一个能够快速接管的系统,能够充分利用投资的方案。为此我们强烈建议采用双active的结构,让容灾系统的数据库也处于OPEN状态,这样实际上关键系统就拥有了第二数据中心,而不但仅是一个灾难备份系统,经过第二数据中心能够实现如下功能:3.2 核心业务的灾备平台经过数据同步建立的第二数据中心能够实现对业务关键数据的容灾及保护,在不影响生产数据库性能的同时为生产数据库在本地或异地建立一份准实时镜像,以保证在生产数据库发生灾难时可
32、使用容灾数据库进行业务接管和数据恢复。3.3 业务负载分担这里要求第二数据中心的数据必须处于实时可读取状态,数据库必须处于OPEN状态,实现系统业务模块的重新部署。经过第二数据中心实现对核心系统的业务模块进行负载分担,将那些只对数据进行读取操作的模块都迁移到第二数据中心上来,主要包括: 提供帐务和话单实时查询; 提供统计报表运行; 提供经营分析数据抽取; 提供其它系统的数据访问接口;这样作将达到两个好处: 提高数据访问的效率,提高外围系统部署的灵活性; 提高核心系统的运行效率,提高核心系统运行的稳定和可靠性;3.4 容灾技术的推荐“DSG RealSync”我们建议采用DSG RealSync
33、软件作为关键系统的数据备份方案。这个方案能够很好的解决灾备的难点:第一:网络带宽要求低:交易级复制软件需要在网络上传输的量为oracle redo log的1/3。一方面比oracle DG的带宽要求低,当然更远远低于磁盘阵列复制所需要的带宽。第二:可支持不同硬件环境之间的异构环境容灾,使得关键系统的集中容灾方案不但能够满足多个IT系统的需求,同时更能满足用户IT系统的五花八门的硬件环境的需求。第三:容灾数据库更可靠:因为容灾数据库是OPEN状态的,因此不会存在容灾数据库无法启动的风险。同时这种方式可避免生产库上出现坏块等物理错误。第四:容灾数据库处于OPEN状态,可在容灾数据库上进行查询、统
34、计报表等功能,实现业务负载分担。DSG从 在中国成立以来,在RealSync这个数据库复制产品的项目实施方面也经过了很长的一段路。DSG始终以“客户需求为导向”的原则发展自己的产品,到当前为止,DSG RealSync产品已经在电信、政府、政券和企业采用,主要包括(详见方案后案例):DSG-RealSync数据同步复制容灾产品应用案例 电信行业 广西移动BOSS容灾及查询平台建设系统; 北京移动告警数据同步、备份及容灾系统 广西电信数据灾备中心应用 陕西电信BOSS数据复制应用 福建电信计费系统数据复制应用 辽宁网通支撑系统复制/查询统计平台项目 江苏联通大客户系统数据复制项目 四川联通业务支
35、撑系统数据复制应用 山东联通计费系统容灾项目 广东联通综合营帐数据复制 江西联通BOSS系统数据复制/查询平台应用 湖北联通数据复制/查询平台应用 成都电信Oracle数据异构复制迁移项目 舟山电信支撑系统容灾及备份应用 绍兴电信支撑系统容灾及备份应用 湖州电信支撑系统容灾及备份应用 其它行业 河北省地税数据集中及容灾系统; 上海松江财政异地容灾 武汉财政异地容灾备份项目 辽宁省交通厅征稽局征费系统“数据同步复制软件”容灾项目 中国金融期货交易所异地容灾 济钢Oracle-ERP数据同步复制项目 深圳神州通集团数据复制异地容灾应用 长江证券数据集中的容灾应用 华泰证券数据集中的容灾应用 国联证
36、券数据集中的容灾应用 民族证券数据集中的容灾应用 西南证券数据集中的容灾应用 山西证券数据集中的容灾应用 金通证券数据集中的容灾应用 中原证券数据集中的容灾应用 西南证券数据集中的容灾应用 南京证券异地容灾项目 银河证券数据容灾备份综合管理应用 西部证券数据容灾备份一体化综合管理应用 DSG-SnapAssure高速备份产品应用案例 电信行业 中国电信总部结算中心备份系统 中国联通总部CRM备份系统 中国电信全国九省结算中心备份系统(江苏、江西、广西、青海、海南、新疆、贵州、甘肃、福建) 北方电信九省结算系统备份(辽宁、黑龙江、吉林、河南、山西、山东、河北、天津、内蒙古 ) 信息产业部全国十省
37、互连互通和网间结算备份系统(含浙江、江苏、陕西、黑龙江、福建、江西、甘肃、吉林、宁夏和重庆信产厅) 江西移动BOSS系统异地备份系统 甘肃移动BOSS系统集中备份 青海移动BOSS灾备系统 新疆移动结算系统灾备项目 天津联通固网计费备份系统 广东联通综合结算备份系统; 辽宁联通全省数据库集中备份 四川联通业务支撑系统集中备份 河北联通数据备份系统升级应用 陕西联通业务支撑系统的集中备份 重庆联通业务支撑系统的集中备份 吉林、湖北、江西联通支撑系统的集中备份 新疆电信BSS/OSS系统备份项目 青海电信数据集中备份系统 宁夏电信业务支撑系统集中备份 周口通信、沧州通信计费系统备份项目 其它行业
38、银河证券全国数据中心集中备份系统 东莞社保数据备份项目 广西公安备份系统 广州公安备份及查询应用项目 石家庄公安户籍系统备份应用 新疆电力数据备份系统 杭州电力数据备份系统 江汉油田数据备份系统 3.5 DSG RealSync数据库复制产品的特点DSG RealSync产品经过在逻辑级,经过传输和运行数据库事务(Transaction),来提供实时数据复制功能,支持对生产系统数据库生成多个副本,用以作为灾难备份、和信息系统优化部署应用。RealSync对ORACLE的日志进行监控,发现改变的块及时对目标数据库进行更新,当应用系统向数据库中进行任何操作时时,这些信息都将在在线日志中存储,Rea
39、lSync经过对实时获取的数据库在线日志进行分析,获得本次操作的交易指令和交易数据,然后将这些交易指令和交易数据经过格式转化并实时压缩后经过网络传送到目标系统。目标系统的RealSync代理接收数据库包,经过校验码检查,确认正确的数据库包后,将包解压进行格式转化后按照交易的先后顺序在容灾系统中重新执行该交易。(1)Transaction-Based的复制机制:该产品的实现不是经过数据库底层存储复制、也不是将生产系统的Log复制到目标系统上重新应用的模式。而是在源系统上经过Log分析出系统的交易指令(Transaction),然后将交易指令在目标端装载的原理实现的。因此,目标端的数据库必须处于O
40、pen状态,而且两端的操作系统、数据库平台等都能够属于不同版本。(2)快速的Transaction Load技术:基于主机的复制软件最大的问题在于性能是否满足大容量业务需求,如果复制软件在采用标准的SQL语句进行复制的话,势必要求目标系统与源系统具有相同的处理性能,从而导致投资成本大幅度上升。DSG RealSync独创DXF(DSG Extend Format)数据表示格式,经过应用该格式实现数据的传输和装载能够达到数据库装载速度的极限,满足大容量应用系统的性能需求。该产品在支持作为灾难备份时具有如下特点:异构的系统平台,开放的硬件选择:RealSync技术在逻辑级的数据复制技术,因此对于生
41、产系统和容灾系统来说,其硬件平台能够属于不同的厂商、不同的型号,可采用不同的操作系统等。零时间数据库切换的热容灾:系统恢复时间是指当主系统出现故障不能在短期内恢复,而需要启动容灾端系统时,容灾端系统启动的时间。该时间不但仅是指容灾端的硬件系统启动,更主要的、也是更耗费时间的是容灾端数据库系统的启动、业务系统的启动和外部接口的切换等。其中又以数据库的启动最为耗费时间,因为容灾端数据库不属于正常下线,因此重起时需要作许多检查和恢复,花费的时间非常长。RealSync维护的容灾数据库系统在数据复制过程中也始终处于打开状态,保证数据复制在逻辑上的完整性,RealSync技术为源系统提供了永远可用的后备
42、数据库系统。在源系统出现故障时,应用系统可实现实时访问备用数据库系统。达到数据库系统的零切换目的。可靠的数据复制技术:RealSync维护的容灾数据库系统始终处于打开状态,保证数据复制在逻辑上的完整性和可靠性,保证容灾站点数据库系统可用的系统。投资回报分析(ROI):容灾系统始终处于打开状态,可提供数据抽取、报表系统、试验系统等实现数据共享,为信息系统提供更多的可利用资源。支持从高到中低端应用需求:由于RealSync在建设容灾系统时,对服务器、存储阵列和传输带宽要求都无特殊要求,而不同于传统容灾技术要求高端磁盘阵列、高端服务器、数GB的传输带宽,因此该系统适应于高端的电信、金融客户、也适合中
43、端的政府机构、大型企业、同时也适合于运行PC平台的中小型企业应用。该产品在支持作为系统优化部署应用时具有如下特点:按需复制查询和统计系统往往不需要所有的原始数据,因此完全能够按需要复制数据。RealSync系统支持对指定信息的按需复制,如指定需要复制的表、字段和条件等,减少存储和网络带宽的成本。实时数据更新实时更新保证副本系统快速反映源系统的变化,提供账单查询、话单查询等的及时性。经过大量的测试,实时数据复制技术使源系统和目的系统的数据延迟10秒。对生产系统的低干扰性DSG实时数据复制技术不需要经过任何数据库的引擎来获取变更数据,而是经过数据库自身的信息获取源系统上的改变并传送给目的系统,不会
44、对生产系统造成性能影响。系统异构,可提供更多的优化空间源数据库系统和目的数据库系统的可异构,主要包括索引规则和存储参数(如数据块大小、回滚段等)。因此能够在目标数据库上根据业务特点进行调整和优化,完全不受源系统的限制。4 容灾技术对比和分析4.1 容灾产品概述在选择容灾系统的构造时,首先要考虑的就是选择采用合理的异地数据复制技术。数据的远程复制技术是容灾系统的核心技术,它对于数据系统的一致性和可靠性以及系统的应变能力具有举足轻重的作用,经过有效的数据复制,远程的业务数据中心与本地的业务数据实现同步,确保一旦本地系统故障,远程的容灾中心迅速进行完整的接管。一般说,在容灾系统方案的数据复制技术上存
45、在两种主流模式:l 第一种方式是基于智能存储的数据镜像技术。该技术是将数据复制经过磁盘阵列控制器在进行写入操作的同时经过高速网络向容灾系统的阵列上发送相同的I/O指令来实现,因此该方案对主机的资源占用很小;稳定性好;同步性强。该技术主要由各存储设备生产厂家所推荐,如EMC,IBM,HP等都提供了相应的解决方案。l 第二种方式是基于主机系统的数据复制,该方式是把数据定期、在线地复制到目的地的机器上去。这种方案大部分由存储管理软件厂家提供,特别是VERITAS推出了一系列基于该方案的存储管理软件解决方案。实现这些功能的业界常看法决方案主要包括以下几类:l 磁盘阵列复制技术:主要由一些磁盘阵列厂商提供,如EMC SRDF、IBM PPRC 、HP BusinessCopy、HDS TrueCopy等;l 存储卷复制技术:由一些卷管理