超大规模数据库集群保稳系列之三：美团数据库容灾体系建设实践
总第562篇
2023年 第014篇
本文整理自美团技术沙龙第75期的主题分享《美团数据库攻防演练建设实践》，系超大规模数据库集群保稳系列（内含4个议题的PPT及视频）的第3篇文章。
1 容灾介绍
2 业务容灾架构
2.1 容灾架构演进
2.2 美团容灾架构
3 数据库容灾建设
3.1 面临的挑战
3.2 基础高可用
3.3 容灾建设路径
3.4 平台能力建设
3.5 演练体系建设
4 未来思考
4.1 补齐短板
4.2 迭代架构
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架构的。
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 隔离环境演练
3.5.2 生产环境演练
常态化、大规模故障演练：此类演练是日常持续开展的，通过演练平台对数据库集群注入故障，高可用进行故障切换。通过不同的演练规模来验证高可用的并发切换能力。此外，在容灾管控平台上，可以验证逃生能力、止损预案、及大规模故障的观测等。总而言之，它是利用“攻”和“防”相结合的形式，实现能力的验证验收和优化提升。
这类演练主要特点：一是参演集群都是由生产环境的高可用分组进行托管，就是说演练验证的都是生产环境的高可用的能力；二是参演的大规模集群是非业务集群，是每次演练前新创建的专门用于演练的集群，规模可以做到很大，目前可以常态化的进行1500+集群同时进行演练；三是有一定的仿真效果，为使演练更为真实并对RTO做精准评估，对演练集群增加了带载能力。
真实专区演练：上文介绍的隔离环境演练、大规模演练都是偏模拟性质的，和真实的故障场景有比较大的区别。为了弥补和真实故障主键的GAP，我们基于公有云构建了一个专用演练AZ，可以理解为就是一个独立的机房。参演业务和组PaaS件将部分承载业务流量的服务节点部署到演练AZ中，实际演练的时候会进行真实的断网，业务和组件可以在断网的时候观测和评估自己的容灾情况。这种通过真实机房、真实组件集群、真实的业务流量来验证组件和业务的实际容灾情况，会更加真实。
Game Day：此外我们还在评估论证在真实机房开展演练的可行性，随着隔离环境演练、专区演练的常态化开展，各个组件的基础容灾能力会越来越强，在真实机房进行常态化机房演练的终极目标也会随之达成。
4 未来思考
| 4.1 补齐短板
超大规模逃生能力、止损能力不足：随着我们自建数据中心的落地，我们自建的AZ规模会更大，这对能力的要求会更高，我们主要通过平台迭代和演练验证逐步提升能力。 跨域专线故障导致Region级高可用失效：接下来我们会探索单元化方案或者独立部署方案，实现Region级或者更细粒度的闭环管理。 业务出海新挑战：出海会给容灾架构带来一些新需求和挑战，是采用“长臂管辖”还是独立部署，是复用现有技术体系还是打造一套全新架构，这些问题都还需要进一步的探索和论证。 容灾效率问题：平台基础功能已经相对完善，不过容灾决策以及处理协同等还需要人工进行，效率相对较低，未来会把容灾管控、应急止损等能力逐步向自动化演进；多环境演练成本比较高，也要逐步做自动化演练，把核心的演练场景逐步纳到长稳环境，通过定时或一定的策略让它自动去跑故障场景，我们只需要关注核心指标运营即可。
| 4.2 迭代架构
数据库相关技术发展很快，比如Database Mesh、Serverless等新技术形态会逐步落地，届时中间件、高可用、内核等会有比较大的变化，新型客户端HA方案的建设成熟及新Proxy架构，存计分离产品的引入都会使容灾的能力发生比较大的变化。容灾能力建设会随着这些确定的产品演进进行迭代。
---------- END ----------