超大规模数据库集群保稳系列之三:美团数据库容灾体系建设实践
2023-6-9 08:0:0 Author: tech.meituan.com(查看原文) 阅读量:16 收藏

1 容灾介绍

我们通常会把故障分为三大类,一是主机故障,二是机房故障,三是地域故障。每类故障都有各自的诱发因素,而从主机到机房再到地域,故障发生概率依次越来越小,而故障的影响却越来越大。

容灾能力的建设目标是非常明确的,就是要能够应对和处理这种机房级和地域级的大规模故障,从而来保障业务的连续性。近几年,业界也发生了多次数据中心级别的故障,对相关公司的业务和品牌产生了非常大的负面影响。当前容灾能力已经成为众多IT企业建设信息化系统的必选项。

2 业务容灾架构

2.1 容灾架构演进

容灾架构从最早期的单活形态(同城主备)到同城多活形态,再演化到异地多活,根据这个路径可以将容灾分为容灾1.0、容灾2.0、容灾3.0三个阶段。

  • 容灾1.0:容灾体系围绕数据建设,多以主-备的方式部署,但备用机房不承担流量,基本上都是单活结构。
  • 容灾2.0:容灾视角从数据转换为应用系统,业务具有同城双活或同城多活能力,采用同城双活或同城双活加异地冷备(两地三中心)的部署架构,除冷备以外的每个机房都有流量处理能力。
  • 容灾3.0:以业务为中心,多采用单元化架构,容灾基于单元间的两两互备实现,根据单元的部署位置可以实现同城多活和异地多活。采用单元化架构的应用本身具有很好的容灾能力和扩展能力。

由于各公司所处发展阶段不同,采用的方案也会有所区别,美团大部分业务处于2.0阶段(即同城双活或多活架构),但对于大体量、有地域容灾及有地域扩展性要求的业务则处在容灾3.0阶段。下面会介绍一下美团的容灾架构。

2.2 美团容灾架构

美团的容灾架构主要包括两种,一种是N+1容灾架构,一种是SET化架构。

N+1架构:在业界也称散部或者多AZ部署⽅案,将容量为C的系统部署在N+1个机房,每个机房能提供至少C/N的容量,挂掉任何一个机房时,剩余系统仍能支撑C的容量。该方案的核心是把容灾能力下沉到PaaS组件来完成,在出现机房级或者地域级故障的时候,由各个PaaS组件独立完成容灾切换,实现业务恢复。整体架构如下图所示,业务上表现是多机房、多活形态,数据库采用这种主从架构,单机房处理写流量、多机房的负载均摊读流量。下面要讲“数据库容灾体系建设实践” 就是面向N+1架构的。

单元化架构:也叫SET化架构,这是一种偏应用层的容灾架构,它将应用,数据,基础组件按照统一的维度切分成多个单元,每个单元处理一部分闭环流量。业务以单元作为部署单位,通过单元互备方式实现同城容灾或者异地容灾。一般金融业务或者超大规模的业务会选择此类架构,它的好处就是流量可以闭环且资源隔离,具有很强的容灾能力和跨域扩展能力,不过SET化架构的落地需要业务系统做大量的改造,运维管理也较为复杂。简化示意图如下:

美团内部的大部分业务都是N+1架构,外卖和金融等业务采用了单元化架构。总体上美团内部既有同城多活,也有异地多活,两种容灾方案并存。

3 数据库容灾建设

3.1 面临的挑战

超大规模的集群带来的挑战:公司业务高速发展,服务器规模指数级增⻓,数据中心规模越来越大,大机房已有大几千数据库集群,上万个实例。

  • 性能问题:高可用系统的故障并发处理能力出现明显瓶颈。
  • 容灾失效风险:管控链路随集群数量的增加变的越来越复杂,一个环节出问题就会导致整体容灾能力失效。
  • 故障频发:集群数量和规模变大,使原来概率很低的大规模故障变成了稀松平常的故障,其发生的频次和概率越来越高。

演练成本高、频次低:核心能力验证不充分,大规模故障的应对能力处于不可知状态,已知容灾能力“保鲜”困难。拿应对机房级大规模故障的相关能力来讲,很大一部分是处于不可知状态或者仅存在于“纸面”分析中,而对于已验证过的能力随着架构演进迭代,“保鲜”也很困难。

