两地三中心双活系统灾备切换场景和数据补录问题?

目前同城双活的架构部署说明如下:
1、同城双中心应用采用双活部署,数据库采用ADG复制,两中心的应用实时连接主中心的数据库,当主中心的数据库出现问题切换到灾备中心,应用通过DNS自动解析到灾备中心进行交易。
2、主备数据中心分别部署F5负载均衡,应用通过F5 LTM实现应用负载。数据中心内部通过F5 GTM实现内部DNS解析,广域网通过F5 GTM实现双数据中心DNS解析。
3、主备数据中心的网络采用三层架构(未采用二层互通),应用采用不同的网络段地址部署。
对于双活测试需要测试哪些场景?故障切换的场景应该覆盖哪些?对于非计划内的切换,数据丢失的RPO怎么验证,业务数据补录怎么做?

参与42

7同行回答

huawei851120huawei851120  数据库运维工程师 , 某省级联社
感谢TWT社区的邀请。根据我们江苏农信多年的灾备建设和切换经验,向您提出一些建议,如果说的不好请别介意。 1,灾备的目的:灾备的目的不是为了备份,更不是为了实现技术上的成就,花这么多的钱根本上是实现银行的业务连续性管理目标。 2,双活的目的:有次我参加一次讲座,还没讲完,有家...显示全部

感谢TWT社区的邀请。根据我们江苏农信多年的灾备建设和切换经验,向您提出一些建议,如果说的不好请别介意。 1,灾备的目的:灾备的目的不是为了备份,更不是为了实现技术上的成就,花这么多的钱根本上是实现银行的业务连续性管理目标。 2,双活的目的:有次我参加一次讲座,还没讲完,有家银行的领导就问我:“切换?你们都双活了还切换个啥?”这个问题能代表很多人的疑惑。双活这个技术手段为了实现的目标是更快的恢复业务,也就是说为实现更小的RTO和RPO而已。冷备切换要2个小时,双活只需10分钟。假如你不演练的话,怎么说明你的双活建设的牛呢?你没有在10分钟内切换到灾备接管业务,怎么说明你们银行的钱花的值呢?冷备摆在那不是蛮好的嘛,还省钱。您想想是不是? 3,双活怎么切:双活的系统,演练的时候优先切换数据库,再切换应用系统。切换数据库是重点,如果失败就不用再往下切换应用系统了。Oracle数据库的ADG切换效率很高,两三分钟的事情,但是你们要花10分钟进行检查(检查工作远比调度切换脚本更重要)。数据库切换没问题的话,再用DNS切换流量到灾备中心,生产端的应用根本不用停。如果检查没有问题的话,就把生产端和灾备端的应用交易日志取下来,留作监管单位来审计用。到时候你可以给他们看看,“领导您看,这个时候生产端的日志已经不滚动了,灾备端的交易日志还在滚动,灾备还在承接业务,说明我们交易已经成功切换到了灾备中心”。你就这样讲就行了,所以生产端的应用你没有必要停到,正好用来做日志对比说明你们的战果。 4,数据补录问题:我能熟练背诵很多监管文件,人行、银监、省金融办的文件里只是要求我们演练要以真实业务场景为前提进行切换(杜绝一些银行用桌面演练应付监管审计),从来没有哪一家监管单位要求我们非要做计划外的切换。计划外的切换,我建议你们千万不要做,就算你想做,你们行长同意吗?真出了问题,太严重,尤其现在很多交易都是24小时交易,通过自助设备接入完成的。如果数据真的有损失,后果不堪设想,补录非常非常麻烦。

收起
银行 · 2020-03-17
浏览4546
bbaimm88bbaimm88  系统架构师 , 银行
数据的RPO  0 应考考虑一份存储级别的 双活数据,或者异步复制的数据;不能全部依赖数据库软件高可用 (物理+逻辑冗余)双活测试场景 太多了,不同思路不同考虑, 运营商 链路,单点物理设备,系统级别,站点级别故障都要拉通测试,(分行、网店 部分及全面故障); 应用系统分依赖关系...显示全部

数据的RPO  0 应考考虑一份存储级别的 双活数据,或者异步复制的数据;不能全部依赖数据库软件高可用 (物理+逻辑冗余)
双活测试场景 太多了,不同思路不同考虑, 运营商 链路,单点物理设备,系统级别,站点级别故障都要拉通测试,(分行、网店 部分及全面故障); 应用系统分依赖关系 (比如加密平台,短信平台失效);还得同时考虑 双中心故障引起东西流量过大的风险。
综合 网络链路;各个区域路由; 系统隔离级别;应用交付调度策略,从底层一层一层来解决吧!
这个太广泛了, 几句说不完。

