首页  ·  知识 ·  基础设施
容灾整体流程经验分享
王兴蓓  收集  数据中心  编辑:Harriet   图片来源:网络
本文结合企业灾备需求,从容灾及复制技术的选型入手,重点阐述了容灾技术的目标架构,SAN网络优化整合的设计原则,并给出了存储整合与数据复制方案,也谈及了演练涉及的核心环节。

灾备的起源最早是数据备份和恢复,之后是业务应用系统的备份,在这个基础之上,将业务的因素考虑进去,业务的连续运营成为企业追求的目标;从而又引入了业务影响分析、风险分析和建设规划等。业务的恢复涉及到很多业务的流程、资源的调配、人员和组织架构的优化及恢复的策略等多个方面,称之为业务连续性规划。

  目前在数据保护方面,某企业重要业务系统整体架构已实现本地高可用性, 系统关键服务器(数据库服务器、应用服务器)均已实现双机或集群;已基本建成重要业务系统本地数据保护机制,具备较完善的本地数据备份手段,核心业务数据已做到定期备份(全量/增量)和定期进行备份恢复测试。

  机房现状方面,生产中心机房空间资源比较紧张,需要进行空间资源调剂;同城灾备机房空间使用也越来越紧张;异地灾备机房已经在建设中,可以满足几年内的异地灾备建设机房需求。

企业灾备需求

  某企业众多的业务系统中,由于前期都是分批进行搭建,每年产品选型也都有变化,业务系统的主机包括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-2008;

  § 综合考虑目标架构设计、容灾中心总体设计的内容作为数据级容灾方案设计的约束和输入;

  基于以上多维度分析结论,综合成本(具体成本数据略)、及容灾实施对运营的影响、实施风险及未来应用级容灾的考量,确定采用数据库复制与HPXP24000存储虚拟化复制相结合的容灾复制关键技术。

  系统容灾等级确定为核心A+或A的采用应用级容灾技术,其他容灾范围数据采取存储虚拟化复制技术实现数据级容灾。容灾中心同时配置HPXP24000,在生产中心中,根据现有的高端存储类型,使用现有高端存储的存储虚拟化复制技术。

1.1.3.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演练审核评估

  在演练结束后,将对本次演练中各参与部门和演练网点的各演练工作记录进行汇总,对各部分汇总的记录和数据进行统一分析和评估后,对本次演练结果进行提出客观的总结报告,并对所需注意和改进的方面提出切实可行的建议。

  随后,对灾难恢复预案中的相关文档及操作手册进行修改和完善,将灾难恢复预案正式定稿,并组织下发到各有关的部门及人员。


本文作者:王兴蓓 来源:网络收集
CIO之家 www.ciozj.com 微信公众号:imciow
    >>频道首页  >>网站首页   纠错  >>投诉
版权声明:CIO之家尊重行业规范,每篇文章都注明有明确的作者和来源;CIO之家的原创文章,请转载时务必注明文章作者和来源;
延伸阅读
也许感兴趣的
我们推荐的
主题最新
看看其它的