双活数据中心容灾解决方案

1、 双活数据中心容灾解决方案为什么要讲双活数据中心？从应用系统和系统保护来说，分这么几个角度：首先做容灾，第一个要考虑的是主备，上图左侧是最早出现的主备模式，一般是在两个中心建互备系统，比如我在B中心，容灾系统在另外一个地方，这种模式比较容易切换。假如A中心出问题了，就绑定在B中心，或者是把数据复制到B中心，容灾资源是闲置着，承担着容灾的任务。另外真的出问题了，我得需要一个定位，因为并不能确认它是否确实不能用了，所以，要确保这个业务完整，数据也不丢，定的时间加上切换流程，至少得0.5小时，甚至更长，甚至一两天，这样导致弊端很多。后来为了节约资源，发展到现在双中心互备，A中心一部分做生产，B中心也

2、一部分做生产，在原来的储备方式上做了一个改进，优点是因为这两个中心都有生产业务运行，可通过资源共享技术节省资源。但仅仅是计算源，对于存储来说，由于这个存储空间必须要保证完整来做，所以没有办法充分利用起来，还是闲置状态。针对这种问题，我们现在又有了双活并行模式，同一个系统，两个中心都可以承担业务，同时对外服务，坏掉任何一方不影响。这是非常理想的一种状态，今天主要讲的是要实现这种架构或部分实现，需要哪些技术，需要做哪些工作，只是简单的讲，不一定很深入，也希望能够和大家一起沟通交流，看有没有更好更优的方案。我主要从应用到基础设施的角度来讲。因为从整个应用架构来看，咱们有一些业务可能是有接入层，下面是

3、应用逻辑，后面包括还有一些接口，再下面是数据层，再下面是基础架构，有可能有存储和网络，这么几层，每一层都会有相应的双活实现技术。例如应用层可能有各种集群，数据层可能有一边同时可读写，或一边只能读等。再如基础架构层，在网络上对稳定性和带宽吞吐性能要求更高，甚至需要打通跨中心的大二层网络，存储方面则需改变一主一备的读写机制，实现同时可读写。下面从这五个方面展开谈，一个是数据层，二是存储层，三是接入/应用层，四是虚拟化/云平台；五是技术关键点。一、数据层首先讲数据层（这里指传统数据库）中的双活方式，一种叫Active Standby方式，一种方式为两个都是Active方式，此外还有数据逻辑复制软件模

4、式。Active Standby是基于Oracle ADG技术，这个模式采用从主库向备库传输redo日志方式，备库恢复数据过程可以用只读方式打开进行查询操作，实现了部分双活功能，在主节点故障后可以将备节点切为生产。ActiveActive方式指的是两点都可以同时读写，例如通过Oracle Extend RAC实现多个集群节点同时对外提供业务访问。该方式能做到故障无缝切换，提升应用系统整体性能。这种模式理论上不需进行人工切换操作。另外在基于逻辑复制的软件，利用数据库在线日志中的数据变化信息，通过网络将变化信息投递到目标端，最后将目标端还原数据，从而实现源目标的数据同步。方式一：Oracle AD

5、G首先第一个模式是Oracle ADG模式。通过网络从生产向容灾传输归档或redo日志，容灾端恢复方式同步恢复。这个数据库不断把日志写入到备库。这种方式的优点是存储支持异构。应用场景：可以把这个库可以作为应急或容灾用，作为数据保护手段。方式二：逻辑复制通过DSG、GoldenGate等逻辑复制软件技术实现跨中心数据库的相互复制，这种逻辑复制支持表级的复制，要求两个数据中心各建一套数据库，物理独立，同时能读写。基于数据库日志准实时复制数据，支持异构数据库，异构OS。可以实现一对一、一对多，多对一、双向复制等多种拓扑结构。把日志进行分析，写到这个库，是以跨中心的共享存储基础，通过共享存储资源和Or

6、acle数据库集群软件管理，实现各个中心节点对数据库并行访问。方式三：Oracle 远程RAC Oracle Extended RAC以跨中心共享存储为基础，通过共享存储资源和Oracle Clusterware数据库集群管理，实现各个中心节点对数据库并行访问。共享存储可以采用存储自身数据复制技术，存储虚拟网关或远程卷管理等技术，以Oracle ASM存储卷管理为例，实现数据的双向实时复制。要点：两个数据中心分别部署一套存储，各提供一套LUN设备给全部数据库主机。存储的SAN网络和RAC心跳网络需使用低延迟、高带宽的DWDM光纤链路。配置ASM磁盘组。每个磁盘组配置两个失效组，每个失效组对应来

