Mesos、Omega和Borg三個(gè)系統(tǒng)有什么區(qū)別?

作者：翻譯：鐘最龍 2015-08-10 14:59:37

云計(jì)算 Google最近公布了他們?cè)谙到y(tǒng)基礎(chǔ)設(shè)施領(lǐng)域的一顆王冠寶石：Borg，一個(gè)集群調(diào)度器。這促使我重新閱讀論論述相同主題的Mesos和Omega的論文。我想這幾種系統(tǒng)做一個(gè)的對(duì)比會(huì)很有意思。Mesos因?yàn)槠溟_創(chuàng)性的兩層調(diào)度(two-level scheduling)理念而廣受美譽(yù)，Omega在此基礎(chǔ)上用類似數(shù)據(jù)庫(kù)的技術(shù)做了改進(jìn)，Borg可以看作是對(duì)所有這些思想的巔峰之作。

洛陽(yáng)ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書未來市場(chǎng)廣闊！成為成都創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！

Google最近公布了他們?cè)谙到y(tǒng)基礎(chǔ)設(shè)施領(lǐng)域的一顆王冠寶石：Borg，一個(gè)集群調(diào)度器。這促使我重新閱讀論論述相同主題的Mesos和Omega的論文。我想這幾種系統(tǒng)做一個(gè)的對(duì)比會(huì)很有意思。Mesos因?yàn)槠溟_創(chuàng)性的兩層調(diào)度(two-level scheduling)理念而廣受美譽(yù)，Omega在此基礎(chǔ)上用類似數(shù)據(jù)庫(kù)的技術(shù)做了改進(jìn)，Borg可以看作是對(duì)所有這些思想的***之作。

1 背景

集群調(diào)度器可謂是歷史久遠(yuǎn)，它出現(xiàn)在大數(shù)據(jù)的概念之前。在高性能計(jì)算(HPC)的領(lǐng)域里，關(guān)于如何調(diào)度成千的核心已經(jīng)有了豐富的資料，但相比于數(shù)據(jù)中心調(diào)度解決的問題，核心調(diào)度的問題范圍顯然簡(jiǎn)單很多。而Mesos/Borg等系統(tǒng)要解決的正是數(shù)據(jù)中心調(diào)度。接下來，讓我們通過幾個(gè)維度對(duì)比下它們。

1.1 調(diào)度中的局部性(Scheduling for locality)

超級(jí)計(jì)算機(jī)可以將存儲(chǔ)和計(jì)算分離，并用和內(nèi)存速度差不多的近乎全等分帶寬的網(wǎng)絡(luò)將它們連接起來。這意味著你的任務(wù)可以放在集群的任何地方，而不用擔(dān)心具體位置，因?yàn)樗械挠?jì)算節(jié)點(diǎn)都可以相同快速訪問到數(shù)據(jù)。有一些特別優(yōu)化過的應(yīng)用會(huì)針對(duì)網(wǎng)絡(luò)拓?fù)溥M(jìn)行優(yōu)化，但是這些情況很少見。

數(shù)據(jù)中心調(diào)度器需要關(guān)心具體位置，實(shí)際上這是GFS和MapReduce共同設(shè)計(jì)的所有關(guān)鍵所在。21世紀(jì)初的時(shí)候，相比于硬盤帶寬，網(wǎng)絡(luò)帶寬更加昂貴。所以為了降低成本，設(shè)計(jì)上會(huì)把數(shù)據(jù)存儲(chǔ)和計(jì)算任務(wù)放到同一個(gè)節(jié)點(diǎn)上。這是一個(gè)主要的調(diào)度限制，盡管之前在你能將任務(wù)放到任何地方，如今你需要將它放在三個(gè)副本的某一副本中。

1.2 硬件的配置

