金融行业双活数据中心的建设

金融行业双活数据中心的建设

“双活“这个概念，已经被提了不少年了。因为金融行业对业务的稳定性要求较高，所以双活也收到金融行业客户的关注。本文将着重分析双活数据中心的架构，并对金融行业双活数据中心给出建设的意见。

 

在正式开始文章以前，咱们带着三个问题去来读这篇文章，在文章的最后，我将会对这三个问题进行参考性回复。

 

Q1: 双活是哪一个公司的强项？Red Hat、VMware、IBM、EMC？

Q2: 双活主要靠的是应用层交付，如负载均衡等，而不需底层IaaS层的高可用？

Q3: 大家的双活方案是什么？是否能知足咱们的要求？

 

1. 双活数据中心的概念

双活是两个数据中心，每一个都具备独立运行生产应用所须要的全部资源。此架构下全部的应用请求会被动态负载均衡到两个数据中心，当其中一个数据中心故障时，另一个数据中心接管全部的应用请求。

 

双活数据中心的的优点在于：

l  提升用户的快速体验和链路的利用率，但愿能够经过任意一条链路访问到不一样数据中心的业务；

l  双中心都能提供业务负载，须要时可直接在另外一个中心扩容资源；

l  知足临时快速加载基础架构资源的要求。

l  充分利用资源，避免了一个数据中心常年处于闲置状态而形成浪费，经过资源整合，双活数据中心的服务能力是双倍的；

l  若是中断了一个数据中心，其余的数据中心仍可独立响应业务，对用户来讲业务切换是无感知的

 

2.双活的分类

在讨论双活的分类以前，咱们必须明确一个前提：即双活针对一套应用（而不是不一样的应用在不一样的数据中心实现主备的总体双活）。在这个前提下，双活分为狭义双活与广义双活。

 

• 广义的双活数据中心指的是：一个应用WEP/APP/DB，要么App提供双活，数据库跨数据中心主备。要么App主备，数据库跨数据中心实现双活。前者应用双活，后者是数据库双活。

 

• 狭义的双活数据中心，指的是：一个应用的Web/APP/DB在两个数据中心都是双活的。也就是应用双活+数据库双活。

 

接下来，咱们看一下这几种双活的特色和实现方式。

 

应用双活：

• 双生产中心均提供web层和app层服务

• 数据库服务只在其中一个中心提供

• 经过数据复制技术将数据复制到对方

• 出现灾难时，根据须要分层切换，或所有切换到另外一中心。

 

 

应用层双活须要负载均衡器配合。在架构层面，多个数据中心经过内部私有网络互联，统一对外提供服务。在多个数据中心内，应用在每一个数据中心都是处于活动状态，在这种运行模式下，必须使用应用交付设备来实现应用的管理。

 

数据库双活：

• 双中心Web/APP层是主备

• 数据库双活，依赖于高端双活存储

• 出现灾难时，应用切换到第二数据中心

 

 

 

 

狭义双活：单应用对称双活：

• 双生产中心均须要完成生产业务

• 经过双活存储进行数据复制，在两边提供无差异的存储服务

• 经过业务模块或用户的方式将业务分配到不一样的中心

• 平时主要的处理能力均分配给生产应用系统使用

• 出现灾难时，根据须要接管的方式，动态调度资源给关键应用使用

 

不一样双活技术对技术的要求：

3.双活方案的落地 

在早些年，应用主要是单实例、单体应用。那时应用的高可用主要经过操做系统HA软件和共享存储保证，如PowerHA、MC/SG、Redhat Linux HA。彼时，实现应用的双活是比较难的。由于应用自己不具有双活的功能。所以，目前大多数落地的双活方案，更可能是数据库的双活。

 

在线网环境，最主流的数据库毋庸置疑固然是Oracle数据库。数据库的双活方案实现的是Oracle extended RAC。咱们知道，RAC自己就是双活的，只是默认安装在一个共享存储上，不能规避存储的总体故障。Oracle extended RAC是将数据库部署在具备同步复制功能的存储上。以下图所示。

 

 

咱们能够看到双活节点其实包含三个数据中心，提供正常服务的站点A，站点B， 和提供仲裁做用的站点C，站点C上不保存和提供任何的数据服务。目前市场上全部的双活方案都是如此。Oracle RAC的双活必须依赖于双活存储。双活存储有一个关键的特征：在数据中心之间能够实现同步双向复制，由于只有这样，才能保证两个站点的存储都能同时被读写。

 

目前市场上常见的双活存储有：EMC vPlex, HP 3Par，GPFS A-A，SVC的双活。对Oracle RAC而言，要么提供块设备，要么提供共享文件系统。

 

