企业容灾方案简述
文章目录
-
- 一、容灾基本名词解释
- 二、为什么企业需要做容灾方案
- 三、企业该怎么选择容灾方案
- 四、典型案例
-
- 1 、异地容灾
- 2 、同城容灾
-
- （1）、同城半双活（单写）
- （2）、同城双活（双写）
- 3、异地多活
- 4、容灾方案对比
一、容灾基本名词解释
- 容灾
“容”，容忍，恢复，“灾”，故障； - 冷备
与本地IDC数据完全同步，不与本地IDC共同承载业务流量的数据中心 - 热备
与本地IDC数据完全同步，且与本地IDC共同承载业务流量的数据中心 - 双活
本地IDC与一个备份IDC同时承载业务流量 - 多活
本地IDC与多个备份IDC同时承载业务流量 - 同城双活
本地IDC与备份IDC在同一地理位置，且共同承载业务流量 - 异地双活
本地IDC与备份IDC不在同一地理位置，且共同承载业务流量 - 两地三中心
两地三中心=同城双活+异地备份
同城双活的基础上再添加一个异地IDC
二、为什么企业需要做容灾方案
容灾的目的：面对灾难时，业务如何做冗余来快速恢复业务。
“灾“可大可小，某种意义上来讲就是"单点"问题，例如核心业务部署单台服务器上，这台服务器宕机起不来了，对业务来讲就是一场灾难；
而“容”，是解决各种"单点"问题。以资源部署粒度来看，企业一直在解决单点问题路上。
业务容灾方案有很多种，但是万变不离其宗，本质上都是通过“冗余”来解决"单点"问题；从而不同维度的单点问题，方案决策因素和成本差异会非常大。
三、企业该怎么选择容灾方案
决策因素
首先，要思考以下两个问题：
1. 为什么要做容灾？
梳理当前系统“灾”，主要有哪些痛点，并对其优先级排序。例如单点隐患，难扩展性，运维成本高等等现状，结合现状进行排序，对后续方案选择至关重要。
2. 容灾要做到什么程度能满足当前要求？
设计当前系统“容”，对当前系统潜在灾难逃生通道进行冗余设计，当灾难真正发生，预计多长时间能恢复，或者业务稳定性SLA，如SLA=99.999%（业界所说的5个9）。
其次，基于容灾范围和目标，在设计容灾方案重点从以下三方面来考虑评估。
- 成本
包括人力，时间以及资金。对于成本和恢复耗时成反比，业务恢复时间越少，成本也会越高
- 可用性
首先考虑引入方案对现有系统增加哪些不确定因素，评估这些不确定对稳定性影响。
举个例子，某客户使用腾讯tdsql产品，当前是是单可用区部署，主从数据同步使用强同步；客户计划实现同地域不同AZ粒度容灾。这样一个变化会引入不确定因素，例如AZ之间网络延时和稳定性，如果AZ间网络时常抖动，等待从节点返回ack有延时，线上业务时常被hang。
其次考虑当前方案能否满足容灾切换和恢复目标。
- 扩展性
主要为后续业务容灾平滑演进。从某种意义来讲，无论是自建idc还是云厂家在建设数据中心时候都不能无限大，在物理机房限制条件下，如果业务发展足够好，就会存在资源不够，扩展受物理设施限制。因此在容灾方案选择的时候，要有前瞻性，对于set化进行提前布局。
四、典型案例
虽然这里对“容灾”概念进行扩展，一般指同地域以及跨地域粒度的容灾；以云上客户案例同时结合腾讯云产品能力，分别对同城容灾，异地灾备以及异地多活进行说明。
1 、异地容灾
异地容灾的核心特征：
1）容灾范围：地域粒度的容灾。
2）流量分布：单地域承载100%业务流量。
3）数据存储：数据库以及存储均在异地做冷备，数据单向同步。
4）常见使用场景：主要在数据层安全级别容灾，业务层较少异地部署。跨地域数据同步耗时较长，国内大约30-60ms之间，一般线上业务很忍受。备用区没有承载业务或者只有数据层冷份，恢复时间保证强依赖业务快速扩容，调度以及版本一致性等能力支撑。
以下是云上某个金融公司异地容灾架构：
1）接入层和业务层均使用低配以及业务单台服务器部署方式，主要提升业务快速扩容能力，一方面主可用区异常，借助腾讯弹性伸缩AS能快速扩容，另一方面业务发布版本在不同地域保持一致。
2）该数据层使用云上PAAS产品，云上产品均支持异地容灾能力，同时操作便捷。如CDB和COS均通过云上控制台按钮式方式建设异地容灾能力；而对于es通过ccr方式进行数据复制。
2 、同城容灾
同城容灾根据数据写入方式分为单写或者双写；单写称为半双活，双写称为双活。
（1）、同城半双活（单写）
同城半双活核心特征：
1）容灾范围：可用区粒度容灾。
2）流量分布：每个可用区均承载业务流量；数据层存在跨区写场景，根据业务敏感程度，流量按照适中比例调度到两个可用区，但是必须要两个可用区均承载业务，这里可用性和性能要进行取舍。
3）数据存储：数据库az部署，其中数据库单向同步，单可用区写多可用区读。
4）常见场景：业务对数据一致性要求较高，同时能接受跨可用区延时，网络延时大约2-3ms，对业务改动较小场景。
以下是某云上智慧零售企业同城半双活架构：
1）接入层和服务层均两个两个可用区1:1数量同规格部署，通过业务域名解析来承载业务
2）中间件和数据层均使用云上跨az产品能力，如果存量是实例为单可用区，在控制台升级为多可用区；期间对业务没有影响，例如cdb，redis产品。对于es，ckafka，TDMQ有天然的跨az容灾能力，如果当前产品不支持存量升级，产品均有成熟方案，迁移成本较低。
（2）、同城双活（双写）
同城双活核心特征：
1）容灾范围：可用区粒度容灾
2）流量分布：每个可用区均承载流量业务；数据库采用分区模式，将数据分为两个可用区，az间的网络延时对业务影响较小
3）数据存储：数据库和存储跨az部署，其中数据库双向同步，读写均在各自可用区；存储cos本身具备多az容灾
4）常见场景：数据一致性强依赖于业务，同时业务不能接受跨az延时；相比单写方案，对业务改造较大，相当于单元化和set的业务改造级别。
以下是云上某saas厂家同城双活案例：
云上的存储业务均采用虚拟机或者黑石机器进行自建，业务以账户单双号进行set化部署；A区的数据库存双号，B区的数据库存双号；数据库同步使用双向方式；每个AZ数据库均存在全量数据；当一个可用区故障，业务通过DNS以及业务调用配置下发能力，将业务切换到另外一个可用区，同时取消同步能力。
同城双活双写
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化改造都是公司多部门合作的超级大项目 | 良好的调度能力和地域粒度容灾能力 | \ |