当前位置:文档之家› AIX 的存储高可用和容灾解决方案实现

AIX 的存储高可用和容灾解决方案实现

AIX 的存储高可用和容灾解决方案实现

本文介绍如何结合使用 AIX LVM Mirror 和 DS8000 Metro Mirror 技术,在存储架构层

面实现存储高可用的同时满足企业同城容灾需求。本文同时就该方法最受人关注的容灾切换部分,分别就计划内和计划外两种场景进行详细讨论,并结合实验,充分论证了该方案的可行性。

基本技术介绍

AIX LVM Mirror 本地存储高可用解决方案介绍

Logical Volume Manager(LVM)是AIX 上用于逻辑卷管理的软件。LVM 本身提供Logical Volume (LV)数据在多个Physical Volume (PV)之间做数据镜像的功能,以达到存储的本地高可用性。在LVM Mirror 方案中写I/O 与底层设备交互如下图所示。

图 1. LVM Mirror 方案架构

当服务器发出写I/O 时,该I/O 在Parallel 模式下会同时并行发送到两台存储设备上。如上

图中Step 1, Step 2 和Step 1’, Step 2’。只有当Step 2 和Step 2’都完成时,一个写I/O 才会被服务器认为完成。

在该解决方案中,当底层任一存储,即PV,出现故障时,LVM 会自动将停止该PV 上所有的I/O 活动,并将相应读写切换到剩下的正常PV 上。整个切换过程在LVM 层完成,所有LV 在故障切换过程中状态保持在线,对应用层透明。切换时间最低在15 秒左右,甚至更短。

同城容灾解决方案介绍

DS8000 Metro Mirror (MM)技术是一种满足Recovery Point Object (RPO)为0 的存储级同城容灾解决方案。该方案中,数据通过存储底层的I/O 同步复制到容灾站点来达到相应的容灾目的。在DS8000 MM 方案中写I/O 与不同站点间DS8000 存储交互如下图所示。

图 2. DS8000 MM 方案架构

当服务器发出写I/O 时,首先该写I/O 首先放往在生产站点主存储设备上;其次该写I/O 由生产站点主存储发往灾备站点备存储;接着备存储发回写I/O 完成信息;最后主存储向服务端发送写I/O 完成信息。整个过程中,每个写I/O 保证会在生产和容灾站点间同步完成。

在该解决方案中,当生产站点发生灾难时,会触发站点切换场景,即生产站点所有设备宕机,灾备站点服务器和存储在容灾端被启用并提供服务。由于容灾端存储的数据是通过同步复制技术产生,数据与生产保持一致,从而保证了RPO 为0。值得注意的时DS8000 MM 该方案本身不提供生产站点的本地存储高可用保证。当本地存储发生故障且无法恢复时,最终需要将生产切换到容灾站点。整个过程一般为几个小时或更高。

AIX LVM Mirror 结合 DS8000 Metro Mirror 解决方案介绍

AIX LVM Mirror 结合DS8000 Metro Mirror 解决方案是一种融合两种方案优点的存储高可用加容灾解决方案。该解决方案的基本架构图如下图所示。

图 3. AIX LVM Mirror 结合DS8000 Metro Mirror 架构

AIX LVM Mirror 结合DS8000 Metro Mirror 解决方案其优点是显而易见的:其为企业基础架构提供本地存储高可用保护的同时,也提供了存储级同城容灾的能力。

但是在本方案中,由于生产端服务器的AIX LVM 的LV Copy 存在两份,而容灾端只有一份,因此在容灾端的单份Copy 对容灾切换的影响成为客户主要关注点,主要有以下几点:

容灾切换时影响:容灾端应用在单份Copy 情况下其LVM VG 和应用是否能正常拉起,以及相应RTO 影响。

生产回切时影响:生产端LVM Mirror 能否正常重新同步,及其对生产的性能影响。

整个操作流程复杂度:复杂度是否可控,是否会对运维团队带来额外负担。对于以上问题我们将分计划内和计划外两种切换场景在第二章节进行详细讨论。AIX LVM Mirror 结合 DS8000 Metro Mirror 容灾切换和恢复

步骤

一般容灾切换场景可分为计划内和计划外两种,以下章节分别就该两种场景进行讨论。所有讨论均基于实际测试结果,测试环境如下:

硬件为Power 570,4 核CPU,16G 内存。

操作系统AIX 6100-05 + PowerHA 6.1.0.9,双机配置为Active-Standby 方式。

应用为Oracle 10g。(这里以Oracle 应用为例,本方案也适用于其他应用场景。)

整个测试数据容量大小约为1 TB。

计划内切换和恢复步骤

计划内切换特点在于容灾站点切换以业务验证为主,容灾端应用运行时间短,期间AIX LVM 和存储不会做变更。因此在此短时间期间AIX LVM 可以以非健康状态运行。针对其特点,设计LVM Mirror + DS8000 MetroMirror 的存储架构切换流程如下图。

图 4. 计划内切换流程

点击查看大图

步骤一,容灾切换:

停止生产端应用和卸载相关文件系统。

在生产端应用服务器执行varyoffvg 和exportvg 操作。

将DS8000 MetroMirror Failover 到容灾端。

在容灾端服务器通过importvg –f 方式导入VG 配置信息,varyonvg。注意,importvg 增加-f 参数将保证vg 即使在单份copy 不存在的情况下也会被导入。

在容灾端启动应用。

步骤二,数据回迁:

将DS8000 MetroMirror 配置从容灾端failback 到生产端,该过程不影响容灾端应用运行。经过此步骤,生产端的两台DS8000 数据将不一致。

步骤三,生产恢复:

停止容灾端应用和卸载相关文件系统。

在容灾端应用服务器执行varyoffvg 和exportvg 操作。

将DS8000 MetroMirror Failover 到生产端。