收起
银行 · 2020-03-17
浏览5098
  • 你们单位现在双活做了吗?或者现在做的规模是多大(多少个系统实现双活)?
    2020-03-17
  • 基础架构支持全双活,业务系统约20多套双活,其他系统部分功能双活。
    2020-03-17
  • bbaimm88  bbaimm88回复 summit
    [此评论已删除]
    2020-03-24
  • 建议 数据层:Vplex 双活存储+Oracle Extend RAC + ADG; 应用 F5+DNS 或者 vsphere+双活存储+网络大二层;
    2020-03-27
haizdlhaizdl  技术经理 , 大连
对于双活测试需要测试哪些场景? 故障切换的场景应该覆盖哪些?a)大的故障分层,从底层到上层: 存储设备、数据库、数据库计算节点、应用节点、接入层网络、汇聚及核心层网络、LTM本地负载、GTM全局负载、数据中心路由等各功能层都要测试其单点和整体功能失效情况,当然测试的时...显示全部
  1. 对于双活测试需要测试哪些场景? 故障切换的场景应该覆盖哪些?

a)大的故障分层,从底层到上层: 存储设备、数据库、数据库计算节点、应用节点、接入层网络、汇聚及核心层网络、LTM本地负载、GTM全局负载、数据中心路由等各功能层都要测试其单点和整体功能失效情况,当然测试的时候一个CASE可以覆盖多个分支。

b)数据库功能层:

ADG 无GAP正常切换、有GAP可以修复场合下的切换、有GAP不可修复场合下的切换等。

  1. 对于非计划内的切换,数据丢失的RPO怎么验证,业务数据补录怎么做?

首先,所谓非计划内的切换也分为很多种场合,例如数据可修复以及不可修复的场合,DNS切换过程是否对于全部应用都奏效,DNS缓存机制如何设计?这个需要针对自己的架构再仔细考虑考虑。

接着,我们来谈数据丢失的场合。架设日志有GAP,但是不可修复,最终强制切换成功的情况下:
数据库界定数据的唯一方式就是事务的时间戳,ADG只能从日志GAP的事务ID顺序来判断数据丢失的时间戳信息,通过时间戳信息可以转换为数据库节点的时间点。应用判断业务完整性是靠应用的事务性和应用执行的时间点信息。如果两个时间点信息一致,那么结合应用事务的完整性就可以判断不同业务数据的RPO。具体通过什么方式达到时间信息的完全一致性,可能会涉及多个方面,需要根据自己的架构综合考虑NTP、RAC MTSS、应用取时机制及事务机制等等,总而言之要保障这几个时间机制最终能达到一致,这样才能将RPO定位到业务上,后续无论是补录还是其他方式都有业务根据可依。

收起
银行 · 2020-03-16
浏览4542
xjwangbo100xjwangbo100  系统架构师 , 哈密市商业银行
双活的话 数据库应该是RAC+双活存储这种架构吧我 如果是ADG的话数据只能有一个读写 另外一个只能读显示全部

双活的话 数据库应该是RAC+双活存储这种架构吧我 如果是ADG的话数据只能有一个读写 另外一个只能读

收起
银行 · 2020-03-16
浏览4560
匿名用户匿名用户
两个中心,计算能力,人员支持相同么?如果有差距,是不是生产中心的任何局部影响的故障都会切换到灾备中心?多库还是单库?如果是多库,多库间有关联么?考虑前置机,加密机的容灾了么?...显示全部

两个中心,计算能力,人员支持相同么?如果有差距,是不是生产中心的任何局部影响的故障都会切换到灾备中心?多库还是单库?如果是多库,多库间有关联么?考虑前置机,加密机的容灾了么?

收起
软件开发 · 2020-03-16
浏览4569
  • 1、目前数据中心的配置是1:0.5的配置(除核心之外) 2、目前要做的是跟柜面系统相关的系统计划做同城双活(核心、esb、ecif、IC、加密)这六套系统。 3、单系统应用故障或者数据库故障都会切换到灾备机房运行。数据库主备数据中心都是采用RAC部署,通过ADG实现同步复制。
    2020-03-17
