摘要
Google的Borg系統(tǒng)是一個(gè)集群管理器床牧，它在許多集群中運(yùn)行著成千上萬的工作彭谁，這些工作來自成千上萬個(gè)不同的應(yīng)用程序肛捍，每個(gè)集群中最多有成千上萬臺(tái)計(jì)算機(jī)椭微。
通過將準(zhǔn)入控制洞坑，有效的任務(wù)打包，過量使用和機(jī)器共享與流程級(jí)的性能隔離相結(jié)合蝇率，可以實(shí)現(xiàn)高利用率迟杂。 它通過運(yùn)行時(shí)功能（可最大程度地縮短故障恢復(fù)時(shí)間）和調(diào)度策略來降低相關(guān)故障的可能性，從而支持高可用性應(yīng)用程序本慕。 Borg通過提供聲明性（declarative）的作業(yè)規(guī)范語言排拷，名稱服務(wù)（name service）集成，實(shí)時(shí)作業(yè)監(jiān)視以及分析和模擬系統(tǒng)行為的工具锅尘，為用戶簡(jiǎn)化了生活监氢。
我們提供了Borg系統(tǒng)架構(gòu)和功能的摘要，重要的設(shè)計(jì)決策，一些政策決策的定量分析以及對(duì)十年運(yùn)營(yíng)中獲得的經(jīng)驗(yàn)教訓(xùn)的定性分析經(jīng)驗(yàn)忙菠。
1 介紹
我們?cè)趦?nèi)部將群集管理系統(tǒng)稱為Borg授予何鸡，計(jì)劃，啟動(dòng)牛欢，重新啟動(dòng)和監(jiān)視Google運(yùn)行的所有應(yīng)用程序。 本文解釋了如何淆游。
Borg提供了三個(gè)主要好處：（1）隱藏資源管理和故障處理的詳細(xì)信息傍睹，以便其用戶可以專注于應(yīng)用程序開發(fā)； （2）具有很高的可靠性和可用性犹菱，并支持相同的應(yīng)用拾稳； （3）讓我們有效地在成千上萬的計(jì)算機(jī)上運(yùn)行工作負(fù)載。 Borg不是第一個(gè)解決這些問題的系統(tǒng)腊脱，但是它是這種規(guī)模的访得，具有如此程度的靈活性和完整性的操作系統(tǒng)之一。 本文圍繞這些主題進(jìn)行了組織陕凹，并總結(jié)了十多年來我們?cè)谏a(chǎn)中使用Borg進(jìn)行的定性觀察悍抑。
2 用戶角度
Borg的用戶是運(yùn)行Google應(yīng)用程序和服務(wù)的Google開發(fā)人員和系統(tǒng)管理員（站點(diǎn)可靠性工程師或SRE）搜骡。 用戶以作業(yè)的形式將其工作提交給Borg，每個(gè)作業(yè)都包含一個(gè)或多個(gè)都運(yùn)行相同程序（二進(jìn)制）的任務(wù)佑女。 每個(gè)作業(yè)都在一個(gè)Borg單元中運(yùn)行记靡，Borg單元是一組作為一個(gè)單元進(jìn)行管理的計(jì)算機(jī)。 本節(jié)的其余部分描述了Borg用戶視圖中暴露的主要功能团驱。
2.1 工作負(fù)載
Borg單元運(yùn)行的異構(gòu)工作負(fù)載包括兩個(gè)主要部分：第一個(gè)是長(zhǎng)期運(yùn)行的服務(wù)摸吠，應(yīng)“永不中斷”，并處理短暫的對(duì)延遲敏感的請(qǐng)求（幾微秒到幾百毫秒）嚎花。 此類服務(wù)用于面向最終用戶的產(chǎn)品（例如Gmail寸痢，Google文檔和網(wǎng)絡(luò)搜索）以及內(nèi)部基礎(chǔ)架構(gòu)服務(wù)（例如BigTable）。 第二個(gè)是批處理作業(yè)贩幻，需要花費(fèi)幾秒鐘到幾天的時(shí)間才能完成轿腺； 這些對(duì)短期性能波動(dòng)的敏感度要低得多。 不同單元之間的工作負(fù)載組合會(huì)有所不同丛楚，這些單元會(huì)根據(jù)其主要承租方運(yùn)行不同的應(yīng)用程序混合（例如族壳，某些單元是非常繁重的批處理），并且還會(huì)隨著時(shí)間而變化：批處理作業(yè)來來往往趣些，許多最終用戶 面對(duì)服務(wù)工作會(huì)看到日間使用模式仿荆。 Brog必須同樣妥善處理所有這些案件。
可以從2011年5月開始的為期一個(gè)月的公開跟蹤中找到具有代表性的Borg工作負(fù)載[80]，該跟蹤已被廣泛分析（例如[68]和[1拢操、26锦亦、27、57]）令境。
在過去的幾年中杠园，已經(jīng)在Borg之上構(gòu)建了許多應(yīng)用程序框架，包括我們的內(nèi)部MapRe duce系統(tǒng)[23]舔庶，F(xiàn)lumeJava [18]抛蚁，Millwheel [3]和Pregel [59]。其中大多數(shù)都有一個(gè)控制器惕橙，該控制器提交一份主工作和一個(gè)或多個(gè)工人工作瞧甩。前兩個(gè)與YARN的應(yīng)用程序管理器[76]扮演相似的角色。我們的分布式存儲(chǔ)系統(tǒng)（例如GFS [34]及其后續(xù)CFS弥鹦，Bigtable [19]和Megastore [8]）都在Borg上運(yùn)行肚逸。
在本文中，我們將優(yōu)先級(jí)較高的博格工作分類為“生產(chǎn)”（生產(chǎn)）工作彬坏，其余分類為“非生產(chǎn)”（非生產(chǎn)）工作朦促。大多數(shù)長(zhǎng)時(shí)間運(yùn)行的服務(wù)器作業(yè)都是prod；大多數(shù)批處理作業(yè)都是非生產(chǎn)性的苍鲜。在一個(gè)代表性的單元中思灰，生產(chǎn)作業(yè)分配了大約70％的CPU資源，代表了大約60％的CPU使用率混滔。它們大約分配了總內(nèi)存的55％洒疚，約占總內(nèi)存的85％總內(nèi)存使用量。在§5.5中坯屿，分配和使用之間的差異將被證明很重要油湖。
2.2 集群和單元
一個(gè)單元中的機(jī)器屬于一個(gè)集群，由連接它們的高性能數(shù)據(jù)中心級(jí)網(wǎng)絡(luò)結(jié)構(gòu)定義领跛。 群集位于單個(gè)數(shù)據(jù)中心建筑物內(nèi)乏德，建筑物的集合構(gòu)成一個(gè)站點(diǎn)。群集通常承載一個(gè)大型單元吠昭，并可能具有一些較小規(guī)模的測(cè)試或?qū)Ｓ脝卧?我們竭力避免出現(xiàn)任何單點(diǎn)故障喊括。
排除測(cè)試單元后，我們的平均單元大小約為10,000臺(tái)機(jī)器矢棚； 有些更大郑什。 單元中的機(jī)器在許多方面都是異構(gòu)的：大小（CPU蒲肋，RAM蘑拯，磁盤钝满，網(wǎng)絡(luò)），處理器類型申窘，性能和功能（例如外部IP地址或閃存）弯蚜。 Borg通過確定在單元中的哪個(gè)位置運(yùn)行任務(wù)，分配資源剃法，停止其程序和其他依賴項(xiàng)碎捺，監(jiān)視其運(yùn)行狀況并在失敗時(shí)重新啟動(dòng)它們，從而使用戶免受這些差異中的大多數(shù)的影響贷洲。
2.3 工作和任務(wù)
Borg作業(yè)的屬性包括其名稱牵寺，所有者和它擁有的任務(wù)數(shù)。 作業(yè)可能會(huì)受到約束恩脂，以迫使其任務(wù)在具有特定屬性（例如處理器體系結(jié)構(gòu)，操作系統(tǒng)版本或外部IP地址）的機(jī)器上運(yùn)行趣斤。 后者的行為就像偏好而不是要求俩块。 可以將工作的開始推遲到之前的工作完成為止。 作業(yè)僅在一個(gè)單元中運(yùn)行浓领。
每個(gè)任務(wù)都映射到在計(jì)算機(jī)上的容器中運(yùn)行的一組Linux進(jìn)程[62]玉凯。 由于我們不想支付虛擬化的成本，絕大多數(shù)Borg工作負(fù)載不在虛擬機(jī)（VM）內(nèi)運(yùn)行联贩。此外漫仆，該系統(tǒng)是在我們對(duì)沒有虛擬化的處理器進(jìn)行大量投資對(duì)支持硬件的設(shè)計(jì)方案。
任務(wù)也具有屬性泪幌，例如其資源需求和任務(wù)在任務(wù)中的索引盲厌。 大多數(shù)任務(wù)在所有任務(wù)中的屬性都是相同的，但可以被覆蓋（例如祸泪，提供特定于任務(wù)的命令行標(biāo)志）吗浩。每個(gè)資源維度（CPU核心，RAM没隘，磁盤空間懂扼，磁盤訪問速率， TCP端口等）以細(xì)粒度獨(dú)立指定右蒲； 我們不強(qiáng)加固定大小的存儲(chǔ)桶或插槽（第5.4節(jié)）阀湿。 Borg程序是靜態(tài)鏈接的，以減少對(duì)其運(yùn)行時(shí)環(huán)境的依賴性瑰妄，并構(gòu)成為二進(jìn)制文件和數(shù)據(jù)文件的程序包陷嘴，其安裝由Borg精心安排。
用戶通過向Borg發(fā)出遠(yuǎn)程過程調(diào)用（RPC）（通常是從命令行工具翰撑，其他Borg作業(yè)或我們的監(jiān)視系統(tǒng)罩旋，第2.6節(jié)）來對(duì)作業(yè)進(jìn)行操作啊央。 大多數(shù)作業(yè)描述是用聲明性配置語言BCL編寫的。 這是GCL的一種變體[12]涨醋，它生成protobuf文件[67]瓜饥，并使用一些Borg特定的關(guān)鍵字進(jìn)行了擴(kuò)展。 GCL提供了lambda函數(shù)以允許計(jì)算浴骂，并且應(yīng)用程序使用這些函數(shù)來調(diào)整其配置以適應(yīng)其環(huán)境乓土。 成千上萬的BCL文件的長(zhǎng)度超過1000行，而我們已經(jīng)積累了數(shù)千萬行的BCL溯警。Borg作業(yè)配置與Aurora配置文件相似[6]趣苏。
圖2說明了作業(yè)和任務(wù)在其生命周期內(nèi)所經(jīng)歷的狀態(tài)。
用戶可以通過將新作業(yè)配置推送到Borg喳挑，然后指示Borg將任務(wù)更新為新規(guī)范來更改正在運(yùn)行的作業(yè)中某些或所有任務(wù)的屬性彬伦。這是一種輕量級(jí)的，非原子性的事務(wù)伊诵，可以很容易地撤消单绑，直到關(guān)閉（提交）。通常以滾動(dòng)方式進(jìn)行更新曹宴，并且可以限制更新導(dǎo)致的任務(wù)中斷（重新計(jì)劃或搶占）的數(shù)量搂橙；會(huì)導(dǎo)致更多中斷的任何更改都將被跳過。
某些任務(wù)更新（例如笛坦，推送新的二進(jìn)制文件）總是會(huì)要求重新啟動(dòng)任務(wù)区转；有些（例如，增加的資源需求或更改的約束）可能會(huì)使任務(wù)不再適合計(jì)算機(jī)弯屈，并導(dǎo)致任務(wù)被停止和重新安排;并且某些操作（例如更改優(yōu)先級(jí)）始終可以在不重新啟動(dòng)或移動(dòng)任務(wù)的情況下完成蜗帜。
在SIGKILL搶占任務(wù)之前，可以要求通過Unix SIGTERM信號(hào)通知任務(wù)资厉，因此它們有時(shí)間清理厅缺，保存狀態(tài)，完成任何當(dāng)前正在執(zhí)行的請(qǐng)求并拒絕新請(qǐng)求宴偿。如果搶占者設(shè)置了延遲范圍湘捎，則實(shí)際通知可能會(huì)少一些。實(shí)際上窄刘，通知是在大約80％的時(shí)間內(nèi)發(fā)送的窥妇。
2.4 分配（Alloc）
Borg分配（分配的縮寫）是一臺(tái)機(jī)器上可以運(yùn)行一個(gè)或多個(gè)任務(wù)的一組保留資源。 無論是否使用它們娩践，資源都會(huì)保持分配狀態(tài)活翩。Alloc可用于為將來的任務(wù)留出資源烹骨，在停止任務(wù)和重新啟動(dòng)任務(wù)之間保留資源，以及將來自不同作業(yè)的任務(wù)收集到同一臺(tái)計(jì)算機(jī)上–例如 材泄，一個(gè)Web服務(wù)器實(shí)例和一個(gè)關(guān)聯(lián)的日志保護(hù)程序任務(wù)沮焕，該任務(wù)將服務(wù)器的URL日志從本地磁盤復(fù)制到分布式文件系統(tǒng)。 分配資源與機(jī)器資源的處理方式相似拉宗；一個(gè)內(nèi)部運(yùn)行的多個(gè)任務(wù)共享其資源峦树。 如果必須將分配重定位到另一臺(tái)計(jì)算機(jī)，則將其任務(wù)重新安排旦事。
分配集就像一項(xiàng)工作：它是一組在多臺(tái)機(jī)器上保留資源的分配魁巩。 創(chuàng)建分配集后，可以提交一個(gè)或多個(gè)作業(yè)以在其中運(yùn)行姐浮。 為簡(jiǎn)便起見谷遂，我們通常使用“任務(wù)”來指代一個(gè)分配或頂級(jí)任務(wù)（一個(gè)在分配外的任務(wù)），而“作業(yè)”則指代一個(gè)作業(yè)或分配集卖鲤。
2.5 優(yōu)先級(jí)埋凯，配額和準(zhǔn)入控制
如果出現(xiàn)的工作量超出了容納的工作量，會(huì)發(fā)生什么情況扫尖？ 我們?yōu)榇说慕鉀Q方案是優(yōu)先級(jí)和配額。
每個(gè)作業(yè)都有一個(gè)優(yōu)先級(jí)掠廓，一個(gè)小的正整數(shù)换怖。 高優(yōu)先級(jí)任務(wù)可以以低優(yōu)先級(jí)任務(wù)為代價(jià)獲得資源，即使這涉及搶占（殺死）后者蟀瞧。 Borg為不同用途定義了不重疊的優(yōu)先級(jí)帶沉颂，包括（按降序排列）：監(jiān)視（monitoring），生產(chǎn)（production）悦污，批處理（batch）和best efford（也稱為測(cè)試或免費(fèi)）铸屉。 在本文中，生產(chǎn)工作屬于監(jiān)視和生產(chǎn)帶中的工作切端。
盡管搶占式任務(wù)通常會(huì)在單元格中的其他地方重新安排彻坛，但如果高優(yōu)先級(jí)的任務(wù)碰到了優(yōu)先級(jí)稍低的任務(wù)，而又搶占了另一個(gè)稍低優(yōu)先級(jí)的任務(wù)踏枣，則搶占級(jí)聯(lián)可能會(huì)發(fā)生昌屉，依此類推。 為了消除大多數(shù)情況茵瀑，我們不允許生產(chǎn)優(yōu)先級(jí)范圍內(nèi)的任務(wù)互相搶占间驮。 細(xì)粒度的優(yōu)先級(jí)在其他情況下仍然有用，例如马昨，MapReduce主任務(wù)以比其所控制的工作人員稍高的優(yōu)先級(jí)運(yùn)行竞帽，以提高其可靠性扛施。
優(yōu)先級(jí)表示在單元中正在運(yùn)行或正在等待運(yùn)行的作業(yè)的相對(duì)重要性。 配額用于決定允許哪些作業(yè)進(jìn)行調(diào)度屹篓。 配額表示為一段時(shí)間（通常為幾個(gè)月）內(nèi)給定優(yōu)先級(jí)的資源數(shù)量（CPU疙渣，RAM，磁盤等）的向量抱虐。 數(shù)量指定了用戶的作業(yè)請(qǐng)求一次可以請(qǐng)求的最大資源量（例如昌阿，“從現(xiàn)在到7月底，單元xx中的產(chǎn)品優(yōu)先級(jí)為20 TiB RAM”）恳邀。 配額檢查是準(zhǔn)入控制的一部分懦冰，而不是計(jì)劃的一部分：配額不足的作業(yè)在提交后將立即被拒絕。
較高優(yōu)先級(jí)的配額要比較低優(yōu)先級(jí)的配額花費(fèi)更多谣沸。生產(chǎn)優(yōu)先級(jí)配額僅限于單元中可用的實(shí)際資源刷钢，因此提交適合其配額的生產(chǎn)優(yōu)先級(jí)作業(yè)的用戶可以期望其運(yùn)行，模態(tài)碎片化和約束乳附。即使我們鼓勵(lì)用戶購(gòu)買的配額不要超過需求内地，但許多用戶還是超買，因?yàn)檫@可以使他們避免應(yīng)用程序用戶群增長(zhǎng)時(shí)的未來短缺赋除。我們通過降低優(yōu)先級(jí)的配額超額銷售來解決此問題：每個(gè)用戶都有無限的購(gòu)買空間優(yōu)先級(jí)為零的配額阱缓，盡管由于資源超額預(yù)訂，這通常很難執(zhí)行举农【Ｕ耄可能會(huì)接受低優(yōu)先級(jí)的工作，但由于資源不足而使其處于待處理狀態(tài)（計(jì)劃外）颁糟。
配額分配是在Borg之外進(jìn)行的航背，并且與我們的物理容量計(jì)劃直接相關(guān)，其結(jié)果反映在不同數(shù)據(jù)中心的配額價(jià)格和可用性上棱貌。用戶作業(yè)只有在具有足夠優(yōu)先級(jí)的配額時(shí)才被接受玖媚。配額的使用減少了對(duì)諸如主導(dǎo)資源公平（DRF）[29，35婚脱，36今魔，66]之類的政策的需求。
Borg有一個(gè)功能系統(tǒng)障贸，可以為某些用戶提供特殊的特權(quán)涡贱。例如妹卿，允許管理員刪除或修改單元中的任何作業(yè)粘室，或者允許用戶訪問受限制的內(nèi)核功能或Borg行為，例如禁用其作業(yè)上的資源估計(jì)（第5.5節(jié)）恨豁。
2.6 命名和監(jiān)控
創(chuàng)建和放置任務(wù)還不夠：服務(wù)的客戶端和其他系統(tǒng)需要能夠找到它們嘀粱，即使將它們重新放置到新計(jì)算機(jī)上也是如此激挪。 為此辰狡，Borg為每個(gè)任務(wù)創(chuàng)建一個(gè)穩(wěn)定的“ Borg名稱服務(wù)”（BNS）名稱，其中包括單元名稱垄分，作業(yè)名稱和任務(wù)編號(hào)宛篇。Borg將任務(wù)的主機(jī)名和端口寫入一致且高度可用的Chubby文件中。 此名稱薄湿，我們的RPC系統(tǒng)將使用該名稱來查找任務(wù)端點(diǎn)叫倍。 BNS名稱也是任務(wù)DNS名稱的基礎(chǔ)，因此豺瘤，用戶ubar在單元cc中的作業(yè)jfoo中的第五十個(gè)任務(wù)可以通過50.jfoo.ubar.cc.borg.google.com進(jìn)行訪問吆倦。 Borg還會(huì)在每次更改時(shí)將作業(yè)大小和任務(wù)運(yùn)行狀況信息寫入Chubby，以便負(fù)載平衡器可以看到將請(qǐng)求路由到何處坐求。
幾乎在Borg下運(yùn)行的每個(gè)任務(wù)都包含一個(gè)內(nèi)置的HTTP服務(wù)器蚕泽，該服務(wù)器發(fā)布有關(guān)任務(wù)運(yùn)行狀況和成千上萬個(gè)性能指標(biāo)（例如RPC延遲）的信息。 Borg監(jiān)視運(yùn)行狀況檢查URL桥嗤，并重新啟動(dòng)無法及時(shí)響應(yīng)或返回HTTP錯(cuò)誤代碼的任務(wù)须妻。監(jiān)視工具可跟蹤其他數(shù)據(jù)，以用于儀表板并針對(duì)違反服務(wù)水平目標(biāo)（SLO）的情況發(fā)出警報(bào)泛领。
一項(xiàng)名為Sigma的服務(wù)提供了一個(gè)基于Web的用戶界面（UI）荒吏，用戶可以通過該界面檢查其所有作業(yè)，特定單元的狀態(tài)渊鞋，或者向下鉆取到各個(gè)作業(yè)和任務(wù)以檢查其資源行為司倚，詳細(xì)的日志，執(zhí)行歷史篓像，以及最終的命運(yùn)。我們的應(yīng)用程序產(chǎn)生大量的日志信息皿伺；它們會(huì)自動(dòng)輪換狀態(tài)以避免磁盤空間用盡员辩，并在任務(wù)退出后保留一段時(shí)間以幫助調(diào)試。如果作業(yè)沒有運(yùn)行鸵鸥，Borg會(huì)提供“為什么要暫掛（pending）奠滑？”注釋（annotation），以及有關(guān)如何修改作業(yè)的資源請(qǐng)求以更好地適應(yīng)單元的指南妒穴。我們發(fā)布了可能很容易安排的“整合”資源形態(tài)指南宋税。
Borg在Infrastore中記錄所有作業(yè)提交和任務(wù)事件，以及每個(gè)任務(wù)的詳細(xì)資源使用信息讼油，Infrastore是可擴(kuò)展的只讀數(shù)據(jù)存儲(chǔ)杰赛，具有通過Dremel的類似SQL的交互式界面[61]。此數(shù)據(jù)用于基于使用情況的計(jì)費(fèi)矮台，調(diào)試作業(yè)和系統(tǒng)故障以及長(zhǎng)期容量規(guī)劃乏屯。它還提供了Google集群工作負(fù)載跟蹤的數(shù)據(jù)根时。
所有這些功能可幫助用戶了解和調(diào)試Borg的行為及其工作，并幫助我們的SRE每人管理數(shù)萬臺(tái)計(jì)算機(jī)辰晕。
3 Brog架構(gòu)
一個(gè)Borg單元由一組計(jì)算機(jī)蛤迎，一個(gè)邏輯上集中的控制器（稱為Borgmaster）和一個(gè)稱為Borglet的代理進(jìn)程組成，該進(jìn)程在該單元中的每臺(tái)計(jì)算機(jī)上運(yùn)行（請(qǐng)參見圖1）含友。 Borg的所有組件都是用C ++編寫的替裆。
3.1 Borgmaster
每個(gè)單元的Borgmaster包含兩個(gè)進(jìn)程：Borgmaster主進(jìn)程和一個(gè)單獨(dú)的調(diào)度程序（第3.2節(jié)）。 Borgmaster主進(jìn)程處理客戶端RPC窘问，這些RPC會(huì)改變狀態(tài)（例如辆童，創(chuàng)建作業(yè)）或提供對(duì)數(shù)據(jù)的只讀訪問權(quán)限（例如，查找作業(yè)）南缓。它還為系統(tǒng)中的所有對(duì)象（機(jī)器胸遇，任務(wù)，分配等）管理狀態(tài)機(jī)汉形，與Borglets通信纸镊，并提供Web UI作為Sigma的備份。
從邏輯上講概疆，Borgmaster是單個(gè)進(jìn)程逗威，但實(shí)際上可以重復(fù)五次。每個(gè)副本都維護(hù)該單元大多數(shù)狀態(tài)的內(nèi)存副本岔冀，并且此狀態(tài)也記錄在副本本地磁盤上的高可用性凯旭，基于Paxos的分布式存儲(chǔ)中。每個(gè)單元由一個(gè)選舉產(chǎn)生的主力同時(shí)充當(dāng)Paxos的領(lǐng)導(dǎo)者和狀態(tài)改變者使套，處理改變單元狀態(tài)的所有操作罐呼，例如提交作業(yè)或終止機(jī)器上的任務(wù)。一個(gè)主當(dāng)選（使用的Paxos）當(dāng)單元成長(zhǎng)時(shí)侦高，每當(dāng)主當(dāng)選失敗;它獲取了Chubby鎖嫉柴，以便其他系統(tǒng)可以找到它。選擇一個(gè)主節(jié)點(diǎn)并進(jìn)行故障轉(zhuǎn)移通常需要大約10秒鐘奉呛，但在一個(gè)大單元中可能要花費(fèi)一分鐘的時(shí)間计螺，因?yàn)楸仨氈貥?gòu)某些內(nèi)存狀態(tài)。當(dāng)副本從中斷中恢復(fù)時(shí)瞧壮，它會(huì)與其他最新的Paxos副本動(dòng)態(tài)地重新同步其狀態(tài)登馒。
Borgmaster在某個(gè)時(shí)間點(diǎn)的狀態(tài)稱為檢查點(diǎn)，其形式為定期快照以及保存在Paxos商店中的更改日志咆槽。檢查點(diǎn)有許多用途陈轿，包括將Borgmaster的狀態(tài)恢復(fù)到過去的任意點(diǎn)（例如，在接受觸發(fā)Borg中的軟件缺陷的請(qǐng)求之前，可以對(duì)其進(jìn)行調(diào)試）济欢；用手將其固定在末端赠堵；建立事件的持久日志以供將來查詢；和離線模擬法褥。
稱為Fauxmaster的高保真Borgmaster模擬器可用于讀取檢查點(diǎn)文件茫叭，并包含生產(chǎn)Borgmaster代碼的完整副本，以及指向Borglet的殘存接口半等。它接受RPC進(jìn)行狀態(tài)機(jī)更改并執(zhí)行操作揍愁，例如“計(jì)劃所有未完成的任務(wù)”，并且我們通過與RPC進(jìn)行交互杀饵，就好像它是一個(gè)實(shí)時(shí)的Borgmaster一樣莽囤，使用它來調(diào)試故障，并且模擬的Borglet可以真實(shí)地回放切距。檢查點(diǎn)文件中的交互朽缎。用戶可以單步執(zhí)行并觀察過去實(shí)際發(fā)生的對(duì)系統(tǒng)狀態(tài)的更改。 Fauxmaster還可以用于容量規(guī)劃（“該類型可以容納多少個(gè)新工作谜悟？”）以及在更改單元的配置之前進(jìn)行完整性檢查（“此更改是否可以淘汰任何重要的工作话肖？”）。
3.2 Scheduling
提交作業(yè)后葡幸，Borgmaster將其持久地記錄在Paxos商店中最筒，并將該作業(yè)的任務(wù)添加到等待隊(duì)列中。 調(diào)度程序會(huì)對(duì)此進(jìn)行異步掃描蔚叨，如果有足夠的可用資源滿足任務(wù)的約束床蜘，調(diào)度程序會(huì)將任務(wù)分配給計(jì)算機(jī)。 （調(diào)度程序主要在任務(wù)而不是作業(yè)上運(yùn)行蔑水。）掃描過程從高優(yōu)先級(jí)到低優(yōu)先級(jí)邢锯，并由優(yōu)先級(jí)內(nèi)的循環(huán)機(jī)制調(diào)制，以確保整個(gè)用戶之間的公平性并避免行頭阻塞大型任務(wù) 搀别。 調(diào)度算法分為兩部分：可行性檢查丹擎，以找到可以在其上運(yùn)行任務(wù)的機(jī)器；以及評(píng)分领曼，從中選擇一臺(tái)可行的機(jī)器。
在可行性檢查中蛮穿，調(diào)度程序會(huì)找到一組滿足任務(wù)約束并且具有足夠“可用”資源的機(jī)器庶骄，其中包括分配給可以撤出的低優(yōu)先級(jí)任務(wù)的資源。在計(jì)分中践磅，調(diào)度程序確定每種可行機(jī)器的“優(yōu)劣”单刁。分?jǐn)?shù)考慮了用戶指定的偏好，但主要受內(nèi)置標(biāo)準(zhǔn)驅(qū)動(dòng)，例如羔飞，最小化被搶占任務(wù)的數(shù)量和優(yōu)先級(jí)肺樟，挑選已經(jīng)擁有任務(wù)包副本的機(jī)器，將任務(wù)分散在各個(gè)電源上以及故障域逻淌，以及打包質(zhì)量么伯，包括將高優(yōu)先級(jí)任務(wù)和低優(yōu)先級(jí)任務(wù)混合到一臺(tái)機(jī)器上，以允許高優(yōu)先級(jí)任務(wù)在負(fù)載峰值時(shí)擴(kuò)展卡儒。
Borg最初使用E-PVM [4]的一種變體進(jìn)行評(píng)分田柔，該變體跨異構(gòu)資源生成單個(gè)成本值，并在放置任務(wù)時(shí)最大程度地降低了成本變化骨望。實(shí)際上硬爆，E-PVM最終會(huì)在所有計(jì)算機(jī)上分散負(fù)載，從而為負(fù)載峰值留出了空間-但以增加碎片為代價(jià)擎鸠，特別是對(duì)于需要大部分計(jì)算機(jī)的大型任務(wù)缀磕；我們有時(shí)將此稱為“最不適合”。
在可行性檢查中劣光，調(diào)度程序會(huì)找到一組滿足任務(wù)約束并且具有足夠“可用”資源的機(jī)器袜蚕，其中包括分配給可以撤出的低優(yōu)先級(jí)任務(wù)的資源。在計(jì)分中赎线，調(diào)度程序確定每種可行機(jī)器的“優(yōu)劣”廷没。分?jǐn)?shù)考慮了用戶指定的偏好，但主要受內(nèi)置標(biāo)準(zhǔn)驅(qū)動(dòng)垂寥，例如颠黎，最小化被搶占任務(wù)的數(shù)量和優(yōu)先級(jí)，挑選已經(jīng)擁有任務(wù)包副本的機(jī)器滞项，將任務(wù)分散在各個(gè)電源上以及故障域狭归，以及打包質(zhì)量，包括將高優(yōu)先級(jí)任務(wù)和低優(yōu)先級(jí)任務(wù)混合到一臺(tái)機(jī)器上文判，以允許高優(yōu)先級(jí)任務(wù)在負(fù)載峰值時(shí)擴(kuò)展过椎。
Borg最初使用E-PVM的一種變體進(jìn)行評(píng)分，該變體在異構(gòu)資源中生成單個(gè)成本值戏仓，并在放置任務(wù)時(shí)最大程度地降低了成本變化疚宇。實(shí)際上，E-PVM最終會(huì)在所有計(jì)算機(jī)上分散負(fù)載赏殃，從而為負(fù)載峰值留出了空間-但以增加碎片為代價(jià)敷待，特別是對(duì)于需要大部分計(jì)算機(jī)的大型任務(wù)；我們有時(shí)將此稱為“最不適合”仁热。
頻譜的另一端是“最佳擬合”榜揖，它試圖盡可能緊密地填充機(jī)器。這使一些機(jī)器沒有用戶作業(yè)（它們?nèi)栽谶\(yùn)行存儲(chǔ)服務(wù)器），因此放置大型任務(wù)很簡(jiǎn)單举哟，但是緊湊的包裝將懲罰用戶或Borg對(duì)資源需求的任何錯(cuò)誤估計(jì)思劳。這會(huì)傷害負(fù)載激增的應(yīng)用程序，并且對(duì)于指定CPU需求較低的批處理作業(yè)特別不利妨猩，因此它們可以輕松地進(jìn)行調(diào)度潜叛，并嘗試在未使用的資源中合理地運(yùn)行：20％的非生產(chǎn)任務(wù)要求的CPU內(nèi)核數(shù)少于0.1。
我們當(dāng)前的評(píng)分模型是一種混合模型册赛，該模型試圖減少擱淺資源的數(shù)量–由于計(jì)算機(jī)上的另一資源已完全分配钠导，因此無法使用這些資源。與最適合我們的工作負(fù)載相比森瘪，它提供了大約3–5％的打包效率（在[78]中定義）牡属。
如果在計(jì)分階段選擇的計(jì)算機(jī)沒有足夠的可用資源來滿足新任務(wù)的需求，那么Borg會(huì)搶先（殺死）低優(yōu)先級(jí)的任務(wù)扼睬，從最低優(yōu)先級(jí)到最高優(yōu)先級(jí)逮栅，直到成功為止。我們將搶占式任務(wù)添加到調(diào)度程序的待處理隊(duì)列中窗宇，而不是遷移或休眠它們措伐。
任務(wù)啟動(dòng)延遲（從作業(yè)提交到任務(wù)運(yùn)行的時(shí)間）是一個(gè)已經(jīng)受到并將繼續(xù)引起極大關(guān)注的領(lǐng)域。它變化很大军俊，中位數(shù)通常約為25 s侥加。軟件包安裝約占總數(shù)的80％：已知的瓶頸之一是爭(zhēng)用寫入軟件包的本地磁盤。為了減少任務(wù)啟動(dòng)時(shí)間粪躬，調(diào)度程序傾向于將任務(wù)分配給已經(jīng)安裝了必要軟件包（程序和數(shù)據(jù)）的計(jì)算機(jī)：大多數(shù)軟件包是不可變的担败，因此可以共享和緩存。 （這是Borg調(diào)度程序支持的唯一的數(shù)據(jù)局部性形式镰官。）此外提前，Borg使用樹和類似torrent的協(xié)議將程序包并行分發(fā)到計(jì)算機(jī)上。
此外泳唠，調(diào)度程序使用多種技術(shù)來擴(kuò)展到具有成千上萬臺(tái)計(jì)算機(jī)的單元（第3.4節(jié)）狈网。
3.3 Borglet
Borglet是本地Borg代理，它存在于單元中的每臺(tái)計(jì)算機(jī)上笨腥。 它開始和停止任務(wù)拓哺； 如果它們失敗，則重新啟動(dòng)它們脖母； 通過操縱操作系統(tǒng)內(nèi)核設(shè)置來管理本地資源士鸥； 滾動(dòng)調(diào)試日志； 并將機(jī)器的狀態(tài)報(bào)告給Borgmaster和其他監(jiān)視系統(tǒng)镶奉。
Borgmaster每隔幾秒鐘會(huì)對(duì)每個(gè)Borglet進(jìn)行一次輪詢础淤，以檢索計(jì)算機(jī)的當(dāng)前狀態(tài)并將其發(fā)送給任何未解決的請(qǐng)求。這使Borgmaster可以控制通信速率哨苛，避免了需要顯式的流量控制機(jī)制鸽凶，并防止了恢復(fù)風(fēng)暴。
當(dāng)選主負(fù)責(zé)準(zhǔn)備的消息發(fā)送到Borglets并與他們的反應(yīng)更新小區(qū)的狀態(tài)建峭。為了提高性能玻侥，每個(gè)Borgmaster副本都運(yùn)行一個(gè)無狀態(tài)鏈接碎片，以處理與某些Borglet的通信亿蒸。每當(dāng)發(fā)生Borgmaster選舉時(shí)凑兰，都會(huì)重新計(jì)算分區(qū)。對(duì)于彈性边锁，在Borglet始終報(bào)告它的全部狀態(tài)姑食，但鏈路聚合碎片和報(bào)告唯一的區(qū)別的狀態(tài)機(jī)，以減少在當(dāng)選主更新負(fù)載壓縮該信息茅坛。
如果Borglet不響應(yīng)多個(gè)輪詢消息音半，則其計(jì)算機(jī)將標(biāo)記為已關(guān)閉，并且其正在運(yùn)行的所有任務(wù)都將在其他計(jì)算機(jī)上重新安排贡蓖。如果恢復(fù)了通訊曹鸠，則Borgmaster會(huì)通知Borglet取消已重新安排的任務(wù)，以避免重復(fù)斥铺。即使Borglet與Borgmaster失去聯(lián)系彻桃，它仍會(huì)繼續(xù)正常運(yùn)行，因此晾蜘，即使所有Borgmaster副本都失敗了邻眷，當(dāng)前運(yùn)行的任務(wù)和服務(wù)也會(huì)保持正常運(yùn)行。
3.4 Scalability（可擴(kuò)展性）
我們不確定Borg集中式架構(gòu)的最終可擴(kuò)展性限制將來自何處笙纤； 到目前為止耗溜，每次達(dá)到極限時(shí)，我們都設(shè)法消除了極限省容。 單個(gè)Borgmaster可以在一個(gè)單元中管理數(shù)千個(gè)機(jī)器抖拴，并且?guī)讉€(gè)單元每分鐘的到達(dá)率超過10000個(gè)任務(wù)。 繁忙的Borgmaster使用10–14個(gè)CPU內(nèi)核和多達(dá)50個(gè)GiB RAM腥椒。 我們使用多種技術(shù)來達(dá)到這一規(guī)模阿宅。
早期版本的Borgmaster具有一個(gè)簡(jiǎn)單的同步循環(huán)，該循環(huán)接受請(qǐng)求笼蛛，計(jì)劃任務(wù)并與Borglet通信洒放。 為了處理更大的單元，我們將調(diào)度程序拆分為一個(gè)單獨(dú)的進(jìn)程滨砍，以便它可以與其他Borgmaster函數(shù)在并行處理中一起運(yùn)行往湿，以復(fù)制它們以實(shí)現(xiàn)容錯(cuò)能力妖异。 調(diào)度程序副本對(duì)單元狀態(tài)的緩存副本進(jìn)行操作。它反復(fù)：從當(dāng)選主（包括分配和暫掛pending工作）檢索狀態(tài)改變; 更新其本地副本领追； 進(jìn)行調(diào)度以分配任務(wù)他膳；并通知那些為signments的選舉的Master。 主機(jī)將接受并應(yīng)用這些分配绒窑，除非它們不合適（例如棕孙，基于過期狀態(tài)），這將導(dǎo)致它們?cè)谡{(diào)度程序的下一個(gè)傳遞中被重新考慮些膨。 這在本質(zhì)上與Omega [69]中使用的樂觀并發(fā)控制非常相似蟀俊，并且實(shí)際上，我們最近為Borg添加了針對(duì)不同工作負(fù)載類型使用不同調(diào)度程序的功能订雾。
為了縮短響應(yīng)時(shí)間肢预，我們添加了單獨(dú)的線程來與Borglet對(duì)話并響應(yīng)只讀RPC。為了獲得更高的性能洼哎，我們將這些功能分片（劃分）到五個(gè)Borgmaster副本§3.3中误甚。它們共同使UI的99％ile響應(yīng)時(shí)間低于1s，并且使Borglet輪詢間隔的95％ile低于10s谱净。
使Borg調(diào)度程序更具可伸縮性的幾件事：
分?jǐn)?shù)緩存：評(píng)估可行性并為機(jī)器評(píng)分是昂貴的窑邦，因此Borg會(huì)緩存分?jǐn)?shù)，直到機(jī)器的屬性或任務(wù)發(fā)生變化–例如壕探，機(jī)器上的任務(wù)終止冈钦，屬性被更改或任務(wù)的要求改變。忽略資源數(shù)量的細(xì)微變化可減少緩存失效李请。
等價(jià)類：Borg作業(yè)中的任務(wù)通常具有相同的要求和約束瞧筛，因此，Borg不會(huì)對(duì)每臺(tái)機(jī)器上的每個(gè)待處理任務(wù)進(jìn)行挖掘可行性导盅，并為所有可行的機(jī)器評(píng)分较幌，Borg只對(duì)每個(gè)等價(jià)項(xiàng)進(jìn)行可行性和評(píng)分類–一組具有相同要求的任務(wù)。
寬松的隨機(jī)化：計(jì)算大型單元中所有計(jì)算機(jī)的可行性和分?jǐn)?shù)是浪費(fèi)的白翻，因此調(diào)度程序以隨機(jī)順序檢查計(jì)算機(jī)乍炉，直到找到“足夠”可行的計(jì)算機(jī)進(jìn)行評(píng)分，然后在其中選擇最佳計(jì)算機(jī)放滤馍。這減少了任務(wù)進(jìn)入和離開系統(tǒng)時(shí)所需的計(jì)分和緩存失效數(shù)量岛琼，并加快了將任務(wù)分配給計(jì)算機(jī)的速度。寬松的隨機(jī)性有點(diǎn)類似于Sparrow [65]的批量采樣巢株，同時(shí)還處理優(yōu)先級(jí)槐瑞，優(yōu)先級(jí)，異質(zhì)性和軟件包安裝成本阁苞。
在我們的實(shí)驗(yàn)（第3節(jié)）中困檩，從頭開始計(jì)劃一個(gè)單元的全部工作量通常需要幾百秒祠挫，但在禁用上述技術(shù)的三天后仍未完成。通過掛起隊(duì)列的傳遞不到半秒鐘即可完成悼沿。
4 可用性
失敗是大型系統(tǒng)中的常態(tài)[10、11显沈、22]。 圖3提供了15個(gè)樣本單元中任務(wù)逐出原因的細(xì)分逢唤。 在Borg上運(yùn)行的應(yīng)用程序應(yīng)使用復(fù)制拉讯，將持久狀態(tài)存儲(chǔ)在分布式文件系統(tǒng)中以及（如果適用）偶爾使用檢查點(diǎn)等技術(shù)來處理此類事件。 即使這樣鳖藕，我們?nèi)栽谂p輕這些事件的影響魔慷。 例如，Brog：
?如有必要著恩，可在新的機(jī)器上自動(dòng)重新安排已撤消的任務(wù)院尔；
通過在不同的故障域（例如機(jī)器，機(jī)架和電源域）中分散作業(yè)的任務(wù)喉誊，減少相關(guān)的故障邀摆；
?限制允許的任務(wù)中斷率和作業(yè)中可以在維護(hù)活動(dòng)（例如OS或機(jī)器升級(jí)）中同時(shí)關(guān)閉的任務(wù)數(shù)量；
?使用聲明性的期望狀態(tài)表示和等效的等效更改操作伍茄，以便失敗的客戶端可以無害地重新提交任何被遺忘的請(qǐng)求栋盹；
?對(duì)無法訪問的計(jì)算機(jī)尋找新位置的速率限制，因?yàn)樗鼰o法區(qū)分大規(guī)模計(jì)算機(jī)故障和網(wǎng)絡(luò)分區(qū)敷矫；
?避免重復(fù)任務(wù)：導(dǎo)致任務(wù)或機(jī)器崩潰的機(jī)器配對(duì)例获；和
?通過反復(fù)重新運(yùn)行l(wèi)ogsaver任務(wù)（第2.4節(jié)）來恢復(fù)寫入本地磁盤的關(guān)鍵中間數(shù)據(jù)，即使已將附加到它的分配終止或移動(dòng)到另一臺(tái)計(jì)算機(jī)也是如此曹仗。用戶可以設(shè)置系統(tǒng)嘗試運(yùn)行多長(zhǎng)時(shí)間榨汤；通常幾天。
Borg的一項(xiàng)關(guān)鍵設(shè)計(jì)功能是怎茫，即使Borgmaster或任務(wù)的Borglet掉線了收壕，已經(jīng)在運(yùn)行的任務(wù)也可以繼續(xù)運(yùn)行。但是保持主機(jī)正常運(yùn)行仍然很重要轨蛤，因?yàn)楫?dāng)主機(jī)關(guān)閉時(shí)啼器，無法提交新作業(yè)或更新現(xiàn)有作業(yè)，并且無法重新計(jì)劃故障機(jī)器中的任務(wù)俱萍。
Borgmaster使用多種技術(shù)組合端壳，使其在實(shí)踐中可實(shí)現(xiàn)99.99％的可用性：復(fù)制以解決機(jī)器故障；準(zhǔn)入控制枪蘑，避免超載损谦；使用簡(jiǎn)單的低級(jí)工具來部署實(shí)例岖免，以最小化外部依賴關(guān)系。每個(gè)單元彼此獨(dú)立照捡，以最大程度地減少相關(guān)的操作員錯(cuò)誤和故障傳播的機(jī)會(huì)颅湘。這些目標(biāo)（而不是可伸縮性限制）是反對(duì)大型單元的主要論據(jù)。
5 使用率
Borg的主要目標(biāo)之一是有效利用Google的機(jī)器群，這是一筆可觀的財(cái)務(wù)投資：將利用率提高幾個(gè)百分點(diǎn)可以節(jié)省數(shù)百萬美元悲立。 本節(jié)討論和評(píng)估Borg用來執(zhí)行此操作的一些策略和技術(shù)鹿寨。
5.1 評(píng)估方法
我們的工作受到放置限制写隶，需要處理罕見的工作量高峰关顷，我們的機(jī)器是異構(gòu)的缺菌，并且我們?cè)趶姆?wù)工作中回收的資源中運(yùn)行批處理工作蚌斩。 因此荆忍，要評(píng)估我們的政策選擇匹耕，我們需要一個(gè)比“平均利用率”更復(fù)雜的指標(biāo)膜蛔。 經(jīng)過大量實(shí)驗(yàn)后螟深，我們選擇了單元壓縮：給定工作負(fù)載后敬特，我們發(fā)現(xiàn)可以通過卸下機(jī)器來裝入一個(gè)小單元格柔吼，直到不再適合工作負(fù)載為止毒费，然后從頭開始重新打包工作負(fù)載以確保我們 沒有掛在一個(gè)不幸的配置上。 這提供了干凈的終止條件愈魏，并有助于自動(dòng)進(jìn)行比較觅玻，而不會(huì)產(chǎn)生合成工作負(fù)荷和建模的陷阱。 評(píng)估技術(shù)的定量比較可以在以下方面找到：細(xì)節(jié)令人驚訝地微妙培漏。
不可能在實(shí)時(shí)生產(chǎn)單元上進(jìn)行實(shí)驗(yàn)溪厘，但是我們使用Fauxmaster來獲得高保真模擬結(jié)果，它使用來自實(shí)際生產(chǎn)單元和工作負(fù)載的數(shù)據(jù)牌柄，包括所有約束畸悬，實(shí)際限制，保留和使用情況 數(shù)據(jù)（第5.5節(jié)）珊佣。 該數(shù)據(jù)來自2014年10月1日（星期三）14:00 采取的博格檢查站蹋宦。 （其他檢查點(diǎn)產(chǎn)生的結(jié)果相似披粟。）我們首先去除專用，測(cè)試和小型（<5000臺(tái)機(jī)器）的小單元冷冗，然后選擇了15個(gè)Borg單元進(jìn)行報(bào)告守屉，然后對(duì)剩余的單元進(jìn)行采樣，以實(shí)現(xiàn)在大小蒿辙。
為了在壓縮單元中保持機(jī)器異質(zhì)性，我們隨機(jī)選擇要移除的機(jī)器习瑰。為了保持工作負(fù)載的異構(gòu)性，我們保留了所有內(nèi)容秽荤，但與特定計(jì)算機(jī)（例如Borglets）相關(guān)的服務(wù)器和存儲(chǔ)任務(wù)除外甜奄。對(duì)于大于原始單元格大小一半的工作，我們將硬約束更改為軟約束窃款，并且如果它們非晨涡郑“挑剔”并且只能放置在少數(shù)機(jī)器上，則允許最多0.2％的任務(wù)掛起晨继。廣泛的實(shí)驗(yàn)表明烟阐，這種方法產(chǎn)生的結(jié)果具有低方差的可重復(fù)性。如果我們需要比原始細(xì)胞更大的細(xì)胞紊扬，可以在壓實(shí)之前將原始單元克隆幾次蜒茄。如果我們需要更多的單元格，則只需克隆原始單元格即可餐屎。
對(duì)于具有不同隨機(jī)數(shù)種子的每個(gè)細(xì)胞檀葛，將每個(gè)實(shí)驗(yàn)重復(fù)11次。在圖形中腹缩，我們使用錯(cuò)誤欄顯示所需機(jī)器的最小值和最大值屿聋，然后選擇90％ile值作為“結(jié)果” –平均值或中位數(shù)不會(huì)反映系統(tǒng)管理員所要執(zhí)行的操作如果他們想要合理地確定工作量是否合適，管理員就會(huì)這樣做藏鹊。我們認(rèn)為單元壓縮提供了一種公平润讥，一致的方式來比較調(diào)度策略，它直接轉(zhuǎn)化為成本/收益結(jié)果：更好的策略需要更少的計(jì)算機(jī)來運(yùn)行相同的工作負(fù)載盘寡。
我們的實(shí)驗(yàn)著重于從某個(gè)時(shí)間點(diǎn)安排（打包）工作負(fù)載楚殿，而不是重播長(zhǎng)期工作負(fù)載跟蹤。這部分是為了避免處理開放和關(guān)閉隊(duì)列模型的困難[71竿痰，79]勒魔，部分是因?yàn)閭鹘y(tǒng)的完成時(shí)間指標(biāo)不適用于我們的環(huán)境甫煞，因?yàn)樗拈L(zhǎng)期服務(wù)不完整，部分是為了提供清晰的信號(hào)之所以進(jìn)行比較冠绢，部分是因?yàn)槲覀冋J(rèn)為結(jié)果不會(huì)有明顯的不同抚吠，部分是實(shí)際的問題：我們發(fā)現(xiàn)自己一次消耗了20萬個(gè)Borg CPU內(nèi)核用于我們的實(shí)驗(yàn)，即使在Google的規(guī)模上弟胀，這也是不平凡的投資楷力。
在生產(chǎn)中，我們故意為工作量增長(zhǎng)孵户，偶爾的“黑天鵝”事件萧朝，負(fù)載峰值，機(jī)器故障夏哭，硬件升級(jí)以及大規(guī)模局部故障（例如電源母線槽）留有很大的余量检柬。圖4顯示了如果我們對(duì)它們應(yīng)用單元壓縮，則實(shí)際單元將縮小多少竖配。下圖中的基線使用這些壓縮的大小何址。
5.2 Cell sharing（單元共享）
我們幾乎所有的機(jī)器都同時(shí)執(zhí)行生產(chǎn)任務(wù)和非生產(chǎn)任務(wù)：共享的Borg單元中有98％的計(jì)算機(jī)，由Borg管理的整套計(jì)算機(jī)中有83％进胯。 （我們有一些專用單元用于特殊用途用爪。）
由于許多其他組織在單獨(dú)的群集中運(yùn)行面向用戶和批處理的作業(yè)，因此我們研究了如果執(zhí)行相同的操作會(huì)發(fā)生什么情況胁镐。圖5顯示偎血，將生產(chǎn)工作和非生產(chǎn)工作分開需要在中位單元中增加20–30％的計(jì)算機(jī)來運(yùn)行我們的工作負(fù)載。這是因?yàn)樯a(chǎn)作業(yè)通常會(huì)保留資源以處理罕見的工作量高峰盯漂，但大多數(shù)時(shí)候不會(huì)使用這些資源颇玷。 Borg回收了未使用的資源（第5.5節(jié)）來運(yùn)行許多非生產(chǎn)性工作，因此我們總體上需要的機(jī)器更少就缆。
大多數(shù)Borg單元由成千上萬的用戶共享亚隙。圖6顯示了原因。在此測(cè)試中违崇，如果用戶消耗了至少10 TiB的內(nèi)存（或100 TiB）阿弃，我們會(huì)將用戶的工作量劃分為一個(gè)新的單元。我們現(xiàn)有的策略看起來不錯(cuò)：即使閾值較大羞延，我們也需要2–16倍的單元格渣淳，以及20–150％的額外計(jì)算機(jī)。再一次伴箩，合并資源將大大降低成本入愧。
但是也許將不相關(guān)的用戶和作業(yè)類型打包到同一臺(tái)計(jì)算機(jī)上會(huì)導(dǎo)致CPU干擾，因此我們需要更多的計(jì)算機(jī)來進(jìn)行補(bǔ)償嗎？ 為了評(píng)估這一點(diǎn)棺蛛，我們研究了在以相同機(jī)器類型和相同時(shí)鐘速度運(yùn)行的不同環(huán)境中怔蚌，任務(wù)的CPI（每條指令的周期數(shù)）如何變化。 在這些條件下旁赊，CPI值是可比較的桦踊，并且可以用作性能干擾的代理，因?yàn)镃PI的兩倍會(huì)使CPU綁定程序的運(yùn)行時(shí)間加倍终畅。 數(shù)據(jù)是在一周內(nèi)從大約12000個(gè)隨機(jī)選擇的產(chǎn)品任務(wù)中收集的籍胯，使用[83]中所述的硬件配置基礎(chǔ)結(jié)構(gòu)在5分鐘的間隔內(nèi)對(duì)周期和指令進(jìn)行計(jì)數(shù)，并對(duì)樣本進(jìn)行加權(quán)离福，以便計(jì)算每秒的CPU時(shí)間 一樣杖狼。 結(jié)果不明確。
（1）我們發(fā)現(xiàn)CPI與同一時(shí)間間隔內(nèi)的兩次測(cè)量值呈正相關(guān)：計(jì)算機(jī)上的總體CPU使用率和（主要獨(dú)立地）計(jì)算機(jī)上的任務(wù)數(shù)量妖爷；向計(jì)算機(jī)添加任務(wù)將其他任務(wù)的CPI提高0.3％（使用適合數(shù)據(jù)的線性模型）蝶涩；將機(jī)器CPU使用率提高10％，將CPI降低不到2％絮识。但是绿聘，即使相關(guān)性具有統(tǒng)計(jì)學(xué)意義，它們也只能解釋我們?cè)贑PI測(cè)量中看到的5％的變化笋除；其他因素占主導(dǎo)地位斜友，例如應(yīng)用中的固有差異和特定的干擾模式[24炸裆、83]垃它。
（2）將我們從共享單元中采樣的CPI與少數(shù)應(yīng)用較少的專用單元中的CPI進(jìn)行比較，我們發(fā)現(xiàn)共享單元中的CPI平均為1.58（σ= 0.35）烹看，平均值為1.53（σ= 0.32）在專用單元中–即国拇，共享單元中的CPU性能大約降低3％。
（3）為了解決不同小區(qū)中的應(yīng)用程序可能具有不同的工作負(fù)載甚至遭受選擇偏見（可能對(duì)干擾更敏感的程序已移至專用小區(qū)）的擔(dān)憂惯殊，我們研究了運(yùn)行Borglet的CPI酱吝。在兩種類型的單元中的所有機(jī)器上。我們發(fā)現(xiàn)專用單元的CPI為1.20（σ= 0.29）土思，共享單元的CPI為1.43（σ= 0.45）务热，這表明它在專用單元中的運(yùn)行速度是共享單元的1.19倍，盡管這種超重輕載機(jī)器的效果己儒，將結(jié)果稍微偏向于專用單元崎岂。
這些實(shí)驗(yàn)證實(shí)，在倉(cāng)庫(kù)規(guī)模上進(jìn)行性能比較是很棘手的闪湾，這增強(qiáng)了[51]中的觀察冲甘，并且還表明共享并不會(huì)顯著增加運(yùn)行程序的成本。
但是即使假設(shè)我們的結(jié)果是最不利的，共享仍然是一個(gè)勝利：在幾種不同的分區(qū)方案下江醇，所需的計(jì)算機(jī)數(shù)量減少了濒憋，CPU的速度下降卻無法彌補(bǔ)，共享優(yōu)勢(shì)也適用于包括內(nèi)存在內(nèi)的所有資源 和磁盤陶夜，而不僅僅是CPU凛驮。
5.3 Large cells（大單元）
Google建立大型單元，既可以運(yùn)行大型計(jì)算律适，又可以減少資源碎片辐烂。 我們通過將一個(gè)單元的工作負(fù)載劃分為多個(gè)較小的單元來測(cè)試后者的效果–首先隨機(jī)排列作業(yè)，然后以循環(huán)方式在分區(qū)之間分配它們捂贿。 圖7確認(rèn)使用較小的單元將需要更多的計(jì)算機(jī)纠修。
5.4 Fine-grained resource requests（細(xì)粒度的資源請(qǐng)求）
Borg用戶以毫核心為單位請(qǐng)求CPU，以字節(jié)為單位請(qǐng)求內(nèi)存和磁盤空間颜屠。 （一個(gè)內(nèi)核是處理器超線程辰妙，針對(duì)各種機(jī)器類型的性能進(jìn)行了標(biāo)準(zhǔn)化。）圖8顯示了它們利用了這種粒度：請(qǐng)求的內(nèi)存或CPU內(nèi)核數(shù)量幾乎沒有明顯的“最佳結(jié)合點(diǎn)”甫窟，并且它們之間幾乎沒有明顯的關(guān)聯(lián) 這些資源密浑。 這些分布與[68]中介紹的分布非常相似，不同之處在于粗井，在90％或更高的位置上尔破，我們看到的存儲(chǔ)請(qǐng)求稍大一些。
提供一組固定大小的容器或虛擬機(jī)胆剧，盡管在IaaS（基礎(chǔ)架構(gòu)即服務(wù)）提供商中很常見[7，33]醉冤，但這并不能很好地滿足我們的需求秩霍。 為了說明這一點(diǎn)，我們通過將求出作業(yè)和分配的值四舍五入到每個(gè)資源維度中的下一個(gè)最接近的冪次冪（“ 2.4”）來“破壞” CPU內(nèi)核和內(nèi)存資源的限制蚁阳，從CPU的0.5個(gè)內(nèi)核和RAM的1 GiB開始 铃绒。 圖9顯示，在中位數(shù)情況下韵吨，這樣做將需要增加30％到50％的資源匿垄。 上限來自將整臺(tái)計(jì)算機(jī)分配給在壓縮開始之前將原始單元格增加四倍后無法滿足的大型任務(wù)移宅； 允許這些任務(wù)掛起的下限。 （這少于[37]中報(bào)告的大約100％的開銷椿疗，因?yàn)槲覀冎С?個(gè)以上的存儲(chǔ)桶漏峰，并允許CPU和RAM的容量獨(dú)立擴(kuò)展。）
5.5 Resource reclamation（資源回收）
作業(yè)可以指定資源限制-每個(gè)任務(wù)應(yīng)被授予的資源上限靖苇。 Borg使用該限制來確定用戶是否有足夠的配額來接受作業(yè)，并確定特定的計(jì)算機(jī)是否具有足夠的可用資源來安排任務(wù)班缰。就像有些用戶購(gòu)買的配額超出所需數(shù)量一樣贤壁，有些用戶請(qǐng)求的資源超出其任務(wù)使用的數(shù)量，因?yàn)锽org通常會(huì)終止一個(gè)任務(wù)埠忘，該任務(wù)嘗試使用比其請(qǐng)求更多的RAM或磁盤空間脾拆，或者限制CPU使用它要求什么。另外莹妒，某些任務(wù)有時(shí)需要使用其所有資源（例如名船，在一天中的高峰時(shí)間或在應(yīng)對(duì)拒絕服務(wù)攻擊時(shí)），但大多數(shù)時(shí)候不需要旨怠。
我們不是浪費(fèi)當(dāng)前分配的資源渠驼，而不會(huì)浪費(fèi)掉當(dāng)前消耗的資源，而是估計(jì)任務(wù)將使用多少資源鉴腻，并將剩余資源回收用于可以忍受質(zhì)量較低的資源的工作迷扇，例如批處理作業(yè)。整個(gè)過程稱為資源回收拘哨。估算值稱為任務(wù)的預(yù)留量谋梭，它由Borgmaster每隔幾秒鐘使用Borglet捕獲的細(xì)粒度使用情況（資源消耗）信息進(jìn)行計(jì)算信峻。初始預(yù)留被設(shè)置為等于資源請(qǐng)求（限制）倦青； 300秒后，為了允許啟動(dòng)瞬態(tài)盹舞，它會(huì)逐漸衰減到實(shí)際使用量并增加安全裕度产镐。如果使用量超過預(yù)定量，則預(yù)定量會(huì)迅速增加踢步。
Borg調(diào)度程序使用限制來計(jì)算生產(chǎn)任務(wù)的可行性（第3.2節(jié)）癣亚，因此它們從不依賴回收的資源，也不會(huì)受到資源的過度訂購(gòu)获印；對(duì)于非生產(chǎn)性任務(wù)述雾，它使用現(xiàn)有任務(wù)的保留，以便可以將新任務(wù)調(diào)度到回收的資源中。
如果預(yù)留（預(yù)測(cè)）有誤玻孟，則計(jì)算機(jī)可能會(huì)在運(yùn)行時(shí)用盡資源唆缴，即使所有任務(wù)使用的資源少于其限制。如果發(fā)生這種情況黍翎，我們將殺死或限制非生產(chǎn)性任務(wù)面徽，而不是非生產(chǎn)性任務(wù)。
圖10顯示匣掸，如果沒有資源回收趟紊，將需要更多的機(jī)器。大約20％的工作負(fù)載（第6.2節(jié)）在中位單元中的回收資源中運(yùn)行碰酝。
我們可以在圖11中看到更多詳細(xì)信息霎匈，該圖顯示了預(yù)留量和使用量與限制的比率。如果需要資源送爸，則無論其優(yōu)先級(jí)如何唧躲，超過其內(nèi)存限制的任務(wù)將首先被搶占，因此很少有任務(wù)超過其內(nèi)存限制碱璃。另一方面弄痹，CPU很容易受到限制，因此短期峰值可能會(huì)無害地使使用率超出預(yù)留量嵌器。
圖11表明資源回收可能不一定是保守的：在預(yù)留和使用線之間有很大的區(qū)域肛真。為了對(duì)此進(jìn)行測(cè)試，我們選擇了一個(gè)實(shí)時(shí)生產(chǎn)單元爽航，并通過降低安全裕度將其資源估算算法的參數(shù)調(diào)整為激進(jìn)設(shè)置一周蚓让，然后將其設(shè)置為介于基線和激進(jìn)設(shè)置之間的中間設(shè)置接下來的一周，然后恢復(fù)到基準(zhǔn)讥珍。
圖12顯示了發(fā)生的情況克婶。 預(yù)訂明顯在第二周接近使用筒严，而在第三周則有所減少丹泉，在基準(zhǔn)周（第一和第四周）顯示出最大的差距。 如預(yù)期的那樣鸭蛙，在第2周和第3.5周嘀掸，內(nèi)存不足（OOM）事件的發(fā)生率略有增加。在審查了這些結(jié)果之后规惰，我們認(rèn)為凈收益抵消了負(fù)面影響睬塌，并將中型資源回收參數(shù)部署到了其他單元中。
6 隔離（Isolation）
我們有50％的計(jì)算機(jī)運(yùn)行9個(gè)或更多任務(wù)膏斤； 一臺(tái)90％的計(jì)算機(jī)可執(zhí)行約25個(gè)任務(wù)徐绑，并將運(yùn)行約4500個(gè)線程。 盡管在應(yīng)用程序之間共享計(jì)算機(jī)可以提高利用率莫辨，但是它還需要良好的機(jī)制來防止任務(wù)相互干擾傲茄。 這適用于安全性和性能。
6.1 安全隔離
我們使用Linux chroot監(jiān)獄作為同一臺(tái)計(jì)算機(jī)上多個(gè)任務(wù)之間的主要安全隔離機(jī)制衔掸。 為了允許進(jìn)行遠(yuǎn)程調(diào)試烫幕，我們習(xí)慣于自動(dòng)分發(fā)（和撤消）ssh密鑰俺抽，以使用戶僅在計(jì)算機(jī)正在為用戶運(yùn)行任務(wù)時(shí)才對(duì)其進(jìn)行訪問敞映。 對(duì)于大多數(shù)用戶而言，它已被Borg ssh命令所代替磷斧，該命令與Borglet協(xié)作以建立到與該任務(wù)在同一chroot和cgroup中運(yùn)行的shell的ssh連接振愿，從而更緊密地鎖定訪問捷犹。
VM和安全沙箱技術(shù)被Google的AppEngine（GAE）和Google Compute Engine（GCE）用于運(yùn)行外部軟件。 我們?cè)谧鳛锽org任務(wù)運(yùn)行的KVM進(jìn)程中運(yùn)行每個(gè)托管的VM冕末。
6.2 性能隔離
早期版本的Borglet具有相對(duì)原始的資源隔離實(shí)施：對(duì)內(nèi)存萍歉，磁盤空間和CPU周期進(jìn)行事后使用檢查，結(jié)合使用過多內(nèi)存或磁盤的任務(wù)的終止以及積極使用Linux的CPU優(yōu)先級(jí)來控制任務(wù)那用了太多的CPU档桃。但是枪孩，流氓任務(wù)仍然很容易影響計(jì)算機(jī)上其他任務(wù)的性能，因此一些用戶夸大了他們的資源請(qǐng)求藻肄，以減少Borg可以與他們共同調(diào)度的任務(wù)數(shù)量蔑舞，從而降低了利用率。由于涉及的安全邊際嘹屯，資源回收可以收回部分盈余攻询，但不是全部。在最極端的情況下州弟，用戶請(qǐng)?jiān)甘褂脤Ｓ玫臋C(jī)器或單元钧栖。
現(xiàn)在，所有Borg任務(wù)都在基于Linux cgroup的資源容器[17婆翔、58拯杠、62]中運(yùn)行，并且Borglet操縱容器設(shè)置啃奴，由于OS內(nèi)核處于循環(huán)狀態(tài)阴挣，因此大大提高了控制能力。即使這樣纺腊，偶爾也會(huì)發(fā)生低級(jí)資源干擾（例如畔咧，內(nèi)存帶寬或L3緩存污染），如[60揖膜，83]中所示誓沸。
為了幫助進(jìn)行過載和超額使用，Borg任務(wù)具有一個(gè)應(yīng)用程序類或appclass壹粟。最重要的區(qū)別是延遲敏感型（LS）應(yīng)用程序類與其余類之間的區(qū)別拜隧，在本文中我們將其稱為批處理。 LS任務(wù)用于需要快速響應(yīng)請(qǐng)求的面向用戶的應(yīng)用程序和共享基礎(chǔ)結(jié)構(gòu)服務(wù)趁仙。高優(yōu)先級(jí)LS任務(wù)得到最好的處理洪添，并且能夠一次使批處理任務(wù)餓死幾秒鐘。
第二個(gè)劃分是基于速率的可壓縮資源（例如雀费，CPU周期干奢，磁盤I / O帶寬）之間的劃分，可以通過降低其服務(wù)質(zhì)量而不殺死它來將其從任務(wù)中回收盏袄；以及不可壓縮的資源（例如內(nèi)存忿峻，磁盤空間）薄啥，這些資源通常在不終止任務(wù)的情況下無法收回。如果計(jì)算機(jī)用盡了不可壓縮的資源逛尚，則Borglet會(huì)立即終止從最低優(yōu)先級(jí)到最高優(yōu)先級(jí)的任務(wù)垄惧，直到可以滿足剩余的保留。如果計(jì)算機(jī)用盡了可壓縮資源绰寞，則Borglet會(huì)限制使用（有利于LS任務(wù)）到逊，以便可以處理短暫的負(fù)載尖峰而不會(huì)殺死任何任務(wù)。如果情況沒有改善滤钱，Borgmaster將從計(jì)算機(jī)中刪除一項(xiàng)或多項(xiàng)任務(wù)蕾管。
Borglet中的用戶空間控制循環(huán)根據(jù)預(yù)測(cè)的未來使用情況（針對(duì)生產(chǎn)任務(wù)）或內(nèi)存壓力（針對(duì)非生產(chǎn)任務(wù)）將容器分配給內(nèi)存；處理來自內(nèi)核的內(nèi)存不足（OOM）事件菩暗；當(dāng)他們嘗試分配超出其內(nèi)存限制的內(nèi)存時(shí)掰曾，或者當(dāng)過量使用的計(jì)算機(jī)實(shí)際上耗盡內(nèi)存時(shí)，它們就會(huì)殺死這些任務(wù)停团。 Linux急切的文件緩存大大簡(jiǎn)化了實(shí)現(xiàn)過程旷坦，因?yàn)樗枰_的
內(nèi)存會(huì)計(jì)。
為了改善性能隔離佑稠，LS任務(wù)可以保留整個(gè)物理CPU內(nèi)核秒梅，這將阻止其他LS任務(wù)使用它們。批處理任務(wù)可以在任何內(nèi)核上運(yùn)行舌胶，但是相對(duì)于LS任務(wù)捆蜀，它們具有很小的調(diào)度程序份額。 Borglet動(dòng)態(tài)調(diào)整貪婪LS任務(wù)的資源上限幔嫂，以確保它們不會(huì)在數(shù)分鐘內(nèi)使批處理任務(wù)餓死辆它，并在需要時(shí)有選擇地應(yīng)用CFS帶寬控制[75]；份額不足履恩，因?yàn)槲覀冇卸鄠€(gè)優(yōu)先級(jí)锰茉。
像Leverich [56]一樣，我們發(fā)現(xiàn)標(biāo)準(zhǔn)的Linux CPU調(diào)度程序（CFS）需要大量調(diào)整才能支持低延遲和高利用率切心。為了減少調(diào)度延遲飒筑，我們的CFS版本使用了擴(kuò)展的每組負(fù)載歷史記錄[16]，允許LS任務(wù)搶占批處理任務(wù)绽昏，并在CPU上運(yùn)行多個(gè)LS任務(wù)時(shí)減少了調(diào)度時(shí)間协屡。幸運(yùn)的是，我們的許多應(yīng)用程序都使用了“每個(gè)請(qǐng)求線程”模型全谤，從而減輕了
持續(xù)的負(fù)載失衡的影響肤晓。我們很少使用cpusets將CPU內(nèi)核分配給延遲要求特別嚴(yán)格的應(yīng)用程序。這些努力的一些結(jié)果如圖13所示。在這一領(lǐng)域中材原，工作繼續(xù)進(jìn)行沸久，增加了線程放置和支持NUMA季眷，超線程和功耗感知的CPU管理（例如[81]）余蟹，并提高了Borg的let控制保真度。
允許任務(wù)消耗最大資源子刮。 允許它們中的大多數(shù)超出諸如CPU之類的可壓縮資源的使用范圍威酒，以利用未使用的（松弛）資源稿黄。 大概只有5％的LS任務(wù)禁用了此功能史侣，大概是為了獲得更好的可預(yù)測(cè)性。 不到批處理任務(wù)的1％暇榴。 默認(rèn)情況下橱赠，使用閑置內(nèi)存是禁用的尤仍，因?yàn)樗鼤?huì)增加任務(wù)被殺死的機(jī)會(huì)，但是即使如此狭姨，仍有10％的LS任務(wù)會(huì)覆蓋它宰啦，而79％的批處理任務(wù)會(huì)這樣做，這是因?yàn)檫@是默認(rèn)設(shè)置 MapReduce框架饼拍。 這補(bǔ)充了回收資源的結(jié)果（第5.5節(jié)）赡模。 批處理任務(wù)愿意利用未使用的以及回收的內(nèi)存：在大多數(shù)情況下，這是可行的师抄，盡管當(dāng)LS任務(wù)急需資源時(shí)偶爾的批處理任務(wù)也會(huì)被犧牲掉漓柑。
7 相關(guān)工作
資源調(diào)度已經(jīng)研究了數(shù)十年，涉及范圍廣泛叨吮，例如廣域HPC超級(jí)計(jì)算網(wǎng)格辆布，工作站網(wǎng)絡(luò)和大型服務(wù)器集群。 在這里茶鉴，我們僅關(guān)注與大型服務(wù)器集群有關(guān)的最相關(guān)的工作谚殊。
最近的幾項(xiàng)研究分析了來自Yahoo！蛤铜，Google和Facebook的集群跟蹤[20嫩絮、52、63围肥、68剿干、70、80穆刻、82]置尔，并說明了在這些現(xiàn)代數(shù)據(jù)中心和工作負(fù)載中規(guī)模和異構(gòu)性所面臨的挑戰(zhàn)。 [69]包含集群管理器體系結(jié)構(gòu)的分類法氢伟。
Apache Mesos [45]使用基于報(bào)價(jià)的機(jī)制在中央資源管理器（類似于Borgmaster減去其調(diào)度程序）和多個(gè)“框架”（例如Hadoop [41]和Spark [73]）之間劃分資源管理和放置功能榜轿。 Borg主要使用可擴(kuò)展性很好的基于請(qǐng)求的機(jī)制來集中這些功能幽歼。 DRF [29、35谬盐、36甸私、66]最初是為Mesos開發(fā)的； Borg改用優(yōu)先級(jí)和入場(chǎng)配額飞傀。 Mesos開發(fā)人員已經(jīng)宣布了雄心壯志皇型，將Mesos擴(kuò)展到包括投機(jī)性資源分配和收回，并解決[69]中確定的一些問題砸烦。
YARN [76]是一個(gè)以Hadoop為中心的集群管理器弃鸦。每個(gè)應(yīng)用程序都有一個(gè)管理器，該管理器與中央資源管理器協(xié)商所需資源幢痘。自從大約2008年以來唬格，Google MapReduce作業(yè)就一直使用該方案來從博格（Borg）獲取資源。YARN的資源管理器直到最近才變得容錯(cuò)颜说。一項(xiàng)相關(guān)的開源工作是Hadoop Capacity Scheduler [42]购岗，它提供了多租戶支持，并具有容量保證脑沿，分層隊(duì)列藕畔，彈性共享和公平性。 YARN最近已擴(kuò)展為支持多種資源類型庄拇，優(yōu)先級(jí)注服，搶占和高級(jí)準(zhǔn)入控制[21]。俄羅斯方塊的研究原型[40]支持可識(shí)別makepan的作業(yè)打包措近。
Facebook的Tupperware [64]是一種類似于Borg的系統(tǒng)溶弟，用于在群集上調(diào)度cgroup容器；盡管似乎提供了一種資源回收的形式瞭郑，但僅公開了一些細(xì)節(jié)辜御。 Twitter已開源Aurora [5]，這是一種類似于Borg的調(diào)度程序屈张，用于在Mesos上運(yùn)行的長(zhǎng)期運(yùn)行的服務(wù)擒权，其配置語言和狀態(tài)機(jī)與Borg相似。
微軟的自動(dòng)駕駛系統(tǒng)[48]提供了“自動(dòng)軟件的配置和部署阁谆；自動(dòng)的軟件配置和部署”碳抄。系統(tǒng)監(jiān)控；并針對(duì)Microsoft群集執(zhí)行修復(fù)措施以處理錯(cuò)誤的軟件和硬件”场绿。博格（Borg）生態(tài)系統(tǒng)提供了類似的功能剖效，但這里不進(jìn)行討論。 Isaard [48]概述了我們也遵循的許多最佳實(shí)踐。
Quincy [49]使用網(wǎng)絡(luò)流模型為數(shù)百個(gè)節(jié)點(diǎn)的群集上的數(shù)據(jù)處理DAG提供公平性和數(shù)據(jù)局部性感知調(diào)度璧尸。 Borg使用配額和優(yōu)先級(jí)在用戶之間共享資源咒林，并擴(kuò)展到成千上萬臺(tái)計(jì)算機(jī)。 Quincy直接在Borg之上構(gòu)建執(zhí)行圖爷光，而直接處理執(zhí)行圖垫竞。
Cosmos [44]專注于批處理，重點(diǎn)在于確保其用戶能夠公平地訪問他們捐贈(zèng)給集群的資源瞎颗。它使用每個(gè)職位的經(jīng)理來獲取資源件甥；公開的細(xì)節(jié)很少捌议。
微軟的Apollo系統(tǒng)[13]使用每個(gè)作業(yè)的調(diào)度程序來處理短暫的批處理作業(yè)哼拔，以在集群規(guī)模似乎與Borg單元相當(dāng)?shù)募荷蠈?shí)現(xiàn)高吞吐量。 Apollo利用機(jī)會(huì)優(yōu)先執(zhí)行較低優(yōu)先級(jí)的后臺(tái)工作瓣颅，以（有時(shí)）數(shù)天的排隊(duì)延遲為代價(jià)將利用率提高到較高水平倦逐。 Apollo節(jié)點(diǎn)提供了任務(wù)開始時(shí)間的預(yù)測(cè)矩陣，該矩陣是兩個(gè)資源維度上大小的函數(shù)宫补，調(diào)度程序?qū)⑵渑c啟動(dòng)成本和遠(yuǎn)程數(shù)據(jù)訪問的估計(jì)結(jié)合起來以做出放置決策檬姥，并通過隨機(jī)延遲進(jìn)行調(diào)制以減少?zèng)_突。 Borg使用一個(gè)中央調(diào)度程序來根據(jù)有關(guān)先前分配的狀態(tài)來進(jìn)行放置決策粉怕，可以處理更多的資源維度健民，并專注于高可用性，長(zhǎng)期運(yùn)行的應(yīng)用程序的需求贫贝；阿波羅可能可以處理更高的任務(wù)到達(dá)率秉犹。
阿里巴巴的Fuxi [84]支持?jǐn)?shù)據(jù)分析工作負(fù)載；它自2009年以來一直在運(yùn)行稚晚。像Borgmaster一樣崇堵，中央FuxiMaster（為容錯(cuò)而復(fù)制）從節(jié)點(diǎn)收集資源可用性信息，接受來自應(yīng)用程序的請(qǐng)求客燕，然后將它們相互匹配鸳劳。 Fuxi增量調(diào)度策略是Borg等價(jià)類的反函數(shù)：Fuxi不會(huì)將每個(gè)任務(wù)匹配到一組合適的計(jì)算機(jī)上，而是將新可用的資源與待處理工作的積壓進(jìn)行匹配也搓。與Mesos一樣赏廓，F(xiàn)uxi允許定義“虛擬資源”類型。只有合成工作負(fù)載結(jié)果可公開獲得傍妒。
Omega [69]支持多個(gè)并行的幔摸，專門的“垂直”，每個(gè)垂直近似于一個(gè)Borgmaster減去其持久性存儲(chǔ)和鏈接碎片拍顷。 Omega調(diào)度程序使用樂觀并發(fā)控制來操作存儲(chǔ)在中央持久性存儲(chǔ)中的所需和觀察到的單元狀態(tài)的共享表示抚太，并通過單獨(dú)的鏈接組件與Borglets同步。 Omega架構(gòu)的設(shè)計(jì)旨在支持多個(gè)不同的工作負(fù)載，這些工作負(fù)載具有自己的特定于應(yīng)用程序的RPC接口尿贫，狀態(tài)機(jī)和調(diào)度策略（例如电媳，長(zhǎng)時(shí)間運(yùn)行的服務(wù)器，來自各種框架的批處理作業(yè)庆亡，基礎(chǔ)設(shè)施服務(wù)（如集群存儲(chǔ)系統(tǒng)） 匾乓，來自Google Cloud Platform的虛擬機(jī)）。另一方面又谋，Borg提供了“千篇一律”的RPC接口拼缝，狀態(tài)機(jī)語義和調(diào)度器策略，由于需要支持許多不同的工作負(fù)載彰亥，它們的大小和復(fù)雜性隨著時(shí)間的推移而增長(zhǎng)咧七。尚未成為問題（第3.4節(jié)）。
Google的開源Kubernetes系統(tǒng)[53]將應(yīng)用程序放置在Docker容器[28]中的多個(gè)主機(jī)節(jié)點(diǎn)上任斋。它既可以在裸機(jī)（例如Borg）上運(yùn)行继阻，也可以在各種云托管提供商（例如Google Compute Engine）上運(yùn)行。許多建造Borg的工程師都在積極開發(fā)它废酷。 Google提供了一個(gè)稱為Google Container Engine [39]的托管版本瘟檩。在下一節(jié)中，我們將討論如何將來自Borg的課程應(yīng)用于Kubernetes澈蟆。
高性能計(jì)算社區(qū)在這一領(lǐng)域具有悠久的工作傳統(tǒng)（例如墨辛，毛伊島，摩押市趴俘，LSF平臺(tái)[2睹簇，47，50]）哮幢；但是規(guī)模带膀，工作量和容錯(cuò)性的要求與Google單元的要求不同。通常橙垢，此類系統(tǒng)通過處理大量未完成的工作積壓（隊(duì)列）來實(shí)現(xiàn)高利用率垛叨。
虛擬化提供程序（例如VMware [77]）和數(shù)據(jù)中心解決方案提供程序（例如HP和IBM [46]）提供的群集管理解決方案通常可擴(kuò)展到O（1000）臺(tái)計(jì)算機(jī)柜某。另外嗽元，一些研究小組擁有原型系統(tǒng)，可以通過某些方式（例如[25喂击、40剂癌、72、74]）提高調(diào)度決策的質(zhì)量翰绊。
最后佩谷，正如我們已經(jīng)指出的那樣旁壮，管理大型集群的另一個(gè)重要部分是自動(dòng)化和“操作員擴(kuò)展”。 [43]描述了如何計(jì)劃故障谐檀，多租戶抡谐，運(yùn)行狀況檢查，準(zhǔn)入控制和可重啟性桐猬，以使每個(gè)操作員擁有大量機(jī)器麦撵。博格（Borg）的設(shè)計(jì)理念是相似的，它使我們能夠?yàn)槊總€(gè)操作員（SRE）提供數(shù)萬臺(tái)機(jī)器溃肪。
8 經(jīng)驗(yàn)教訓(xùn)和未來工作
在本節(jié)中免胃，我們講述了從十多年來在生產(chǎn)中使用Borg所學(xué)到的定性課程，并描述了如何在設(shè)計(jì)Kubernetes時(shí)利用這些觀察結(jié)果[53]惫撰。
8.1 經(jīng)驗(yàn)教訓(xùn)：不好
我們從用作警告故事的Borg的一些功能入手羔沙，并在Kubernetes中提供了明智的替代設(shè)計(jì)。
作業(yè)是唯一限制任務(wù)的分組機(jī)制润绎。 Borg沒有一流的方法來將整個(gè)多職位服務(wù)作為單個(gè)實(shí)體進(jìn)行管理撬碟，也無法引用服務(wù)的相關(guān)實(shí)例（例如诞挨，金絲雀和生產(chǎn)軌道）莉撇。作為一種黑客，用戶將其服務(wù)拓?fù)渚幋a在作業(yè)名稱中惶傻，并構(gòu)建更高級(jí)別的管理工具來解析這些名稱棍郎。另一方面，不可能引用作業(yè)的任意子集银室，這會(huì)導(dǎo)致諸如滾動(dòng)更新和調(diào)整作業(yè)大小的語義不靈活等問題涂佃。
為了避免此類困難，Kubernetes拒絕任務(wù)指示蜈敢，而是使用標(biāo)簽（用戶可以將其附加到系統(tǒng)中的任何對(duì)象的標(biāo)簽/值對(duì)）來組織其調(diào)度單位（pod）辜荠。可以通過將job：jobname標(biāo)簽附加到一組pod來實(shí)現(xiàn)等效的Borg作業(yè)抓狭，但是也可以表示任何其他有用的分組伯病，例如服務(wù)，層或發(fā)布類型（例如否过，生產(chǎn)午笛，標(biāo)記） ing，測(cè)試）苗桂。 Kubernetes中的操作通過標(biāo)簽查詢來標(biāo)識(shí)其目標(biāo)药磺，標(biāo)簽查詢選擇操作應(yīng)應(yīng)用于的對(duì)象。這種方法比作業(yè)的單個(gè)固定分組具有更大的靈活性煤伟。
每臺(tái)機(jī)器一個(gè)IP地址會(huì)使事情變得復(fù)雜癌佩。在Borg中木缝，計(jì)算機(jī)上的所有任務(wù)都使用其主機(jī)的單個(gè)IP地址，從而共享主機(jī)的端口空間围辙。這帶來了許多困難：Borg必須安排端口作為資源氨肌；任務(wù)必須預(yù)先聲明它們需要多少個(gè)端口，并愿意在啟動(dòng)時(shí)被告知要使用哪些端口酌畜；
Borglet必須強(qiáng)制執(zhí)行端口隔離怎囚；并且命名和RPC系統(tǒng)必須處理端口以及IP地址。
由于Linux名稱空間桥胞，VM恳守，IPv6和軟件定義的網(wǎng)絡(luò)的出現(xiàn)，Kubernetes可以采用一種更加用戶友好的方法來消除這些復(fù)雜性：每個(gè)pod和服務(wù)都有其自己的IP地址贩虾，從而允許開發(fā)人員選擇端口而不是選擇端口催烘。要求其軟件適應(yīng)基礎(chǔ)架構(gòu)選擇的軟件，并消除管理端口的基礎(chǔ)架構(gòu)復(fù)雜性缎罢。
針對(duì)高級(jí)用戶進(jìn)行優(yōu)化伊群，以犧牲臨時(shí)用戶為代價(jià)。 Borg提供了一系列針對(duì)“高級(jí)用戶”的功能策精，因此他們可以微調(diào)程序的運(yùn)行方式（BCL規(guī)范列出了約230個(gè)參數(shù)）：最初的重點(diǎn)是支持Google的最大資源消費(fèi)者誰的效率提高是最重要的舰始。不幸的是，該API的豐富性使“休閑”用戶的工作變得更加困難咽袜，并限制了它的發(fā)展丸卷。我們的解決方案是構(gòu)建在Borg之上運(yùn)行的自動(dòng)化工具和服務(wù)，并根據(jù)實(shí)驗(yàn)確定適當(dāng)?shù)脑O(shè)置询刹。這些功能得益于容錯(cuò)應(yīng)用程序提供的自由試驗(yàn)：如果自動(dòng)化出錯(cuò)谜嫉，那就是麻煩，而不是災(zāi)難凹联。
8.2 經(jīng)驗(yàn)教訓(xùn)：有益
另一方面沐兰，博格（Borg）的許多設(shè)計(jì)功能非常有益，并且經(jīng)受了時(shí)間的考驗(yàn)蔽挠。
分配是有用的住闯。 Borg分配抽象產(chǎn)生了廣泛使用的logaver模式（第2.4節(jié)），而另一個(gè)流行的模式是簡(jiǎn)單的數(shù)據(jù)加載器任務(wù)定期更新Web服務(wù)器使用的數(shù)據(jù)象泵。 分配和程序包允許單獨(dú)的團(tuán)隊(duì)開發(fā)此類幫助服務(wù)寞秃。 Kubernetes相當(dāng)于alloc的是pod，pod是一個(gè)或多個(gè)容器的資源包絡(luò)偶惠，這些容器總是被調(diào)度到同一臺(tái)機(jī)器上并且可以共享資源春寿。 Kubernetes在同一個(gè)pod中使用輔助容器而不是在alloc中使用任務(wù)，但是想法是相同的忽孽。
集群管理不僅僅是任務(wù)管理绑改。盡管Borg的主要角色是管理任務(wù)和機(jī)器的生命周期谢床，但是在Borg上運(yùn)行的應(yīng)用程序還可以從許多其他群集服務(wù)中受益，包括命名和負(fù)載平衡厘线。 Kubernetes使用服務(wù)抽象支持命名和負(fù)載平衡：服務(wù)具有名稱和由標(biāo)簽選擇器定義的動(dòng)態(tài)Pod集识腿。群集中的任何容器都可以使用服務(wù)名稱連接到服務(wù)。在幕后造壮，Kubernetes會(huì)自動(dòng)在與標(biāo)簽選擇器匹配的Pod之間對(duì)與服務(wù)的連接進(jìn)行負(fù)載平衡渡讼，并跟蹤Pod在哪里運(yùn)行，因?yàn)樗鼈冇捎诠收隙S著時(shí)間重新安排耳璧。
內(nèi)省至關(guān)重要成箫。盡管博格幾乎總是“行之有效”，但是當(dāng)出現(xiàn)問題時(shí)旨枯，找到根本原因可能是具有挑戰(zhàn)性的蹬昌。在Borg中，一個(gè)重要的設(shè)計(jì)決定是向所有用戶公開調(diào)試信息攀隔，而不是將其隱藏：Borg有成千上萬的用戶皂贩，因此“自助”必須是調(diào)試的第一步钥勋。盡管這使我們更難棄用功能并更改用戶依賴的內(nèi)部政策常遂，但這仍然是一個(gè)勝利掰吕，而且我們已經(jīng)
找不到現(xiàn)實(shí)的選擇俊抵。為了處理大量數(shù)據(jù)，我們提供了多個(gè)級(jí)別的UI和調(diào)試工具助泽，因此用戶可以快速識(shí)別與其工作相關(guān)的異常事件楞慈，然后從其應(yīng)用程序和基礎(chǔ)結(jié)構(gòu)本身中深入查看詳細(xì)的事件和錯(cuò)誤日志。
Kubernetes旨在復(fù)制Borg的許多自省技術(shù)败潦。例如，它附帶了諸如cAdvisor [15]之類的工具准脂，用于資源監(jiān)視以及基于Elasticsearch / Kibana [30]和Fluentd [32]的日志聚合劫扒。可以查詢主對(duì)象以獲取其對(duì)象狀態(tài)的快照狸膏。 Kubernetes具有統(tǒng)一的機(jī)制沟饥，所有組件都可以使用該機(jī)制來記錄可供客戶端使用的事件（例如，計(jì)劃中的Pod湾戳，容器發(fā)生故障）贤旷。
主機(jī)是分布式系統(tǒng)的內(nèi)核。 Borgmaster最初是作為一個(gè)整體系統(tǒng)設(shè)計(jì)的砾脑，但是隨著時(shí)間的流逝幼驶，它逐漸成為位于服務(wù)生態(tài)系統(tǒng)核心的內(nèi)核，這些生態(tài)系統(tǒng)可以合作管理用戶的工作韧衣。例如盅藻，我們將調(diào)度程序和主UI（Sigma）分離為單獨(dú)的流程购桑，并添加了用于準(zhǔn)入控制，垂直和水平自動(dòng)縮放氏淑，重新打包任務(wù)勃蜘，定期作業(yè)提交（cron），工作流管理和歸檔的服務(wù)離線查詢的系統(tǒng)操作假残＄怨保總之，這些使我們能夠在不犧牲性能或可維護(hù)性的情況下擴(kuò)大工作量和功能集辉懒。
Kubernetes架構(gòu)更進(jìn)一步：它的核心是一個(gè)API服務(wù)器匀归，該API服務(wù)器僅負(fù)責(zé)處理請(qǐng)求和處理底層狀態(tài)對(duì)象。集群管理邏輯構(gòu)建為小型耗帕，可組合的微服務(wù)穆端，這些微服務(wù)是此API服務(wù)器的客戶端，例如復(fù)制控制器仿便，該控制器在出現(xiàn)故障時(shí)可維護(hù)所需數(shù)量的Pod副本体啰，以及節(jié)點(diǎn)控制器，它管理機(jī)器的生命周期嗽仪。
8.3 結(jié)論
在過去的十年中荒勇，幾乎所有Google的群集工作負(fù)載都已轉(zhuǎn)換為使用Borg。 我們將繼續(xù)發(fā)展它闻坚，并將從中汲取的經(jīng)驗(yàn)教訓(xùn)應(yīng)用到Kubernetes沽翔。
致謝
本文的作者進(jìn)行了評(píng)估并撰寫了這篇論文，但是數(shù)十名設(shè)計(jì)窿凤，實(shí)施和維護(hù)Borg組件和生態(tài)系統(tǒng)的工程師是其成功的關(guān)鍵仅偎。 我們?cè)诖藘H列出最直接參與Borgmaster和Borglets的設(shè)計(jì)，實(shí)現(xiàn)和操作的人員雳殊。 如果我們錯(cuò)過了任何人橘沥，我們深表歉意。
最初的Borgmaster由Jeremy Dion和Mark Vandevoorde以及Ben Smith夯秃，Ken Ashcraft座咆，Maricia Scott，Iu Ming-Yee和Monika Henzinger共同設(shè)計(jì)和實(shí)施仓洼。 最初的Borglet主要由Paul Menage設(shè)計(jì)和實(shí)施介陶。
隨后的貢獻(xiàn)者包括。色建。哺呜。。
博格SRE團(tuán)隊(duì)也發(fā)揮了至關(guān)重要的作用镀岛，并受到稱贊弦牡。 Borg配置語言（BCL）和borgcfg工具最初是由友驮。
我們感謝我們的審稿人和引路人Chris tos Kozyrakis對(duì)本文的反饋。