超級(jí)計(jì)算機(jī)通常由同類節(jié)點(diǎn)組成，例如他們都有一樣的硬件配置。這是因?yàn)槌?jí)算計(jì)通常是一次性采購(gòu)的：一個(gè)實(shí)驗(yàn)室獲得了數(shù)百萬(wàn)的經(jīng)費(fèi)用于更新硬件。一些HPC的應(yīng)用是根據(jù)某超級(jí)計(jì)算機(jī)中特定的CPU模型來優(yōu)化的。新的技術(shù)如GPU或者協(xié)處理器，會(huì)當(dāng)做一個(gè)新的集群推出。

在大數(shù)據(jù)的領(lǐng)域，集群主要受到存儲(chǔ)的限制。因而運(yùn)維會(huì)不斷的添加新機(jī)架來為集群擴(kuò)容。這意味著對(duì)于節(jié)點(diǎn)有著不同的CPU、內(nèi)存能力、硬盤數(shù)量等現(xiàn)象很常見。同時(shí)也會(huì)添置一些特別如SSD、GPU或者疊瓦式硬盤(shingled drive)。一個(gè)單獨(dú)的數(shù)據(jù)中心需要大范圍的應(yīng)用，而這一切又會(huì)強(qiáng)加額外的調(diào)度約束。

1.3 隊(duì)列管理和調(diào)度

當(dāng)在超級(jí)計(jì)算機(jī)上運(yùn)行應(yīng)用時(shí)，你需要指定需要的節(jié)點(diǎn)數(shù)，要提交作業(yè)的隊(duì)列，以及作業(yè)的運(yùn)行時(shí)間。隊(duì)列會(huì)對(duì)你能請(qǐng)求多少資源和你的任務(wù)可以運(yùn)行多久做不同限制。隊(duì)列也有一個(gè)基于優(yōu)先級(jí)或預(yù)留的系統(tǒng)，來決定排序。因?yàn)檫@個(gè)任務(wù)的時(shí)長(zhǎng)都知道了，這是一個(gè)十分簡(jiǎn)單的裝箱的問題。如果隊(duì)列很長(zhǎng)(通常是這樣)，并且有相當(dāng)多的小任務(wù)來填充大的任務(wù)留下的空間，你可以獲得相當(dāng)高的利用率。我喜歡將這個(gè)描述用2D的方式可視化呈現(xiàn)，時(shí)間是X軸，資源利用率作為Y軸。

如前文所述，數(shù)據(jù)中心調(diào)度是一個(gè)普遍的問題。資源請(qǐng)求的形式可以各種各樣，并且可以有更多的維度。任務(wù)也沒有一個(gè)設(shè)定好的時(shí)間范圍，因此預(yù)先計(jì)劃隊(duì)列很困難。于是乎，我們有了越來越復(fù)雜的調(diào)度算法，然后調(diào)度器的性能變得至關(guān)重要。

利用率一般而言是會(huì)變得越來越差(除非你是Google;后面還會(huì)再提到)，但是相比HPC工作量的一個(gè)優(yōu)點(diǎn)是，MapReduce和類似的任務(wù)，可以增量調(diào)度(incrementally scheduled)而無(wú)需成組調(diào)度(gang scheduled)。在HPC中，我們須等待請(qǐng)求的N個(gè)節(jié)點(diǎn)都到位，然后一次性運(yùn)行任務(wù)。MapReduce可以一波一波地運(yùn)行它的任務(wù)，這意味著它仍然可以有效地利用剩余的資源。單一的MR作業(yè)也可以基于集群的需求停止或者繼續(xù)，避免了搶占或資源預(yù)留，并且還有助于實(shí)現(xiàn)多用戶之間的公平性。

2 Mesos

Mesos早于Yarn出現(xiàn)，設(shè)計(jì)的時(shí)候考慮到了最初MapReduce存在的問題。在那時(shí)候，Hadoop集群只能運(yùn)行單一的應(yīng)用：MapReduce。這就很難運(yùn)行不符合一個(gè)map階段跟著一個(gè)reduce的階段這種模型的應(yīng)用。這里***的一個(gè)例子是 Spark。先前，你不得不為Spark安裝一套全新的worker和master，用來和你的MapReduce的worker和master一起運(yùn)行。這從資源利用的角度來講完全不理想，因?yàn)樗鼈兺ǔＪ庆o態(tài)分區(qū)的。

