从IT应用架构角度，畅谈双活数据中心容灾解决方案

《从IT应用架构角度，畅谈双活数据中心容灾解决方案》要点：
本文介绍了从IT应用架构角度，畅谈双活数据中心容灾解决方案，希望对您有用。如果有疑问，可以联系我们。

本文根据朱祥磊老师在〖5月6日DBAplus社群济南数据库技术沙龙〗现场演讲内容整理而成.

讲师介绍：朱祥磊

运营商系统架构师

• 负责业务支撑系统架构规划和建设.获国家级创新奖1项、通信行业级科技进步奖2项、移动集团级业务服务创新奖3项,申请发明专利13项.

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

首先做容灾,第一个要考虑的是主备,上图左侧是最早出现的主备模式,一般是在两个中心建互备系统,比如我在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等技术实现跨中心灵活接入.

• 业务多中心并行模式：通过一组GSLB来对外提供服务,GSLB监控服务的状态,并通知组内其他设备,对于每一个DNS请求返回最佳结果,好的策略选择和配置方式可以最大幅度提高客户体验.
• 业务多中心互备模式：对于内网业务通过一组SLB来提供服务,实现DNS解析,负载分发和故障切换.
• 前置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.下面是各个虚拟化接口,应用层,提供虚拟层跨中心迁移功能.再下面是个存储层,双活架构.

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

文章来自微信公众号：DBAplus社群

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4121.html