andy090909
作者andy0909092020-03-10 18:19
系统工程师, 盛京银行

城商银行关键业务基础平台同城容灾设计方案

字数 5561阅读 4375评论 0赞 5

一、 摘要

为提高防范和抵御业务信息系统风险的能力,保证重要信息数据在灾难情况下的完整性、安全性、可靠性,保证银行业务的连续运作,城商银行应该建立同城灾备中心,对关键业务系统进行容灾保护,完成两地三中心布局:即生产中心、同城灾备中心、异地灾备中心。

本方案设计的关键业务基础平台同城灾备中心目标,达到国家灾备等级 5 级以上,达到灾难恢复点目标 RPO<5 分钟,灾难恢复时间目标 RTO<2 小时。覆盖银行关键业务信息系统,全部网点均需接入,处理能力与生产中心匹配的高标准灾备数据中心。

在当前银行业面临互联网和大数据的高速发展,以及利率市场化的快速推动下,对银行 IT 系统提出了全新的要求,互联网、大数据、移动、社交、智能等都成为银行 IT 系统规划和建设要考虑满足的应用场景。这就要求银行综合业务系统、大前置平台、综合柜面平台等关键业务基础平台能够满足稳定健壮运行、能够实现应用分布式部署、应用全局负载均衡,同城应用基础平台故障隔离,避免分布式应用节点同时故障。

本方案在 IP/SAN 网络设计方面,两中心间通过采用裸光纤连接起来,构成一个拉伸的局域网。两中心间每层网络设备都组成高可用集群,每个中心网络区域完整,两中心网络设备对称,网络区域对称。

主机、存储与容灾软件设计选型上,本方案创造性的借鉴 IBM 大型机上 IBM Z HyperSwap 双活方案的设计思路,是目前基于 Power 平台最高端的高可用及容灾解决方案。

主机选型采用 IPS K1 Power 服务器,存储与容灾软件采用基于 DS8000 系列的同步复制( Metro Mirror ) +PowerHA7.1 (含 Hyperswap )的解决方案。

应用系统部署方案设计方向为,应用支持多节点多活部署模式,分布式部署在同城灾备数据中心和主中心,最终实现应用系统双中心多活最佳状态。关键业务数据库服务器采用支持双活的 Oracle RAC ;

构建本同城容灾方案最大的难点在于数据的实时同步, PowerHA7.1 (含 Hyperswap )依赖高端存储的底层同步技术与可靠的同城双数据中心间裸光纤互联,创造性地为开放平台提供了实时同步与自动切换,为同城容灾数据中心的实现提供了有力保障。

二、 背景描述

建立容灾系统是当前各级监管部门对银行业的强制性要求 , 部分城商银行已经完成建立异地灾备数据中心,异地灾备中心实现了部分业务应用的数据准实时同步。但异地灾备中心覆盖的业务系统不够全面,数据同步不够及时,数据实时灾备要求不高,只能满足阶段性的需要,与城商银行的业务连续性要求还有差距。

生产中心核心应用采用 Power 服务器连接独立的 IBM DS8800 高端存储架构,但没有启用双存储同步实时复制技术,一旦该存储故障必将影响核心系统正常运行,存在核心数据丢失风险。

此次方案设计将建设同城灾备中心,完成城商银行两地三中心布局。同城灾备中心相比异地灾备中心建设标准更高。采用跟同城生产中心对等的网络、服务器、存储基础架构,形成双中心双存储数据底层实时复制,建成后可以大大增强城商银行抗风险能力。

三、 解决方案

本方案在前期做了大量准备工作,包括详细对比了当前主流灾备技术,双活中心网络架构与系统架构选型、双活中心可行性分析、双活方案风险分析等,形成了本同城灾备中心容灾方案。决定采用基于存储 DS8800 的同步复制( Metro Mirror ) +PowerHA7.1 (含 Hyperswap )的解决方案。

同城两个站点逻辑架构 在同城的两个数据中心设计中,同城数据中心网络分区与生产数据中心对等,也分为服务输出层、核心路由层与服务请求层。两中心间以太网、 SAN 都通过裸光纤实现互通。以太网部分,两中心相同分区间通过两组千兆高性能交换机打通;两中心间三层交换机互通,核心路由器互通。服务请求层中的七个接入区除办公接入区、离行办公接入区外都需在同城数据中心实现接入冗余。

1)、核心区数据库层设计 :在同城两个中心之间设计成双活运行模式,需要网络、主机、存储、管理软件及应用软件的协调和配合,在城商银行同城容灾方案里,包括了 PowerHA HyperSwap + oracle RAC 双活方案,运行在 Power 平台并承载核心数据库系统。