Mesos可以為所有集群應(yīng)用提供一個(gè)通用的調(diào)度器API來解決了這個(gè)問題。MapReduce和Spark變成了不同簡(jiǎn)單應(yīng)用，使用的是同一個(gè)底層資源分享框架。最簡(jiǎn)單的方式是寫一個(gè)中心化的調(diào)度器，但是這有一些缺點(diǎn)：

• API的復(fù)雜度。我們需要一個(gè)API，其得是所有已知的框架調(diào)度器API的超集。這是本身就很困難。如何表達(dá)資源的請(qǐng)求，同樣變得十分復(fù)雜。
• 性能。數(shù)萬(wàn)的節(jié)點(diǎn)和數(shù)百萬(wàn)的任務(wù)數(shù)目不小。特別當(dāng)調(diào)度問題復(fù)雜的時(shí)候。
• 代碼的敏捷性。新的調(diào)度器和新的框架不斷的出現(xiàn)，這會(huì)帶來新的需求。

相反的，Mesos引入了新的“兩層調(diào)度”(two-level scheduling)的概念。Mesos將每應(yīng)用程序自身的調(diào)度工作委派給應(yīng)用程序，但Mesos仍然負(fù)責(zé)在應(yīng)用之間的分派資源，保證整體上的公平性。所以Mesos非常的輕量，只有10K行代碼。

“兩層調(diào)度”是通過一個(gè)比較文藝的API叫做“資源發(fā)放(resource offer)”的接口來完成的。Mesos會(huì)周期地向應(yīng)用程序調(diào)度器“發(fā)放”一些資源。這在開始聽起來可能很落后(請(qǐng)求從master發(fā)到應(yīng)用?)，但是實(shí)際上沒有那么奇怪。在MR1中，“任務(wù)追蹤器工作者(TaskTracker worker)”了解各節(jié)點(diǎn)上具體的運(yùn)行情況。當(dāng)一個(gè)“任務(wù)追蹤器工作者”通過的心跳說某一任務(wù)已經(jīng)完成，“作業(yè)追蹤器”(JobTracker)會(huì)隨后選擇其他作業(yè)來在該“任務(wù)追蹤器”上運(yùn)行。調(diào)度決策是通過該worker中的一個(gè)資源發(fā)放來觸發(fā)的。在Mesos中，資源發(fā)放由Mesos的master 而不是slave發(fā)出，因?yàn)镸esos管理著集群。并沒有太大的不同。

“資源發(fā)放”就好似一個(gè)對(duì)部分資源有時(shí)限的租約。Mesos依據(jù)不同的策略，如優(yōu)先級(jí)、公平分享等向應(yīng)用發(fā)放資源。然后，應(yīng)用會(huì)計(jì)算如何使用這些資源，同時(shí)告訴Mesos發(fā)放的資源中哪些是它需要的。這給了應(yīng)用很大的靈活性，因?yàn)槠淇梢赃x擇暫時(shí)先運(yùn)行一部分的任務(wù)，并等待稍后更大塊的資源分配(成組分配)，或者對(duì)任務(wù)進(jìn)行體積調(diào)整來適應(yīng)實(shí)際發(fā)放的資源情況。因?yàn)橘Y源是有時(shí)間約束的，這也促使應(yīng)用盡快的進(jìn)行調(diào)度。

一些問題和它們是如何被解決的：

• 長(zhǎng)時(shí)間的任務(wù)會(huì)霸占(hogging)著資源。Mesos能讓你為一些占時(shí)短的任務(wù)保留一些資源，并能在任務(wù)超過時(shí)間限制后殺掉。這也鼓勵(lì)使用短線任務(wù)，其對(duì)公平有利。
• 性能隔離。使用Linux的容器(cgroups)。
• 大型任務(wù)的餓死。要獲得一個(gè)節(jié)點(diǎn)的獨(dú)有的訪問權(quán)是很困難的，因?yàn)橐恍?yīng)用中較小任務(wù)會(huì)蠶食它。修復(fù)方法是可以設(shè)置“最小發(fā)放大小”。

