百度大規模戰略性混部系統演進

我今天給你們分享的題目是《百度大規模戰略性混部系統演進》，主要介紹三個方面的內容：第一部分是背景，即咱們爲何要作混部。第二部分是混部的方案，我主要圍繞兩個方面去介紹，一是混部形態下核心的資源管理架構，我會介紹一下百度資源管理架構究竟是什麼樣的，咱們在線資源管理架構與離線資源管理架構的技術棧以及它的演進流程；二是混部核心技術，這裏包括咱們怎麼去作容器的隔離，怎麼去作資源的超發以及資源模型的優化。最後是收益和將來展望的部分。

爲何要作混部

首先，一個經典的互聯網公司成本的構成大概是三個方面，第一是研發成本，也就是你我你們的成本，研發人員的工資。第二個是互聯網運營成本，包括線上線作廣告、營銷等各類各樣的成本，這些成本也是不可忽視的，固然咱們今天主要是講的第三個成本，也就是建 IDC 與服務器的成本，這個成本也是經典互聯網公司成本構成很是重要的一個部分。

咱們怎麼去下降公司的成本？提高資源利用率其實就是下降服務器成本的一個很是重要的手段。

資源利用率現狀分析

咱們在作機房規劃的時候有一個很是大的特色，就是離線機房與在線機房分離作規劃。舉個例子，假如咱們在寧夏作一個機房，這個時候確定考慮作一個離線機房，由於在線機房須要考慮網民請求分佈的問題，要得到最好的訪問優化體驗以及訪問速度，勢必須要在一些訪問熱點上去作本身的機房規劃，好比北京、上海、廣州這樣的地方。而對於離線機房來講不用關心這些，它最在意的是如何提高計算和儲存的資源和基礎設施的規模。

在線機房與離線機房分別規劃存在一個很是大的矛盾點，在於在線業務和離線業務自己的資源需求和特色不同，咱們的資源利用率很是不均衡。對離線來講，它是須要大規模的數據計算和日誌數據儲存和 AI 訓練，它的利用率常態很是高，隨着業務的增加它的資源也是常態不足。而對於在線來講，在線須要作大容量資源災備和高低分的冗餘，它的利用率很是低。

咱們能夠初步經過這個現狀分析到，只有將離線、在線機房統一規劃纔可以充分使用資源，提高資源利用率，從而減小在線與離線服務器採購成本。

混部架構與核心技術

接下來主要講一下混部的方案與核心的架構，這裏面主要講三個點，一是百度的在離線混部思路，二是百度內部是如何在混部這條路徑上發展的，三是混部的資源架構在百度內部是什麼樣的形態。

在離線混部思路

首先仍是從基礎提及，什麼叫在離線混部？能夠從兩個方面去解釋，一是機房統一規劃，咱們將在線機房與離線機房統一規劃成一個混部機房。二是業務混合運行，咱們的在線服務和離線做業同時混合在一臺機器上運行。這二者構成了「在離線混部」。

在離線混部的難點在於，咱們須要——

1）保證在線不受到影響：在線與離線混合在一塊兒，對離線來講每每是很是耗 CPU 和內存一些業務，咱們須要保證離線不要影響在線，在線不會由於 CPU 的干擾而致使一些服務的延遲或者故障；

2）保證離線運行良好：在保證在線不受影響的同時，也須要保證離線運行良好，由於咱們作混部實際上要節省離線資源，最終是要給離線作預算的交付；

3）挖潛更多的混部資源：在保證一和二兩點的同時，咱們還須要挖掘更多的混部資源，要去考慮怎樣把 CPU 利用率作到更加極致。

咱們今天主要是從前兩個方面的難點出發去闡述百度是怎麼樣作在離線混部的。

百度混部演進歷程

簡單給你們介紹一下百度混部的演進歷程。

百度從 2012 年就開始嘗試進入混部技術領域，研發並推廣了代理計算（BVC/IDLE）系統。BVC 是咱們的搜索業務團隊在作的一套資源混部系統，叫代理計算，IDLE 是 INF 團隊當年作的基於進程的一套混部系統，這兩套系統當年都承擔了在離線混部一些工做，但因爲架構上受限、資源隔離方案不完備，最終混部出來的計算資源都是不可靠的。

