既要穩也要省,容器資源該怎麼分配?
眾所周知,假期出行,熱情高漲,需求增多也使得穩定性保障壓力大。當各個服務流量激增時,資源負載壓力將會顯著提升。微觀上,單臺物理機的 CPU 利用率會大幅提升,單機上各個容器之間的爭搶會增加,效能受到影響。宏觀上,整個彈性雲的熱點機器會增加,可供排程的資源會降低,容器排程和擴容的失敗率會上升。
今年,在降本增效的大前提下,不額外增加計算型伺服器採購,如何保障資源供給以及確保高壓場景下的容器穩定性,對彈性雲而言是個巨大的挑戰。為了提供更穩定的容器服務,彈性雲全面梳理了容器服務資源保障的每一個環節,提出了新分級保障體系,提供了明確的容器資源保障等級,在此基礎上,針對不同優先順序的容器提供相應的資源和穩定性保障。
早期彈性雲容器體系帶來的超賣隱患
彈性雲早期分級體系提供了1/2/3級容器等級,只是對容器的優先順序進行了簡單的區分,並未將容器優先順序與底層的資源保障關聯在一起。容器服務在使用過程中,會遇到以下問題:
資源爭搶嚴重
業務延遲較高,毛刺較多
擴容失敗機率較高
業務容量評估不準
物理機數量難以評估
之所以會存在這些問題,實際上還是因為在資源層面沒有相應的保障。從單機資源看,部分物理機的 CPU 使用率峰值過高,並且容器的 CPU 資源存在不同程度的超賣。
從叢集資源來看,舊體系下 quota 與物理機資源缺乏關聯,導致業務申請的 quota 僅僅停留在數字層面,不指導物理機資源的準備。此外,quota 還缺乏管控,導致 quota 的申請與實際需求嚴重脫節。
造成上述諸多問題很重要的一個原因就是彈性雲資源整體上是超賣的,且比較嚴重。
所謂的資源超賣,指的是資源的申請量>供給量,表現為單機 & 叢集方面均超賣。
單機層面,一臺物理機上執行的所有容器的規格相加大於物理機所能提供的資源總量。
叢集層面,服務資源的 quota 總和大於叢集物理機資源總量。
從上圖中可以看到,單是1級服務申請的資源量,就已經超過了物理機的總資源量。在叢集和單機都超賣的情況下,早期的分級體系並沒有確立明確的超賣規則,使得舊體系容器執行環境整體處於無序和不確定的狀態下。
兩大超賣解決思路帶來的四大收益
思路一:核心服務鏈路不超賣
所有的核心服務鏈路上的服務均1:1對應物理機資源,不超賣。透過對機房1和機房2進行簡單的統計, 發現核心服務鏈路中網約車+兩輪車+代駕服務的申請量總和佔據了所有服務總申請量的大約一半,且機房1核心服務的申請量已經超過總CPU數,機房2核心服務的申請量基本接近總CPU數。所以,核心服務不超賣受限於資源,方式不可行。
思路二:核心服務鏈路中最重要的服務不超賣
受限於資源,無法做到所有的核心服務鏈路中的服務都不超賣,那退一步,在物理資源有限的情況下,保障核心服務鏈路中最重要的服務不超賣,並在此基礎上,對於剩餘的服務制定合理的超賣規則。
因此,彈性雲需要重新制定分級保障體系,同時為新分級體系制定明確的超賣規則。超賣規則如下:
核心服務中20% -> S級服務:不超賣
老1級 -> A級服務:2倍超賣
老2/3級 -> B級服務:4倍超賣
在新的超賣規則下,可以看到,機房1和機房2的總物理CPU量是基本能滿足需求的(機房2的資源申請量略微超出, 可以透過新增機器或是縮容來滿足要求)。
這樣的重新設計下,我們在2022年元旦前完成所有S級服務的接入,2022年國慶前完成網約車核心服務/兩輪車核心服務/代駕核心服務接入新體系。總體來看,這樣的改變帶來了四大收益:
收益1:資源層面,S級服務CPU外部爭搶降低60% ~80%,A級服務CPU外部爭搶降低30~50%。
收益2:業務延遲方面,業務99分位延遲(均值)降低7% ~ 20%業務99分位延遲(最大值)降低5% ~ 15%。
收益3:容量方面,高峰期S級服務比之前多承載30%+流量,S級服務比之前能縮容30%+資源。
收益4:業務收益角度,高峰期CPU外部爭搶下降65%~75%,毛刺基本消失,業務延遲指標下降5%~25%,業務壓測CPU外部爭搶下降60%~70%。
彈性雲新分級保障體系總體架構
為了支援新分級保障體系,彈性雲從下到上,針對每一層中的相關元件都進行開發改造,同時也包含了系統部 CMP 系統quota相關的開發工作,主要體現在作業系統層、k8s 排程層、kube-odin 層、服務樹和系統部 CMP 系統。
從上述架構圖中可以看到,位於最底層的是機房的物理機資源,物理機分別位於不同的機房。
作業系統層
物理機之上是作業系統層,作業系統層面分為核心態和使用者態。在核心態新增特性上,新分級體系對 CPU 排程,記憶體管理,IO 讀寫都進行了針對性的開發和最佳化。
CPU 排程:
新增優先順序權重概念,不同優先順序容器的排程權重不同,用於區分不同等級容器排程優先順序。
新增 CPU Burst 技術,允許部分重要容器能短時間內突破規格的上線,臨時使用超量的 CPU。
記憶體管理:
新增優先順序回收技術,優先回收低優先順序容器的記憶體,最後回收高優先順序容器記憶體。
新增分級水位特性,減少系統記憶體緊張時高優先順序容器記憶體分配受阻。
IO 讀寫:
新增頻寬限速特性,支援對低優先順序容器的 IO 讀寫頻寬進行限速,以減少對高優先順序容器的影響。
新增優先順序頻寬分配特性,支援按容器優先順序分配 IO 頻寬。
在使用者態新增特性上,作業系統使用者態針對新分級體系的支援主要體現在 Kubelet、IRMAS 和單機資源排程這幾個元件上。其中,kubelet 和 IRMAS 主要新增了新分級體系容器的識別、資訊採集上報、單機資源配置、環境適配等工作。新增單機資源排程模組實現了極端情況下單機資源的壓制和恢復,以及與 k8s 排程聯動等功能。
k8s 排程層
在 k8s 容器排程層,針對新分級體系新增了最小資源保障策略,指的是透過合理的排程,保障任何時候,容器均能獲得承諾的資源量。
容器分級均衡打散策略指的是保證一臺物理機上不會存在過多同一級別的容器,將不同等級的容器均勻打散到不同的物理機上。
分級容量資源大盤指的是資源大盤新增新分級體系容器支援,實時觀察新分級容器容量健康情況。
擴容成功率保障指的是新增容量預估特性,最佳化資源申請流程,實時監控彈性雲可供擴容資源量,有效提高擴容成功率。
kube-odin 層
kube-odin 層配合新分級體系也進行了相關改動和升級:
新增新等級接入平臺:包括新等級容器查詢操作相關介面的適配。
計費管理模組:新增新分級體系容器的計費支援,支援多種計費場景。
服務 quota 操作:新增 quota 操作介面。
服務樹
服務樹在保持相容性的基礎上,新增了新分級體系叢集資訊的支援。
系統部 CMP 系統
新體系容器的 quota 申請和使用由系統部 CMP 系統操作和記錄。
CMP 系統透過獲取業務申請的 quota 資訊,能明確推算所需的物理機資源,更好實現物理機資源的保障。針對新體系容器的 quota 支援,CMP 系統新增了 quota 成本賬戶、quota 成本賬戶以及 quota 申請模組。
quota 成本賬戶:包含S級/A級/B級的 quota 資訊。
quota 管控模組:對 quota 的使用量進行追蹤和考察,以便進行有效的資源管控。
quota 申請模組:規範 quota 申請流程,明確 quota 申請規則。
新分級體系三大重點資源保障
新分級體系立足於核心問題,在單機層面和叢集層面都對容器申請的資源進行相應保障。
單機資源保障:CPU
新分級體系資源保障的其中一個重點為:保障容器的 CPU 資源任何時刻都能按超賣比所規定的有效交付。
在前文中,我們提到新體系容器的超賣規則為:S級不超賣,A級2倍超賣,B級4倍超賣。那對於不同等級的容器,可輕鬆得知其所需的物理 CPU 個數。新分級體系所需要保證的就是一臺物理機上所有容器經過超賣比計算後得到的物理 CPU 個數必須小於物理機上的 CPU 個數。
上述的示例中,對於一個40核的物理機,可用的 CPU 數為: 40*90%=36核 (90%為計算各種 agent 和排程損耗之後的有效核數)。容器總共申請的核數為56核,經過超賣比計算後得到的所需物理核為36,剛好滿足要求。
透過明確超賣比,根據超賣比準備對應物理 CPU 資源的方式,在高負載期間,如果所有的容器都滿載執行,則物理機上的 CPU 資源將會按照超賣比承諾的比例進行分配。在低負載時刻,算力足夠時,由於機器整體空閒,容器之間幾乎不發生爭搶,此時容器可以正常使用 CPU。
單機資源保障:記憶體
在物理機層面,記憶體是所有容器之間共享的資源,傳統核心沒有對容器進行優先順序的劃分,所有容器的記憶體使用對於核心而言都是一視同仁。
記憶體對容器效能的影響主要體現在記憶體分配和記憶體回收上。
記憶體分級水位
作業系統核心會監控整個系統的記憶體使用情況,當可用記憶體低於一定水位時,就會阻塞記憶體分配路徑,觸發記憶體回收操作。
某些場景下,低優先順序容器可能大量申請記憶體,導致記憶體水位線降職 min 水位以下,物理機面臨記憶體分配和回收時,高優容器將會受到影響,無法及時的分配記憶體。
針對這個場景,核心新增了記憶體分級水位特性,允許按照優先順序設定不同的 min 水位。這樣,在申請記憶體時,低優先順序容器會先達到回收水位線觸發低優先順序容器的記憶體回收,而高優先順序容器的記憶體回收水位線較低,可以正常分配。
記憶體按優先順序回收
由於原生記憶體沒有對記憶體進行優先順序區分,因此當核心走到記憶體回收路徑,會無差別的進行記憶體回收動作。此時,可能高優先順序容器的記憶體被回收,而低優先順序容器記憶體則完好無損。
新分級體系的目標顯然是要在回收記憶體的時候優先回收低優先順序容器的記憶體,這樣可以最大程度保護高優先順序容器的記憶體,進而保障高優先順序容器的效能表現。
基於優先順序回收的思想,核心所做的就是識別容器優先順序,然後按照容器優先順序逐一回收記憶體,直至記憶體水位線恢復健康水平。
先回收B級容器的記憶體
再回收A級容器的記憶體
最後才回收S級容器的記憶體
叢集資源保障:quota
業務在申請容器服務的時候,一般需要指定單個容器的規格(CPU/記憶體大小)和申請的數量。彙總服務總共所需的資源量,即為 quota,quota 管理的最小單位為成本賬戶。
可以看到,在新分級體系下,quota 按照容器優先順序,分為了對應的S級/A級/B級 quota。quota 是用於描述業務的資源申請量,而對於彈性雲和系統部而言, 則可以根據 quota,進行物理資源的準備。例如對於某個成本賬戶,申請的 quota 如下所示:
我們可以清楚看到,業務申請的 quota 量與實際準備物理機資源量之間的對應關係。
透過建立並規範 quota 的申請和使用流程,新分級體系能根據資源超賣規則有效的將 quota 的申請量與後臺真實物理資源的準備量結合起來,從而實現資源層面的強保障。另外,在 quota 體系逐步完善之後,還能根據 quota 使用率和容器的 CPU 使用率對 quota 進行有效的資源管控。
總結
很長一段時間,舊的彈性雲分級體系存在資源爭搶、業務延遲、擴容失敗、業務無法準確評估容量、物理機數量難以評估等問題。這些問題的本質是由於沒有制定明確的資源準備和分配規則。
新分級體系立足於核心問題,提出了明確的資源超賣規則,在單機層面和叢集層面都對容器申請的資源進行相應保障。在單機層面,保證了按超賣比轉化後實際的物理機資源不會超過物理機所提供的最大資源量,同時制定了明確的資源爭搶規則。在叢集層面,建立並規範了 quota 申請流程,明確了 quota 與物理機資源之間的對應關係,保障了資源的供給,同時,也有效管控了 quota ,避免資源的浪費。
透過在容器資源申請、容器排程、執行時保障、資源管控等多個方面新增資源保障策略,彈性雲新分級體系支援容器高效穩定的執行,確保了彈性雲整體的穩定性,也一定程度降低了物理機運營成本。
來自 “ 滴滴技術 ”, 原文作者:陳賀;原文連結:https://server.it168.com/a2023/1023/6825/000006825776.shtml,如有侵權,請聯絡管理員刪除。
相關文章
- “成年人”的資料庫,既要又要也要!資料庫
- “既要效能,也要安全”,這樣的Rust,誰不喜歡!Rust
- 核心是如何給容器中的程式分配CPU資源的?
- 既要技術制勝,也要體驗為王:今天我們需要怎樣的WLAN?
- 穩定的牛分配
- 既要發展也要管制,人工智慧是帶著枷鎖的舞者人工智慧
- 省時省力更精準!資料監控是個好東西,我們應該怎麼做?
- 物理機虛擬資源分配推薦
- Spark如何進行動態資源分配Spark
- 無線資源分配方法(筆記)筆記
- Netty 中的記憶體分配淺析-資料容器Netty記憶體
- 什麼是API資料介面該怎麼使用?API
- 該怎麼做事?
- 怎麼測試伺服器穩不穩定伺服器
- 資料探勘和資料提取該怎麼區分?
- 既要“美顏”,還要“保真”,美顏api該如何做出改變?API
- 如何科學合理地分配客戶資源?
- 沒團隊沒資源,想代理短影片同城爆店專案應該怎麼做?
- 使用免費開源軟體時遇到問題該怎麼辦?
- 資料產品規劃到底該怎麼做?
- 怎麼學大資料?該從哪學起?大資料
- 資源又不足?專案資源該如何有效管理?
- 容器技術之Docker資源限制Docker
- 應該怎麼分頁?
- 該怎麼學好JavaJava
- docker中怎麼啟動容器Docker
- 多專案並行時人員怎麼分配並行
- docker筆記34-容器資源需求、資源限制及HeapSterDocker筆記
- 各有利弊,開源和商業軟體應該怎麼選?
- 企業在資料中臺上該怎麼選擇
- APP資料洩露該怎麼去排查和溯源APP
- 3000字長文教你大資料該怎麼學!大資料
- 碼教授告訴你大資料該怎麼用大資料
- Jasper 怎麼配置動態資料來源
- 如何把不同的客戶資源合理配置/自動分配
- Kubernetes:容器資源需求與限制(約束)
- 講講怎麼列舉MmMapViewInSystemSpace分配的記憶體View記憶體
- 用linux/cmd該怎麼操作Linux