一，背景与概述
复杂系统的灾难恢复是个难题，具有海量数据及复杂业务场景的大数据容灾是个大难题。
MaxCompute是集团内重要数据平台，是自主研发的大数据解决方案，其规模和稳定性在业界都是领先的。在周边系统众多，业务场景复杂，海量数据存储和计算调度都是一个难题的情况下，需要保证大数据系统在灾难发生时能够尽快切换到备用系统服务，最小限度影响客户使用。
容灾系统及方案的建设有很多种方式，如同城双活，异地多活，冷备容灾等。MaxCompute大数据的容灾方案是在多年集团内部断网演练基础上，依据MaxCompute卓越具有前瞻性的设计形成的，选用了同城异地双活方案，并经过详细的系统修改及优化，部署测试，多轮演练，达到了客户现场输出的成熟度。
本文详细介绍了MaxCompute在专有云输出背景下依托现有技术及技术改造而形成的大数据容灾原理，技术方案，操作步骤，及相关RPO与RTO设计，还有一些在大数据容灾系统设计，实现，演练及部署过程中的思考，这里贡献给大家。
二，大数据容灾技术方案
2.1，MaxCompute容灾原理
MaxCompute的大数据容灾技术方案是基于现有系统架构，数据管理及运维特点形成的，主要依据MaxCompute目前现有技术与实现方案：多地域多控多计算集群支持， 统一元数据中数据版本管理， 跨集群复制与同步。
多地域多控多计算集群支持：
MaxCompte从系统架构上支持异地多机房环境下的多控制集群和多计算集群架构，在满足一定带宽及网络延迟要求条件下，MaxCompte服务能够从逻辑上管理同样功能的控制集群，并选择其中一个异地主控集群。且能够支持对单个项目空间进行多个计算集群配置，让同一个项目空间逻辑上拥有多个数据存储与计算的集群。即从系统设计开始，MaxCompute就没有区分地理上的控制集群和计算集群，可以对满足一定带宽和网络延迟条件下的异地集群同等对待，并能够做到从用户项目空间映射管理上管理异地集群，具备多集群统一调度能力。
统一元数据中数据版本管理:
MaxCompute在多计算集群部署时，同一份数据（表或分区）在多个计算集群上可能具有不同的版本，MaxCompute Meta服务会维护每份数据的版本信息，表示如下：
{"LatestVersion":*V1*,"Status":{"ClusterA":"*V1*","ClusterB":"*V0*"}
项目空间数据跨集群复制与同步:
MaxCompute中的的项目空间支持多个计算集群的配置，并且在元数据中有关于多个集群中每一份数据的版本信息，为了便于数据管理交互和计算，为了统一进行数据资源和计算资源的调度管理，MaxCompute设计并实现了项目空间中数据的跨集群复制与同步功能。
MaxCompute中当一份数据版本更新后，会触发一个分布式的跨集群数据复制任务，将数据复制到其他计算集群。 也可以针对项目空间中的数据进行统一的数据复制配置，如数据复制的内容及范围，频率及规则。同时跨集群复制同步也，通过对复制任务数的限制可以对机房间数据复制流量进行控制，用以从策略和方式上影响数据分布状态。
MaxCompute容灾基于以上三个系统特点和实现，从逻辑上确保服务能够支持多个逻辑集群，同一个项目空间能够跨集群管理，从物理上可以对同一份数据进行异地多机房存储与同步，并通过统一的数据同步方案进行数据同步管理和调度。在元数据容灾的基础上，形成了一套MaxCompute大数据容灾方案，该容灾方案依赖于数据的异地存放与元数据版本管理，服务运行中的数据状态如下图所示：
2.2，整体部署方案
主备机房中都会部署一套完整的MaxCompute服务（控制集群、计算集群、tunnel，MaxCompute前端）；
- 主备机房中的MaxCompute服务形成双控制集群双计算集群系统，对外提供统一接口，提供MaxCompute服务。
- 主机房及备用机房的MaxCompute服务均能够正常服务，但平时备用机房MaxCompute服务处于静默状态，由主机房提供服务。
- 主备机房的MaxCompute服务都打开数据复制功能，由主机房的Replication Service提供数据复制，按照复制策略定时或者按照数据请求将主机房数据同步至备用机房。
对于这个方案，主备机房各有一套MaxCompute服务，模块说明如下：
在正常工作状态下，主机房的MaxCompute提供服务，备机房的MaxCompute没有服务请求，上层数据业务都只通过两个服务域名使用MaxCompute：
- MaxCompute服务域名：指向命令前端集群的虚拟IP，即系统架构图中的VIP2
- Tunnel服务域名：指向Tunnel前端集群的虚拟IP，即系统架构图中的VIP1MaxCompute通过数据异步复制机制，不断将主机房的MaxCompute数据同步到备机房的计算集群，MaxCompute引入数据版本的机制。
2.3，容灾切换方案
- 容灾切换
容灾切换分计划内和计划外，对于计划内的切换，查看数据实时同步状态，选择某个已经完全同步的时刻进行容灾切换，这样RTO会非常短（分钟级），RPO为当前时刻，不需要回补数据。除了选择执行的时间点外，计划内和计划外的容灾切换流程是一致的。
主备容灾切换流程如下：
- 停掉主机房的VIP1和VIP2，主机房的MaxCompute服务不再接受新请求。
- 完成MaxCompute服务依赖系统如用户中心UMM和Meta存储服务OTS的双机房容灾切换。
- MaxCompute控制集群切换及MaxCompute计算集群切换
- MaxCompute服务切换后数据异常（本数据异常仅包括已制定数据同步方案而因故障未进行同步的数据）梳理及补数据操作
- 数据检查
对于在数据同步复制过程中发生主集群故障的数据，此时数据状态如下图所示，需进行复制同步状态检查及恢复操作。 MaxCompute依托大数据管家进行集群和服务运维，在大数据管家中开发了支持（Resource/volume/table）的未同步数据状态检查及元数据修复。
对于计划内的切换，UMM和OTS不会有数据丢失，且RTO为0，对于计划外的切换，可能有短暂时间内的数据丢失，通常是秒级，对于MaxCompute这样的离线大规模数据处理系统，忽略这段短暂时间内meta数据丢失的影响。
- MaxCompute提供工具扫描Meta数据，生成一份未同步的数据表或分区的列表。
- MaxCompute提供工具直接操作Meta数据，将未同步的数据表或分区drop掉，避免备机房MaxCompute服务起来后数据不正确。
- 启用备机房的VIP1’和VIP2’，切换MaxCompute服务域名和Tunnel服务域名到新的VIP，至此备机房的MaxCompute服务恢复，接受请求。
- 上层数据业务根据未同步的数据表或分区列表，进行数据重新导入和重新计算。至此数据恢复完成，可以恢复上层数据业务。
2.4，MaxCompute系统改造以支持大数据容灾
在实现整合Maxcompute容灾方案过程中，以及测试过程中，对现有实现中很多逻辑进行了优化和处理，并和相关依赖系统同步改造，完成Maxcompute大数据平台的容灾方案并测试验证通过，交付客户现场部署, 主要有：
- 相关依赖系统如OTS，账号系统UMM、AAS支持容灾改造
- 控制集群服务切换逻辑改造
- 控制集群配置读入与生效方式改造，使其能够接受容灾切换的请求并立即生效
- 相关管理Admintask支持多种数据检查功能
- 跨集群复制服务切换及切换后状态检查改造
- Resource数据同步方案
- 多控多计算在升级和新部署场景下的部署工具改造
- 大数据管家增加容灾切换，数据检查功能与接口
- MaxCompute部署底座支持VIP及域名切换功能
- ......
三，RPO与RTO
对于MaxCompute这种大规模离线数据处理系统来说，数据加工往往有突发的情况，在某个时间段产出的数据量可能非常大，受限于机房间的带宽，新上传的和新计算的数据复制到备机房需要一定的时间，MaxCompute提供实时查看当前未同步的数据表/分区，实时的容灾数据同步率等信息，实时数据同步率主要取决于两个因素的影响：
- 机房间带宽大小
- 主机房MaxCompute计算集群繁忙程度
因为数据复制也是以飞天分布式任务来进行的，需要用到主机房的MaxCompute计算集群的计算资源（主要是CPU和内存），MaxCompute可以根据这两个因素给出数据同步完成的时间预估。
数据中心灾难恢复流程，主要围绕两个指标RPO和RTO，借下图来说明MaxCompute容灾方案的细节：
MaxCompute的多控制、多计算集群的架构天然的支持高可用和数据容灾场景，在机房或集群遭受不可恢复性破坏时，确保数据不会丢失，业务不受影响。
MaxCompute是典型的离线计算平台，需要支持大量数据的写入操作，只能选择异步复制。
- RPO恢复点目标：
- RTO恢复时间目标：
容灾配置及部署对RPO/RTO的影响
- RPO时间要求配置Resource、Table， Volume 的同步周期。
- RPO（RecoveryPointObjective）影响范围通过数据检查扫描得到的Resource、Table， Volume未同步列表体现
- 大数据管家手动操作完成（控制集群切换 + 计算集群切换 + 数据检查完成 + Meta数据修补） + 用户使用上层业务系统补数据完成 = 切换完毕
- RTO （RecoveryTimeObjective） = 灾难决策 + 技术恢复（MaxCompute依赖系统及服务恢复 + MaxCompute服务恢复 + 数据检查与恢复）
四，项目落地实例
本容灾方案已经经过多轮内部演练，达到了产品输出的成熟度要求，在阿里云专有云底座部署的基础上，该方案已经在内部多轮数据同步验证，服务切换演练验证，数据检查验证，能够做到灾难场景下的服务切换，达到了系统设计目的，能够做到容灾方案对客户影响降到最低。
MaxCompute容灾方案和实现是阿里云专有云输出中系统能力重要一部分，支持了多个专有云版本。已经在政通专有云中依据目前容灾方案部署完毕，并能够平滑切换到新的专有云版本。做到了不同版本的专有云中系统能力的兼容和延续性。目前部署后的主备集群工作正常，数据同步正常。
控制集群切换（容灾模式）
计算集群切换（容灾模式）
未同步数据检查
五，一些思考
1, 正向切换和反向切换
正切和回切方案是一样的，MaxCompute数据异步复制系统只根据计算集群的数据版本来做数据复制，当切换到备机房后，备机房的数据版本会更新，数据会从备机房复制回原来的主机房，从而完成数据的同步。
所以，回切的步骤和正切的步骤一致。但需要等待数据从备用机房同步到主机房完成后做默认计算集群切换，不然会造成两边数据不一致问题。
2， MaxCompute容灾方案建立在依赖系统容灾的基础上，依赖系统服务状态对MaxCompute容灾及功能使用非常重要，在做方案过程中，需要综合考虑整体服务级的容灾方案，不仅着眼与MaxCompute系统本身，对其依赖系统容灾方案，冗余配置，服务状态，数据状态都需要通盘考虑。
3，大数据服务容灾是典型的分布式系统容灾方案涉及到系统间协调，主要考虑点为数据状态，服务状态切换，在灾难发生时最大程度保护重要数据，尽快使服务恢复，对客户影响降到最小。
4，系统设计的前瞻性对容灾方案及最终落地方案影响很大，客户业务状况对容灾场景和方案设计及实现影响很大。
5，大数据容灾部署状态及灾难发生后的容灾切换只是系统能力中的一个，更多的工作在于从业务层面合理分配数据资源，系统设计层面支持容灾能力，容灾切换和操作过程中准确判断系统及数据状态，是一个需要客户和服务提供商也就是Maxcompute平台团队共同面对的问题。
6，容灾方案都有一定的场景限制，本大数据容灾方案集中讨论了在异地单机房故障情况下容灾切换能力，对于上层业务系统适配链接使用多地MaxCompute服务没有阐述。这一点上也需要服务提供方和客户方共同参与，协调沟通最符合业务场景的大数据容灾方案与项目实践。
如有疑问欢迎联系 MC混合云容灾owner: 赵奕捷(陆东)
