金融行业双活数据中心建设思路及方法探讨

赵海 13342272286@126.com

【摘要】：随着金融行业业务的迅速发展，业务的连续性以及数据的重要性变得越来越重要。金融企业对灾难预防以及灾难恢复的投入越来越大，双活数据中心的建设也成为业界的热门话题。但是与此同时也产生了很多盲从现象，很多企业在双活数据中心的建设意义以及建设方法上并没有清晰的认识。本文就金融行业双活建设项目的意义、目标、原则以及建设思路和具体实施方案进行深入探讨，旨在给企业在建设双活数据中心项目过程中提供参考。

【关键字】: 数据中心；双活；容灾；RTO；RPO；数据复制

1. 引言

近年来，随着互联网金融的快速发展，金融企业数据中心建设面临着新的挑战。那就是对RTO和RPO的极限追求。从而也就诞生了近年来的热点话题-双活数据中心建设。

那么我们为什么要建设双活数据中心，它能给我们带来什么样的价值？什么样的数据中心架构叫做双活数据中心？如何认识适合自己业务模式的双活模式？建设阶段我们应该以什么样的原则来指导我们的建设工作？具体的建设思路以及具体的建设方案应该如何把握？基于这些问题本文进行深入研究并展开探讨。

2. 双活数据中心建设意义

从科技工作层面来讲，其实双活数据中心并不是一个行业标准或者规范。行业的标准是对RTO和RPO约束，银监局和中国人民银行对商业银行业最严格的要求标准是5级容灾标准，RPO=15分钟，RTO=30分钟。而根据国际标准share78，六级容灾标准是RPO=0，RTO=分钟级；七级容灾标准是RPO=0，RTO近似为0。双活的概念也就由此而来，为了达到国际最高标准。

那么决策是否建设双活数据中心的依据也就在于此，首先确定自己企业合适的目标，是不是要必须追求7级标准？是不是所有业务都必须追求这个目标？如果不是那么首先要对企业业务进行细分并详细规划每一个业务的容灾目标。浙江决定要不要建设双活数据中心以及建设什么样的双活数据中心。

3. 双活数据中心建设思路

其实对于双活数据中心的定义，从来就没有一个标准的定义或者是行业标准。所有的描述或者所谓的定义暂时都来自厂商的描述。按照目前技术发展的现状以及行业建设状况调查分析，本文认为双活的基础架构基本如下图所描述：

图3.1 双活数据中心架构基础轮廓

双活模式主要分三种，主要区别在于途中（A、B、C、D、E、F几个位置的技术架构差异），接下来详细探讨。

3.1 数据中心级别的广义双活

双活认定的标准以数据中心工作模式为基准，只要两个数据中心正常时都工作，灾难时能自动切换，那么认为是双活数据中心模式。如图3.1中的位置参数表示如下：

A = 业务定义（读写）

B = 业务定义（读写）

A ≠ B

E = 数据库HA模式

F = 存储复制

表3.1.1 数据中心级别双活架构

注1：数据复制可以选择存储的同步复制也可以选择数据库层面的同步复制。

表3.1.2 故障切换模型设计

这种双活架构属于广义上的双活模式，两个数据心之间除了存储端的复制，基本没有其他联系。其实这种模式的双活是传统主备模式容灾组合架构的简单升级版。唯一区别的是传统容灾模式下的存储复制是基于异步单向模式的，而双活架构下的复制是基于同步双向模式的。具体架构描述如下图:

图3.1 数据中心级双活架构

这种模式下需要的基本关键技术必备的功能如下所述：①域名解析设备需要实现动态及全局智能解析，当本地应用无法访问时，DNS能跟负载均衡设备实现联动的健康检查而侦测到这一故障。并且按照解析的动态规则实现解析变化。②负载均衡设备需要实现本地集群化，保证本地负载均衡功能的高可用性。③应用最好以虚拟化方式实现，这样可以平衡资源的严重浪费与高可用的冗余部署之间的矛盾。④数据库在两个数据中心也需要双份部署，同一个业务部署在两个数据中心的数据库节点之间没有任何联系，因为网络二层没有打通，无法实现HA。一般来讲需要手动切换。当然如果不用存储复制技术而是用的ORACLE的ADG技术或者是DB2的DR技术，那么可以实现半自动化或全自动。⑤如果采用的存储层面的复制技术，那么必须是同步复制，必须是双向复制。

