为什么要讲双活数据中心？从应用系统和系统保护来说，分这么几个角度：

首先做容灾，第一个要考虑的是主备，上图左侧是最早出现的主备模式，一般是在两个中心建互备系统，比如我在B中心，容灾系统在另外一个地方，这种模式比较容易切换。假如A中心出问题了，就绑定在B中心，或者是把数据复制到B中心，容灾资源是闲置着，承担着容灾的任务。另外真的出问题了，我得需要一个定位，因为并不能确认它是否确实不能用了，所以，要确保这个业务完整，数据也不丢，定的时间加上切换流程，至少得0.5小时，甚至更长，甚至一两天，这样导致弊端很多。

后来为了节约资源，发展到现在双中心互备，A中心一部分做生产，B中心也一部分做生产，在原来的储备方式上做了一个改进，优点是因为这两个中心都有生产业务运行，可通过资源共享技术节省资源。但仅仅是计算源，对于存储来说，由于这个存储空间必须要保证完整来做，所以没有办法充分利用起来，还是闲置状态。针对这种问题，我们现在又有了双活并行模式，同一个系统，两个中心都可以承担业务，同时对外服务，坏掉任何一方不影响。

这是非常理想的一种状态，今天主要讲的是要实现这种架构或部分实现，需要哪些技术，需要做哪些工作，只是简单的讲，不一定很深入，也希望能够和大家一起沟通交流，看有没有更好更优的方案。

我主要从应用到基础设施的角度来讲。因为从整个应用架构来看，咱们有一些业务可能是有接入层，下面是应用逻辑，后面包括还有一些接口，再下面是数据层，再下面是基础架构，有可能有存储和网络，这么几层，每一层都会有相应的双活实现技术。例如应用层可能有各种集群，数据层可能有一边同时可读写，或一边只能读等。再如基础架构层，在网络上对稳定性和带宽吞吐性能要求更高，甚至需要打通跨中心的大二层网络，存储方面则需改变一主一备的读写机制，实现同时可读写。

下面从这五个方面展开谈，一个是数据层，二是存储层，三是接入/应用层，四是虚拟化/云平台；五是技术关键点。

首先讲数据层（这里指传统数据库）中的双活方式，一种叫Active Standby方式，一种方式为两个都是Active方式，此外还有数据逻辑复制软件模式。

Active Standby是基于Oracle ADG技术，这个模式采用从主库向备库传输redo日志方式，备库恢复数据过程可以用只读方式打开进行查询操作，实现了部分双活功能，在主节点故障后可以将备节点切为生产。

Active—Active方式指的是两点都可以同时读写，例如通过Oracle Extend RAC实现多个集群节点同时对外提供业务访问。该方式能做到故障无缝切换，提升应用系统整体性能。这种模式理论上不需进行人工切换操作。

另外在基于逻辑复制的软件，利用数据库在线日志中的数据变化信息，通过网络将变化信息投递到目标端，最后将目标端还原数据，从而实现源目标的数据同步。

方式一：Oracle ADG

首先第一个模式是Oracle ADG模式。通过网络从生产向容灾传输归档或redo日志，容灾端恢复方式同步恢复。这个数据库不断把日志写入到备库。这种方式的优点是存储支持异构。

应用场景：可以把这个库可以作为应急或容灾用，作为数据保护手段。

方式二：逻辑复制

通过DSG、GoldenGate等逻辑复制软件技术实现跨中心数据库的相互复制，这种逻辑复制支持表级的复制，要求两个数据中心各建一套数据库，物理独立，同时能读写。基于数据库日志准实时复制数据，支持异构数据库，异构OS。可以实现一对一、一对多，多对一、双向复制等多种拓扑结构。把日志进行分析，写到这个库，是以跨中心的共享存储基础，通过共享存储资源和Oracle数据库集群软件管理，实现各个中心节点对数据库并行访问。

方式三：Oracle 远程RAC  

Oracle Extended RAC以跨中心共享存储为基础，通过共享存储资源和Oracle Clusterware数据库集群管理，实现各个中心节点对数据库并行访问。

共享存储可以采用存储自身数据复制技术，存储虚拟网关或远程卷管理等技术，以Oracle ASM存储卷管理为例，实现数据的双向实时复制。

要点：

• 两个数据中心分别部署一套存储，各提供一套LUN设备给全部数据库主机。

• 存储的SAN网络和RAC心跳网络需使用低延迟、高带宽的DWDM光纤链路。