尚未解決/和解決方案未知的問題：

• 成組調(diào)度。我認(rèn)為這種調(diào)度策略若不預(yù)先知道任務(wù)的長(zhǎng)度或者進(jìn)行搶占是不可能達(dá)到高利用率的。在低利用率的情況下不斷地囤積資源是可以的，但是可能會(huì)導(dǎo)致死鎖
• 跨應(yīng)用的搶占(Cross-application preemption)也并非易事。資源發(fā)放API沒有辦法說“這里是一些低優(yōu)先級(jí)的任務(wù)，如果你們有需要我可以停止他們”。Mesos依靠任務(wù)的占時(shí)短來獲得公平。

3. Omega

Omega可以說是Mesos的后繼者，并且實(shí)際上有一個(gè)共同的作者。因?yàn)樵撜撐膶?duì)于其評(píng)估使用的是模擬的結(jié)果，我懷疑其從來沒有在Google進(jìn)入過生產(chǎn)，并且其中的理念被帶入了下一代的Borg。即使對(duì)于Google來說，重寫API很可能還是改動(dòng)太大。

Omega將資源發(fā)放往前更推進(jìn)了一步。在Mesos中，資源發(fā)放是悲觀的(pessimistic)或者叫獨(dú)占的(exclusive)。如果資源已發(fā)放給了一個(gè)應(yīng)用，同樣的資源不會(huì)發(fā)放給另外一個(gè)應(yīng)用，除非該發(fā)放的資源超時(shí)。在Omega中，資源發(fā)放是樂觀的(optimistic)，每一個(gè)應(yīng)用都發(fā)放了所有的可用的資源，沖突是在提交的時(shí)候被解決的。Omega的資源管理器，本質(zhì)上是一個(gè)保存著每一個(gè)節(jié)點(diǎn)的狀態(tài)關(guān)系數(shù)據(jù)庫(kù)，并且用不同的樂觀并發(fā)控制來解決沖突。這樣的好處是其大大的提高了調(diào)度器的性能(完全的并行，full parallelism)和資源利用率。

不足的的地方是，應(yīng)用處于一種可以隨時(shí)獨(dú)占天下的狀態(tài)，因?yàn)樗鼈冊(cè)试S以任意的速度吞食資源，甚至搶占在其他用戶之前。這對(duì)于Google來說是可行的，因?yàn)樗麄兪褂玫南到y(tǒng)是基于優(yōu)先級(jí)的，并且可以對(duì)著他們內(nèi)部的用戶吼。他們的任務(wù)量大概分為兩種優(yōu)先級(jí)類：高優(yōu)先級(jí)的服務(wù)類作業(yè)(HBase，web 服務(wù)器，長(zhǎng)期運(yùn)行的服務(wù))和低優(yōu)先級(jí)的批量式作業(yè)(MapReduce等類似的)。應(yīng)用允許搶占低優(yōu)先級(jí)的作業(yè)，并且可以停留在靠合作式強(qiáng)力取得的范圍內(nèi)，包括提交的作業(yè)數(shù)，分配的資源大小等。我想雅虎在對(duì)著用戶吼這種做法上有不同的看法(這顯然不是一種可伸縮的做法)，但不知為何在Google居然可以。

論文大多數(shù)討論的是這種樂觀的分配策略是如何與沖突一起工作的，因?yàn)檫@是一個(gè)繞不開問題，這里有一些高層次的觀點(diǎn):