2)、核心区应用层设计: 对于关键业务核心群应用的运行从高性能、高可伸缩性与低价格三方面考虑,应用系统采用虚拟化云平台方式部署。通过虚拟机实现资源灵活分配,提高资源的合理利用,系统横向扩展方便。系统维护工作量小,方便系统迁移及灾备。

虚拟化是资源高度集中的硬件环境,为避免存储单点故障引起整体瘫痪,存储将采用双存储方案,在主备两个数据中心分别部署存储并做实时同步复制。

将虚拟化云平台 X86 服务器,分为两个独立的物理资源池,将应用平均分布在两个物理资源池中,外部通过相关设备进行负载均衡关联,如果一组设备出现问题,可通过负载设备进行隔离,以降低物理设备故障对系统的影响。

HyperSwap A-A 系统逻辑架构 城商银行的核心数据库双活方案采用的是 IBM PowerHA HyperSwap A-A 解决方案,部署 Oracle 的 RAC(Real Application Cluster) 三节点。系统逻辑架构图如下图所示:

HyperSwap A-A 系统逻辑架构图

下面为在此架构的描述:

1 .主站点有三个节点(两个是 RAC 节点,一个是仲裁节点),备站点有两个节点(一个是 RAC 节点,一个是备份的仲裁节点);

2 .两个站点各有一个 DS8K 存储

3 . Oracle RAC 有三个 voting devices, 其中两个分别来自存储 Storage A ( DS8800 )和 Storage B ( DS8870 ) , 都没有激活 hyperswap 功能,第三个来自仲裁节点的 NFS 文件系统( NFS 文件系统同时只会有一个激活)

4 .主 NFS 文件系统是部署在一个单独的分区上,该文件系统创建在基于 lvm mirror 基础上的 VG ,该 VG 包含一块内置盘,还包括一块来自 Storage A 的盘(非 hyperswap 盘 ,Vote3 ),这块 Vote3 的 LUN 通过 DS8K PPRC metro mirror 同步技术与 Storage B 上的另一块盘 (Vote3’) 进行同步;该 NFS 文件系统正常情况下处于运行状态

5 .备站点的备份仲裁分区也是一个独立的分区,配置了 NFS 文件系统,当主站点出现故障时,临时用来作为 Oracle NFS Quorum 所在的节点;该节点访问 Storage B 上的 Vote3’ LUN 并以此创建 VG ,在正常情况下,由于 Vote3’ LUN 处于 Target 模式,不能直接读写,所以正常情况下,该 VG 不会 varyon ,只有当主站点全线瘫痪,需要仅启动备站点的服务的时候,才会手工激活该 VG ,并将 NFS 服务投入使用。

6 .每个节点都有 4 条链路,每条链路都能访问每个存储,并将盘的访问策略设置为 round_roubin ;这样在正常情况下,四条链路上都会有负载,可以充分发挥链路的性能。

系统关键技术特点:

1 、对所有应用的磁盘访问方式透明

不同的应用软件访问磁盘的方式有所不同,例如 Oracle RAC 直接访问裸盘, Informix 数据库访问逻辑卷 (Logic Volume) 或文件系统,中间件软件访问文件系统等,如果能通过一种技术能对应用的磁盘访问方式透明,那将提高系统的健壮性和减少运维的技术及人员要求。

PowerHA HyperSwap 方案中对磁盘的管理是基于裸盘层面的,对上层应用如何使用这些盘不关心,所以这是一种平台级的解决方案,满足企业级的高可用及管理的要求。

利用稳定的两个中心来最大限度保证高可用

在设计双活数据中心时,不可避免需要讨论仲裁的设计,因为在发生两数据中心之间链路故障时(称之为脑裂故障),需要通过稳定的仲裁机制判断由哪一个数据中心来继续提供服务,这样才能保证数据的一致及服务的及时恢复。

本设计方案要求城商银行有两个同城数据中心,线路距离在 10KM 以内;在本期双活方案中,期望把仲裁站点的设备放置在同城两个数据中心内;要求尽可能在各种故障场景下,优先保证 Site1 存活;只有当主站点完全瘫痪时,可以通过手工干预的方式在短时间内将 Site2 投入使用。

2 、 满足存储故障不影响业务的需求

城商银行的重要数据基本都放置在方案中的两个 DS8K 存储上,虽然两个存储之间的数据是相互备份的,但是在发生某一存储故障时,如何让另一存储的数据尽快投入使用,并且不存在数据不一致的情况。通过采用 PowerHA HyperSwap 技术,确保在任意一个存储出现故障时,业务最多只有 <30 秒的暂停时间,随后业务就继续提供服务了。这一特性保障在存储故障时 RTO<30s, RPO=0 。