在生产端应用服务器执行importvg 和varyonvg -n 操作。注意,varyonvg 增加-n 参数将保证vg 在两份copy 不一致的情况下不会被自动同步,而以最新copy 为准。

在生产端启动应用。经过此步骤,生产应用正常启动,但是两份DS8000 的LV Copy 还处于不一致阶段,数据还未进行同步。

步骤四,结束:

在选取适当时间段,如业务不繁忙的时间,执行syncvg 操作,将两份LV Copy 进行同步。

至此,计划内容灾切换演练结束,生产端应用恢复正常。

计划内切换流程主要关注点讨论

以下对本方案和常规DS8000 MetroMirror 非LVM Mirror 容灾方案就计划内切换流程作三方面对比。

容灾切换时RTO 影响和其他影响。

在容灾端进行切换的时候,相对普通DS8000 MetroMirror 方案,由于生产端采用了LVM Mirror 的方式,在容灾端少了一组LV Copy,因此在容灾端服务器需要通过importvg –f 方式在容灾端导入vg 信息。相比直接importvg 方式,经过实测,总计1T 共 4 个VG 导入过程正常,时间并未有明显增加,耗时仅增加约2%不到,RTO 影响几乎可以忽略不计。随后应用能正常启动无异常。

生产回切时RTO 影响、性能和其他影响。

当应用在生产端进行回切时,相对普通DS8000 MetroMirror 方案,由于生产端的两份LVM 的LV Copy 在回切后数据不一致,需要有一个数据同步过程。由于数据同步期间性能会对生产应用造成一定影响,因此在恢复过程中,生产端LVM 采用varyonvg –n 的方式拉起VG,以最快速度挂载VG,正常启动应用,且避免数据提前同步。在应用正常运行后,挑选合适阶段设置合适的同步线程数目再进行数据同步。因此整个恢复过程中,比对普通非LVM Mirror 方式,RTO 无影响,性能影响相对可控。

另外LVM Mirror 重新同步的方式Physical Partition(PP)级别的增量同步方式进行同步,因此同步数据量较少,具体大小取决于应用特征和数据规模。在本例中1T 总容量的的重新同步的数据量约占1/3。采用双线程同步,同步速率约200MB 左右,同步时间约半小时。

整个操作流程复杂度。

在整个流程中,唯一增加的复杂度在于在生产回切时,需要重新对LVM Mirror 的两份数据进行重新同步。在实际操作中,使用syncvg 对整个VG 进行同步。该过程可通过设定同步线程数来平衡同步速率和对生产的性能影响,操作相对简单直接。

计划外切换和恢复步骤

计划外切换特点在于生产站点不可用,容灾端应用运行时间可能会较长,期间AIX LVM 和存储有可能做变更。因此在此长时间期间AIX LVM 须以健康状态运行。针对其特点,设计其切换流程如下图。

图 5. 计划外切换流程

点击查看大图

步骤一,容灾切换:

直接将DS8000 MetroMirror Failover 到容灾端。

在容灾端服务器通过importvg –f 方式导入VG 配置信息,varyonvg。注意,importvg 增加-f 参数将保证vg 即使在单份copy 不存在的情况下也会被导入。

在容灾端启动应用。

步骤二,在线删除单份不存在的copy:

使用rmlvcopy 命令将不存在的copy 在线删除。

使用reducevg 命令将不存在的pv 通过制定pv id 的方式在线删除。经过该步骤后,LVM Mirror 被拆除,整个LVM 恢复单份copy 正常状态,容灾端应用存储可进行常规的变更。

步骤三,数据回迁:

在生产站点恢复后,将DS8000 MetroMirror 配置从容灾端failback 到生产端,该过程不影响容灾端应用运行。

步骤四,生产恢复:

停止容灾端应用和卸载相关文件系统。

在容灾端应用服务器执行varyoffvg 和exportvg 操作。

将DS8000 MetroMirror Failover 到生产端。

在生产端应用服务器执行importvg 和varyonvgn 操作。

在生产端启动应用,经过此步骤,生产应用正常启动,但是只有单份LV Copy,本地还不具备存储高可用能力。

步骤五,结束:

在选取适当时间段,如业务不繁忙的时间,重新执行mklvcopy 和syncvg 操作,实施LVM Mirror。

至此,计划外容灾切换演练结束,生产端应用恢复正常。

计划外切换流程主要关注点讨论

以下对本方案和常规DS8000 MetroMirror 非LVM Mirror 容灾方案就计划外切换流程作三方面对比。

容灾切换时RTO 影响和其他影响。

计划内切换流程和计划外切换流程对RTO 影响相同,且亦能保证应用正常启动。唯一不同在于需要额外使用rmlvcopy 和reducevg 命令将多余的不存在的lv copy 删除,保证系统正常长时间运行。在本例中整个过程操作不到半小时完成,且此过程对生产透明,亦可在线运行,因此影响很低。

生产回切时RTO 影响、性能和其他影响。

计划外的生产回切其实和常规DS8000 MetroMirror 非LVM Mirror 容灾方案计划外回切相同,因此无RTO 影响和性能影响。但是为了恢复到本地存储高可用状态,需要重新建立LVM Mirror 关系,因此在这里多了重新实施LVM Mirror 的过程。整个过程长短与应用规模有关系。在本例中1TB 的数据量采用双线程同步速率大约200MB 左右,总计后台同步时间约一个半小时,加上实际操作时间总计约两个半小时左右。

整个操作流程复杂度。

在整个流程中,增加的复杂度主要在于切换时在容灾端需要在线删除不存在的lv copy,在生产回切后,需要重新再次实施LVM Mirror。这些操作虽然相对比较复杂,但在理论和实际实验中都能对应用做到透明,在性能方面通过合理规划都能将影响降到最低。

结论

