(完整word版)OracleDataGuard容灾解决方案

(完整word版)OracleDataGuard容灾解决方案
(完整word版)OracleDataGuard容灾解决方案

Oracle DataGuard容灾解决方案

目录

一. 需求分析 (3)

二. 解决方案 (3)

拓扑架构 (3)

方案特点 (4)

方案优势 (4)

产品介绍 (5)

三. Oracle维保服务 (8)

四. 方案报价 (10)

一. 需求分析

用户现有两台服务器,windows2008平台,一台运行oracle 11g r2,一台运行用友NC 6.3。现在通过每天备份的方式保证安全。用户希望在他的另一个机房(裸光纤互联)中搭建容灾平台。

因此本方案针对以上现状,提出Oracle DataGuard容灾解决方案,这样主数据库在遇到极端状况时,可以及时切换到备库,保证业务的连续性。

二. 解决方案

拓扑架构

Dataguard可以实现远程数据容灾,利用该功能也可实现高可用性。

数据容灾是指建立一个异地的数据系统,该系统是本地关键应用数据的一个实时复制。在本地数据及整个应用系统出现灾难时,系统至少在或本地异地保存有一份可用的关键业务的数据,基于该功能,结合客户实际情况我方推荐使用其作为保证系统可靠运行的一种解决方案,由于两台机器的数据一致性以及低延迟,完全可以胜任,在主机出现故障时,切换至备机运行。

方案特点

?对现有的环境改动小,能最大限度的减少对现有应用系统的影响。

?能满足客户对海量数据的管理要求。

?可以实现远距离容灾,对网络要求低,低延时,快速业务切换。

?同步或异步日志传输;

?低成本的投入。

方案优势

灾难恢复和高可用性—Data Guard 提供了一个高效和全面的灾难恢复和高可用性解决方案。易于管理的转换和故障切换功能允许主数据库和备用数据库之间的角色转换,从而使主数据库因计划的和计划外的中断所导致的停机时间减到最少。

完善的数据保护—使用备用数据库,Data Guard 可保证即使遇到不可预见的灾难也不会丢失数据。备用数据库提供了防止数据损坏和用户错误的安全保护。主数据库上的存储器级物理损坏不会传播到备用数据库上。同样,导致主数据库永久损坏的逻辑损坏或用户错误也能够得到解决。最后,在将重做数据应用到备用数据库时会对其进行验证。

有效利用系统资源—备用数据库表使用从主数据库接收到的重做数据进行更新,并且可用于诸如备份操作、报表、合计和查询等其它任务,从而减少执行这些任务所必需的主数据库工作负载,节省宝贵的CPU 和I/O 周期。使用逻辑备用数据库,用户可以在模式中不从主数据库进行更新的表上执行数据处理操作。逻辑备用数据库可以在从主数据库中对表进行更新时保持打开,并可同时对表进行只读访问。最后,可以在维护的表上创建额外索引和物化视图,以获得更好的查询性能和适应特定的业务要求。

灵活的数据保护功能,从而在可用性与性能要求之间取得平衡—Oracle Data Guard 提供了最大保护、最高可用性和最高性能等模式,来帮助企业在系统性能要求和数据保护之间取得平衡。

自动间隔检测及其解决方案—如果主数据库与一个或更多个备用数据库之间的连接丢失(例如,由于网络问题),则在主数据库上生成的重做数据将无

法发送到那些备用数据库上。一旦重新建立连接,Data Guard 就自动检测丢失的存档日志序列(或间隔),并将必要的存档日志自动传输到备用数据库中。备用数据库将重新与主数据库同步,而无需管理员的任何手动干预。

简单的集中式管理—Data Guard Broker 使一个Data Guard 配置中的多个数据库间的管理和操作任务自动化。Broker 还监控单个Data Guard 配置内的所有系统。管理员可以使用Oracle Enterprise Manager 或Broker 自己专用的命令行界面(DGMGRL) 来利用这个集成的管理框架。

与Oracle 数据库集成—Oracle Data Guard 是作为Oracle 数据库(企业版)的一个完全集成的功能提供的,实现无缝集成。

产品介绍

Dataguard技术是ORACLE推荐的高可用性方案:

Oracle Data Guard 是管理、监控和自动化软件的基础构件,它创建、维护和监控一个或多个备用数据库,以保护企业数据结构不受故障、灾难、错误和崩溃的影响。

Data Guard使用备用数据库保持为与生产数据库在事物上一致的副本。这些备用数据库可能位于距生产数据中心数千英里的远程灾难恢复站点,或者可能位与同一城市、同一校园乃至同一建筑内。当生产数据库由于计划中断或以为中断而变得不可用时,Data Guard可以将任意备用数据库切换到生产角色,从而使与中断相关的停机时间减到最少,并防止任何数据丢失。

作为Oracle 数据库企业版的一个特性推出的Data Guard 能够与其他的Oracle 高可用性(HA) 解决方案(如真正应用集群(RAC) 和恢复管理器(RMAN))结合使用,以提供业内前所未有的高水平数据保护和数据可用性。

Data Guard结构组件

Data Guard是ORACLE数据库的一个选件,市面上很多产品是利用其做了一定包装后推出到市场,其实质仍然是利用了Data Guard的技术。利用Data Guard 的条件是:

?源ORACLE数据库和目标ORACLE数据库版本要一致

?操作系统平台要一致

即Data Guard不能实现跨平台的数据容灾,如果利用Data Guard需要首先进行数据整合,然后结合Oracle Rac实现真正的高可用性容灾。

Dataguar功能

Oracle Data Guard包括一个生产数据库,也称为主数据库,以及一个或多个备用数据库,这些备用数据库是与主数据库在事务上一致的副本。Data Guard利用重做数据保持这种事务一致性。当主数据库中发生事务时,则生成重做数据并将其写入本地重做日志文件中。通过Data Guard,还将重做数据传输到备用站点上,并应用到备用数据库中,从而使备用数据库与主数据库保持同步。Data Guard 允许管理员选择将重做数据同步还是异步地发送到备用站点上。

备用数据库的底层技术是Data Guard重做应用(物理备用数据库)和Data Guard SQL应用(逻辑备用数据库)。物理备用数据库在磁盘上拥有和主数据库逐块相同的数据库结构,并且使用Oracle介质恢复进行更新。逻辑备用数据库是一个独立数据库,它与主数据库包含相同的数据。它使用SQL语句进行更新,

其相对优势是能够并行用于恢复以及诸如报表、查询等其他任务。

Data Guard简化了主数据库和选定的备用数据库之间的转换和故障切换,从而减少了由计划停机和计划外故障所导致的总停机时间。

主数据库和备用数据库以及它们的各种交互可以使用SQL*Plus来进行管理。为了获得更简便的可管理性,Data Guard还提供了一个分布式管理框架(称为Data Guard Broker),它不但自动化了Data Guard配置的创建、维护和监控,并对这些操作进行统一管理。管理员可以使用Oracle Enterprise Manager或Broker 自己的专用命令行界面(DGMGRL)来利用Broker 的管理功能。

Oracle Data Guard为了灾难恢复和高可用性通过使用多个进程达到自动控制的目的。对于物理备用数据库而言,备用联机日志是可选的。逻辑备用数据库并不使用备用联机重做日志。

主节点上,日志传输服务主要使用如下几个进程来完成:

