我们通常会把故障分为三大类,一是主机故障,二是机房故障,三是地域故障。每类故障都有各自的诱发因素,而从主机到机房再到地域,故障发生概率依次越来越小,而故障的影响却越来越大。
容灾能力的建设目标是非常明确的,就是要能够应对和处理这种机房级和地域级的大规模故障,从而来保障业务的连续性。近几年,业界也发生了多次数据中心级别的故障,对相关公司的业务和品牌产生了非常大的负面影响。当前容灾能力已经成为众多IT企业建设信息化系统的必选项。
容灾架构从最早期的单活形态(同城主备)到同城多活形态,再演化到异地多活,根据这个路径可以将容灾分为容灾1.0、容灾2.0、容灾3.0三个阶段。
由于各公司所处发展阶段不同,采用的方案也会有所区别,美团大部分业务处于2.0阶段(即同城双活或多活架构),但对于大体量、有地域容灾及有地域扩展性要求的业务则处在容灾3.0阶段。下面会介绍一下美团的容灾架构。
美团的容灾架构主要包括两种,一种是N+1容灾架构,一种是SET化架构。
N+1架构:在业界也称散部或者多AZ部署⽅案,将容量为C的系统部署在N+1个机房,每个机房能提供至少C/N的容量,挂掉任何一个机房时,剩余系统仍能支撑C的容量。该方案的核心是把容灾能力下沉到PaaS组件来完成,在出现机房级或者地域级故障的时候,由各个PaaS组件独立完成容灾切换,实现业务恢复。整体架构如下图所示,业务上表现是多机房、多活形态,数据库采用这种主从架构,单机房处理写流量、多机房的负载均摊读流量。下面要讲“数据库容灾体系建设实践” 就是面向N+1架构的。
单元化架构:也叫SET化架构,这是一种偏应用层的容灾架构,它将应用,数据,基础组件按照统一的维度切分成多个单元,每个单元处理一部分闭环流量。业务以单元作为部署单位,通过单元互备方式实现同城容灾或者异地容灾。一般金融业务或者超大规模的业务会选择此类架构,它的好处就是流量可以闭环且资源隔离,具有很强的容灾能力和跨域扩展能力,不过SET化架构的落地需要业务系统做大量的改造,运维管理也较为复杂。简化示意图如下:
美团内部的大部分业务都是N+1架构,外卖和金融等业务采用了单元化架构。总体上美团内部既有同城多活,也有异地多活,两种容灾方案并存。
超大规模的集群带来的挑战:公司业务高速发展,服务器规模指数级增⻓,数据中心规模越来越大,大机房已有大几千数据库集群,上万个实例。
演练成本高、频次低:核心能力验证不充分,大规模故障的应对能力处于不可知状态,已知容灾能力“保鲜”困难。拿应对机房级大规模故障的相关能力来讲,很大一部分是处于不可知状态或者仅存在于“纸面”分析中,而对于已验证过的能力随着架构演进迭代,“保鲜”也很困难。
数据库作为有状态的服务之一,本身建设应对大规模故障能力的难度和挑战都相对更大。
数据库架构 在美团主要有两种一种是主从架构,一种是MGR架构。
为了建设提升数据库服务的容灾能力,内部成立了容灾管控项目DDTP(Database Disaster Tolerance Platform),专注提升数据库应对大规模故障的能力,核心包括基础容灾管控和故障演练两大能力,分别对应两个平台产品:一是容灾管控平台,一个是数据库演练平台。
容灾管控平台主要专注于防守,它的核心功能主要包括事前逃生、事中观测以及止损、事后恢复等,数据库演练平台则专注于进攻,支持多种故障类型和多种故障注入方式,具备故障编排,故障复盘等核心能力。这个系列的第二篇《数据库攻防演练建设实践》就是对演练平台的详细介绍。接下来,我们将重点介绍一下容灾管控平台的主要内容,首先看一下全景图:
数据库建立了一套N+1容灾计算标准,分为6个等级,如果集群容灾等级≥4级则容灾达标,否则容灾不达标。
从标准可以看出,从等级3开始就是多机房部署了。3级和4、5级的区别是,3级不满足N+1要求,即如果一个机房的节点都出问题,剩余节点无法承担峰值流量。等级4、5都是具备N+1要求的,等级5会满足region间容量对等。除基础标准以外,SET化集群有特殊规则,比如路由策略要闭环、SET集群的绑定机房要统一、互备SET容量要对等、集群内机型要统一等。这些规则都会纳入容灾计算来确定集群的最终容灾等级。
在基础容灾数据建设中,会把上述规则代码化、计算流程化,通过近实时的方式做基础数据“保鲜”。容灾数据是容灾管控平台上用于逃生切换和事中止损的基础数据,同时还会基于容灾数据建设风险隐患(即容灾不达标隐患),并通过一定的运营治理来消除这种隐患。
故障前逃逸能力就是批量主库切换和从库摘流,主要用于在故障前收到预警,提前感知灾难来临,快速将一个机房的所有数据库服务切走或者下线从库流量,以降低真实故障带来的影响。
我们知道对于主从架构的集群,如果因为断电或者断网发生故障切换,很可能会发生数据丢失。数据一旦丢失,业务需要进行确认并做善后工作,有时候会非常繁琐。如果能够在事前逃走就会把这些风险都规避掉。同时除了主库逃走以外,从库也可以提前把流量“摘掉”,从而做到故障对业务方“无感”。
在大规模故障发生的时候,一般会出现告警轰炸,电话咨询轰炸等情况,如果没有全局的故障感知能力,就会使故障处理比较混乱,处理时间比较长,让故障影响放大,所以我们建设了容灾观测大盘,它能够实时、准确、可靠地对故障进行观测,以确保值班同学能够掌握故障的实时情况。
如下图所示,如果发生了故障,可以快速拿到故障集群或者实例列表,并在对应的页面上发起兜底切换动作,进而实现快速止损。对观测大盘的核心诉求就是要实时、准确、可靠。可以通过减少服务依赖来提升自身的可用性。
在介绍故障中的止损之前,先了解一下预案服务。预案服务的核心功能就是管理常见故障以及对应的各种处理预案,并提供执行控制能力,让预案可以方便、可控地运行。
故障止损:在有了预案以后,我们就可以进行兜底止损。如下图所示,当大规模故障发生的时候,HA会自动进行故障处理。如果集群切换失败或者漏切,那么它就会进入兜底阶段。首先从DDTP平台化兜底,如果平台受故障影响不可用,可以在运维编排层进行兜底。如果运维编排服务也失效,则需要人工通过CLI工具进行兜底。CLI是DBA最底层的工具,它和高可用是两个独立的链路。CLI会进行集群拓扑探测、选主选举、拓扑调整、配置修改、配置下发等逻辑,等同于手工集群切换步骤。
总体原则优先提升高可用自动切换的成功率,减少透传到兜底阶段的集群数量。其次提升预案可靠性,优先选择白屏,逐级下沉,易用性下降,可靠性提升。
虽然集群具备N+1能力,一个机房故障的时候,集群剩余节点是能够支撑峰值流量,但它不具备再一次AZ故障的容灾能力,所以在故障后会根据各机房的资源情况,通过容灾决策中心快速进行集群扩容来补齐核心集群的容灾容量,使其重新具备AZ容灾能力。
上述方案有一个比较大的弊端就是需要有足够的资源来进行扩容,这是非常困难的,目前我们在建设更快速的恢复能力,如实例原地修复,集群原地扩容等,在AZ恢复之后,可以快速复用发生故障的机房内的机器资源,实现容灾快速恢复。
各项基础容灾能力不能只存在于架构设计、理论评估层面,必须实打实的可用,这就要需要通过演练进行验证。容灾管控项目之初,就制定了以演练为抓手的策略,验证并驱动各项基础能力的提升。 截止目前,已经初步建成了多环境、高频次、大规模、长链路的演练体系。
隔离环境演练顾名思义,它是一套和生产机房完全隔离的演练环境,有自己独立的TOR、机柜,风险能做到完全隔离,可以开展独立断网或断电操作。参与演练的PaaS组件和业务服务要在该环境独立部署。在隔离环境除了会定期开展各种容灾演练发现容灾问题外,还可以验证各PaaS的独立部署能力,为国际化业务支撑提供基础。
这类演练主要特点:一是参演集群都是由生产环境的高可用分组进行托管,就是说演练验证的都是生产环境的高可用的能力;二是参演的大规模集群是非业务集群,是每次演练前新创建的专门用于演练的集群,规模可以做到很大,目前可以常态化的进行1500+集群同时进行演练;三是有一定的仿真效果,为使演练更为真实并对RTO做精准评估,对演练集群增加了带载能力。
经过两年多的建设,虽然在高可用自动切换、容灾能力运营治理、大规模故障观测、故障止损预案、容灾恢复等方面取得了一定的成果。但是还有很多能力短板需要建设补齐,业务新的发展也带来了新的需求和挑战。未来我们会补齐短板、迭代技术架构两个方向上进行持续的提升。
数据库相关技术发展很快,比如Database Mesh、Serverless等新技术形态会逐步落地,届时中间件、高可用、内核等会有比较大的变化,新型客户端HA方案的建设成熟及新Proxy架构,存计分离产品的引入都会使容灾的能力发生比较大的变化。容灾能力建设会随着这些确定的产品演进进行迭代。
容灾建设是一件非常有挑战的事,也是所有公司业务发展壮大后必须面对的一件事。欢迎大家在文末留言,跟我们一起交流。