2012 年的時候，咱們開始啓動 Matrix， 2014 年 Matrix 全面上線，成爲了百度虛擬化、容器化的基礎設施，目前在百度內部全面應用，而且託管了全部機器。

2014 年，咱們也作了另一個事情，就是將百度全部離線分佈式計算框架所有統一到一個資源管理平臺，叫 Normandy。這裏說到的離線計算框架包括 MapReduce、Spark、MPI 還有機器學習框架等各類分佈式計算框架。

2015 年，百度正式啓動戰略性混部 2.0 項目千尋，而且已經上線。這套系統徹底構建在 Matrix 之上，也就是說它是一套容器化的在離線混部的基礎設施，而且在 2015 年的時候達到數萬臺的規模。

2017 年，千尋混部規模呈現更快速增加，在此期間咱們作了大量資源隔離與混部核心技術的研究和推廣。

2019 年，百度混部的規模已經達到數十萬臺，這是很是規模化的飛躍，全部新交付的機器已經所有交付給在離線混部，新的機器已經所有能夠在線機器和離線機器同時運行。

混部技術棧

這張圖是百度的混部技術棧。最底層的部分是機器管理系統 Matrix-Ultron，它託管了百度全部的服務器，實現了整個機器生命週期管理，包括機器自動維修、環境一致性，還有資源化交付等核心工做。

在 Matrix-Ultron 之上就是咱們說的 Matrix ，Matrix 咱們能夠經過多個角度去理解它，首先它是一個容器引擎，相似百度的 Docker，另外 Matrix 自己也支持了開源件 Docker 運行時和鏡像協議。Matrix 也支持實例管理、資源模型和資源隔離，Matrix 在單機上作了資源建模，而且提出了優先級資源模型，經過一系列內核態和用戶態的技術實現了隔離。資源模型和資源隔離也是混部的核心基礎。

在 Matrix 之上承載了三個系統，第一個是在線調度系統。第二個是離線調度系統 Normandy。第三個就是最右邊的 AFS 文件系統，它是一套託管文件和磁盤的系統。

在調度系統之上，還有在線 PaaS 系統、MR/Spark 批量計算引擎和 MPI/Paddle 機器學習框架。對於在線 PaaS 來講，目前百度內部有兩套系統，分別是 Opera 和 Beehive，分別服務於搜索和非搜索的業務。MR/Spark 批量計算引擎和 MPI/Paddle 機器學習框架則處於離線調度系統之上。AFS 做爲 PaaS 系統提供文件服務。

最上面一層是在線服務和離線做業，包括百度內部的全部的業務，這裏面有搜索、Feed、鳳巢、網盤、度祕、無人車和地圖等各類各樣的業務。

混部的理論基礎

混部的理論基礎很簡單，咱們須要有一套在線與離線在單機上運行的規範，這個規範核心設計點有兩套，第一個是基於優先級，第二個須要有超發，由於對於在線來講 Quota 申請每每是按照峯值去申請的，必定會產生資源冗餘，咱們如何讓離線混部上去？須要有一套完整的超發模型，既然有超發以後，咱們須要模擬在線與離線兩個優先級去對單機上資源優先級進行建模，百度內部基於 Matrix 優先級分爲三個 Band，第一個是在線優先級 Stable，其餘的兩個 Normal 和 Besteffort 都表示離線優先級，Normal 表示我須要有必定的 SLA，它是基本穩定的，Besteffort 表示我是零計費，我不穩定，可是你能夠運行。

這裏面最核心的部分就是超發模型。當用戶 request – used > 0，咱們能夠經過 reclaim 單機資源模式實現整機上的超發。咱們這裏說的 total 其實就等於，對離線優先級來講，它整機資源 total’就等於 total 單機物理資源，再加上咱們超發資源，即 total’= total + sum(request – used)。

