为什么采用两地三中心GDPS 双活解决方案

为什么采用两地三中心GDPS 双活解决方案？

澄清一个概念，如果我们仅仅是指两地三中心GDPS灾备解决方案的话，那么早在七－八年前国内很多大行就已经做到了这一点，具体的实现多是通过同城两个中心的GDPS PPRC解决方案联合异城两个中心的GDPS z/OS Global Mirror或者GDPS Global Mirror解决方案．我们这里提到的两地三中心GDPS双活解决方案是近三年来很火的一个专题，而且因为今年在某一大行的成功实施，使得这个主题无数次被提及，那么为什么要采用两地三中心GDPS 双活解决方案呢？哪些场景下可以用到这个解决方案？

想来大家都应该看到过：银行营业网点或者银行官网上会发出因为某系统升级或者故障从凌晨几点到几点无法做交易的消息．　事实上无论是计划内的应用，数据库，中间件，系统和硬件升级维护，或者计划外的系统综合休(SYSPLEX）级的故障，还是突如其来的火灾，地震，水灾，以及最要命的恐怖袭击，都有可能造成银行系统的不可用，进而造成业务的中断．各大行都迫切希望减少计划内和计划外停机的业务不可用时间，最好能够在面对各种极端情况时，依然能够保证业务的持续可用性，让用户感觉不到有任何故障存在，故两地三中心GDPS 双活业务持续可用解决方案应运而生．该解决方案在不同城市的两个数据中心间沿用已经存在的GDPS z/OS Global Mirror灾备解决方案，其核心则在于同城两个数据中心间的GDPS双活方案，从而使得关键应用运行于同城的任一个数据中心，在这两个数据中心之间做到自如地站点级别切换，一个站点的应用故障不会影响到另外一个站点的应用 *** 作．

GDPS双活的英文全称是Geographically Dispersed Parallel Sysplex Active-Active，即地理分散并行系统综合体双活解决方案．　该解决方案由两个分布于不同数据中心的并行系统综合体组成，这两个数据中心的功能分布是1:1模式，同时对外提供服务，数据中心间实现负载均衡，任何一个中心具备100%生产支持能力，具备无缝业务切换能力，减少应用停机时间，从而保证业务的持续可用性．

说到GDPS 双活解决方案的适用场景，我们需要明确GDPS双活解决方案是一个新生的且持续发展的解决方案，总共分成三个阶段，第一阶段为GDPS Active-Standby, 第二阶段为 GDPS Active-Query, 第三阶段为 GDPS Active-Active, 当前处于第二个阶段．

在当前GDPS Active-Query通常的配置中，两个Active 的站点A和B，站点A是生产站点，主要用于运行核心业务，包含OLTP(联机事务处理) 和批量作业,　站点B则只用于运行只读的Query(查询)，并且随时准备着运行OLTP和批量作业　如果在站点B上监控到端到端的延时超过预定义的阈值，那么Query能够自动地Switch到站点A去做运行，当然这里我们可以在一分钟内通过SA REXX从监控表里抽几次样，如果几次都超过的话，再做切换，会更为合适．对于站点A而言，如果行里要对站点A的生产系统进行升级和改造，以前在行里通常需要请求三到五个小时的停机时间窗口(遇到问题的话，可能会更久)，在这个过程中，站点A是无法对外界提供服务的，但是现在采用了GDPS 双活方案后，因为站点 B可以无缝接管站点A的业务，所以可以通过GDPS A-A作站点级切换，把OLTP Workload 定向到站点B，由B站点对外界提供业务，此时所有的OLTP和Query Workload都运行在了站点B，整个过程对于客户而言，都是透明的．然后对站点A进行升级，可以是升级应用程序，硬件，DB2z版本，甚至z/OS, 到升级完成后，在B站点停OLTP　Workload,反向同步站点B改变的数据到站点A, 再把OLTP Workload回切到站点A 整个过程中，站点切换耗时大概2分钟左右，回切基本上是相近时间，在站点B停OLTP Workload并反向同步数据耗时大概是10分钟，加到一起整个升级过程把对外界不能提供业务的时间控制在了十分钟的级别，与原有的三至五个小时相比有了巨大的改进

灾备双活如何实现数据同步？

问题1：金融系统中同城灾备如何实现数据实时同步（两地是异构存储），请软件推荐和方法？

问题2：如果是远距离（1000KM）异地灾备双活，如何较好的实现数据同步？

希望获得：具体解决, 注意事项, 实例参考

问题1：金融系统中同城灾备如何实现数据实时同步（两地是异构存储），请软件推荐和方法

问题2：如果是远距离（1000KM）异地灾备双活，如何较好的实现数据同步？

A1：数据实时同步复制有两种大的分类：

1）存储复制 - 即使异构存储也能，只不过效果差点。利用虚拟化网关集群设备（比如VPLEX）。但是有一个缺点，存储层面的块儿复制，解决不了逻辑校验的问题，有可能同步过去的块儿数据，数据库无法识别。

2）数据库层面的复制，Oracle、db2都有。是基于日志的复制，数据复制量很小。很安全。但是灾难时刻拉起数据库的时间也不是很理想。有条件的做一下自动化开发。

wangj0923技术经理 , 工行

存储复制最大的问题是，复制过去的磁盘对数据库来讲突然下宕后挂上的，有可能不识别，即便识别了，也要进行一致性校验，那个时间是无法忍受的。

数据库复制的问题是同步模式对主库的影响较大，备库出问题容易hang主库，而异步模式无法确保RPO为零。

需要各种技术组合起来用。

shenxzh系统工程师 , Nanjing Securities

同城灾备，如果是ORACLE数据库，可以使用远距离RAC，实现同城双活数据中心（通过ORACLE ASM实现异构存储双活，或者存储虚拟设备VPLEX,SVC等）

远距离异地灾备，最好使用主备模式，采用dataguard利用异步模式（或采用12C的far sync功能），保证数据安全

else_xie系统运维工程师 , PICC

cz_doctor、xk2008赞同了此回答

首先要确定，实现要异地实时同步，生产环境答应吗？

另外带宽，速度的压力，成本投入能答应吗？

每一个数据的修改交互，都需要问1000KM外的，是否OK了。然后才下一步？那多累的，估计某些应用可以，同步数据少的，对业务性能不敏感的。

现在很多存储的复制技术，异步效果也趋于同步效果，只要业务压力在可接受范围内，就能及时传送数据过去，只要自己明白，如果遇到业务高峰时，是要承受数据传输滞后比较明显的结果而已。

另外，对复制同步的数据，如果不是在线进行使用的，要定期的验证检查，反正数据已经是“带病”的，还一直在同步，哪天真的要用，才发现，那就迟了。

zhoujia8218(提问者)

你的这些反问点，都是我要关注的和不明确的地方，谢谢提醒

nitkey系统架构师 , ECT

xiaoyaozi赞同了此回答

问题1：异构存储要实现同城实时同步有几种实现方式：1存储前面加一层虚拟网关，通过虚拟网关来实现两个存储的数据同步；2 *** 作系统层面，通过LVM或者veritas的卷管理软件实现；3通过应用层自己实现数据同步，比如ORACLE的DG，DB2的HADR。同城实时同步一般对架构环境的要求都较高，如果再加上是异构存储，要特别注意两个存储的性能是否匹配，否则会出现短板

问题2:1000KM以上我认为基本上只有靠存储的异步复制，通过数据库的复制方式在远距离的案例上不是太多。

孔再华数据库运维工程师 , 中国民生银行

同城灾备可以做到对等双活。相当于双中心不差别提供服务。数据库技术有DB2 GDPC和Oracle Extended RAC。DB2 GDPC集群底层通过GPFS集群文件系统完成数据同步，支持异构的存储。

远距离灾备如果需要双活肯定是有很大限制的。首先数据不可能实时同步，代价太大。因此对一致性要求高的系统几乎不可能。但是如果使用异步的方式，例如DB2的HADR技术，或者是CDC等数据逻辑同步技术，能够做到同步数据，但是灾备服务器只能用来做查询分析等作用。

zhoujia8218(提问者)

CDC远距离复制时有没有需要注意的吗？我们只用过同城的，远距离的没有尝试过

以上就是关于为什么采用两地三中心GDPS 双活解决方案全部的内容，包括:为什么采用两地三中心GDPS 双活解决方案、如何使用虚拟化软件实现双活灾备系统、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！