1、LGWR LGWR搜集事务日志,并且更新联机日志。在同步模式下,LGWR 直接将redo信息直接传送到备库中的RFS进程,主库在继续进行处理前需要等待备库的确认。在非同步情况下,也是直接将日志信息传递到备库的RFS进程,但是不等待备库的确认信息主库进程可以继续运行处理。

2、ARCH ARCHn或者是一个SQL session执行了一个归档操作,为了恢复的需要,创建了一个联机日志的拷贝。Archn进程可以在归档的同时,传递日志流到备库的RFS进程。该进程还用于前瞻性检测和解决备库的日志不连续问题(GAP)。

3、FAL Fetch archive log 只有物理备库才有该进程,FAL进程提供了一个client/server的机制,用来解决检测在主库产生的连续的归档日志,而在备库接受的归档日志不连续的问题。

备库节点上,日志应用进程主要使用如下的进程来完成:

1、RFS Rfs进程主要用来接受从主库传送过来的日志信息。对于物理备用数据库而言,RFS进程可以直接将日志写进备用重做日志,也可以直接将日志信息写到归档日志中。为了使用备库重做日志,我们必须创建他们,一般和主库的联机日志大小以及组一样。

2、ARCHn只对物理备库,Arch进程归档备库重做日志,这些日志以后将

被MPR进程应用到备库。

3、MRP Managed recovery process 该进程只针对物理备库。该进程应用归档日志到备库。如果我们使用SQL语句启用该进程ALTER DATABASE RECOVER MANAGED STANDBY DATABASE,那么前台进程将会做恢复。如果加上disconnect语句,那么恢复过程将在后台进程,发出该语句的进程可以继续做其他的事情。

4、LSP Logical standby process 只有逻辑备库才会有该进程。LSP进程控制着应用归档日志到逻辑备用数据库。

三. Oracle维保服务

故障级别划分

首先,我们按照Oracle数据库在生产出现问题时对应用系统的不同影响进行了故障级别的划分,针对不同的故障级别我们将提供合适的技术支持服务。

?1级故障(L1):Oracle数据库出现的告警或报错甚至瘫痪,使日常业务处理受到影响,远程支持无法立即解决,视为1级故障,对应一级故障

提供应急服务,4小时内提出解决方案,最快速度到达现场(适合的交

通工具)

?2级故障(L2):Oracle数据库出现的告警或报错,但日常业务仍可以正常进行,远程支持可以解决,视为2级故障。对应二级故障提供远程服

务,2小时内到达现场,该服务对应安装服务

?3级故障(L3):Oracle数据库出现的告警或报错,通过远程技术指导或电话指导可以快速解决,视为3级故障,此故障使用邮件或电话可以解

?4级故障(L4):生产系统目前正常运行,但为预防故障,需要定期进行检查,视为4级故障。

技术支持服务方式

我们将为维保签约客户成立技术支持小组,由Oracle认证工程师组成的专家小组将为客户提供全方位的维保服务。并针对客户的具体应用情况,为其分配

有Oracle资质的专员工程师,为客户提供一站式服务。具体服务内容如下:提供7*24小时电话技术咨询服务

客户在工作日(法定节假日除外)上班时间可以拨打热线服务电话,签约用户会有专门的工程师在非工作时间接受日常技术问题咨询。服务适用于所有级别故障处理。对客户提出的一般性问题进行技术咨询、指导。如遇客户新添加应用系统,我方帮助用户评定方案的可行性,同时顾问咨询服务可以帮助您找到利用该数据库平台的解决方案,以便把您的企业转变成信息驱动的企业。

提供邮件技术咨询服务

为客户提供技术服务邮箱,客户可以通过邮件方式将日常工作和学习中遇到的问题提交,我们技术专家将在接收到邮件24小时之内答复。此服务适用于所有级别故障处理。

即时信息服务

利用QQ、MSN、Yahoo Messenger等即时信息软件,为企业提供交互式的即时信息ORACLE技术支持服务,解决用户在使用ORACLE过程中遇到的问题。

提供专员工程师7*24小时(整个服务年度内)技术支持服务

专员工程师在签约后五个工作日内将对客户的Oracle具体情况做调研,以便更快、更准确地解决问题。客户可以在全天拨打专员工程师手机或通过网络与专员工程师联系,寻求技术支持。此服务适用于3级及3级以上故障处理。

定期巡检服务(四次/年度)

技术支持小组将派专员工程师定期对签约客户进行巡检服务,对客户进行现场指导、解答技术问题;对Oracle数据库的运行状态及环境进行监测,解决故障隐患。

提供认证工程师故障应急服务

客户遇到Oracle数据库的1级和2级故障,可申请故障应急服务。技术支持小组专家将在接到申请后30分钟内响应,对故障现象进行分析判断,并选派得力的工程师进行现场服务。

提供Oracle软件的升级支持服务

当客户需要对Oracle软件升级时,我们将无偿提供技术支持服务,但不负责提供各类升级包软件;如需现场安装调试,技术支持小组将派出认证工程师24

小时内到达现场。

提供Oracle数据库调整优化服务

客户在服务年度中根据应用系统运行情况结合巡检报告提出调优服务要求,我们将派遣有丰富经验的工程师出具调优计划,直接调整相应参数或提交用户由用户协调应用系统开发商进行语句的优化,用户批准后进行调整优化相关参数,以便系统高效运行。

提供现场工程师值守服务

客户在系统运行过程中,根据用户要求提供工程师现场值守,根据客户授权情况进行相应调整或上报给客户相关领导,经请示后进行处理。

远程DBA值守服务

客户在系统运行过程中,根据用户要求提供工程师远程值守,随时发现数据库系统运行状态,根据客户授权情况进行即时处理。

顾问式咨询服务

及时提供多种方式的顾问咨询,包括新上系统或者改造升级某个系统时,涉及数据库部分的方案评审,提供架构建议以及在应用系统升级及调整优化时对涉及数据库部分的内容进行评估,出具可行性报告供客户参考使用。

四. 方案报价

医院容灾

浪擎-陕西省中医院 1.概述 陕西省中医医院是一所以科研、教学为基础,以医疗为中心的三级甲等综合性中医医院,是国家药品临床研究基地之一,充分发挥中医药优势,结合现代医药科技成果、在诸多专科专病诊疗方面独具特色。目前开设病床380张,有临床医技科室30多个,全院在职职工665人,其中,高级中医药专家117名,博士3名,硕士24名,有国家级名老中医药专家5名,省级名老中医药专家11名;有突出贡献的专家7名,享受政府特殊津贴的专家18名,“三五人才”5人。 2.建设目标 1)业务系统服务器实时备份到备用服务器。 2)容灾系统对生产机(主服务器)不能有任何性能影响。必须保证该系统的正常运行。 3)为降低容灾成本,提高资源利用率主备服务器硬件规格或配置无需相同。 4)强调持久化服务能力,业务系统运行不允许中断。 5)强调数据的准确性,业务系统不允许丢失数据或出错。 6)需要可靠的容灾方案,保证数据的安全及提供快速的恢复能力。 3.选用部件 针对于上述需求说明,选用以下规格的部件: ?浪擎?镜像系统Oracle客户端代理 ?浪擎?镜像系统Oracle服务器端 ?浪擎?镜像系统WEB管理平台 4.应用说明 当HIS和LIS的服务器处于可用状态时,即能正常提供业务服务时,把HIS和LIS的主服务器的Oracle镜像代理连接至备用服务器的Oracle镜像服务器。当镜像代理检测到主存储数据变化后,将捕获变化的数据实时的复制到备用存储上。实现了实时的复制。具体部署如下图:

