医院数据中心异地灾备系统建设.docx

上传人:b****6 文档编号:13436538 上传时间:2023-06-14 格式:DOCX 页数:45 大小:98.27KB
下载 相关 举报
医院数据中心异地灾备系统建设.docx_第1页
第1页 / 共45页
医院数据中心异地灾备系统建设.docx_第2页
第2页 / 共45页
医院数据中心异地灾备系统建设.docx_第3页
第3页 / 共45页
医院数据中心异地灾备系统建设.docx_第4页
第4页 / 共45页
医院数据中心异地灾备系统建设.docx_第5页
第5页 / 共45页
医院数据中心异地灾备系统建设.docx_第6页
第6页 / 共45页
医院数据中心异地灾备系统建设.docx_第7页
第7页 / 共45页
医院数据中心异地灾备系统建设.docx_第8页
第8页 / 共45页
医院数据中心异地灾备系统建设.docx_第9页
第9页 / 共45页
医院数据中心异地灾备系统建设.docx_第10页
第10页 / 共45页
医院数据中心异地灾备系统建设.docx_第11页
第11页 / 共45页
医院数据中心异地灾备系统建设.docx_第12页
第12页 / 共45页
医院数据中心异地灾备系统建设.docx_第13页
第13页 / 共45页
医院数据中心异地灾备系统建设.docx_第14页
第14页 / 共45页
医院数据中心异地灾备系统建设.docx_第15页
第15页 / 共45页
医院数据中心异地灾备系统建设.docx_第16页
第16页 / 共45页
医院数据中心异地灾备系统建设.docx_第17页
第17页 / 共45页
医院数据中心异地灾备系统建设.docx_第18页
第18页 / 共45页
医院数据中心异地灾备系统建设.docx_第19页
第19页 / 共45页
医院数据中心异地灾备系统建设.docx_第20页
第20页 / 共45页
亲,该文档总共45页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

医院数据中心异地灾备系统建设.docx

《医院数据中心异地灾备系统建设.docx》由会员分享,可在线阅读,更多相关《医院数据中心异地灾备系统建设.docx(45页珍藏版)》请在冰点文库上搜索。

医院数据中心异地灾备系统建设.docx

医院数据中心异地灾备系统建设

医院数据中心异地灾备系统建设

1医院数据中心异地灾备系统建设

 

 

医院数据中心

异地灾备系统建设

 

项目建议书

 

迪思杰(北京)数码技术有限公司

2010-8-24

 

 

能有这么多技术人员保障,能够解决各个环节的启动、切换等,这个一个非常现实的问题。

由于Realsync软件实施的容灾数据库是OPEN状态的,所以没有主机、存储、数据库重启等繁琐步骤,只需要将容灾端ORACLE数据库的trigger激活,并将应用服务器器连接到接管的数据库服务器上。

Realsync是所有方案中切换最简单、最方便的,相信这个操作大部分的IT部门人员都可以完成。

       不足二:

30分钟切换(接管)的压力较大

由于采用磁盘阵列/存储卷/虚拟容灾方案,在业务切换(接管)时需要经过主机启动、存储启动、Oracle数据库启动、网络切换、应用切换等多个环节;其中仅UNIX操作系统启动(含服务器外围设备和网络等元素的启动)和Oracle启动两个步骤就要花费几十分钟(至少为15+10=25分钟)。

在很多关键行业,如果要实现30分钟内接管业务,这是有一定压力的。

因此,在证券等实时性较高的行业,数据库复制技术被大规模采用。

(DSG目前在金融证券基金期货行业,拥有50多个灾备客户)

       不足三:

备份数据库是否一定能够接管还存在疑问

由于磁盘阵列/存储卷/虚拟容灾方案是采用基于IO级别的同步,而这个同步和Oracle的写操作是不完全一致的,所以备份数据库存在几个疑问:

n       疑问一:

灾难产生时,备份系统的Oracle是否一定能够起得来?

n       疑问二:

即使Oracle能够起得来,数据是否一定都能够读取?

n       疑问三:

灾难切换后系统的性能是否处于正常状态?

       不足四:

无法避免物理错误(如磁盘坏块),导致数据不一致、不安全

