簡介：ODPS主備集群雙向數據復制導致主備中心網絡打爆問題

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的待回收數據?；旌显粕蠌娏医ㄗh關閉實時復制，以減少機房間的帶寬和存儲壓力。改為定時復制的策略，比如設置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技術學院釘釘圈子，和更多云上人交流關于云平臺的那些事。

原文鏈接：https://developer.aliyun.com/article/796081?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。 與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的ODPS主备集群双向数据复制导致主备中心网络打爆问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。