導(dǎo)讀：混部是什么？把集群混合起來，將不同類型的任務(wù)調(diào)度到相同的物理資源上，通過調(diào)度，資源隔離等控制手段 , 在保障 SLO 的基礎(chǔ)上，充分使用資源能力，極大降低成本，我們稱這樣的技術(shù)為混部（Co-loaction）。

背景概述

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

另一方面，全球從 IT 時(shí)代全面走向了 DT 時(shí)代，現(xiàn)在又在向更深入的 AI 時(shí)代邁進(jìn)。各各樣的大數(shù)據(jù)處理框架不斷涌現(xiàn)，從 Hadoop 到 Spark，從 Jstorm 到 Flink，甚至包括深度學(xué)習(xí)框架 Tensorflow 的出現(xiàn)，成千上萬的數(shù)據(jù)分析背后是大量的計(jì)算任務(wù)，占用了大量的計(jì)算資源。由于計(jì)算任務(wù)占用的計(jì)算量很高，CPU 水位通常在50%-60% 以上，不同于在線服務(wù)，計(jì)算任務(wù)的峰值通常出現(xiàn)在凌晨，水位甚至能達(dá)到 70% 以上。所以我們往往就會(huì)建立獨(dú)立的計(jì)算任務(wù)集群。

展開全文

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

那么同樣的原理，是否如果能讓這兩個(gè)集群混合起來部署，讓計(jì)算任務(wù)的一部分任務(wù)跑到在線服務(wù)的資源之上，把在線服務(wù)空閑的資源利用起來呢？答案是肯定的。

混部技術(shù)簡介

混部技術(shù)示意圖

把集群混合起來，將不同類型的任務(wù)調(diào)度到相同的物理資源上，通過調(diào)度，資源隔離等控制手段 , 在保障 SLO 的基礎(chǔ)上，充分使用資源能力，極大降低成本，我們稱這樣的技術(shù)為混部（Co-loaction）。

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

從原理中我們可以看到可以混部在一起的任務(wù)有兩個(gè)比較重要的特征：

1.可以劃分優(yōu)先級(jí)：一定需要優(yōu)先級(jí)比較低的任務(wù)，它們能像水和沙子一樣，隨時(shí)能被趕走，而不會(huì)受到不可承受的影響，讓優(yōu)先級(jí)高的任務(wù)不受干擾。在線的特點(diǎn)是：峰值壓力時(shí)間不長，對(duì)延時(shí)比較敏感，業(yè)務(wù)的壓力抖動(dòng)比較厲害，典型的如早上 10 點(diǎn)的聚劃算活動(dòng)，就會(huì)在非常短的時(shí)間內(nèi)，造成交易集群的壓力瞬間上升 10 幾倍，對(duì)于穩(wěn)定的要求非常高，在混部的時(shí)候，必須要保證在線的通暢，需要有極強(qiáng)的抗干擾能力。而計(jì)算任務(wù)的特點(diǎn)是：平時(shí)的壓力比較高，相對(duì)來說計(jì)算量可控，并且延遲不敏感，失敗后也可以重跑。至少需要幾分鐘跑完的計(jì)算任務(wù)，相對(duì)于幾秒甚至幾十秒的延遲，并不會(huì)產(chǎn)生嚴(yán)重的問題，正好可以承提起水和沙子的角色。

2.資源占用互補(bǔ)性：兩種任務(wù)在不同的時(shí)間點(diǎn)對(duì)水位的占用不一樣。如在線服務(wù)是，平時(shí)比較低，大促時(shí)比較高；凌晨比較低，白天比較高。而計(jì)算任務(wù)則反過來，平時(shí)比較高，大促時(shí)可以降級(jí)；凌晨非常高，白天卻要低一些。

這種方式帶來的成本節(jié)省是非常巨大的：假設(shè)數(shù)據(jù)中心有 N 臺(tái)服務(wù)器，利用率從R1 提高到 R2，不考慮其他實(shí)際制約因素的情況下，節(jié)約 X 臺(tái)，那么理想的公式是：

N*R1 = (N-X)*R2

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

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

也就是說如果企業(yè)有 10 萬臺(tái)服務(wù)器，利用率從 28% 提升到 40%，代入上述公式，就能節(jié)省出 3 萬臺(tái)機(jī)器。假設(shè)一臺(tái)機(jī)器的成本為 2 萬元，那么節(jié)約成本就有6 個(gè)億。

2015 年，Google 發(fā)表了 Borg 論文，其中就提到了在線服務(wù)與計(jì)算任務(wù)之間的混合運(yùn)行，也就是我們說的混部技術(shù)。Borg 論文中描述了 Google 由于采用了這項(xiàng)技術(shù)，為 Google 節(jié)省了 20%-30% 的機(jī)器規(guī)模。

混部技術(shù)的歷程

