存储级数据容灾方案模板.docx
《存储级数据容灾方案模板.docx》由会员分享，可在线阅读，更多相关《存储级数据容灾方案模板.docx（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要求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.判断异常影响程度
业务持续管理小组和/或业务持续行政小组的负责人在判断异常影响程度的基础上，做出不启动BCP的决定。
4.异常处理
在通知恢复的人员过程中，发生异常的站点的值班人员必须并立即投入异常恢复工作，并与内部和外部的支援团队取得联系，获得相应支持。
4.灾难恢复预案
容灾系统建成之后，必须能够发挥相应的效益。
鉴于本次容灾项目为数据级的容灾系统，在发生系统故障的时候，需要手工对应用系统进行切换，因此，我们应对各种系统状况提前做出操作预案，这样才能保证容灾系统真正发挥效益。
4.1.计划内和计划外停机的切换步骤
4.1.1.计划内停机
生产中心操作：
◆检查生产中心和容灾中心所有的主机、存储、网络、卷复制软件是否都正常；
◆正常停止生产中心的所有应用；
◆断开产中心和容灾中心的复制关系；
容灾中心操作：
◆阵列上的卷MAP给容灾中心的主机；
◆手工启动应用系统；
4.1.2.计划外停机
生产中心不能做任何操作的情况；
容灾中心操作：
◆阵列上的卷MAP给容灾中心的主机；
◆手工启动应用测试；
4.2.设备故障的影响和处理
4.2.1.生产中心主机故障
I一台主机问题；应用切换到cluster另外的一台主机；对应用有小切换的影响；
II两台主机问题或者cluster问题；数据切换到容灾中心；在容灾中心启用应用；对应用有大切换影响；
4.2.2.生产中心存储系统故障
I阵列自己的冗余功能；替换故障备件；对应用无影响；
II阵列不能冗余问题（2块控制器故障；多块硬盘同时故障），数据切换到容灾中心；在容灾中心启用应用；对应用有大切换影响；
4.2.3.复制链路故障
数据复制中断；对应用无影响；链路恢复后数据正常复制；
4.2.4.容灾中心设备故障
容灾中心设备故障对应用系统无影响。
4.3.实施风险提示
根据xxxx的业务应用需求，本方案旨在用最低的投资达到xxxx所需在60分钟心实现应用系统切换的系统容灾效果，无法规避如下风险因素：
◆应用系统的自动实施切换
本方案在需要切换系统时，必须人工干预，无法实现自动切换；
◆数据库数据异常
当数据库数据存在异常时，容灾系统在进行切换时首先需要进行数据数据的回滚才能启动数据库，回滚时间视数据库的数据量而定，可能会超出60分钟的恢复时限。
（所有容灾方案均无法规避该问题）
◆同城灾难
本容灾方案无法规避地震、电网大规模断电等覆盖全市的灾难恢复；
5.应急管理预案
5.1.紧急响应策略
5.1.1.紧急相应策略概述
紧急响应策略包括三个部分：
紧急事件响应、恢复和复原。
紧急事件响应包括为保护生命和减轻损失所采取的最初行动策略。
恢复是指继续支持关键业务所采取的步骤。
复原是回到业务的运行状态。
紧急响应策略是用于减少紧急事件对业务连续性造成负面影响的一套机制、计划、方法和规程。
紧急响应策略包括建立和管理紧急事件运作中心，该中心用于在紧急事件中发布命令。
紧急事件响应方式概述
紧急事件响应方式根据不同类别的紧急事件，由有关部门组成紧急事件响应指挥中心，用户主管领导人担任总指挥，统一领导、统一指挥紧急事件处理，协调、调动相关力量和资源，决定采取处理紧急事件的重大措施；确定对外口径，指导对外新闻发布；其中容灾工作委员会的主要指责是组织开展对紧急事件的监测与报告、分析和预警；需要启动紧急事件紧急预案时，提请决策层批准，进行组织和协调专业技术机构及其人员进行现场调查与处理，实施现场撤离与抢修等紧急处理措施；组织制定有关的调查方案、技术标准和规范；依照条例规定及时对紧急事件评估；发布、通报紧急事件信息，可以授权其他部门向社会发布本行政区域紧急事件信息；开展健康教育、技术人员培训和演练；会同有关部门提出物资和经费储备计划；检查督导紧急事件紧急预案的落实情况等。
5.1.2.紧急响应和运作的需求
1、识别潜在的紧急事件类型和所需的响应（如火灾、危险物质泄漏、疾病等）
2、识别现有的、正确的紧急事件相应规程
通知规程：
（1）内部的（逐级规程），包括本地的、机构的。
（2）外部的（响应规程），包括公共机构和媒体、产品和服务的供应商
事件前的准备：
（1）根据灾难的类型：
自然事件、事故、有意的破坏
（2）管理和职权的连续性
（3）指定人员的角色
紧急措施：
（1）疏散
（2）医疗和人员咨询
（3）危险材料响应
（4）灭火
（5）通知
（6）其他
设施的稳定：
消减损失：
测试规程和责任：
3、建议制定还没有的紧急事件规程，规程包括以下内容：
人员的保护：
（3）人员集合的位置以及确保所有员工识别和安全的过程，如果需要包括适当的逐级过程
（4）认识和了解充分和更严格地履行任何相关法律要求的重要性
（5）识别直接部署和后续合同的选项
（6）了解法律规定的内在意义
事件的控制：
（1）了解拯救和控制损失的原则
（2）了解用于控制业务影响的紧急事件服务工作进行补充的可用选项
（3）了解业务功能本身控制灾难影响的可能性
后果的评估：
（1）分析形势并提供有效的评估报告
（2）评价事件对机构的直接影响
（3）将形势通报给相关设施和机构其他地点中的员工
（4）提供对媒体可能关注事项的理解并与现存的公共关系和/或市场部门联合制定响应方案
决定最适宜的行动：
（1）了解在建议或决定连续性选项过程中需要考虑的事项
（2）了解紧急事件服务的角色
（3）维护安全的原则（人员、物理和信息）
4、将灾难恢复、业务连续性规程与紧急事件规程整合起来
5、识别管理紧急事件的命令和控制需求
设计和装备紧急事件运作中心
在事件中命令和决策的职权角色
通信载体（如邮件、无线电、信使和移动电话等）
6、建议制定对角色、职权进行定义的命令和控制规程以及管理紧急事件的通信规程
开启紧急事件运作中心
紧急事件运作中心的安全
紧急事件运作中心团队的进度安排
紧急事件运作中心的管理和运作
关闭紧急事件运作中心
7、紧急事件响应和分类救护
制定、实施和演练紧急事件响应和分类救护规程，包括确定紧急事件中行动的优先顺序
制定、实施和演练分类救护规程，如急救和医疗；确定地点和制定到附近医院的运输规程
8、拯救和复原需求
集合适当的团队：
（7）了解通过电话进行有效诊断的需要
（8）了解在受到影响的地点对相关资源进行有效集中的需要
（9）制定内部逐级规程以便在事件/响应展开的现场提供所需等级的资源
定义初始现场的行动策略：
（1）了解对直接消减损失和拯救需求进行识别的需要
（2）了解其需求并在需要的情况下准备站点保安、安全和稳定措施计划
（3）识别保护现场资产的适当方法，包括设备房产和文档
（4）认识建立与外部机构联络的潜在需求（如法律法规、紧急事件服务如消防部门以及警察、保险公司、损失理赔等）
（5）了解业务需求和对其进行解释以协助物理资产的恢复
（6）与公共当局建立设施访问的规程
（7）与第三方服务提供商尽力规程，包括适当的合同协议
9、确保紧急事件响应规程与公共当局的要求相统一
5.1.3.紧急响应场所的分类和功能、建设描述
紧急响应场所至少包括避难所（shelterinplace）、紧急操作中心EOC（emergencyoperationcenter）、紧急事件运作中心ICS（incidentcommandcenter）；
紧急响应场所建设描述，包括建设内容、设备需求、场地需求、环境需求等；
紧急事件运作中心ICS是紧急指挥体系的首脑部门，也是紧急事件处理指挥的场所。
实现对紧急事件的分析、计划、组织、协调和管理控制等指挥功能。
紧急事件运作中心的总体目标是：
面对紧急事件，能够为指挥首长和参与指挥的业务人员和专家，提供各种通讯和信息服务，提供决策依据和分析手段，和指挥命令实施部署和监督方法能及时、有效地调集各种资源，实施事故、灾难控制和抢修救治工作，减轻紧急事件对生命安全和业务造成的威胁，用最有效的控制手段和最小的资源投入，将损失控制在最小范围内。
紧急事件运作中心基本功能包括：
1.紧急事件的评估与触发启动，根据对各种资料数据的分析评估，对事件进行级别判定，经核实后向相应级别的部门提出预案启动建议。
2.指挥功能：
指挥现场为参加指挥首长提供会议设施、桌面终端网络、电话系统。
参谋人员为首长提供各种辅助决策信息。
3.通讯功能：
利用专线、因特网、卫星网络、电话设备、移动通讯设备与及其他相关单位的通讯网络。
4.信息收集分析功能：
收集、整理各种相关信息资源。
紧急事件运作中心应急指挥系统具有以下六大功能：
（1）可实现针对特定事件的特定范围内资源实时调度方案的辅助制定，合理配置有关资源，及时控制事件蔓延。
（2）可实现对特定范围内紧急事件的实时监测，及时发现突发事件。
（3）可生成针对不同应急事件的多种处理预案。
（5）可实现具有真实感的虚拟环境下的事件演化模型，并对处理方案的预期效果进行模拟。
（6）可实现相关资源管理业务和信息管理的统一性和一致性，并实现网络化远程调度管理，从根本上提高管理效率。
5.1.4.紧急场所设施使用人员的权限分配
建议制定对角色、职权进行定义的命令和控制规程，考虑管理和职权的连续性。
5.1.5.紧急事件发生前的监测、监控与预警系统
监测、监控与预警系统是紧急预警处理的基础。
平时细致有效的监测与监控是第一步。
一旦发现有紧急事件出现，对局部事件进行实时监控，就可以展开及时的调查和分析，防止事件的扩散，在全面分析和科学判断的前提下，发出预警信号，提醒企业和社会进行相关的应对和准备工作，防患于未然。
监测预警主要包括：
◆火灾监测
◆供电监测
◆监测
◆急救监测
◆影响区域监测
以上部分根据风险分析来完善。
预警系统是指对监测数据进行整合、分析和判断，建立诊断和预测模型，对易造成重大危害的分布状态及危险因素进行早期报告。
紧急事件紧急预警处理系统要想达到高效、快速反应，首先必须形成完全覆盖，不留漏点。
但完全覆盖必然涉及到社会的方方面面，其中包括许多单位和行政、事业单位。
5.1.6.
紧急事件发生后的紧急事件响应程序
紧急事件的一般响应程序是：
紧急事件的一般处理程序包括事件通知、事件评估、紧急预案启动及相关措施；
5.1.6.1.事件通知
通知规程
事件的发生可能有先兆也可能没有先兆。
例如，飓风将影响某个地区或计算机病毒会在某日发作经常会得到实现通知。
但是，设备故障或者犯罪活动就可能没有先兆。
通知规程应该在计划中包含这两种情况。
适当的通知对减少IT系统的影响是很重要的；在一些情况下，它可以为允许系统人员正常关闭系统避免系统崩溃赢得足够的时间。
在灾难发生后，应该通知损害评估小组使其能够确定事态的严重程度和下一步将要采取的行动。
损害评估完成后，应该通知相应的恢复和支持小组。
可以通过各种方法完成通知，包括电话、传呼、电子邮件或者移动电话。
由于无法确定能否有效恢复，所以通过电子邮件发送通知应该谨慎从事。
在工作时间发送的通知应该发送到办公地址，在局域网停顿的事件中可以使用个人电子邮箱传送消息。
在影响广泛的灾难事件中，有效的通知工具是电台、电视广播和WEB网站。
通知策略应该定义在事件发生后人员无法联络时的规程。
一种通知方法是呼叫树。
这种技术指定特定人员执行通知任务，此人负责通知其他的恢复人员。
呼叫树应该包括主要的和备用的联络方法，应该讨论在某个人无法联系时应该采取的规程。
下面是一个呼叫树（举个例子）：
需要通知的人员应该在计划附录中的联系清单中标明。
这个清单确定人员在其团队中的职位、姓名和联络信息（如家庭、工作电话号码及传呼号码、电子邮件地址和家庭地址）。
通知还应该发给会因为不知情而受到负面影响的外部机构或者互联的伙伴系统。
根据中断类型的不同，POC可能具有恢复能力。
所以，与外部机构相连的每一个互联系统
升级会员 