阿里云云原生异地多活解决方案.docx

? ? ? ? ? DTCC-阿里云张鑫 阿里云云原生异地多活解决方案 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 简介： 异地多活，顾名思义就是分布在异地多个站点同时对外提供服务，与传统灾备最主要的区别是“多活”里所有站点都是同时在对外提供服务的。在业务不断复杂化和容灾要求不断严格化的今天，如何实现云原生的异地多活解决方案，成为了中大型企业不得不面对的挑战。在第十一届中国数据库技术大会（DTCC2020）上，阿里云高级数据库专家张鑫就为大家分享了阿里云云原生异地多活解决方案。 嘉宾介绍： 张鑫（花名：六金），阿里云高级数据库专家，之前主要作为DBA支持阿里巴巴内部包括交易、广告等在内的核心系统，近两年转战专有云市场，面向大型政企客户提供数据库解决方案。 本次分享将主要分为三个方面： 容灾架构分析 阿里云异地多活解决方案 异地多活客户案例 一、容灾架构分析 容灾必要性 异地多活本身是从容灾出发的，因此首先介绍一下容灾的必要性。生产系统可能会遇到三类故障，第一个是主机级故障，如单点负载过高、数据损坏等；第二类是机房级故障，如供电故障、机房网络故障等；第三类是地域级故障，如自然灾害等。对于上述三类故障而言，显然是地域级故障影响面最大，但发生概率最低，但对于主机级故障而言，却并不一定发生概率低且影响面小。阿里巴巴对于自身多年来的故障类型做了梳理，发现随着现在业务系统复杂度的增加，单点故障也可能会造成全局影响，而且当复杂度达到一定程度时，如果发生这种单点故障，排查和恢复都会非常困难，因此容灾能力成为了企业信息化建设的必选项。 容灾行业分析 从行业分析来看，容灾的市场还是比较可观的。根据权威报告预测：在2020年全球容灾市场份额将达到115.9亿美元，并且客户群体非常广泛，比如政府、金融、能源、互联网、通信等，基本上只要有信息化系统就有容灾需求。阿里云目前拥有十万家企业用户和四十万个数据库实例，这些都需要容灾能力保障。而在国家层面，也具有严格的合规要求，尤其是现在大型的政企客户都需参照《信息系统容灾恢复规范》GB/T 20988进行容灾建设。 容灾架构演进 容灾架构的演进主要分成几个阶段。同城容灾最为简单，即在同一个地域内有一个IDC并部署了业务，容灾时再部署一个机房备份系统和数据库，在中间实现异步或者同步的数据同步，业务流量集中在一边，另外一边只做灾备。后来逐渐演进出了同城双活，其借用了同城内两个数据中心地理距离比较近，网络延迟较短的优势，可以将业务部署到两端，因为物理距离较短，延迟等问题都可以接受。再往后就是异地双活，即两点三中心以及其衍生出的两地四中心等，主要就是在同城双活的基础之上再增加一个灾备中心，这个灾备中心常态下是不接收流量的，只有发生地域级故障时才会切换。 传统的容灾方案 重新梳理一下传统的容灾方案，对于同城容灾或者同城双活而言，优势在于部署简单，并且接入成本非常低；缺点在于仅提供同城保护，在GB/T 20988中只能达到1级能力，因此对于大型客户而言，无法选择该方案。对于异地冷备而言，优势同样在于部署简单，对业务侵入比较少，并且异地部署的灾备能力相对而言会高一些，能够达到2到5级；缺点在于冷备单元冗余成本较高，造成一定的资源浪费，此外因为灾备单元常年不接流量，因此真正发生故障的时候切换是否可用是一个未知数。对于两地三中心而言，其实就是同城双活和异地冷备两种方案的结合，其优势就是上述两个方案的优势，缺点则是冷备中心成本浪费和地域级故障发生时不敢进行切换。 二、阿里云异地多活解决方案 阿里云异地多活架构 如上图所示的是阿里云异地多活整体架构。实际上，异地多活的本质是通过对业务做自顶向下的流量隔离来实现的。阿里云将整个异地多活架构分为三层，第一层是接入层，实现异地双活首先需要为业务制定一个分流策略，如按照地域或用户维度分配流量，一旦定义好分流策略，即可在接入层实现流量拆分，属于本单元的流量可以继续向下透传执行，如果不属于则会将其转入正确的单元。第二层是服务层，就是对外提供服务的业务系统，针对于提供能力的不同划分为了单元化服务、中心化服务和普通服务三种类型。第三层是数据层，这一层所需要解决的是数据库所需要具备的双向跨域同步能力、防循环能力，并且需要保障切流时的数据质量。 阿里云针对OLTP和OLAP两种业务场景对于多活架构方案进行了细化，接下来逐个介绍。 OLTP业务多活架构 针对于OLTP业务，阿里云提供了一套相应的多活架构，其中包含了几个关键要素。第一，多活配置，主要通过MSHA进行一站式多活配置，其负责制定流量划分策略、决定哪些数据库需要进行多活。第二，多活流量控制，主要根据既定规则通过MSFE进行分流，其负责流量识别、流量分发以及流量校正。第三，多活数据同步，主要是通过DTS实现