全方位對比Mesos、Omega和Borg

谷歌最近公布了他們基礎設施系統王冠上的寶石之一：Borg，集群調度系統。這促使我重新閱讀了Mesos和Omega論文，它們與Borg的功能類似。我覺得對比下這三個系統一定會非常有趣。Mesos兩級調度的突破性理念得到了認可，Omega使用類似數據庫的技術有所改進，Borg可以看作是對所有這些思想的巔峰之作。

背景

集群調度系統在大數據出現之前就存在已久。在高性能計算（HPC）的世界中，關于上千核CPU的調度有豐富的文獻，但他們的問題域比數據中心調度系統要解決什么更簡單，到底該用Mesos/Borg還是與他們同類的其他產品。讓我們從幾個維度對他們進行一次對比。

為具體位置而調度

超級計算機將存儲和計算分離，并使用近似于全等分帶寬的網絡連接起來，其運行速度接近內存速度（GB/秒）。這意味著我們的任務可以放置在集群上的任何地方，而不必考慮具體位置，因為所有計算節點都可以同樣快速地訪問數據。一些超優化的應用優化了網絡拓撲，但這畢竟是非常罕見的。

數據中心調度系統會關心具體位置，實際上，這是GFS和MapReduce共同設計的結果。回眸2000年初，那時的網絡帶寬遠比磁盤帶寬昂貴。所以，為了經濟上極大的節約，調度算法會將計算任務保持在與數據相同的節點上。這是調度主要的約束;在我們可以把任務放到任何地方之前，需要將其放在三個數據副本之一的節點上。

硬件配置

超級計算機通常由同質節點組成的，即它們都具有相同的硬件規格。這是因為，超級計算機一般是一次性購買的：實驗室獲得幾百萬美元的采購費用，然后一次全部預支出去。一些高性能計算應用的優化是針對超級計算機中特定型號的CPU的。新技術，如圖形處理器和協處理器的推出，就要作為一個新的集群。

在大數據領域，集群主要受存儲限制，因此運維不斷地增加新的機架，更新規格來擴展群集容量。這意味著節點可以有不同的CPU、內存容量、磁盤數量等。這樣的節點還可以配入指定的附加設備，如固態硬盤、圖形處理器、重疊驅動器（shingled drive）等。一個數據中心可能要支持廣泛的應用，而這一切又會強加額外的調度約束。

隊列管理和調度

在超級計算機上運行應用程序時，你需要指定想要多少個節點、要提交作業的隊列，以及作業將運行多長時間。隊列存儲可以請求多少資源、作業可以運行多久等不同的限制。同時，隊列也有優先級或基于系統的預留來確定排序。由于作業的持續時間都是已知的，這是一個非常簡單的打包到盒子的問題。如果隊列很長（通常就是這樣），并有可以很好融合的小作業回填大作業（也是典型）的剩余空間，則可以實現非常高的資源利用率。我很喜歡將這一描述用以時間為X軸，以資源使用為Y軸的可視化2D圖呈現出來。

如前所述，數據中心的調度是一個比較普遍的問題。資源請求的“形狀”可以是相當多樣，并有更多的維度。作業也沒有設定持續時間，所以很難預先計劃隊列。因此，我們有更復雜的調度算法，從而，調度器的性能變得非常重要。

利用率作為一般的規則將變得糟糕（除非你是谷歌，以及更多的后來者），但高性能計算之上的應用有一個優勢是可以使用MapReduce和類似的技術逐漸代替組調度。高性能計算，會等到請求所需的N個節點都可用后，同時運行所有任務。MapReduce可以在多次波動中運行它的任務，這意味著它仍然可以有效地利用剩余的資源。單一的MR作業也可以基于集群的需求起伏，避免了搶占或資源預留，并且還有助于實現多用戶之間的公平性。

Mesos

Mesos的出現早于YARN，并且在設計時考慮了原有MapReduce的問題。當時，Hadoop集群只可以運行一種單一的應用：MapReduce。這使得它很難運行不符合先是map階段后是reduce階段的應用程序。這里最好的例子是Spark。在Mesos出現之前，你必須為Spark安裝一套全新的worker和master，這一套設置與MapReduce的worker和master放在一起。這么做，從利用率的角度來看非常不理想，因為他們通常是靜態分區的。

