公司灾备专项方案.doc

公司灾备需求
　　某公司众多业务系统中，由于前期都是分批进行搭建，每年产品选型也均有变化，业务系统主机涉及windows、linux、unix系统，存储产品也涉及了IBM、EMC、HDS等，在面临众多产品及不同生产环境时，灾备需求需要进行细致分析，其中涉及如下几种环节：
　　1、灾备征询
　　2、容灾技术选型
　　3、生产系统整合
　　4、灾备系统投产
　　5、演习
1.1.1 灾备征询
　　建设初期需要对生产系统进行全面调研，不但仅涉及硬件信息收集，更涉及业务风险分析，业务关联性分析等。
　　通过对既有系统数据收集，充分分析既有生产系统面临挑战，以及生产中心所处位置地理、天气、社会环境进行充分分析，最后对同城灾备中心及异地灾备中心选址给出合理征询交付物。
　　业务关联性分析方面需要跟业务部门进行沟通，梳理出关联业务数据流向和数据依赖性，用来确认容灾最后范畴及重要限度，避免由于某些特定关联业务梳理不到位，导致核心应用由于关联性问题，容灾级别减少或灾备项目建设失败状况发生。
1.1.2 核心技术选型
　　近几年来，容灾已经成为信息数据中心建设热门课题。诸多容灾技术也迅速发展起来，对顾客来说也有很辽阔选取余地。由于容灾方案技术复杂性和多样性，普通顾客很难弄清其中优劣以拟定如何选取最适合自己状况容灾解决方案。下面就容灾建设中备份及复制技术做一种进一步探讨，最后为本次容灾中各系统选取适合容灾方式。
　　容灾系统规定生产中心和灾备中心同步工作，生产中心和灾备中心之间有传播链路连接。数据自生产中心实时复制传送到灾备中心。在此基本上，可以在应用层进行集群管理，当生产中心遭受劫难浮现故障时可由灾备中心接管并继续提供服务。
　　和数据备份相比，数据复制技术具备实时性高、数据丢失少或零丢失、容灾恢复快、投资较高等特点。
　　但是数据复制技术不能代替数据备份技术，由于数据复制技术保证是两地数据一致及完整，但是她不能避免由于人员误操作、病毒或其她方式带来数据丢失或破坏，因此就算有了完整数据复制技术，也不能放弃数据备份。
　　依照数据复制层次，数据复制技术实现可以分为三种：存储系统层数据复制、操作系统数据复制和数据库数据复制。
　　数据复制技术比较
　　下面对数据复制三种技术做一种简朴比较：
复制技术
比较项目
存储系统数据复制
操作系统层数据复制
应用程序层数据复制
基于存储
数据复制
虚拟存储技术
基本原理
数据复制过程通过本地存储系统和远端存储系统之间通信完毕。
复制技术是随着着存储局域网浮现引入，通过构建虚拟存储上实现数据复制。
通过操作系统或者数据卷管理器来实现对数据远程复制。
数据库异地复制技术，普通采用日记复制功能，依托本地和远程主机间日记归档与传递来实现两端数据一致。
平台规定
同构存储
与平台无关，
需要增长专有复制服务器或带有复制功能SAN互换机
同构主机、异构存储
与平台无关
复制性能
高
高
高
较高
资源占用
对生产系统存储性能有影响
对网络规定高
对生产系统主机性能有影响
占用某些生产系统数据库资源
技术成熟度
成熟
成熟度有待提高，非主流复制技术。
成熟
成熟
投入成本
高，需要同构存储
较高，需要专有设备
较高，需要同构主机
普通
某些软件免费，如DataGuard
复制软件
IBM PPRC
EMC SRDF
HP CA（Continues Access）
HDS TrueCopy
Brocade Tapestry DMM
UIT SVM
EMC VSM
原厂技术：
IBM AIX LVM
HP-UINX MirrorDisk
Sun Solaris SVM
专业复制软件：
Symantec SF/VVR
Oracle DataGuard
Oracle GoldenGate
DNT IDR
DSG RealSync
Quest SharePlex
　　操作系统数据复制选取是系统自身镜像复制技术，或者安装第三方软件来进行镜像复制，对于操作系统会导致比较大影响，对IO压力很大，因此本次项目不考虑使用此种技术。
　　依照顾客既有设备状况，最后选取存储复制方式来进行本次容灾最后核心技术，由于在核心数据库中，访问量很大，因此在存储复制同步，咱们采用数据库复制技术，将核心数据库进行了同城数据库复制技术，并采用数据库复制软件，完毕了核心数据库读写分离。
　　在网络方面，同城采用DWDM方式连接，容灾中心采用fcoip方式进行了连接，在网络层面采用OTV技术，使两地之间“二层”打通，为后期实现双活数据中心打下了良好基本。
1.1.3 生产中心整合
　　1.1.3.1 容灾中心SAN存储系统目的架构