AIX LVM Mirror 和DS8000 Metro Mirror 分别是业界内成熟的技术。通过实践证明,其两者结合可以充分结合组成一种整体的存储高可用和容灾解决方案。该方案有效为客户消除了本地存储单点故障和带来了同城容灾能力的同时,在日常运维,特别是站点切换流程中,使增加的运维成本相对可控。

请注意,本文中的方案并不一定适用于您的IT 环境或问题。具体情况请经过实际测试或咨询当地IBM IT 专家进行论证。

Oracle数据库高可用解决方案


甲骨文最高可用性架构 骨 最高 用性架构 Maximum Availability Architecture

议程表
? ? ? ? ? 甲骨文简介 高可用性介绍 传 高 用性分析 传统高可用性分析 甲骨文高可用性方案介绍(MAA) 客户成功案例分享
2

Oracle公司概揽
总揽
? ? ? ? ? ? 从08财年收入$22.4B,11财年收入35.6B 在40多项产品或市场领域占据业界第一 320,000客户跨越145国家 10W员工规模 (1 in i 3 joined j i df from acquisition) i iti ) Oracle在线社区上有超过五百万开发者 34年从业经验
革新和创新
? 超过3,000 3 000个产品,拥有 个产品 拥有2,000 2 000多个专利 ? 09财年投入$3B 研发和测试资金 ? 7,500 售后支持人员, 支持27国语言
3

今天的甲骨文公司
? 全球最大的企业软件供应商 ? 数据库市场占有率第一 ? 中间件市场占有率第一 ? 应用软件市场占有率第一 ? 服务器市场占有率第三 ? 开源产品的领军者 ? 虚拟化产品的竞争者 ? 云计算方案供应商
FAST?=?FusionMiddleware Applications System Tech
4

议程表
? ? ? ? ? 甲骨文简介 高可用性介绍 传 高 用性分析 传统高可用性分析 甲骨文高可用性方案介绍(MAA) 客户成功案例分享
5

高可用性集群解决方案设计HA

1.业务连续 1.1.共享存储集群 业务系统运营时,服务器、网络、应用等故障将导致业务系统无常对外提供业务,造成业务中断,将会给企业带来无法估量的损失。针对业务系统面临的运营风险,Rose提供了基于共享存储的高可用解决方案,当服务器、网络、应用发生故障时,Rose可以自动快速将业务系统切换到集群备机运行,保证整个业务系统的对外正常服务,为业务系统提供7x24连续运营的强大保障。 1.1.1.适用场景 基于共享磁盘阵列的高可用集群,以保障业务系统连续运营 硬件结构:2台主机、1台磁盘阵列

主机 备机心跳 磁盘阵列 局域网 1.1. 2.案例分析 某证券公司案例 客户需求分析 某证券公司在全国100多个城市和地区共设有40多个分公司、100多个营业部。经营围涵盖:证券经纪,证券投资咨询,与证券交易、证券投资活动有关的财务顾问,证券承销与保荐,证券自营,证券资产管理,融资融券,证券投资基金代销,金融产品代销,为期货公司提供中间介绍业务,证券投资基金托管,股票期权做市。 该证券公司的系统承担着企业的部沟通、关键信息的传达等重要角色,随着企业的业务发展,系统的压力越来越重。由于服务器为单机运行,如果发生意外宕机,将会给企业的日常工作带来不便,甚至

给企业带来重大损失。因此,急需对服务器实现高可用保护,保障服务器的7×24小时连续运营。 解决方案 经过实际的需求调研,结合客户实际应用环境,推荐采用共享存储的热备集群方案。部署热备集群前的单机环境:业务系统,后台数据库为MySQL,操作系统为RedHat6,数据存储于磁盘阵列。 在单机单柜的基础上,增加1台备用主机,即可构建基于共享存储的热备集群。增加1台物理服务器作为服务器的备机,并在备机部署系统,通过Rose共享存储热备集群产品,实现对应用的高可用保护。如主机上运行的系统出现异常故障导致宕机,比如应用服务异常、硬件设备故障,Rose将实时监测该故障,并自动将系统切换至备用主机,以保障系统的连续运营。

高可用软件系列方案之二(存储高可用)讲解

高可用方案之二 高可用中的存储容灾方案 北京市科瑞讯科技发展股份有限公司

企业和事业单位的运转越来越依赖于计算机系统,如果一旦这个数据处理中心无法正常运转,就会造成业务停顿,导致不可挽回的损失。 随着信息时代的到来,关键数据的安全、持续可用问题直接关系到企业的生存和发展。用户对于保证数据的安全、持续可用的方案需求也变得多元化、复杂化,单一的解决方案已经逐渐不能满足用户的实际需求。 中金富捷凭借其丰富的研发经验,为您提供高可用性系列产品和优质的服务,推出了中金富捷高可用存储容灾解决方案,目的在于保证数据永不丢失和系统永不停顿,彻底解决传统高可用系统中存储设备单点故障的风险。 而采用中金富捷科技有限公司硬盘虚拟化产品SyMirror,可以最大限度的保护用户的数据信息,将用户的不同的存储设备进行同步复制,同时虚拟存储系统提供用户透明化的存取访问,任何一台存储设备的故障都会在SyMirror软件的检测下迅速切换到备用存储设备继续使用。而故障的存储设备修好后,重新加入SyMirror系统后,SyMirror会自动将增量数据同步到加入的存储设备。 具有国际领先技术的中金富捷SyMirror软件,具有以几个特点: 1、数据实时同步功能,确保两台存储设备的数据在任保时候保持一致。 2、透明化的数据存取功能,任何一台存储设备的损坏都不影响用户使用存储设备。 3、虚拟存储中的任何一个真实的存储设备都可以在任保时候轻松离线工作。 4、智能增量数据实别功能,确保加入虚拟系统中的存储设备进行快速增量同步。 5、存储设备之间的容灾切换时间小于1秒钟,对用户存取数据几乎无任何影响。 6、同PlusWell HA软件系统紧密配合,随动切换。实现真正意义的高可用冗余存储方 案。 北京中金富捷科技有限公司的高可用存储容灾方案结合了PlusWell HA高可用软件的高可用性及PlusWell SyMirror虚拟存储软件的透明化特点,结合二者之优势为客户提供了一套没有单点故障的高可用存储容灾方案。 一:方案特点 1、传统高可用解决方案(双机热备): 主要以一台共享的存储设备提供数据共享存储区域,两台或两台以上的服务器提供主备两种状态,当主机故障时,备机接管主机工作。实现业务的可持续性工作。其工作原理如下:

emc存储容灾技术解决方案

EMC VNX5400 存储容灾技术解决方案 2017年8月 易安信电脑系统(中国)有限公司 .1

一、需求分析 随着各行业数字化进程的推进,数据逐渐成为企事业单位的运营核心,用户对承载数据的存储系统的稳定性要求也越来越高。虽然不少存储厂商能够向用户提供稳定性极高的存储设备,但还是无法防止各种自然灾难对生产系统造成不可恢复的毁坏。为了保证数据存取的持续性、可恢复性和高可用性,远程容灾解决方案应运而生,而远程复制技术则是远程容灾方案中的关键技术之一。 远程复制技术是指通过建立远程容灾中心,将生产中心数据实时或分批次地复制到容灾中心。正常情况下,系统的各种应用运行在生产中心的计算机系统上,数据同时存放在生产中心和容灾中心的存储系统中。当生产中心由于断电、火灾甚至地震等灾难无法工作时,则立即采取一系列相关措施,将网络、数据线路切换至容灾中心,并且利用容灾中心已经搭建的计算机系统重新启动应用系统。 容灾系统最重要的目标就是保证容灾切换时间满足业务连续性要求,同时尽可能保持生产中心和容灾中心数据的连续性和完整性,而如何解决生产中心到容灾中心的数据复制和恢复则是容灾备份方案的核心内容。 本方案采用EMC MirrorView 复制软件基于磁盘阵列(VNX5300-VNX5400)的数据复制技术。它是由磁盘阵列自身实现数据的远程复制和同步,即磁盘阵列将对本系统中的存储器写I/O操作复制到远端的存储系统中并执行,保证生产数据和备份数据的一致性。由于这种方式下数据复制软件运行在磁盘阵列内,因此较容易实现生产中心和容灾容灾中心的生产数据和应用数据或目录 .2

的实时拷贝维护能力,且一般很少影响生产中心主机系统的性能。如果在容灾中心具备了实时生产数据、备用主机和网络环境,那么就可以当灾难发生后及时开始业务系统的恢复。 .3

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

数据中心容灾备份方案 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 备份工作。另外,为包含数据库的客户端安装数据库代理程序,从而保证数据库的在线热备份。 备份介质层(内置虚拟带库):主流备份介质有备份存储或虚拟带库等磁盘介质、物理磁带库等,一般建议将备份存储或虚拟带库等磁盘介质作为一级备份介质,用于近期的备份数据存放,将物理磁带库或者光盘库作为二级备份介质,用于长期的备份数据存放。

存储高可用解决方案

方 案 建 议 书 (XXX容灾方案建议)

目录 第1章XXXX容灾方案参考 (1) 1.1 系统现状 (1) 1.2 容灾需求分析 (1) 1.3 容灾参考方案 (2) 1.3.1 总体架构规划 (2) 1.3.2 V7000 外部存储虚拟化功能说明 (2) 1.3.3 V7000 VDM(虚拟磁盘镜像)功能说明 (3) 1.3.4 后期存储扩展建议 (4) 1.4 系统配置参考 (4) 第2章V7000存储设备介绍 (6) 2.1 IBM V7000存储系统概述 (6) 2.2 通过IBM S YSTEM S TORAGE E ASY T IER增强访问能力 (6) 2.3 通过精简调配来优化效率 (7) 2.4 动态迁移避免系统中断运行 (7) 2.5 通过复制服务来保护数据 (8) 2.6 管理工具与IBM S YSTEMS D IRECTOR相集成 (9) 2.7 高性能SSD支持 (10) 2.8 外部存储系统虚拟化 (10) 第3章存储高可用技术建议 (11) 3.1 存储高可用性的内容 (11) 3.2 存储高可用性方案的主要实现方式 (13) 3.2.1 方式一:磁盘设备间数据镜像( 如LVM Mirror ) (14) 3.2.2 方式二:磁盘设备间数据复制(如PPRC或ERM) (18) 3.2.3 方式三:采用SVC或V7000或V7000实现逻辑卷镜像 (20) 3.2.4 三种HA方式的比较 (21)

第1章XXXX容灾方案参考 1.1系统现状 XXXX现有IT系统的现状大致如下图所示。采用IBM P550服务器作为数据库服务器,采用DS3400存储设备作为主存储系统。 1.2容灾需求分析 当前,XXXX计划在同一园区内建设容灾系统,在容灾中心和主生产中心之间采用2km长的裸光纤进行直连。并且,希望对现有的存储设备进行充分利旧。 IBM将针对当前所了解的情况,做出初步的方案,供XXXX容灾建设参考。 由于DS3400设备没有自身的基于磁盘的远程复制功能,因此无法采用基于存储底层的磁盘复制技术。此外,由于DS3400的性能有限,且缓存较低,因此采用基于AIX操作系统的LVM镜像方式性能会有影响。(各种高可用技术,详见第3章的说明) 而目前IBM最新的虚拟化存储设备V7000,即可以支持外部存储的接入,也可以支持内部存储和外部存储之间的镜像,因此可以通过V7000存储设备来实现存储的高可用,并达到同园区内容灾的目的。

数据中心容灾备份方案

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

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 备份工作。另外,为包含数据库的客户端安装数据库代理程序,从而保证数据库的在线热备份。

