Part 01
容灾介绍
我们通常会把故障分为三类,一是主机故障,二是机房故障,三是地域故障。每类故障都有各自的诱发因素,而从主机到机房再到地域,故障发生概率依次越来越小,而故障的影响却越来越大。
图片
容灾能力的建设目标是非常明确的,就是要能够应对和处理这种机房级和地域级的大规模故障,从而来保障业务的连续性。近几年,业界也发生了多次数据中心级别的故障,对相关公司的业务和品牌产生了非常大的负面影响。当前容灾能力已经成为众多企业建设信息化系统的必选项。
Part 02
容灾架构演进
容灾架构从最早期的同城主备到同城多活形态,再演化到异地多活,根据这个过程可以将容灾分为容灾1.0、容灾2.0、容灾3.0三个阶段。
- 容灾1.0:容灾体系围绕数据建设,多以主-备的方式部署,但备用机房不承担流量,基本上都是单活结构。
- 容灾2.0:容灾视角从数据转换为应用系统,业务具有同城双活或同城多活能力,采用同城双活或同城双活加异地冷备(两地三中心)的部署架构,除冷备以外的每个机房都有流量处理能力。
- 容灾3.0:以业务为中心,多采用单元化架构,容灾基于单元间的两两互备实现,根据单元的部署位置可以实现同城多活和异地多活。采用单元化架构的应用本身具有很好的容灾能力和扩展能力。
Part 03
常见节点故障处理过程
(1)计算节点故障
分布式数据库的计算节点多采用多实例部署。所以当一个计算节点故障后,负载均衡通过心跳检查识别到故障,自动把请求分发到其他的计算节点上。等到该节点恢复后,负载均衡检测到节点正常服务,会将请求重新均衡到该计算节点上。
(2)存储节点主库故障
当分布式数据库的存储节点集群出现主库故障,集群的健康检查会监测到主库发生故障,并通过多次探测确认故障。如果主库故障确认,系统会控制存储节点集群进行主从切换,将一个从库节点选举为新的主库节点,并调整集群的主从同步关系。同时集群拓扑的元数据会进行更新,推送到集群的各节点,包括查询路由相关信息。这样应用层的写操作会发送到新的主库。此时存在故障的副本节点,根据集群的副本策略和恢复机制,恢复系统会触发一个恢复任务,重新恢复一个新的从库节点加入集群。
(3)存储节点从库故障
当分布式集群的一组主从出现从库节点故障,集群的健康检查模块会监测到从库故障,并通过多次探测来确认故障。如果确认从库故障,系统会将该从库进行下线处理。同时集群拓扑的元数据会进行更新,将该故障的从库节点从集群信息中删除,并推送到集群的各节点进行更新。查询路由相关的信息更新后,应用层的读操作不再发送到故障的从库。此时由于存在一个故障的副本节点,根据集群的副本策略和恢复机制,系统的恢复系统会触发一个恢复任务,重新恢复一个新的从库节点加入集群。
(4)网络故障
专线网络抖动异常一般会带来延时和丢包,集群的计算服务节点、存储服务节点、管控节点之间的通讯都有完备的超时重试机制,少量的延时丢包不会影响查询性能,跨专线的主从延时会增大,待网络质量恢复后即恢复正常。
Part 04
容灾架构案例介绍
(1)美团数据库容灾方案
美团的容灾架构主要包括两种,一种是N+1容灾架构,一种是SET化架构。
N+1架构:在业界也称散部或者多AZ部署⽅案,将容量为C的系统部署在N+1个机房,每个机房能提供至少C/N的容量,挂掉任何一个机房时,剩余系统仍能支撑C的容量。该方案的核心是把容灾能力下沉到PaaS组件来完成,在出现机房级或者地域级故障的时候,由各个PaaS组件独立完成容灾切换,实现业务恢复。整体架构如下图所示,业务上表现是多机房、多活形态,数据库采用这种主从架构,单机房处理写流量、多机房的负载均摊读流量。下面要讲“数据库容灾体系建设实践” 就是面向N+1架构的。
图片
SET化架构:这是一种偏应用层的容灾架构,它将应用,数据,基础组件按照统一的维度切分成多个单元,每个单元处理一部分闭环流量。业务以单元作为部署单位,通过单元互备方式实现同城容灾或者异地容灾。一般金融业务或者超大规模的业务会选择此类架构,它的好处就是流量可以闭环且资源隔离,具有很强的容灾能力和跨域扩展能力,不过SET化架构的落地需要业务系统做大量的改造,运维管理也较为复杂。简化示意图如下:
图片
(2)阿里数据库容灾方案
DT大淘系数据是阿里巴巴集团典型的数据中台,DT引入了Hologres的读写分离能力,并结合全链路的主备双链路,在降低单库出问题概率的同时构建异地主备容灾,建立产品核心指标的“复活甲”,通过秒级切换的高可用容灾方案,高吞吐写入和灵活查询互不干扰,分析查询QPS增长80%的同时,查询抖动明显减少,让业务拥有底气和信心去应对随时可能出现的不可控风险,为整个产品和业务决策分析提供稳定支持。
图片
(3)浪潮数据库容灾方案
与传统的数据灾备和复制技术不同,浪潮K-DB和DSG SuperSync方案是针对Oracle数据库的异构灾备和数据复制方案,提供了基于逻辑的交易复制方式。该方式通过直接捕获Oracle数据库的交易,将数据库的改变逻辑复制到K-DB数据库中,实现Oracle系统数据库和K-DB系统数据库数据的一致性,从而提高系统数据的安全性和灵活性,降低灾备系统TCO,系统架构如下:
图片
K-DB Standby Cluster提供同构数据库的高可用性、数据的保护、灾难恢复功能,DSG SuperSync提供异构数据库的高可用性、数据的保护、灾难恢复功能。
(4)腾讯数据库容灾方案
客户业务场景最常用腾讯云数据产品主要是redis,cdb,mongoDB以及TDSQL。
图片
Part 05
结束语
系统建设过程中高可用自动切换、容灾能力运营治理、大规模故障观测、故障止损预案、容灾恢复等方面都会有很多的需求和挑战,也是所有公司业务发展壮大后必须面对的一件事,欢迎大家能跟我们一起交流这个过程,共同进步。