　　存储系统目的架构描述：
　　?A-以核心边沿拓扑为主双Fabric SAN架构；
　　?B-支持分层虚拟化存储系统，涉及不同级别磁盘系统和磁带备份设备，虚拟化设备，所有设备连接在核心互换机上；
　　?C-服务器资源池，支持各种类型Unix和x86服务器，通过边沿交
　　换机与SAN相连；
　　?D-高IO需求服务器与核心互换及直接相连，直接访问磁盘存储，例如NAS网关，备份服务器等；
　　?E-管理服务器，提供对所有存储系统组件统一监控和管理；
　　?F-管理网络，提供管理服务器和各种不同存储系统组件通讯。
　　SAN网络目的架构：
　　采用核心-边沿架构二级布置模式，核心互换机连接存储设备，涉及磁盘和磁带库设备，边沿互换机连接服务器。

　　分级存储系统目的架构：
　　核心业务系统构造化数据布置在高品位存储设备上。
　　重要业务系统数据布置在中低端存储池。
　　业务系统数据保存在磁带库环境中，涉及虚拟磁带库和物理磁带库。
　　备份系统目的架构：
　　业务系统数据备份采用数据先备份到虚拟磁带库上，之后再导出/迁移到物理磁带库上作离线保存。
　　核心业务系统单独配备一张HBA卡，用作备份环境链路，和生产环境存储业务数据流量进行隔离。
　　对于采用LAN备份方式业务系统，建立独立LAN环境，避免与生产LAN环境产生资源竞争状况。
　　1.1.3.2 SAN优化整合设计原则：
　　?SAN架构采用核心-边沿架构，冗余双Fabric网络；
　　?从冗余性和高可用性考虑，每个边沿互换机到核心互换机之间ISL级联至少采用两条ISL级联线；容灾中心采用ISL Trunking；依照现状考虑布置ISL Trunking(对于数据库存服务器较多，较多高带宽流量主机（例如单个主机带宽流量>200MB/s ）；
　　?Core核心互换机界定，所选Core互换机端口数量不少于160口； 对于高带宽流量主机（例如单个主机带宽流量>200MB/s ）可以直接连接到 Core互换机，其他主机通过Edge互换机接入，向目的架构演进；
　　?对于同城容灾SAN环境，同城生产中心和容灾中心之间 距离在10公里内，通过互换机直接ISL连接，本次SAN优化生产中心SAN网络需要与其他业务SAN实现统一，则SAN融合后整个SAN网络规模较大，中间链路波动会对生产端SAN环境有影响，建议考虑同城生产中心和同城容灾中心之间布置SAN Router，对生产和容灾中心进行隔离;
　　?整合时需要考虑品牌，FOS及DOMAINID等。
　　针对SAN网络优化整合方案，其收益分析如下：
　　?构建公司级统一SAN网络架构，架构简朴，依照业务需要灵活扩展
　　 当前SAN网络按业务系统独立布置，存在各种SAN孤岛，不利于资源共享
　　?满足下一步数据级容灾规定
　　 统一SAN网络架构，利于后续数据级容灾工作实行
　　 实现FCIP设备共享，节约投资
　　?实现集中公司备份环境
　　 采用基于LAN、LAN-Free备份方式，提高备份效率，
　　 减轻对备份窗口紧张压力
　　?统一管理
　　 建立统一SAN基本架构进行统一监控管理
　　现状存在如下问题：
　　?SAN架构复杂，存在各种坚井式SAN网络孤岛
　　 不利于资源共享
　　?备份效率不高
　　 无法实现基于LAN-Free备份
　　?管理复杂，维护困难
　　 各种孤立SAN网络环境，不利于统一监控和维护
　　1.1.3.3 存储整合方案
　　从数据库角度看，通过前期调研显示公司共有27个物理数据库，其中除人力资源应用系统外所使用数据库都是Oracle 10g（15个，超过95%），物理数据库所使用操作系统绝大多数都为AIX(37个)，别的都为HP-UX操作系统(18个)和windows及linux操作系统(8个)。
　　从实现方式角度，当前数据库除3套采用HA方式实现，12套采用Oracle RAC，12套在单机上安装Oracle。
　　容灾系统建设通过前期征询、现状调研分析、目的架构初步设计等阶段，在充分理解既有环境基本上，如下述内容作为设计原则与前提条件：
　　§ 以业务影响分析作为容灾方略选取重要根据；
　　§ 以应用影响分析和现状调研分析作为容灾方案需求；
　　§ 参照国信办《信息安全技术信息系统劫难恢复规范》、《信息系统劫难恢复规划及实行》、银行业金融机构信息系统管理指引、证券公司集中交易安全管理技术指引和人行发布《银行业信息系统劫难恢复管理规范》--JR/T 0044-；
　　§ 综合考虑目的架构设计、容灾中心总体设计内容作为数据级容灾方案设计约束和输入；
　　基于以上多维度分析结论，综合成本（详细成本数据略）、及容灾实行对运营影响、实行风险及将来应用级容灾考量，拟定采用数据库复制与HPXP24000存储虚拟化复制相结合容灾复制核心技术。
　　系统容灾级别拟定为核心A+或A采用应用级容灾技术，其她容灾范畴数据采用存储虚拟化复制技术实现数据级容灾。容灾中心同步配备HPXP24000，在生产中心中，依照既有高品位存储类型，使用既有高品位存储存储虚拟化复制技术。
1.13.4 容灾数据复制设计方略
　　1) 对既有生产影响小
　　容灾数据复制技术设计，不应引起生产性能大幅下降、也不应对既有对生产环境中系统、应用、数据类型和整体构造产生较大改动。尽量选用适合生产环境数据复制技术和模式，减少对生产系统影响。
　　2) 多对一、容灾资源共享
　　对性质和类型（数据类型、存储位置、数据属性）相似或相近数据尽量采用相似数据复制技术。采用多对一数据复制技术，实现灾备中心资源共享，提供资源运用率、便于后期运营维护管理。
　　3) 健壮性、稳定性、容错性
　　数据复制技术和数据传播链路设计要充分考虑其健壮性、稳定性和容错性。数据复制链路设计要尽量考虑高可用设计保证数据持续保护。
　　4) 数据完整性、一致性
　　数据复制完整性、一致性是数据复制保护核心考量点，需要咱们在设计数据复制技术时候充分考虑，不漏掉数据，容灾中心数据要具备一致性和可用性。
　　5) 精简数据、节约空间和带宽
　　对非业务数据，例如操作系统数据，应用程序等，不纳入容灾保护范畴，以达到节约磁盘空间、减少复制带宽。在不影响生产性能前提下，数据传播考虑启用压缩功能，提高带宽资源运用率。
　　6) 集中复制
　　结合优化整合工作，在合理范畴内，采用数据集中、存储集中、集中复制方略。
　　7) 数据复制安全性方略
　　数据已经作为当代公司IT架构最核心某些，其在寻常备份数据迁移和转移、数据远程传递复制过程中，数据安全须符合有关规定。
　　8) 数据恢复、演习
　　容灾方案设计必要考虑数据恢复性和可演习性。
1.1.4 灾备系统投产
　　灾备系统投产前需要完毕如下环节：
　　1、容灾中心数据初始化
　　数据初始化有各种办法，本次方案中采用存储复制技术。
　　2、容灾中心应用级容灾搭建
　　相应生产中心，将容灾中心网络，应用服务器，数据库服务器，支撑服务器统一搭建。
　　3、容灾中心应用级系统测试
　　针对容灾中心应用环境，进行业务测试，保证明现所有设计方案中应用场景。
　　4、容灾中心运维
　　容灾中心运维不但仅是针对既有设备巡检这样单一，需要涉及如下几点：
　　1、硬件设备正常运营。
　　2、复制链路定期查询。
　　3、生产中心新购设备追加。
　　4、生产中心应用升级等。
1.1.5 演习
1.1.5.1 演习目的
　　灾备系统建设完毕后，灾备系统劫难恢复预演是证明系统可用性最有效手段。劫难恢复演习通过模仿劫难发生时环境，对劫难恢复有关人员、劫难备份系统和劫难恢复筹划进行一次全面检查和验证。
　　演习目的为：
　　l 确认劫难备份方案实行完毕，并检查其可用性；
　　l 检查在灾备中心远程数据复制系统有效性；
　　l 检查在灾备中心备份通信网络系统可用性；
　　l 检查参加劫难恢复演习网点可成功恢复商定业务；
　　l 检查劫难恢复时间与否在商定期间目的之内；
　　l 检查劫难恢复预案中流程、规程和操作文档有效性；
　　l 检查劫难备份中心场地、人员组织、设备和设施与否按合同商定范畴提供了劫难备份服务能力。
　　1.1.5.2 演习覆盖范畴
　　无论真实切换还是模仿切换演习，演习业务范畴都将限于一定业务某些，因而两种演习方式所能覆盖业务范畴是一致。
　　演习验证效果
　　l 真实切换演习：直接将生产系统切换至灾备系统，由灾备系统接管生产系统运营，在演习完毕后，再将灾备系统回切至生产系统。该方式可以直接验证灾备系统可用性。
　　l 模仿切换演习：在演习期间不中断总部电脑中心生产系统运营，采用有效方式模仿劫难场景，启动灾备系统，选用某些分支网点切换至灾备系统完毕演习内容，验证灾备系统可用性。
　　演习对生产影响
　　l 真实切换演习：由于劫难备份系统业务范畴为核心业务，因而切换至灾备系统运营期间必然导致某些业务无法对外提供服务，涉及某些核心业务以及重要服务渠道。此外，真实切换必要进行系统回切（重要是数据环境回切），回切期间全行业务都将中断对外服务。因而，真实切换演习将会对生产业务导致较大影响。同步开放平台采用数据冷备份，系统回切难度大，恢复时间较长。
　　l 模仿切换演习：通过一定技术手段模仿总部电脑中心劫难，演习过程仅会对参加演习分支网点业务导致影响；并且通过合理选取演习时间，可以将对生产业务影响降到最低。模仿测试无法与外联单位联测。
　　演习实行风险
　　l 真实切换演习：该方式涉及范畴广，实行过程复杂，对生产系统影响大，演习方案除了需要验证灾备系统有效性之外，还要充分考虑过程中也许对生产导致影响以及有关应急办法。因而，该演习方式实行风险较高。
　　l 模仿切换演习：无论发生何种问题，都尚有回退空间，并且不会对真实业务导致任何损失。该方式实行风险较低。
　　1.1.5.3演习审核评估
　　在演习结束后，将对本次演习中各参加部门和演习网点各演习工作记录进行汇总，对各某些汇总记录和数据进行统一分析和评估后，对本次演习成果进行提出客观总结报告，并对所需注意和改进方面提出切实可行建议。
　　随后，对劫难恢复预案中有关文档及操作手册进行修改和完善，将劫难恢复预案正式定稿，并组织下发到各关于部门及人员。