5.方案特色 1)备用端可查询 由于备用数据库处于打开运行状态,不同于冷容灾模式下容灾站点的数据库系统在进行数据复制是不可用的情况,因此备用数据库可以通过为其它系统提供数据查询或共享服务。 2)高性价比 对主备系统硬件一致性无要求,目标端无需购置昂贵的存储设备或光纤通信设备等,极大的降低系统投入成本,充分保护现有设备投资。 3)方便灵活 由于采用逻辑数据复制原理,镜像系统可采用一对一、多对一复制方式,应用方式非常灵活,并且大大减少投入成本。 4)高效率、低负载 数据复制引擎效率很高,同时保证了复制数据的精确性。在源数据库端,数据复制引擎严格地遵守读一致性模式。 5)基于Web的任务监控和配置管理 提供B/S图形化管理界面,复制任务状态和设置均可通过浏览器操作完成。 6)全方位的复制包含各种数据类型 系统支持数据库所有的数据类型、DML和DDL复制。在复制时,系统可选择性地在用户级、对象级、命令级排除(exclude)不需要复制的内容。 7)灾难恢复 系统可以容忍实例失败、系统失败和网络失败。 8)可选择性复制 当系统技术被用于某些目的(如报表系统)时,无需对所有的数据表信息进行复制,而只需要复制那些需要的表的信息,这样可以大大减少存储和网络带宽的成本。

系统容灾解决方案

系统容灾解决方案 容灾基本概念 容灾是一个范畴比较广泛的概念,广义上,我们可以把所有与业务连续性相关的内容都纳入容灾。容灾是一个系统工程,它包括支持用户业务的方方面面。而容灾对于IT而言,就是提供一个能防止用户业务系统遭受各种灾难影响及破坏的计算机系统。容灾还表现为一种未雨绸缪的主动性,而不是在灾难发生后的“亡羊补牢”。 从狭义的角度,我们平常所谈论的容灾是指:除了生产站点以外,用户另外建立的冗余站点,当灾难发生,生产站点受到破坏时,冗余站点可以接管用户正常的业务,达到业务不间断的目的。为了达到更高的可用性,许多用户甚至建立多个冗余站点。 容灾系统是指在相隔较远的异地,建立两套或多套功能相同的IT系统,互相之间可以进行健康状态监视和功能切换,当一处系统因意外(如火灾、地震等)停止工作时,整个应用系统可以切换到另一处,使得该系统功能可以继续正常工作。容灾技术是系统的高可用性技术的一个组成部分,容灾系统更加强调处理外界环境对系统的影响,特别是灾难性事件对整个IT节点的影响,提供节点级别的系统恢复功能。 要实现容灾,首先要了解哪些事件可以定义为灾难?典型的灾难事件是自然灾难,如火灾、洪水、地震、飓风、龙卷风、台风等;还有其它如原提供给业务运营所需的服务中断,出现设备故障、软件错误、网络中断和电力故障等等;此外,人为的因素往往也会酿成大祸,如操作员错误、破坏、植入有害代码和病毒袭击等。现阶段,由于信息技术正处在高速发展的阶段,很多生产流程和制度仍不完善,加之缺乏经验,这方面的损失屡见不鲜。 容灾的七个层次 等级1: 被定义为没有信息存储的需求,没有建立备援硬件平台的需求,也没有发展应急计划的需求,数据仅在本地进行备份恢复,没有数据送往异地。这种方式是成本最低的灾难恢复解决方案,但事实上这种恢复并没有真正达到灾难恢复的能力。 一种典型等级1方式就是采用本地磁带库自动备份方案,通过制定相关的备份策略,可以实现系统等级1备份。 等级2: 是一种为许多站点采用的备份标准方式。数据在完成写操作之后,将会送到远离本地的地方,同时具备有数据恢复的程序。在灾难发生后,在一台未启动的计算机上重新完成。系统和数据将被恢复并重新与网络相连。这种灾难恢复方案相对来说成本较低,但同时有难以管理的问题,即很难知道什么样的数据在什么样的地方。这种情况下,恢复时间长短依赖于何时硬件平台能够被提供和准备好。

医疗行业高可用及容灾解决方案

赛门铁克医疗行业高可用及容灾解决方案 一、行业背景 医疗行业的信息化建设经过了几个阶段的发展,HIS、LIS、RIS以及PACS等众多内容丰富、功能强大的应用软件逐渐成熟,成为医院信息技术的核心。随着时间的推移,这些环境的数据越来越多,数据的价值也越来越大,数据丢失或系统停机所造成的损失会造成越来越严重的后果,甚至变得不能接受。 另一方面,“9.11”事件爆发以后,“容灾”这个词汇逐渐成为人们谈论最多的焦点之一。而随后的一系列自然灾害的发生,更推动了IT系统容灾的需求。医疗行业也不例外,今天许多医院管理者和就医者都十分关心医院的IT系统的高可用性。 二、需求分析 医院信息系统是一个数据量大,数据类型复杂和事务并发多的实时系统,由于医院业务的特殊性,任何人为或自然因素所导致的应用或系统中断,都会造成医院巨大的经济和名誉损失及严重的法律后果。所以医院应用对IT系统的持续稳定运行提出了非常苛刻的要求。 在目前已经上线的医院IT环境中,绝大多数医院都采用了群集技术(也就是通常人们所说的“双机热备份”)来保证服务的持续运行或者在用户可以容忍的时间之内自动进行服务恢复。群集技术在应对服务器故障方面有着显而易见的效果,这一技术已经得到大多数医院用户的认可,并已经得到很大程度上的普及。 但是,随着群集技术运用的普及,很多用户发现群集本身也有一些非常明显的不足: 1、由于传统的群集解决方案多采用“2+1”的模式,即两台服务器连接到一台磁盘阵列。这种结构是为了在两台服务器之间共享数据。但是单台磁盘阵列往往就成了核心系统的一个单点故障点,一旦磁盘阵列发生故障,则整个系统将发生停机,作为7×24营业的医院来说,这种意外的停机是无法忍受的; 2、很多用户往往有这样的误解――既然我的系统已经是“双机热备份”了,那么,我的数据也不需要备份了。这种误解导致很多用户往往忽视了数据备份的重要性,结果整个系统的数据只有磁盘阵列中的一个拷贝,等到由于磁盘阵列发生故障或人为误操作导致数据丢失的时候,才发现悔之晚矣! 3、虽然关心容灾,但由于各种原因目前大多数国内的医院在建设IT系统时并没有过多地考虑。一旦发生火灾、地震等灾难性事故,整个系统将毁于一旦,数据将一去不复返,医院将遭受无法估量的巨大损失。

数据中心容灾备份方案

数据保护系统 医院备份、容灾及归档数据容灾 解决方案

1、前言 在医院信息化建设中,HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化HIS、LIS 和PACS 等系统是目前各个医院的核心业务系统,承担了 病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作,任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失,重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性,必须针对核心系统建立数据安全保护,做到“不停、不丢、可追查”,以确保核心业务系统得到全面保护。 随着电子病历新规在 4 月 1 日的正式施行,《电子病历应用管理规范(试行)》要求电子病历的书写、存储、使用和封存等均需按相关规定进行,根据规范,门(急)诊电子病历由医疗机构保管的,保存时间自患者最后一次就诊之日起不少于15 年;住院电子病历保存时间自患者最后一次出院之日起不少于30 年。

