我认为应该这样去设计双活架构,你觉得呢?

所谓双活数据中心的架构

我认为有数据中心级别的双活、应用级别的双活、业务级别的双活之分。

1)数据中心级别的双活,相对容易实现,只要不同的业务跑在不同的数据中心就可以了。

2)应用级别的双活,只要业务能读写分离,同样的业务系统,写操作单中心做,读操作双数据中心做,需要应用系统的高度逻辑隔离。

3)业务级别的双活,就是指同一笔业务既可以在A中心写入,也可以在B中心写入。这种双活就相对困难了。

对于业务级别的双活来讲,他的关键制约条件是什么呢?我们从上到下来看:

网络层面,双数据中心2层打通,GTM+LTM很容易做到分流控制。

应用层面,只要是短连接应用,挂载负载均衡设备上,无论是虚拟化还是实体机,也非常容易做到。

数据层面,要完成三个功能:一是两边都能写入,而是两边都要保留数据的副本,三是两边的数据库节点能快速接管彼此的业务。那就是数据库AA集群+数据复制技术。首先来看AA集群技术,典型的ORACLE RAC,可是有一个致命的问题是关系型数据库的AA集群会有数据热点问题,在双中心之间的链路延时和不稳定情况下,这么做是非常危险的,不出问题是侥幸,出问题是时间的问题。再说数据复制技术,存储层面的复制技术有很多,但是没有一个能解决逻辑校验的,也就是说存储的块数据同步过去了,但是有可能在危急时刻,数据库还是拉不起来。而且还有一个关键问题就是数据库的仲裁和存储的仲裁再加上光纤链路的远距离不可控,危急时刻做出正确的仲裁,很难。不要简单听信仲裁时间的先后以及第三点仲裁中心的说法,那是理论上不是实践。血淋淋的案例摆在面前。再看数据库层面的复制技术,典型的就是ADG,现在做的也是越来越好了,只要日志复制过去,那就不会有数据丢失的危险,但是这个ADG切换就不是1分两分钟能搞定的事情了。

因此我认为,在既有关系型数据库的前提下,双活最稳妥的做法就是:

网络层: 大二层、GTM

应用层:虚拟化 + LTM

数据层:单中心集群数据库 + 数据库复制技术

管理层:开发脚本减少切换浪费掉不必要的时间

参与103

11同行回答

wangj0923wangj0923  技术经理 , 工行
赞同!根据我们的实施的经验补充几点:1,网络大二层必要性不大,双中心耦合度太高,用DNS搞定。2,虚拟化不是必须的,但虚拟化对缩短恢复时间有好处。3,跨中心数据库复制技术,同步模式对主库影响太大,异步模式会有数据丢失,需要补偿措施。...显示全部

赞同!

根据我们的实施的经验补充几点:

1,网络大二层必要性不大,双中心耦合度太高,用DNS搞定。

2,虚拟化不是必须的,但虚拟化对缩短恢复时间有好处。

3,跨中心数据库复制技术,同步模式对主库影响太大,异步模式会有数据丢失,需要补偿措施。

收起
银行 · 2016-01-08
浏览5449
  • 你指的APP访问DB用DNS访问的方式? 这个的确可以实现双活自动切换,但是依赖DNS老化和刷新时间,这个DNS老化和刷新时间的设计还要配合ADG同城或异地拉起的时间。 你们实践经验,大概多长比较合适?
    2018-09-15
sxtycxxsxtycxx  解决方案经理 , 人工智能(计算机视觉)
    补充网络的大二层是为虚拟化环境中,虚拟机跨数据中心飘移的,在双活数据中心模式确实必要性不大,   另外说到双活无法解决逻辑,建议在保障业务连续性的同时增加CDP,对业务系统的逻辑错误、操作系统、病毒等进行有效的保护...显示全部

    补充网络的大二层是为虚拟化环境中,虚拟机跨数据中心飘移的,在双活数据中心模式确实必要性不大,

   另外说到双活无法解决逻辑,建议在保障业务连续性的同时增加CDP,对业务系统的逻辑错误、操作系统、病毒等进行有效的保护