由于磁盘阵列/存储卷/虚拟容灾方案是采用基于IO级别的同步,无法解决磁盘经常出现的物理错误,例如:

数据库坏块,这是Oracle数据库经常出现的典型问题(我们可以提供许多实例)。

因此,基于磁盘阵列/存储卷/虚拟容灾的方案将面临数据丢失的风险。

而数据库复制技术则不会有这样的问题。

 

2.2推荐采用“RealSync产品”

要建立查询数据库的关键技术,就是数据库的实时复制。

目前****医院是采用的Oracle数据库,而实现Oracle数据库数据实时复制的产品只有两类方案,一是Oracle自带的工具,二是第三方的数据库复制工具。

而Oracle自带的工具在资源占用、效率和功能等方面,还满足不了****医院现有系统的需求,因此在本方案里,DSG推荐采用Realsyc产品,该产品目前在业内应用范围广泛,主要实现如下功能:

(一)核心业务的灾备平台

通过数据同步建立灾备中心可以实现对业务关键数据的容灾及保护,在不影响生产数据库性能的同时为生产数据库在本地或异地建立一份准实时镜像,以保证在生产数据库发生灾难时可使用容灾数据库进行业务接管和数据恢复。

(二)业务负载分担

由于复制的第二数据中心的数据处于实时可读取状态,数据库处于OPEN状态,从而实现系统业务模块的重新部署。

通过第二数据中心实现对核心系统的业务模块进行负载分担,将那些只对数据进行读取操作的模块都迁移到第二数据中心上来,主要包括:

ü       提供帐务和话单实时查询;

ü       提供统计报表运行;

ü       提供经营分析数据抽取;提供其他系统的数据访问接口;

这样作将达到两个好处:

ü       提高数据访问的效率,提高外围系统部署的灵活性;

ü       提高核心系统的运行效率,提高核心系统运行的稳定和可靠性;

 

2.3为什么推荐RealSync产品

我们建议采用DSGRealSync软件的原因在于:

1.       提供可靠的应急切换,避免物理错误的复制

实现对业务关键数据的容灾及保护,打开的Oracle数据库确保在业务切换时数据库一定可以打开接管业务,避免了数据库可能无法启动的风险;DSGRealsync是基于交易指令的复制,因此对于那些产生坏块,或者是文件被破坏等操作将不会在目标系统重现。

2.       支持不同硬件平台之间的复制

RealSync技术是逻辑级的数据复制技术,因此对于生产系统和目标系统来说,其硬件平台可以属于不同的厂商、不同的型号,亦可采用不同的操作系统等等。

它的优点在于:

一方面,在系统建设时,为用户提供硬件平台的灵活选择空间;同时,提供了在同一解决方案架构下,实现企业不同平台上的多个信息系统的统一复制的支持。

如支持UNIX/AIX---Linux的复制容灾,大大节约成本。

3.       复制目标数据库处于OPEN状态、数据是实时的、可以支持实时数据库访问

RealSync维护的容灾数据库在数据复制过程中始终处于打开状态,客户可通过打开的Oracle数据库实现快速切换,且在目标端数据库提供数据查询、报表和ETL抽取等功能,实现业务分担;满足此次提供的业务需求。

4.       按需复制,满足业务需求,降低存储成本和网络成本

根据客户建设管理数据库的业务需求,很多情况下,仅仅对需要的数据表信息进行复制,realsync软件完全可以支持这类需求,这样也可以减轻复制的压力、减少存储和网络带宽的成本。

5.       对生产系统的低干扰性

DSG实时数据复制技术不需要通过任何数据库的引擎来获取变更数据,而是通过数据库自身的信息获取源系统上的改变并传送给目的系统,这不会对生产系统造成性能影响。

6.       提供不停业务的首次全同步功能和单表修复功能

RealSync还提供目标端系统数据初始装载功能支持,将主系统上的已有存量数据,在不中断业务的情况下平滑的装载到目标数据库上。

这是realsync软件独有的功能。

7.       支持长距离复制、更低的网络带宽要求和运行成本