技术方案-应用高可用解决方案(两地三中心)

英方软件数据库系统高可用解决方案 英方软件(上海)有限公司

目录 1. 概述 (1) 2. 需求分析 (2) 3.1主机配置 (3) 3.2方案拓扑图: (3) 3.3 I2高可用方案功能介绍 (4) 3.4管理控制台 (7) 5. I2的主要优势 (10) 6. 典型案例 (12) 7.公司简介 (13)

1. 概述 现代大型企业大多拥有为数众多的服务器,提供Internet与Intranet使用者各种不同的服务。如数据库系统、影像系统、录音系统、Email系统等。保持业务的持续性是当今企业用户进行数据存储需要考虑的一个重要方面。系统故障的出现,可能导致生产停顿,客户满意度降低,甚至失去客户,企业的竞争力也大打折扣。因此,保持业务的持续性是用户在选择计算机系统的重要指标。究其根本,保护业务持续性的重要手段就是提高计算机系统的高可靠性同时将数据的损失降至最低限度。 关键数据和数据库的备份操作已经成为日常运行处理的一个组成部分,以确保出现问题时及时恢复重要数据。传统的解决方案,类似于磁带机备份存在较大的缺点. 通常数据采用磁带离线备份,当数据量较大或突发灾难发生时,备份磁带无法真正及时快速恢复数据及业务。 提供有效的数据保护和高可用性服务,又在合理预算范围之内,并且能够基于你现有环境当中,获得实时数据保护,并无距离限制,为确保你重要数据的保护----包含数据库和邮件系统。I2为您提供了完美的解决方案。 I2 采用先进的异步实时数据复制技术(Asychronous Real-Time Data Replication),立即将所有服务器上对于磁盘系统的变更透过网络传输至备援服务器,而非整个档案或磁盘的镜设(Mirror),因此对于服务器的效能与网络带宽的影响都能降至最低,并能将成本降至最低,做到真正的实时数据保护. 业务数据是用户最宝贵的资产之一,数据的损失就是企业资产利润的损失,所以保护业务数据是企业计算系统的主要功能之一。实施I2的备份方案可以将用户数据的损失降至最低甚至为零。

双机双柜高可用解决方案

双机双柜高可用解决方案 关键字:双机双柜 传统的基于共享存储的双机热备方案解决了用户业务连续性的问题,当主服务器故障时,备机能及时接管保证业务7*24小时连续运行。但共享的存储设备却成为了系统的单一故障点,当盘阵不可用时,整个业务系统也必然停顿。 为了解决共享盘阵单点故障可能导致的系统不可用问题,Rose提出了相应的解决方案。仅需在现有架构基础上增加一台冗余的磁盘阵列,即构成双机双盘柜的解决方案,既消除了存储的单点故障,又使得客户拥有冗余的数据副本,大大提升了数据和业务的可靠性。 双机双柜高可用解决方案一:镜像方式 如上图所示,主、备服务器上均挂载一个磁盘阵列,部署Rose的双机双柜解决方案,通过Rose双机镜像软件利用TCP/IP网络实现主备机存储设备上的数据实时同步,当主机遭遇存储设备故障时,由于备机上有一份完全一致的数据,则可以利用备机上的数据将应用正常启动并恢复生产。 解决方案优点: ●数据存储在两台磁盘阵列上,数据冗余备份,避免磁盘单点故障 ●基于镜像技术的实施复制,保证数据的一致性

●Rose的高可用技术,保证业务连续性 ●提升高可用容灾距离 双机双柜高可用解决方案二:LAN-FREE方式 该方案中服务器、交换机、存储设备均有冗余设计,磁盘阵列A 和磁盘阵列B 分别接入不同的光纤存储交换机,服务器A 和服务器B 分别接入不同的光纤存储交换机;这种部署结构,实现了硬件设备和存储通道的完全冗余。 利用盘阵的多路径管理软件将冗余路径映射的磁盘还原为实际磁盘,通过操作系统的磁盘管理工具将不同盘阵映射的磁盘创建为RAID 1镜像卷。分别在服务器上部署需保护的应用,并将应用数据存放至不同盘阵构成的镜像卷中,实现对业务系统的高可用保护;通过系统的软RAID技术及光纤存储网络实现两台磁盘阵列中的数据同步。 冗余的存储路径设计,有效避免了存储HBA卡、光纤存储交换机、磁盘阵列、存储通道的单点故障,完全冗余的双机双柜结构保证了业务系统的连续运营和业务系统的数据安全,方案稳定性及可靠性得到保障。 解决方案优点: ●完全冗余结构,有效避免硬件设备和软件的单点故障。彻底解决了传统双机单柜模式下,磁盘阵列单点故障的情况。 ●数据的存储架构为FC-SAN,通过存储多路径管理软件实现存储通道的负载冗余,提升了业务系统数据存储的可靠性、高效性、安全性,并且基于FC-SAN 的架构具有高可扩展性。 ●高性价比的整体解决方案,既帮助用户实现了高容错,高安全,高性能的解

容灾备份-解决方案方法

容灾备份系统2010-8-11

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

高可用解决方案

高可用解决方案 数据中心高可用网络系统设计 数据中心的故障类型众多,但故障所导致的结果却大同小异。即数据中心中的设备、链路或server发生故障,无法对外提供正常服务。缓解这些问题最简单的方式就是冗余设计,可以通过对设备、链路、Server提供备份,从而将故障对用户业务的影响降低到最小。 但是,一味的增加冗余设计是否就可以达到缓解故障影响的目的?有人可能会将网络可用性与冗余性等同起来。事实上,冗余性只是整个可用性架构中的一个方面。一味的强调冗余性有可能会降低可用性,减小冗余所带来的优点,因为冗余性在带来好处的同时也会带来一些如下缺点: w 网络复杂度增加 w 网络支撑负担加重 w 配置和管理难度增加 因此,数据中心的高可用设计是一个综合的概念。在选用高可靠设备组件、提高网络的冗余性的同时,还需要加强网络构架及协议部署的优化,从而实现真正的高可用。设计一个高可用的数据中心网络,可参考类似OSI七层模型,在各个层面保证高可用,最终实现数据中心基础网络系统的高可用,如图1所示。 网络架构高可用设计 企业在进行数据中心架构规划设计时,一般需要按照模块化、层次化原则进行,避免在后续规模越来越大的情况再进行大规模的整改,造成时间与投资浪费。 模块化设计

