2017-02-28 DBA日记，同城双活的技术研究

背景

“同城双活”这一概念在2016年之后提得特别多，为了与时俱进，今天就专门研究一下这个课题。
目的

研究同城双活的架构模式，为企业系统架构的未来发展作好准备。
问题

1.什么是同城双活？

2.oracle给出那出解决方案？

3.Mysql又给出那些解决方案？
分析

1. 同城双活的定义：

双活数据中心，区别于一个数据中心、一个灾备中心的模式。灾难是一个小概率事件，采用一主一备这种方式，备份数据中心只在灾难发生时才能起到作用，这对于某些用户来说是IT资源和资金的浪费。而双活数据中心的特点是两个数据中心都是在线运行的，如果断了一个数据中心，另外一个数据中心还是在正常运行的，对用户来说是不可感知的，业务几乎不受影响。这样就充分利用了资源，从而避免一个数据中心常年处于闲置状态而造成浪费。并且通过资源整合，“双活”数据中心的服务能力是双倍的。

关键字：同城，对两个站点的距离是要求的。

2. 双活分类，双活+概念

2.1 网络双活

2.2 存储双活

2.3 应用双活

2.4 数据库双活

3. 身为DBA，当然第一焦点放在数据库双活和存储双活上。我们看前辈们的研究资料：

数据库双活则是指两个数据库系统可以在相隔比较远的情况下同时运行、支持相同的应用负载，并且在一方出现故障时能够迅速切换到另一方（分钟级），保证业务高可用性。比如ORACLE扩展的RAC和DB2的purescale技术。但数据库的双活前提必须是网络和存储双活。以ORACLE扩展的11G
RAC为例，其ASM卷则需要在两边存储做镜像绑定，以保证读写一致。



4. 解读关键字：

场景：其中一个机房出现故障时~~~~~~~~~~

作为：另一个数据库能支持相同的应用负载，能够快速切换，保证业务连续性，

前提条件：需实现网络双活, 存储双活

疑问？数据一致性？事务一致性是第一考滤因素吗？

5. ORACLE关于双活的解决方案：

在双活数据中心模式下，Oracle RAC数据库可以实现跨站点部署。两个Oracle RAC节点


分别部署在两个数据中心（Oracle RAC 1部署在数据中心1，Oracle RAC 2部署在数据中心

2），即使数据中心1发生故障，也不会影响到运行在数据中心2里的Oracle RAC 2应用。结合

VMware HA技术，还可以保证数据中心2自动重启原来运行在数据中心1的Oracle RAC 1应用。

相比运行在物理架构上RAC，则运行在VMware虚拟化平台之上的Oracle RAC不仅可以实现更高

级别的业务连续性，而且可以在线进行维护和扩容。借助VMware vMotion技术，还可以在线

迁移Oracle RAC节点，从而避免了硬件维护时的应用部分中断。此外，通过VMware Hot-Add

技术，我们还可以在线增加RAC节点虚拟机的CPU数量以及内存容量，从而避免了硬件扩容时的

应用中断。

6. ORACLE双活的关键词：

扩展RAC能够实现节点分别部署在不同的数据中心中上。并且利用vmware ha、vmware

vmotion、 vmware hot-add技术，可以动态维护RAC、节点迁移、资源增加等功能。

限制：oracle原厂的说明，

An Oracle RAC extended cluster is an architecture that provides extremely fast

recovery from a site failure and allows for all nodes, at all sites, to actively process

transactions as part of single database cluster. An extended cluster provides greater

high availability than a local Oracle RAC cluster, but because the sites are typically in

the same metropolitan area, this architecture may not fulfill all disaster recovery

requirements for your organization.

扩展RAC未必能全部满足你的灾备要求，如距离。

7. 数据库双活的基础——存储双活



存储双活使信息能在数据中心内部以及数据中心之间共享、存取或移动，从而将各种不同的存

储系统联合成为单一资源。它允许地理上分离的两个数据中心间的存储系统同时进行数据存取，对

客户透明，且保证了数据的可靠性和可用性。 利用跨数据中心的存储虚拟化功能和数据镜像功

能，结合上层应用集群，使两个数据中心都处于运行状态，可同时承担相同业务，提高数据中心的

整体服务能力和系统资源利用率，并且互为生产和备份，当单数据中心故障时，业务自动切换到另

一数据中心，实现RPO=0，RTO≈0，解决了传统灾备中心不能承载业务和业务无法自动切换的问

