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的待回收資料。混合雲上強烈建議關閉實時複制，以減少機房間的帶寬和存儲壓力。改為定時複制的政策，比如設定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技術學院釘釘圈子，和更多雲上人交流關于雲平台的那些事。