通過為所有集群應用提供一個通用調度器，Mesos解決了這一問題。MapReduce和Spark被簡單地作為不同的應用程序，他們可以使用相同的基礎資源，共享Mesos的Framework。最簡單的實現方法是寫一個集中式的調度器，但具有如下一些缺點：

• API的復雜性：我們需要一個單一的API，它是所有已知Framework調度器API的超集。這本身就是一個難題。資源請求也會變得非常復雜。
• 性能：成千上萬個節點和數百萬的任務實在太多，特別是當調度問題很復雜的時候。
• 代碼的靈活性：要為新的需求，持續編寫新的調度器和新的Framework。

相反，Mesos引入了兩級調度的理念。Mesos將每個應用程序的調度工作委派給應用程序本身，同時，Mesos仍然負責應用和執行整體公平性之間的資源分配。因此，Mesos可以做得相當薄，只有10K行代碼。

兩級調度通過一個名為資源邀約的新API發起，Mesos會周期地為應用程序調度器提供一些資源。這咋聽起來很落后（請求要從master到應用程序？），但其實這一點都不奇怪。在MR1中，TaskTracker worker是實際的運行節點。當TT心跳報告任務完成后，JobTracker會選擇別的任務讓TaskTracker運行。調度決策本質上是由 worker上的資源邀約觸發的。在Mesos中，資源邀約來自Mesos master，而不是slave，因為Mesos在管理集群。沒有什么不同。

資源邀約扮演著對資源有時間限制的租約。基于優先級或公平份額策略，Mesos向應用程序提供資源。然后，應用程序會計算如何使用他們，并且告訴Mesos資源邀約中它想要的那部分資源。這給了應用程序很大的靈活性，因為它可以選擇現在運行任務的一部分、等待后面更大的分配（組調度），或者調整任務的大小以適應可用的資源。由于邀約是有時間限制的，這也激勵了應用程序去實現快速地調度。

一些問題及解決辦法：

• 長任務占用資源：Mesos允許為短任務預留一些資源，時間期限一到便殺死他們。這也激勵了用戶使用短任務，它具有很好的公平性。
• 性能隔離：使用Linux容器（cgroups）。
• 大型任務饑餓：很難得到一個節點的唯一訪問權，因為一些具有較小任務的其他應用程序會蠶食它。可以通過設定請求資源的最小規模來修復這一問題。

尚未解決的/未知的決定：

• 組調度：我認為，無法預知任務長度或者搶占不可能做到高利用率。可以使用低利用率來增量囤積資源，但這可能會導致死鎖。
• 跨應用程序搶占很也難：資源邀約API沒有辦法說“這里有一些低優先級的任務，如果你想要，我可以殺掉他們。”Mesos實現公平性取決于任務必須是短期的。

Omega

Omega是Mesos的繼任者，事實上，是同一作者。由于論文采用模擬結果做評估，所以我懷疑它永遠不會進入谷歌的生產，而其中的想法會進入下一代Borg中。改寫API可能是太侵入性的變化，即使是谷歌。

Omega讓資源邀約更進一步。在Mesos中，資源邀約是悲觀的或獨占的。如果資源已經提供給一個應用程序，同樣的資源將不能提供給另一個應用程序，直到邀約超時。在Omega中，資源邀約是樂觀的。每個應用程序可以請求群集上的所有可用資源，沖突在提交時解決。Omega的資源管理器基本上只是一個記錄每個節點狀態的關系數據庫，使用不同類型的樂觀并發控制解決沖突。這樣的好處是大大增加了調度器的性能（完全并行）和更好的利用率。