咱们看一个基于块设备的双活存储方案---vPlex

接下来看一个基于并行文件系统的双活存储方案----GPFS A-A：

 

咱们再看一个HP 3Par的双活存储方案：

4.Oracle Extended RAC在各类故障场景下的表现

 

将双节点的Oracle Extended RAC部署到双活存储上，模拟各类故障场景。咱们关注出现故障时，数据库对外服务的表现。从下表能够看出，数据库双活能够应对单数据中心级别的全部故障。

 

5.容器时代的双活

近些年，随着容器、微服务的普及，不少应用已经作到了分布式和无状态化。传统的高可用技术做用被大大削弱。

 

例如，客户的容器化应用运行在Openshift/kubernetes上，单个应用使用一个Service IP，一个Service IP对应一个或者多个Pods。ServiceIP到不一样的pods，自己就能够作负载均衡。这时候，在一个数据中心内部，咱们只须要让pods运行到不一样的计算节点上，多个pod同时访问一个pvc，便可以实现单数据中心业务的高可用，而彻底不是使用传统的HA软件，也不用依赖底层虚拟化的HA功能（若是将Openshift安装到虚拟化上）。

 

在Openshift环境中，双活数据中心经过以下方式实现。

 

须要两个独立的数据中心，部署两套Openshift集群。容器的持久化数据保存在双活存储上。两个站点同时对外提供服务，当一个站点出现故障，另一个站点接管新的请求。总体业务不中断。

因为容器的弹性能力很强、启停的速度很快。所以上图的方案能够实现基于容器的应用级别双活。即便咱们在Openshift中部署一些轻量级的数据库为应用提供数据，如MySQL，也能够经过双活存储方案实现。或者咱们将MySQL部署到物理服务器，经过双活存储实现异地双活也是能够的。

 

但上面方案有一个缺点，是什么呢？成本高。

 

本质上讲，运行在容器上的应用，相比于核心业务系统，一般关键性没那么高。并且容器的持久数据一般是日志、监控数据和配置文件。咱们只要保证数据不丢失便可。这时候，再为容器化的应用配置高端的双活存储就显得成本太高。咱们只须要保证企业的核心数据库是双活的便可。

 

所以，基于容器的高可用解决方案，咱们能够考虑以下的配置：两个独立的数据中心，部署两套Openshift集群。底层存储单向同步或异步复制。第一站点发生故障时，灾第二站点的容器在很短的时间提供服务（秒级）。

 

6.金融行业构建双数据中心的建议

近两年，不少国内的银行在构建直销银行、数字银行。这二者都是互联网金融的体现。互联网金融须要的是敏态IT：快速迭代、快速上线。这类业务也一般选用容器平台构建。对于金融行业客户而言，在保证传统核心稳定的状况下，构建互联网核心，也就是：双核心、大外围是一种广泛的作法。在这种状况下，将传统的核心数据库实现数据库双活，将容器化应用实现跨数据中心主备，是一种既能兼顾成本和业务连续性较高的方法。固然，若是企业对RTO/RPO要求很是高，而且预算较多，实现对称双活也是彻底能够的。

 

 

最后，我将三个问题的参考回复分享出来：

Q1: 双活是哪一个公司的强项？Red Hat、VMware、IBM?

A1: 双活数据中心是个复杂的工程，包含服务器、存储、硬件、网络设备、应用等。没有一个厂商能够独立完成。从落地的双活方案看，数据库双活更多，针对数据库双活，传统高端存储厂商更有优点。从技术的发展看，随着K8S和微服务的普及，显然应用的双活更容易实现，在这种场景中，PaaS厂商和作中间件的厂商会更有优点。

 

Q2: 双活主要靠的是应用层交付，如负载均衡等，而不须要IaaS的高可用等功能？

A2: 负载均衡在虚拟化和容器出现以前就已经出现，随着技术的发展，负载均衡更注重于应用交付，而基IaaS更注重于资源调度。两种技术共同做用于双活数据中心。

 

因为K8S自己能够提供容器的高可用，它确实必定程度上削弱了容器须要依赖虚拟化HA来保证高可用的必要性。例如，咱们能够将Openshift部署到物理机上，依然能够实现应用的高可用。而部署到虚拟化上的目的，更可能是出于为了统一管理、更为方便为Openshift集群增长资源的目的。

 

Q3: 大家的双活方案是什么？是否能知足咱们的要求？

A3: 没有最完美的方案，只有最适合的方案。咱们须要先了解客户的现状、条件，投资、以及目标，而后给出一个最适合的方案。就经验而言，对于金融行业，核心数据库实现数据库双活、应用实现数据中心主备，总体上是更容易实现的。