1. 故障问题描述
客户现场发生了ODPS主备机房相互数据全量复制导致的主备中心网络被打爆的问题，严重影响了日常运行的ODPS任务。在ODPS主备机房的环境中，用户的任务均在主机房中运行，产生的数据默认会落在主机房，通过ODPS replicationService将主机房的数据异步复制到备用机房。那么为什么会有反向同步到主机房数据的情况，需要对该问题开展排查进行根因分析。
2. 故障现象
在排查过程中观察关闭数据前后的机器网络负载状态，当打开数据主备复制的时候，机器的网卡的进出流量很大。
图1
继续排查发现主机房复制作业和备机房复制作业都在运行，而且很多都是没有更新的数据表，这种没有必要的全量数据同步造成大量的网络开销。
图2
图3
图4
3. 故障原因分析
在解决问题之前，我们需要先搞清楚ODPS同城双机房容灾整体技术方案和其中的跨机房数据异步复制工作原理。
3.1 ODPS同城双机房容灾整体技术方案
ODPS产品应用中针对每一种场景的故障或者集群灾难，其故障恢复或者服务切换方案都是不同的。该客户属于ODPS同城双机房容灾方案，我们先看下ODPS同城双机房容灾整体技术方案。
- 特点:
- 主备机房均部署完整的MaxCompute服务（控制集群、计算集群、tunnel、前端）。
- 主备机房均可以正常使用，但正常状态下，备机房处于静默状态，不处理具体业务请求。
- 主备机房之间开启数据传输，设置既定的策略定时或按需将数据同步到备机房。
- 核心逻辑:
- 元数据保持同步复制；
- 业务数据保持异步复制；
- RTO：可以实现分钟级；
- RPO：视数据量及同步频率来定，一般为小时级。
- 网络要求：
- 元数据的同步延迟要控制在5ms以内；
- 业务数据的同步延迟要控制在20ms以内。
图5
- 模块具体说明如下：
- VIP1：指向一组Tunnel数据服务节点的虚拟IP，绑定ODPS tunnel的域名，所有的ODPS数据上传和下载都经过VIP1。
- VIP2：指向一组ODPS DDL/DML命令服务节点的虚拟IP，绑定ODPS服务的域名，所有的DDL/DML命令都通过VIP2提交给ODPS进行处理。
- Tunnel前端集群：部署ODPS Tunnel服务进程的一组节点，用于数据上传和下载，会调用用户中心和Meta服务进行用户请求的鉴权，读写计算存储集群的数据。
- 命令前端集群：部署ODPS DDL/DML命令处理服务的一组前端节点，将DDL/DML操作命令转发给ODPS控制服务进行处理。
- 控制服务：处理前端发来的DDL/DML命令，对于DML，会进行SQL语法分析、查询优化和查询计划生成，通过提交给计算集群的分布式作业来完成物理执行计划。
- 用户中心：即UMM服务，负责管理整个阿里云和大数据平台的用户。
- Meta服务：ODPS采用OTS作为自己的Meta存储服务，负责管理ODPS对象的元数据，包括Project信息，表数据（Table）的schema及其数据存储在飞天集群上的路径，数据在不同飞天集群上的版本信息，用户UDF的元数据信息等等。
- 计算集群：用于存储和计算的飞天集群，存储所有的数据和UDF程序，所有的DML命令会解析为一个飞天的分布式DAG（有向无环图）作业提交给计算集群来执行。飞天集群最核心的模块包括盘古（Pangu）和伏羲（Fuxi），盘古是一个分布式文件系统，Fuxi负责资源和作业调度管理。
在这个方案中，主备机房各有一套ODPS服务，它们共享同一个用户中心（UMM）和Meta服务，UMM和OTS都具备各自双机房容灾能力，具体详见它们的容灾方案。
3.2 跨机房数据异步复制工作原理
我们再来看下跨机房数据异步复制工作原理：
- 在正常工作状态下，主机房的ODPS提供服务，备机房的ODPS没有服务请求，上层数据业务都只通过两个服务域名使用ODPS：
- ODPS服务域名：指向命令前端集群的虚拟IP，即系统架构图中的VIP2。
- Tunnel服务域名：指向Tunnel前端集群的虚拟IP，即系统架构图中的VIP1。
- ODPS通过数据异步复制机制，由主机房的Replication Service不断将主机房的ODPS数据同步到备机房的计算集群，ODPS引入数据版本的机制：
- 同一份数据（表或分区）在多个计算集群上可能具有不同的版本，ODPS Meta服务会维护每份数据的版本信息，表示如下：
{"LatestVersion":*V1*,"Status":{"ClusterA":"*V1*","ClusterB":"*V0*"}} |
- 当一份数据版本更新后，触发一个分布式的跨集群数据复制任务，将数据复制到其他计算集群，通过对复制任务的限制可以进行机房间数据复制流量管控。
- 对于ODPS这种大规模离线数据处理系统来说，数据加工往往有突发的情况，在某个时间段产出的数据量可能非常大，受限于机房间的带宽，新上传的和新计算的数据复制到备机房需要一定的时间，ODPS提供实时查看当前未同步的数据表/分区，实时的容灾数据同步率等信息，实时数据同步率主要取决于两个因素的影响：
- 机房间带宽大小；
- 主机房ODPS计算集群繁忙程度。
因为数据复制也是以飞天分布式任务来进行的，需要用到主机房的ODPS计算集群的计算资源（主要是CPU和内存），ODPS可以根据这两个因素给出数据同步完成的时间预估。
考虑到集群间带宽，存储等资源的竞争， 需要用户自行选择是否创建容灾project。通过ascm/dtcenter创建project时，可以选择创建单集群project，也可以选择创建多集群project。其中单集群project不支持容灾功能。
容灾project配置：
- 通过ascm/dtcenter创建多集群project之后，默认主备集群不会进行数据同步，需要通过bcc页面配置开启数据同步（maxcompute模块下 -> 运维菜单 -> 业务运维 -> 项目管理 -> 项目列表）。
图6
- 客户某个project的资源复制配置:
图7
配置项说明，开启资源复制后，以下配置才能生效。
- SyncObject:配置同步的集群，以及同步数据类型，参照上图将ODPS集群名修改为现场主备集群名称即可开启ODPS数据完全复制。
- ScanMetaInterval：数据同步间隔，单位为秒。
- EnableEvent：数据是否实时同步，配置为true时，当主集群数据产生变化，会立刻同步到备集群，同时ScanMetaInterval配置将失效。
注：配置数据同步为实时同步或数据同步间隔配置时间较短会较大程度占用网络带宽，建议当需要同步的数据量较大时，关闭实时同步并调大同步间隔。
- 容灾复制风险和实践说明：
- 如上一节提到的 EnableEvent 如果设置为true，那么project中的数据会在被更改后立刻触发同步，并且每次同步的数据量为该表或该分区的全部数据量。例如：某非分区表中有1T的数据，如果对该表插入1条数据，就需要将这1T的数据都复制到备机房。 如果1分钟内写了10次数据，那一分钟就会复制10次1T的数据到备机房，从而产生9T的待回收数据。混合云上强烈建议关闭实时复制，以减少机房间的带宽和存储压力。改为定时复制的策略，比如设置ScanMetaInterval，6小时一次扫描复制一次。 EnableEvent = false ScanMetaInterval=21600 #6小时=21600秒
- 为防止高峰时段ODPS占满集群带宽，可以在adminconsle->跨集群复制全局配置，这里限制ODPS集群间复制的流量带宽，单位是Gb，下图示例:
图8
从具体的备机房往主中心复制作业日志截图中可以看到，集群的名字是大写，而客户在资源复制同步中设置的sourceLocation中是小写,客户侧存在错误配置的问题。
图9
和ODPS的研发同学沟通确认了这个问题的root cause是ODPS的replicationService在发起项目数据异步复制时会拿SyncObject的集群通过ots来校验备用集群对应的project的版本号。这里将大小写不同认为是备机房该项目不存在，于是发起了同步，但是在数据落地存储的时候有数据校验并不会把这些真正存储起来。于是带来了不必要的网络开销，但并不会影响数据质量。
通过bcc修改资源配置，将SyncObject中集群改为大写，并重启ODPS的replicationService后问题得到彻底解决。
图10
4. 问题结论
ODPS主备集群做数据复制同步带宽被打满，root cause是ODPS project资源复制中的集群名是小写，而ODPS project集群的名称是大写，数据同步的时候会认为该project不存在，导致了双向同步，通过测试也验证了这一点。该问题已经通过bcc批量更正项目名中集群信息为大写，同时重启replicationService解决。
需要特别注意：客户在bcc中项目资源复制配置中需要注意保持同步数据集群名字大小写和集群名字匹配。
通过这次问题排查可以很好地了解到当前的ODPS多机房的数据同步方案和多机房的技术容灾架构。
我们是阿里云智能全球技术服务-SRE团队，我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队；提供专业、体系化的SRE服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术，您可用钉钉扫描下方二维码，加入阿里云SRE技术学院钉钉圈子，和更多云上人交流关于云平台的那些事。