所谓双活数据中心的架构
我认为有数据中心级别的双活、应用级别的双活、业务级别的双活之分。
1)数据中心级别的双活,相对容易实现,只要不同的业务跑在不同的数据中心就可以了。
2)应用级别的双活,只要业务能读写分离,同样的业务系统,写操作单中心做,读操作双数据中心做,需要应用系统的高度逻辑隔离。
3)业务级别的双活,就是指同一笔业务既可以在A中心写入,也可以在B中心写入。这种双活就相对困难了。
对于业务级别的双活来讲,他的关键制约条件是什么呢?我们从上到下来看:
网络层面,双数据中心2层打通,GTM+LTM很容易做到分流控制。
应用层面,只要是短连接应用,挂载负载均衡设备上,无论是虚拟化还是实体机,也非常容易做到。
数据层面,要完成三个功能:一是两边都能写入,而是两边都要保留数据的副本,三是两边的数据库节点能快速接管彼此的业务。那就是数据库AA集群+数据复制技术。首先来看AA集群技术,典型的ORACLE RAC,可是有一个致命的问题是关系型数据库的AA集群会有数据热点问题,在双中心之间的链路延时和不稳定情况下,这么做是非常危险的,不出问题是侥幸,出问题是时间的问题。再说数据复制技术,存储层面的复制技术有很多,但是没有一个能解决逻辑校验的,也就是说存储的块数据同步过去了,但是有可能在危急时刻,数据库还是拉不起来。而且还有一个关键问题就是数据库的仲裁和存储的仲裁再加上光纤链路的远距离不可控,危急时刻做出正确的仲裁,很难。不要简单听信仲裁时间的先后以及第三点仲裁中心的说法,那是理论上不是实践。血淋淋的案例摆在面前。再看数据库层面的复制技术,典型的就是ADG,现在做的也是越来越好了,只要日志复制过去,那就不会有数据丢失的危险,但是这个ADG切换就不是1分两分钟能搞定的事情了。
因此我认为,在既有关系型数据库的前提下,双活最稳妥的做法就是:
网络层: 大二层、GTM
应用层:虚拟化 + LTM
数据层:单中心集群数据库 + 数据库复制技术
管理层:开发脚本减少切换浪费掉不必要的时间
赞同!
根据我们的实施的经验补充几点:
1,网络大二层必要性不大,双中心耦合度太高,用DNS搞定。
2,虚拟化不是必须的,但虚拟化对缩短恢复时间有好处。
3,跨中心数据库复制技术,同步模式对主库影响太大,异步模式会有数据丢失,需要补偿措施。
补充网络的大二层是为虚拟化环境中,虚拟机跨数据中心飘移的,在双活数据中心模式确实必要性不大,
另外说到双活无法解决逻辑,建议在保障业务连续性的同时增加CDP,对业务系统的逻辑错误、操作系统、病毒等进行有效的保护
收起1、数据中心级的双活
网络大二层不是必需,可用可不用;
虚拟化可用可不用,如果想实现虚拟服务IP跨中心飘移,这叫主备,根本就不是双活了;
2、应用级多活
略过
3、业务级的双活
现在国内能实现的,可行的,只有2种模式:1、按功能划分,多个中心,每个中心的功能定位及部署运行的系统不同;2、多个中心部署系统相同,但是支撑服务的客户群不同,且此不同客户群之间不会有数据交互。都是非对称的假双活,国内没有真正的对称性业务双活,1个案例也没有。
收起其实在双活搭建的最难点也就是如何保证数据库的双活。数据库的双活不是为了提高系统利用率,而是在于灾难发生的时候,应用能更快的恢复响应。在数据层,单中心集群加数据复制就不太满足发生灾难时快速恢复的要求。这也是为什么要做数据库双活。数据库双活不可避免会有很多的热点数据,这在RAC和DB2 GDPC集群里面都是常见的问题。这些问题也是有调优办法的,主要的思路是分散热点数据。解决了性能问题后,双活环境才算真正达到效果。
同城双活,网络层面可以大二层。异地的双活,大二层代价较高,可使用全局负载均衡+DNS进行流量导引。数据层面使用数据库自身的高可用解决方案,比如ADG、Oracle Extended RAC,这些比存储阵列的双活效果要好。
光纤抖动确实会影响数据库的交易。主要是存储复制的IO请求如果正好在这个光钎上,可能会丢失,只能等到超时。这个影响比较大。现在在光钎交换机上配置了一些策略来抵抗抖动,同时还有DCP保护。
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的部分,就是需要应用和网络配合
收起热点数据的问题会随距离增加时延加大而导致性能无法接受,这也是ORACLE官方不推荐使用extended RAC的原因。通过应用改造使数据分区分片是一个不得已的折中方案。