目前Realsync是全球同类方案中要求最低的,交易级复制软件仅需要在网络上传输的量为Oracleredolog的1/3,一方面比OracleDG的带宽要求低,当然更远远低于磁盘阵列、卷文件、虚拟存储复制所需要的带宽。

8.       成熟的产品、稳定的应用

DSG从2002年在中国成立以来,在RealSync这个数据库复制产品的项目实施方面也经过了很长的一段路。

DSG始终以“客户需求为导向”的原则发展自己的产品,到目前为止,DSGRealSync产品已经在数据量超大的电信行业、安全性要求极高的金融行业、环境较为复杂的政府和企业中被广为采用,主要包括:

l       电信行业:

北京移动、广西移动、甘肃移动、贵州移动、青海移动、澳门电信、广西电信、陕西电信、贵州电信、四川电信、山东电信、内蒙电信、河北电信、辽宁电信、吉林电信、江西电信、云南电信、安徽电信、海南电信、福建电信、甘肃电信、宁夏电信、新疆电信、广东电信、杭州电信、舟山电信、绍兴电信、湖州电信、辽宁网通、山东联通、江西联通、福建联通、广西联通、湖南联通、江苏联通、四川联通、吉林联通、广东联通、贵州联通、湖北联通、内蒙联通、贵州联通、云南联通…

l       金融行业:

广发银行、太平洋保险集团、上海黄金交易所、中国金融期货交易所、中国期货保证金监控中心、天平保险、华夏基金、易方达基金、金元比联基金、友邦基金、招商基金、南方基金、鲁证期货、中银期货、东吴期货、信达期货、西部期货、国泰君安期货、鲁能金穗期货、东航期货、中原期货、中大期货、广发证券、银河证券、民族证券、宏源证券、新时代证券、上海证券、远东证券、太平洋证券、东兴证券、万联证券、金元证券、信达证券、江南证券、华泰证券、南京证券、信泰证券、东吴证券、长江证券、国联证券、东海证券、西南证券、山西证券、金通证券、中原证券、财达证券、西部证券、国盛证券、国海证券、华福证券、恒泰证券、湘财证券、华鑫证券、财富证券、中天证券、财通证券、国金证券、中投证券、华欧证券、中邮证券、德邦证券、爱建证券、华宝证券、联合证券、日信证券、英大证券…

l       政府行业:

国家知识产权局、北京电力、四川电力、河南电力、江西电力、青海电力、吉林电力、湖南电力、安徽电力、宁夏电力、天富热电、厦门电力、河北省地税、重庆地税、深圳地税、深圳市统计局、武汉财政、上海松江财政、吉林省交通厅、辽宁省征稽局、蛇口码头、宁波港、江苏省航道局、江苏农垦、无锡公积金、贵州公安、东营公安、青岛有线、泰州社保、南通社保、阿克苏社保、太仓社保、中国一汽、济南钢铁、南京军区总医院、格力电器、深圳神州通集团、深圳统计局、阿里巴巴、河北省地税11地市征管数据集中容灾备份系统、江西省电力12地市营销数据集中容灾备份……

 

2.4RealSync在应急灾备方面的特点

l       零时间数据库切换的热容灾:

系统恢复时间是指当主系统出现故障不能在短期内恢复,而需要启动容灾端系统时,容灾端系统启动的时间。

该时间不仅仅是指容灾端的硬件系统启动,更主要的、也是更耗费时间的是容灾端数据库系统的启动、业务系统的启动和外部接口的切换等。

其中又以数据库的启动最为耗费时间,因为容灾端数据库不属于正常下线,因此重起时需要作许多检查和恢复,花费的时间非常长。

RealSync维护的容灾数据库系统在数据复制过程中也始终处于打开状态,保证数据复制在逻辑上的完整性,保证灾难切换的时效性和可靠性,RealSync技术为源系统提供了永远可用的后备数据库系统。

在源系统出现故障时,应用系统可实现实时访问备用数据库系统。

达到数据库系统的零切换目的。

打开的备份数据库保证数据复制在逻辑上的完整性,为源系统提供了永远可用的后备数据库系统,确保容灾系统的可靠性。

当源系统出现故障时,应用系统可实现实时访问备用数据库系统,无需重新启动备用数据库,达到数据库的秒级切换目的。

