简介：ODPS 主备集群双向数据复制导致主备核心网络打爆问题

1. 故障问题形容

客户现场产生了 ODPS 主备机房互相数据全量复制导致的主备核心网络被打爆的问题，重大影响了日常运行的 ODPS 工作。在 ODPS 主备机房的环境中，用户的工作均在主机房中运行，产生的数据默认会落在主机房，通过 ODPS replicationService 将主机房的数据异步复制到备用机房。那么为什么会有反向同步到主机房数据的状况，须要对该问题发展排查进行根因剖析。

2. 故障景象

在排查过程中察看敞开数据前后的机器网络负载状态，当关上数据主备复制的时候，机器的网卡的进出流量很大。

图 1

持续排查发现主机房复制作业和备机房复制作业都在运行，而且很多都是没有更新的数据表，这种没有必要的全量数据同步造成大量的网络开销。

图 2

图 3

图 4

3. 故障起因剖析

在解决问题之前，咱们须要先搞清楚 ODPS 同城双机房容灾整体技术计划和其中的跨机房数据异步复制工作原理。

3.1 ODPS 同城双机房容灾整体技术计划

ODPS 产品利用中针对每一种场景的故障或者集群劫难，其故障复原或者服务切换计划都是不同的。该客户属于 ODPS 同城双机房容灾计划，咱们先看下 ODPS 同城双机房容灾整体技术计划。

1. 特点:

• • 主备机房均部署残缺的 MaxCompute 服务（管制集群、计算集群、tunnel、前端）。
  • 主备机房均能够失常应用，但失常状态下，备机房处于静默状态，不解决具体业务申请。
  • 主备机房之间开启数据传输，设置既定的策略定时或按需将数据同步到备机房。

1. 外围逻辑:

• • 元数据放弃同步复制；
  • 业务数据放弃异步复制；
  • RTO：能够实现分钟级；
  • RPO：视数据量及同步频率来定，个别为小时级。

1. 网络要求：

• • 元数据的同步提早要管制在 5ms 以内；
  • 业务数据的同步提早要管制在 20ms 以内。

图 5

1. 模块具体阐明如下：

• • 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 跨机房数据异步复制工作原理

咱们再来看下跨机房数据异步复制工作原理：

1. 在失常工作状态下，主机房的 ODPS 提供服务，备机房的 ODPS 没有服务申请，下层数据业务都只通过两个服务域名应用 ODPS：

• • ODPS 服务域名：指向命令前端集群的虚构 IP，即零碎架构图中的 VIP2。
  • Tunnel 服务域名：指向 Tunnel 前端集群的虚构 IP，即零碎架构图中的 VIP1。

1. ODPS 通过数据异步复制机制，由主机房的 Replication Service 一直将主机房的 ODPS 数据同步到备机房的计算集群，ODPS 引入数据版本的机制：

• • 同一份数据（表或分区）在多个计算集群上可能具备不同的版本，ODPS Meta 服务会保护每份数据的版本信息，示意如下：

当一份数据版本更新后，触发一个分布式的跨集群数据复制工作，将数据复制到其余计算集群，通过对复制工作的限度能够进行机房间数据复制流量管控。

1. 对于 ODPS 这种大规模离线数据处理系统来说，数据加工往往有突发的状况，在某个时间段产出的数据量可能十分大，受限于机房间的带宽，新上传的和新计算的数据复制到备机房须要肯定的工夫，ODPS 提供实时查看以后未同步的数据表 / 分区，实时的容灾数据同步率等信息，实时数据同步率次要取决于两个因素的影响：

机房间带宽大小；
* 主机房 ODPS 计算集群忙碌水平。

因为数据复制也是以飞天分布式工作来进行的，须要用到主机房的 ODPS 计算集群的计算资源（次要是 CPU 和内存），ODPS 能够依据这两个因素给出数据同步实现的工夫预估。

思考到集群间带宽，存储等资源的竞争，须要用户自行抉择是否创立容灾 project。通过 ascm/dtcenter 创立 project 时，能够抉择创立单集群 project，也能够抉择创立多集群 project。其中单集群 project 不反对容灾性能。

容灾 project 配置：

1. 通过 ascm/dtcenter 创立多集群 project 之后，默认主备集群不会进行数据同步，须要通过 bcc 页面配置开启数据同步（maxcompute 模块下 -> 运维菜单 -> 业务运维 -> 项目管理 -> 我的项目列表）。

图 6

1. 客户某个 project 的资源复制配置:

图 7

配置项阐明，开启资源复制后，以下配置能力失效。

SyncObject: 配置同步的集群，以及同步数据类型，参照上图将 ODPS 集群名批改为现场主备集群名称即可开启 ODPS 数据齐全复制。
* ScanMetaInterval：数据同步距离，单位为秒。
* EnableEvent：数据是否实时同步，配置为 true 时，当主集群数据产生变动，会立即同步到备集群，同时 ScanMetaInterval 配置将生效。

注：配置数据同步为实时同步或数据同步距离配置工夫较短会较大水平占用网络带宽，倡议当须要同步的数据量较大时，敞开实时同步并调大同步距离。

1. 容灾复制危险和实际阐明：

如上一节提到的 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 技术学院钉钉圈子，和更多云上人交换对于云平台的那些事。

> 版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。