• 服務(wù)類型的作業(yè)更大型，并且對(duì)安放的位置有更嚴(yán)格的需求，因?yàn)樾枰獙?shí)現(xiàn)容錯(cuò)(分布在不同的機(jī)架上)。
• Omega可以伸縮到數(shù)十個(gè)調(diào)度器，但無(wú)法伸縮到數(shù)百調(diào)度器，因?yàn)榉职l(fā)完整的集群狀態(tài)的開銷很大。
• 幾秒的調(diào)度時(shí)間是很平常的。他們也和高達(dá)數(shù)十秒甚至數(shù)百秒的調(diào)度器做了比較，這正是兩層調(diào)度真正了不起的地方。不能確定這種情況有多么普遍，或許只對(duì)于服務(wù)類的工作才這樣?
• 集群的資源利用率通常在60%。
• 沖突足夠的少見，OCC在實(shí)際中可行。在調(diào)度器崩潰之前，能達(dá)到6倍于他們正常的批量工作量。
• 增量調(diào)度非常重要。成組調(diào)度因?yàn)椴粩嘣龆嗟臎_突，實(shí)現(xiàn)起來十分的昂貴。顯然，絕大部分的應(yīng)用可以很好的適應(yīng)增量調(diào)度，只需要幾次部分分配( partial allocations)就能達(dá)到他們總體想要的數(shù)量。
• 即使對(duì)于復(fù)雜的調(diào)度器來說(每作業(yè)幾十倍的的額外開銷)，Omega仍能在合理的等待時(shí)間下調(diào)度混合的工作量。
• 根據(jù)經(jīng)驗(yàn)，在Omege中實(shí)驗(yàn)一個(gè)新的MapReduce調(diào)度器是十分容易的。

開放式問題

• 在一些情況下，樂觀的并發(fā)控制會(huì)因?yàn)楦哳l率的沖突和因重試產(chǎn)生的重復(fù)工作而崩潰。似乎他們?cè)趯?shí)際中不會(huì)遇到這個(gè)情況，但是我不知道是否在遇到奇形怪狀的任務(wù)時(shí)是否會(huì)遇到最壞的場(chǎng)景。這受服務(wù)型和批量式的作業(yè)的影響么?這個(gè)問題是否在實(shí)際中是否會(huì)進(jìn)行調(diào)優(yōu)?
• 缺少全局的策略真的可以接受么?如公平，搶占等等。
• 對(duì)于不同類型的作業(yè)的其調(diào)度時(shí)間的表現(xiàn)是怎樣的?是否有人已經(jīng)寫出十分復(fù)雜的調(diào)度器了?

4. Borg

這是一個(gè)充滿生產(chǎn)環(huán)境的經(jīng)驗(yàn)的論文。它針對(duì)的工作量，與Omega一樣，因?yàn)槎汲鲎杂贕oogle，因而他們很基本點(diǎn)是一樣的。

4.1 高層次的

• 任何東西都運(yùn)行在Borg之中，包含存儲(chǔ)系統(tǒng)，如CFS和BigTable等。
• 中等類型的集群包含10k左右的節(jié)點(diǎn)，盡管有的要大的多。
• 節(jié)點(diǎn)可以十分的異構(gòu)。
• 使用了Linux的進(jìn)程隔離(本質(zhì)上來說是容器)，因?yàn)锽org出現(xiàn)在現(xiàn)在的虛擬機(jī)基礎(chǔ)設(shè)施之前。效率和啟動(dòng)時(shí)間當(dāng)時(shí)十分重要。
• 所有的作業(yè)都是靜態(tài)鏈接的可執(zhí)行文件。
• 有非常復(fù)雜且豐富的資源定義語(yǔ)言可用。
• 可以滾動(dòng)升級(jí)運(yùn)行的作業(yè)，同時(shí)意味著配置和執(zhí)行文件。這有時(shí)需要任務(wù)重啟，因而容錯(cuò)是很重要的。
• 支持在最終被SIGKILL殺死之前，通過SIGTERM優(yōu)雅的退出。也可以選擇溫柔地殺死，但不能保證正確性。

4.2 Allocs

• 資源分配是和進(jìn)程的存活分開的。一個(gè)alloc可以用任務(wù)分組(task grouping)或者來在任務(wù)重啟之間來保持資源。
• 一個(gè)alloc集(alloc set)是一個(gè)組分配在不同的機(jī)器上的alloc。多個(gè)作業(yè)可以在同一個(gè)alloc里面運(yùn)行。
• 這其實(shí)是一個(gè)常見的模式。多進(jìn)程對(duì)于分離擔(dān)憂和開發(fā)是有用的。

