阿里妹導讀：混部是什麼？把叢集混合起來，將不同型別的任務排程到相同的物理資源上，通過排程，資源隔離等控制手段 , 在保障 SLO 的基礎上，充分使用資源能力，極大降低成本，我們稱這樣的技術為混部（Co-loaction）。

背景概述

每年雙十一創造奇蹟的背後，是巨大的成本投入。為了完成對流量峰值的支撐，我們需要大量的計算資源，而在平時，這些資源往往又是空閒的。另一方面，為了在極端情況下，如機房整體斷電等還能保障阿里巴巴的業務不受損失，也需要在全國各地建立冗餘資源。而且就算是一天當中，線上服務的負載也是不一樣的，白天一般情況下要比凌晨高得多。根據蓋特納和麥肯錫前幾年的調研資料，全球的伺服器的CPU 利用率只有 6% 到 12%。即使通過虛擬化技術優化，利用率還是隻有 7% －17%，而阿里巴巴的線上服務整體日均利用率也在 10% 左右。

另一方面，全球從 IT 時代全面走向了 DT 時代，現在又在向更深入的 AI 時代邁進。各各樣的大資料處理框架不斷湧現，從 Hadoop 到 Spark，從 Jstorm 到 Flink，甚至包括深度學習框架 Tensorflow 的出現，成千上萬的資料分析背後是大量的計算任務，佔用了大量的計算資源。由於計算任務佔用的計算量很高，CPU 水位通常在50%-60% 以上，不同於線上服務，計算任務的峰值通常出現在凌晨，水位甚至能達到 70% 以上。所以我們往往就會建立獨立的計算任務叢集。

很多人都被車堵過，而堵車的時候，並不是所有的車道都在堵車。有一個比較有趣的情況，我們稱之為潮汐現象，而它造成的問題是在早高峰的時候是進城方向堵車，而晚高峰是出城方向堵。而為了緩解這個問題，我們使用了潮汐車道的方式。

那麼同樣的原理，是否如果能讓這兩個叢集混合起來部署，讓計算任務的一部分任務跑到線上服務的資源之上，把線上服務空閒的資源利用起來呢？答案是肯定的。

混部技術簡介

混部技術示意圖

把叢集混合起來，將不同型別的任務排程到相同的物理資源上，通過排程，資源隔離等控制手段 , 在保障 SLO 的基礎上，充分使用資源能力，極大降低成本，我們稱這樣的技術為混部（Co-loaction）。

打個比方，跑在容器裡的線上服務就像石塊；而計算任務我們把它比喻成沙子和水。當線上壓力小的時候，計算任務就佔住那些空隙，把空閒的資源都使用起來，而當線上忙的時候，計算任務就立即退出那些空隙，把資源還給線上業務。這樣的技術一方面在平時，我們可以極大地提升資源的利用率；另一方面，在大促活動需要突增線上伺服器的時候，又可以通過線上業務佔用計算任務資源的方式，來頂住那短暫的峰值壓力。

從原理中我們可以看到可以混部在一起的任務有兩個比較重要的特徵：

1.可以劃分優先順序：一定需要優先順序比較低的任務，它們能像水和沙子一樣，隨時能被趕走，而不會受到不可承受的影響，讓優先順序高的任務不受干擾。線上的特點是：峰值壓力時間不長，對延時比較敏感，業務的壓力抖動比較厲害，典型的如早上 10 點的聚划算活動，就會在非常短的時間內，造成交易叢集的壓力瞬間上升 10 幾倍，對於穩定的要求非常高，在混部的時候，必須要保證線上的通暢，需要有極強的抗干擾能力。而計算任務的特點是：平時的壓力比較高，相對來說計算量可控，並且延遲不敏感，失敗後也可以重跑。至少需要幾分鐘跑完的計算任務，相對於幾秒甚至幾十秒的延遲，並不會產生嚴重的問題，正好可以承提起水和沙子的角色。

