CTO愈來愈高的狀況下，我是如何幫老闆省下400萬的？

**上篇連接：**juejin.cn/post/686596…

混部系統設計

咱們基於 Kubernetes 實現了在/離線業務混部系統，遵循如下設計原則：

• 動態調度：根據節點的真實負載實現離線業務的動態調度
• 動態資源分配和隔離：根據在線業務的負載，動態調整分配給離線業務的資源量，動態執行資源隔離策略，下降甚至消除彼此之間的性能干擾
• 插件化：不對k8s作任何in-tree的侵入式改動，全部組件要基於k8s的擴展機制開發，而且混部系統自己擴展性強
• 及時響應：當混部節點資源利用率太高，或者對在線業務產生影響時，可以及時發現，並驅逐離線業務，以保證在線業務的SLA
• 可運維、可觀測：對用戶和運維人員友好，接入成本低，使用成本低 image
  

圖6 系統架構

Resource Reclaim

Resource Reclaim是指回收在線業務已申請的，可是目前還空閒的資源，而後給離線業務使用。這部分資源是low-quality的，沒有過高的可用性保證.

咱們自定義了擴展資源colocation/cpu和colocation/memory（分別對應原生的cpu和memory），來表徵上述 reclaimed resource，實現離線任務的動態調度。

圖7 resource reclaim

節點上在線業務CPU Usage高，則咱們分配給離線業務的資源就會減小；在線業務CPU Usage低，則咱們就能夠將更多的資源分配給離線業務。

動態調度

基於擴展資源colocation/cpu和colocation/memory 實現離線任務的動態調度，優先將離線任務調度到節點負載較低、離線任務較少的混部節點上，均衡不一樣節點之間的負載、減小業務之間的資源競爭。

動態資源分配和動態資源隔離

Google 在數據中心資源管理領域，不少年之前就開始投入大量人力、物力。因爲硬件在性能隔離上的侷限性，Google在軟件層面作了大量的改造，率先提出了多項資源隔離技術，包括cgroups、Container等（內核的不少功能特性都是業務需求觸發的，而不是憑空想象出來的）。咱們對於在/離線業務的性能隔離也是主要經過cgroup來實現的。

kubelet cgroup manager 沒有可擴展點，直接修改kubelet代碼又會給後續的運維升級帶來比較大的成本，所以咱們單獨開發了一個zeus-isolation-agent運行在每一個混部節點上，經過定時動態更新cgroup來實如今/離線業務資源隔離。

圖8 在/離線業務資源隔離

從CPU、內存、緩存、磁盤到網絡，咱們實現了多維度的隔離策略，顯著下降在/離線業務之間的互相干擾。以緩存爲例，咱們對內核進行了定製化改造，給在/離線業務設置不一樣的緩存回收優先級，優先回收離線業務使用的緩存。

離線業務的重調度

存在這樣一種場景，剛開始時混部節點上的在線業務較少、負載較低，可以分配給離線業務的資源較多，所以用戶可以調度較多的離線業務上去。可是，後來用戶調度了更多的在線業務上來或者在線業務的流量飆升，致使節點上可以給離線業務的資源很是有限，離線任務執行效率會很低。假如此時，其餘混部節點比較空閒，爲了不離線任務的飢餓、減少業務之間的資源競爭，咱們會重調度離線任務到其餘node上。

離線任務的重調度，主要有以下優勢：

• 均衡各個混部節點的負載狀況，避免有的節點負載較高而有的節點又過於空閒
• 避免某個節點負載太高，以致於影響到在線業務性能和穩定性
• 提升離線業務的執行效率

可是，重調度也有缺點，若是沒有遠程checkpoint機制，會致使重調度以前的算力被浪費。影響程度有多大，是跟單個任務的處理時長有關係的。若是處理一個任務的時長是秒級，那麼重調度的影響是微乎其微的。若是處理一個任務的時長是天級別的，那麼重調度的影響仍是比較大的。所以，是否使用重調度功能、重調度的觸發閾值等用戶都是能夠實現workload級別的配置的。

落地成果

上述在/離線業務混部方案已經集成到網易輕舟容器平臺NCS中，在網易內部獲得普遍應用，大幅提升了服務器資源利用率，取得顯著成果。

