简述异地多活方案以及腾讯云实践

背景前言

为了保障系统可用性, 我们通常会为了应对故障将组件或数据做冗余。常见的类型包括: 变更故障、硬件故障、断电断网、自然灾害, 发生的频率一次降低。

部分系统对可用性要求极高, 为了应对上述即使可能性非常低的故障, 我们需要从容灾层面去考虑这些情况。

本文从常见的容灾方案和容灾架构入手介绍, 结合腾讯云多可用区容灾方案进行示例讲解。

系统与数据容灾架构

衡量容灾能力

评价容灾能力主要是RPO和RTO两个指标。

  • RPO : 应发生故障时能忍受数据丢失的最大程度。系统越重要,要求 RPO 越小
    - 如果做数据备份,RPO越小意味着数据的备份频率更高,比如一般的系统可能一天备份一次,非常重要的系统可能一小时备份一次;
    - 如果做数据同步,RPO越小意味着要求数据同步链路的可靠性更高或延迟更低,对整个生产环境和网络的压力越大,需要的成本也更高。
  • RTO: 应用从出现故障到故障恢复能接受的最大时间。系统越重要,要求 RTO 越小

国家标准化管理委员会发布的容灾恢复RTO/RPO各等级对应关系如下:

灾难恢复能力登记

RTO

RPO

1

2天以上

1至7天

2

24小时以上

1至7天

3

12小时以上

数小时至1天

4

数小时至2天

数小时至1天

5

数分钟至两天

0至30分钟

6

数分钟

0

我们可以看到最严格的6级标准 RPO 为0, 意味系统不允许丢失数据(很多大型项目也都有着这个要求)

容灾分层

image.png

相对接入层、应用层容灾而言,数据层的容灾相对比较复杂,实现起来难度大一些。 下面我们主要阐述的也是数据层的容灾。

主流容灾架构

同城灾备

同一个城市至少部署两个机房,仅主机房对外提供服务, 备机房平时不提供服务能力,主要作为主机房的备份,主备之间数据采用单向同步的形式。

undefined(https://iwiki.woa.com/tencent/api/attachments/s3/url?attachmentid=68288undefined(https://km.woa.com/gkm/api/img/cos-file-url?url=https%3A%2F%2Fkm-pro-1258638997.cos.ap-guangzhou.myqcloud.com%2Ffiles%2Fphotos%2Fpictures%2F202208%2F1661740963-7135-630c27a3ae350-387876.png&is_redirect=1

优点: 部署简单,将同一套架构完全复制到另外机房即可,数据做单向同步,对业务的改造极少。

缺点: 备数据中心存在资源浪费的情况;关键时刻不敢切流,容易出现版本、参数、操作系统不一致等情况

同城双活

两个机房同时对外提供服务。为了数据的一致性,所有写操作都会放在主数据中心,因此两个数据中心的距离要求小于50km,RT小于2ms~6ms。如果请求落在备数据中心,则涉及到跨机房写操作(备机房应用写主数据中心)。如果跨机房的 RT 非常大,数据请求在主、备数据中心的性能差异也会非常大,无法提供很好的用户体验。架构上数据采用单向同步方式。

image.png

优点: 解决了备数据中心资源浪费的问题,并且因为日常保持提供服务状态,出现故障时可以随时切换,切换前只需要做数据中心的主备切换, RTO为分钟级。

缺点: 灾备局限在同城区域内,距离受限, 城市级灾难容易不可用。 对于延时敏感的系统跨机房写会给用户带来不好的体验

伪异地双活(应用层双活)

这种架构与同城双活有很多相似之处,唯一的区别在于备数据中心的读写进行了分离,读操作直接读备数据中心,而写操作为了保证数据一致性,将打到主数据中心的数据库上。要求两个数据中心距离小于100km,RT小于6ms。如果两个机房的距离过远,请求在两个机房之间的性能表现差异会很大。此架构比较适合读多写少的系统。

image.png

优点: 具备了一定程度的地域级别容灾能力,虽然架构要求距离小于100km,但是对于大部分地级城市而言,100km已经能够覆盖两个地级城市,RTO 只需分钟级别。

缺点: 业务系统需要能够接受一定的跨机房网络延;业务需要进行一定程度的改造, 将操作分位读操作和写操作两类;容灾距离依然受到非常大的限制(主要受限于跨机房写)

异地双(多)活

异地双活可以接受两个机房之间的距离大于1000km,RT 超过 10ms。为了解决此前两个机房中的性能差异,我们使用了单元化的解决方案。单元化指请求落到某单元后,所有请求操作都在单元内闭环处理,避免涉及跨机房操作。因而不管请求打到哪个机房都能保证基本一致的处理效率,也能保证良好的用户体验。为了实现单元化,要求各个机房之间数据双向同步

image.png

优点: 容灾能力非常强,几乎不受限制, RTO为分钟级别。

缺点: 部署复杂,涉及到数据的双向同步(需要在同步过程中解决数据冲突的问题, 云厂商一般使用DTS工具进行同步),还会涉及到比如 Redis 缓存、 Rocket MQ 、有状态中间件等;业务改造成本非常高,涉及到单元化和接入层等维度。

云上容灾架构分析

案例一腾讯云上云基础架构

云上基础容灾架构如下(数据层采取同城双活):

image.png

主要产品:

  • CDN 加速
  • WAF应用防火墙+DDOS防护
  • CLB 负载均衡(多可用区)
  • 多可用区云主机
  • 数据库(多可用区主备+异地灾备)
本站文章资源均来源自网络,除非特别声明,否则均不代表站方观点,并仅供查阅,不作为任何参考依据!
如有侵权请及时跟我们联系,本站将及时删除!
如遇版权问题,请查看 本站版权声明
THE END
分享
二维码
海报
简述异地多活方案以及腾讯云实践
为了保障系统可用性, 我们通常会为了应对故障将组件或数据做冗余。常见的类型包括: 变更故障、硬件故障、断电断网、自然灾害, 发生的频率一次降低。
<<上一篇
下一篇>>