阿里巴巴早期混合云架構(gòu)

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

混部能產(chǎn)生這么大的幫助，可是業(yè)界能使用在生產(chǎn)的沒有幾家公司，其原因也非常簡單，第一個(gè)是規(guī)模，第二個(gè)是技術(shù)門檻。當(dāng)你機(jī)器規(guī)模不夠大的時(shí)候，顯然意義不大。而在技術(shù)上，計(jì)算型任務(wù)通常都可以把利用率跑到很高，如果計(jì)算型任務(wù)和在線型業(yè)務(wù)運(yùn)行在同一臺(tái)機(jī)器上，怎么避免計(jì)算型任務(wù)的運(yùn)行不會(huì)對(duì)在線型業(yè)務(wù)的響應(yīng)時(shí)間等關(guān)鍵指標(biāo)不產(chǎn)生太大的影響呢，這個(gè)需要在技術(shù)上有全方位的突破，而阿里巴巴從無到有，花了 4 年多的時(shí)間才讓這項(xiàng)技術(shù)在電商域得以大規(guī)模落地。

2014 年，我們最主要的工作是進(jìn)行技術(shù)論證，方案設(shè)計(jì)，以及相關(guān)的一些實(shí)驗(yàn)性研究

2015 年，我們開始了日常測(cè)試環(huán)境的測(cè)試工作。這一期間讓我們總結(jié)了相當(dāng)多的問題：如調(diào)度融合問題、資源爭搶隔離問題、存儲(chǔ)依賴問題、內(nèi)存不足問題等等

2016 年，當(dāng)我們把大部分問題都解決掉時(shí)，我們開啟了線上 200 臺(tái)左右的小規(guī)模驗(yàn)證。由于電商的金融屬性，對(duì)于抗干擾要求特別高，在不斷的業(yè)務(wù)考驗(yàn)下，我們不停地修正著技術(shù)方案

2017 年，經(jīng)過一年的磨合，混部的整體技術(shù)終于走向了成熟和大規(guī)模生產(chǎn)。阿巴巴雙十一當(dāng)中，約有 1/5 的流量是跑在混部集群之上

混部非混部集群資源使用對(duì)比圖

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

混部非混部集群平均服務(wù)響應(yīng)時(shí)間對(duì)比圖

混部調(diào)度的架構(gòu)

混部調(diào)度的架構(gòu)示意圖

在混部集群中，我們的兩個(gè)調(diào)度平臺(tái)同時(shí)自主運(yùn)行，sigma 管理在線服務(wù)容器的調(diào)度，而 Fuxi 管理 ODPS 上的的計(jì)算任務(wù)。為了讓這兩個(gè)調(diào)度器能一起進(jìn)行工作，在中間我們使用了零層與零層管控來協(xié)調(diào)兩者之間的資源分配。

1. 在線服務(wù)容器調(diào)度器 Sigma 的特點(diǎn)是：

兼容 Kubernetes 的 API，和開源社區(qū)共建

采用阿里兼容 OCI 標(biāo)準(zhǔn)的 Pouch 容器

經(jīng)歷過阿里多年的大規(guī)模使用和雙十一的驗(yàn)證

2. 計(jì)算任務(wù)調(diào)度器 Fuxi 的特點(diǎn)是：

面向海量數(shù)據(jù)處理和大規(guī)模計(jì)算類型的復(fù)雜應(yīng)用

提供了一個(gè)數(shù)據(jù)驅(qū)動(dòng)的多級(jí)流水線并行計(jì)算框架，在表述能力上兼容 MapReduce，Map-Reduce-Merge，Cascading，F(xiàn)lumeJava 等多種編程模式

高可擴(kuò)展性，支持十萬以上級(jí)的并行任務(wù)調(diào)度，能根據(jù)數(shù)據(jù)分布優(yōu)化網(wǎng)絡(luò)開銷。自動(dòng)檢測(cè)故障和系統(tǒng)熱點(diǎn)，重試失敗任務(wù)，保證作業(yè)穩(wěn)定可靠運(yùn)行完成

3. 通過零層的資源協(xié)調(diào)機(jī)制，讓整個(gè)集群平穩(wěn)地管理并運(yùn)行進(jìn)來：

混部集群管理

各調(diào)度租戶之間的資源配比

日常與壓測(cè)大促等時(shí)段的策略

異常檢測(cè)與處理

混部的資源隔離

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

而解決資源競爭的問題，主要從兩個(gè)方面出發(fā)：

1.調(diào)度：通過資源畫像的技術(shù)，在資源真正發(fā)生競爭之前，就預(yù)測(cè)規(guī)劃好，盡量減少這種情況發(fā)生的可能性。它是主動(dòng)觸發(fā)，可以不斷優(yōu)化，但延時(shí)較高。

