数据中心双活技术方案选型规划

1、 数据中心双活技术方案选型规划 谈到双活就必须要从IT业务连续性管理这个话题谈起。只有从根上我们知道这个需求以及技术方案是怎么生长出来的，我们才能够彻底搞清楚，用户在什么情况下适合什么样的解决方案，以及未来技术解决方案的走向。为了保证IT系统对业务支撑的连续性，在HA高可靠方案的基础上，生长出来了DR的概念。即如果由于某些不可抗力原因，如火灾、地震、公共卫生安全事件、或其他原因，导致单数据中心整个出现问题，如何能够保证IT能够继续有效运行。在这个概念下提出了RTO以及RPO的概念。所谓的双活方案就是在这样的概念下生长出来的。即如果RTO和RPO都双双等于零，那就是所谓的双活方案。针对应用服务器

2、场景，由于Load balance解决方案(这里又分为有状态和无状态两种)已经非常成熟了。因此一直以来应用服务的双活方方面面的都问题不大（ 老旧应用改造除外 ）。核心需要解决的问题一直是数据库层面上的双活问题。目前针对数据库双活的解决方案有很多种。总的来说分为两大类：原生数据库双活（多活）方案以及传统数据库的双活方案。1.原生数据库双活（多活）方案目前新型的分布式NewSQL数据库，在系统设计方面就充分考虑到了双活/多活的需求。因此原生满足。目前对于这类数据库典型的实现方式有两种：方法1：在数据库底层建立统一的分布式存储系统，数据库实例写下来的数据同时写多副本。这些副本可以分布在多个数据中心上

3、。在数据库实例端，可以做多个集群多实例方案，或者也可以做快速服务切换方案。因此任何一个数据中心出现问题，都不会影响。以下是一个例子：方法2：在数据库底层建立统一的KV数据库集群（目前用RockDB的居多）来解决数据文件跨节点，跨数据中心存储的问题，并通过Raft机制来实现数据同步和跨数据中心切换。数据库实例层的设计方式和方法1类似。这里典型方案如TiDB。综上所述的两种方法来看，其实原生的数据库双活解决方案也没有太多神秘，基本的解题思路依然是在分布式存储层来解决问题。只是实现的技术路径不同而已。2. 传统数据库的双活方案这里讲的传统数据库如Oracle, DB2，Informix等。由于这些数

4、据库本身并没有在原生状态下考虑双活问题。因此双活方案都是在原生体系外面通过附加解决方案来构建的。这类解决方案基本上也都是在解决一个问题：就是如何将多块部署在不同数据中心上的数据盘（数据块）逻辑上merge成一个。从接替思路上基本上有两种：方法1：通过存储设备层实现。如EMC的vplex解决方案，IBM的SVC解决方案，IBM的HyperSwap解决方案，浪潮存储双活方案等。都是通过存储层来实现的。方法2：通过分布式文件系统实现。例如题主在问题里讲到的GPFS解决方案，就是属于这一类。通过GPFS分布式文件系统的Failure Group功能，将另一份双活数据同步地写到另一个数据中心去。以上是对

5、目前市面上的一些双活方案的技术总结。双活方案的优缺点先来谈谈优点：数据中心切换时间短：这个优点是必然的，虽然在技术上无法实现完全的RTO=0，但是基本上可以控制在秒级。这已经非常不错了，无论是在银行、证券。还是在社保、公安户政、交警、这个级别的可靠性保证妥妥地没问题。数据中心故障切换自动化：自动化切换是切换时间短的技术性保证。没有自动化切换是不可能做到这么短的切换时间的。再来谈谈缺点：建设代价高：为了保证RTO和RPO同时为0，需要满足的条件是非常苛刻的。1、是两个数据中心的距离必须要短，最好在5公里以内。否则的话数据在两个数据中心间的同步会拖慢整合业务系统。让用户感知下降，这个是我们最不希望看到的。2、网络链路要求高：网络链路延迟必须要低，并且不能有网络抖动现象。最好是有单独独立的光纤。3、建设费用高：即使是只有上述两点要求，这个建设的费用也是相当不低了。运维代价高：如果从应用系统级别就要实现双活的话，那么就设计到应用服务器集群双活、数据库双活、网络双活的多个方案集成。这个集成的复杂度，光想想看心里基本上就有点数了。因此对运维团队的考验是相当大的。最后的建议：双活虽好，适不适合每个客户的场景，这个问题