模块化设计是指在对一定范围内的不同功能或相同功能不同性能、不同规格的应用进行功能分析的基础上,划分并设计出一系列功能模块,模块之间松耦合,力求在满足业务应用要求的基础上使网络稳定可靠、易于扩展、结构简单、易于维护。 层次化设计 包括网络架构分层和应用系统分层两个方面。在当前网络及安全设备虚拟化不断完善的情况下,应用系统分层可完全通过设备配置来实现逻辑分层,不影响网络的物理拓扑。对于网络架构层次化设计,选择三层架构还是二层架构是不少企业进行数据中心网络建设时面临的难题。 从可靠性的角度来看,三层架构和二层架构均可以实现数据中心网络的高可用。近年来随着云计算的逐渐兴起,二层扁平化网络架构更适合云计算网络模型,可以满足大规模服务器虚拟化集群、虚拟机灵活迁移的部署。二层架构和三层架构两者之间没有绝对的优劣之分,企业用户可根据自身的业务特点进行选择。也可以先二层,后续针对某些特定的功能分区采用三层组网。 设备层高可用设计 设备可靠是系统可靠的最基本保证,数据中心核心交换区设备的可靠稳定尤为重要。尽管可以通过架构、策略、配置等的调整和优化等多种手段降低核心设备的故障几率以及影响范围,但若要解决最根本的设备本身的软硬件故障,则必须选用数据中心级的网络设备。 关于数据中心级设备,业界还没有标准的定义,但从目前主流网络设备供应商提供的数据中心解决方案产品可以看出,数据中心级交换机应具备以下特征: 1) 控制平面与转发平面物理分离 控制平面与转发平面硬件物理分离,引擎切换时不影响转发,可实现零丢包。同时控制平面与转发平面均提供独立的冗余架构,实现控制与转发两级冗余,保证更高的可靠性。 2)关键部件更强的冗余能力 除了引擎和交换网板的冗余外,此类设备的电源一般均可以配置多块,实现N+M的冗余,保证电源的可靠性更高;另外风扇的冗余也由原来的风扇级冗余,提高到了风扇框冗余,每个独立的风扇框内多个风扇冗余。 3)虚拟化能力 数据中心的复杂度越来越高,需要管理的设备也越来越多,设备的虚拟化可将同一层面(核心、汇聚、接入)的多台设备虚拟化为一台,进行设备的横向整合,简化设备的配置和管理。 4)突发大流量的缓冲能力

SQL server高可用方案

SQL server高可用方案 一、高可用的类型 ●AlwaysOn 高可用性解决方案,需要sql server 版本在2012以上 SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案”。客户通过使用AlwaysOn 技术,可以提高应用管理方面的工作。 SQL Server AlwaysOn 在以下2个级别提供了可用性。 *数据库级可用性 是一种“热备份”技术。在同步提交模式下,主副本的数据被同步更新到其他辅助副本,主副本与辅助副本之间可以时,辅助副本可以立即成为新的主副本。 *实例级可用性 AlwaysOn 故障转移群集实例(Failover Cluster Instance,简称FCI)可以在多个16个节点之间实现故障转移(版只支持2个节点。 当主节点发生故障时,辅助节点提升为主节点并获取共享存储中的数据,然后才在这个新的主节点服务器中启动FCI 是一种“冷备份”技术。辅助节点并不从主节点同步数据,唯一的一份数据被保存在共享存储(群集共享磁盘)●日志传送 日志传送依赖于传统的Windows 文件复制技术与SQL Server 代理。 主数据库所做出的任何数据变化都会被生成事务日志,这些事务日志将定期备份。然后备份文件被辅助数据库所属最后事务日志备份在辅助数据库中进行恢复,从面实现在两个数据库之间异步更新数据。 当主数据库发生故障时,可以使辅助数据库变成联机状态。可以把每一个辅助数据库都当作“冷备用”数据库

●其它辅助技术 对数据库进行备份,当出现故障时,手动将数据还原到服务器,使得数据库重新联机,这也可以算作实现高可用性复制(Replication)并不算是一个高可用性解决方案,只是它的功能可以实现高可用性。复制通过“发布-订阅”模式服务器间实现可用性。 SQL server复制 定义及应用:数据库间复制和分发数据和数据库对象,然后在数据库间进 过局域网和广域网、拨号连接、无线连接和Internet 将数据分配到不同位sql server复制分成三类: 事务复制通常用于需要高吞吐量的服务器到服务器方案(包括:提高可伸 点的数据、集成异类数据以及减轻批处理的负荷)。 合并复制主要是为可能存在数据冲突的移动应用程序或分步式服务器应用 交换数据、POS(消费者销售点)应用程序以及集成来自多个站点的数据 快照复制用于为事务复制和合并复制提供初始数据集;在适合数据完全刷二、高可用的服务器配置: 如果只是需要复制方式,则搭建两台相同硬件配置和操作系统版本与补丁 如果需要AlwaysOn 高可用方式,即出现故障后系统自动进行切换到备用 服务器、从服务器)相同硬件配置和操作系统版本与补丁、相同数据库版本三、各种实现方式的对比 下表将SQL Server 常用的高可用性解决方案进行综合对比。

