“浅”谈容灾和双活数据中心（下）

本文接续前文：“浅”谈容灾和双活数据中心（上），上 篇发布之后，瓜哥粉丝量暴涨了好几百，感谢大家关注！

第三部分：双活，看上去很美。

3.1 装逼是要付出代价的

看这标题，想必瓜哥是要开始吐槽双活了。没错。传统灾备模式下，一主一备，灾备端冷启动或者暖启动，这种方式虽然有资源浪费和 RTO 较大等缺点，但是其最大一个优点就是保险。那么说双活不保险喽？瓜哥认为是的。世上没有无代价的交换。双活的不保险，体现在灾备端对生产端是有严重影响的，或者说双活场景下，已经没有主和备的角色分别了，是对称式的，也就是两边会相互影响。这种影响，很有可能导致两边一损俱损，多活应用的多个实例之间耦合较紧，诸如“单节点无法启动 ” 、 “ 无法加入新节点 ” 等类似耦合性问题，时有发生，带来了很大的运维复杂度，尤其是异地多实例的场景下，出现问题，你咋弄？登陆到远端机器调试，甚至需要重装、重启，有时候还不得不在异地放个人配合你，俩人水平不一样沟通或许也有问题，你就得亲自来回跑，这些想想都头疼。这就好像很多单一应用主机做了 HA 双机热备一样，结果发现本来屁事没有的单机环境，自从部署了 HA 之后，反而多了很多屁事。

双活也一样，只会增加运维难度，而不会降低。双活就得预防脑裂，而“预防脑裂”本身就可能会出各种问题，徒增成本不说，远距离链路上会发生什么谁也无法预知，一旦软件做的有问题不够健壮，反而会导致更大问题甚至脑裂，也就是根本没防止脑裂而增加脑裂概率了。还有就是一旦两边、仲裁，都失去联系，那么系统只能停机，而这种情况在传统灾备架构里是不会发生的，从这一点上说，双活的可用性概率反而是下降的，因为链路闪断、故障的几率，比整个数据中心大灾难的几率那是高多了。

传统双活，一主一备，或者至少是互备，容灾端是不会影响源端的。而双活，“备份 ” 的意思更少了一些，这与传统的观念就背离的越来越远了。双活两边各自影响，搞不好一端出问题，另一端跟着遭殃，甚至两边直接全挂掉，比如一旦某个地方不一致，或者经过链路闪断之后出现了状态机混乱，全崩。其实这个已经是有前车之鉴的了。据说某用户使用了某品牌的双活之后，出现脑裂问题，导致停机数小时，高层直接被下课。从这一点上来讲，双活既可以是个略显逼格的奇葩装备，但也有可能成为一个定时炸弹。再一个例子，支付宝光纤被挖断，愣是停业务两小时，至于其到底是否部署了双活甚至多活，谁也不知道，瓜哥也不能妄加揣测，但是至少说明一点，所谓双活，可能并没有你想象中的那么健壮，虽然它看上去很美。

3.2 另一种双活，不中看但或许很适合你

业界有几个厂商也宣称自己支持双活，但机制并不是上述那样。同样 A 和 B 两个站点， A 实例访问本地数据副本， B 实例也访问 A 站点的数据副本，而 A 存储与 B 存储之间保持复制关系，在 B 站点维护一份镜像副本，镜像副本平时不能挂起给业务主机，仅当出了问题之后，比如 A 存储宕机，镜像副本才可以挂起给业务。这些厂商的这种双活方案，各自也都包装了一套名词出来，比如 “Stretched Cluster” ，意即将本来耦合在本地的主备容灾系统拓展到异地，平时备份端的主机也可以访问源端的数据，只不过要跨广域网，数据是集中访问源端副本，不需要考虑一致性问题。出现问题需要切换时，靠主机上的多路径软件将路径切换到备份端，继续业务。

下面这个拓扑是利用虚拟化网关组成的的 Stretch Cluster 结构，两台主机运行双活应用，当 A 主机当掉之后， B 主机可以继续访问 A 站点的 A 存储，路径不变化。该厂商针对这个场景做了一些优化措施：由于 B 主机访问 A 存储是跨广域网访问时延大，此时完全可以切换到 B 站点 B 存储访问，因为 A 存储上对应的卷当前只有 B 主机一人在访问了，不会发生不一致的问题，所以 B 主机上所配备的该厂商的多路径软件此时会检查 A 存储和 B 存储的镜像状态，当发现为完全同步态之后，会将 B 的访问路径切换到 B 存储，这个切换速度较快，对 IO 影响很小，切换之后 B 对 A 反向同步。

可以看到，这种双活体系，其效果接近于对称式双活，远端节点的读 IO 不能在本地完成，这一点赶不上对称式双活（当读 IO 目标地址没有被锁定时可以终结在本地），对于写 IO ，对称式双活也需要写到对端去，两者相差不太大，但是 Stretch Cluster 能避免仲裁 / 脑裂方面的风险。运维难度大大降低。

综上所述，双活与灾备的目标其实是有所背离的，他将 “ 备份 ” 这个最后保障的保险系数拉低了。从业务角度来看，传统企业的业务系统多数是由人 + 机器组成的，传统业务离不开人的接入，人没了，仅有机器，业务也跑步起来。而新兴业务尤其是互联网类业务，或者无人值守业务，人为因素介入较少，都是机器全自动化操作，只要机器活着，业务