• 配置ASM磁盘组。每个磁盘组配置两个失效组，每个失效组对应来自一套存储的LUN设备。

• 在第三个站点部署用于RAC的第3个投票盘，使用NFS的方式挂载到所有数据库主机。

• 与管理普通的RAC系统类似，需要重点加强对站点间光纤链路情况的监控与应急。

内存库双活技术

内存库双活技术，将数据放在内存中直接操作的数据库，相对于磁盘，内存的数据读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。

应用场景：用于实时计费，读写分离场景，主要有Oracle Times Ten，Altibase商用以及华为等相关产品。内存库集群部署主要有HA模式，双活模式，线性拆分和分布式集群四种模式。

内存库通过复制手段，实时地复制到另外一个中心，它们之间是一个跨中心的数据，这是HA模式。另外双活模式，和这个模式是HA模式的延伸，可能一部分表是一个方向复制，另外一些表反过来。还有一种是线性拆分模式，将内存数据放在多个内存库集群中，每个内存库存放一部分数据，并互为备份，这种模式需要应用进行针对性改造。分布式集群模式，自动实现不同数据分片和副本机制，是目前比较流行的一种结构。

数据层双活技术比较

逻辑技术软件容易出现逻辑错误导致数据不一致，而且很难稽核。ADG模式数据在数据库级是完全一致的，当然前提是能正常同步，但是不支持两边同时能读写。从数据延迟来看，不管是ADG还是逻辑复制软件，都跟日志量有关系，后面会讲我们在不同日志量情况下做的测试延迟结果。

存储层作为双活系统核心基础架构平台，其双活技术在整个架构中起到关键作用，目前基于存储层双活方案主要有下面三种：

• 基于远程卷管理软件的虚拟化，比如Symantec SF、IBM GPFS、Oracle ASM等。

• 基于存储网关虚礼化，如EMC、vplex、IBM、SVC。在传统存储上面增加了一个虚拟化网关，在每个机房里面，新增存储虚拟化网关设备组成跨站点集群，并对存储卷进行重新封装，对外提供主机访问。

• 存储卷镜像技术，将两套磁盘阵列组成一个集群，两台存储上的LUN被虚拟化为一个虚拟卷。

流派一 远程卷管理软件

• 数据同步：底层数据复制采用远程卷管理软件，如赛门铁克的storage Foundation（SF）、IBM的GPFS、Oracle的ASM等，通过逻辑卷镜像技术实现底层数据逻辑同步。上层应用采用Oracle Extended RAC方案实现远程多节点RAC，使生产和容灾节点都处于在线状态，应用逻辑访问的是同一个数据库。

• 数据读写：支持双读写。

• 数据一致性：完全一致。

上面是不用远程卷管理软件的一个情况，我只需要认识到自己机房的存储就可以了。底层存储实现远程复制到容灾存储上，如果改造成远程管理软件，那么服务器既要认到本地存储也要认到对端存储，实现两边都是同时可以对存储读写的，而且还可以通过设置策略，写的话向2个存储同时写，读的话可以优先读本地的，从而可以加快读的速度。

流派二 存储网关虚拟化

实现原理：将存储虚拟化技术和Oracle的远程RAC技术结合，实现跨中心的数据双活访问。平时两边主机分别访问本地存储，故障情况下可垮中心访问对方存储。对于同一个数据块的读写冲突机制，是由Oracle RAC来保证的。存储不能直接给服务器访问，需要先通过中间层虚拟化网关设备，再访问存储。为了防止出现两个中心间网络全断情况下，两边互相不知道谁还活着，需要建一个仲裁节点（建议在第三个中心），实现让谁作为主，让谁作为访问的仲裁机制，从而防止数据不一致这种极端情况。

流派三 基于存储自身卷镜像

这是一个存储自身卷的镜像，这是一些新的设备情况，它的优点，整个网络架构没有改变，从主机到交换机到存储，也没有增加任何的设备，这种是相对来说比较易于实行（也需要一个仲裁站点）。

存储层双活技术对比

这是一个存储层的双活技术比较，容灾技术有2个重要参数，RPO（故障恢复点）和RTO（故障恢复时间）。这几种理论上都能实现RPO等于0，也能支持双活读写。从可靠性来看，这个数据不是完全决定的，需要根据实际情况定。从异构性来说，除了存储自身虚拟化和存储HA机制不支持外，其余都支持。但不管存储双活有哪几种，双活都需要用到远程Extend RAC。