2.內(nèi)核：在資源真正發(fā)生競爭的極端情況下，根據(jù)任務(wù)的優(yōu)先級(jí)，如何做到既能保障高優(yōu)先級(jí)任務(wù)不受影響，又能控制影響到的低優(yōu)先級(jí)任務(wù)傷害最低。它是被動(dòng)觸發(fā)，保底的必須手段，生效快。

在調(diào)度上，我們主要從以下方面進(jìn)行優(yōu)化：

1.日常的分時(shí)復(fù)用：由于波峰波谷的存在，在線服務(wù)與計(jì)算任務(wù)在一天中的峰值正好可以產(chǎn)生互補(bǔ)的情況，所以我們可以通過白天夜晚的分時(shí)復(fù)用提高資源的使用效率。

對(duì)集群進(jìn)行資源使用的畫像

在線服務(wù)凌晨 1-6 點(diǎn)為低峰，離線是高峰，針對(duì)這一特性進(jìn)行水位調(diào)整

通過在線服務(wù)資源畫像智能挑選空閑容器進(jìn)行 offline 處理

2.大促的分時(shí)復(fù)用：電商類業(yè)務(wù)由于大促的存在，在大促或壓測(cè)的時(shí)候會(huì)產(chǎn)生比平時(shí)高幾倍十幾倍的壓力差，如果這個(gè)時(shí)候?qū)τ?jì)算任務(wù)的資源進(jìn)行降級(jí)讓給在線服務(wù)全使用，就可以輕松地支撐起那短暫的脈沖壓力。

日常態(tài)，計(jì)算任務(wù)占用在線服務(wù)的資源

大促態(tài)，在線服務(wù)占用計(jì)算任務(wù)的資源

1 小時(shí)快速完成切換，提高資源的利用

3.無損有損降級(jí)：在線服務(wù)會(huì)有一些特定的業(yè)務(wù)高峰時(shí)間，比如壓測(cè)，比如大促等。那么如何在降級(jí)計(jì)算任務(wù)的時(shí)候，帶來的影響盡可能小呢？這里我們就需要對(duì)降級(jí)的方案做特殊的處理。

無損降級(jí)：由于在線服務(wù)的 NC 平均利用率不高，再加上 70% 的計(jì)算任務(wù)小于 3 分鐘，那么只要壓測(cè)或大促在降級(jí)之后的 5 分鐘，計(jì)算任務(wù)對(duì)于在線服務(wù)的干擾就不會(huì)那么大了。另一個(gè)問題是做到分鐘級(jí)的恢復(fù)，這樣只有當(dāng)在線服務(wù)的真正高峰才會(huì)受到影響，而這個(gè)時(shí)間段又是比較短的，那么影響就會(huì)降低。

有損降級(jí)：當(dāng)在線服務(wù)受到嚴(yán)重影響的時(shí)候，我們也可以做到秒級(jí)的 Kill，迅速恢復(fù)，讓在線服務(wù)的影響降到最低。

4.計(jì)算任務(wù)選?。河?jì)算任務(wù)我們比喻成沙子，但是沙子也有大有小，也需要對(duì)沙

子進(jìn)行篩選，才能把空隙填充滿但又不溢出。

對(duì)作業(yè)進(jìn)行資源使用的畫像，分析出作業(yè)需要消耗的資源。

通過 0 層來獲得宿主機(jī)剩余的確切計(jì)算資源能力

挑選符合條件的最佳作業(yè)，盡可能最大利用，也盡可能降低競爭。

5.動(dòng)態(tài)彈性內(nèi)存：由于我們的存量資源并沒有考慮到混部，內(nèi)存與 CPU 都是按照在線服務(wù)原來的使用配比，并沒有富余的內(nèi)存存在，但是由于計(jì)算增加了，內(nèi)存就成了瓶頸，原來在線服務(wù)以靜態(tài)分配內(nèi)存的方式就不再適合。

在線服務(wù)的內(nèi)存加入共享分組

基于在線服務(wù)的實(shí)際內(nèi)存使用，動(dòng)態(tài)調(diào)整計(jì)算任務(wù)占用的內(nèi)存水位

當(dāng)在線服務(wù)壓力突增時(shí)，通過遷移或 Kill 任務(wù)的方式，自動(dòng)降級(jí)計(jì)算任務(wù)的內(nèi)存水位。計(jì)算任務(wù)釋放內(nèi)存后，內(nèi)核馬上進(jìn)行資源回收

當(dāng)整機(jī)發(fā)生 OOM 時(shí)，優(yōu)先殺計(jì)算任務(wù)中優(yōu)先級(jí)低的任務(wù)

