阿里妹導讀：混部是什么？把集群混合起來，將不同類型的任務調度到相同的物理資源上，通過調度，資源隔離等控制手段 , 在保障 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 上的的計算任務。為了讓這兩個調度器能一起進行工作，在中間我們使用了零層與零層管控來協調兩者之間的資源分配。

在線服務容器調度器 Sigma 的特點是：

兼容 Kubernetes 的 API，和開源社區共建

采用阿里兼容 OCI 標準的 Pouch 容器

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

計算任務調度器 Fuxi 的特點是：

面向海量數據處理和大規模計算類型的復雜應用

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

高可擴展性，支持十萬以上級的并行任務調度，能根據數據分布優化網絡開銷。自動檢測故障和系統熱點，重試失敗任務，保證作業穩定可靠運行完成

通過零層的資源協調機制，讓整個集群平穩地管理并運行進來：

混部集群管理

各調度租戶之間的資源配比

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

異常檢測與處理

混部的資源隔離

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

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

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 的網絡設施，整個網絡能力提升，也讓遠程訪問變得像本地一樣快。

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

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 的機會。

內存保護

● 內存回收隔離

○ 按照不同的 CGroup 分配優先級

○ 增加組內回收機制，避免全局內存回收干擾在線任務

○ 按優先級確定內存回收的權重，在線任務的內存被回收的更少

● OOM 優先級

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

IO 分級限制

● 文件級別的 IO 帶寬隔離 ( 上限 )

○ 新增 blkio 的控制接口

○ 限制 IOPS，BPS

● 文件級別的保低帶寬 ( 下限 )

○ 允許應用超出保底帶寬后使用富余的空閑帶寬；

● Metadata throttle

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

網絡流量控制

● 帶寬隔離

○ 隔離本機帶寬（TC）

○ Pouch 容器間的帶寬隔離

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

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

○ 進程間按照優先級可以搶占帶寬

混部的未來規劃

混部技術經過四年的磨煉，終于在 2017 支撐起了阿里巴巴雙十一核心交易流量的 20%，并且也作為阿里巴巴未來數據中心建設的標準技術。而在未來的一年中，混部技術會向更精細化的調度能力演進。

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

總結

以上是生活随笔為你收集整理的揭秘！阿里数据中心大幅降低成本的核心技术：混部技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。