- 1、本文档共8页,可阅读全部内容。
- 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
容灾基本名词解释
容灾
“容”,容忍,恢复,“灾”,故障;
冷备
与本地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)容灾范围:地域粒度的容灾。
2)流量分布:单地域承载100%业务流量。
3)数据存储:数据库以及存储均在异地做冷备,数据单向同步。
4)常见使用场景:主要在数据层安全级别容灾,业务层较少异地部署。跨地域数据同步耗时较长,国内大约30-60ms之间,一般线上业务很忍受。备用区没有承载业务或者只有数据层冷份,恢复时间保证强依赖业务快速扩容,调度以及版本一致性等能力支撑。
以下是云上某个金融公司异地容灾架构:
1)接入层和业务层均使用低配以及业务单台服务器部署方式,主要提升业务快速扩容能力,一方面主可用区异常,借助腾讯弹性伸缩AS能快速扩容,另一方面业务发布版本在不同地域保持一致。
2)该数据层使用云上PAAS产品,云上产品均支持异地容灾能力,同时操作便捷。如CDB和COS均通过云上控制台按钮式方式建设异地容灾能力;而对于es通过ccr方式进行数据复制。
同城容灾
同城容灾根据数据写入方式分为单写或者双写;单写称为半双活,双写称为双活。
同城半双活(单写)
同城半双活核心特征:
1)容灾范围:可用区粒度容灾。
2)流量分布:每个可用区均承载业务流量;数据层存在跨区写场景,根据业务敏感程度,流量按照适中比例调度到两个可用区,但是必须要两个可用区均承载业务,这里可用性和性能要进行取舍。
3)数据存储:数据库az部署,其中数据库单向同步,单可用区写多可用区读。
4)常见场景:业务对数据一致性要求较高,同时能接受跨可用区延时,网络延时大约2-3ms,对业务改动较小场景。
以下是某云上智慧零售企业同城半双活架构:
1)接入层和服务层均两个两个可用区1:1数量同规格部署,通过业务域名解析来承载业务
中间件和数据层均使用云上跨az产品能力,如果存量是实例为单可用区,在控制台升级为多可用区;期间对业务没有影响,例如cdb,redis产品。对于es,ckafka,TDMQ有天然的跨az容灾能力,如果当前产品不支持存量升级
文档评论(0)