2.資源佔用互補性：兩種任務在不同的時間點對水位的佔用不一樣。如線上服務是，平時比較低，大促時比較高；凌晨比較低，白天比較高。而計算任務則反過來，平時比較高，大促時可以降級；凌晨非常高，白天卻要低一些。

這種方式帶來的成本節省是非常巨大的：假設資料中心有 N 臺伺服器，利用率從R1 提高到 R2，不考慮其他實際制約因素的情況下，節約 X 臺，那麼理想的公式是：

N*R1 = (N-X)*R2

=> X*R2 = N*R2 – N*R1

=> X = N*(R2-R1)/R2

也就是說如果企業有 10 萬臺伺服器，利用率從 28% 提升到 40%，代入上述公式，就能節省出 3 萬臺機器。假設一臺機器的成本為 2 萬元，那麼節約成本就有6 個億。

2015 年，Google 發表了 Borg 論文，其中就提到了線上服務與計算任務之間的混合執行，也就是我們說的混部技術。Borg 論文中描述了 Google 由於採用了這項技術，為 Google 節省了 20%-30% 的機器規模。

混部技術的歷程

阿里巴巴早期混合雲架構

大家都知道這今年阿里巴巴雙十一的交易峰值是每秒 32.5 萬比，相比去年幾乎增加了 1 倍，但是這樣的高峰卻只有 1 小時左右。為了讓交易的成本降低，從 2014年開始，我們一方面通過阿里雲的公有彈性雲資源降低成本，另一方面也開始研究混部相關的技術。

混部能產生這麼大的幫助，可是業界能使用在生產的沒有幾家公司，其原因也非常簡單，第一個是規模，第二個是技術門檻。當你機器規模不夠大的時候，顯然意義不大。而在技術上，計算型任務通常都可以把利用率跑到很高，如果計算型任務和線上型業務執行在同一臺機器上，怎麼避免計算型任務的執行不會對線上型業務的響應時間等關鍵指標不產生太大的影響呢，這個需要在技術上有全方位的突破，而阿里巴巴從無到有，花了 4 年多的時間才讓這項技術在電商域得以大規模落地。

• 2014 年，我們最主要的工作是進行技術論證，方案設計，以及相關的一些實驗性研究

• 2015 年，我們開始了日常測試環境的測試工作。這一期間讓我們總結了相當多的問題：如排程融合問題、資源爭搶隔離問題、儲存依賴問題、記憶體不足問題等等

• 2016 年，當我們把大部分問題都解決掉時，我們開啟了線上 200 臺左右的小規模驗證。由於電商的金融屬性，對於抗干擾要求特別高，在不斷的業務考驗下，我們不停地修正著技術方案

• 2017 年，經過一年的磨合，混部的整體技術終於走向了成熟和大規模生產。阿巴巴雙十一當中，約有 1/5 的流量是跑在混部叢集之上

混部非混部叢集資源使用對比圖

在日常情況下，我們可以把線上服務的叢集的 CPU 利用率從非混部的 10%提升到混部的 40% 以上，整體的成本節省在 30% 以上。而線上受到的干擾在 5%以內。

混部非混部叢集平均服務響應時間對比圖

混部排程的架構

混部排程的架構示意圖

在混部叢集中，我們的兩個排程平臺同時自主執行，sigma 管理線上服務容器的排程，而 Fuxi 管理 ODPS 上的的計算任務。為了讓這兩個排程器能一起進行工作，在中間我們使用了零層與零層管控來協調兩者之間的資源分配。

1. 線上服務容器排程器 Sigma 的特點是：

• 相容 Kubernetes 的 API，和開源社群共建

•  採用阿里相容 OCI 標準的 Pouch 容器

• 經歷過阿里多年的大規模使用和雙十一的驗證

2. 計算任務排程器 Fuxi 的特點是：

• 面向海量資料處理和大規模計算型別的複雜應用