所有這一切的缺點是，應用程序是在一個絕對自由的環境中，他們可以以最快的速度吞噬他們想要的資源，甚至搶占其他用戶的資源。對谷歌來說這沒問題，因為他們使用基于優先級的系統，并且可以向他們的內部用戶咆哮。他們的應用大致只分為兩種優先級：高優先級的服務性作業（如HBase、web服務器、長住服務等）和低優先級的批處理作業（MapReduce和類似技術）。應用程序可以搶占低優先級的作業，并且在協作執行限制的范圍＃內授信，以提交作業、計算資源分配等。我認為雅虎沒法沖著用戶大叫（當然是不可擴展的），但這在谷歌某種方式上是可行的。

論文的大部分在談論這種樂觀的分配方案如何與沖突一起工作的，這永遠是個問題。有一些高級的注意事項：

• 服務性作業都較大，對（跨機架的）容錯有更嚴格的配置需求。
• 由于在分配完全群集狀態上的開銷，Omega大概可以將調度器擴展到十倍，但是無法達到百倍。
• 秒級的調度時間是典型的。他們還比較了十秒級和百秒級的調度，這是兩級調度的好處真正發揮作用的地方。無法確定這樣的場景有多普遍，也許是由服務性作業來決定？
• 典型的集群利用率約為60％。
• 在OCC實踐中，沖突非常罕見。在調度器崩潰之前，他們能夠將正常批處理作業上升6倍。
• 增量調度是非常重要的。組調度明顯更昂貴，因為要增加沖突處理的實現。顯然，大多數的應用程序可以做好增量，通過實現部分資源分配進而達到他們所需的全額資源。
• 即使執行復雜的調度器（每作業十余秒的費），Omega仍然可以在合理的等待時間內調度一個混合的作業。
• 用一個新的MapReduce調度器進行實驗，從經驗上說，在Omega中會非常容易。

開放式問題

• 在某些時候，因為高沖突率和重試導致的重復工作，樂觀并發控制會崩潰。在實踐中他們好像沒有碰到這種問題，但我不知道是否有奇形怪狀的任務致使出現最壞的場景。這是受服務和批處理作業聯合影響的嗎？在實踐中他們做過什么調優嗎？
• 是否缺乏真正可以接受的全局策略？如公平性、搶占等。
• 不同類型的作業調度的時間是多少？有人已經寫出非常復雜的調度器嗎？

Borg

這是一個具備生產經驗的論文。與Omega有相同的負載作業量，因為它也出自谷歌，所以很多元點都是一樣的。

高級功能

• 谷歌的一切都在Borg中運行，包括像CFS和BigTable這樣的存儲系統。
• 平均集群大小為10K個節點，雖然還有更大集群。
• 節點可以是異構的。
• Borg使用了Linux進程隔離技術（基本上就是容器技術），因為Borg的出現早于現代虛擬機基礎架構。效率和啟動時間是很重要的。
• 所有作業都是靜態鏈接的二進制文件。
• 有非常復雜、非常豐富的資源規范語言。
• 可以滾動更新運行的作業，更新可以是配置和二進制文件。有時這需要任務重新啟動，所以容錯很重要。
• 通過SIGTERM支持“正常停止”，否則通過SIGKILL最終殺掉進程。軟殺進程是可選的，但從正確性上說是不可靠的。

Alloc

• 資源分配從進程活躍度中分離。Alloc可以用于為任務組資源分配，或者為重新啟動的任務保留資源。
• Alloc集合是一組在多臺機器上的Alloc。多個作業可以在一個單一的Alloc中運行。
• Alloc實際上是一種很常見的模式！對于分離問題與實現，多進程是有用的。

優先級和配額

• 兩級優先級：服務性的高優先級和批處理的低優先級。
• 更高的優先級作業可以搶占低優先級的。
• 高優先級的作業不能彼此搶占（在防止級聯活鎖的情況下）。
• 配額用于接入控制。用戶支付更多的配額獲得更高的優先級。
• 運行在最低優先級還提供了“自由”層，以鼓勵高利用率和回填工作。
• 這是一個簡單易懂的系統！

調度