数据库作为有状态的服务之一,本身建设应对大规模故障能力的难度和挑战都相对更大。

3.2 基础高可用

数据库架构 在美团主要有两种一种是主从架构,一种是MGR架构。

  • 主从架构:应用通过数据库中间件访问数据库,在故障发生时,高可用做故障探测、拓扑调整、配置下发,进而应用恢复。
  • MGR架构:应用也是通过中间件访问数据库,不过中间件对MGR做了适配,内部叫Zebra for MGR,中间件自动进行拓扑探测感知,一旦MGR发生了切换,新拓扑会被探测到,数据源会进行调整,进而业务恢复。
  • 美团的高可用架构:美团主从集群的高可用是基于Orchestrator二次开发的,本质上是一个中心化的管控架构,如下图所示,有多个高可用分组,每个分组托管一部分数据库集群,分组在北京和上海实现两Region部署,底层核心组件只在北京部署,比如我们的核心CMBD、WorkflowDB等,一旦北上专线出现问题,上海侧的高可用会失效不可用。

3.3 容灾建设路径

  • 容灾建设路径:确定容灾目标、制定容灾标准、建设容灾平台、夯实基础能力、演练验证和风险运营。
  • 容灾建设飞轮:内环是平台能力建设,从容灾需求的提出到研发上线,体验提升,用户使用,发现问题提出新需求,不断的迭代提升。另一个方面就是完善演练平台建设,开展高频演练(或者真实故障驱动),发现问题、提出改进,促近平台能力持续迭代提升。

3.4 平台能力建设

为了建设提升数据库服务的容灾能力,内部成立了容灾管控项目DDTP(Database Disaster Tolerance Platform),专注提升数据库应对大规模故障的能力,核心包括基础容灾管控和故障演练两大能力,分别对应两个平台产品:一是容灾管控平台,一个是数据库演练平台。

容灾管控平台主要专注于防守,它的核心功能主要包括事前逃生、事中观测以及止损、事后恢复等,数据库演练平台则专注于进攻,支持多种故障类型和多种故障注入方式,具备故障编排,故障复盘等核心能力。这个系列的第二篇《数据库攻防演练建设实践》就是对演练平台的详细介绍。接下来,我们将重点介绍一下容灾管控平台的主要内容,首先看一下全景图:

  • 数据库服务:包括MySQL、Blade、MGR等基础数据库服务。
  • 基础能力层:主要是备份恢复、资源管理、弹性伸缩、主从高可用以及指标监控能力,这些能力是稳定性保障的基本部分,但在容灾场景下需要进一步加强,以处理大规模故障场景。
  • 管控编排层:核心是运维编排服务OOS(Operation Orchestration Service),会把基础能力按需编排生成对应的处理流程也叫服务化预案,每个预案对应一个或者多个具体的运维场景。容灾预案也在这个范畴。
  • 平台服务层:是容灾管控平台的能力层,包括:1)容灾管控,容灾计算评估和隐患治理,还有故障前容灾逃生、故障中的兜底切换,故障摘流等。2)容灾观测,明确故障范围,支持故障中的容灾决策。3)容灾恢复,故障后通过实例修复、集群扩容等功能快速恢复集群的容灾能力。4)预案服务,包含了常见故障应急预案的管理和执行等等。

3.4.1 容量达标

数据库建立了一套N+1容灾计算标准,分为6个等级,如果集群容灾等级≥4级则容灾达标,否则容灾不达标。

从标准可以看出,从等级3开始就是多机房部署了。3级和4、5级的区别是,3级不满足N+1要求,即如果一个机房的节点都出问题,剩余节点无法承担峰值流量。等级4、5都是具备N+1要求的,等级5会满足region间容量对等。除基础标准以外,SET化集群有特殊规则,比如路由策略要闭环、SET集群的绑定机房要统一、互备SET容量要对等、集群内机型要统一等。这些规则都会纳入容灾计算来确定集群的最终容灾等级。

在基础容灾数据建设中,会把上述规则代码化、计算流程化,通过近实时的方式做基础数据“保鲜”。容灾数据是容灾管控平台上用于逃生切换和事中止损的基础数据,同时还会基于容灾数据建设风险隐患(即容灾不达标隐患),并通过一定的运营治理来消除这种隐患。