MSSQL数据库高可用性方案

高可用MS SQL Server数据库解决方案 建设目标 减少硬件或软件故障造成的影响,保持业务连续性,从而将用户可以察觉到的停机时间减至最小,确保数据库服务7*24小时(RTO为99.9%)运转,建设一套完整的高可用性MS SQL Server数据库系统。 需求分析 服务器宕机造成的影响 服务器宕机时间使得丢失客户收益并降低员工生产效率,为了避免对业务造成影响,从两个方面采取预防措施: 一、计划宕机时的可用性: ●补丁或补丁包安装 ●软硬件升级 ●更改系统配置 ●数据库维护 ●应用程序升级 二、防止非计划性宕机: ●人为错误导致的失败 ●站点灾难 ●硬件故障

●数据损毁 ●软件故障 现有状况 ●服务器存在单点故障; ●数据库未做高可用性配置; ●数据库版本为MS SQL Server2008; ●服务器配置为CPU E7540 2.0,24G存; ●数据库容量约800G 技术解决方案 解决思路 考虑到本项目的需求和最佳性能,为了达到最佳可用性,方案采用两台数据库服务器做故障转移集群,连接同一台存储做数据库的共享存储,实现故障自动转移。同时,将旧服务器作为镜像数据库,采用SQL Server 2012的alwayson 功能来再次完成自动故障转移,并可以分担查询的负载。

架构拓扑 新数据库:承担数据库主体计算功能,用于生产数据,采用双机集群,实现自动故障转移。 旧数据库:通过镜像功能,存储数据库副本,用于发生故障时的转移。也可配置为只读,承担备份的负载。 存储:存储采用双控制器,双FC连接两台服务器,避免单点故障。 主/辅域控制器:采用双机模式,SQL Server 2012 实现高可用的必备基础设施。 高可靠性技术方案 SQL Server的企业版支持所有的高可用性功能,这些功能包括:

数据库负载均衡解决方案

双节点数据库负载均衡解决方案 问题的提出? 在SQL Server数据库平台上,企业的数据库系统存在的形式主要有单机模式和集群模式(为了保证数据库的可用性或实现备份)如:失败转移集群(MSCS)、镜像(Mirror)、第三方的高可用(HA)集群或备份软件等。伴随着企业的发展,企业的数据量和访问量也会迅猛增加,此时数据库就会面临很大的负载和压力,意味着数据库会成为整个信息系统的瓶颈。这些“集群”技术能解决这类问题吗?SQL Server数据库上传统的集群技术 Microsoft Cluster Server(MSCS) 相对于单点来说Microsoft Cluster Server(MSCS)是一个可以提升可用性的技术,属于高可用集群,Microsoft称之为失败转移集群。 MSCS 从硬件连接上看,很像Oracle的RAC,两个节点,通过网络连接,共享磁盘;事实上SQL Server 数据库只运行在一个节点上,当出现故障时,另一个节点只是作为这个节点的备份; 因为始终只有一个节点在运行,在性能上也得不到提升,系统也就不具备扩展的能力。当现有的服务器不能满足应用的负载时只能更换更高配置的服务器。 Mirror 镜像是SQL Server 2005中的一个主要特点,目的是为了提高可用性,和MSCS相比,用户实现数据库的高可用更容易了,不需要共享磁盘柜,也不受地域的限制。共设了三个服务器,第一是工作数据库(Principal Datebase),第二个是镜像数据库(Mirror),第三个是监视服务器(Witness Server,在可用性方面有了一些保证,但仍然是单服务器工作;在扩展和性能的提升上依旧没有什么帮助。

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

方案模板(适合政府、公安、医院等) 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)

存储高可用解决方案

目录 第1章存储高可用性给业务连续运营提供保障 (1)

1.1为什么要构建存储高可用性解决方案 (1) 1.2存储高可用性解决方案简述 (2) 1.3存储高可用性解决方案价值 (2) 第2章IBM存储高可用性解决方案介绍 (3) 2.1存储高可用性的内容 (3) 2.2存储高可用性方案的主要实现方式 (4) 第3章IBM高可用性存储产品介绍 (11) 3.1 IBM SYSTEM STORGE DS8000 TURBO系列存储产品 (11) 3.2 IBM SYSTEM STORAGE DS5000系列存储产品 (17) 3.3 IBM SYSTEM STORAGE DS4000系列存储产品 (20) 第4章为什么选择IBM (22) 第5章IBM中国公司简介 (23) 第1章存储高可用性给业务连续运营提供保障 1.1 为什么要构建存储高可用性解决方案 随着社会的发展和科技的进步,企业越来越依赖于数据处理来进行业务运营,对IT 系统的依赖性也随之增加。一旦数据由于某种原因丢失,就有可能造成整个组织在运营上的重大不便和经济损失,企业的信誉也将受到影响。如果核心数据丢失,严重时完全有可能造成整个企业的瘫痪。所以

