本文简要描述了几种双活模式,以及每种双活模式的适用场景,结合目前常用的几种双活方案进行了简要说明,并通过比较对几种方案的优缺点进行了简单分析,以供读者在进行双活方案选择时参考。
随着信息化技术的不断发展,应用系统的高可用性已经成为企业获得良好发展、赢得市场信誉的基本要求,尤其对于广大银行企业来说,系统停机时间的增长不仅直接会给企业带来重要的财产损失,而且更重要的是也就意味着会有一批重要客户的流失,而这些客户可能是企业赖以生存的根本。与此同时,商业银行信息系统的安全、稳定运行关系着国家金融安全和社会稳定,大力发展灾备系统及业务连续性体系建设不仅成为银行自身发展的需求,而且已成为人民银行及银监会对银行的硬性要求。目前,两地三中心的灾备模式已经在众多银行得以推广运行,但为了充分利用灾备中心的软硬件资源,保护已有投资,近年来又产生了双中心双活、多中心多活的概念及架构模型,本文将针对这一主题进行探讨,分别就存在的双活模式、双活模式的适用场景以及业界当前针对数据库双活的几种备选方案进行说明。
一双活模式
Activ-Qury(简称AQ模式)
AQ模式是常用的站点内“交易库-历史库”架构模式的延伸,即正常情况下,主数据中心处理读写类型的应用请求,备数据中心处理只读类型的应用请求,数据从主数据中心复制到备数据中心,但与之不同的是,当主站点出现故障时,备站点可以同时受理交易和查询请求,数据进行反向复制,当备站点出现故障时,主站点可以同时受理交易和查询请求。
由于出现站点故障时,除了需要进行应用切换之外,还需要对数据库的服务模式进行切换,这需要较长的切换时间(分钟级)。同时,由于两个数据中心处理的业务模式不同,因此,很难做到中心间的负载均衡。
Activ-Activ(简称AA模式)
AA模式是理想的双活架构,此模式要求主数据中心和备数据中心均可受理读写类型的应用请求,数据在主数据中心和备数据中心之间进行双向复制。考虑到发生数据更改冲突时不仅可能造成应用处理性能的下降(单库,集群模式),而且极易造成站点间数据的不一致(分库,同步模式),因此,往往需要在应用设计层面尽量避免数据同时更改的冲突。根据双活中心之间业务处理模式的不同,又可以分为如下两类:
一种是非对称的双活(即AsymmtricActiv-Activ简称AAA)即通过业务拆分,使主备中心分别处理不同的业务,即正常情况下,某种特定类型的工作负载只会由一个特定的数据中心进行处理。出现站点故障时,需要进行应用切换,这需要一定的切换时间(分钟级)。但由于两个数据中心处理的业务种类存在不同,所以,很难做到两个数据中心的完全负载均衡,要达到更好的负载均衡效果,需要在进行业务拆分时,除了考虑业务之间的依赖性之外,还需综合考虑实际的业务处理复杂度、业务量等多种因素。
一种是对称的双活(即SymmtricActiv-Activ简称SAA)即主备数据中心之间完全对等地处理所有应用请求,对于任何一个应用请求,在任何一个数据中心进行处理的概率相同,最终在哪个数据中心处理由负载均衡设备决定。由于两个数据中心正常情况下均可以处理所有类型的应用请求,所以,当出现站点故障时,具有无缝的应用切换能力,几乎不会产生任何的切换时间,并且,借助于负载均衡设备,可以使得两个数据中心之间达到最好的负载均衡效果。
二适用场景分析
双活数据中心是容灾中心建设的延续和发展。相对主备数据中心的方案,双活方案极大地提高了数据中心设备的利用率,使用户投资得到最大程度的保护。但数据中心是否可以做到双活取决于应用的具体架构和业务模式。就目前的技术水平而言,不是任何应用都适合“双活”。因此,在考虑一个业务或应用环境的灾备方案时,需要从应用架构出发,设计出适合业务需求的切实可行的方案。
AQ模式的适用场景分析
一端处理交易,一端处理查询,该模式下写操作只发生在一个站点,数据进行单向复制,直接规避了数据更改冲突的问题。
由于所有的应用系统都必然存在这两种操作,所以,实际上绝大多数应用系统都适合采用该模式,尤其对于兼具交易处理和综合查询(尤其是复杂查询)并且查询负载较高的应用来说,更为适合。
AQ模式对于双活架构的设计选择比较灵活,可以采用分库并进行库间数据同步的方式,也可以采用数据库集群的方式。
AAA模式的适用场景分析
该模式的关键在于通过业务及设计层面的拆分,将应用拆分为相互独立的多个子系统或者子功能组合,使得这些子系统或者子功能组合之间不会出现更新同一数据的情况。因此,只要应用中不存在贯穿所有业务类型的热点数据,都可以采用该种架构模式。
AQ模式对于双活架构的设计选择比较灵活,可以采用分库并进行库间数据同步的方式,也可以采用数据库集群的方式。
SAA模式的适用场景分析
这种类型的双活模式实施过程和使用效果最为理想,但对业务需求的约束最为苛刻。如果业务之间存在很强的依赖关系,由于这些依赖关系的存在,就势必要求具有强依赖关系的业务必须在一个站点进行处理,而这是和SSA模式的特点相违背的。因此,该模式只适用于业务独立性很强的业务系统中。
由于要求两个站点之间实时看到相同的数据,这就只能基于数据库集群方式实现的双活来实现。
三存储层双活技术
实现数据存储层(文件系统、数据库)的双活是整个双活中心建设的核心,以下就几种常见的用于实现整个数据存储层双活的技术进行简要说明。
3.1存储系统双活
目前用于双活数据中心建设的主要有如下三种存储系统架构方案:
一、基于主机磁盘卷镜像技术,如VERITASVolumRplicator(简称VVR),这种方式需要消耗一定的主机和CPU资源,会一定程度地影响应用系统的性能。
二、基于虚拟化卷镜像技术,如IBMSVC、EMCVPLEXMtro,这种方式需要在主机和存储层之间增加虚拟化层,在增加了架构复杂度的同时,也引进了虚拟化层这一新的故障点,并可能导致成本增加,性能下降。但采用该技术可使得主生产中心产生的数据可以在备中心进行本地读取。
三、基于存储同步复制技术,如HDSHAM和IBMOpnHyprSwap,这种方式完全基于存储系统实现数据同步复制,性能较高,且需要的投资成本较低。但存在的缺点是应用系统只能同时访问一端的存储系统,正常情况下,位于复制目标端的存储系统不能供应用访问。从这种意义上来讲,并不属于严格意义上的存储系统双活。
3.2文件系统的双活
文件系统的双活实现可以基于上述存储系统双活的技术实现,也可以通过诸如IBMGPFS技术实现,建立跨站点的共享文件系统GPFS,通过建立failgroup由GPFS实现站点间的数据同步。
3.3数据库双活
3.3.1数据库集群方式实现的双活
数据库的双活通常依赖采用Shar-Disk架构的数据库集群技术实现,比如ORACLEExtnddRAC以及IBM开放式平台上的GDPC以及基于大型主机平台的DataSharing。这通常需要依赖于共享文件系统,并且考虑到双活的需要,需要在站点间进行数据实时同步,这需要依赖于存储系统的双活技术或者诸如GPFS技术。
在基于Shar-Disk架构的数据库集群中,ORACLERAC技术成熟度较高,在业界也有不少成功案例,但通常都是运行在单个数据中心内,扩展到两个乃至多个数据中心的案例也较少。另外,ORACLERAC有一个重要的缺陷是节点之间是网状通讯结构,这就使得集群中节点之间的通讯成本非常大,这会严重影响RAC的扩展能力。
与之相比,IBM借鉴主机平台DataSharing技术实现的开放式平台上的DB2PurScal以及通过距离扩展衍生出来的GDPC,从架构设计上建立了以powrHA节点为中心的星型结构,从而规避了普通成员节点之间日常的通讯开销,并借助高速互联网络如Infiniband等,可实现普通成员节点和powrHA节点之间远程内存访问(RDMA)操作,从而大大提高了节点之间的通讯效率,因此,从理论上可以获得更好的扩展能力以及更佳的处理性能。但由于DB2PurScal技术是最近几年才发展起来的技术,技术成熟度和实际应用案例相对较少,尤其是跨站点的集群技术,实际应用案例更少,存在一定的使用风险。
从系统架构、技术成熟度、稳定性、安全性、可扩展能力、切换效率方面,IBM主机DB2DataSharing都有业界最佳的应用实践,但IBM主机平台投资成本要远远大于开放式平台,而且,由于主机平台采用较为封闭的技术模式,这就使得无论是企业内部人员培养还是应用上线后的系统运维都需要增加更多的投资。
另外,以上这些技术有一个共同点就是在进行应用写操作时都需要同步进行存储层的跨中心写操作,因此,对于应用写入性能存在一定的影响,但由于所有的数据库写操作在双中心之间实时同步,因此,可以确保RPO=0的灾备目标。
3.3.2基于数据复制方式实现的双活
这种方式需要采用按站点分库设计,站点之间的数据库通过数据复制软件进行数据同步。市场上可供选择的数据库复制产品较多,各大数据库供应商都提供了针对各自关系型数据库的数据库复制产品,比如ORACLE的DataGuard、GoldnGat,IBM的HADR、CDC以及Q-复制等。
这些产品的共同特点是数据复制基于异步方式进行,从而使得交易处理和数据同步独立运行,可以大大提高应用的处理效率,但一旦出现站点故障,可能会丢失一定的业务数据,所以,对于严格要求RPO=0的应用而言,该方案并不适用。
由