摘要：本文結合華為CCE團隊在混合部署方面的研究和實戰，介紹了混合部署的背景、概念、混部技術的設計方案和實際落地情況，以及對未來的計劃和展望。
現代網際網路資料中心的規模隨著應用服務需求的快速增長而不斷擴大，但伺服器資源利用率卻一直很低，導致企業基礎設施成本不斷上漲。隨著雲原生技術的發展，混合部署成為了降低成本的一大手段。本文結合華為CCE團隊在混合部署方面的研究和實戰，介紹了混合部署的背景、概念、混部技術的設計方案和實際落地情況，以及對未來的計劃和展望。
雲原生與資源利用率現狀
雲原生概念在2013年由Matt Stine提出並沿用至今，經過不斷的總結完善，已經涵蓋了DevOps、持續交付、微服務、容器化等主題，成為一套完整的技術方法體系。通過構建易觀測、低耦合、容錯性高的系統來達成提高效率、加速創新、降低成本的目標。
隨著雲原生基礎技術日漸成熟，在提升效率和加速創新的目標上已經取得了顯著的成效。得益於效率提升的優勢，如今千行百業都在擁抱雲原生，Gartner報告指出，到2022年將有75%的全球化企業在生產中使用雲原生的容器化應用。同時伴隨著開源專案的不斷更新和逐步成熟，其加速創新的優點也促使各企業在AI、大資料、邊緣、高效能運算等新興業務場景不斷採用雲原生技術來構建創新解決方案。然而在降低成本的目標上，當前仍面臨著基礎設施成本高昂和資源利用率低下的問題。全球雲基礎設施服務支出保持千億美元的年增長，總體規模已經突破萬億美元大關，中國僅IDC業務在2019年就突破了千億大關，並保持30%的年增長率。根據Dell'Oro市場研究公司於2021年7月釋出的預測，未來五年伺服器支出將以11%的年複合增長率增長，到2025年將佔資料中心資本支出的近一半。《中國“新基建”發展研究報告》稱，到2025年，資料中心將佔全球能耗的最大份額，高達33%。另一方面，全球伺服器平均利用率不到20%，我國大多數資料中心的PUE普遍大於2.2。由此可見，雲基礎設施在降低成本上還有很大的提升空間。
圖 1 中國資料中心市場規模
2021年7月工業和資訊化部印發的《新型資料中心發展三年行動計劃（2021-2023年）》（簡稱“計劃”）提出，到2021年底，全國資料中心平均利用率力爭提升到55%以上，總算力超過120 EFLOPS，新建大型及以上資料中心PUE降低到1.35以下。到2023年底，平均利用率力爭提升到60%以上，總算力超過200 EFLOPS，新建大型及以上資料中心PUE降低到1.3以下。
為了幫助達成“計劃”的目標，這裡簡要分析資源利用率低下的原因，並基於HCE（Huawei Cloud EulerOS）制定一套行之有效的解決方案。
在離線混合部署的提出
造成伺服器資源利用率低的主要原因可以歸為兩大類：
1、不同型別業務分開部署在不同的資源池
為了避免業務之間的競爭影響到服務質量，不同型別的業務通常分開部署在不同的資源池。但業務的執行往往存在高峰期和低谷期，例如網購、社交一類的業務在白天的使用量明顯高於夜間，但版本構建、測試類的業務則主要集中在晚上執行。分開部署導致伺服器普遍存在空閒週期，很多業務空閒期遠長於高峰期，導致總體資源利用率很低。
2、服務預留資源與實際使用資源之間存在較大冗餘
企業通常採用過量供應資源的方式來保障服務質量，導致預留的資源量與實際的使用量之間存在較大的差距，下圖為推特資料中心管理系統30天內的CPU和memory資源預留和實際使用情況，CPU實際使用值在20%上下，但預留值卻接近80%，超出了實際使用值的三倍，記憶體預留則超出了實際使用值的1.5倍。
圖 2 推特資料中心資源利用率
基於以上原因，如果能夠將業務的波谷時段利用起來，就能減少波谷時間，從時間維度提升效能；同理，將資源預留冗餘縮小，就能從空間維度提升效能。因此將不同優先順序、不同波動週期的業務進行混合部署，為兩個維度提升利用率提供了可能性，即利用低優先順序任務佔用空閒資源，同時高優先順序任務能及時搶佔到資源，從而保證關鍵業務的服務質量。在離線業務在特徵上很好的滿足了上述條件，本文提到的混合部署特指在離線混合部署。
線上業務通常是處理使用者請求的服務，包含交易、購物、搜尋、網頁瀏覽等對於實時響應要求高、延時敏感的業務。離線業務通常是計算密集型的批處理任務，包含大資料分析、機器學習訓練、演算法運算、統計報告等優先順序較低、相應要求不高的業務。在離線任務的主要特徵如下表所示：
表 1 在離線業務特徵
從表1可以看出，在離線業務在很多特徵上具有互補性，將二者進行混合部署也已經成為資料中心提升整體資源利用率的主流方法。
方案設計
方案介紹
在離線業務混合部署對容器管理平臺提出了更高的要求，這些要求包括：
- 排程器需要同時支援線上任務和離線任務的排程，離線任務對排程器提出了更高的效能要求、更多的排程特性需求，比如大資料或AI任務需要支援gang-scheduling、binpack等。
- 工作節點支援同時執行線上和離線容器，在離線業務統一管理。
- 超賣特性支援，根據節點實時和預測的空閒資源進行排程，提升資源利用率的同時減少在離線執行干擾以達到單次排程最優。
- 多維度資源隔離與搶佔，確保離線任務充分利用空閒資源的前提下，支援線上任務對資源百毫秒級搶佔。
- 節點可觀測性增強，對在離線任務資源佈局動態優化，識別線上業務是否受到干擾，對干擾進行定位和控制。
- 叢集可觀測性增強，對叢集任務佈局動態優化，減少叢集資源使用不均衡問題。
基於Volcano混合部署解決方案如下圖所示：
圖 3 基於Volcano混合部署架構
Volcano混部排程能力
目前Kubernetes的預設排程器是以Pod為單位進行排程的，不區分Pod中執行的業務型別。因此無法滿足混部場景對資源分配的特殊要求。針對上述問題，Volcano實現了基於應用模型感知的智慧排程演算法，根據使用者提交的作業型別，針對其應用模型對資源的訴求和整體應用負載的情況，優化排程方式，通過資源搶佔，分時複用等機制減少叢集資源的空閒比例。
Volcano應用模型感知分為兩種：
1.作業型別感知：能夠識別線上作業和離線作業。
2.Pod型別感知：能夠識別作業中不同型別的Pod，例如Tensorflow作業中的PS和Worker，Spark作業中的Driver和Executor等。
針對作業型別感知，Volcano通過作業混合部署+資源超賣的方式，實現叢集資源利用率的提升，示意如下：
圖 4 混合排程超賣示意圖
資源超賣是指將叢集資源申請量與使用量的差值進行再次分配，進而提升叢集的資源使用率，參考如下方式進行：
圖 5 資源超賣示意圖
其中request-used為資源超賣部分，Volcano排程器會將這部分資源再次分配。由於超賣資源的穩定性不能保證，因此只能用於執行SLA較低的離線作業。
使用者提交多種型別作業時，Volcano進行統一排程，優先保證線上作業執行（如圖4所示）。當線上作業壓力較低時，意味著節點上物理資源的使用率較低，此時Volcano會進行資源超賣，將離線作業排程到相應的節點上執行。當線上作業壓力變大時，Volcano會驅逐掉當前節點上的離線作業，保證線上作業能夠正常執行。
針對Pod型別感知，Volcano根據應用模型對資源的訴求和整體應用模型本身執行的要求，進行優化排程。以Tensorflow作業為例，一個Tensorflow作業中包含若干PS Pod和若干Worker Pod，當PS Pod和Worker Pod能夠均勻分配時，TF作業的執行效果更優。例如，對於一個包含2個PS Pod和4個Worker Pod的TF作業，預設排程器和Volcano對比如下：
圖 6 作業型別感知排程
可以看出，在資源充足的情況下，預設排程器會出現PS Pod和Worker Pod分別被排程到不同節點的情況，Volcano能夠保證將1個PS Pod和2個Worker Pod排程到一臺節點上，從而提升作業整體執行效率。
目前K8S提供的預設排程器，僅根據節點資源請求數量排程Pod。該方式並未考慮到節點實際資源使用情況，可能會出現各個節點資源申請率相同，而實際負載差別較大的情況。對於高負載的節點，可能會導致應用響應速度變慢，無法滿足SLA。對於低負載的節點，則存在資源浪費的情況。
針對該問題，Volcano提出了基於節點物理資源使用率的預測及排程功能，提供以下三方面的能力：
1.預測排程：接入叢集監控系統，根據節點及Pod歷史資源使用率，預測未來節點及Pod資源使用率的變化趨勢，根據預測結果進行合理排程。
2.負載均衡排程：根據叢集各節點當前負載情況，結合未來使用趨勢的預測，將pod排程到使用率較低的節點，進而提升整個叢集資源使用的均衡性。
3.資源搶佔排程：節點資源不足時，排程器實時驅逐部分離線作業，保證線上作業的資源使用。
節點管理
混合部署的節點管理主要包括兩個部分，一是資源配置管理，二是干擾控制管理。資源配置元件主要負責在pod建立時配置相關的優先順序用於資源隔離。干擾控制元件主要負責在容器執行時動態檢測異常並進行相關處理。
圖 7 cgroup控制層級
雖然kubernetes支援多種QoS型別的Pod，如Guaranteed、Burstable和BestEffort，但是這些型別並不能和在離線任務直接對應。HCE通過新增cgroup介面來控制pod的優先順序，如cpu cgroup下的cpu.qos_level用於控制當前Pod對CPU資源搶佔的優先順序。當前通過kubelet執行相關配置操作，保證Pod各資源配置的一致性。
資源超賣及在離線作業混部必然會導致不同作業之間的相互干擾，因此除了通過cgroup進行資源隔離之外，kubelet同時會實時採集節點上物理資源使用率，根據不同的情況驅逐離線作業，提前釋放相應資源，防止對線上作業的SLA產生影響。
節點資源隔離
資源隔離技術涉及的資源包括CPU、記憶體、網路和IO等等，針對每一種資源，需要結合已有隔離技術來應對混合部署場景下的新需求。在離線混合部署對資源的需求可歸納為兩點：對於資源分配情況優先供應給線上任務，對於資源回收情況優先從離線任務回收資源。
對於CPU資源，目前核心已經提供豐富的隔離和頻寬控制技術，例如排程類、排程策略、程式優先順序、cpu.shares等，但這些技術並非為混合部署設計，使用上存在如下一些問題。
- 排程類：不同的排程類優先順序不同，並且支援快速搶佔，這一特點和混合部署的需求吻合。但由於系統程式執行在CFS類上，離線任務就只能用優先順序更低的IDLE排程類，而IDLE排程類不能用於普通程式排程，因此不能通過設定不同排程類來支援CPU搶佔。
- 排程策略：CFS支援多種排程策略，不同策略優先順序也不同，這也是混合部署所需要特性。由於通用程式執行在SCHED_NORMAL策略，因此離線任務可以選擇優先順序更低的SCHED_BATCH或SCHED_IDLE策略。使用排程策略的關鍵問題是沒有提供cgroup控制介面，使用者無法通過cgroup配置Pod的排程策略。
- 權重（優先順序&cpu.share）：程式優先順序和cpu.shares通過虛擬時間片來控制CPU權重，只能保障總體執行時間比例，本質上屬於公平排程的範疇，不能保障線上程式實時搶佔離線程式。
HCE目前的做法是在SCHED_IDLE上進行修改以滿足離線程式排程：
- 新增cgroup介面cpu.qos_level來控制Pod中所有程式的優先順序。
- 引入throttle機制對離線任務進行進一步壓制，使得線上任務能夠獨佔CPU。
- 增加kill boost機制避免當線上業務100%佔用CPU時，殺死離線任務無法釋放資源的問題。
- 對線上任務進行高負載檢測，超時後對核心態離線任務放行，防止離線程式在核心態發生優先順序反轉導致系統假死。
在記憶體資源方面，HCE通過如下能力支援記憶體分級保障：
- 新增cgroup介面memory.qos_level來控制Pod優先順序。
- 分級回收：通過記憶體回收水位分級和OOM回收分級來保障線上任務記憶體需求。
- kill快速回收：該技術可以使得分配記憶體觸發大量離線任務OOM的情況下仍能具有較高的記憶體分配效能。
- 頁快取限制：避免因page cache使用過多導致記憶體不足從而影響業務功能。
網路資源原生可以使用TC HTB規則控制優先順序，但該方法配置繁瑣，規則數量增加時會導致效能損耗變大，對於線上小報文離線大報文情況，線上任務效能會受到干擾。
HCE對此提出以下網路隔離優化機制：
- 基於eBPF和EDT技術實現動態限速分配策略，根據業務優先順序自動調整頻寬，實現per-cgroup級別的頻寬隔離。
- 網路頻寬優先順序搶佔機制，當線上業務佔用頻寬比較低時，空閒頻寬能夠分配給離線業務使用；而當線上業務需要更多頻寬時，能夠迅速（<100ms）將頻寬從離線業務上搶佔回來。
- 對離線業務提供最低頻寬保障，避免飢餓導致的業務中斷。
落地效果
CPU隔離效果
這裡使用CloudSuite驗證CPU隔離效果，使用web-serving模擬線上業務，in-memory-analytics模擬離線業務。使用三種部署方式進行驗證：只執行線上、在離線混合部署、在離線混合部署（開啟QoS隔離特性）。測試資料如下所示，利用CPU搶佔能力可以讓線上任務達到接近獨立部署的效能。
圖 8 混合部署響應時間
網路隔離效果
網路通過netperf進行測試，分別在不同優先順序Pod執行發包測試，在離線發包時序如下圖所示，時間軸單位為s，在第5秒驗證離線對線上的效能影響，在第15秒驗證線上任務對網路的搶佔能力。
圖 9 網路發包時序
取樣資料如下圖所示，啟動離線任務對線上任務網路效能影響較小，線上任務可以在100ms時間內完成網路效能從0到最大的搶佔。
圖 10 網路搶佔效能
計劃與展望
雖然混合部署解決方案是提升資源利用率的重要技術手段，但該方案目前沒有形成業界統一標準，存在重複設計，通用性不強等問題。後續計劃向kubernetes和linux核心提交貢獻來推進生態標準化。
未來，混合部署的含義也將隨著技術的發展而逐漸豐富，例如多種型別任務的混合部署，異構資源的混合部署等等。因此需要在兩級優先順序設計的基礎上，探索多級優先順序場景和擴充套件方案，以支援更豐富任務型別。異構和跨代硬體資源的混合部署對傳統基於資源部署的方式提出了新的需求，讓業務的部署不再需要感知底層硬體資源才能提供更智慧的排程、更精準的資源匹配。
此外，仍有部分資源沒有分級搶佔能力，例如L1/L2快取、快取頻寬等，因此混合部署的效能干擾不可避免。為了讓混合部署後仍能提供優質的服務質量，不僅要從晶片微架構到上層排程層進行全面設計，還需要一種預測、反饋和校正機制。
參考資料
- 雲原生2.0白皮書
- 資料中心產業發展指數2021年
- 新型資料中心發展三年行動計劃（2021-2023年）
- 中國資料中心行業研究報告2020年
- 王康瑾,賈統,李影.在離線混部作業排程與資源管理技術研究綜述.軟體學報,2020,31(10):3100-3119
- Interference-Aware Scheduling for Inference Serving