下图是一个例子，一个比较前端的系统，分为接入/接口层、应用层、主机/数据库层、存储层等，各个层面统筹考虑双活机制，才能实现零切换。首先不能像原来烟筒式的数据库连接，应考虑统一数据库访问接口，并实现应用自动重联机制，确保自动切换，减少人工切换。在应用层，则考虑双中心部署相同的应用集群方式，或跨中心的集群方式。

从接入层看，如何把业务接入到两个中心，一般有这么几种，一种是采用全局负载均衡（如F5的GTM）、DNS、或前置CDN等技术实现跨中心灵活接入。

1. 业务多中心并行模式：通过一组GSLB来对外提供服务，GSLB监控服务的状态，并通知组内其他设备，对于每一个DNS请求返回最佳结果，好的策略选择和配置方式可以最大幅度提高客户体验。

2. 业务多中心互备模式：对于内网业务通过一组SLB来提供服务，实现DNS解析，负载分发和故障切换。

3. 前置CDN，通过CDN来进行不同中心的业务接入。

现在都在讲云计算，是非常热门的，其主要技术特征，首先是带来虚拟化技术，其次应用实现集群化和x86化。

相应带来的问题：我们原来的双活设计模式，可能不适应这种虚拟化或应用集群化模式，需要重新考虑业务连续性双活方案。我总结了四大类：

1. 继续沿用传统基于负载均衡的双活架构。每个中心部署独立的云化应用集群，通过接入层负载均衡实现双活。举个例子，有Web集群，通过前面接入增把业务分发到不同集群去。

2. 基于分布式应用协调机制，可以建一套跨中心应用集群，通过分布式应用协调机制，实现跨中心的高可靠性集群，统一配置，统一管理和任务分配。

3. Hadoop、MPP等的双活机制，应用写两份方式实现双活，跨中心集群方式。

4. 虚拟化平台的跨中心双活（迁移），我们也是既可以建跨中心集群，也可以建两个独立集群，通过一些业务来分发。举个例子，我们现在可以建云资源池，建一些独立的池。

模式一 相互独立的双集群

在每个中心部署独立的云化应用集群：

1. 如Web类应用可通过接入层和负载均衡实现双活访问；

2. 如Hadoop或MPP集群应用可通过上层应用实现双集群数据同步，从而实现双活。

模式二 跨中心单集群模式

第一种是基于分布式应用协调机制：构建一套跨中心应用集群，通过分布式应用协调如ZooKeeper实现跨中心的高可靠性集群，实现统一配置、统一管理和任务分配。

第二种是基于数据副本保护机制：如详单云和大数据的Hadoop集群、大数据的MPP集群等，通过进行合理规划设计，确保任一中心节点都是完整的数据副本，由集群自动维护两个中心的数据副本同步机制来实现双活。

虚拟化云平台双活

基于存储阵列双活和VMware 跨站点集群功能实现虚拟化平台数据中心容灾解决方案，在阵列双活技术支撑下，通过VMware Cluster 的HA高可用功能实现故障业务切换保护，从而达到保证业务连续性的要求。

• 网络站点间二层互联，采用波分传输，存储实现双活为上层提供共享存储；

• 将两个数据中心服务器配置为一个集群，通过HA和DRS实现高可用和资源动态智能分配；

• 服务器之间建议通过万兆以太网提供心跳服务与vMotion迁移流量，集群内的所有服务器需符合集群的兼容性规则。

• 应用层：由四台服务器构建VMware ESXi Cluster。

1、跨中心大二层网络

为了降低二层网络，evn otv必须整体在一个二层网络里，这种情况怎么实现呢？这里就需要考虑到大二层网络，有那么几种技术，一种是EVN/OTV/EVI技术，通过Mac in ip，实现了这两个中间的二层网络互通。EVN的话，以中间为界，这是一个机房，这是另外一个机房，这是它们内部接入的交换机，然后它们把这个接入到这上面，中心间也是类似的，这个P和这个P之间打通，这样就实现了互通。

第二个方案是采用二层光纤直连技术打通。每个中心部署互联汇聚交换机，中心内的汇聚（网关）交换机通过链路聚合接入该互联汇聚交换机，互联汇聚交换机通过链路聚合接入波分设备，链路聚合保证整网无二层环路。同时在汇聚互联交换机配置二层风暴抑制。