3 、 RAC 的仲裁机制与 PowerHA 的仲裁机制结合

在一个双活方案中,往往会出现两种或更多的仲裁机制,如何能让不同的仲裁机制协同工作是非常重要的话题。在基于 PowerHA HyperSwap 的 Oracle RAC 的双活解决方案中, Oracle RAC 的仲裁机制和 PowerHA 的机制相互默契配合,在不同的故障中发挥作用,保障业务系统的稳定可靠。

四、 方案实施效果

系统性能是生产环境非常关注的内容之一,通过对 PowerHA HyperSwap 的原理分析,并结合城商银行实际的链路环境,下面通过正常运行时性能及故障发生时的性能影响进行描述。

正常运行时性能描述

部署了 PowerHA HyperSwap 之后,不改变应用访问存储的方式,对存储的聚合管理是通过升级后的 MPIO 驱动实现,该驱动是 AIX 操作系统自带的,不存在任何的虚拟层,所以 PowerHA HyperSwap 不会影响系统的性能。

在实验环境的压力测试过程中,站点之间的 FC 链路及 Ethernet 链路都满负荷运行,并且能持续运行(在测试中,模拟了 24 小时的稳定压力测试);测试环境中的 Oracle RAC 及应用系统均表现稳定。

故障发生时的性能影响

在发生主存储故障之后,由于 PowerHA 会将主存储切到 Site2 站点,这样, Site1 站点的应用需要通过站点间的链路来访问 Site2 的存储,会带来一定时间的延迟。

由于城商银行两数据中心之间的线路距离只有不到10KM,通过直连的方式连接,并且带宽很充足,线路质量很好,所以在压力测试过程中,基本看不出性能的衰减。

基于 PowerHA HyperSwap 同城双活数据中心系统优势:

1 、灵活的应用级中心切换 , 提高了双活中心的可用性。

双活中心的高可用性通过以下三个特点展现:

对支持双活的应用来说,同一时间两个中心都是生产中心,这是真正意义上的双活模式,不存在切换一说 ;

对不支持双活的应用来说,同一时间只有一个中心是生产中心,另一个中心是主备模式,但此方案支持以应用为单位做中心间切换,所以从整体看,两个中心都有生产系统,宏观上是双活模式 ;

支持以中心为单位做中心间切换。在灾难情形下,一个中心就能接管全部业务,可以把全部业务放到一个中心运行。

2 、 双活中心抵御风险的能力时刻在得到验证,降低了中心切换复杂度,增加了灾难应对的可靠性。

传统的灾备模式有天生的缺陷,那就是随着时间的推移,数据中心间配置不一致与操作生疏感在不断累积和暗藏,灾备中心的可靠性通过每年有限次的、定期进行的灾备切换演练来验证和保证,但是次数再多准备再充分的演练也难以规避天生缺陷带来的操作风险,灾备中心的可靠性大打折扣。相较前者,双活中心时刻处于实战中,运行能力时刻在得到验证,可靠性更高。

3 、 一键式计划内切换,降低了常规应急演练费用与数据中心运行维护费用。

对于非双活应用,需要定期做中心间计划内切换, HA7.1 传统功能可完成主机切换, Hyperswap 作为 HA7.1 的一个新功能,继承了 HA 操作简洁的特点,一键式完成存储主备切换 。常规的应急演练如同日常操作,不再神秘。对计划外切换, HA7.1 能根据故障情形自动完成。

4 、 双活中心近零的 RPO 与极小的 RTO , 在灾难情形时,能极大的减少银行的经济损失与信用损失。

依赖于 IBM DS8K PPRC MetroMirror 写事务机制的良好特性,灾难时,中心间数据 RPO 理论上为零,实验室与现场测试得结果也为零,近零的 RPO 与极小的 RTO ,确保灾难恢复的可靠性,直接的提升银行信用与客户信心,减少银行经济损失。

五、 方案设计经验总结

本方案设计是 IBM 北京实验室技术专家、荣科科技技术骨干、和阜新银行 IT 专家多方研讨的结果。在详细学习了解当前主流同城灾备方案基础上,采用本集成方案设计的同城灾备中心,其设计方案合理可行,整个过程安全可控,方案设计过程中积累了详实的技术资料与实验室测试实施痕迹,方便了日后的运维管理与学习。

同城容灾数据中心的技术方案经历了实验室、城商银行内部环境测试、内部演练重重测试,测试用例细致周全,基本覆盖所能想到的各种风险情形。结合测试用例与测试结果,形成了完整详细的用户手册与灾备预案,具有很强的指导性与操作性。

同城容灾数据中心高可用软件简洁的管理界面,简化了各种切换操作,降低了操作风险,方便了技术人员的管理工作。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

5

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广