4.3 優(yōu)先級(jí)和配額

• 兩類優(yōu)先級(jí)的：高和低，分別用于服務(wù)類和批量類的。
• 較高優(yōu)先級(jí)的作業(yè)能搶占較低優(yōu)先級(jí)的作業(yè)。
• 高優(yōu)先級(jí)的任務(wù)能互相搶占(防止連串的活鎖場(chǎng)景)。
• 配額用于準(zhǔn)入控制。用戶需要付更高的費(fèi)用以獲得更高優(yōu)先級(jí)的配額。
• 同時(shí)也提供了一個(gè)空閑的運(yùn)行在***優(yōu)先級(jí)層，來鼓勵(lì)高利用率和回填式的工作。
• 這是一個(gè)簡(jiǎn)單易于理解的系統(tǒng)!

4.4 調(diào)度

• 兩個(gè)調(diào)度的階段：找到可用的節(jié)點(diǎn)，然后給這些節(jié)點(diǎn)打分用于***的安置。
• 可用性很大程度由任務(wù)的約束條件來決定
• 打分最主要是根據(jù)系統(tǒng)的屬性來決定的，像***匹配(best-fit)與最差匹配(worst-fit)的對(duì)比，作業(yè)混合(job mix)，失效域(failure domains)，局部性(locality)等等。
• 一旦最終節(jié)點(diǎn)被選中，Borg會(huì)在必要時(shí)進(jìn)行搶占。
• 因?yàn)樾枰獙⒁蕾嚲植炕? localizing dependencies)，一般的調(diào)度時(shí)間在25秒左右。下載執(zhí)行文件占了80%的時(shí)間。這種局部化操作很重要。分發(fā)執(zhí)行文件時(shí)用到了Torrent和樹協(xié)議。

4.5 伸縮性

• 中心化并沒有成為一個(gè)不可能的性能瓶頸。
• 每分鐘數(shù)萬(wàn)節(jié)點(diǎn)，上萬(wàn)任務(wù)的調(diào)度頻率。
• 通常Borgmaster使用10-14核和50GB左右的內(nèi)存。
• 架構(gòu)已經(jīng)逐漸越來越多進(jìn)程化(multi-process)，參考Omega和兩層調(diào)度。
• Borgmaster雖然為單主，但是一些責(zé)任有進(jìn)行分片：如來自worker的狀態(tài)的更新，只讀的RPC等。
• 一些顯而易見的優(yōu)化：緩存機(jī)器的評(píng)分，每任務(wù)類型一次性地計(jì)算可用性，在做調(diào)度的決策的時(shí)候不要嘗試獲得全局的***性。
• 反對(duì)增大cell的主要觀點(diǎn)是隔離操作的失誤和錯(cuò)誤的上串。架構(gòu)保持良好的伸縮性。

4.6 使用率

• 他們的主要指標(biāo)是cell compaction(細(xì)胞壓縮)，或者叫能最滿足一組任務(wù)所需要最小的集群。本質(zhì)上即盒包裝(box packing)。
• 從這些獲得了的大的提升：不隔離任務(wù)量或用戶，有大的共享的集群，細(xì)粒度的資源請(qǐng)求。
• 在一個(gè)每Borglet的基礎(chǔ)上樂觀的過量使用(Optimistic overcommit )。Borglet能做資源評(píng)估，并且回填非生產(chǎn)(non-prod)的工作。如果這個(gè)評(píng)估不正確，殺死非生產(chǎn)的工作。內(nèi)存是非彈性化的資源。
• 分享不會(huì)大的影響CPI(CPU干擾，CPU interface),但是我比懷疑對(duì)于存儲(chǔ)這一塊的影響。

4.7 吸取的教訓(xùn)

這里列舉的問題在Kubernetes里面已經(jīng)修復(fù)了，這是他們的一個(gè)開放的開源的容器調(diào)度器。

壞處

