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

朱祥磊 2017-05-16 09:47:44

本文根据朱祥磊老师在〖5月6日DBAplus社群济南数据库技术沙龙〗现场演讲内容整理而成。点击文末链接还能下载PPT哦~

 

讲师介绍

朱祥磊

运营商系统架构师

 

  • 负责业务支撑系统架构规划和建设。获国家级创新奖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等技术实现跨中心灵活接入。

 

  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。下面是各个虚拟化接口,应用层,提供虚拟层跨中心迁移功能。再下面是个存储层,双活架构。

 

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

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告