快盘下载:好资源、好软件、快快下载吧!

快盘排行|快盘最新

当前位置:首页软件教程电脑软件教程 → 容灾系列(一)—— 云上业务容灾方案要如何选?

容灾系列(一)—— 云上业务容灾方案要如何选?

时间:2022-09-17 08:06:21人气:作者:快盘下载我要评论

说起容灾,很多同学脑子冒出来熟悉字眼,”同城双活”,“两地三中心”,“单元化”,“set化”等等。其实这些名词背后均隐射一层含义,面对一些灾难时候,业务如何做冗余来快速恢复业务。

本文从容灾概念,决策因素,典型案例和方案对比进行说明,希望容灾方案的选择有所帮助。

1.容灾概念

将容灾这个词,分开来看“容”和“灾”。“灾“可大可小,某种意义上来讲就是"单点"问题,例如核心业务部署单台服务器上,这台服务器宕机起不来了,对业务来讲就是一场灾难;而“容”,是解决各种"单点"问题。以资源部署粒度来看,一直在解决单点问题路上,如下图:

容灾系列(一)—— 云上业务容灾方案要如何选?

资源不同维度单点

业务容灾方案有很多种,但是万变不离其宗,本质上都是通过“冗余”来解决"单点"问题;从而不同维度的单点问题,方案决策因素和成本差异会非常大。

2.决策因素

首先,要思考以下两个问题:

1)为什么要做容灾?

梳理当前系统“灾”,主要有哪些痛点,并对其优先级排序。例如单点隐患,难扩展性,运维成本高等等现状,结合现状进行排序,对后续方案选择至关重要。

2)容灾要做到什么程度能满足当前要求?

设计当前系统“容”,对当前系统潜在灾难逃生通道进行冗余设计,当灾难真正发生,预计多长时间能恢复,或者业务稳定性SLA,如SLA=99.999%。

其次,基于容灾范围和目标,在设计容灾方案重点从以下三方面来考虑评估。

1)成本,包括人力,时间以及资金。对于成本和恢复耗时成反比,业务恢复时间越少,成本也会越高;可以参考标准SHARE78模型。

开销和恢复时间对应关系

2)可用性,首先考虑引入方案对现有系统增加哪些不确定因素,评估这些不确定对稳定性影响。举个例子,某客户使用腾讯tdsql产品,当前是是单可用区部署,主从数据同步使用强同步;客户计划实现同地域不同AZ粒度容灾。这样一个变化会引入不确定因素,例如AZ之间网络延时和稳定性,如果AZ间网络时常抖动,等待从节点返回ack有延时,线上业务时常被hang。其次考虑当前方案能否满足容灾切换和恢复目标。

3)扩展性,主要为后续业务容灾平滑演进。从某种意义来讲,无论是自建idc还是云厂家在建设数据中心时候都不能无限大,在物理机房限制条件下,如果业务发展足够好,就会存在资源不够,扩展受物理设施限制。因此在容灾方案选择的时候,要有前瞻性,对于set化进行提前布局。

3. 典型案例

虽然这里对“容灾”概念进行扩展,一般指同地域以及跨地域粒度的容灾;以云上客户案例同时结合腾讯云产品能力,分别对同城容灾,异地灾备以及异地多活进行说明。

3.1 异地容灾

异地容灾的核心特征:

1)容灾范围:地域粒度的容灾。

2)流量分布:单地域承载100%业务流量。

3)数据存储:数据库以及存储均在异地做冷备,数据单向同步。

4)常见使用场景:主要在数据层安全级别容灾,业务层较少异地部署。跨地域数据同步耗时较长,国内大约30-60ms之间,一般线上业务很忍受。备用区没有承载业务或者只有数据层冷份,恢复时间保证强依赖业务快速扩容,调度以及版本一致性等能力支撑。

以下是云上某个金融公司异地容灾架构:

1)接入层和业务层均使用低配以及业务单台服务器部署方式,主要提升业务快速扩容能力,一方面主可用区异常,借助腾讯弹性伸缩AS能快速扩容,另一方面业务发布版本在不同地域保持一致。

2)该数据层使用云上PAAS产品,云上产品均支持异地容灾能力,同时操作便捷。如CDB和COS均通过云上控制台按钮式方式建设异地容灾能力;而对于es通过ccr方式进行数据复制。

系统架构

异地容灾

3.2 同城容灾

同城容灾根据数据写入方式分为单写或者双写;单写称为半双活,双写称为双活。

3.2.1 同城半双活(单写)

同城半双活核心特征:

1)容灾范围:可用区粒度容灾。

2)流量分布:每个可用区均承载业务流量;数据层存在跨区写场景,根据业务敏感程度,流量按照适中比例调度到两个可用区,但是必须要两个可用区均承载业务,这里可用性和性能要进行取舍。

3)数据存储:数据库az部署,其中数据库单向同步,单可用区写多可用区读。

4)常见场景:业务对数据一致性要求较高,同时能接受跨可用区延时,网络延时大约2-3ms,对业务改动较小场景。

以下是某云上智慧零售企业同城半双活架构:

1)接入层和服务层均两个两个可用区1:1数量同规格部署,通过业务域名解析来承载业务

2)中间件和数据层均使用云上跨az产品能力,如果存量是实例为单可用区,在控制台升级为多可用区;期间对业务没有影响,例如cdb,redis产品。对于es,ckafka,TDMQ有天然的跨az容灾能力,如果当前产品不支持存量升级,产品均有成熟方案,迁移成本较低。

架构设计

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.方案对比

关于以上四种容灾方案,分别从成本,可用性以及可扩展性做横向对比总结。

容灾方案

成本

可用性

可扩展性

异地灾备

优势: 业务改造较少 待提升: 1.增加跨地域间流量费用 2.增加周期性切换演习 3.资源闲置

优势: 具有地域容灾能力 待提升: 业务切换,决策成本较高,业务恢复能力较弱

适用于数据安全层容灾,方案对业务扩展性依赖较弱

双活单写

优势: 1.通过平台能力跨可用区属性,建设容灾技术部署人力成本 2.业务改造相对较少

优势: 1.核心组件单可用区集群高可用,同时具备跨可用区容灾能力 2.故障秒级、自动切换能力 3.数据一致性好 待提升: 同地域可用区粒度容灾能力

演进同城多活以及全局高可用

双活双写

待提升: 1.增加业务单元化改造 2.增加整体建设周期相对较长 3.增加故障期间切换能力开发成本 4.redis双写需要业务层支持

待提升: 1.可能存在数据冲突问题 2.业务实现较为复杂,会增加潜在风险

更好向异地多活演进

异地多活

结合自身业务评估,对业务改造量通常来讲,set话改造都是公司多部门合作的超级大项目

良好的调度能力和地域粒度容灾能力

相关文章

网友评论

快盘下载暂未开通留言功能。

关于我们| 广告联络| 联系我们| 网站帮助| 免责声明| 软件发布

Copyright 2019-2029 【快快下载吧】 版权所有 快快下载吧 | 豫ICP备10006759号公安备案:41010502004165

声明: 快快下载吧上的所有软件和资料来源于互联网,仅供学习和研究使用,请测试后自行销毁,如有侵犯你版权的,请来信指出,本站将立即改正。