l       异构的系统平台,开放的硬件选择:

RealSync技术是逻辑级的数据复制技术,因此对于生产系统和容灾系统来说,其硬件平台可以属于不同的厂商、不同的型号,可采用不同的操作系统等。

它的优点在于:

一方面为用户提供容灾系统建设时,硬件平台的可灵活选择空间;同时提供了在同一容灾解决方案架构下,实现企业不同平台上的多个信息系统的统一容灾支持。

l       支持从高到中低端应用需求:

由于RealSync在建设容灾系统时,对服务器、存储阵列和传输带宽要求都无特殊要求,而不同于传统容灾技术要求高端磁盘阵列、高端服务器、数GB的传输带宽,所以该系统适应于高端的电信、金融客户、也适合中端的政府机构、大型企业、同时也适合于运行PC平台的中小型企业应用。

l       投资回报分析(ROI):

采用RealSync容灾技术,容灾数据库始终处于打开状态,不同于其他模式下容灾数据库系统不可用的状态。

因此,可以通过RealSync维护的容灾系统,提供数据共享服务:

为决策分析和报表系统提供快速的数据抽取功能

提供准实时脱机查询,提高查询效率

为试验系统提供真实的生产数据

将以上本来需要在主系统上运行的业务与生产系统完全隔离,充分利用容灾系统的资源,实现企业应用负载分担,减少对生产系统的影响,提高服务系统响应效率;从而将容灾系统这个成本中心转化为利润中心。

l       灵活的组网结构和低带宽资源需求

RealSync采用交易(Transaction)传输方式,极大的减少了复制过程中需要传输的数据量。

使得在网络上传输的数据量大大减少,要求更低的网络带宽。

Realsync支持标准的TCP/IP网络传输,用户可灵活布建容灾网络架构。

系统可支持1:

1、N:

1、1:

N和双向容灾结构支持,提高企业容灾结构的灵活性。

 

2.5RealSync在报表分担、数据共享利用等方面的特点

l       按需复制

查询和统计系统往往不需要所有的原始数据,因此完全可以按需要复制数据。

RealSync系统支持对指定信息的按需复制,如指定需要复制的表、字段和条件等,减少存储和网络带宽的成本。

l       实时数据更新

实时更新保证副本系统快速反映源系统的变化,提供账单查询、话单查询等的及时性。

经过大量的测试,实时数据复制技术使源系统和目的系统的数据延迟<10秒。

l       对生产系统的低干扰性

DSG实时数据复制技术不需要通过任何数据库的引擎来获取变更数据,而是通过数据库自身的信息获取源系统上的改变并传送给目的系统,不会对生产系统造成性能影响。

l       系统异构,可提供更多的优化空间

源数据库系统和目的数据库系统的可异构,主要包括索引规则和存储参数(如数据块大小、回滚段等)。

因此可以在目标数据库上根据业务特点进行调整和优化,完全不受源系统的限制。

3      方案设计

数据库同步复制软件是****医院实施关键系统灾备工程的一个重要组成部分,当生产系统出现异常或故障时,备份系统的数据库能够完全代替生产系统的Oracle数据库管理系统,以实现关键系统的正常运行。

l       业务功能实现:

在关键业务应用系统的数据库上安装复制软件代理程序,通过代理程序获取数据库的交易,实现数据变化的实时跟踪。

抓取的数据通过1000Mbps以太网进行实时传输,实现系统数据同步到备份系统上的实时传输。

l       技术实现:

复制软件是采用交易复制的方式进行数据同步;灾备数据库上的Oracle数据库处于OPEN状态,可提供实时数据访问;如可将生产系统上的统计查询等业务运行在历史的Oracle数据库上,数据复制的时延可以空载在3-5秒左右;具体细节如下:

3.1方案设计

根据以上系统状况和功能要求,本期项目将采用1套Realsync数据库复制软件来完成:

根据业务需求,在关键系统安装DSGRealSync程序,该程序对ORACLE数据库产生的redolog进行实时分析,生成sql语句。

并将sql语句通过IP网络传输到历史数据库。

 

3.2Realsync软件配置

DSGrealsync软件的安装分为生产系统和目标系统两个方面:

