簡介：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服務會維護每份資料的版本資訊，表示如下：