混部的核心思路

這是咱們在混部上單機在線與離線運行的一套規則規範，這裏面有一個很是核心的點，一旦咱們實現了超發，勢必就須要考慮當資源發生競爭時咱們處理的行爲，這就是咱們講的混部的核心思路，咱們怎麼去解決單機上一旦發生資源競爭處理行爲。

最主要從兩個方面解決這個問題，一是經過單機資源隔離作離線避讓，二是經過集羣調度作一些有規劃的事情。單機隔離的優點很是明顯，可以作到快速避讓，響應及時。而集羣調度的響應很是慢，它的好處是能夠根據單機上的行爲，動態反饋給集羣調度作一些更加有規範的動態預測和有規劃的調度。

混部的難點有兩個，一是怎麼去保證在線不要受到影響，二是怎麼去保證離線也能運行良好。

1）如何保證在線不受影響：咱們基本思路有兩個，分別是內核和用戶態管控和離線「大框」模型。咱們本身研發的單機上的控制組件 Watch-Dog 能夠監控全部的在線與離線資源的使用和避讓的行爲，咱們經過內核態與用戶態方式同時管控離線資源使用。另外，爲了更加安全去控制離線，咱們設計了一套離線大框模型，將全部的離線運行在一個受限的大框內，對於 CPU 和內存，咱們都是經過大框綁核和內存硬限的方式去解決問題。對 IO 而言，咱們經過隔離磁盤、磁盤 IO 隔離的方式解決這個問題，同時在上層若是不能作磁盤的隔離，咱們會作各類各樣計算框架的優化。咱們在網絡層面也是經過 QoS 標籤去保證在線不要受到離線影響，同時有一套 Transkeeper 組件在離線框架內部去作了一套對內部一些帶寬的限流和規整。

在線服務有一個很是大的特色，即便離線資源使用在一個受限的範圍以內，仍然有極可能對在線受到影響，這些部分須要咱們對混部領域作更深層次的研究。咱們作了一些更加精細化資源管控策略。簡單列舉以下。

1. 離線大框綁核：根據單機 reclaim 資源量；離線內共享；

2. core-aware：快退避，慢啓動，避免 HT 干擾；

3. HT 干擾規避：自動從遷移離線做業，避免和在線服務干擾；

4. L3-cache：CAT 隔離；

5. CPI 干擾抑制：檢測、干擾源識別、避讓。

咱們着重講一下後四點。對於 care-aware 策略，當在線與離線同時運行 HT 的時候可能會受到干擾，咱們經過用戶態的方式，當在線的資源使用開始變多的時候，離線大框就須要實時收縮，咱們就作了一個快退避的策略。可是一旦在線資源使用開始收縮，這個時候離線須要經過慢啓動的方式去解決這個問題，由於離線一旦快啓動，這個時候由於 CPUrebalance 調度過慢，在線有可能還在那批 CPU 核上運行，勢必會產生干擾，即便它的資源使用是在受限大框以內，它仍然在 CPU 微架構上會對在線形成干擾，咱們經過慢啓動的方式去避免這些干擾。同時咱們在內核上也作了一些事情，即 HT 超線程干擾的規避，當在線進程在 HT 上運行，離線進程自動化遷移，避免對在線業務作干擾。同時假設在線與離線同時在 HT 核上運行，咱們也經過其餘的方式，好比說 L3-Cache 隔離的方式去避免在線業務的干擾。同時咱們也引入了 CPI 干擾的方式，去對在線服務運行質量作檢測，對在線業務檢測出來以後，對離線資源干擾源作識別，而且造成一套避讓的機制。以上主要是介紹一些精細化的管控策略。

2）保證離線運行良好：咱們接下來說一下怎麼樣去保證離線運行良好。這裏面主要有兩個部分的內容，第一個部分是咱們在單機上作了更加精細的避讓機制，另一個咱們在集羣調度層面也作了一些更好優化。