• 能調(diào)度多作業(yè)的工作流而不是單作業(yè)會(huì)很好，有利于跟蹤和管理。這也需要更靈活的方式來指帶工作流的組件。這通過添加任意的鍵值對(duì)到每一個(gè)任務(wù)，并且讓用戶可以方便用戶查詢得到解決。
• 每一個(gè)機(jī)器一個(gè)IP。這帶一個(gè)機(jī)器上端口的沖突，和復(fù)雜的綁定和服務(wù)發(fā)現(xiàn)。這能通過Linux的命名空間，IPv6，SDN得到解決。
• 復(fù)雜的定義語(yǔ)言。太多的疙瘩需要解開，這讓一個(gè)普通用戶很難上手。需要一些在自動(dòng)決定資源需求方面的工作。

好處

• Allocs 真是好極了。允許助手服務(wù)能方便的跟主要task放在一起。
• 內(nèi)置的負(fù)載均衡和命名功能十分的有用。
• 指標(biāo)，調(diào)試和Web界面，對(duì)于用于用戶解決自己的問題十分的有用。
• 中心化向上擴(kuò)展的很好，但是需要分散到多個(gè)進(jìn)程里面去。Kubernetes從頭做這個(gè)，意味在不同的調(diào)度器組件之間一個(gè)干凈的API。

5 ***的話

看起來YARN需要借鑒Mesos和Omega的設(shè)計(jì)，才能使伸縮達(dá)到10K的節(jié)點(diǎn)規(guī)模。相比于Mesos和 Omega，YARN仍然是一個(gè)中心化的調(diào)度器，常常像一個(gè)稻草人一樣在人們需要對(duì)Mesos和Omega進(jìn)行類比的時(shí)候搬出來。Borg特別提到了需要進(jìn)行分片以獲得伸縮性。

要獲得高資源利用率，又不犧牲SLO(Service Level Objective，服務(wù)水平目標(biāo))，隔離性就至關(guān)重要。這會(huì)浮現(xiàn)到應(yīng)用的層面，在這一層應(yīng)用自身需要進(jìn)行容忍時(shí)延的設(shè)計(jì)。想一想BigTable中 tail-at-scale的請(qǐng)求復(fù)制。最終，這也會(huì)涉及到硬件開銷與軟件開銷成本的權(quán)衡。在低資源利用率下運(yùn)行可以繞過這個(gè)問題?；蛘吣憧梢杂y而上，通過OS的隔離機(jī)制，資源預(yù)估和對(duì)工作量及調(diào)度器的不斷調(diào)優(yōu)來解決這個(gè)問題。對(duì)Google來說，擁有那樣的規(guī)模，足夠多的硬件，需要聘一大批內(nèi)核的開發(fā)者是相當(dāng)合情合理的。而且幸運(yùn)的是，這些開發(fā)者已經(jīng)幫我們解決了這些問題。

我不確定對(duì)Google工作量的設(shè)想是否適用更普通的場(chǎng)景。對(duì)優(yōu)先級(jí)分類，保留資源和搶占對(duì)于Google來說奏效，但我們的客戶幾乎都使用公平分享調(diào)度器(fair share scheduler)。Yahoo使用容量調(diào)度器( capacity scheduler)。Twitter也使用公平調(diào)度器( fair scheduler)。我并沒有聽說過需要結(jié)合優(yōu)先級(jí)+資源保留的調(diào)度器( priority + reservation scheduler)的需求。

***，運(yùn)行大型的共享集群，這種我們預(yù)想在Google中的上演的狀況，在我們的客戶中卻很難遇到。我們的客戶中雖然也有使用成千的節(jié)點(diǎn)的，但它們實(shí)際上是分散到了成百節(jié)點(diǎn)上的pod里面去的。把不同的用戶和應(yīng)用分到不同的集群，也仍然是常見的做法。集群通常在硬件上也是同構(gòu)的，但我想這種情況會(huì)很快改變。

網(wǎng)站名稱：Mesos、Omega和Borg三個(gè)系統(tǒng)有什么區(qū)別?
網(wǎng)站路徑：http://uogjgqi.cn/article/cdoddoe.html