收起
互联网服务 · 2016-01-08
浏览4334
prada_guprada_gu  其它 , xxx
1、数据中心级的双活网络大二层不是必需,可用可不用;虚拟化可用可不用,如果想实现虚拟服务IP跨中心飘移,这叫主备,根本就不是双活了;2、应用级多活略过3、业务级的双活现在国内能实现的,可行的,只有2种模式:1、按功能划分,多个中心,每个中心的功能定位及部署运行的系统不同;2、多个中...显示全部

1、数据中心级的双活

网络大二层不是必需,可用可不用;

虚拟化可用可不用,如果想实现虚拟服务IP跨中心飘移,这叫主备,根本就不是双活了;

2、应用级多活

略过

3、业务级的双活

现在国内能实现的,可行的,只有2种模式:1、按功能划分,多个中心,每个中心的功能定位及部署运行的系统不同;2、多个中心部署系统相同,但是支撑服务的客户群不同,且此不同客户群之间不会有数据交互。都是非对称的假双活,国内没有真正的对称性业务双活,1个案例也没有。

收起
IT其它 · 2016-01-12
浏览4316
anikikonganikikong  数据库运维工程师 , 中国民生银行
其实在双活搭建的最难点也就是如何保证数据库的双活。数据库的双活不是为了提高系统利用率,而是在于灾难发生的时候,应用能更快的恢复响应。在数据层,单中心集群加数据复制就不太满足发生灾难时快速恢复的要求。这也是为什么要做数据库双活。数据库双活不可避免会有很多的热...显示全部

其实在双活搭建的最难点也就是如何保证数据库的双活。数据库的双活不是为了提高系统利用率,而是在于灾难发生的时候,应用能更快的恢复响应。在数据层,单中心集群加数据复制就不太满足发生灾难时快速恢复的要求。这也是为什么要做数据库双活。数据库双活不可避免会有很多的热点数据,这在RAC和DB2 GDPC集群里面都是常见的问题。这些问题也是有调优办法的,主要的思路是分散热点数据。解决了性能问题后,双活环境才算真正达到效果。

收起
银行 · 2016-01-08
浏览4469
  • 没错。ORACLE数据库也是有分区技术的。但是这就需要应用做大的调整了,数据库模型得重新设计。而且应用系统能否改造还得看它的业务特点。 而且这仅仅是一个缓解问题的手段,不是科学合理的解决方案,我认为。您觉得呢。
    2016-01-08
  • 我在DB2集群环境的调优都仅仅从数据库出发,尽量减少对应用的依赖。Oracle需要通过应用来分,所以比较麻烦。而DB2我仅从数据库内部做了数据的分区,对应用透明。传统非双活方案在灾难恢复上很难再提高时间了。暂时也没发现有新的解决方案,都绕不过去。
    2016-01-12
xjsunjiexjsunjie  系统架构师 , CNPC
同城双活,网络层面可以大二层。异地的双活,大二层代价较高,可使用全局负载均衡+DNS进行流量导引。数据层面使用数据库自身的高可用解决方案,比如ADG、Oracle Extended RAC,这些比存储阵列的双活效果要好。...显示全部

同城双活,网络层面可以大二层。异地的双活,大二层代价较高,可使用全局负载均衡+DNS进行流量导引。数据层面使用数据库自身的高可用解决方案,比如ADG、Oracle Extended RAC,这些比存储阵列的双活效果要好。

收起
互联网服务 · 2016-01-08
浏览4404
  • 如果异地也想实现双活,那就真的是为了双活而双活了。
    2016-01-08
anikikonganikikong  数据库运维工程师 , 中国民生银行
光纤抖动确实会影响数据库的交易。主要是存储复制的IO请求如果正好在这个光钎上,可能会丢失,只能等到超时。这个影响比较大。现在在光钎交换机上配置了一些策略来抵抗抖动,同时还有DCP保护。...显示全部

