从灾备到双活:运维管理新挑战

2017/12/13 10:21

提到双活,大家往往会和灾备联系起来,而且容易混淆一些概念,确实双活是由灾备发展而来,可以说双活起源于灾备,但其实际更多是融合于生产,只有这样理解才能真正做好双活。本文对灾备和双活的区别以及如何做好双活进行了综合分析。

一、整体架构

灾备体系经过多年发展,已非常完善,有健全的法律法规和建设标准,以及各行业和企业都建有不同级别的灾备系统,而双活是新提出的数据中心架构模式,没有相关建设标准和法规,实施案例在国际和国内都非常少。灾备和双活在整体架构上的区别主要是灾备区分一主一备,而双活不区分主备,两个中心同时生产并互为灾备。这里所说的是严格意义的双活,对于具体应用而言,需要实现负载均衡、数据同步、应用集群、具备相互接管能力。

严格意义的双活和高级别灾备很类似,即高级别的灾备是双活的初步模型。关于灾备等级划分,目前在国际上主要是SHARE78,在国内主要是国标《信息系统灾难恢复规范》(GB/T20988-2007)。从两个标准对最高级灾备等级的描述可以看出,我们对双活和对最高级灾备的要求要点大致相同,最大的区别是双活要求两个中心实现同时生产、做双活的应用必须动态负载均衡、故障或灾难发生时另外一端自动接管。国标第六等级灾备和严格双活的整体框架对比见表1。

新知图谱, 从灾备到双活:运维管理新挑战

二、技术架构

从整体架构层面可以看出,双活比灾备复杂得多,在技术架构层面更是如此。对于技术架构,数据复制是灾备建设的技术架构核心。数据层的复制主要利用存储复制、数据库复制等技术,除数据层外其他层面在技术架构上主备中心之间基本是独立的,因此灾备实施主要是数据复制的实施。而双活的技术架构要比灾备复杂很多,其要求在信息系统的所有层面都进行双活设计。

整体技术架构:要求两个中心都为生产中心,都部署生产(负载比例视不同情况而定),实现负载均衡,同时两端保障数据一致,在发生故障或灾难时自动进行生产切换;访问接入层:需要进行全局的站点轮询、负载均衡设计;Web层、应用层:需要进行集群和负载均衡设计;数据库层:需要保证两端数据完全一致,零丢失,并同时可读写、可自动切换;系统平台层:实现集群设计;存储层:实现数据一致,可自动切换;网络层:实现两端部署一致,可完全自动切换接管,实现统一的安全管理。

三、运维管理

上面提到双活的技术架构比灾备建设复杂很多,但实际更为艰巨的挑战是双活的运维管理,主要体现在以下几个方面。

1.运维工作量的大量增加

对于生产人员来说,实施双活后需要运维两端的生产,网络管理员运维两端的生产网络、系统管理员运维两端的服务器和存储、数据库管理员运维两端的数据库、应用管理员运维两端的应用,基本上工作量变成了两倍。此外还要运维两端的双活设计,例如数据库管理员要监控管理两端的数据库实时复制情况等,对于生产人员来说工作量至少增加了一倍以上。对于灾备而言,主备两端可以是两套人马,通过灾备管理机制实现良好的运维管理。而从经验看,要让双活运作起来,双活两端必须都由生产人员进行管理,两端的资源统一管理,对于同一个应用系统应该是同一个团队进行运维管理,保证两端在各个层面完全一致,需要将双活看作是生产的延伸而非传统的灾备。

2.运维标准的高要求

在技术架构分析中提到,灾备主要是在数据层面要求主备之间的实时互动,而其他层面比较独立,因此对于灾备运维人员而言,运维工作较为简单,表现在生产端的部分变更、架构调整甚至不影响灾备端。而双活的运维标准要求非常高,对于所有层面、细节的调整、变更都需要关注并进行相应的调整和变更,只有这样两端才能保持完全一致并能实现自动接管。

3.对配套管理的影响

双活对数据中心整体运维管理有很大影响,不仅体现在上述生产系统运维本身,也体现在配套管理上。一是对于数据备份管理,传统上只有一份生产数据,因此直接在生产数据上进行备份,而双活有两份生产数据,只需要选择一端进行备份即可,而且可以适当考虑与批处理、性能压力、运维窗口等因素进行合理备份。二是对于监控管理,首先是监控范围扩充了需要监控双活两端的生产,还需监控数据复制等情况;其次是监控报警机制需要进行大的变化,例如对于应用软件的监控只有两端都宕机了才是严重报警。三是对流程管理也有影响,相关的事件管理等需要进行一定改动,例如双活一端的数据库宕库不是严重事件只是重要事件等。四是对安全管理,双活的安全管理要严格于灾备,要求两端实现统一的安全管理并采用相同标准,包括物理安全、网络安全、系统安全、安全配置、访问控制、人员安全等方面。

对于运维管理而言,很多方面都和传统的机制有所不同,需要进行适当改造,以适应双活架构下的运维管理。

(文章来源:金融电子化)

更多新知

知识库

已收录新知