DataOps 助力容量管理-Project 遷移優化應用實踐

Maxcompute（原ODPS）是阿里唯一的自研大數據平台，平台承載了不可丟失的交易數據。內部是一個邏輯統一大數據池， EB級數據透明的相互依賴。但其在物理上卻是橫跨多地域龐大數量構成的集群組合. 這在容量問題上面會帶來物理資源瓶頸無法滿足業務需求的巨大挑戰。

——對於集群(cluster)，存在計算、存儲、文件數等多個維度的資源，集群間存在通信的帶寬資源，帶寬成本因集群間的距離而不同；

——對於應用(project)，各個應用對不同維度的資源的消耗存在差異，對於計算資源的消耗，存在很強的時段差異性；

——此外應用之間存在數據訪問依賴，會消耗集群間的帶寬資源。隨著業務的日益發展，集群個數和規模在不斷擴大，應用間的依賴也愈發複雜。

我們要解決的問題

當任何一個集群計算、存儲、文件數資源達到瓶頸都會對集團的業務造成影響，同時降低其他資源的使用效率，這就引發了Maxcompute的容量管理問題。目前對於容量問題主要有兩大解決方案。

通過採購機器進行擴容，這要求我們對集群未來的資源消耗做出精準的預測，做出合理的採購預算；

優化 Maxcompute 應用在不同集群的排布，包括全局排布優化和局部遷移策略的優化。所謂全局排布優化，相當於將線上應用全部打亂，重新在各個集群間進行分配。

而局部遷移策略優化，是針對那些資源遇到瓶頸，穩定性可能受到影響的集群，提前做出應用的調度。受限於應用遷移的自動化程度、遷移效率、實際業務情況，全局排布優化的工程化實施還有一定困難。

當前我們在採購預算和局部應用遷移兩個方面都取得了一定的進展，本文將詳細解讀如何利用數據+演算法的方案來解決局部應用遷移優化的策略。

1 人工決策的經驗沉澱與局限

過去Maxcompute中應用的遷移強依賴於運維人員的經驗，運維人員對各個維度資源的「危險水位」有著一定的敏感度，基於對各個業務的了解，在某個集群某個維度的資源到達危險水位時，制定出一些應用（project）的遷移方案。 但人工決策存在很多局限：

集群的資源維度多，運維人員每天需要花大量的時間查看監控指標，但依舊可能遺漏或未能及時發現遷移需求。

線上的project眾多，每個project也有多維的屬性，project之間因為業務因素存在不同強度的數據依賴，人工很難全面考慮各個因素做出最優的遷移決策，運維人員通常根據業務歸屬，從較粗的粒度制定遷移計劃。

project的遷移會牽一髮而動全身，帶來各個層面的影響。

在遷移策略真正執行之前，人工難以準確地預估和量化這些影響，通常為了防止遷移後接受集群的資源不足或者出現集群間帶寬被承包，運維人員作出的遷移計劃一般較為保守。

2 DataOps數據驅動引入新思路

運維人員的資源調度經驗十分寶貴，但作為大數據計算平台的建設和服務者，我們應該把握好數據這一利器，充分利用數據進行決策，突破人工運維存在的一些瓶頸。

遷移需求的及時甚至提前感知

最優Project遷移策略的精細化求解

遷移結果的準確量化評估。

3 優化演算法設計思路

3.1 整體解決方案設計

整體解決方案主要分為三個步驟：

集群層面的遷移需求判定和量化 即確定哪些集群需要遷移，各項資源需要遷移多少量；那些集群可以接收遷移，各項資源的容納能力是多少。

線性規劃求解最優遷移策略 這一步的目的是挑選出最合適的project遷移到最合適的集群。

遷移影響的量化估計：分析本次遷移對集群資源水位和帶寬消耗會產生什麼影響，因為現實場景較複雜，存在跨集群複製等問題，有些影響需要得到遷移策略後，根據新的project排布才能模擬計算出影響的大小。

量化影響的目的是給運維人員一個圖形化的直觀展現，特別是演算法運行初期，可以幫助運維人員判斷演算法的可行性。

3.2 集群層面的遷移需求判定和量化

在Maxcompute當前線上每個集群的伺服器規模、計算和存儲能力及彈性均不相同。

因此我們結合運維人員的專家經驗以及集群歷史運行情況，為每個集群的每項資源均設定了個性化的「需遷移水位」和「可接收水位」。

其次，Maxcompute的資源使用存在明顯的「高峰時段」，在量化遷移需求時，我們主要考慮高峰時段的水位，結合集群資源總體容量進而可以得到具體的需遷移量和可接收量。