3.2 业务级别的广义双活

双活认定的标准以业务是否可以在双中心内同时进行为判定标准。只要同类业务能分布在两个数据中心执行，就认为是双活数据中心模式。如图3.1中的位置参数表示如下：

A = 业务定义

B = 业务定义

A = B

D = 跨数据中心应用集群（区分优先级）

E = HA

F = HA

表3.2.1 业务级别双活架构

表3.2.1 故障切换模型设计

这种双活架构虽然实现了同类业务在前端的负载分担，但是在数据库层面还是属于单点模式。这种模式比前一种模式最大的技术变更就是要求网络上的二层打通。具体实现架构如下所示：

图3.2 业务级双活架构

以上架构，各个层面应该具备的功能描述如下：

①双中心DNS设备为主备模式，域名全局解析，DNS设备跟负载均衡设备能实现联动健康检查。②网络层面必须实现二层联通以保证数据库层面的跨数据中心HA以及应用服务器的应用大集群。③负载均衡层，如果是两个小集群方式，那么不能将其放入大二层，只保证其三层可达就可以了，否则客户端无法实现请求路由切换；如果是大集群方式，那么可以放入大二层网络，但是要设计好会话同步问题；④数据库在两个数据中心实现跨数据中心HA部署，主要是以操作系统的HA，将数据库服务作为HA的服务方式来实现，例如IBM的HyperSwap。⑤存储层面需要实现HA以及同步复制，例如IBM的SVC集群解决方案，NETAPP的MCC解决方案。

3.3 应用级别的双活

应用级别的双活，本文将其定义为同一个应用系统的IO可以从两个数据中心分别访问数据库节点，当然这个访问又会分为读操作和写操作。那么相应的这种模式下的双活又分为两种：一种是读写分离的模式；另外一种是混合模式，也就是业内相对较为彻底的双活架构。如图3.1中的位置参数表示如下：

A = 业务定义

B = 业务定义

A = B

E = 数据库AA集群模式

F = HA/AA

表3.3.1 业务级别双活架构

表3.3.2 故障切换模型设计

这种双活架构虽然实现了应用IO级别的双活，是目前金融行业较为彻底的双活。具体架构如下：

图3.2 应用级双活架构

各个层面应该具备的功能与3.2区别最大的几个关键点描述如下：①数据库在两个数据中心实现跨数据中心集群模式。②存储层可以选择HA方式也可以选择EMC提供的VPLEX虚拟化集群方式。

本节初始曾提到基于该架构，可以通过控制应用链接数据库的具体模式，将读写分离，那么为什么要这么做呢？在这里本文需要将本架构下的关键风险点提出：

1）双数据中心的连接依赖的是运营商的裸光纤，其本身的延时和链路的稳定性是数据库AA集群最大的威胁。拿ORACLE来举例说明，ORACLE RAC 的各个节点共享同一份数据，两节点同时读写的场合下，为了保证数据的一致性它们会同步缓存，锁信息以及全局配置信息等，由于关系数据库的特点，不可避免会产生热点数据问题，那么数据库节点之间就可能会发生IO频繁等待的问题。这种问题一旦成为常态化，那么整个集群性能会呈倍数级性能衰减，严重的时候可能将整个数据库集群挂起。另外由于光线的抖动不仅仅会引起性能的蝴蝶效应，而且可能会因仲裁、光线链路切换的混合参与导致脑裂等严重异常问题，不稳定时刻内涉及到的设备越多，系统越复杂，产生异常问题的可能性就越大。

2）仲裁一致性问题，以上双活架构会涉及到存储集群、数据库集群两个仲裁机制的协同问题。如果发生数据中心之间的链路断裂问题，有可能仅仅影响网络、有可能仅仅影响SAN、也有可能是裸光纤的瞬时全部断裂。这个时候如果存储和数据库的仲裁结果恰恰相反，那么就是两个数据中心同时的灾难了。数据库的仲裁盘在存储虚拟化之后的逻辑磁盘上，存储的仲裁中心在两个数据中心之外的第三点上。由于网络和存储同时断裂，数据库假设先感知到网络断裂，那就要发生仲裁，双中心资源对等情况下，ORACLE选择实例号小的子集群存活。由于存储对SAN中断的感知落后了，那么它根据第三方仲裁点来仲裁存储的存活，如果没有其他策略来保障，它的仲裁结果完全有可能与数据库已经做出的判断相反。

