簡介：ODPS主備叢集雙向資料複製導致主備中心網路打爆問題
1. 故障問題描述
客戶現場發生了ODPS主備機房相互資料全量複製導致的主備中心網路被打爆的問題，嚴重影響了日常執行的ODPS任務。在ODPS主備機房的環境中，使用者的任務均在主機房中執行，產生的資料預設會落在主機房，通過ODPS replicationService將主機房的資料非同步複製到備用機房。那麼為什麼會有反向同步到主機房資料的情況，需要對該問題開展排查進行根因分析。
2. 故障現象
在排查過程中觀察關閉資料前後的機器網路負載狀態，當開啟資料主備複製的時候，機器的網路卡的進出流量很大。
繼續排查發現主機房複製作業和備機房複製作業都在執行，而且很多都是沒有更新的資料表，這種沒有必要的全量資料同步造成大量的網路開銷。
圖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服務會維護每份資料的版本資訊，表示如下：
| <span class="lake-fontsize-12">{"LatestVersion":V1,"Status":{"ClusterA":"V1","ClusterB":"V0"}}</span> |
圖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技術學院釘釘圈子，和更多雲上人交流關於雲平臺的那些事。
> 版權宣告：本文內容由阿里雲實名註冊使用者自發貢獻，版權歸原作者所有，阿里雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。