2、医院备份、容灾及归档解决方案 针对医疗卫生行业的特点和医院信息化建设中的主要应用,包括:HIS、PACS、RIS、LIS 等,本公司推出基于数据保护系统的多种解决方案,以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾 2.1 数据备份解决方案 针对于医院的HIS、PACS、LIS 等服务器进行数据备份时,数据保护系统的备份架构采用三层构架。 备份软件主控层(内置一体机):负责管理制定全域内的备份策略和跟踪客户端的备份,能够管理磁盘空间和磁带库库及光盘库,实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。 客户端层(数据库和操作系统客户端):其他应用服务器和数据库服务器安装备份软件标准客户端,通过这个客户端完成每台服务器的LAN 或LAN-FREE 备份工作。另外,为包含数据库的客户端安装数据库代理程序,从而保证数据库的在线热备份。

数据中心容灾备份方案完整版

数据中心容灾备份方案 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

数据保护系统 医院备份、容灾及归档数据容灾 解决方案 1、前言 在医院信息化建设中,HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化 HIS、LIS 和 PACS 等系统是目前各个医院的核心业务系统,承担了病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作,任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失,重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性,必须针对核心系统建立数据安全保护,做到“不停、不丢、可追查”,以确保核心业务系统得到全面保护。 随着电子病历新规在 4 月 1 日的正式施行,《电子病历应用管理规范(试行)》要求电子病历的书写、存储、使用和封存等均需按相关规定进行,根据规范,门(急)诊电子病历由医疗机构保管的,保存时间自患者最后一次就诊之日起不少于15 年;住院电子病历保存时间自患者最后一次出院之日起不少于 30 年。

2、医院备份、容灾及归档解决方案 针对医疗卫生行业的特点和医院信息化建设中的主要应用,包括:HIS、PACS、RIS、LIS 等,本公司推出基于数据保护系统的多种解决方案,以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾 数据备份解决方案 针对于医院的 HIS、PACS、LIS 等服务器进行数据备份时,数据保护系统的备份架构采用三层构架。 备份软件主控层(内置一体机):负责管理制定全域内的备份策略和跟踪客户端的备份,能够管理磁盘空间和磁带库库及光盘库,实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。 客户端层(数据库和操作系统客户端):其他应用服务器和数据库服务器安装备份软件标准客户端,通过这个客户端完成每台服务器的 LAN 或 LAN-FREE 备份工作。另外,为包含数据库的客户端安装数据库代理程序,从而保证数据库的在线热备份。 备份介质层(内置虚拟带库):主流备份介质有备份存储或虚拟带库等磁盘介质、物理磁带库等,一般建议将备份存储或虚拟带库等磁盘介质作为一级备份介质,用于近期的备份数据存放,将物理磁带库或者光盘库作为二级备份介质,用于长期的备份数据存放。

灾备中心数据容灾解决方案

财政灾备中心数据容灾解决方案 上海浪擎科技有限公司售前咨询部2012年8月25日

目录 1. 统一统筹,责任分明................................... 错误!未定义书签。2.浪擎灾备中心设计 (3) 2.1 灾备中心网络设计 (3) 2.2 两级监管的优势 (4) 2.3 横向扩展—支撑更多的用户 (5) 2.4 浪擎灾备软件的容灾优势 5 3.附件: (10) 2.4 附件1:部分案例介绍 (10) 1.统一统筹,分级管理

众所周知,集中建设备份中心的目的很明确,就是要本着少花钱多办事的原则,为全区域的各政府部门建立起一个共享的灾备平台,统一规划,节省投资。灾备中心共享化的确是一种符合政府信息化需求特点的建设趋势,即建成后将用一个灾备中心同时满足多个政府部门的数据备份保护需求。同时,灾备是一项长效的、专业的系统工程,只有专业的管理和服务才能将产品、技术、运维、演练有机结合,才能真正将灾备落到实处。然而各政府部门用户普遍“人少事多”,在规划和建设灾难备份和恢复系统时,经常面临着许多同样的困惑,例如对灾难恢复建设不熟悉、没经验,管理、技术、运维都面临调整、垂直行业无标准或标准混乱;投资保护和长远规划难于兼顾等等。因此,集中建立一个共享的灾备平台,实现专业人员集中管理,将灾备作为一种既统一管理、又可自主选择灾备级别的服务提供给各委办局使用,能从根本上避免“建而不管,备未无患”的尴尬,同时因为采用共享式灾备,可以极大的节约灾备中心的软硬件投入。 可见,建立集中的政府灾备中心,确实是一件有很大价值的好事儿。 但另一方面,随着部份地区的探索和实践,也发现政府异地灾备份中心与普遍意义的数据(灾备)中心在建设上存在着较大差异,建设和管理还存在很多难处。由区域政府牵头来建设灾备份中心,其核心难度在于:各条块、各委办局IT系统建设程度不一,数据存储形式复杂。因此如何搭建起一个同时满足各种不同复杂需求的统一灾备中心,并如何将灾备作为一种统一的、可选择的服务提供给各委办局使用,的确是一件非常“棘手”的任务。 结合多年的实际经验,浪擎科技对政府异地备份建设进行了一个小小的总结: 政府异地备份一般由灾备中心、委办局单位、备份系统、管理制度等组成。浪擎科技的建设经验证明,由于多家单位牵涉其中,在灾备系统建设之初就应理顺各方关系,协调好责任与义务。 上海浪擎信息科技有限公司是一家专注于存储、备份与容灾领域解决方案研发的公司,建设了多个大型的政府异地备份系统结合多年的实际经验,浪擎科技对政府异地备份建设进行了一个小小的总结: 政府异地备份一般由灾备中心、委办局单位、备份系统、管理制度等组成。浪擎科技的建设经验证明,由于多家单位牵涉其中,在灾备系统建设之初就应理顺各方关系,协调好责任与义务。 2.浪擎灾备中心设计 2.1灾备中心网络设计 目前政府电子政务网络由政务内网和政务外网构成。政府灾备可以选择电子政务网络作为灾备的基础网络,对于涉密的系统可经由政务内网传输;对于非涉密的系统可经由政务外网传输。数据量特别大的单位可架设专网接入灾备中心。

电信核心业务系统容灾解决方案