n       生产系统上:

DSGrealsync在每个数据库实例都要安装一个productionagent,用来分析本agent产生的redolog数据。

n       目标系统上:

DSGreasync在备份中心的服务器上,分别安装一个realsync,但需要为每个instance启动一个destinationagentport。

Realsync数据库复制软件

Seq.

Name

Description

Qty

备注

1

rs-0501-0101

RealSyncLicenceforProductionServer UNIX

1

数据源客户端模块:

安装在数据源服务器端的软件代理程序,负责监测源端数据库变化,并将改变信息实时同步传输

2

rs-0501-0201

RealSyncLicenceforDestinationServer UNIX

1

目标客户端模块:

安装在目标数据库服务器端的软件代理程序,负责接收数据库修改指令,并加载数据,在实现数据同步的同时完成数据共享

3

rs-0501-0801

RealSyncFullSync LicenseUNIX

1

执行首次数据初始完全同步的模块

4

RS-0401-0601

RealSyncManagementConsole

1

管理平台软件模块,用于系统管理员维护,对软件进行统一的配置、策略和过程的管理,支持字符和界面操作。

 

各模块的作用:

RealSyncforProductionServer:

安装在源系统(DataSource)上运行数据库实例的服务器上,每个数据库实例配置一个License;

该模块中又包含以下功能:

ü       AnalyzerModule:

日志分析功能

ü       SynthisizerModule:

交易合成功能

ü       senderModule:

数据传输(输出端)功能

RealSyncforDestinationServer:

安装在复制目标系统(DataTarget)上运行数据库实例的服务器上,每个数据库实例配置一个License;

该模块中又包含以下功能:

ü       ImporterModule:

数据传输(输入端)功能

ü       LoaderModule:

交易指令装载功能

RealSyncFullSync

首次全同步功能;

提供从源数据库上把已有的存量数据初始化同步到目标系统上来,即将源系统上的所有表的数据export出来传输到备份系统上import进去,实现初始数据的同步。

该模块的特点是在初始化过程中无需业务停机,而且可以多路并发,可处理全同步过程中的变量数据。

RealSyncmanagementconsole:

管理控制界面;

 

3.3性能和资源需求估算

在关键业务系统中的应用,性能和压力是复制软件的核心,是每天每时每刻都用到的,尤其是在业务高峰期情况下,能否跟得上日志的产生速度、能否不大量的占用系统资源、能否保证复制的及时性是整个数据库复制软件产品最为核心的内容。

根据我们在各种国内的几十家应用情况显示来看DSGRealSync在实时复制方面的性能是同类产品中领先的。

主要体现在:

n       网络需求

RealSync对数据传输采用TCP/IP网络传输。

RealSync复制操作只是读取操作系统的日志文件,同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。

RealSync只将日志的三分之一的内容通过网络进行传输。

实际每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3。

根据估算,如客户每天产生的日志量约为10GB,我们按照80%的日志量在1天的20%时间内(这里设为4小时)产生的,那么我们可以估计高峰期的日志量为8GB/3*1024*1024/(4*3600)=1.5Mb/s。

同时为了预留一定的带宽,建议将带宽作为10Mbps就能满足日常的复制需求。

本项目的带宽情况完全能够满足要求。

n       日志分析速度

我们采取了积压日志分析的方式进行测试,利用rac环境下的两台服务器同时产生10GB的日志数据,然后启动realsync测试其在多长时间内能够分析完这些数据。

测试结果表名,在rac模式下,由两个数据库节点同时工作,在5分钟内产生的10GB归档日志,共计800万条记录,realsync只需要2分钟40秒即能分析完累积的日志,约9分钟装载完成。

日志分析的速度远远高于产生日志的速度。

完全能够满足用户IT系统的业务需求,即使是在业务高峰期,也不会造成日志累积。

目前DSG的用户中,广西移动每天的增量日志达到600G,realsync依然稳定运行。

n       每秒钟复制的操作数

在测试过程中,我们采用PL/SQL方式在源端产生1万,10万,100万条记录,以及进行1万,10万,100万的update,delete操作等。

按照统计结果,DSGRealSync达到平均18000条/s的复制速度。

