要“癫痫”，还是要“脑裂”？——“IT生存法则”之双活数据中心

“老王，你们医院的双活数据中心方案定了吗？”

“还没呢，已经听好几个厂家介绍方案了，有点晕，不知选哪个好，你有什么建议？”

“也谈不上什么建议，就是提醒你下，上双活方案，一定要防范好‘脑裂’的风险！”

“‘脑裂’？那不是治‘癫痫’病的后遗症吗？‘双活’也会有后遗症？”

“可不是，前一段某金融部门还专门发文提醒上‘双活’后的‘脑裂’问题呢！”

“是吗？那我们得好好评估一下，最终方案一定要考虑这方面的风险！”

是啊，是要搞搞清清楚下面这几个问题，再做抉择：

第一个问题是：为什么要上“双活”？

随着信息技术越来越成为驱动业务拓展的动力，对IT应用系统的连续性提出更高的要求，君不见SLA（服务水平协议）都在比小数点后有几个9吗？恨不得直接写100%呢。可做为基础架构的IT系统，终归是机器设备，总会在生命周期中出现各类故障，对于网络设备可以通过双机冗余模式解决，对于应用服务器可以通过负载均衡方案解决，但对于数据库服务器及其存储设备，则一直采用传统的冷备模式，既当主设备出故障时，冷启动备机应急，显然这种解决方案，其故障恢复时间无法降到秒级，最好的也在分钟级，当需要保证7×24不间断提供服务时，这里就成为了瓶颈。

正是在这种局面下，诸多存储设备厂商，借鉴数据库厂商的HA（高可用性）解决方案，提出并开发了“双活”模式，理想的“双活”解决方案，由于双机互为主、备，并实时同步数据，因此只需毫秒级的延迟，即可在一方出故障时，接管对数据的存取，保证业务的连续性。

第二个问题是：“双活”有什么利弊？

正所谓成也萧何，败也萧何。由于IT系统的复杂性，环境、线路、设备、系统，甚至是线缆都可能是故障源，采取“双活”后，如何破解数据的“CAP”难题就成为该模式能否有效的关键！也就是说数据的一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance）三者只能同时选择实现二个，其中，一致性追求RPO为零，可用性追求RTO为零，分区容忍性追求多存储复本且在不同存储载体上，截止目前，由于相关理论尚且没有被证伪，要找到三者兼顾的解决方案还不现实。

“双活”的目的，本来是解决可用性（注：随时可用）的问题的，顺便实现分区容忍性，这就带来了数据的一致性无法保证的问题，既所谓的“脑裂”问题，如果发生的话，将造成数据的不可用，进而影响业务的连续性，虽然其发生概率较小，但一旦发生则是致命的。

这也是为什么大家上“双活”模式时，非常慎重的原因！

第三个问题是：如何应对“脑裂”风险？

“脑裂”有风险，“双活”又要上，既然没有完美的技术，那就选择能根据场景变换组合的解决方案。比如上述三者的分类组合，如CP、CA、AP等组合都能实现的方案。

这就需要进行场景变换实测，看该解决方案是否支持“同步复制”和“异步复制”，是否支持同步成功以“同步命令发出”或“同步结果完成”为信号的双模式。

还有，是否有“仲裁服务器”和“多路径软件”用来对“脑裂”现象强行干预。

最为重要是，是否有手工模式，以便在“仲裁”失效或“各方”失联的情况下，通过传统的手工模式（注：类似冷备模式）恢复服务。

——IT语录：鱼与熊掌不可兼得，舍鱼而取熊掌者也！

“老婆，问一个严肃的个人问题？”

“什么严肃问题？不会是你犯严重错误了吧？”

“别瞎猜！是这样，假如你得了‘癫痫’，如果做手术，可以治好，但却有后遗症！你是做呢？还是不做?”

“那要看是什么后遗症了！”

“比如‘脑裂’？就是脑子中总有两小人打驾，一个往左，一个往右，不知听哪个的好。”

“那不成精神分裂了吗？”

“到没那么严重，慢慢适应，最终选一个小人的指令就行了？”

“这还行，如果用‘精神分裂’换‘癫痫’，那还不如不换呢！”

……

想想也是，任何方案都不是十全十美的，要有利的一面，一定会带来不利的一面，关键是最在乎什么？以及如何取舍？只要控制住风险，并将不利影响减少到最小，就是可以接受的，要不怎么会有那么多的人愿意做治‘癫痫’的手术呢？

明天就要上会讨论确定是否上“双活”方案了，经与老婆调侃几句，王主任心静了许多，似乎有些小小释然。

下期预告：他们为什么要“磨洋工”？