• 兩個階段調度：找到可行的節點，然后為最終放置對這些節點評分。
• 可行性在很大程度上由任務約束決定。
• 評分主要由系統屬性決定，比如最適合與最不適合、作業組成、故障域、具體位置等。
• 一旦最終節點被選擇，Borg將搶占該節點的資源以適應需求。
• 典型的調度時間是25秒左右，這依賴于具體節點的本地化。下載二進制占這個時長的80％。這個具體位置很重要。 Torrent和樹協議用于分發二進制文件。

伸縮性

• 集中化一直是潛在的性能瓶頸。
• 針對成千上萬個節點，每分鐘調度的速率為10K任務。
• 典型的Borgmaster使用10-14個內核和50GB內存。
• 隨著時間推移，參照Omega和兩級調度，Borg架構已經變成更多的多進程。
• Borgmaster是獨立的主節點，但有些責任依然共享：worker狀態的更新、只讀的RPC。
• 一些明顯的優化：緩存的機器分數、每種任務類型計算一次的可行性，在做調度決策時，不要試圖全局最優。
• 對較大單元的主要爭論是隔離操作錯誤和失敗的傳播。架構保持良好的伸縮性。

利用率

• 他們的主要的度量指標是單元壓縮，或者說還有空間容納一組任務的最小集群。從本質上講是打包裝箱。
• 主要收益來自以下幾點：不分隔作業或用戶、有很大的共享集群、細粒度的資源請求。
• 基于Borglet的樂觀過量使用。 Borglets做資源估算，然后回填非prod工作。如果估計不正確，殺掉非prod工作。內存是無彈性的資源。
• 共享不會顯著影響CPI（CPU干擾），但我不知道對存儲是否有影響。

經驗教訓

這里列出的問題多數在他們的公開的、開放源碼的容器調度系統Kubernetes中已經修復。

缺點：

• 對于跟蹤和管理來說，調度多作業的工作流程要比調度單一的作業更好。關于工作流組件，還需要更靈活的方式。解決辦法是可以將任意的鍵值對附加到每個任務上，并允許用戶對其進行查詢。
• 每臺機器一個IP。這會導致一臺機器上的端口沖突，以及復雜的綁定和服務發現。可以通過Linux的命名空間、IPv6和SDN來解決。
• 復雜的規范語言。知識點太多，作為一個普通用戶很難上手。自動化確定資源請求需要一些工作。

優點：

Alloc非常牛！輔助服務可以很容易置入下一個主任務。后臺服務，如負載均衡服務和命名服務是非常有用的。度量、調試、網頁界面都很重要，用戶能通過他們解決自己的問題。集中化的可擴展性很好，但需要將其拆分到多個進程中。為此，Kubernetes從新開始，為不同調度器組件提供一套干凈的 API。

結束語

YARN看上去借鑒了Mesos和Omega，使伸縮規模到達10K節點。與Mesos和Omega相比，YARN仍然是一個集中式的調度系統。Borg特別強調要分片伸縮。

為了實現高利用率而不損害服務水平目標（SLO），隔離是非常重要的。這可以在應用程序層面來實現，而應用服務本身需要設計為延遲容忍的。想想在 BigTable中，為避免請求延遲（tail-at-scale）采用的向副本發起請求。最終，問題歸結為是要硬件來做隔離還是軟件來做。保持運行于利用率較低的狀態可以回避這一問題。或者，你可以直接通過OS的隔離機制、資源評估和調整你的作業和調度器來解決。在谷歌的規模下，有足夠的硬件、可以招一批內核開發工程師來實現。幸運的是，他們為我們做足了工作 :)

我也想知道，是否谷歌的假設作業更具備普遍性。谷歌能很好地使用優先級分類、資源預留，以及搶占，但是我們的客戶幾乎全部使用公平共享調度器。雅虎使用容量調度器。 推ter使用的公平調度器。我沒有聽說過的關于優先級+資源預留調度器的任何需求或使用。

最后，很少有客戶會運行在谷歌預想的大共享集群上。我們的客戶在使用千級的節點，但是這被分為百級的pod節點上。為單獨的用戶或者應用程序獨立部署集群也是常見的。集群在硬件方面通常還是同構的。我認為這將開始改變，并且會很快。

原文鏈接：mesos, omega, borg: a survey