以網易傳媒爲例，傳媒將視頻轉碼業務做爲離線業務混部到了在線業務的機器上，混部後CPU利用率從 6%-15% 提升到 55% 左右。

先了解一下視頻轉碼服務的特色：

• CPU密集型，大量讀寫磁盤保存臨時數據，有必定量網絡IO
• Long-running pod，而不是一個run-to-complete類型的pod，它會從隊列中不斷取視頻任務進行轉碼處理，沒有任務的話就空閒且保持運行
• 轉碼單個視頻的時長在秒級，所以重調度對其影響是微乎其微的

redis+視頻轉碼

Redis業務是對於時延比較敏感的在線業務，SLO要求較高，可是其CPU利用率較低，所以咱們嘗試將視頻轉碼業務混部到了Redis專屬節點上，下面咱們看一下這兩個在/離業務混部的效果。

圖9 Redis節點混部先後CPU利用率

從圖9 能夠看到，Redis節點混部前CPU利用率在8%左右，混部後達到30~35%，利用率大幅提高。

而後咱們再看一下混部先後redis的SET/GET操做的RT對比。

圖10 Redis GET 操做平均響應時間

表3 Redis GET 操做平均響應時間

從圖10 和 表3 能夠看出，混部先後GET操做的RT 基本沒有變化。

圖11 Redis SET 操做平均響應時間

表4 Redis SET 操做平均響應時間

從圖11 和 表4 能夠看出，混部先後SET操做的RT 基本沒有變化。

廣告推薦+視頻轉碼

廣告推薦服務也是一個對穩定性和性能要求很高的時延敏感的在線類型業務，下面咱們看一下轉碼服務和廣告推薦服務混部取得的效果（節點上還有其餘類型的在線服務，這裏咱們以時延敏感的廣告推薦服務爲例）。

圖12 混部先後節點CPU利用率對比

從圖12 能夠看到，混部以前cpu利用率在10-20%之間，混部以後cpu利用率長時間維持在55%左右，利用率提高幅度較大。

混部的目的是提升資源利用率、下降成本，可是前提是不能對在線業務產生明顯的性能影響。所以，咱們再看一下該廣告推薦服務的某個核心性能指標在混部先後的變化：

圖13 廣告推薦服務請求處理時間

從圖13 發現，混部先後該核心性能指標是沒有任何衰減和惡化的，混部前的平均RT是6.59ms，混部後的平均RT是6.65ms:

表5 廣告推薦服務混部先後的平均RT指標

總結和展望

目前，混部已經在網易獲得普遍落地，取得顯著成果。接下來，咱們會繼續探索和實踐雲原生技術，基於網易輕舟將混部方案落地到更多企業，讓更多企業享受到雲原生的紅利。

參考文獻

[1] The Datacenter as a Computer
[2] Overall Data Center Costs
[3] 數據中心成本與利用率現狀分析
[4] Quasar: resource-efficient and QoS-aware cluster management
[5] 淺談混部系統研究
[6] PerfIso: Performance Isolation for Commercial Latency-Sensitive Services
[7] Borg: the Next Generation
[8] Autopilot: workload auto scaling at Google
[9] Improving Resource Efficiency in Cloud Computing

若是你喜歡這篇文章的話，別忘了 轉發、收藏、留言互動！

還有，關注我！關注我！關注我！

大佬們分別是：
張曉龍——網易數帆輕舟技術總監。負責基礎設施研發 /運維至今，在虛擬化、網絡、容器、大規模基礎設施管理以及分佈式系統等技術架構有多年經驗，當前主要興趣點在雲原生技術方向。
李嵐清——網易數帆輕舟業務部資深系統開發工程師。具備多年Kubernetes開發運維經驗，負責在/離線業務混部、容器網絡編排等多個項目，推進和協助網易內部多個業務實現容器化。
陳林亮——網易數帆輕舟資深雲計算開發工程師。具備多年雲計算開發，運維及優化經驗，參與開發網易雲計算1.0至當前3.0多個雲平臺。目前專一在在/離線業務混部、容器編排資源優化等方向。