作者：錢君、南異
審核&校對：溪洋、海珠
編輯&排版：雯燕
混部顧名思義，就是將不同類型的業務在同一台機器上混合部署起來，讓它們共享機器上的 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 產品詳情！
了解更多相關信息，請掃描下方二維碼或搜索微信號（AlibabaCloud888）添加雲原生小助手！獲取更多相關資訊！