保证企业的业务连续运营及数据处理的高可靠性和高可用性,就成为所有IT 人员在建设IT 基础架构中首先要考虑的问题。 显然,企业所面临的风险和挑战来自多方面: ?无法预知的IT 硬件设备的损坏、断电、火灾、自然灾害、恐怖袭击等,造成数据丢失或业务的突然中断; ?系统人员误操作造成意外宕机或关键数据丢失,无法避免; ?手段频多的黑客攻击、病毒入侵、垃圾邮件、网络与系统的漏洞,造成网络瘫痪、系统崩溃; ?用户需要实时应用与访问机密、关键数据,向企业的服务提出更高的要求; ?行业与政府的标准与法规的不断变化,进一步增加了企业的压力与成本。 信息是企业的最宝贵的资产之一;集中的数据备份、恢复和管理已经成为企业数据存储管理的重要任务。企业需要的是: ?数据与存储系统的高可用性,保证数据7X24 小时的连续访问; ?将现有的存储技术集成,创造出一种更有效的数据存储管理,实现高效、高可靠性、低成本的数据管理; ?需要一套成熟度高,业内应用广泛的企业级软硬件整体解决方案; ?需要对企业现有的数据库、邮件系统、文件服务器以及各种应用系统进行集中化、自动化的基于策略的保护; ?易于IT部门日常的管理维护,界面友好,可操作性强; ?能够符合企业日后发展需求,对异构平台有很好的支持,可以满足将来远程数据灾备的需求; ?一旦发生灾难(洪水、地震、火灾等),或者人为灾难(用户失误、磁盘失

系统容灾解决方案

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

被定义为没有信息存储的需求,没有建立备援硬件平台的需求,也没有发展应急计划的需求,数据仅在本地进行备份恢复,没有数据送往异地。这种方式是成本最低的灾难恢复解决方案,但事实上这种恢复并没有真正达到灾难恢复的能力。 一种典型等级1方式就是采用本地磁带库自动备份方案,通过制定相关的备份策略,可以实现系统等级1备份。 等级2: 是一种为许多站点采用的备份标准方式。数据在完成写操作之后,将会送到远离本地的地方,同时具备有数据恢复的程序。在灾难发生后,在一台未启动的计算机上重新完成。系统和数据将被恢复并重新与网络相连。这种灾难恢复方案相对来说成本较低,但同时有难以管理的问题,即很难知道什么样的数据在什么样的地方。这种情况下,恢复时间长短依赖于何时硬件平台能够被提供和准备好。 典型方式就是将数据备份到本地磁带介质上,然后通过运输方式(如“卡车”)将备份介质送往异地保存,而异地没有主机系统。当灾难发生时,再使用新的主机,利用数据备份介质(磁带)将数据恢复起来。 等级3: 相当于等级2再加上具有热备份能力站点的灾难恢复。热备份站点拥有足够的硬件和网络设备去支持关键应用的安装需求。对于十分关键的应用,在灾难发生的同时,必须在异地有正运行着的硬件提供支持。这种方式与等级2方式的区别是在异地有一个热备份站点,该站点有主机系统,平时利用数据备份介质(磁带)将数据恢复到主机系统起来。一旦发生灾难,利用该主机系统将数据恢复。 这种情况下,由于备份介质是采用运输方式送往异地,可能会有一天、甚至一周的数据丢失。由于备份站点己经有主机系统,数据恢复典型地需要一定的时间。 等级4:

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

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

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

数据容灾备份设计方案

数据容灾备份设计方案 1.1数据备份的主要方式 目前比较实用的的数据备份方式可分为本地备份异地保存、远程磁带库与光盘库、远程关键数据+定期备份、远程数据库复制、网络数据镜像、远程镜像磁盘等六种。 (1)本地备份异地保存 是指按一定的时间间隔(如一天)将系统某一时刻的数据备份到磁带、磁盘、光盘等介质上,然后及时地传递到远离运行中心的、安全的地方保存起来。 (2)远程磁带库、光盘库 是指通过网络将数据传送到远离生产中心的磁带库或光盘库系统。本方式要求在生产系统与磁带库或光盘库系统之间建立通信线路。 — (3)远程关键数据+定期备份 本方式定期备份全部数据,同时生产系统实时向备份系统传送数据库日志或应用系统交易流水等关键数据。 (4)远程数据库复制 生产系统相分离的备份系统上建立生产系统上重要数据库的一个镜像拷贝,通过通信线路将生产系统的数据库日志传送到备份系统,使备份系统的数据库与生产系统的数据库数据变化保持同步。 (5)网络数据镜像 是指对生产系统的数据库数据和重要的数据与目标文件进行监控与跟踪,并将对这些数据及目标文件的操作日志通过网络实时传送到备份系统,备份系统则根据操作日志对磁盘中数据进行更新,以保证生产系统与备份系统数据同步。 (6)远程镜像磁盘 利用高速光纤通信线路和特殊的磁盘控制技术将镜像磁盘安放到远 …

离生产系统的地方,镜像磁盘的数据与主磁盘数据以实时同步或实时异步方式保持一致。磁盘镜像可备份所有类型的数据。备份拓扑网络结构1.2(即东风东路院区中心机广州市第八人民医院具有两个不同地点的中心机房房和嘉禾院区中心机房),在这基础上是可以构建一个异地容灾的数据备份系统,以确保本单位的系统正常运营及对关键业务数据进行有效地保护,以下设计方案仅提供参考。嘉禾院区数据中心东风东院区数据中心 本方案中,我们采用EMC的CDP保护技术来实现数据的连续保护和容灾系统。 1.在东风东院区数据中心部署一台EMC 480统一存储平台,配置一个大容量光纤磁盘存储设备,作为整个系统数据集中存储平台。 2.在嘉禾院区数据中心部署一台EMC 480统一存储系统,配置一个大容量光纤磁盘存储设备,作为整个平台的灾备存储平台。 ) 3.两地各部署两台EMC RecoverPoint/SE RPA,采用CLR技术,即CDP(持续数据保护)+CRR(持续远程复制),实现并发的本地和远程数据保护。 4.在东风东院区数据中心本地采用EMC RecoverPoint/SE CDP(持续数据保护)技术实现本地的数据保护。. 5.两地采用EMC RecoverPoint/SE CRR(持续远程复制)技术,实现远程的数据保护。由于两地之间专线的带宽有限,可以采用EMC Recoverpoint/SE异步复制技术,将东风东院区数据中心EMC480上的数据定时复制到嘉禾院区数据中心。根据带宽的大小,如果后期专线带宽有所增加,RecoverPoint会自动切换同步、异步、快照时间点三种复制方式,尽最大可能保证数据的零丢失。 1.3本地数据数据保护(CDP)设计

相关主题
文本预览
相关文档 最新文档