容灾系列(一)—— 云上业务容灾方案要如何选?
说起容灾,很多同学脑子冒出来熟悉字眼,”同城双活”,“两地三中心”,“单元化”,“set化”等等。其实这些名词背后均隐射一层含义,面对一些灾难时候,业务如何做冗余来快速恢复业务。
本文从容灾概念,决策因素,典型案例和方案对比进行说明,希望容灾方案的选择有所帮助。
1.容灾概念
将容灾这个词,分开来看“容”和“灾”。“灾“可大可小,某种意义上来讲就是"单点"问题,例如核心业务部署单台服务器上,这台服务器宕机起不来了,对业务来讲就是一场灾难;而“容”,是解决各种"单点"问题。以资源部署粒度来看,一直在解决单点问题路上,如下图:
3.2.2 同城双活(双写)
同城双活核心特征:
1)容灾范围:可用区粒度容灾
2)流量分布:每个可用区均承载流量业务;数据库采用分区模式,将数据分为两个可用区,az间的网络延时对业务影响较小
3)数据存储:数据库和存储跨az部署,其中数据库双向同步,读写均在各自可用区;存储cos本身具备多az容灾
4)常见场景:数据一致性强依赖于业务,同时业务不能接受跨az延时;相比单写方案,对业务改造较大,相当于单元化和set的业务改造级别。
以下是云上某saas厂家同城双活案例:
云上的存储业务均采用虚拟机或者黑石机器进行自建,业务以账户单双号进行set化部署;A区的数据库存双号,B区的数据库存双号;数据库同步使用双向方式;每个AZ数据库均存在全量数据;当一个可用区故障,业务通过DNS以及业务调用配置下发能力,将业务切换到另外一个可用区,同时取消同步能力。
3.3 异地多活
异地多活核心特征:
1)容灾范围:地域粒度容灾
2)流量分布:每个地域均承载流量业务;数据库读写均在同一个地域
3)数据存储:每个地域均存储本地数据和全局数据
4)常见场景:业务已经完成set改造,每个地域为独立一个或者多个set,全局数据进行地域之间复制同步。
以下为某生活巨头异地多活的场景:
业务流量统一调度,通过路由层进行set路由,将流量分发到各个set;各个set业务流量相互独立;数据容灾各个set之间两两互备,同时set和中心互备形成三副本。某个set故障后,流量入口切换set路由保障服务。
4.方案对比
关于以上四种容灾方案,分别从成本,可用性以及可扩展性做横向对比总结。
容灾方案 |
成本 |
可用性 |
可扩展性 |
---|---|---|---|
异地灾备 |
优势: 待提升: |
优势: 待提升: |
适用于数据安全层容灾,方案对业务扩展性依赖较弱 |
双活单写 |
优势: |
优势: 待提升: |
演进同城多活以及全局高可用 |
双活双写 |
待提升: |
待提升: |
更好向异地多活演进 |
异地多活 |
结合自身业务评估,对业务改造量通常来讲,set话改造都是公司多部门合作的超级大项目 |
良好的调度能力和地域粒度容灾能力 |
\\ |