3.4.2 故障前逃生

故障前逃逸能力就是批量主库切换和从库摘流,主要用于在故障前收到预警,提前感知灾难来临,快速将一个机房的所有数据库服务切走或者下线从库流量,以降低真实故障带来的影响。

我们知道对于主从架构的集群,如果因为断电或者断网发生故障切换,很可能会发生数据丢失。数据一旦丢失,业务需要进行确认并做善后工作,有时候会非常繁琐。如果能够在事前逃走就会把这些风险都规避掉。同时除了主库逃走以外,从库也可以提前把流量“摘掉”,从而做到故障对业务方“无感”。

3.4.3 故障中观测

在大规模故障发生的时候,一般会出现告警轰炸,电话咨询轰炸等情况,如果没有全局的故障感知能力,就会使故障处理比较混乱,处理时间比较长,让故障影响放大,所以我们建设了容灾观测大盘,它能够实时、准确、可靠地对故障进行观测,以确保值班同学能够掌握故障的实时情况。

如下图所示,如果发生了故障,可以快速拿到故障集群或者实例列表,并在对应的页面上发起兜底切换动作,进而实现快速止损。对观测大盘的核心诉求就是要实时、准确、可靠。可以通过减少服务依赖来提升自身的可用性。

3.4.4 故障中止损

在介绍故障中的止损之前,先了解一下预案服务。预案服务的核心功能就是管理常见故障以及对应的各种处理预案,并提供执行控制能力,让预案可以方便、可控地运行。

故障止损:在有了预案以后,我们就可以进行兜底止损。如下图所示,当大规模故障发生的时候,HA会自动进行故障处理。如果集群切换失败或者漏切,那么它就会进入兜底阶段。首先从DDTP平台化兜底,如果平台受故障影响不可用,可以在运维编排层进行兜底。如果运维编排服务也失效,则需要人工通过CLI工具进行兜底。CLI是DBA最底层的工具,它和高可用是两个独立的链路。CLI会进行集群拓扑探测、选主选举、拓扑调整、配置修改、配置下发等逻辑,等同于手工集群切换步骤。

总体原则优先提升高可用自动切换的成功率,减少透传到兜底阶段的集群数量。其次提升预案可靠性,优先选择白屏,逐级下沉,易用性下降,可靠性提升。

3.4.5 故障后恢复

虽然集群具备N+1能力,一个机房故障的时候,集群剩余节点是能够支撑峰值流量,但它不具备再一次AZ故障的容灾能力,所以在故障后会根据各机房的资源情况,通过容灾决策中心快速进行集群扩容来补齐核心集群的容灾容量,使其重新具备AZ容灾能力。

上述方案有一个比较大的弊端就是需要有足够的资源来进行扩容,这是非常困难的,目前我们在建设更快速的恢复能力,如实例原地修复,集群原地扩容等,在AZ恢复之后,可以快速复用发生故障的机房内的机器资源,实现容灾快速恢复。

3.5 演练体系建设

各项基础容灾能力不能只存在于架构设计、理论评估层面,必须实打实的可用,这就要需要通过演练进行验证。容灾管控项目之初,就制定了以演练为抓手的策略,验证并驱动各项基础能力的提升。 截止目前,已经初步建成了多环境、高频次、大规模、长链路的演练体系。

  • 多环境:我们建设了多种演练环境,满足各个PaaS组件的各类容灾演练需求。一是容灾管控平台的⻓稳环境,二是线下专用于演练的隔离环境,三是生产环境,有演练专区以及正常生产环境。
  • 高频次:目前能做到天、周级别。天级别属于常态化的演练,主要是在长稳环境下自动发起,几百个集群的演练规模;周级别主要是在隔离环境、演练专区定期组织的断网、断电真实演练等。
  • 大规模:是在生产环境开展的演练,用于验证基础高可用、兜底预案、逃生预案、容灾恢复等功能的大规模、高并发处理能力,确定管控系统的服务容量。
  • 长链路:整个容灾链路涉及到很多组件,包括CMDB数据库、流程数据库,高可用组件,配置中心、预案服务等,我们会逐步把这些组件都纳入演练,可以让一个或者多个组件服务同时故障,发现潜在问题,验证多服务的多节点同时故障对于整个故障处理能力的影响。