• 提供了一個數據驅動的多級流水線平行計算框架，在表述能力上相容 MapReduce，Map-Reduce-Merge，Cascading，FlumeJava 等多種程式設計模式

• 高可擴充套件性，支援十萬以上級的並行任務排程，能根據資料分佈優化網路開銷。自動檢測故障和系統熱點，重試失敗任務，保證作業穩定可靠執行完成

3. 通過零層的資源協調機制，讓整個叢集平穩地管理並執行進來：

• 混部叢集管理

• 各排程租戶之間的資源配比

• 日常與壓測大促等時段的策略

• 異常檢測與處理

混部的資源隔離

在混部中，放在首位的就是資源隔離問題，如果隔離問題沒做好，競爭問題沒解決，那就很容易引發線上的問題。輕一點，讓使用者的感官體驗變差；重一點，引發線上故障，造成無法服務的惡劣影響。

而解決資源競爭的問題，主要從兩個方面出發：

1.排程：通過資源畫像的技術，在資源真正發生競爭之前，就預測規劃好，儘量減少這種情況發生的可能性。它是主動觸發，可以不斷優化，但延時較高。

2.核心：在資源真正發生競爭的極端情況下，根據任務的優先順序，如何做到既能保障高優先順序任務不受影響，又能控制影響到的低優先順序任務傷害最低。它是被動觸發，保底的必須手段，生效快。

在排程上，我們主要從以下方面進行優化：

1.日常的分時複用：由於波峰波谷的存在，線上服務與計算任務在一天中的峰值正好可以產生互補的情況，所以我們可以通過白天夜晚的分時複用提高資源的使用效率。

• 對叢集進行資源使用的畫像

• 線上服務凌晨 1-6 點為低峰，離線是高峰，針對這一特性進行水位調整

• 通過線上服務資源畫像智慧挑選空閒容器進行 offline 處理

2.大促的分時複用：電商類業務由於大促的存在，在大促或壓測的時候會產生比平時高几倍十幾倍的壓力差，如果這個時候對計算任務的資源進行降級讓給線上服務全使用，就可以輕鬆地支撐起那短暫的脈衝壓力。

• 日常態，計算任務佔用線上服務的資源

• 大促態，線上服務佔用計算任務的資源

• 1 小時快速完成切換，提高資源的利用

3.無損有損降級：線上服務會有一些特定的業務高峰時間，比如壓測，比如大促等。那麼如何在降級計算任務的時候，帶來的影響儘可能小呢？這裡我們就需要對降級的方案做特殊的處理。

• 無損降級：由於線上服務的 NC 平均利用率不高，再加上 70% 的計算任務小於 3 分鐘，那麼只要壓測或大促在降級之後的 5 分鐘，計算任務對於線上服務的干擾就不會那麼大了。另一個問題是做到分鐘級的恢復，這樣只有當線上服務的真正高峰才會受到影響，而這個時間段又是比較短的，那麼影響就會降低。

• 有損降級：當線上服務受到嚴重影響的時候，我們也可以做到秒級的 Kill，迅速恢復，讓線上服務的影響降到最低。

4.計算任務選取：計算任務我們比喻成沙子，但是沙子也有大有小，也需要對沙

子進行篩選，才能把空隙填充滿但又不溢位。

• 對作業進行資源使用的畫像，分析出作業需要消耗的資源。

• 通過 0 層來獲得宿主機剩餘的確切計算資源能力

• 挑選符合條件的最佳作業，儘可能最大利用，也儘可能降低競爭。

5.動態彈性記憶體：由於我們的存量資源並沒有考慮到混部，記憶體與 CPU 都是按照線上服務原來的使用配比，並沒有富餘的記憶體存在，但是由於計算增加了，記憶體就成了瓶頸，原來線上服務以靜態分配記憶體的方式就不再適合。

• 線上服務的記憶體加入共享分組

• 基於線上服務的實際記憶體使用，動態調整計算任務佔用的記憶體水位