电信核心业务系统容灾解决方案 Oracle 技术产品咨询顾问高壮志2004/05/24 随着电信运营商多年的系统建设,其核心业务系统的高可用性越来越受到人们的关注。从整个系统的角度来看高可用性,包括主机、操作系统、数据库、应用、网络设备等许多方面。而这些系统的一个显著特点就是以数据为中心,因此对数据的保护是整个系统高可用性的核心体现。Oracle数据库作为电信运营商核心系统的主流数据库,针对企业用户的重要数据、重要业务高可用性的需求提出了建立在数据库级别的容灾方案-- Oracle Data Guard (数据卫士)。 为什么要使用Data Guard 电信行业现有系统在容灾方面基本上有两种做法。一是采用备份的方法,即定期地将数据备份到硬盘和磁带上。这种方法的缺陷是实时性较差,恢复时间较长;另外备份设备和生产系统一般都处于同一物理位置,不能满足异地容灾的要求。另一种做法就是硬件镜像的做法,这种做法在硬件投资上较大,对两点间网络带宽有较大要求。鱼和熊掌,可否兼得?下面让我们来看看Oracle Data Guard解决方案。 Oracle Data Guard Oracle9i Data Guard 维护了一个或多个与客户生产数据的同步备份。Oracle9i Data Guard配置包括一个松散连接的系统集合,由一个生产数据库和若干备用数据库组成,形成一个独立、易于管理的数据保护方案。现有运营商的核心业务系统的数据库在物理位置上往往位于省信息中心或计费中心的机房内,如果在同一城市有其它机房或利用其它城市机房部署同步备份的数据库,通过Oracle网络服务连接到一起,就可以构成一个很好的容灾解决方案。在修改主数据库时,对主数据库更改而生成的更新数据即发送到备用数据库,这些更改在备用数据库被重新应用。当生产数据库出现故障时,备用数据库可以继续提供服务。 图1提供了一个例子。 图1简单的双工作区配置

医院通用备份容灾方案模板

方案模板(适合政府、公安、医院等) XXXXX用户 信息系统数据安全方案建议书

目录 1. 需求说明 (5) 1.1. 项目背景 (5) 1.2. 实现目标 (6) 1.3. 环境概述 (7) 1.4. 待解决问题 (9) 2. 容灾概述 (10) 2.1. 概述 (10) 2.2. 灾难恢复和业务持续性的区别 (11) 2.3. 我们对灾难恢复的认识 (12) 2.4. 数据库容灾的几种实现方式 (14) 2.5. 有效的容灾方案应有特点 (15) 2.6. 容灾系统的设计指标 (16)

3. 方案设计 (19) 3.1. 设计概述 (19) 3.2. 设计思想 (19) 3.3. 设计原则 (22) 3.4. 方案说明 (24) 3.4.1. 方案综述 (24) 3.4.2. 数据库服务器容灾 (26) 3.4.3. 应用及虚拟机应用容灾 (29) 3.4.4. 本地备份 (36) 3.5. 容灾系统拓扑图 (39) 3.6. 配置清单 (41) 3.7. 方案总结 (41) 4. 实施方案 (42) 5. 产品概要 (42) 5.1. LanderVault 简述 (42) 5.2. 功能模块介绍 (44) 5.2.1. 统一集中管理平台:LanderVault (44) 5.2.2. Cluster高可用集群系统 (45) 5.2.3. Replicator网格化数据复制系统 (45)

5.2.4. Backup数据备份系统 (46) 5.2.5. Disaster应用级容灾系统 (46) 5.2.6. 备份一体化平台 (46) 5.2.7. 容灾一体化平台 (47) 5.2.8. 分布式存储 (48) 5.2.9. ORACLE逻辑复制AliveDB (49) 6. 公司简介 (50)

容灾备份-解决方案方法

容灾备份系统 2010-8-11 项目背景 随着计算机技术的快速发展,每个企业都在大量的使用计算机处理自己的核心数据,这些数据往往是企业生产经营必不可少的部分。依赖这些数据的计算机系统的停机往往会造成企业生产经营活动的停顿,给企业造成巨大的损失。所以,可以说,这些数据是企业的生命核心。

企业的IT 管理员为了保证生产经营活动的持续运行,不断的加强对系统和数据的保护,如使用基于双机的高可用技术,磁盘阵列系统的RAID 技术等。然而,人们依然无法 回避由于磁盘故障,人为失误,应用程序的逻辑错误,自然灾害等原因带来的系统停机或者 数据丢失。所以,数据备份作为数据保护的最后一道屏障,必不可少。 二、功能介绍 实时保护:连续捕获、实时备份数据变化,全过程保护数据安全。实现真正的持续性 数据保护(CDP),无需设置任何备份时间点,居国内外同类产品领先地位。 完善备份:同一软件可实现“数据库双机热备+接管”、“本地实时灾备” 、“异 地实时灾备” ,全方位保证数据库安全。 任意回退:可按任意操作步数或时间点进行数据回退。主数据库遭到破坏时,备份数 据库可将主数据库回退到损坏前最后时刻的状态,且能保证事件的完整性。 快速恢复:主数据库或表损坏,从站自动检测,提示回退的步数。恢复1个G数据 库在3-5分钟。 增量备份:只备份变化部分,在保障备份数据安全的同时减少备份的工作量。 错峰机制:在系统负荷极大时暂停备份以免系统瘫痪,当系统负荷下降时备份暂停 期间的数据,并重新开始实时备份。 低耗资源:对主数据库压力小,系统采用消息机制,只有灾数据库发生变化时才触 发,只传数据库的变化部分,不同于文件拷贝,和数据表的轮询。 操作简单:自主开发设计,着重考虑国内用户使用习惯,安装、设置非常简单。维护 方便:启动或连接中断后重连时,自动校验主从站数据,保证数据准确。 加密传输:底层通讯采用自主研发的通讯平台,所有数据都是用加密数据包进行数据 交换,充分保证数据安全。 高性价比:在各项性能领先的同时,价格远远优于国外软件。当选择不接管的热 容灾备份方式时,从站可采用低档Server 或高稳定性的PC(有足够的存储空间即 可),从而实现极低的总体成本。 通用性好:不对数据库中的应用做任何修改。与数据库中表的结构无关,且无任 何限制。对数据库备份完整:如TABLES(表)、DIAGRAM(S关系图)、VIEWS(视图)、USERS(用户)、ROLES、RULES等。

数据中心容灾备份方案

数据中心容灾备份方案 Company number:【WTUT-WT88Y-W8BBGB-BWYTT-19998】

数据保护系统 医院备份、容灾及归档数据容灾 解决方案 1、前言 在医院信息化建设中,HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化 HIS、LIS 和 PACS 等系统是目前各个医院的核心业务系统,承担了病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作,任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失,重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性,必须针对核心系统建立数据安全保护,做到“不停、不丢、可追查”,以确保核心业务系统得到全面保护。 随着电子病历新规在 4 月 1 日的正式施行,《电子病历应用管理规范(试行)》要求电子病历的书写、存储、使用和封存等均需按相关规定进行,根据规范,门(急)诊电子病历由医疗机构保管的,保存时间自患者最后一次就诊之日起不少于 15 年;住院电子病历保存时间自患者最后一次出院之日起不少于30 年。

2、医院备份、容灾及归档解决方案 针对医疗卫生行业的特点和医院信息化建设中的主要应用,包括:HIS、PACS、RIS、LIS 等,本公司推出基于数据保护系统的多种解决方案,以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾 数据备份解决方案 针对于医院的 HIS、PACS、LIS 等服务器进行数据备份时,数据保护系统的备份架构采用三层构架。 备份软件主控层(内置一体机):负责管理制定全域内的备份策略和跟踪客户端的备份,能够管理磁盘空间和磁带库库及光盘库,实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。 客户端层(数据库和操作系统客户端):其他应用服务器和数据库服务器安装备份软件标准客户端,通过这个客户端完成每台服务器的 LAN 或 LAN-FREE 备份工作。另外,为包含数据库的客户端安装数据库代理程序,从而保证数据库的在线热备份。

(完整版)存储级数据容灾方案

