openEuler 資源利用率提升之道 01:概論
問題背景
據 Canalys 釋出的一份報告顯示[1],全球雲基礎設施服務支出在 2022 年第一季度同比增長 34%,達到 559 億美元。然而,多個研究表明,當前全球資料中心使用者叢集的平均 CPU 利用率低於 20%,存在巨大的資源浪費。因此,提升資料中心資源利用率是當前急需解決的一個重要問題[2]。
問題成因
資源利用率低下的主要原因是任務和資源調配失衡,這種失衡又有多種表現形式,例如:
-
排程系統和叢集獨立:不同的作業採用不同的排程系統,作業不能在更加廣泛的叢集中流動,其他叢集的空閒資源不能有效利用。
-
任務型別缺乏多樣性:叢集中的作業同質化嚴重,作業集中使用一部分資源,導致這部分資源利用率較高,但是其餘資源空閒。
-
缺乏優先順序分級管理:要麼是缺乏低優先順序作業填補空閒資源,要麼是有低優先順序作業但是叢集不具備分級管控能力,導致資源過度分配。
-
叢集中資源型別單一:叢集內部資源整體規格單一,不能根據總體業務對各類資源的動態需求進行彈性伸縮,導致部分資源配置過高。
總體而言,是叢集內部任務和資源的多樣性不足,排程對多樣性任務和資源的管理能力薄弱導致。
解決思路
將不同型別的作業混合部署,分別從時間上和空間上提升資源的使用率。
-
資源超賣(空分超賣):線上業務的空閒資源超賣給離線作業,提升總體資源利用率。 -
錯峰使用(時分超賣):線上業務的空閒時段填充離線作業,減少資源空轉。
技術挑戰
不論是空分超賣還是時分超賣,都存在共峰資源不足的問題,該問題會導致部分業務服務質量(QoS)受損。如何在提升資源利用率之後,保障業務 QoS 不受損是技術上的關鍵挑戰。
此外,雲上業務的多樣性和複雜性進一步加大了保障服務質量的難度:
一方面,從負載特徵可感知程度,可以分為白盒應用,黑盒應用和灰盒應用。白盒應用可以被系統感知內部結構,實時獲取 QoS 指標;黑盒業務則不能被系統感知內部結構,系統甚至不知道應用的 QoS 是什麼;可感知程度介於二者之間的應用稱為灰盒應用。如何精準量化黑盒業務的服務質量並定位干擾源是能力泛化的技術挑戰,也是業界研究熱點。
另一方面,從負載的業務複雜程度,可以分為輕量化應用(如微服務,函式計算),傳統應用(如單體應用)和超級應用(如 HPC/AI)等。需要克服全棧協同感知等技術難題,構建具有普適性的統一系統。
解決方案簡介
根據上面的成因分析,進一步的,將多樣性業務/負載和資源融合部署排程,能夠顯著提升資源調配的靈活性,從而達到提升高資源利用效率的目的。但這也帶來了更大的技術挑戰,管理的業務/負載越多,資源型別越多,依賴關係越複雜,對系統的多目標優化要求就越複雜。基於此,我們將其分為如下幾個發展階段:
L0:獨立部署:叢集獨立技術棧、獨立資源池,叢集利用率低(<20%)。
L1:共享部署:統一技術棧擴大叢集規模,單一型別業務共享資源部署,基於動態彈性提升資源利用率,叢集資源利用率較低(<30%)。
-
相關技術:技術棧統一、容器化改造、彈性伸縮
L2:「混合部署」:統一技術棧擴大叢集規模,多種型別業務共享資源部署,基於超賣和隔離技術提升資源利用率,叢集資源利用率高(>40%)。
-
相關技術:資源超賣、資源分級隔離、反饋控制
L3:「泛型混部」:混合部署業務型別泛化,支援公有云上成千上萬種黑盒業務共享資源部署,基於 QoS 量化感知保障關鍵業務服務質量。
-
相關技術:QoS 量化/定位、精準控制、QoS 感知排程
L4:「融合部署」:在負載型別泛化的基礎之上,融合容器、虛機、輕量化執行時等多樣性負載,結合 HPC/AI+異構資源感知等複雜場景,全面提升各類資源整體利用率。
-
相關技術:異構資源感知排程、統一排程
其中,L1~L2 以提升叢集 CPU 資源利用率為主,L3~L4 對資源利用率提升技術進行泛化。
業界當前在內部業務上進行 L2 級別的探索並顯著的提升了叢集甚至資料中心的整體利用率,但在公有云泛化上還處於早期階段,還沒有大規模商用。
我們在結合未來泛型與融合部署的趨勢上,構築了一套可持續演進的資源利用率解決方案,如下圖所示:
為了達到最佳的部署效果,需要任務執行的多個層面進行控制和優化:
「叢集管理層」:排程層面將性能干擾較強的業務分開部署,通過任務組合優化減少不必要的干擾。
「單機管理層」:單機管理層面實時感知資源競爭,消除對關鍵作業的影響。
「資源隔離層」:通過對任務分級優先控制,保障高優先順序任務資源需求。
目前華為基於上述框架已經實現了 L2 級解決方案,相關特性已在華為內部完成驗證並陸續上線。技術上在各層面上均取得了重要突破:
「叢集管理層」:
-
預測排程:支援基於節點物理資源使用率預測排程[3]、負載均衡排程、資源搶佔排程等特性。 -
特徵建模:設計並實現了一套通用的應用畫像建模元件,該元件能夠自動進行干擾注入、指標採集和模型輸出。
「單機管理層」:
-
QoS 量化:基於量化模型實時檢測業務 QoS 並對干擾源進行實時控制。 -
拓撲編排:根據硬體拓撲關係,對業務進行動態親和性編排,在資源配額不變的情況下,提升整體效能。 -
功耗控制:資源利用率提升後增加了整機功耗過高風險,需實時監測功耗變化,進行鍼對性的功耗壓制。 -
L3/MB 控制:當前底層硬體提供了 L3 快取和記憶體頻寬隔離能力,但仍需軟體動態控制,以實現干擾控制和資源利用率的平衡。
「資源隔離層」:
-
分級搶佔:對可優先順序排隊資源提供分級搶佔能力,如 CPU、MEM、IO/NET 等,其中 CPU 絕對壓制能力(避免優先順序翻轉),NET 搶佔效能(<100ms)等業界領先。 -
彈性排程:支援潮汐親和性、CPU Burst 等彈性排程能力。
以上細顆粒特性,我們也會陸續開放到 openEuler 上,請大家多多使用、在社群上多多交流。
未來計劃
當前我們已經在一些內部場景驗證並落地了混合部署方案,已經達到了 L2 階段。短期來看,還需要突破黑盒業務 QoS 保障相關技術並進入 L3 階段,只有達到 L3 階段才能讓更多使用者從中收益。長期來看,除了容器場景外,還有更多的負載型別、資源型別需要提升資源利用率,這需要在叢集排程、OS 等層面出現更多的技術突破。
本文簡要介紹對於雲上資源利用率提升解決技術的思考,後續計劃對其中涉及的隔離技術,反饋控制技術,感知排程技術等進行詳細介紹,敬請期待!
參考資料
-
Global cloud services spend hits US$55.9 billion in Q1 2022 -
王康瑾,賈統,李影.在離線混部作業排程與資源管理技術研究綜述.軟體學報,2020,31(10):3100-3119 -
Volcano:在離線作業混部管理平臺,實現智慧資源管理和作業排程
加入我們
文中所述資源利用率提升技術,由 Cloud Native SIG、High Performance Network SIG,Kernel SIG, OpenStack SIG 和 Virt SIG 共同參與,其原始碼將在 openEuler 社群逐步開源。如果您對相關技術感興趣,歡迎您的圍觀和加入。您可以新增小助手微信,加入對應 SIG 微信群。
本文分享自微信公眾號 - openEuler(openEulercommunity)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。
- 玩轉機密計算從 secGear 開始
- openEuler資源利用率提升之道06:虛擬機器混部OpenStack排程
- openGauss Cluster Manager RTO Test
- JVM 鎖 bug 導致 G1 GC 掛起問題分析和解決【畢昇JDK技術剖析 · 第 2 期】
- 手把手帶你玩轉 openEuler | openEuler 的使用
- 681名學生中選!暑期2021開啟火熱“開源之夏”!
- 手把手帶你玩轉 openEuler | 初識 openEuler
- StratoVirt 中的 PCI 裝置熱插拔實現
- 使用 NMT 和 pmap 解決 JVM 資源洩漏問題
- JNI 中錯誤的訊號處理導致 JVM 崩潰問題分析
- Java Flight Recorder - 事件機制詳解
- 畢昇 JDK 8u292、11.0.11 釋出!
- StratoVirt 中的虛擬網絡卡是如何實現的?
- openEuler結合ebpf提升ServiceMesh服務體驗的探索
- 我的openEuler社群參與之旅
- StratoVirt 的中斷處理是如何實現的?
- 看看畢昇 JDK 團隊是如何解決 JVM 中 CMS 的 Crash
- 使用 perf 解決 JDK8 小版本升級後效能下降的問題【畢昇JDK技術剖析 · 第 1 期】
- 2021年畢昇 JDK 的第一個重要更新來了
- 漏洞盒子 × openEuler | 廣邀白帽共築安全的Linux開放應用生態