经常看到和听到的架构是这样的。理论上生产数据复制到异地的备份也会对数据有保障,但是架构越复杂,维护,操作起来也越复杂,往往这样的架构最后出问题的并不是数据复制链路本身。而是在生产系统故障的时候业务割接时候的其他问题,
举个简单的例子,刚刚做双机结构的时候。是微软win2000+sql2000的架构,做的过程是装好两台系统,配置双机结构,然后在主机上安装SQL,这样备机也同时安装上了sql2000,当主机挂掉,备机会自动接替主机工作,到这里位置一切都很理想,但是很快我们就放弃了这种结构,因为
1,当主机故障,备机切换了以后。我无法在线把主机在添加到这个双机结构中,只能把整套双机环境全全部推了重来,
2,两台机器不能同时启动,否则会因为争抢资源而导致双机结构崩溃,
现在的技术发展的自然比起零几年的时候要先进了许多,但同样会因为某些条件至于而导致这种理想的架构真的在出现故障的时候能理想的实现智能接管。所以双活也好。两地三中心也好。有成熟的容灾方案,做定期的容灾演练是保证系统架构运行的根本。,如同拿着倚天剑的人一定要是个武林高手。否则可能伤到的会是自己。
收起这个问题很奇特,当然是由用的,没有建它做什么,关键看你为什么要建,目的是什么,建灾备的需求,响应级别。
如果说你是认为,本地双活完全能满足生产环境的高可用需求,那就要看是否能满足用户的业务和管理需求,有不少企业做灾备不是为了别的就是为了审计或等保的需要。
你有没有听说过某个IDC机房因失火,造成对外业务全部中断的情况,虽然可能,但基本没有发生过。那做了数据同步建了灾备机房是否就安全了,如果恰巧2个机房相聚数十公里却在同一个地震带上时会发生什么...............
这也就是开始说的,为啥要建灾备,目的、需求、预算要先搞清楚,才能设计建设有效的灾备环境。
收起在灾备系统上见过这样的系统,但是业务生产上没有见过有客户这么花气力。
灾备系统是A--B---C,但C不复制到A,是一个不闭合的三角模型。即使是一个灾备三中心,也是相当花钱的。备份存储都是EMC DataDomain的高端产品,都是窄带复制传输,运行也没有问题。恢复验证也测试过,安全性确实有提高,但是三中心数据一致的滞后性还是很明显,基本都在3H左右,数据量大的时候滞后更多。可想而知,如果是业务上三中心互备,算上SAN网络、设备、存储,估计不是特大公司都不会采用了吧。
收起