首先單機層面上咱們針對可壓縮的資源儘可能優先壓縮，被 kill 每每比壓縮好不少，離線有一些大數據的業務可能須要運行 2—3 小時，若是在即將完成以前被 kill 掉，它勢必須要重算，若是經過壓縮的方式能夠緩解這種破壞的行爲，同時對不可壓縮的資源咱們足量避讓就能夠了，不須要粗暴的所有殺掉。

第二個層面咱們經過調度優化的方式，這裏面須要回答一個問題：如何學習一套超發的資源？剛纔提到資源有優先級、有超發，怎麼去學習一套穩定的超發曲線，保證離線不要一直被避讓干擾。這裏面有一個核心的內容，就是須要在線資源使用作畫像，好比咱們看一天的值，看兩天的值，甚至看一週的值，最終學習一套穩定的曲線，使得在線資源超發可以趨於穩定，這樣的狀況下離線可以避免被殺。同時在這個基礎上創建單機上資源隔離反饋的閉環，咱們能夠經過自動化學習的方式去創建更加優化的機制。

咱們同時也對計算框架作了一些優化，好比計算 Shuffle 流式化。咱們將能夠作到兩個優點點，第一個優點咱們避免了本地磁盤 IO，由於 Shuffle 由 pull 變爲 push，且經過 FS（全內存）交換，避免了 MapReduce 各類各樣的磁盤行爲。另一個是減小了重算，它避免了 Map 端節點掛掉而致使任務重算，也作了 backup 的工做。固然，計算框架還作了不少其餘的優化去更好適應咱們的混部場景，這裏就不一一列舉了。

支撐系統建設

在混部實施過程當中，其實須要大量基礎性支持工做。

1）混部框架自動化入退場

2）機器環境一致性：網卡多隊列、內核參數等等

3）資源化交付：資源訂單至 Quota 交付，業務看不見機器

收益與將來展望

百度目前混部規模數十萬臺，它的混部集羣 CPU 利用率比在線利用率提高 40%—80%。咱們在 2016 年—2018 年實際節省數萬臺服務器的離線預算，這也是咱們混部收益。

咱們將來會作儲存與計算分離，由於這裏面一個比較大的問題，就是磁盤調度是」超維」調度，單純的磁盤調度沒有辦法很好解決磁盤利用效率這個問題。因此如今百度正在將全部的儲存磁盤資源統一至一套儲存的 IaaS 系統託管，這樣達到一個效果是可以對磁盤扁平化管理使得更快更容易去提高磁盤託管效率及利用率。

最後一點，咱們想提出這樣一個思路，就是無差異的混部，其實咱們以前作了不少好比說離線混部，咱們經過把離線計算框架所有混合在一塊兒，同時在 2017 年的時候也開始啓動在線混部，在線的合池，也作了在線的混部。那麼咱們怎麼去作無差異的混部？這個事情很難，可是其實有幾個思路，首先仍是須要定義好資源的 SLA，好比說將它分爲高優先級、低優先級，同時相對應有一套服務的 SLA 等級，一旦把這個事情作好之後，咱們資源層面就能解釋清楚對外提供的服務是什麼樣子的。另一個還須要大量的一些基礎服務的改造，好比說 MapReduce 和 Spark 目前都須要作一些預部署的工做，Spark 須要部署 NodeManager，MapReduce 須要部署 Shuffle，這些框架應該被改造以更加適合「雲原生」。

今天主要給你們介紹到這裏，總結一下剛纔說的內容。首先是說明了百度作混部的背景。另外講解了百度在混部架構上演進，以及它的歷程，包括它的核心技術是什麼樣的，以及將來的展望。今天主要給你們介紹這麼多，謝謝你們。

演講嘉賓：張慕華，百度基礎架構部資深研發工程師，畢業於天津大學取得計算機碩士學位。畢業後加入百度。前後參與或者負責 HHVM 虛擬機、分佈式計算、分佈式調度、在離線混部等多個產品或系統的研發工做。目前主要負責離線 PaaS 系統 Normandy、集羣操做系統 Matrix、在離線混部系統千尋的技術和架構建設，專一於分佈式架構、容器和調度等方向。