leodongleodong  系统工程师 , 哈尔滨
ADG做同城数据库复制,不算数据库的真双活,但能提高切换速度。场景1.同城中心数据库切换,考虑问题一、除了数据库数据,落地文件,程序文件、批量脚本如何保证一致,批量是否可以正常执行。二、应用是否需要重启,不需要的话多长时间能重新连到备库,连接应用的其他相关联的应用系统多...显示全部

ADG做同城数据库复制,不算数据库的真双活,但能提高切换速度。场景1.同城中心数据库切换,考虑问题一、除了数据库数据,落地文件,程序文件、批量脚本如何保证一致,批量是否可以正常执行。二、应用是否需要重启,不需要的话多长时间能重新连到备库,连接应用的其他相关联的应用系统多长时间恢复业务,三、切换备库后,主中心的应用连接备库后延迟增加多少,四、确定切换顺序,保证少错账或不错账。场景二. 应用切换,理论上应用切换没有特别影响,考虑问题一、是否应用系统没有主程序,每个节点都能承担所有业务,二、应用切换后批量是否可以正常同时也要考虑逻辑复制与存储复制的稳定性要差一些,增强监控策略,保证同城数据一致。

收起
银行 · 2020-03-18
浏览4158
zhaijianjzhaijianj  基础架构经理 , 奇瑞捷豹路虎汽车有限公司
1 你个这个架构不是双活吧。如果是ADG的最高保护模式(Maximum Protection)可以做到两边数据完全一样,但是,也是一边读写,一边读。切换的时候重新开库,另一边才可以读写。而且, 最高保护模式(Maximum Protection )会提高生产库的压力。一般的做法都是最高性能模式(Maximum Performa...显示全部

1 你个这个架构不是双活吧。如果是ADG的最高保护模式(Maximum Protection)可以做到两边数据完全一样,但是,也是一边读写,一边读。切换的时候重新开库,另一边才可以读写。而且, 最高保护模式(Maximum Protection )会提高生产库的压力。
一般的做法都是最高性能模式(Maximum Performance) 也是一边读写,一边读。 是异步的。RPO肯定不是0 。这比较稳妥不影响生产库。
2 F5做DNS 负载没有问题。问题是,怎么区分写请求 读请求到不同的数据中心?F5做不到的。只能在应用端处理,这个对应用来说也挺难的,除非前期应用就是这么设计的。
3  假设2的问题解决了,ADG  最高保护模式 。也只是一个读写数据中心  一个只读数据中心。停掉一边的F5做 读写测试,停掉另一边做只读测试。
RPO验证就是 写一条数据,看两边是不是都可以查到。两边的时间差就是RPO时间。 如果最高保护模式 那应该是0  最高性能模式会有RPO时间。时间的长短和性能,网络,都用关系。
如果RPO 要求的是5分钟,那丢五分钟的数据是允许的。不用补录数据。RPO=0 就不应该有补录数据的情况。
你这种情况应该用存储双活+跨站点RAC 

收起
汽车 · 2020-03-17
浏览4677
  • 我这边用的最大性能模式,不用读写分离。如果采用extendRAC,怎么保障脑裂问题?
    2020-03-27
  • extendRAC 有磁盘心跳与网络心跳, 磁盘是双活磁盘,这个双活一定要第三站点来保障仲裁; 网络一定 双机房是网络设备双冗余(底层链路是多家运营商光纤保障) Oracle心跳IP 建议选取 2组pri ip。 oracle 通过 磁盘与网络双因素 来投票 仲裁来驱逐节点的。 只要链路不同时出现抖动 还是稳定的。有保障的。
    2020-03-27
  • zhaijianj  zhaijianj回复 summit
    兄弟这么痴迷双活呀。那你就别想ADG了。跨站点的RAC保证不脑裂,这保证不了。只能降低这个风险。vplex 标准架构就有第三仲裁点,所以就存储这块包括仲裁盘,可以降低一部分风险。网络上就个个点都做好冗余,心跳线的设计,数据线的设计,RAC其实是会检测上联网关的。两站点之间的裸纤的质量,延时,冗余,有没有被其他施工单位挖断的风险,要不要选择不同的运营商等。要注意点很多。我的观点是双活不能让基础基础架构硬扛,是可以做到,但你不也操心吗?如果应用系统的架构适合双活,容易实现,或者应用很容易读写分离,基础架构在支撑一下,就更放心更省心。
    2020-03-27

提问者

summit
summit0517
架构管理岗某城商银行
擅长领域: 云计算服务器容器

问题来自

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2020-03-16
  • 关注会员:10 人
  • 问题浏览:11811
  • 最近回答:2020-03-18
  • X社区推广