存储级数据容灾方案模板教材

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

1.用户现状与需求

1.1.用户IT系统现状

用户现有系统包括数据库、应用、WEB、邮件等系统,虽然是双机架构,但是其稳定性和可靠性都没有达到核心系统应该具备的标准,而且直连的存储架构对于性能和管理型都有一定的局限性。

业务数据是企业业务的生命线,如何保护好计算机系统里存储的数据,保证系统稳定可靠地运行,并为业务系统提供快捷可靠的访问,是系统建设中最重要的问题之一。为了保护业务系统的关键业务数据,我们必须对这些数据进行有效的备份,并支持快速恢复。

通过备份的方式将文件、数据库等重要数据做一个副本,只能在本地建立数据保护。但因意外(如火灾、地震等)停止工作时,随之而来的损失更是不可估量,为避免类似风险的存在,就需要建立异地容灾系统,整个应用系统可以切换到另一处,使得该系统功能可以继续正常工作,保证业务稳定运行。

1.2.用户需求

1.2.1.建设目标

从容灾的级别来说,可以规划数据级容灾和应用级容灾,根据业务种类多,业务方式多样化的特点,仅建设一个数据级容灾是不够,容灾发生时,业务快速的恢复是容灾系统的一大需求。应用级容灾是建立在数据级容灾的基础上,在容灾切换时,除了切换核心的数据库数据外,还包含了IP地址切换(按客户需要选择),中间件服务,用户级业务。应用级容灾从流程上实现了全业务的连续性需求。

从我们的灾难系统建设经验出发,xxx有限公司可以考虑以下业务连续性计划目标:RPO(最大允许数据丢失时间):零数据丢失

RTO(最大允许宕机时间):30分钟

应用级容灾需求

1.2.2.需求分析

用户需要保障数据的长期安全可靠的,数据对于灾难的安全性和可恢复性:灾难切换时间要求灾难系统切换时间不超过30分钟,最好在10分钟内实现。

多种灾难切换方式提供自动灾难系统切换和手动灾难切换方式

计划内维护要求提供计划内维护支持能力,计划内维护切换时间不多于10分钟

数据丢失性要求原则上要求零数据丢失,可以依据情况进行调整

数据同步方式提供同步和异步两种方式

备份和灾难备份方式采用物理备份方式实现

物理部件失败要求支持部分磁盘,文件系统,主机,磁盘柜等各种物理部件失败导致的失败保护。

站点失败要求支持由于火灾,电力以及其他因素导致站点失败的数据保护。

逻辑失败要求支持由于数据块腐败导致的数据库无法启动,数据丢失等逻辑失败保护

人类错误失败要求支持由于人类误操作以及入侵等导致人类错误失败导致的数据保护或者恢复。

生产系统的性能影响要求生产系统性能影响不超过5%

生产系统可用性要求容灾系统不会降低生产系统可用性

网络链路分钟级别短暂故障要求不会对生产系统产生影响

网络链路小时级别长期故障要求不会对生产系统产生影响

网络链路密集的秒级别短暂故障要求不会对生产系统产生影响

网络链路容错支持网络链路的容错,可以利用网络的备份链路,比如多路网卡等灾难系统的硬件故障由于灾难系统硬件故障导致的灾难系统不可用不会对生产系统产生影响,比如网卡,磁盘以及控制卡等

灾难系统的软件故障由于灾难系统软件故障导致的灾难系统不可用不会对生产系统产生影响,比如灾难系统管理软件部件等

网络协议采用IP网络实现

网络带宽一般的百兆或者千兆带宽

RTT要求R TT要求在10ms以内即可满足要求,可以容忍部分时间的30ms响应在线实施要求要求在备份系统实施期间保持生产系统运行

存储系统失败的原址运行在生产系统主机可用的情况下可以支持系统原址运行

部分文件失败的原址运行在部分文件失败的情况下可以支持系统原址运行

2.建议方案

2.1设计原则

通过对用户具体环境和需求的分析,我们在针对性的方案设计上应遵循以下原则:

➢最高的性价比,根据用户的实际需求,提供合适的解决方案,在有限的资金许可范围内提供符合需求的方案。

➢优化的策略,关键业务系统和一般应用系统优先级的策略化,需要确保关键业务系统的数据不丢失。

➢广泛的适用性,支持异构平台,产品可以适应不同类型的应用、数据以及主机存储设备。

2.3.8容灾方案设计

目前有很多种容灾技术,分类也比较复杂。根据用户应用系统特点的不同,应用系统持续服务紧迫性的区别,应有针对性的选择容灾系统方案。

(1)基于应用程序容灾解决方案

◆方案优点

•应用程序在本地、远端双写I/O;

•该方案能够实现业务系统在发生灾难时自动切换,保证业务的完全连续性;

◆方案缺点

•投资非常高,容灾软件价格昂贵;

•实施复杂,应用系统需要重新搭建;

•该方案完全由软件实现,需消耗主机系统资源,效率底;

(2)基于数据库复制的远程容灾解决方案

◆方案优点

•数据库本身的远程复制(Oracle DB Guard);

•实施相对简便,支持异构存储;

◆方案缺点

•只能复制数据库文件,实现数据库容灾;

•需要重新调试、安装数据库;

•停机时间较长;

(3)基于主机的远程数据复制软件容灾解决方案

◆方案优点

•复制软件在卷管理器层面截获I/O,远程复制

•支持异构存储;

•可以实现应用的实时、自动切换;

◆方案缺点

•需要重新配置存储卷,停机时间较长;

•新增容灾系统需要增加软件授权;

(4)基于存储的远程数据复制容灾解决方案

◆方案优点

•智能存储远程数据复制,技术较成熟;

•设备、软件投资费用低;

•实施简便,应用系统仅需短时间停机;

•不需要对应用、数据库重新安装调试;

◆方案缺点

•只支持同一厂商同一系列存储;

•不能实现应用的实时、自动切换;

根据用户的应用特点:建议使用基于存储的容灾方案。

2.3.9系统整体架构

本地灾备中心

服务器均采用原有服务器,所有服务器配置HBA卡,连接至用户现有光纤交换机;

新增存储加入SAN网络,存储空间可根据业务需求,自由划分给多套系统使用;

相关文档
最新文档