做容灾,冷备是不是个好方案?

阅读数:1 2020 年 3 月 17 日 22:07

做容灾,冷备是不是个好方案?

主备、冷备、热备、双活、多活、同城、异地、多云,等等等等,这些保证业务高可用和容灾名词,我们经常会听到,不绝于耳。

但是,真的当我们自己要去建设,选择方案时,就发现不知道该怎么选择和搭配了。

结合近期我们的一些讨论,准备用几篇文章简单分享下我们的理解,今天先聊冷备。

冷备是不是个好方案?

这里的冷备我们可以理解为,是主站系统核心链路的镜像站点,应用、各类分布式服务以及底层基础设施都是独立,且启动的。

它跟主站唯一的差别就是,正常情况下,不承载任何线上流量。

理论上,只要有状态的数据(也就是各类分布式服务,如数据库、缓存、消息等组件)同步好,接入层流量能够灵活调度,当出现问题的时候,切入口流量,就可以顺畅的切过去。

看上去很美好,但是实际操作起来,基本不可行。

这里有一个关键点,就是业务应用,应用的代码和配置是随时在变化的。

原则上,我们可以通过持续交付和运维自动化等等手段,确保每次变更都能够同步到备站点,并通过流程约束不允许有外部操作。

所以,手段上,我们可以做到非常完备,流程上,我们可以设计的非常严密。

但是,我们始终绕不开的一个命题,只要不承载真实的线上业务流量,我们就无法证明这个系统是可用的。

何况,有可能是好几个月我们都不会发生真实的切换动作,所以,一个几个月没有经过线上流量检验的系统,在真正需要切换时,不会有任何人敢决策直接切换的。

当然,以上是我们的直接推断,确实行不通。但是我们仍然要经过一些详细的论证,从其它角度看是否有解。

从另外一个角度的论证过程

当时我们讨论在冷备的前提下,应该怎么保证系统的可用性,没想到,论证的过程,反而进一步证实了冷备只是一个美好的愿望。

1、通过模拟压测的方式。

但是我们知道,压测的模型是根据线上业务模型来定制的,但是业务场景和逻辑每天都在发生变化,压测模型的同步有时是跟不上业务模型变化的。

况且这个日常工作量要靠人,无法做到自动生成,所以基本不可持续。

再就是,压测的结果检验是通过技术指标衡量,而非业务指标,也就是是否 200ok,或者出现 5xx 之类的错误。

业务逻辑上是否正确,并没有办法确保。这种情况就极易造成数据污染。数据故障的影响范围远远超过服务不可用的影响。

所以,压测可以最大程度评估系统容量,但是无法保证系统业务正确性。

2、切换后,接入线上流量前,QA 介入验证。

理由同上,工作量大,也无法覆盖到所有场景,时间不可控,完全起不到冷备节点的快速承载业务效果。

3、定期模拟演练,确保系统周期范围内可用

但是这里就有一个前提,冷备站点的建设目标,并不是全量建设,而是在极端状况下,确保核心业务临时可用,当主站点恢复后,仍然要切回去。

这里暗含的一个意思就是,一旦需要做这个动作,业务必然有损,而且涉及范围非常大,这就意味着,每一次演练都要付出极大的业务代价。

从这个角度,产品运营及决策者们是不会允许你经常干这种事情的。

到这里,你会发现,连日常演练的条件都不具备了。

4、一个绕不开的限制条件

数据同步必然是单向的,为了保证数据一致,通常要确保备用站点是禁写的,以防止各类误操作引起的数据污染。

所以,即使上面几个方案可行,基础条件上又不满足,因为根本无法写入数据,关键的业务逻辑根本不具备验证条件。

最后,结论

冷备只能是冷备,关键时刻并不能起到快速承载业务的效果,在业务容灾建设时,这个思路其实是不可行的。

但是对于部分组件,比如数据库、大数据、文件,这些存储类的部件,做冷备是有重大意义的。

也就是,后面我们在提到冷备时,应该叫做数据冷备、文件冷备、源代码冷备才有意义,或许会更准确些。

本文转载自成哥的世界公众号。

原文链接: https://mp.weixin.qq.com/s/aORRbfURAE4LUP97CY4bjA

评论

发布