6.存儲(chǔ)計(jì)算分離：在線服務(wù)是重 IOPS，但是存儲(chǔ)量不大，所以使用的都是SSD 的小盤；而計(jì)算任務(wù)都是重存儲(chǔ)量，但 IOPS 不大，所以使用的都是HDD 的大盤。而在混部的時(shí)候，如果還是以本地盤的方式來處理數(shù)據(jù)，計(jì)算混雜在一起，對(duì)于調(diào)度復(fù)雜度是幾何級(jí)的提升。所以我們需要把本地盤虛擬化成統(tǒng)一的存儲(chǔ)池，通過遠(yuǎn)程的方式，根據(jù)不同的需求訪問不一樣的存儲(chǔ)設(shè)備。另外阿里也開始大規(guī)模建設(shè) 25G 的網(wǎng)絡(luò)設(shè)施，整個(gè)網(wǎng)絡(luò)能力提升，也讓遠(yuǎn)程訪問變得像本地一樣快。

內(nèi)核隔離，我們主要從以下方面進(jìn)行處理 :

1. CPU 調(diào)度優(yōu)化：這是隔離當(dāng)中最重要的一項(xiàng)，當(dāng)在線業(yè)務(wù)使用 CPU 壓力上升，計(jì)算任務(wù)必須要毫秒級(jí)的自適性退出。

● CPU 搶占

○ 按照 CGroup 分配優(yōu)先級(jí) (cpu.shares)

○ 高優(yōu)先級(jí)任務(wù)可以搶占低優(yōu)先級(jí)任務(wù)的時(shí)間片

● 規(guī)避 HT（noise clean）

○ 避免離線任務(wù)調(diào)度到在線任務(wù)相鄰的 HT 上

○ 保證已經(jīng)運(yùn)行的離線任務(wù)在在線任務(wù)于相鄰 HT 上喚醒后遷走

● L3 Cache 隔離

○ 通過 BDW CPU 的特性 CAT 來進(jìn)行對(duì) Cache 訪問的流量控制，進(jìn)而達(dá)到

限制低優(yōu)先級(jí)計(jì)算任務(wù)對(duì) CPU 的占用。

● 內(nèi)存帶寬隔離

○ Memory Bandwidth Monitoring ，通過時(shí)實(shí)監(jiān)控來進(jìn)行策略調(diào)整

○ Cfs bandwidth control 調(diào)節(jié)計(jì)算任務(wù)運(yùn)行時(shí)間片長度。通過縮短時(shí)間片，

讓高優(yōu)先級(jí)任務(wù)更容易獲得占用 CPU 的機(jī)會(huì)。

2. 內(nèi)存保護(hù)

● 內(nèi)存回收隔離

○ 按照不同的 CGroup 分配優(yōu)先級(jí)

○ 增加組內(nèi)回收機(jī)制，避免全局內(nèi)存回收干擾在線任務(wù)

○ 按優(yōu)先級(jí)確定內(nèi)存回收的權(quán)重，在線任務(wù)的內(nèi)存被回收的更少

● OOM 優(yōu)先級(jí)

○ 整機(jī) OOM 時(shí)，優(yōu)先殺低優(yōu)先級(jí)任務(wù)

3. IO 分級(jí)限制

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

○ 新增 blkio 的控制接口

○ 限制 IOPS，BPS

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

○ 允許應(yīng)用超出保底帶寬后使用富余的空閑帶寬；

● Metadata throttle

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

4. 網(wǎng)絡(luò)流量控制

● 帶寬隔離

○ 隔離本機(jī)帶寬（TC）

○ Pouch 容器間的帶寬隔離

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

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

○ 進(jìn)程間按照優(yōu)先級(jí)可以搶占帶寬

混部的未來規(guī)劃

混部技術(shù)經(jīng)過四年的磨煉，終于在 2017 支撐起了阿里巴巴雙十一核心交易流量的 20%，并且也作為阿里巴巴未來數(shù)據(jù)中心建設(shè)的標(biāo)準(zhǔn)技術(shù)。而在未來的一年中，混部技術(shù)會(huì)向更精細(xì)化的調(diào)度能力演進(jìn)。

在場景上，會(huì)更多元化，無論是實(shí)時(shí)計(jì)算，還是 GPU，甚至是 FPGA，都能夠混部在一起。在規(guī)模上，也會(huì)從十萬核級(jí)別的集群往百萬核級(jí)別的集群擴(kuò)展。在資源畫像能力上，會(huì)引入更多的深度學(xué)習(xí)，提高預(yù)測(cè)的準(zhǔn)確性，為利用率再次大幅度提升打基礎(chǔ)。在調(diào)度能力上，會(huì)建立更加完善的優(yōu)先級(jí)體系，在資源分配與協(xié)調(diào)上不會(huì)以在線服務(wù)和計(jì)算任務(wù)來區(qū)別，而是以通用的優(yōu)先級(jí)來調(diào)度，解決更多資源類型部混問題?？偨Y(jié)一句話，讓混部真正成為調(diào)度的一種通用能力。