簡介：本文作為混部實踐系列開篇，本篇文章將介紹資源隔離技術在混部中的重要性、其落地挑戰及我們的應對思路。
作者：錢君、南異
稽核&校__對：溪洋、海珠
編輯&排版：雯燕
混部顧名思義，就是將不同型別的業務在同一臺機器上混合部署起來，讓它們共享機器上的 CPU、記憶體、IO 等資源，目的就是最大限度地提高資源利用率，從而降低採購和運營等成本。
2014 年，阿里開始了第一次探索混部，經過七年磨練，這把將資源利用率大幅提升的利劍正式開始商用。
通過計算資源、記憶體資源、儲存資源、網路資源等全鏈路的隔離以及毫秒級的自適應排程能力，阿里可以在雙十一的流量下進行全時混部，通過智慧化的決策與運維能力，支撐著內部百萬級的 Pod 混部，不管是 CPU 與 GPU 資源，普通容器與安全容器，包括國產化環境各種異構基礎設施，都能實現高效混部，這讓阿里核心電商業務生產叢集成本下降了 50% 以上，同時讓核心業務受到的干擾小於 5%。
針對雲原生時代的資源效能提升問題，我們將基於大規模場景下的混部實踐推出系列文章，詳細介紹並分享關於混部技術的細節，及大規模生產中碰到的種種落地的實際問題。作為系列開篇，本篇文章將介紹資源隔離技術在混部中的重要性、其落地挑戰及我們的應對思路。
混部和資源隔離之間的關係：資源隔離是混部的基石
混部通常是將不同優先順序的任務混合在一起，例如高優先順序的實時任務（對時延敏感，資源消耗低；稱為線上）和低優先順序的批處理任務（對時延不敏感，資源消耗高；稱為離線），當高優先順序業務需要資源時，低優先順序任務需要立即歸還，並且低優先順序任務的執行不能對高優先順序任務造成明顯干擾。
為了滿足混部的需求，在單機維度的核心資源隔離技術是最為關鍵的一項技術，阿里雲在核心資源隔離技術上深耕多年，積累了許多業界領先的經驗，我們將這些核心資源隔離技術主要涉及的範圍概括為核心中的排程、記憶體和 IO 這三大子系統，並且在各個子系統領域根據雲原生的混部場景進行了深入的改造和優化，包括 CPU Group Identity、SMT expeller、基於 Cgroup 的記憶體非同步回收等。這些關鍵的技術使客戶有能力在雲原生混部場景中根據業務特點給出最優解決方案，有效提高使用者的資源使用率並降低使用者資源的使用成本，非常適用於容器雲混部場景，同時也是大規模化混合部署方案所強依賴的關鍵技術。
下圖是資源隔離能力在整個混部方案中的位置：
為什麼需要資源隔離，資源隔離會遇到哪些攔路虎
假設我們現在有一臺伺服器，上面執行了高優的線上業務以及離線任務。線上任務對響應時間 (Response Time, RT) 的需求是很明確的，要求儘可能低的 RT，故被稱之為延遲敏感型 (Latency-Sensitive, LS) 負載；離線任務永遠是有多少資源吃多少資源的，故此類負載被稱之為 Best Effort (BE)。如果我們對線上和離線任務不加干涉，那麼離線任務很有可能會頻繁、長期佔用各種資源，從而讓線上任務沒有機會排程，或者排程不及時，或者獲取不到頻寬等等，從而出現線上業務 RT 急劇升高的情況。所以在這種場景下我們需要必要的手段來對線上和離線容器進行資源使用上的隔離，來確保線上高優容器在使用資源時可以及時地獲取，最終能夠在提升整體資源使用率的情況下保障高優容器的 QoS。
下面讓我們一起看看線上和離線混跑時可能出現的情況：
- 首先，CPU 是最有可能面對在離線競爭的，因為 CPU 排程是核心，線上和離線任務可能分別會排程到一個核上，相互搶執行時間；
- 當然任務也可能會分別跑到相互對應的一對 HT 上，相互競爭指令發射頻寬和其他流水線資源；
- 接下來 CPU 的各級快取必然是會被消耗掉的，而快取資源是有限的，所以這裡涉及到了快取資源劃分的問題；
- 即使我們已經完美解決了各級快取的資源劃分，問題仍然存在。首先記憶體是 CPU 快取的下一級，記憶體本身也類似，會發生爭搶，不論線上或離線任務，都是需要像 CPU 快取一樣進行記憶體資源劃分的；
- 另外當 CPU 最後一級快取 (Last Level Cache, LLC) 沒有命中的時候，記憶體的頻寬（我們稱之為執行時容量，以有別於記憶體大小劃分這種靜態容量）會變高，所以記憶體和 CPU 快取之間的資源消耗，是相互影響的；
- 假設 CPU 和記憶體資源都沒問題，對於本機來說現在隔離已經做得很好了，但是線上高優的業務和離線任務的執行過程中都是和網路有密切的關係，那麼很容易理解，網路也可能是需要隔離的；
- 最後，線上部分機型對 IO 的使用可能會發生搶佔，我們需要有效的 IO 隔離策略。
以上就是一個很簡單的資源隔離流程的思路，可以看到每一環都有可能會出現干擾或者競爭。
隔離技術方案介紹：獨有的隔離技術方案，各顯神通
核心資源隔離技術主要涉及核心中的排程、記憶體和 IO 這三大子系統，這些技術基於 Linux Cgroup V1 提供資源的基本隔離劃分以及 QoS 保障，適用於容器雲場景，同時也是大規模化混合部署方案所強依賴的關鍵技術。
除了基本的 CPU、記憶體和 IO 資源隔離技術外，我們也研發了資源隔離檢視、資源監控指標 SLI (Service Level Indicator) 以及資源競爭分析等配套工具，提供包括監控、告警、運維、診斷等在內的整套資源隔離和混部解決方案，如下圖所示：
彈性容器場景的排程器優化
如何保證計算服務質量的同時儘可能提高計算資源利用率，是容器排程的經典問題。隨著 CPU 利用率不斷提升，CPU 頻寬控制器暴露出彈性不足的問題日趨嚴重，面對容器的短時間 CPU 突發需求，頻寬控制器需要對容器的 CPU 使用進行限流，避免影響負載延遲和吞吐。
CPU Burst 技術最初由阿里雲作業系統團隊提出並貢獻到Linux社群和龍蜥社群，分別在 Linux 5.14 和龍蜥ANCK 4.19 版本被收錄。它是一種彈性容器頻寬控制技術，在滿足平均 CPU 使用率低於一定限制的條件下，CPU Burst 允許短時間的 CPU 突發使用，實現服務質量提升和容器負載加速。
在容器場景中使用 CPU Burst 之後，測試容器的服務質量顯著提升，如下圖所示，在實測中可以發現使用該特性技術以後，RT長尾問題幾乎消失。
Group Identity 技術
為了滿足業務方在 CPU 資源隔離上的需求，需要在滿足 CPU 資源利用最大化的情況下，保證高優業務的服務質量不受影響，或將影響範圍控制在一定範圍內。此時核心排程器需要賦予高優先順序的任務更多的排程機會來最小化其排程延遲，並把低優先順序任務對其帶來的影響降到最低，這是行業中通用的需求。
在這樣的背景下，我們引入了 Group Identity 的概念，即每個 CPU Cgroup 會有一個身份識別，以 CPU Cgroup 組為單位實現排程特殊優先順序，提升高優先順序組的及時搶佔能力確保了高優先順序任務的效能，適用於線上和離線混跑的業務場景。當在離線混部時，可以最大程度降低由於離線業務引入的線上業務排程不及時的問題，增加高優先業務的 CPU 搶佔時機等底層等核心技術保障線上業務在 CPU 排程延遲上不受離線業務的影響。
SMT expeller 技術
在某些線上業務場景中，使用超執行緒情況下的 QPS 比未使用超執行緒時下降明顯，並且相應 RT 也增加了不少。根本原因跟超執行緒的物理性質有關，超執行緒技術在一個物理核上模擬兩個邏輯核，兩個邏輯核具有各自獨立的暫存器（eax、ebx、ecx、msr 等等）和 APIC，但會共享使用物理核的執行資源，包括執行引擎、L1/L2 快取、TLB 和系統匯流排等等。這就意味著，如果一對 HT 的一個核上跑了線上任務，與此同時它對應的 HT 核上跑了一個離線任務，那麼它們之間是會發生競爭的，這就是我們需要解決的問題。
為了儘可能減輕這種競爭的影響，我們想要讓一個核上的線上任務執行的時候，它對應的 HT 上不再執行離線任務；或者當一個核上有離線任務執行的時候，線上任務排程到了其對應的 HT 上時，離線任務會被驅趕走。聽起來離線混得很慘對不對？但是這就是我們保證 HT 資源不被爭搶的機制。
SMT expeller 特性是基於 Group Identity 框架進一步實現了超執行緒 (HT) 隔離排程，保障高優先順序業務不會受到來自 HT 的低優先順序任務干擾。通過 Group Identity 框架進一步實現的超執行緒排程隔離，可以很好保障高優先順序業務不會受到來自對應 HT 上的低優先順序任務的干擾。
處理器硬體資源管理技術
我們的核心架構支援 Intel®Resource Director Technology(Intel®RDT)，它是一種處理器支援的硬體資源管理技術。包括監控 Cache 資源的 Cache Monitoring Technology (CMT) ，監控記憶體頻寬的 Memory Bandwidth Monitoring (MBM)，負責 Cache 資源分配的 Cache Allocation Technology(CAT) 和監控記憶體頻寬的 Memory Bandwidth Allocation(MBA)。
其中，CAT 使得 LLC(Last Level Cache) 變成了一種支援 QualityofService(QoS) 的資源。在混部環境裡面，如果沒有 LLC 的隔離，離線應用不停的讀寫資料導致大量的 LLC 佔用，會導致線上的 LLC 被不斷汙染，影響資料訪問甚至硬體中斷延遲升高、效能下降。
MBA 用於記憶體頻寬分配。對於記憶體頻寬敏感的業務來說，記憶體頻寬比 LLC 控制更能影響效能和時延。在混部環境裡面，離線通常是資源消耗型的，特別是一些 AI 型別的作業對記憶體頻寬資源的消耗非常大，記憶體佔用頻寬一旦達到瓶頸，可能使得線上業務的效能和時延成倍的下降，並表現出 CPU 水位上升。
Memcg 後臺回收
在原生的核心系統中，當容器的記憶體使用量達到上限時，如果再申請使用記憶體，則當前的程式上下文中就會進行直接記憶體回收的動作，這無疑會影響當前程式的執行效率，引發效能問題。那我們是否有方法當容器的記憶體達到一定水線的時候讓其提前進行記憶體的非同步回收？這樣就有比較大的概率避免容器內的程式在申請使用記憶體時由於記憶體使用達到上限而進入直接記憶體回收。
我們知道在核心中有一個 kswapd 的後臺核心執行緒，用來當系統的記憶體使用量達到一定水位以後來進行非同步的記憶體回收。但是這裡有一種情況，比如當前高優業務容器的記憶體使用已經達到一個比較緊張的狀態，但是宿主機總體的空閒記憶體還有很多，這樣核心的 kswapd 的執行緒就不會被喚醒進行記憶體回收，導致這些記憶體使用壓力大的高優容器的記憶體沒有機會被回收。這是個比較大的矛盾。由於目前原生核心中沒有 memory Cgroup 級別的記憶體非同步回收機制，也就是說容器的記憶體回收嚴重依賴宿主機層面的 kswapd 的回收或者只能依靠自己的同步回收，這會嚴重影響一些高優容器的業務效能。
基於以上背景，阿里雲作業系統團隊提供了一個類似宿主機層面的 kswapd 的基於 Memcg 的非同步回收策略，可以根據使用者需求提前進行容器級別的記憶體回收機制，做到提前記憶體釋壓。
具體的非同步回收過程可以通過下面這幅圖進行描述：
Memcg 全域性水位線分級
通常資源消耗型的離線任務時常會瞬間申請大量的記憶體，使得系統的空閒記憶體觸及全域性 min 水線，引發系統所有任務進入直接記憶體回收的慢速流程，這時時延敏感型的線上業務很容易發生效能抖動。此場景下，無論是全域性 kswapd 後臺回收還是 Memcg 級別的後臺回收機制，都是無能為力的。
我們基於 "記憶體消耗型的離線任務通常對時延不敏感" 這樣一個事實，設計了 "Memcg的全域性 min 水線分級功能" 來解決上述抖動難題。在標準 upstream 全域性共享 min 水線的基礎上，將離線任務的全域性 min 水線上移讓其提前進入直接記憶體回收，同時將時延敏感的線上任務的全域性 min 水線下移，在一定程度上實現了離線任務和線上任務的 min 水線隔離。這樣當離線任務瞬間大量記憶體申請的時候，會將離線任務抑制在其上移的 min 水線，避免了線上任務發生直接記憶體回收，隨後當全域性 kswapd 回收一定量的記憶體後，離線任務的短時間抑制得以解除。
核心思想是通過為在離線容器設定不同標準的全域性水位線來分別控制其申請記憶體的動作，這樣能讓離線容器的任務在申請記憶體時先與線上業務進入直接記憶體回收，解決離線容器瞬間申請大量記憶體引發的問題。
對 Linux 記憶體管理有一定基礎的同學也可以查閱下面這幅圖，詳細記錄了在離線容器混部過程中多種水位線作用下的走勢：
Memcg OOM 優先順序
在真實的業務場景中，特別是記憶體超賣環境，當發生 Global OOM 的時候，有理由去選擇殺掉那些優先順序比較低的離線業務，而保護高優先順序線上業務；當發生離線 Memcg OOM 的時候，有理由去選擇殺掉那些優先順序比較低的作業，而保高優先順序離線作業。這其實是雲原生場景中一個比較通用的需求，但是目前的標準 Linux 核心並不具備這個能力。在選擇殺程式的時候，核心會有一個演算法去選擇 victim，但通常是找一個 OOM score 最大的程式殺，這個被殺的程式有可能是線上高優業務程式，這並不是我們想看到的。
基於以上原因，阿里雲作業系統團隊提供了一個 Memcg OOM 優先順序的特性，通過該特性我們可以保障在系統由於記憶體緊張而發生 OOM 時通過選擇低優的業務程式進行 Kill，從而避免高優業務程式被殺的可能，可以大幅降低由於線上業務程式退出而給客戶業務帶來的影響。
CgroupV1 Writeback 限流
Block IO Cgroup 自合入核心之後，一直存在一個問題，就是隻能對 Direct IO 進行限流 (buffer IO 之後短期內執行 fsync 也可以限流)，因為這些 IO 到達 Block Throttle 層時，當前程式就是真正發起 IO 的程式，根據程式可以獲取到相應的 Cgroup 從而正確記賬，如果超過了使用者設定的頻寬 /IOPS 上限，則進行限制。對於那些 buffer 寫，且最終由 kworker 執行緒下發的 IO，Block Throttle 層無法通過當前程式獲取 IO 所屬的 Cgroup，也就無法對這些 IO 進行限流。
基於以上背景，目前在 Cgroup V2 版本中已經支援非同步 IO 限流，但是在 Cgroup V1 中並不支援，由於目前在雲原生環境下主要還是使用 Cgroup V1 版本，阿里雲作業系統團隊通過建立 Page <-> Memcg <-> blkcg 這三者的關係實現了在 Cgroup V1 中對 IO 非同步限流的功能，限流的主要演算法基本上和 Cgroup V2 保持一致。
blk-iocost 權重控制
正常情況下，為了避免一個 IO 飢餓型作業輕易耗盡整個系統 IO 資源，我們會設定每個 Cgroup 的 IO 頻寬上限，其最大缺點是即使裝置空閒，配置上限的 Cgroup 在其已傳送 IO 超過上限時不能繼續傳送 IO，引起儲存資源浪費。
基於以上需求，出現了一種 IO 控制器 - IOCOST，該控制器是基於 blkcg 的權重來分配磁碟的資源，可以做到在滿足業務 IO QOS 的前提下，盡最大程度利用磁碟的 IO 資源，一旦出現磁碟 IO 能力達到上限導致觸及 QOS 設定的目標時，此時 iocost 控制器會通過權重來控制各個 group 的 IO 使用，在此基礎上，blk-iocost 又擁有一定的自適應能力，儘可能的避免磁碟能力被浪費。
展望與期待
以上所有這些的資源隔離能力目前已經完全貢獻給了龍蜥社群，相關原始碼可以參考ANCK（Anolis Cloud Kernel），有興趣的同學可以關注龍蜥社群：https://openanolis.cn/
同時，阿里雲容器服務團隊也正在與作業系統團隊合作，通過阿里雲容器服務 ACK 敏捷版及 CNStack(CloudNative Stack) 產品家族對外輸出，持續落地 ACK Anywhere，為更多企業賦能。在商用化版本里，我們將完全基於雲原生社群標準，以外掛化的方式無縫的安裝在 K8s 叢集為輸出形態線下交付客戶。其中核心的 OS 層隔離能力，已經發布到支援多架構的開源、中立、開放的 Linux 作業系統發行版-龍蜥（Anolis OS）中。
近期，阿里雲混部核心技術系列文章將陸續分享關於 CPU Brust 技術實踐、核心資源隔離之 CPU 相關隔離/記憶體相關隔離/IO 相關隔離/網路相關隔離等內容，敬請持續關注！
??點選此處，即可檢視容器服務 ACK 產品詳情！
版權宣告：本文內容由阿里雲實名註冊使用者自發貢獻，版權歸原作者所有，阿里雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。