1.用户现状与需求 1.1.用户IT系统现状 用户现有系统包括数据库、应用、WEB、邮件等系统,虽然是双机架构,但是其稳定性和可靠性都没有达到核心系统应该具备的标准,而且直连的存储架构对于性能和管理型都有一定的局限性。 业务数据是企业业务的生命线,如何保护好计算机系统里存储的数据,保证系统稳定可靠地运行,并为业务系统提供快捷可靠的访问,是系统建设中最重要的问题之一。为了保护业务系统的关键业务数据,我们必须对这些数据进行有效的备份,并支持快速恢复。 通过备份的方式将文件、数据库等重要数据做一个副本,只能在本地建立数据保护。但因意外(如火灾、地震等)停止工作时,随之而来的损失更是不可估量,为避免类似风险的存在,就需要建立异地容灾系统,整个应用系统可以切换到另一处,使得该系统功能可以继续正常工作,保证业务稳定运行。 1.2.用户需求 1.2.1.建设目标 从容灾的级别来说,可以规划数据级容灾和应用级容灾,根据业务种类多,业务方式多样化的特点,仅建设一个数据级容灾是不够,容灾发生时,业务快速的恢复是容灾系统的一大需求。应用级容灾是建立在数据级容灾的基础上,在容灾切换时,除了切换核心的数据库数据外,还包含了IP地址切换(按客户需要选择),中间件服务,用户级业务。应用级容灾从流程上实现了全业务的连续性需求。 从我们的灾难系统建设经验出发,xxx有限公司可以考虑以下业务连续性计划目标:RPO(最大允许数据丢失时间):零数据丢失 RTO(最大允许宕机时间):30分钟

应用级容灾需求 1.2.2.需求分析 用户需要保障数据的长期安全可靠的,数据对于灾难的安全性和可恢复性:灾难切换时间要求灾难系统切换时间不超过30分钟,最好在10分钟内实现。 多种灾难切换方式提供自动灾难系统切换和手动灾难切换方式 计划内维护要求提供计划内维护支持能力,计划内维护切换时间不多于10分钟 数据丢失性要求原则上要求零数据丢失,可以依据情况进行调整 数据同步方式提供同步和异步两种方式 备份和灾难备份方式采用物理备份方式实现 物理部件失败要求支持部分磁盘,文件系统,主机,磁盘柜等各种物理部件失败导致的失败保护。 站点失败要求支持由于火灾,电力以及其他因素导致站点失败的数据保护。 逻辑失败要求支持由于数据块腐败导致的数据库无法启动,数据丢失等逻辑失败保护 人类错误失败要求支持由于人类误操作以及入侵等导致人类错误失败导致的数据保护或者恢复。 生产系统的性能影响要求生产系统性能影响不超过5% 生产系统可用性要求容灾系统不会降低生产系统可用性 网络链路分钟级别短暂故障要求不会对生产系统产生影响 网络链路小时级别长期故障要求不会对生产系统产生影响 网络链路密集的秒级别短暂故障要求不会对生产系统产生影响 网络链路容错支持网络链路的容错,可以利用网络的备份链路,比如多路网卡等灾难系统的硬件故障由于灾难系统硬件故障导致的灾难系统不可用不会对生产系统产生影响,比如网卡,磁盘以及控制卡等 灾难系统的软件故障由于灾难系统软件故障导致的灾难系统不可用不会对生产系统产生影响,比如灾难系统管理软件部件等 网络协议采用IP网络实现

某公司系统容灾解决建设方案

某公司软件容灾方案 1容灾软件 Symantec 的存储管理软件VERITAS Storage Foundation(简称SF)适用于企业存储管理的标准化平台,它不仅提供比操作系统本身逻辑卷管理器更加强大的在线卷管理功能,还提供许多高级的存储管理功能,其中包括用于容灾的数据镜像、数据复制等功能。是目前市场上广泛使用的容灾软件。 Symantec VERITAS Cluster Server(简称VCS)是一个用于容灾演练、应用级容灾的软件。它是在基本的HA软件功能的基础上发展而来的。 Veritas Storage Foundation 软件可以根据企业不同需求,提供不同的容灾解决方案,小到同城数据镜像,大到两地三中心数据容灾。SF与VCS紧密集成,可以提供完整的、从数据到应用、并自动实时演练的企业容灾方案。 铁道部高铁指挥实验系统采用了SF/VCS实现了容灾。

2数据同城镜像方式 利用灾备中信和主中心之间或者同机房内的裸光纤线路构成SAN环境,直接采用Storage Foundation在两个存储之间实现存储镜像。即所有数据都将同时写入两边的磁盘整列中。 如上图所示,主中心的服务器将应用的每个写i/o数据同时写入到两个中心的存储中。由于镜像的实现是依托于底层的Volume,所有数据存取的过程对于应用来说都是透明的。我们可以通过设臵Volume Manager的读取策略来指定主中心的服务器从本地的磁盘阵列上读取数据,加快数据查询的速度。 在这个场景中,数据发生物理错误的可能性基本上分为两种,生产中心的存储系统出现物理错误,如硬盘问题、光纤卡问题、光纤连接问题或光纤交换机问题等,另外一种就是整个数据中心出现故障。

医院灾备建设双活数据中心解决方案

XX 医院灾备建设灾备技术建议书 2016 年 1 月 5 日

1 项目概述 (5) 1.1 项目背 景 (5) 1.2 系统现状描 述 (5) 1.2.1 应用系统现 状 (5) 1.2.2 IT 系统现 状 (6) 1.3 需求分 析 (7) 1.3.1 行业发展要 求 (8) 1.3.2 灾备建设需 求 (9) 2 系统总体设计原则 (11) 3 容灾建设方案 (13) 3.1 业务系统特征及灾备需 求 (13) 3.1.1 HIS 门诊 类 (13) 3.1.2 HIS 住院 类 (13) 3.1.3 EMR 电子病历系 统 (14) 3.1.4 PACS 影像系 统 (14) 3.1.5 LIS 实验室检验系 统 (15) 3.1.6 医院各类经营管理系 统 (15) 3.1.7 业务需求分析汇 总 (16) 3.2 总体架构设 计 (17) 3.3 应用双活架构设 计 (18) 4 关键技术 (20) 4.1 存储层解决方 案 (20) 4.1.1 VIS 虚拟化技术.......................................................................错误!未定义书 签。 4.2 数据库层解决方 案 (25)

4.2.1 Oracle RAC 技术...................................................................... 错误!未定义 书签。 4.3 管理层解决方 案 (29) 4.3.1 灾备决策支持平台方 案 (30) 5 容灾相关产品及规格 (40) 5.1 Tecal RH5885 V3 机架服务 器 (40) 5.1.1 功能和价 值 (40) 5.1.2 规格参 数 (41) 5.2 OceanStor V3 系列存 储 (43) 5.2.1 功能和价 值 (43) 5.2.2 规格参 数 (44) 5.3 FusionSphere 云操作系 统 (46) 5.3.1 FusionCompute 虚拟 化 (46) 5.3.2 FusionManager 云管 理 (49) 5.4 SNS 系 列 (52) 5.4.1 功能和价 值 (52) 5.4.2 规格参 数 (53) 5.5 BIG-IP 本地流量管理器平 台 (58) 5.5.1 功能和价 值 (58) 5.5.2 规格参 数 (59) 5.6 OceanStor ReplicationDirector 管理软 件 (61)

存储级数据容灾方案

