·2019-09-20 11:18

系统架构师·银行

中小银行数据库双活技术路线选型分析及架构设计实践分享

字数 5230阅读 6381评论 7赞 16

## 摘要：

老数据中心数据库运行在 AIX 、 Linux 、 Windows 、 ESXI 系统上，场景复杂、系统混用、版本不同、平台多管理复杂，技术难点随之增多，运维压力大，急需一个集中化资源池来承载银行重要生产系统数据库，能够统一化管理。在新的数据中心，企业基于 LinuxONE 平台实施了 Oracle Extend RAC 数据库双活技术，实现了各个基础平台双活，并通过部署 Vertias 的容灾管理平台实现 RAC 站点级一键流程化切换。项目最终建设效果，保障了数据库一致性，提高了容灾切换能力，减少了应用变更操作，减少了业务部门数据验证环节。

## 一、数据库双活建设的行业背景、建设现状与趋势

我行外围系统数据库现有 33 套及新建系统数据库 15 套，数据库共计 48 套，按我行生产系统分类定级标准的业务连续性要求规划，在新机房中 1 、 2 级系统数据库将采用稳定性架构（如： Oracle RAC 、 Oracle ADG 等技术）。老机房数据运行在 AIX 、 Linux 、 Windows 、 ESXI 系统上。场景复杂系统混用、版本不同、备份方式各异等不规范现象，平台多管理复杂，技术难点随之增多，运维压力大。急需一个集中化资源池来承载银行重要生产系统数据库，能够统一化管理。

新机房建设将统一标准化，软硬都将统一标准，统一集中化管理，统一场景，集中技术力量保障，避免过于分散技术人力资源。考察其他银行建设经验与规划，趋向选择根据数据库集中化管理是最具性价比的首选方案，技术实现方式有 x86 虚拟化技术与 LinuxONE 整合方案以及 PowerVM 方案，几种技术各有特色。

规划建设目标，建设数据库资源池，能够统一高效管理全行数据库。

## 二、数据库双活建设的需求分析

**建设需求有如下几点：**

1 、监管需求，无论什么样的数据库高可用方案必须满足监管对业务连续性的要求指标，能够提供更优的 RTO 与 RPO ，并且保障系统数据一致性。数据库双活优于主备模式。

2 、数据安全需求，业务数据一致性是系统的关键，跨站点的数据库集群，可以通过 Oracle RAC 集群机制来保障数据一致；而普通常用的 ADG 同步模式难免出现同步异常，又需要重新 ADG 同步，并且 ADG 同步有一定时延（与网络传输质量挂钩），当主库异常而日志未完成同步时备库有数据丢失。切换后的数据补录通常很繁琐。

3 、业务层面需要，业务都倾向科技部门保障数据切换快，数据无丢失，业务恢复后不担心账务数据问题。站点切换只需要业务参与功能确认即可。不再担心业务数据丢失情况。大多中小银行的系统切换数据验证是一件繁琐枯燥又责任重大的事。

4 、基础平台架构需要，新机房建设架构设计，一是应用服务通过应用交互实现双中心调度，二是存储层面实现了双活，具备双活数据库基本条件。三是网络可提供稳定的大二层网络。

为了与应用双活配套提供更好的服务，我们自身基础架构平台需要双活数据库来配套完善。

5 、应急容灾需求。为了实现数据 0 丢失，建设数据库双活能够很好解决这类问题，数据库双活 OracleExtendRAC+ADG 无疑是完美解决方案。双活数据库搭配应用交互可满足各种应用灾难场景应急，可满足站点级别灾难应急，从而保障业务不受太大影响。

**建设难点分析：**

1 、基础平台实现难。多家运营商提供独立光缆链路（配置足够多裸纤）；数据库双活需要极其稳定的波分链路保障对波分管理监控应急处置及时；极其稳定存储双活保障，第三站点存储仲裁能够在各种场景做出正确判断（ SAN 发生链路抖动能够自动抛弃不稳定链路）；稳定的大二层网络保障，为 RAC 集群提供同段 IP 网络；保障各个链路时延都不超过 1ms ，成功案例的版本选择。

2 、硬件平台选择难，无真实测试数据。

硬件可选平台有 Power 、 x86 和 LinuxONE ，需要从开放性、稳定性、安全性、运维压力、费用等多方面考量，结合自身运维体系选择最适合的平台。

