存储级数据容灾方案模板教材.docx
- 文档编号:2392600
- 上传时间:2022-10-29
- 格式:DOCX
- 页数:24
- 大小:124.15KB
存储级数据容灾方案模板教材.docx
《存储级数据容灾方案模板教材.docx》由会员分享,可在线阅读,更多相关《存储级数据容灾方案模板教材.docx(24页珍藏版)》请在冰豆网上搜索。
存储级数据容灾方案模板教材
1.用户现状与需求
1.1.用户IT系统现状
用户现有系统包括数据库、应用、WEB、邮件等系统,虽然是双机架构,但是其稳定性和可靠性都没有达到核心系统应该具备的标准,而且直连的存储架构对于性能和管理型都有一定的局限性。
业务数据是企业业务的生命线,如何保护好计算机系统里存储的数据,保证系统稳定可靠地运行,并为业务系统提供快捷可靠的访问,是系统建设中最重要的问题之一。
为了保护业务系统的关键业务数据,我们必须对这些数据进行有效的备份,并支持快速恢复。
通过备份的方式将文件、数据库等重要数据做一个副本,只能在本地建立数据保护。
但因意外(如火灾、地震等)停止工作时,随之而来的损失更是不可估量,为避免类似风险的存在,就需要建立异地容灾系统,整个应用系统可以切换到另一处,使得该系统功能可以继续正常工作,保证业务稳定运行。
1.2.用户需求
1.2.1.建设目标
从容灾的级别来说,可以规划数据级容灾和应用级容灾,根据业务种类多,业务方式多样化的特点,仅建设一个数据级容灾是不够,容灾发生时,业务快速的恢复是容灾系统的一大需求。
应用级容灾是建立在数据级容灾的基础上,在容灾切换时,除了切换核心的数据库数据外,还包含了IP地址切换(按客户需要选择),中间件服务,用户级业务。
应用级容灾从流程上实现了全业务的连续性需求。
从我们的灾难系统建设经验出发,xxx有限公司可以考虑以下业务连续性计划目标:
RPO(最大允许数据丢失时间):
零数据丢失
RTO(最大允许宕机时间):
30分钟
应用级容灾需求
1.2.2.需求分析
用户需要保障数据的长期安全可靠的,数据对于灾难的安全性和可恢复性:
灾难切换时间要求灾难系统切换时间不超过30分钟,最好在10分钟内实现。
多种灾难切换方式提供自动灾难系统切换和手动灾难切换方式
计划内维护要求提供计划内维护支持能力,计划内维护切换时间不多于10分钟
数据丢失性要求原则上要求零数据丢失,可以依据情况进行调整
数据同步方式提供同步和异步两种方式
备份和灾难备份方式采用物理备份方式实现
物理部件失败要求支持部分磁盘,文件系统,主机,磁盘柜等各种物理部件失败导致的失败保护。
站点失败要求支持由于火灾,电力以及其他因素导致站点失败的数据保护。
逻辑失败要求支持由于数据块腐败导致的数据库无法启动,数据丢失等逻辑失败保护
人类错误失败要求支持由于人类误操作以及入侵等导致人类错误失败导致的数据保护或者恢复。
生产系统的性能影响要求生产系统性能影响不超过5%
生产系统可用性要求容灾系统不会降低生产系统可用性
网络链路分钟级别短暂故障要求不会对生产系统产生影响
网络链路小时级别长期故障要求不会对生产系统产生影响
网络链路密集的秒级别短暂故障要求不会对生产系统产生影响
网络链路容错支持网络链路的容错,可以利用网络的备份链路,比如多路网卡等
灾难系统的硬件故障由于灾难系统硬件故障导致的灾难系统不可用不会对生产系统产生影响,比如网卡,磁盘以及控制卡等
灾难系统的软件故障由于灾难系统软件故障导致的灾难系统不可用不会对生产系统产生影响,比如灾难系统管理软件部件等
网络协议采用IP网络实现
网络带宽一般的百兆或者千兆带宽
RTT要求RTT要求在10ms以内即可满足要求,可以容忍部分时间的30ms响应
在线实施要求要求在备份系统实施期间保持生产系统运行
存储系统失败的原址运行在生产系统主机可用的情况下可以支持系统原址运行
部分文件失败的原址运行在部分文件失败的情况下可以支持系统原址运行
2.
建议方案
2.1设计原则
通过对用户具体环境和需求的分析,我们在针对性的方案设计上应遵循以下原则:
Ø最高的性价比,根据用户的实际需求,提供合适的解决方案,在有限的资金许可范围内提供符合需求的方案。
Ø优化的策略,关键业务系统和一般应用系统优先级的策略化,需要确保关键业务系统的数据不丢失。
Ø广泛的适用性,支持异构平台,产品可以适应不同类型的应用、数据以及主机存储设备。
2.3.8容灾方案设计
目前有很多种容灾技术,分类也比较复杂。
根据用户应用系统特点的不同,应用系统持续服务紧迫性的区别,应有针对性的选择容灾系统方案。
(1)基于应用程序容灾解决方案
◆方案优点
应用程序在本地、远端双写I/O;
该方案能够实现业务系统在发生灾难时自动切换,保证业务的完全连续性;
◆方案缺点
投资非常高,容灾软件价格昂贵;
实施复杂,应用系统需要重新搭建;
该方案完全由软件实现,需消耗主机系统资源,效率底;
(2)基于数据库复制的远程容灾解决方案
◆方案优点
数据库本身的远程复制(OracleDBGuard);
实施相对简便,支持异构存储;
◆方案缺点
只能复制数据库文件,实现数据库容灾;
需要重新调试、安装数据库;
停机时间较长;
(3)基于主机的远程数据复制软件容灾解决方案
◆方案优点
复制软件在卷管理器层面截获I/O,远程复制
支持异构存储;
可以实现应用的实时、自动切换;
◆方案缺点
需要重新配置存储卷,停机时间较长;
新增容灾系统需要增加软件授权;
(4)基于存储的远程数据复制容灾解决方案
◆方案优点
智能存储远程数据复制,技术较成熟;
设备、软件投资费用低;
实施简便,应用系统仅需短时间停机;
不需要对应用、数据库重新安装调试;
◆方案缺点
只支持同一厂商同一系列存储;
不能实现应用的实时、自动切换;
根据用户的应用特点:
建议使用基于存储的容灾方案。
2.3.9系统整体架构
本地灾备中心
服务器均采用原有服务器,所有服务器配置HBA卡,连接至用户现有光纤交换机;
新增存储加入SAN网络,存储空间可根据业务需求,自由划分给多套系统使用;
新增一台备份服务器,安装NBU服务端,新增一台HDS虚拟带库作为备份介质保存备份数据,实现SAN备份。
主数据中心和灾备中心之间通过高速光纤链路连接,为数据复制和备份提供了很好的链路基础。
利用HDS容灾管理软件TrueCopy实现磁盘阵列之间数据的复制。
建立同城异地容灭系统,通过数据同步保证在总部运行中心出现重大灾难故障时,能启用灾备中心进行正常交易。
异地备份中心
容灾中心新增容灾服务器、容灾交换机,新增的HDSAMS2100作为容灾存储设备,该备份中心只需要保存业务系统数据一份可用的备份。
当本地机房瘫痪时,容灾服务器接管ERP及交易系统。
3.
灾备中心运行维护方案
3.1.解决方案选择
保持业务持续性,恢复业务处理的方法可以包括与冷、温或热站点供应商签订商业合同、移动站点、镜像站点、与内部或外部机构签订互惠协议、与设备供应商签订服务水平协议(SLA)。
另外,在制定系统恢复策略时应该考虑诸如独立磁盘冗余阵列(RAID)、自动故障切换、不间断电源(UPS)和镜像系统等技术。
业务持续性计划必须包括在比较长的期间在备用设施中恢复和执行系统运行的策略。
通常,有三种备用站点可供选择:
n由机构拥有或运行的专用站点
n与内部或外部实体签订的互惠协议或协议备忘录
n商业租用设施
无论选择哪种类型的备用站点,设施必须能够支持应急计划中所定义的系统操作。
三种站点类型可以根据运行的准备程度进行分类。
这样的话,站点可以被确定为冷站点、温站点、热站点、移动站点和镜像站点。
根据BIA的结果和银联对业务持续性的要求,选择的解决方案可以描述为:
(1)建立异地容灾中心将完全复制生产中心的数据,并实现两中心间的数据实时同步,其功能为:
a.正常工作状态下,灾备中心将配置为生产中心的完全数据复制,以保证当生产中心发生灾难时,数据的完整性。
b.当生产中心的存储系统及数据不可访问时,可以通过对备份数据中心的数据的访问。
(2)建立灾备中心,生产中心的数据将完全复制到灾备中心,允许存在一定的时间差,但应满足RPO和RTO要求。
灾备中心配置有与生产中心架构相同的服务器系统,在生产中心无法运行的情况下接替生产中心的生产业务,实现对业务持续性的要求。
a.正常工作状态下,备份中心将配置为生产中心的数据复制源,以最大限度的不影响生产中心的主机和存储系统的性能。
b.当生产中心灾难发生时,灾备中心的完全复制数据将用于生产数据中心的数据同步,以保证当生产中心灾难发生时,灾备中心没有数据丢失;业务可以恢复运行。
3.2.业务持续性策略
3.2.1.日常运行状态
在没有任何异常情况发生的情况下,系统按照正常的运行状态运转,工作人员按照各自的岗位职责开展工作。
定期将工作内容和工作结果向上级管理人员汇报并接受上级管理人员的监督和检查。
3.2.2.切换流程
切换流程分计划内切换流程和计划外切换流程,首先讨论计划为切换流程。
1.发现并确定灾难情况
运行中心运行保障室是负责发现可能导致业务系统灾难的事件的主要部门。
同时,网络维护室、系统维护室和安全管理室等其它部门应该将所发现的可能导致灾难的时间随时向运行保障室报告。
2.通知负责恢复的人员
运行保障室按照预定程序通知业务持续管理小组的值班人员,值班人员需要监控事件的发展,必要时将向业务持续小组负责人通报。
当发生可能导致业务处理中心的情况后,需要通知以下人员:
◆信息中心主管
◆业务持续管理小组负责人
◆业务持续行政小组负责人
◆负责维护发生以外事件的系统的部门负责人
3.判断异常影响程度,启动BCP计划
启动BCP计划是业务持续管理小组和/或业务持续行政小组的职责。
通常由业务持续管理小组和/或业务持续行政小组的负责人宣布BCP计划的启动。
在被授权的组织会负责人确定需要启动灾备站点后,宣布BCP计划启动。
按照BCP所定义的工作内容,损害评估小组和灾难恢复小组开始工作。
4.激活灾备站点
在通知恢复的人员过程中,灾备站点的值班人员必须被通知并立即投入工作,做好业务运行环境的检查等工作。
关闭可能对恢复业务运行有影响的任何应用系统,做好恢复业务运行的准备。
在收到BCP启动的通知后,按照BCP所定义的操作流程,与生产中心陪着或独立执行业务恢复工作。
5.发布公告
业务持续管理小组的相关成员按照BCP所定义的工作内容向外发布公告
6.提供业务恢复所需的服务
在业务恢复以及业务在灾备站点运行期间,内部和外部的支持团队以及相关工作人员按照BCP所定义的工作内容为业务的持续运行服务。
对于计划内切换流程,其大部分内容与计划为流程相同,通常由通知负责恢复的人员开始,直到提供业务恢复所需的服务。
计划内切换可能是由于演习或需要进行站点级的设备维护造成的,有很强的计划性,灾备站点人员应该提早完成恢复业务运行的准备工作,如所有工作人员到位等。
3.2.3.非切换异常处理流程
切换流程用于处理不会导致业务切换的异常事件,如部分设备的损坏没有影响业务处理的正常运行,或备份中型和/或灾备中心发生异常等。
虽然这些异常事件不会对业务的运行造成直接影响,但是使系统整体的稳定性降低,业务运行的风险加大了,而且这样的事件大量存在,应该引起足够的重视。
初步计划的非切换异常处理流程如下:
1.发现并确定灾难情况
运行中心运行保障室是负责发现可能导致业务系统灾难的事件的主要部门。
同时,网络维护室、系统维护室和安全管理室等其它部门应该将所发现的可能导致灾难的时间随时向运行保障室报告。
2.通知负责恢复的人员
运行保障室按照预定程序通知业务持续管理小组的值班人员,值班人员需要监控事件的发展,必要时将向业务持续小组负责人通报。
当发生可能导致业务处理中心的情况后,需要通知以下人员:
◆信息中心主管
◆业务持续管理小组负责人
◆业务持续行政小组负责人
◆负责维护发生以外事件的系统的部门负责人
3.判断异常影响程度
业务持续管理小组和/或业务持续行政小组的负责
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 存储 级数 据容灾 方案 模板 教材
![提示](https://static.bdocx.com/images/bang_tan.gif)