题 .

典型的技术有IBM的SVC和EMC的VPLEX。IBM SVC是一个软硬件集成化的产品,专业的虚拟

存储软件运行在集群式的硬件引擎上。主机集群可通过两边存储同时访问同一个虚拟卷，双中心同

时提供对外服务，可提高资源利用率。EMC的VPLEX Metro技术则可以将在100公里之内的两个

VPLEX集群连接起来，也就是会有8个VPLEX引擎，通过这些引擎能将两个数据中心内最多1.6万个

虚拟存储卷整合在一起，并且将最大响应时间控制在5ms以内，同时保证两个数据中心中的应用都

能访问这些存储卷。

8. 网络双活

9. 应用双活

数据中心双活在应用处理层面上实现了完全冗余，在线交易通过负载均衡自动路由到不同

数据中心的应用服务器，所有的业务系统同时在同城的两个数据中心运行，同时为用户提供服

务。当某个数据中心的应用系统出现问题时，有另一个数据中心的应用来持续的提供服务。好

处是服务能力是双倍的，业务连续性和稳定性得到了大大的提高且对用户来说服务体验更好，

故障无需感知。

10. 总结

1)各层面都要双活才能实现数据中心的双活 真正的双活，要在数据中心的从上到下

各个层面，都要实现双活。存储、服务器、网络、数据库、应用，各层面都要有双活的设

计，这样才能真正意义上实现数据中心层面的双活。

2)各个层面的整合是实现数据中心双活的难点 企业中的IT基础架构设施都是多年发

展和积累起来的，从硬件设备、网络、存储、应用软件、中间件到数据库都是各种各样

的，不同层面的整合各家又都有不同的技术，在多种可能的技术选择方案中寻求平衡和控

制是比较复制的，所以整合我认为是目前实现数据中心双活的难点，技术选型的承上启下

更是关键。

3)从某种程度上说，双活数据中心可以看做是一个云数据中心，因为它具有云计算所需

的高可靠性、灵活性、高可用性和极高的业务连续性水平。不仅能够满足应用对性能、可

用性的需求，而且还可以灵活动态扩展。

11. 参考资料

http://wenku.baidu.com/link?url=H5QhDQvSN86JIKfgCG3NURzR5ae_Mc_gKJ5Vp7LoRl1R9_QM29UfXWlxJ2jPYKYb_z02K7l9xY5IzliH6TJ1QSewXeEmObL_3Hy-rfsss7_

https://docs.oracle.com/cd/E11882_01/server.112/e10803/config_rac.htm#HABPT00244

12. ORACLE关于oracle rac on extended distance cluster的说明

Oracle RAC on Extended Distance Clusters
Oracle RAC on Extended Distance Clusters is an architecture where servers in the cluster reside in locations
that are physically separate. Oracle RAC on Extended Distance Clusters provides extremely fast recovery from a site failure and allows for all servers, in all sites, to actively process transactions as part of a single database cluster. While this architecture
creates great interest and has been successfully implemented, it is critical to understand where this architecture best fits especially in regards to distance,latency, and degree of protection it provides. The high impact of latency, and therefore distance,
creates some practical limitations as to where this architecture can be deployed. This architecture fits best where the 2 datacenters are located relatively
close (<~100km) and where the extremely expensive costs of setting up direct cables with
dedicated channels between the sites have already been taken.
Oracle RAC on Extended Distance Clusters provides greater availability than local Oracle RAC but it may not
fit the full Disaster Recovery requirements of every organization. Feasible separation is great protection for some disasters (local
power outage, airplane crash, server room flooding) but not all.Disasters such as earthquakes, hurricanes, and regional floods may affect a greater area. One shouldanalyze
their situation in order to determine if both sites are likely to be affected by the same disaster.
For comprehensive protection against disasters including protection against corruptions and regional disasters, Oracle
recommends the use of Oracle Data Guard in combination with Oracle RAC as
described in the Oracle Maximum Availability Architecture guidelines. Oracle Data Guard also provides additional benefits such as support for rolling upgrades across Oracle versions.
Configuring an extended distance cluster is more complex than configuring a local cluster. Specific focus
needs to go into node layout, voting disks, and data disk placement. Implemented properly, this architecture can provide greater availability than a local Oracle RAC database, but should be considered with Oracle’s Maximum Availability Architecture in mind.