• 當線上服務壓力突增時，通過遷移或 Kill 任務的方式，自動降級計算任務的內存水位。計算任務釋放記憶體後，核心馬上進行資源回收

• 當整機發生 OOM 時，優先殺計算任務中優先順序低的任務

6.儲存計算分離：線上服務是重 IOPS，但是儲存量不大，所以使用的都是SSD 的小盤；而計算任務都是重儲存量，但 IOPS 不大，所以使用的都是HDD 的大盤。而在混部的時候，如果還是以本地盤的方式來處理資料，計算混雜在一起，對於排程複雜度是幾何級的提升。所以我們需要把本地盤虛擬化成統一的儲存池，通過遠端的方式，根據不同的需求訪問不一樣的儲存裝置。另外阿里也開始大規模建設 25G 的網路設施，整個網路能力提升，也讓遠端訪問變得像本地一樣快。

核心隔離，我們主要從以下方面進行處理 :

1. CPU 排程優化：這是隔離當中最重要的一項，當線上業務使用 CPU 壓力上升，計算任務必須要毫秒級的自適性退出。

● CPU 搶佔 

○ 按照 CGroup 分配優先順序 (cpu.shares)

○ 高優先順序任務可以搶佔低優先順序任務的時間片

● 規避 HT（noise clean）

○ 避免離線任務排程到線上任務相鄰的 HT 上

○ 保證已經執行的離線任務在線上任務於相鄰 HT 上喚醒後遷走

● L3 Cache 隔離

○ 通過 BDW CPU 的特性 CAT 來進行對 Cache 訪問的流量控制，進而達到

限制低優先順序計算任務對 CPU 的佔用。

● 記憶體頻寬隔離

○ Memory Bandwidth Monitoring ，通過時實監控來進行策略調整

○ Cfs bandwidth control 調節計算任務執行時間片長度。通過縮短時間片，

讓高優先順序任務更容易獲得佔用 CPU 的機會。

2. 記憶體保護

● 記憶體回收隔離

○ 按照不同的 CGroup 分配優先順序

○ 增加組內回收機制，避免全域性記憶體回收干擾線上任務

○ 按優先順序確定記憶體回收的權重，線上任務的記憶體被回收的更少

● OOM 優先順序

○ 整機 OOM 時，優先殺低優先順序任務

3. IO 分級限制

● 檔案級別的 IO 頻寬隔離 ( 上限 )

○ 新增 blkio 的控制介面

○ 限制 IOPS，BPS

● 檔案級別的保低頻寬 ( 下限 )

○ 允許應用超出保底頻寬後使用富餘的空閒頻寬；

● Metadata throttle

○ 限制特定操作的 metadata 操作，例如一次性刪除大量小檔案。

4. 網路流量控制

● 頻寬隔離

○ 隔離本機頻寬（TC）

○ Pouch 容器間的頻寬隔離

● 頻寬共享（金、銀、銅）

○ 在離線間可以存在共享頻寬

○ 程序間按照優先順序可以搶佔頻寬

混部的未來規劃

混部技術經過四年的磨鍊，終於在 2017 支撐起了阿里巴巴雙十一核心交易流量的 20%，並且也作為阿里巴巴未來資料中心建設的標準技術。而在未來的一年中，混部技術會向更精細化的排程能力演進。

在場景上，會更多元化，無論是實時計算，還是 GPU，甚至是 FPGA，都能夠混部在一起。在規模上，也會從十萬核級別的叢集往百萬核級別的叢集擴充套件。在資源畫像能力上，會引入更多的深度學習，提高預測的準確性，為利用率再次大幅度提升打基礎。在排程能力上，會建立更加完善的優先順序體系，在資源分配與協調上不會以線上服務和計算任務來區別，而是以通用的優先順序來排程，解決更多資源型別部混問題。總結一句話，讓混部真正成為排程的一種通用能力。

你可能還喜歡

點選下方圖片即可閱讀

免費下載！

關注「阿里技術」

把握前沿技術脈搏