3）双重热点问题，如果我们将ORACLE RAC假设在存储的AA集群之上。本质上EMC VPLEX也是一个ORACLE RAC，因为它要实现同一时刻内存储的双向复制，也就是说两个虚拟化网关就相当于RAC节点，同样会有热点问题，同样会同步一个全局配置以及缓存，只不过它是基于块儿的热点。这两个层面上双重竞争，系统变得异常复杂，非常容易出问题。

4）存储复制无法解决逻辑校验。存储复制技术是以块儿为单位的复制技术。虽然能很好完成数据复制功能，但是如果源数据块儿已经发生了逻辑错误，存储是无法识别到这一错误的。直接结果就是复制到对端的数据无法被应用识别，最终应用还是中断。典型的案例比如说ASM的磁盘头部逻辑性损坏。

如果解决以上面临的风险点呢？对于热点问题，这是关系型数据库的固有特点，要保证数据的强一致性，那热点就不可消除。只能通过以下方式来改善：

1）业务高度去耦，能做到数据库分区的尽量分区，比如说银行的交易系统，我们是否可以根据终端的地域属性将表分区，当然应用层也需要做相应的区分链接处理。

2）业务读写分离，减少锁的等待。这就需要应用本身能做到高度隔离，而且读写需要分别使用不同的数据库链接方式。

对于第二个风险点，仲裁一致性问题，有以下几种解决思路：

1）通过存储层和数据库层的仲裁触发时间以及判定时间的控制参数，保证数据库仲裁发生在存储之后。

2）数据库在资源对等情况下，按照实例号大小策略来判断仲裁结果，存储在资源对等情况下同样可以设置其策略，我们需要保证这两个策略结果的一致性。

3）ORACLE的仲裁策略，首先保证集群中获取投票资源最多的子集存活，资源对等情况下才会选择实例号小的存活。如果设置两边的节点数不一致，那么这种情况下，数据库的仲裁结果就是可知的，根据这个可知结果将存储侧的仲裁方式设置为固定方式。

4）部分或者全部利用数据库复制技术代替存储复制技术。数据库复制技术可以是以日志的复制来实现的，对于数据库来讲，只要redo日志存在，那么数据一定能恢复。而且类似ASM磁盘头部逻辑错误，一定不会复制到对端。也就保证了对端数据库不会因为逻辑错误而无法启动数据库应用。

3.4 三种架构的对比分析

本节将重点通过架构对比、功能对比、实现复杂度对比等方面来分析这三种架构的优劣。

表3.4 双活架构对比

3.5 本文认为的合理双活架构

由以上分析我们可以看出，对于容灾指标高的架构所面临的风险项也是最多的，在风险和容灾目标面前我们需要一个平衡。具体架构实现如下图：

表3.5 折中双活架构

根据以上架构，可以看到：

1）增加数据库复制技术保护，以防块复制的逻辑校验缺失造成数据丢失风险。

2）存储层面以HA方式代替AA模式集群。

3）根据应用隔离的程度控制应用链接数据库节点的模式，实现业务读写分离。

4.总结及展望

本文认为目前所研究分析的双活架构是属于折中解决方案，并不是一个科学合理的解决方案。分布式架构才是解决问题的科学合理架构，但是关系型数据库对数据的强一致性要求无法从数据库单方面来实现整体架构的分布式部署，但是可以实现分布式部署的数据库（NOSQL）又无法满足数据的强一致性。通过从应用、网络、数据库、存存等一系列层面实现系统性整体的分布式架构实在是一件很困难的事情，需要耗费大量的人力物力，并不是每一个金融企业都能实现的事情。本文相信当人类认识OLTP模式的观念发生变革之后，或许有可能很容易地实现真正的OLTP分布式架构。比如区块链技术就从根本上颠覆了账务平衡的传统理论观点。相信会有类似的新技术能够实现完美替代。