547
技術社區[雲棲]
MaxCompute(ODPS)大數據容災方案與實現（及項目落地實例）專有雲
一，背景與概述複雜係統的災難恢複是個難題，具有海量數據及複雜業務場景的大數據容災是個大難題。
MaxCompute是集團內重要數據平台，是自主研發的大數據解決方案，其規模和穩定性在業界都是領先的。在周邊係統眾多，業務場景複雜，海量數據存儲和計算調度都是一個難題的情況下，需要保證大數據係統在災難發生時能夠盡快切換到備用係統服務，最小限度影響客戶使用。
容災係統及方案的建設有很多種方式，如同城雙活，異地多活，冷備容災等。MaxCompute大數據的容災方案是在多年集團內部斷網演練基礎上，依據MaxCompute卓越具有前瞻性的設計形成的，選用了同城異地雙活方案，並經過詳細的係統修改及優化，部署測試，多輪演練，達到了客戶現場輸出的成熟度。
本文詳細介紹了MaxCompute在專有雲輸出背景下依托現有技術及技術改造而形成的大數據容災原理，技術方案，操作步驟，及相關RPO與RTO設計，還有一些在大數據容災係統設計，實現，演練及部署過程中的思考，這裏貢獻給大家。
二，大數據容災技術方案
2.1，MaxCompute容災原理
MaxCompute的大數據容災技術方案是基於現有係統架構，數據管理及運維特點形成的，主要依據MaxCompute目前現有技術與實現方案：多地域多控多計算集群支持， 統一元數據中數據版本管理， 跨集群複製與同步。
多地域多控多計算集群支持：
MaxCompte從係統架構上支持異地多機房環境下的多控製集群和多計算集群架構，在滿足一定帶寬及網絡延遲要求條件下，MaxCompte服務能夠從邏輯上管理同樣功能的控製集群，並選擇其中一個異地主控集群。且能夠支持對單個項目空間進行多個計算集群配置，讓同一個項目空間邏輯上擁有多個數據存儲與計算的集群。即從係統設計開始，MaxCompute就沒有區分地理上的控製集群和計算集群，可以對滿足一定帶寬和網絡延遲條件下的異地集群同等對待，並能夠做到從用戶項目空間映射管理上管理異地集群，具備多集群統一調度能力。
統一元數據中數據版本管理:
MaxCompute在多計算集群部署時，同一份數據（表或分區）在多個計算集群上可能具有不同的版本，MaxCompute Meta服務會維護每份數據的版本信息，表示如下：
{"LatestVersion":*V1*,"Status":{"ClusterA":"*V1*","ClusterB":"*V0*"}項目空間數據跨集群複製與同步:
MaxCompute中的的項目空間支持多個計算集群的配置，並且在元數據中有關於多個集群中每一份數據的版本信息，為了便於數據管理交互和計算，為了統一進行數據資源和計算資源的調度管理，MaxCompute設計並實現了項目空間中數據的跨集群複製與同步功能。
MaxCompute中當一份數據版本更新後，會觸發一個分布式的跨集群數據複製任務，將數據複製到其他計算集群。 也可以針對項目空間中的數據進行統一的數據複製配置，如數據複製的內容及範圍，頻率及規則。同時跨集群複製同步也，通過對複製任務數的限製可以對機房間數據複製流量進行控製，用以從策略和方式上影響數據分布狀態。
MaxCompute容災基於以上三個係統特點和實現，從邏輯上確保服務能夠支持多個邏輯集群，同一個項目空間能夠跨集群管理，從物理上可以對同一份數據進行異地多機房存儲與同步，並通過統一的數據同步方案進行數據同步管理和調度。在元數據容災的基礎上，形成了一套MaxCompute大數據容災方案，該容災方案依賴於數據的異地存放與元數據版本管理，服務運行中的數據狀態如下圖所示：
2.2，整體部署方案
主備機房中都會部署一套完整的MaxCompute服務（控製集群、計算集群、tunnel，MaxCompute前端）；
- 主備機房中的MaxCompute服務形成雙控製集群雙計算集群係統，對外提供統一接口，提供MaxCompute服務。
- 主機房及備用機房的MaxCompute服務均能夠正常服務，但平時備用機房MaxCompute服務處於靜默狀態，由主機房提供服務。
- 主備機房的MaxCompute服務都打開數據複製功能，由主機房的Replication Service提供數據複製，按照複製策略定時或者按照數據請求將主機房數據同步至備用機房。
對於這個方案，主備機房各有一套MaxCompute服務，模塊說明如下：
在正常工作狀態下，主機房的MaxCompute提供服務，備機房的MaxCompute沒有服務請求，上層數據業務都隻通過兩個服務域名使用MaxCompute：
-
MaxCompute服務域名：指向命令前端集群的虛擬IP，即係統架構圖中的VIP2
-
Tunnel服務域名：指向Tunnel前端集群的虛擬IP，即係統架構圖中的VIP1MaxCompute通過數據異步複製機製，不斷將主機房的MaxCompute數據同步到備機房的計算集群，MaxCompute引入數據版本的機製。
2.3，容災切換方案
-
容災切換
容災切換分計劃內和計劃外，對於計劃內的切換，查看數據實時同步狀態，選擇某個已經完全同步的時刻進行容災切換，這樣RTO會非常短（分鍾級），RPO為當前時刻，不需要回補數據。除了選擇執行的時間點外，計劃內和計劃外的容災切換流程是一致的。
主備容災切換流程如下：
- 停掉主機房的VIP1和VIP2，主機房的MaxCompute服務不再接受新請求。
- 完成MaxCompute服務依賴係統如用戶中心UMM和Meta存儲服務OTS的雙機房容災切換。
- MaxCompute控製集群切換及MaxCompute計算集群切換
- MaxCompute服務切換後數據異常（本數據異常僅包括已製定數據同步方案而因故障未進行同步的數據）梳理及補數據操作
- 數據檢查
對於在數據同步複製過程中發生主集群故障的數據，此時數據狀態如下圖所示，需進行複製同步狀態檢查及恢複操作。 MaxCompute依托大數據管家進行集群和服務運維，在大數據管家中開發了支持（Resource/volume/table）的未同步數據狀態檢查及元數據修複。
對於計劃內的切換，UMM和OTS不會有數據丟失，且RTO為0，對於計劃外的切換，可能有短暫時間內的數據丟失，通常是秒級，對於MaxCompute這樣的離線大規模數據處理係統，忽略這段短暫時間內meta數據丟失的影響。
- MaxCompute提供工具掃描Meta數據，生成一份未同步的數據表或分區的列表。
- MaxCompute提供工具直接操作Meta數據，將未同步的數據表或分區drop掉，避免備機房MaxCompute服務起來後數據不正確。
- 啟用備機房的VIP1’和VIP2’，切換MaxCompute服務域名和Tunnel服務域名到新的VIP，至此備機房的MaxCompute服務恢複，接受請求。
- 上層數據業務根據未同步的數據表或分區列表，進行數據重新導入和重新計算。至此數據恢複完成，可以恢複上層數據業務。
2.4，MaxCompute係統改造以支持大數據容災
在實現整合Maxcompute容災方案過程中，以及測試過程中，對現有實現中很多邏輯進行了優化和處理，並和相關依賴係統同步改造，完成Maxcompute大數據平台的容災方案並測試驗證通過，交付客戶現場部署, 主要有：
- 相關依賴係統如OTS，賬號係統UMM、AAS支持容災改造
- 控製集群服務切換邏輯改造
- 控製集群配置讀入與生效方式改造，使其能夠接受容災切換的請求並立即生效
- 相關管理Admintask支持多種數據檢查功能
- 跨集群複製服務切換及切換後狀態檢查改造
- Resource數據同步方案
- 多控多計算在升級和新部署場景下的部署工具改造
- 大數據管家增加容災切換，數據檢查功能與接口
- MaxCompute部署底座支持VIP及域名切換功能
- ......
三，RPO與RTO
對於MaxCompute這種大規模離線數據處理係統來說，數據加工往往有突發的情況，在某個時間段產出的數據量可能非常大，受限於機房間的帶寬，新上傳的和新計算的數據複製到備機房需要一定的時間，MaxCompute提供實時查看當前未同步的數據表/分區，實時的容災數據同步率等信息，實時數據同步率主要取決於兩個因素的影響：
- 機房間帶寬大小
- 主機房MaxCompute計算集群繁忙程度
因為數據複製也是以飛天分布式任務來進行的，需要用到主機房的MaxCompute計算集群的計算資源（主要是CPU和內存），MaxCompute可以根據這兩個因素給出數據同步完成的時間預估。
數據中心災難恢複流程，主要圍繞兩個指標RPO和RTO，借下圖來說明MaxCompute容災方案的細節：
MaxCompute的多控製、多計算集群的架構天然的支持高可用和數據容災場景，在機房或集群遭受不可恢複性破壞時，確保數據不會丟失，業務不受影響。
MaxCompute是典型的離線計算平台，需要支持大量數據的寫入操作，隻能選擇異步複製。
- RPO恢複點目標：
- RTO恢複時間目標：
容災配置及部署對RPO/RTO的影響
- RPO時間要求配置Resource、Table， Volume 的同步周期。
- RPO（RecoveryPointObjective）影響範圍通過數據檢查掃描得到的Resource、Table， Volume未同步列表體現
- 大數據管家手動操作完成（控製集群切換 + 計算集群切換 + 數據檢查完成 + Meta數據修補） + 用戶使用上層業務係統補數據完成 = 切換完畢
- RTO （RecoveryTimeObjective） = 災難決策 + 技術恢複（MaxCompute依賴係統及服務恢複 + MaxCompute服務恢複 + 數據檢查與恢複）
四，項目落地實例
本容災方案已經經過多輪內部演練，達到了產品輸出的成熟度要求，在阿裏雲專有雲底座部署的基礎上，該方案已經在內部多輪數據同步驗證，服務切換演練驗證，數據檢查驗證，能夠做到災難場景下的服務切換，達到了係統設計目的，能夠做到容災方案對客戶影響降到最低。
MaxCompute容災方案和實現是阿裏雲專有雲輸出中係統能力重要一部分，支持了多個專有雲版本。已經在政通專有雲中依據目前容災方案部署完畢，並能夠平滑切換到新的專有雲版本。做到了不同版本的專有雲中係統能力的兼容和延續性。目前部署後的主備集群工作正常，數據同步正常。
控製集群切換（容災模式）
計算集群切換（容災模式）
未同步數據檢查
五，一些思考
1, 正向切換和反向切換
正切和回切方案是一樣的，MaxCompute數據異步複製係統隻根據計算集群的數據版本來做數據複製，當切換到備機房後，備機房的數據版本會更新，數據會從備機房複製回原來的主機房，從而完成數據的同步。
所以，回切的步驟和正切的步驟一致。但需要等待數據從備用機房同步到主機房完成後做默認計算集群切換，不然會造成兩邊數據不一致問題。
2， MaxCompute容災方案建立在依賴係統容災的基礎上，依賴係統服務狀態對MaxCompute容災及功能使用非常重要，在做方案過程中，需要綜合考慮整體服務級的容災方案，不僅著眼與MaxCompute係統本身，對其依賴係統容災方案，冗餘配置，服務狀態，數據狀態都需要通盤考慮。
3，大數據服務容災是典型的分布式係統容災方案涉及到係統間協調，主要考慮點為數據狀態，服務狀態切換，在災難發生時最大程度保護重要數據，盡快使服務恢複，對客戶影響降到最小。
4，係統設計的前瞻性對容災方案及最終落地方案影響很大，客戶業務狀況對容災場景和方案設計及實現影響很大。
5，大數據容災部署狀態及災難發生後的容災切換隻是係統能力中的一個，更多的工作在於從業務層麵合理分配數據資源，係統設計層麵支持容災能力，容災切換和操作過程中準確判斷係統及數據狀態，是一個需要客戶和服務提供商也就是Maxcompute平台團隊共同麵對的問題。
6，容災方案都有一定的場景限製，本大數據容災方案集中討論了在異地單機房故障情況下容災切換能力，對於上層業務係統適配鏈接使用多地MaxCompute服務沒有闡述。這一點上也需要服務提供方和客戶方共同參與，協調溝通最符合業務場景的大數據容災方案與項目實踐。
最後更新：2017-04-14 13:32:07