1.用户现状与需求 1.1.用户系统现状 用户现有系统包括数据库、应用、、邮件等系统,虽然是双机架构,但是其稳定性和可靠性都没有达到核心系统应该具备的标准,而且直连的存储架构对于性能和管理型都有一定的局限性。 业务数据是企业业务的生命线,如何保护好计算机系统里存储的数据,保证系统稳定可靠地运行,并为业务系统提供快捷可靠的访问,是系统建设中最重要的问题之一。为了保护业务系统的关键业务数据,我们必须对这些数据进行有效的备份,并支持快速恢复。 通过备份的方式将文件、数据库等重要数据做一个副本,只能在本地建立数据保护。但因意外(如火灾、地震等)停止工作时,随之而来的损失更是不可估量,为避免类似风险的存在,就需要建立异地容灾系统,整个应用系统可以切换到另一处,使得该系统功能可以继续正常工作,保证业务稳定运行。 1.2.用户需求 1.2.1.建设目标 从容灾的级别来说,可以规划数据级容灾和应用级容灾,根据业务种类多,业务方式多样化的特点,仅建设一个数据级容灾是不够,容灾发生时,业务快速的恢复是容灾系统的一大需求。应用级容灾是建立在数据级容灾的基础上,在容灾切换时,除了切换核心的数据库数据外,还包含了地址切换(按客户需要选择),中间件服务,用户级业务。应用级容灾从流程上实现了全业务的连续性需求。 从我们的灾难系统建设经验出发,有限公司可以考虑以下业务连续性计划目标:(最大允许数据丢失时间):零数据丢失 (最大允许宕机时间):30分钟 应用级容灾需求

1.2.2.需求分析 用户需要保障数据的长期安全可靠的,数据对于灾难的安全性和可恢复性:灾难切换时间要求灾难系统切换时间不超过30分钟,最好在10分钟内实现。 多种灾难切换方式提供自动灾难系统切换和手动灾难切换方式 计划内维护要求提供计划内维护支持能力,计划内维护切换时间不多于10分钟 数据丢失性要求原则上要求零数据丢失,可以依据情况进行调整 数据同步方式提供同步和异步两种方式 备份和灾难备份方式采用物理备份方式实现 物理部件失败要求支持部分磁盘,文件系统,主机,磁盘柜等各种物理部件失败导致的失败保护。 站点失败要求支持由于火灾,电力以及其他因素导致站点失败的数据保护。 逻辑失败要求支持由于数据块腐败导致的数据库无法启动,数据丢失等逻辑失败保护 人类错误失败要求支持由于人类误操作以及入侵等导致人类错误失败导致的数据保护或者恢复。 生产系统的性能影响要求生产系统性能影响不超过5% 生产系统可用性要求容灾系统不会降低生产系统可用性 网络链路分钟级别短暂故障要求不会对生产系统产生影响 网络链路小时级别长期故障要求不会对生产系统产生影响 网络链路密集的秒级别短暂故障要求不会对生产系统产生影响 网络链路容错支持网络链路的容错,可以利用网络的备份链路,比如多路网卡等灾难系统的硬件故障由于灾难系统硬件故障导致的灾难系统不可用不会对生产系统产生影响,比如网卡,磁盘以及控制卡等 灾难系统的软件故障由于灾难系统软件故障导致的灾难系统不可用不会对生产系统产生影响,比如灾难系统管理软件部件等 网络协议采用网络实现 网络带宽一般的百兆或者千兆带宽

IBM-数据级容灾解决方案.

1、基于软件的数据备份技术 在应用软件进行灾难备份的解决方案中,应从下面三个层次考虑:用户应用程序 客户机软件 数据库引擎 其中用户应用程序和客户机软件一般不包含关键数据,几乎所有数据都由数据库引擎管理并放置在数据库服务器中。在这三者之中,数据库中的数据保护最为重要。 一般情况下,用户应用程序和客户机软件只需要将其执行代码和参数配置文件做以备份,当灾难发生时,可以通过这些备份重新安装和配置用户应用程序和客户机软件。 对数据库的备份,如果采用硬件级灾难备份有两种方法:一是采用备份的方法,即定期地将数据备份到硬盘和磁带/磁带库上,这些磁带可以通过运输的方式运到远程,以防磁带在本地的灾难中发生毁坏。这种方法的缺陷是实时性较差,恢复时间较长;另一种做法就是硬件镜像的做法,这种做法在硬件的投资上较大,对两点间的网络带宽有较大的要求。那么,有没有一种两者兼顾的解决方案呢?数据库产品提供的数据库复制技术就是一种两者兼顾的灾难备份解决方案。在前面提到的灾难恢复方案的7个层次中属于第5或第6层次。 数据库复制技术在数据库级别的灾难备份解决方案中可以实现远程容灾。目前已有的产品有IBM DB2 HADR、IBM INFORMIX HDR以及ORACLE DATA GUARD。 IBM DB2 HADR是High Availability Disaster Recovery 的缩写,HADR 将HA(高可用性)和INFORMIX DR的技术紧密结合起来。INFORMIX HDR是High Availability Data Replication的缩写。

HDR的工作原理是通过将主数据库服务器(简称为A)的逻辑日志缓冲区复制到备份数据库服务器(简称为B),而且能在主数据库服务器操作失败时自动切换到备份数据库服务器。复制方式有同步方式和异步方式两种。我们将在下面详细介绍HDR的工作原理以及同步方式和异步方式。 正常状态下,主数据库服务器做数据库的读写操作,备份数据库服务器为只读方式。当主数据库服务器失败时,备份数据库服务器会自动接管主数据库服务器的事务处理。此时,备份数据库服务器作为主数据库服务器进行数据库的读写操作。当主数据库服务器被修复后,主数据库服务器作为新的备份数据库服务器。

智慧医院系统灾备项目解决方案

智慧医院系统灾备项目解决方案

目录 1 需求分析 (3) 1.1面临的挑战及需求 (3) 1.2建立高效灵活的数据容灾和备份解决方案 (3) 2 可行性分析 (4) 2.1建设目标 (4) 2.2建设思路 (4) 2.3 设计原则 (5) 3 系统建设方案 (5) 3.1 现状分析 (5) 3.2灾备建设 (6) 3.2.1统一存储架构设计 (6) 3.2.2双活数据中心存储设计 (7) 3.2.3 灾备中心整体架构拓扑图 (8) 3.2.4网络灾备拓扑图设计 (9) 3.2.5本地及远程数据备份系统MetroCluster设计 (9) 3.2.6 FlashCache与FlashPool加速区别与对比 (12) 3.2.7 虚拟化环境备份VMware VDP (14) 3.2.8 方案配置 (15) 4 方案优势 (17) 4.1统一存储架构 (17) 4.2读写的高性能 (18) 4.3安全性 (19) 4.3.1完善的应用连续性和数据安全保护解决方案 (19) 4.3.2数据的高可靠性 (21) 4.3.3 Oracle Dataguard 的优势 (21) 4.3.4备份数据一致性和100%可恢复特性 (24) 4.3.5对于个人文件数据的安全性 (26) 4.3.6重复数据删除 (26) 4.3.7国家标准《信息系统灾难恢复规范》最高等级要求 (27) 4.3.8灵活的多元化管理 (28) 5 未来规划 (28) 5.1横向和纵向的系统高扩展性 (28) 5.2重新规划与定义将退役设备 (29) 5.3对未来“云计算”数据中心的支持 (31) 6 厂商介绍 (32)