3 、技术实施难度大，测试复杂，协同配合复杂。双活数据库 RAC 安装参数调整较多。各种高可用测试涉及环节多场景复杂，涉及存储同步效率、存储故障及仲裁判断；涉及操作系统、多路径测试；涉及网络等故障 ;RAC 自身集群等测试。涉及系统、网络、存储、数据库等方面工程师的集体配合，协同合作，一些问题排查也需要各团队合作，有时候问题交流不对称容易推诿扯皮。

4 、监控管理难。稳健的系统建成后的监控管理往往容易麻痹大意，双活数据库横跨涉及面广系统、网络、存储、数据库四方面都必须每层监控到位，任何一层监控盲区都会造成潜在风险。

5 、授权许可难题，大量的数据服务器采购会导致 Oracle 数据库 license 授权许可法律纠纷，无法规避。

## 三、数据库双活的技术路线选型

经过综合对比后我行选择 LinuxONE 平台建设数据库资源池。

使用 3 台 LinuxONE 主机配置 32 核 3T 内存，对 1 、 2 级重要的业务数据库进行集中承载。

双活数据与主备数据库测试对比。

1 、在规划初期使用 RAC+ADG 方式容灾，优点 : 主机房两节点 RAC 管理风险小，可靠性高，成功案例多，同城灾备用 ADG 能够保障数据丢失为分钟级别， RPO 可满足监管指标；缺点 :RTO 受人为操作因素控制较大，不能保证每次切换十分顺利，应用需要修改连接字符串 IP 、服务名、实例名，修改节点较多容易出现操作失误。

建设初期在网络集成，存储双活集成过程中测试效果基本满足生产需求， RAC 与 ADG 切换，大多应用系统负责人修改连接参数应接不暇，切换配合紧密度太高，不是特别理想，时有修改失误发生。

2、 当网络与存储双活集成完毕后，波分链路理想，双活存储指标理想，大二层网络效果好。经过综合分析 , 为了满足业务需求将在 LinuxONE 平台采用 Extend RAC+ADG 模式部署，主机房 2 节点，同城灾备机房 1 节点，外加 ADG 节点，经过集成实施后，数据库各方面表现均良好。 3 节点 RAC 集群与单机房 2 节点没有大的性能差别，完全满足业务使用。应用系统反馈效果良好，体验效果好。运维监控集群节点网络、心跳、磁盘 IO 、 AWR 报告都无性能压力。节点切换应用无任何感知。唯一缺点就是对系统、网络运维要求苛刻。必须保证波分链路，双活存储架构稳定可靠。

**经过几轮真实 UAT 测试对比 Extend RAC 表现了最佳特性，是最佳选择方案。**

## 四、数据库双活的整体架构设计

1 、确定服务器配置、一套 Extend RAC 有三个LPAR 分区实现，重要的信息系统配置 ADG ，一般情况不配置 ADG ，每个系统配置有独立的业务网、 NAS 网、备份网及绑定的心跳网（均为 10GB 网速）外加 2 张 HBA 卡，系统 CPU 、内存及共享磁盘等配置保持一致。

2 、确定系统版本、数据库版本、补丁版本，经与原厂交流及实施成功经验选择 Redhat6+Oracle11GR2 ，补丁采用 2019 年 1 月最新版补丁集。

3 、双活数据库必要条件存储、网络。一是双活存储数据同步时延很小，双活分布式卷同步网络链路延迟在 1Ms ，二是对网络光纤保障要求高，风险可控，三是 SAN 导向器支持链路判断，对光衰大的链路可主动抛弃，防止抖动影响存储同步与集群通讯。四是通讯运营商能够给提供金牌专属服务，对链路问题能够及时响应定位并提供解决方案（需要在合同服务中协议约定）。并提供足够多裸纤分别对 SAN网络与 IP 网络实现独立裸纤组网。

**架构设计示意图**
![](/home/attachment/201909/20/915687_156894941479354.jpg)

规划设计三台 LinuxONE 分区 LPAR1-LPAR6 部署 6 套三节点 RAC ， 3 套 ADG ，剩余一个测试验证分区。

RAC 集群每个节点心跳网线对接 2 台交换机交叉布线并作网卡绑定以保障 RAC 集群高可用，当出现任意节点的系统、网络、主机故障不会导致集群脑裂。

