当前位置:研发设计首页 >> 管理信息化 >> 知识工程 >> 从IT应用架构角度,畅谈双活数据中心容灾解决方案
从IT应用架构角度,畅谈双活数据中心容灾解决方案
2017-05-24 16:27:30  作者:朱祥磊   来源:互联网
  •   运营商系统架构师   负责业务支撑系统架构规划和建设。获国家级创新奖1项、通信行业级科技进步奖2项、移动集团级业务服务创新奖3项,申请发明专利13项。   为什么要讲双活数据中心?从应用系统和系统保 ...

  运营商系统架构师

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

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

  

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

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

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

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

  

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

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

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

  一、数据层

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

  

数据层

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

  

数据层

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

  

数据层

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

  方式一:Oracle ADG

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

  

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

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

  方式二:逻辑复制

  

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

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

  方式三:Oracle 远程RAC

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

  

Oracle

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

  要点:

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

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

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

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

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

  内存库双活技术

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

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

  

内存库双活技术

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

  数据层双活技术比较

  

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

  逻辑技术软件容易出现逻辑错误导致数据不一致,而且很难稽核。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之间打通,这样就实现了互通。

  

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

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

  

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

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

  

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

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

  

 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

  

ADG

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

  4、防止“脑裂”现象

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

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

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

  

ADG

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

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

  

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

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



版权所有:智造网 京ICP证100778号 京公网安备110102003025 虚假新闻举报电话:010-88379107