7、自一套存储的LUN设备。在第三个站点部署用于RAC的第3个投票盘，使用NFS的方式挂载到所有数据库主机。与管理普通的RAC系统类似，需要重点加强对站点间光纤链路情况的监控与应急。内存库双活技术内存库双活技术，将数据放在内存中直接操作的数据库，相对于磁盘，内存的数据读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。应用场景：用于实时计费，读写分离场景，主要有Oracle Times Ten，Altibase商用以及华为等相关产品。内存库集群部署主要有HA模式，双活模式，线性拆分和分布式集群四种模式。内存库通过复制手段，实时地复制到另外一个中心，它们之间是一个跨

8、中心的数据，这是HA模式。另外双活模式，和这个模式是HA模式的延伸，可能一部分表是一个方向复制，另外一些表反过来。还有一种是线性拆分模式，将内存数据放在多个内存库集群中，每个内存库存放一部分数据，并互为备份，这种模式需要应用进行针对性改造。分布式集群模式，自动实现不同数据分片和副本机制，是目前比较流行的一种结构。数据层双活技术比较逻辑技术软件容易出现逻辑错误导致数据不一致，而且很难稽核。ADG模式数据在数据库级是完全一致的，当然前提是能正常同步，但是不支持两边同时能读写。从数据延迟来看，不管是ADG还是逻辑复制软件，都跟日志量有关系，后面会讲我们在不同日志量情况下做的测试延迟结果。二、存储层存

9、储层作为双活系统核心基础架构平台，其双活技术在整个架构中起到关键作用，目前基于存储层双活方案主要有下面三种：基于远程卷管理软件的虚拟化，比如Symantec SF、IBM GPFS、Oracle ASM等。基于存储网关虚礼化，如EMC、vplex、IBM、SVC。在传统存储上面增加了一个虚拟化网关，在每个机房里面，新增存储虚拟化网关设备组成跨站点集群，并对存储卷进行重新封装，对外提供主机访问。存储卷镜像技术，将两套磁盘阵列组成一个集群，两台存储上的LUN被虚拟化为一个虚拟卷。流派一 远程卷管理软件数据同步：底层数据复制采用远程卷管理软件，如赛门铁克的storage Foundation（SF）

10、、IBM的GPFS、Oracle的ASM等，通过逻辑卷镜像技术实现底层数据逻辑同步。上层应用采用Oracle Extended RAC方案实现远程多节点RAC，使生产和容灾节点都处于在线状态，应用逻辑访问的是同一个数据库。数据读写：支持双读写。数据一致性：完全一致。上面是不用远程卷管理软件的一个情况，我只需要认识到自己机房的存储就可以了。底层存储实现远程复制到容灾存储上，如果改造成远程管理软件，那么服务器既要认到本地存储也要认到对端存储，实现两边都是同时可以对存储读写的，而且还可以通过设置策略，写的话向2个存储同时写，读的话可以优先读本地的，从而可以加快读的速度。流派二 存储网关虚拟化实现原理

11、：将存储虚拟化技术和Oracle的远程RAC技术结合，实现跨中心的数据双活访问。平时两边主机分别访问本地存储，故障情况下可垮中心访问对方存储。对于同一个数据块的读写冲突机制，是由Oracle RAC来保证的。存储不能直接给服务器访问，需要先通过中间层虚拟化网关设备，再访问存储。为了防止出现两个中心间网络全断情况下，两边互相不知道谁还活着，需要建一个仲裁节点（建议在第三个中心），实现让谁作为主，让谁作为访问的仲裁机制，从而防止数据不一致这种极端情况。流派三 基于存储自身卷镜像这是一个存储自身卷的镜像，这是一些新的设备情况，它的优点，整个网络架构没有改变，从主机到交换机到存储，也没有增加任何的设备

12、，这种是相对来说比较易于实行（也需要一个仲裁站点）。存储层双活技术对比这是一个存储层的双活技术比较，容灾技术有2个重要参数，RPO（故障恢复点）和RTO（故障恢复时间）。这几种理论上都能实现RPO等于0，也能支持双活读写。从可靠性来看，这个数据不是完全决定的，需要根据实际情况定。从异构性来说，除了存储自身虚拟化和存储HA机制不支持外，其余都支持。但不管存储双活有哪几种，双活都需要用到远程Extend RAC。三、接入/应用层下图是一个例子，一个比较前端的系统，分为接入/接口层、应用层、主机/数据库层、存储层等，各个层面统筹考虑双活机制，才能实现零切换。首先不能像原来烟筒式的数据库连接，应考虑统

13、一数据库访问接口，并实现应用自动重联机制，确保自动切换，减少人工切换。在应用层，则考虑双中心部署相同的应用集群方式，或跨中心的集群方式。从接入层看，如何把业务接入到两个中心，一般有这么几种，一种是采用全局负载均衡（如F5的GTM）、DNS、或前置CDN等技术实现跨中心灵活接入。业务多中心并行模式：通过一组GSLB来对外提供服务，GSLB监控服务的状态，并通知组内其他设备，对于每一个DNS请求返回最佳结果，好的策略选择和配置方式可以最大幅度提高客户体验。业务多中心互备模式：对于内网业务通过一组SLB来提供服务，实现DNS解析，负载分发和故障切换。前置CDN，通过CDN来进行不同中心的业务接入。四