医院行业高可用及容灾解决方案

赛门铁克:医院行业高可用及容灾解决方案 发布日期:2006年6月5日作者:厂商供稿 一、行业背景 医疗行业的信息化建设经过了几个阶段的发展,HIS、LIS、RIS以及PACS等众多内容丰富、功能强大的应用软件逐渐成熟,成为医院信息技术的核心。随着时间的推移,这些环境的数据越来越多,数据的价值也越来越大,数据丢失或系统停机所造成的损失会造成越来越严重的后果,甚至变得不能接受。 另一方面,“9.11”事件爆发以后,“容灾”这个词汇逐渐成为人们谈论最多的焦点之一。而随后的一系列自然灾害的发生,更推动了IT系统容灾的需求。医疗行业也不例外,今天许多医院管理者和就医者都十分关心医院的IT系统的高可用性。 二、需求分析 医院信息系统是一个数据量大,数据类型复杂和事务并发多的实时系统,由于医院业务的特殊性,任何人为或自然因素所导致的应用或系统中断,都会造成医院巨大的经济和名誉损失及严重的法律后果。所以医院应用对IT系统的持续稳定运行提出了非常苛刻的要求。 在目前已经上线的医院IT环境中,绝大多数医院都采用了群集技术(也就是通常人们所说的“双机热备份”)来保证服务的持续运行或者在用户可以容忍的时间之内自动进行服务恢复。群集技术在应对服务器故障方面有着显而易见的效果,这一技术已经得到大多数医院用户的认可,并已经得到很大程度上的普及。 但是,随着群集技术运用的普及,很多用户发现群集本身也有一些非常明显的不足: 1、由于传统的群集解决方案多采用“2+1”的模式,即两台服务器连接到一台磁盘阵列。这种结构是为了在两台服务器之间共享数据。但是单台磁盘阵列往往就成了核心系统的一个单点故障点,一旦磁盘阵列发生故障,则整个系统将发生停机,作为7×24营业

医院行业实时容灾备份解决方案

UPM数据库保镖容灾备份系统 医疗行业解决方案 一、行业背景 21世纪的医院已经逐渐发展为现代化的综合性医院,为了实现医院管理的科学化、现代化、数字化,与国际、国内信息化建设的新技术接轨,适应现代化医院的医疗、科研、教育和管理的要求,现代化的医院所建立起的信息系统(HIS)主要以一体化的临床系统、检验系统、PACS系统等为基础,实现数据全面共享,共同形成全面的医院信息管理系统。庞大的系统必然产生海量数据,对于软件系统而言数据就是根本,任何操作、分析、结算等等都从数据库中提取。从某种意义上说,数据安全成为了现代医院信息系统安全的重中之重。 作为国内数据灾备业的先行军,北京和力记易科技有限公司拥有基于驱动层监控的国际领先的数据库容灾备份技术,针对医疗行业对数据安全的特殊要求研发了一整套适合医院客户实用的解决方案,并在广大的医院客户全体中得到了成功的推广和普及。本着“急客户之所急,忧客户之所忧”的原则,公司的系列解决方案都进行了人性化优化设计,使客户更容易掌握和操控,有备无患,高枕无忧。 二、产品功能介绍 UPM数据库保镖容灾备份系统是跨数据库(MSSQL、MYSQL、SYBASE、DB2、ORACLE)的专业数据库保护管理软件,对数据库保护做到实时、异地、回退、接管。 ﹡实时备份:是指在不停止数据库服务的情况下,对数据库进行自动监控,连续捕获和备份数据变化,实现对主站数据库的所有写操作实时、准确的备份下来。在软件第一次运行时,会对主数据库作一个全备份,此后主数据库有任何变化,软件会立即备份到从站上去,保证数据实时同步。

图1 ﹡数据回退:是指保证在主数据库损坏的情况下,备份的数据库可恢复到主站数据库损坏时的临界点,并支持数据库的回退操作,回退机制可满足数据业务的完整性,可避免因误操作等引起的数据丢失,回退操作可按回退步数、时间点回退两种方式。 图2 ﹡接管:即接管IP,例如主数据库服务器突然宕机,通过此产品可以使数据库备份机迅速接管主站的IP以及对外的数据库服务,使服务器能够达到不间断运行,真正保证系统的高可用性。接管必须避免软件的自动接管模式下可能发生的误接管。采用“智能报警+人工干预模式”,当主数据服务器宕机以后,备份服务器从站会报警并接管弹出确认提示,管理人员可以根据具体情况采取相应措施。 图3 ﹡异地备份:实现数据库异地灾备,即可以在局域网或广域网内的任一机器上,对主站上装有数据库的机器进行备份,这样即使遇到灾难情况,也能通过局域网或者广域网上的备份进行及时的恢复。

数据库容灾、复制解决方案全分析(绝对精品)

数据库容灾、复制解决方案全分析(绝对精品) 目前,针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案: (1)基于存储层的容灾复制方案 这种技术的复制机制是通过基于SAN的存储局域网进行复制,复制针对每个IO进行,复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的系统来说有很大的优势(每天日志量在60G以上),但是对主机、操作系统、数据库版本等要求一致,且对络环境的要求比较高。 目标系统不需要有主机,只要有存储设备就可以,如果需要目标系统可读,需要额外的配置和设备,比较麻烦。 (2)基于逻辑卷的容灾复制方案 这种技术的机制是通过基于TCP/IP的网络环境进行复制,由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似,也可以选择同步或异步两种方式,对主机的软、硬件环境的一致性要求也比较高,对大数据量的应用比较有优势。其目标系统如果要实现可读,需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统,或者是应用系统的容灾复制。 我一直有一个困惑,存储级的复制,假如是同步的,能保证数据库所有文件一致吗?或者说是保证在异常发生的那一刻有足够的缓冲来保障? 也就是说,复制的时候起文件写入顺序和oracle的顺序一致吗?如果不一致就可能有问题,那么是通过什么机制来实现的呢? 上次一个存储厂商来讲产品,我问技术工程师这个问题,没有能给出答案 我对存储级的复制没有深入的研究过,主要是我自己的一些理解,你们帮我看一下吧…… 我觉得基于存储的复制应该是捕捉原系统存储上的每一个变化,而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果,所以在任意时刻,如果原系统的文件是一致的,那么目标端也应该是一致的,如果原系统没有一致,那目标端也会一样的。形象一点说它的原理可能有点像raid 0,就是说它的写入顺序应该和原系统是一样的。不知道我的理解对不对。另外,在发生故障的那一刻,如果是类似断电的情况,那么肯定会有缓存中数据的损失,也不能100%保证数据文件的一致。一般来说是用这种方式做oracle的容灾备份,在发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启动的(这是我接触过的很多这方面的技术人员的一种说法,我没有实际测试过)。我在一个移动运营商那里看到过实际的情况,他们的数据库没有归档,虽然使用了存储级的备份,但是白天却是不做同步的,只有在晚上再将存储同步,到第二天早上,再把存储的同步断掉,然后由另外一台主机来启动目标端存储上的数据库,而且基本上是有1/3的机会目标端数据库是起不来的,需要重新同步。 所以我觉得如果不是数据量大的惊人,其他方式没办法做到同步,或者要同时对数据库和应用进行容灾,存储级的方案是没有什么优势的,尤其是它对网络的环境要求是非常高的,在异地环境中几乎不可能实现。

相关文档
最新文档