另外，存在所有待遷移集群的需求超過所有可接收集群的能力的情況，此時表明平台整體有擴容需求，但由於採購需要一段時間，因此演算法會根據接收能力調整遷移需求，產生臨時性的遷移方案，以解決眼前線上的問題。

3.3 線性規劃優化問題定義和求解

問題分析 ：

當我們確定了集群層面的遷移需求和接收能力後，需要從待遷移集群的眾多project中選擇最佳的遷移方案。這個遷移方案需要考慮以下幾點：

既需要滿足各個待遷移集群計算、存儲和文件數的遷移需求，也不能超過接收集群各項資源的容納能力。

與存儲和文件數不同，由於project的計算資源消耗具有很強的時段性，因此對於計算資源需要細化到小時粒度考慮。

前面提到應用間存在數據訪問依賴，將消耗集群間的帶寬，且位於不同地域的集群間帶寬成本不同。project的遷移應盡量控制集群間的帶寬消耗。

上面的過程可以表述成一個帶約束條件的優化問題，且約束和目標函數均是線性的。線性規劃是最著名的解決最優化問題的方法之一。典型的線性規劃問題的標準形式如下：

線性規劃問題定義

我們的問題中，決策變數x是某個project是否要從集群A遷到集群B，若遷，則x為1；不遷則為0。

即決策變數是01變數，因此這個線性規劃問題其實是01整數規劃。目標函數中我們考慮了機房間的距離（帶寬成本）以及應用間的數據依賴。

約束條件中我們考慮待遷移集群各項資源的遷移需求和可接收集群的接納能力。

（以下為節選約束和變數說明）

求解

解決線性規劃問題的方法有很多，如單純形法、內點法等，也有很多的科學計算工具可以使用，如matlab、scipy等。還有很多優化求解器可以高效地解決大規模線性規劃、混合整數規劃等相關問題，如Cplex、Gurobi等等。

4 遷移影響的量化估計

project遷移對集群的影響可以幫助運維人員直觀地看到本次遷移的效果和影響，具體可以分為三大部分進行分析。

對存儲和文件數水位的影響

由於project的數據量和文件數大小是相對穩定的，因此遷移方案對於集群存儲和文件數水位的影響相對容易確定。

對計算資源水位的影響

project的計算資源消耗有很強的時段性，不同project的計算資源消耗模式具有很大差異，我們將遷移列表中每一個project的CPU消耗都均攤到了運行時間段內的每一個小時，進而估計遷移後集群24小時CPU水位變化。

對集群間流量大小的影響

在前面的線性規劃問題中，我們將project之間的數據依賴放到了目標函數中進行優化，而不是放到約束條件中。

原因在於，根據project之間的數據依賴以及當時的project的集群排布情況，線上每天會根據較複雜的一些規則產生一份跨集群複製列表，將原本需要跨集群直讀的數據轉化為集群內部的讀取。

因此，在遷移策略真正產生之前，我們無法預估線上集群間的流量。而在我們的線性規劃問題求解出遷移策略後，我們需要根據規則和新的project排布模擬出新的跨集群複製列表，再根據線上歷史真實流量情況估計本次project遷移帶來的機房間流量變化。

5 應用效果

智能遷移功能讓運維人員對於每次的遷移任務都擁有量化的精準評估，以及可視化的直觀感受。

在該平台上，運維既可以看到平台根據當前各個集群水位動態計算出來的遷移方案，也可以輸入一些個性化的遷移需求和約束，來定製一套最優的遷移策略。通過作業平台的並行調度，平台支持多個運維人員同時操作和計算。

對於每個遷移需求，詳細求解並展示出結果：

（1）演算法得到的具體最優遷移策略

（2）預計遷移前後集群計算和存儲資源水位變化

（3）預計遷移前後集群間流量變化

（4）預計遷移前後跨地域帶寬使用率變化

小結

Project 遷移優化是面向大數據離線業務用 DataOps 驅動實現容量管理資源排布的一次智能化落地的技術探索。演算法模型中綜合多個維度的資源因素，可以在給定的約束條件下找到最優的遷移策略，同時可以量化遷移帶來的影響。

當然這僅僅是起步，我們仍在持續投入優化策略：嘗試利用機器學習和時間序列分析方法對集群的資源消耗進行預測以指導機器的採購，幫助我們提前感知遷移需求及早做出遷移計劃，下期我們將帶來如何實現資源消耗預測的策略，敬請關注。

第十屆 GOPS 報名火熱，GOPS 2018 · 上海站，運維的寶寶們了解下！

GOPS 2018 · 上海站視頻精彩預覽 ??

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！