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