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

所谓双活数据中心的架构我认为有数据中心级别的双活、应用级别的双活、业务级别的双活之分。1)数据中心级别的双活,相对容易实现,只要不同的业务跑在不同的数据中心就可以了。2)应用级别的双活,只要业务能读写分离,同样的业务系统,写操作单中心做,读操作双数据中心做,需要应用系统...显示全部

所谓双活数据中心的架构

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

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

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

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

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

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

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

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

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

网络层: 大二层、GTM

应用层:虚拟化 + LTM

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

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

收起
参与103

查看其它 10 个回答行成的回答

行成行成  it技术咨询顾问 , 厂商

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
浏览3870

回答者

行成
it技术咨询顾问厂商
擅长领域: 灾备备份存储

行成 最近回答过的问题

回答状态

  • 发布时间:2018-09-15
  • 关注会员:25 人
  • 回答浏览:3870
  • X社区推广