3.5.1 隔离环境演练

隔离环境演练顾名思义,它是一套和生产机房完全隔离的演练环境,有自己独立的TOR、机柜,风险能做到完全隔离,可以开展独立断网或断电操作。参与演练的PaaS组件和业务服务要在该环境独立部署。在隔离环境除了会定期开展各种容灾演练发现容灾问题外,还可以验证各PaaS的独立部署能力,为国际化业务支撑提供基础。

3.5.2 生产环境演练

  • 常态化、大规模故障演练:此类演练是日常持续开展的,通过演练平台对数据库集群注入故障,高可用进行故障切换。通过不同的演练规模来验证高可用的并发切换能力。此外,在容灾管控平台上,可以验证逃生能力、止损预案、及大规模故障的观测等。总而言之,它是利用“攻”和“防”相结合的形式,实现能力的验证验收和优化提升。

这类演练主要特点:一是参演集群都是由生产环境的高可用分组进行托管,就是说演练验证的都是生产环境的高可用的能力;二是参演的大规模集群是非业务集群,是每次演练前新创建的专门用于演练的集群,规模可以做到很大,目前可以常态化的进行1500+集群同时进行演练;三是有一定的仿真效果,为使演练更为真实并对RTO做精准评估,对演练集群增加了带载能力。

  • 真实专区演练:上文介绍的隔离环境演练、大规模演练都是偏模拟性质的,和真实的故障场景有比较大的区别。为了弥补和真实故障主键的GAP,我们基于公有云构建了一个专用演练AZ,可以理解为就是一个独立的机房。参演业务和组PaaS件将部分承载业务流量的服务节点部署到演练AZ中,实际演练的时候会进行真实的断网,业务和组件可以在断网的时候观测和评估自己的容灾情况。这种通过真实机房、真实组件集群、真实的业务流量来验证组件和业务的实际容灾情况,会更加真实。

  • Game Day:此外我们还在评估论证在真实机房开展演练的可行性,随着隔离环境演练、专区演练的常态化开展,各个组件的基础容灾能力会越来越强,在真实机房进行常态化机房演练的终极目标也会随之达成。

4 未来思考

经过两年多的建设,虽然在高可用自动切换、容灾能力运营治理、大规模故障观测、故障止损预案、容灾恢复等方面取得了一定的成果。但是还有很多能力短板需要建设补齐,业务新的发展也带来了新的需求和挑战。未来我们会补齐短板、迭代技术架构两个方向上进行持续的提升。

4.1 补齐短板

  • 超大规模逃生能力、止损能力不足:随着我们自建数据中心的落地,我们自建的AZ规模会更大,这对能力的要求会更高,我们主要通过平台迭代和演练验证逐步提升能力。
  • 跨域专线故障导致Region级高可用失效:接下来我们会探索单元化方案或者独立部署方案,实现Region级或者更细粒度的闭环管理。
  • 业务出海新挑战:出海会给容灾架构带来一些新需求和挑战,是采用“长臂管辖”还是独立部署,是复用现有技术体系还是打造一套全新架构,这些问题都还需要进一步的探索和论证。
  • 容灾效率问题:平台基础功能已经相对完善,不过容灾决策以及处理协同等还需要人工进行,效率相对较低,未来会把容灾管控、应急止损等能力逐步向自动化演进;多环境演练成本比较高,也要逐步做自动化演练,把核心的演练场景逐步纳到长稳环境,通过定时或一定的策略让它自动去跑故障场景,我们只需要关注核心指标运营即可。

4.2 迭代架构

数据库相关技术发展很快,比如Database Mesh、Serverless等新技术形态会逐步落地,届时中间件、高可用、内核等会有比较大的变化,新型客户端HA方案的建设成熟及新Proxy架构,存计分离产品的引入都会使容灾的能力发生比较大的变化。容灾能力建设会随着这些确定的产品演进进行迭代。

容灾建设是一件非常有挑战的事,也是所有公司业务发展壮大后必须面对的一件事。欢迎大家在文末留言,跟我们一起交流。


文章来源: https://tech.meituan.com/2023/06/09/meituan-database-recovery-system.html
如有侵权请联系:admin#unsafe.sh