第三种基于MPLS网络的VPLS互联。每个中心的核心交换机与专用的MPLS域专用网络直连，通过MPLS专属网络的本地PE设备与对端中心的机房PE设备之间建立VPN，将各个PE设备所互连的二层网络通过MPLS  VPN方式建立二层互通。

第四种为基于Overlay网络的大二层互联。

以Vxlan实现方式为例，每个中心通过单独的ED设备与Underlay网络连接，在每个中心内部业务数据通过VXLAN进行业务交换，涉及到跨中心业务互访时，将通过与ED设备直连的leaf设备剥离VXLAN标签转换为VLAN业务后，由ED设备再次进行VXLAN封装，从而通过大二层透传到对端中心的ED设备剥离VXLAN标签，由对端中心的leaf设备重新封装VXLAN标签。一种是VPLS模式，这个是一个标准协议，但是技术比较复杂。大二层互联也是叠加在现有的网络之上，但是是每个厂家私有协议，在复杂的网络环境中很难实现对接。支持Overlay网络，可以跨裸光。

2、关于Golden Gate

还有刚才提到的Golden Gate性能瓶颈在数据同步环节，即在复制进程Replicat入库速度，因为在容灾端恢复数据过程是执行逻辑SQL，比较消耗资源。

抽取进程（Extract） ：该进程主要瓶颈在于LCR(logical change record)转换为UDF环节，主要优化建议：

• 拆分Extract进程，建议同一个schema下表尽量在一个进程组中

• 优化进程参数如eofdelay、flushsecs等

• I/O部分建议增加日志读取间隔3s，增加内存刷新时间3s

投递进程（Pump）：带宽优化和IO优化：

• 复制的表最好有主键或唯一索引，减少生产日志量

• 数据传输过程启用数据压缩特性，减少带宽需求量

• 适当增大TCP缓存

• 增加队列读取间隔为3s，内存刷新时间为5s

复制/应用进程（Replicat）：该环节出现性能问题较多，需要重点优化：

• 合并小交易减少事物数量，减少写checkpoint file/table次数

• 大交易拆分（maxtransops参数），提高写入速度

• 基于表或Range等拆分replicat进程

还有就是这边变化得非常大，尤其在这方面是非常大的，如何优化中进行一定的拆分，建议同一个schema下表尽量在一个进程组中，这个独立解决也可以进行带宽优化和IO优化。合并小交易减少事物数量，减少写checkpoint file次数。大交易拆分，提高写入速度，基于表等拆分进程。这是一个表，在每分钟产生的数据量，如果在16G以下，基本上是准时的，但如果在16G以上延迟非常高，每分钟40G的话，能延迟到1小时了。所以它做的市场上的业务量大，能延迟。

3、关于ADG

这也是我们一个前提测试的情况，我们用了一个数据库的数据总量11G，存储总量是这些，这是它的规格，有40G，有280G左右，我们当时采用的是千兆网，传输日志平均占用带宽为16.24MB/s，单个小时内峰值为52MB/s。目前这是一个测试情况，另外一个注意的地方，需要做的好多测试参数，底层依赖于存储，他们之间设置的参数有规则，参数的超时时间不能随便设，必须保证RAC的磁盘仲裁要晚于GPFS的仲裁，使得在网络故障情况下GPFS提前RAC做出判定。这样才能避免数据的损坏。

4、防止“脑裂”现象

• 由于数据中心间距离远，网络稳定性相比同机房差，必须需要额外进行冗余设计，如网络连接、内部网络、san连接等。2个数据中心间网络不稳定情况下，无论存储虚拟化技术还是Oracle的RAC均可能出现“脑裂”现象，造成访问中断，数据不一致现象发生，需要仔细设计，如采用互联环状全冗余架构等、完善的仲裁机制等。

• 对跨中心间的网络带宽、存储访问带宽利用率不能超过30%。

• 双活由多层软硬件组成，如数据库RAC、远程文件系统、存储等，需要仔细规划它们之间的心跳参数，确保越低层的心跳超时时间越高。

5、全面的计划内外测试场景

双活涉及到跨中心网络层，数据层和存储层，故障场景相比较传统架构更多，更复杂，相互之间存在多种依赖关系，需要充分设计故障测试场景。如果建设的话需要重点进行测试。

这是我们建设的一个双活数据中心架构的例子，这是两个机房，它的上层是接入网，下层是Spine。下面是各个虚拟化接口，应用层，提供虚拟层跨中心迁移功能。再下面是个存储层，双活架构。

今天分享就到这里。若有疑问，欢迎留言交流。