完全能够满足单系统上用户IT系统的业务要求。

n       复制数据延迟

RealSync是一种异步准实时的复制技术,其数据延迟非常小。

数据延迟的周期可以设置,在生产系统中,数据延迟和源系统复制事物的多少,事物的处理方式有关,以及跟设置的log数据轮询周期有关。

在复制数据量正常的OLTP系统中,数据延迟一般在几秒钟。

如果每天产生30GB的日志量,在30Mb带宽的情况下,可确保数据的延迟在5秒钟左右。

n       CPU资源占用

DSGRealSync通过Oracle日志获得数据的变化信息,它独特的技术优势使得它对源系统的资源占用很小。

在生产系统中,实际对源系统的影响和源系统复制事物的多少,事物的处理方式有关。

在复制数据量正常的OLTP系统中,正常状态下对CPU资源的占用为<5%的CPU资源占用。

根据我们在河北地税的使用情况来看,在系统高峰期每2分钟产生100MB的日志量,而REALSYNC的日志分析资源占用仅为2%(4cpu,8Gram)。

n       源端的缓存空间

当灾备中心暂停或传输异常中断导致复制停止时,RealSync会将数据库的变化内容存储在源系统或目标系统的队列中,当系统恢复后,RealSync会自动识别复制环境,自动从断点处开始复制工作。

在上述过程中,主中心的业务不受任何影响。

数据的一致性不会破坏。

当复制环境停止的情况下,需要在源系统和目标系统上存储的空间和业务系统每天峰值的日志数有关。

根据每天平均产生25GB的日志计算,我们建议在源端给REALSYNC预留的缓存空间能够满足一天的缓存量:

按照1/3的比例计算并增加一定的富裕量,需予留10GB的缓存存储空间。

n       业务切换

RealSync是通过对OracleLog日志进行分析获取跟踪源系统的交易指令实时的将指令传输到目标端进行加载,且目标端数据库始终在OPEN状态,可实时在目标端进行查询和统计,所以当灾难发生时或在主机源端发生故障以后,可直接将生产端数据库切换到容灾端,目标端数据库不需要重新启动,确保目标端数据的可用性,并大大提高了RTO、RPO指标。

 

3.4系统实施概述

(一)系统安装

REALSYNC的安装点包括如下:

l       在每个系统的数据库服务器上(RAC环境下是安装在一台服务器上,一个服务器上有多个INSTANCE时,需要为每个INSTANCE安装一个RealsyncAgent),配置一个REALSYNCAGENT,启动一个agent端口;

l       在灾备中心的每个服务器上安装一个ORACLEAgent,但要为每个instance启动一个agent端口;

(二)首次全同步

首次全同步是此次项目中一个非常复杂的问题,因为如何将生产系统首次同步到查询中心是一个非常复杂的问题,也是本项目中的一个难题。

复制环境的建立,首先需要将生产系统中的已有数据初始化同步到目标系统上,同时记录各种系统状态和映射关系等。

因此如何快速、有效的建立复制的初始化环境是每个复制系统都非常关心的问题。

全同步是关键系统中一个非常复杂的问题,因为如何将生产系统首次同步到灾备中心是一个非常复杂的问题,也是本项目中的一个难题。

从目前的技术来看,能够实现首次全同步的方式有多种方案:

第一:

备份/恢复的方式

第二:

ORACLEEXPORT/IMPORT方式;

第三:

采用复制软件自带的首次初始化功能。

在传统办法中,数据首次同步过程大都采用Oracle的EXP/IMP工具,将源端数据库数据抽取出来,通过网络传输至目标端数据库进行加载。

或者是借助第三方的备份软件工具,将源端的数据进行备份,再通过磁带运输至目的地,将磁带数据恢复到目标数据库,从而达到首次数据同步的目的。

这种方式存在大量的问题:

(1)   性能低下:

通过Export/Import方式,最大的问题在于性能很慢,对于一个几十GB的数据库,进行一次export/import,则大约费时8-10小时以上。

(2)   完全需要手工干预:

数据的导出(Export),传输和装载(Import)等过程都需要手工干预和执行。

(3)   业务必需停止:

在执行export/im

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 医药卫生 > 基础医学

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2