14、、虚拟化现在都在讲云计算，是非常热门的，其主要技术特征，首先是带来虚拟化技术，其次应用实现集群化和x86化。相应带来的问题：我们原来的双活设计模式，可能不适应这种虚拟化或应用集群化模式，需要重新考虑业务连续性双活方案。我总结了四大类：继续沿用传统基于负载均衡的双活架构。每个中心部署独立的云化应用集群，通过接入层负载均衡实现双活。举个例子，有Web集群，通过前面接入增把业务分发到不同集群去。基于分布式应用协调机制，可以建一套跨中心应用集群，通过分布式应用协调机制，实现跨中心的高可靠性集群，统一配置，统一管理和任务分配。Hadoop、MPP等的双活机制，应用写两份方式实现双活，跨中心集群方式。虚拟

15、化平台的跨中心双活（迁移），我们也是既可以建跨中心集群，也可以建两个独立集群，通过一些业务来分发。举个例子，我们现在可以建云资源池，建一些独立的池。模式一 相互独立的双集群在每个中心部署独立的云化应用集群：如Web类应用可通过接入层和负载均衡实现双活访问；如Hadoop或MPP集群应用可通过上层应用实现双集群数据同步，从而实现双活。模式二 跨中心单集群模式第一种是基于分布式应用协调机制：构建一套跨中心应用集群，通过分布式应用协调如ZooKeeper实现跨中心的高可靠性集群，实现统一配置、统一管理和任务分配。第二种是基于数据副本保护机制：如详单云和大数据的Hadoop集群、大数据的MPP集群等，

16、通过进行合理规划设计，确保任一中心节点都是完整的数据副本，由集群自动维护两个中心的数据副本同步机制来实现双活。虚拟化云平台双活基于存储阵列双活和VMware 跨站点集群功能实现虚拟化平台数据中心容灾解决方案，在阵列双活技术支撑下，通过VMware Cluster 的HA高可用功能实现故障业务切换保护，从而达到保证业务连续性的要求。网络站点间二层互联，采用波分传输，存储实现双活为上层提供共享存储；将两个数据中心服务器配置为一个集群，通过HA和DRS实现高可用和资源动态智能分配；服务器之间建议通过万兆以太网提供心跳服务与vMotion迁移流量，集群内的所有服务器需符合集群的兼容性规则。应用层：由四

17、台服务器构建VMware ESXi Cluster。五、双活技术关键点1、跨中心大二层网络为了降低二层网络，evn otv必须整体在一个二层网络里，这种情况怎么实现呢？这里就需要考虑到大二层网络，有那么几种技术，一种是EVN/OTV/EVI技术，通过Mac in ip，实现了这两个中间的二层网络互通。EVN的话，以中间为界，这是一个机房，这是另外一个机房，这是它们内部接入的交换机，然后它们把这个接入到这上面，中心间也是类似的，这个P和这个P之间打通，这样就实现了互通。第二个方案是采用二层光纤直连技术打通。每个中心部署互联汇聚交换机，中心内的汇聚（网关）交换机通过链路聚合接入该互联汇聚交换机，互

18、联汇聚交换机通过链路聚合接入波分设备，链路聚合保证整网无二层环路。同时在汇聚互联交换机配置二层风暴抑制。第三种基于MPLS网络的VPLS互联。每个中心的核心交换机与专用的MPLS域专用网络直连，通过MPLS专属网络的本地PE设备与对端中心的机房PE设备之间建立VPN，将各个PE设备所互连的二层网络通过MPLS VPN方式建立二层互通。第四种为基于Overlay网络的大二层互联。以Vxlan实现方式为例，每个中心通过单独的ED设备与Underlay网络连接，在每个中心内部业务数据通过VXLAN进行业务交换，涉及到跨中心业务互访时，将通过与ED设备直连的leaf设备剥离VXLAN标签转换为VLAN

19、业务后，由ED设备再次进行VXLAN封装，从而通过大二层透传到对端中心的ED设备剥离VXLAN标签，由对端中心的leaf设备重新封装VXLAN标签。一种是VPLS模式，这个是一个标准协议，但是技术比较复杂。大二层互联也是叠加在现有的网络之上，但是是每个厂家私有协议，在复杂的网络环境中很难实现对接。支持Overlay网络，可以跨裸光。2、关于Golden Gate还有刚才提到的Golden Gate性能瓶颈在数据同步环节，即在复制进程Replicat入库速度，因为在容灾端恢复数据过程是执行逻辑SQL，比较消耗资源。抽取进程（Extract） ：该进程主要瓶颈在于LCR(logical chang

20、e 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