光纤抖动确实会影响数据库的交易。主要是存储复制的IO请求如果正好在这个光钎上,可能会丢失,只能等到超时。这个影响比较大。现在在光钎交换机上配置了一些策略来抵抗抖动,同时还有DCP保护。

收起
银行 · 2016-01-08
浏览4261
行成行成  it技术咨询顾问 , 厂商
1.网络大二层不建议,没有必要而且故障点也较多;2.存储复制和数据库复制按需使用,个人更建议ADG的方式,存储复制对存储产品有特殊要求,ADG可以实现N:1和配置上的变化,更为灵活;3.数据库层单中心集群(RAC)或HA(mysql),数据库复制到同城(同步)和异地(异步)4.应用系统DNS调用,读写分离,便于...显示全部

1.网络大二层不建议,没有必要而且故障点也较多;
2.存储复制和数据库复制按需使用,个人更建议ADG的方式,存储复制对存储产品有特殊要求,ADG可以实现N:1和配置上的变化,更为灵活;
3.数据库层单中心集群(RAC)或HA(mysql),数据库复制到同城(同步)和异地(异步)
4.应用系统DNS调用,读写分离,便于灾备切换
5.对RAC采用全闪,对mysql建议使用本地服务器内全SSD+pasemaker+corosync
6.虚拟化的同步对缩短恢复时间帮助很大,如vmware SRM或zerto的方案都非常成熟,基于存储和基于网络的复制都能基本保证容灾需求
7.非结构化数据,使用传统的存储同步方案,或者使用SDS对象存储,其天生的三副本或纠删码分布式部署,保证数据多中心可用

关于应用系统之间调用使用DNS的部分,就是需要应用和网络配合

收起
IT咨询服务 · 2018-09-15
浏览3871
wangj0923wangj0923  技术经理 , 工行
热点数据的问题会随距离增加时延加大而导致性能无法接受,这也是ORACLE官方不推荐使用extended RAC的原因。通过应用改造使数据分区分片是一个不得已的折中方案。显示全部

热点数据的问题会随距离增加时延加大而导致性能无法接受,这也是ORACLE官方不推荐使用extended RAC的原因。通过应用改造使数据分区分片是一个不得已的折中方案。

收起
银行 · 2016-01-08
浏览4274
  • 一个是延时导致性能问题,再有一个如果光线不稳定发生抖动,那不仅仅是性能问题。如果光纤链路的切换参数和数据库仲裁参数设置的有冲突,再加上存储的仲裁,问题就大了。
    2016-01-08
thirsdthirsd  技术经理 , xxx
对于双活,从应用层面来说,相对而言,一般采用数据库同步、文件同步、应用dns负载同步实现,再继续redis会话同步,可以做到一定程度得双活。而对于核心系统,例如交易系统,由应用实现切换方案...显示全部

对于双活,从应用层面来说,相对而言,一般采用数据库同步、文件同步、应用dns负载同步实现,再继续redis会话同步,可以做到一定程度得双活。

而对于核心系统,例如交易系统,由应用实现切换方案

收起
金融其它 · 2021-12-27
浏览1263
good_Knightgood_Knight  其它 , xFucntion
很赞,数据库层:本地rac集群+ADG只读+备份主站点alwayson+备站点只读无仲裁+备份高可用+备份+容灾应用层:分布式应用显示全部

很赞,
数据库层:本地rac集群+ADG只读+备份
主站点alwayson+备站点只读无仲裁+备份
高可用+备份+容灾

应用层:分布式应用

收起
软件开发 · 2018-09-15
浏览3207

提问者

haizdl
haizdl101634
技术经理大连
擅长领域: 灾备存储服务器

问题来自

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2016-01-08
  • 关注会员:25 人
  • 问题浏览:18546
  • 最近回答:2021-12-27
  • X社区推广