LPAR1-LPAR55 套 RAC 集群承载 23 套系统数据库，第 6 套 RAC 用于未来新系统上 Oracle12C 推行 PDB 热插拔数据库，为以后数据库架构整体推进 CDB 与 PDB 做测试验证环境。

将生产 RAC 集群节点加入 veritas 容灾平台进行管理。可以实现一键流程化切换集群站点。

## 五、数据库双活的实践经验及上线后的效果

3 台 Z390 LinuxONE 共搭建了可搭建 6 套 RAC ，设计可承载 30 套系统数据库。每个 LPAR 分区对应一套 RAC 集群，其中前三套集群搭建有 ADG ，对重要系统进行二次数据保护，再次提高数据容灾能力。

通过整合原生产 1 、 2 级系统所有 Oracle 数据库，共计 23 套、全部运行在 5 套 RAC 集群。其中 RAC1 、 RAC2 、 RAC3 分别搭建 ADG 。

经过 3 轮 UAT 测试，内容包括硬件层面与基础软件层面。

1 、硬件方面，对单台主机存储链路测试，单台交换机测试，效果：均不影响 RAC 集群，集群 ip 资源自动漂移，业务无感知。

存储单点故障，均通过仲裁实现数据卷有效可靠，持续为数据库提供服务，波分单点故障迅速切换波分链路。

2 、软件方面， RAC 集群单节点切换、单节点正常启停，集群正常提供业务服务，单节点系统宕机或重启故障，数据库 RAC 节点仍然持续提供服务，节点恢复后能够快速恢复集群。

3 、数据移植、跑批测试。在线导入导出测试 RAC 与 ADG 均能正常满足业务需求，无性能压力。

4 、业务验证，业务系统进行模拟一月 30 次跑批处理，结果在 16 小时内完成一月 30 次日结跑批处理。数据库完全满足业务模型压力需求。

5 、结合容灾平台进行站点切换测试（主中心节点运行，备中心库处于 standby ）。一套 RAC 库运行 5 个实例为例实施切换演练。 通过容灾平台 VRP 进行站点切换，完成一套 RAC 库站点切换最长时间 10 分钟即可完成，并实现了数据 0 丢失。

最终架构运行定性，受核心上线工期压缩，测试同步受影响，跨站点的稳定性测试时间不够 30 天，最终选择主中心双节在线运行，备中心第三节点集群在线而实例不打开， ADG 正常运行。站点切换通过 VRP 容灾管理平台实现数据库 RAC 节点切换。 6 套 RAC 库可以并行切换，只需要 10 多分钟即可完成全部 23 套数据库切换。

后期第 6 套 RAC 集群将进行跨站点稳定性测试。通过时间检验 Extend RAC 真实稳定性。

## 六、基于 LinuxONE 平台构建数据库双活的总结经验

集成测试与上线以来获得真实数据， LinuxONE 主机表现了优秀的计算能力，加上配备存储是高端 EMC 全闪存，整个架构体系发挥最大性能优势。 Extend RAC 也表现了完美健壮性与健壮的容灾能力。

切实解决了原有数据库过于分散问题，以及管理节点过多，覆盖面更广问题，有效释放了运维科技技术力量，同时提高基础架构服务能力与容灾能力。

上线运行 4个 月 120 余天效果业务无压力，系统运行良好，业务支撑效果良好。

**LinuxONE与 x86 对比**
![](/home/attachment/201909/23/301729_156923299587031.png)

IBMLinuxonZ主机（2015年命名为LinuxONE）在国内外已经使用了超过18年的时间，从1999年IBM推出LinuxforZ主机开始至今，截止2017年第四季度，全球IBMZ客户中：LinuxONE在Z的装机容量占到了30.3%，全球最大的100家客户中，有91家主机客户正在运行LinuxonZ，到目前为止，还没有发生过一起因为硬件原因导致的宕机事件。

LinuxONE 硬件架构的可靠性、数据库联机处理性能、安全性都比基于 Intel 芯片的 x86 架构更高一个台阶。 Intel 芯片安全漏洞问题和后门问题和高能耗问题是众所周知的，所以我行没有像其他大多数银行那样选择基于 x86 的云平台，而是构建在高可靠高性能的 IBM LinuxONE 硬件系统上的。

最终 LinuxONE 服务器以高稳定性，集约化，数据库授权等优势，成为了我行最终选择目标。

数据库双活 LinuxONE 架构设计

著作权归作者所有

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