简介：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服务会保护每份数据的版本信息，示意如下：        
<span class="lake-fontsize-12">{"LatestVersion":V1,"Status":{"ClusterA":"V1","ClusterB":"V0"}}</span>
当一份数据版本更新后，触发一个分布式的跨集群数据复制工作，将数据复制到其余计算集群，通过对复制工作的限度能够进行机房间数据复制流量管控。1. 对于ODPS这种大规模离线数据处理系统来说，数据加工往往有突发的状况，在某个时间段产出的数据量可能十分大，受限于机房间的带宽，新上传的和新计算的数据复制到备机房须要肯定的工夫，ODPS提供实时查看以后未同步的数据表/分区，实时的容灾数据同步率等信息，实时数据同步率次要取决于两个因素的影响： 机房间带宽大小； * 主机房ODPS计算集群忙碌水平。因为数据复制也是以飞天分布式工作来进行的，须要用到主机房的ODPS计算集群的计算资源（次要是CPU和内存），ODPS能够依据这两个因素给出数据同步实现的工夫预估。思考到集群间带宽，存储等资源的竞争， 须要用户自行抉择是否创立容灾project。通过ascm/dtcenter创立project时，能够抉择创立单集群project，也能够抉择创立多集群project。其中单集群project不反对容灾性能。容灾project配置：1. 通过ascm/dtcenter创立多集群project之后，默认主备集群不会进行数据同步，须要通过bcc页面配置开启数据同步（maxcompute模块下 -> 运维菜单 -> 业务运维 -> 项目管理 -> 我的项目列表）。图61. 客户某个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技术学院钉钉圈子，和更多云上人交换对于云平台的那些事。> 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。