【編者的話】本文是對(duì)Google在分布式底層架構(gòu)的經(jīng)典文章的翻譯，盡可能還原Google作者的原意和了解他們?cè)O(shè)計(jì)這個(gè)系統(tǒng)的初衷，希望大家多多指正我的翻譯，原文較長(zhǎng)，還在翻譯中，***會(huì)整理成一篇文章。

原作:

Abhishek Vermay, Luis Pedrosaz, Madhukar Korupolu,

David Oppenheimer, Eric Tune, John Wilkes

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored.For all other uses, contact the owner/author(s).

EuroSys’15, April 21–24, 2015, Bordeaux, France.

Copyright is held by the owner/author(s).

ACM 978-1-4503-3238-5/15/04.

http://dx.doi.org/10.1145/2741948.2741964

摘要

谷歌的Borg系統(tǒng)群集管理器運(yùn)行幾十萬(wàn)個(gè)以上的jobs，來(lái)自幾千個(gè)不同的應(yīng)用，跨多個(gè)集群，每個(gè)集群有上萬(wàn)個(gè)機(jī)器。

它通過(guò)管理控制、高效的任務(wù)包裝、超售、和進(jìn)程級(jí)別性能隔離實(shí)現(xiàn)了高利用率。它支持高可用性應(yīng)用程序與運(yùn)行時(shí)功能，***限度地減少故障恢復(fù)時(shí)間，減少相關(guān)故障概率的調(diào)度策略。Borg簡(jiǎn)化了用戶生活，通過(guò)提供一個(gè)聲明性的工作規(guī)范語(yǔ)言，名稱服務(wù)集成，實(shí)時(shí)作業(yè)監(jiān)控，和分析和模擬系統(tǒng)行為的工具。

我們將會(huì)展現(xiàn)Borg系統(tǒng)架構(gòu)和特點(diǎn)，重要的設(shè)計(jì)決策，定量分析它的一些策略，和十年以來(lái)的運(yùn)維經(jīng)驗(yàn)和學(xué)到的東西。

1. 簡(jiǎn)介

集群管理系統(tǒng)我們內(nèi)部叫Borg，它管理、調(diào)度、開始、重啟和監(jiān)控谷歌運(yùn)行的應(yīng)用程序的生命周期。本文介紹它是怎么做到這些的。

Borg提供了三個(gè)主要的好處：它(1)隱藏資源管理和故障處理細(xì)節(jié)，使其用戶可以專注于應(yīng)用開發(fā);(2)高可靠性和高可用性的操作，并支持應(yīng)用程序做到高可靠高可用;(3)讓我們?cè)诳鐢?shù)以萬(wàn)計(jì)的機(jī)器上有效運(yùn)行。Borg不是***個(gè)來(lái)解決這些問(wèn)題的系統(tǒng)，但它是在這個(gè)規(guī)模，這種程度的彈性和完整性下運(yùn)行的為數(shù)不多的幾個(gè)系統(tǒng)之一。

本文圍繞這些主題來(lái)編寫，包括了我們?cè)谏a(chǎn)環(huán)境運(yùn)行十年的一些功力。

2.用戶視角

Borg的用戶是谷歌開發(fā)人員和系統(tǒng)管理員(網(wǎng)站可靠性工程師 SRE)，他們運(yùn)行谷歌應(yīng)用與服務(wù)。用戶以job的方式提交他們的工作給Borg，job由一個(gè)或多個(gè)task組成，每個(gè)task含有同樣的二進(jìn)制程序。一個(gè)job在一個(gè)Borg的Cell里面跑，一個(gè)Cell是包括了多臺(tái)機(jī)器的單元。這一節(jié)主要講用戶視角下的Borg系統(tǒng)。

2.1 工作負(fù)載

Borg Cell主要運(yùn)行兩種異構(gòu)的工作負(fù)載。***種是長(zhǎng)期的服務(wù)，應(yīng)該“永遠(yuǎn)”運(yùn)行下去，并處理短時(shí)間的敏感請(qǐng)求(幾微秒到幾百毫秒)。這種服務(wù)是面向終端用戶的產(chǎn)品如Gmail、Google Docs、網(wǎng)頁(yè)搜索，內(nèi)部基礎(chǔ)設(shè)施服務(wù)(例如，Bigtable)。第二種是批處理任務(wù)，需要幾秒到幾天來(lái)完成，對(duì)短期性能波動(dòng)不敏感。在一個(gè)Cell上混合運(yùn)行了這兩種負(fù)載，取決于他們的主要租戶(比如說(shuō)，有些Cell就是專門用來(lái)跑密集的批處理任務(wù)的)。工作負(fù)載也隨著時(shí)間會(huì)產(chǎn)生變化：批處理任務(wù)做完就好，終端用戶服務(wù)的負(fù)載是以每天為周期的。Borg需要把這兩種情況都處理好。

Borg有一個(gè)2011年5月的負(fù)載數(shù)據(jù)[80]，已經(jīng)被廣泛的分析了[68,26，27，57，1]。

最近幾年，很多應(yīng)用框架是搭建在Borg上的，包括我們內(nèi)部的MapReduce[23]、flumejava[18]、 Millwheel[3]、Pregel[59]。這中間的大部分都是有一個(gè)控制器，可以提交job。前2個(gè)框架類似于YARN的應(yīng)用管理器[76]。我們的分布式存儲(chǔ)系統(tǒng)，例如GFS[34]和他的后繼者CFS、Bigtable[19]、Megastore[8]都是跑在Borg上的。

在這篇文章里面，我們把高優(yōu)先級(jí)的Borg的jobs定義為生產(chǎn)(prod)，剩下的是非生產(chǎn)的(non-prod)。大多長(zhǎng)期服務(wù)是prod 的，大部分批處理任務(wù)是non-prod的。在一個(gè)典型的Cell里面，prod job分配了70%的CPU資源然后實(shí)際用了60%;分配了55%的內(nèi)存資源然后實(shí)際用了85%。在$5.5會(huì)展示分配和實(shí)際值的差是很重要的。

2.2 集群和Cell

一個(gè)Cell里面的所有機(jī)器都屬于單個(gè)集群，集群是由高性能的數(shù)據(jù)中心級(jí)別的光纖網(wǎng)絡(luò)連接起來(lái)的。一個(gè)集群安裝在數(shù)據(jù)中心的一座樓里面，n座樓合在一起成為一個(gè)site。一個(gè)集群通常包括一個(gè)大的Cell還有一些小的或測(cè)試性質(zhì)的Cell。我們盡量避免任何單點(diǎn)故障。

在測(cè)試的Cell之外，我們中等大小的Cell大概包括10000臺(tái)機(jī)器;一些Cell還要大很多。一個(gè)Cell中的機(jī)器在很多方面都是異構(gòu)的：大小(CPU、RAM、disk、network)、處理器類型、性能以及外部IP地址或flash存儲(chǔ)。Borg隔離了這些差異，讓用戶單純的選擇用哪個(gè)Cell來(lái)跑任務(wù)，分配資源、安裝程序和其它依賴、監(jiān)控系統(tǒng)的健康并在故障時(shí)重啟。

(譯者注：Cell其實(shí)就是邏輯上的集群)

#p#

2.3 job和task

一個(gè)Borg的job的屬性有：名字、擁有者和有多少個(gè)task。job可以有一些約束，來(lái)指定這個(gè)job跑在什么架構(gòu)的處理器、操作系統(tǒng)版本、是否有外部IP。約束可以是硬的或者軟的。一個(gè)job可以指定在另一個(gè)job跑完后再開始。一個(gè)job只在一個(gè)Cell里面跑。

每個(gè)task包括了一組linux進(jìn)程，跑在一臺(tái)機(jī)器的一個(gè)容器內(nèi)[62]。大部分Borg的工作負(fù)載沒有跑在虛擬機(jī)(VM)里面，因?yàn)槲覀儾幌敫冻鎏摂M化的代價(jià)。而且，Borg在設(shè)計(jì)的時(shí)候還沒硬件虛擬化什么事兒哪。

task也有一些屬性，包括資源用量，在job中的排序。大多task的屬性和job的通用task屬性是一樣的，也可以被覆蓋 —— 例如，提供task專用的命令行參數(shù)，包括CPU核、內(nèi)存、磁盤空間、磁盤訪問(wèn)速度、TCP端口等等，這些都是可以分別設(shè)置并按照一個(gè)好的粒度提供。我們不提供固定的資源的單元。Borg程序都是靜態(tài)編譯的，這樣在跑的環(huán)境下就沒有依賴，這些程序都被打成一個(gè)包，包括二進(jìn)制和數(shù)據(jù)文件，能被Borg安裝起來(lái)。

用戶通過(guò)RPC來(lái)操作Borg的job，大多是從命令行工具，或者從我們的監(jiān)控系統(tǒng)($2.6)。大多job描述文件是用一種申明式配置文件 BCL -- GCL[12]的一個(gè)變種，會(huì)產(chǎn)生一個(gè)protobuf文件[67]。BCL有一些自己的關(guān)鍵字。GCL提供了lambda表達(dá)式來(lái)允許計(jì)算，這樣就能讓應(yīng)用在環(huán)境里面調(diào)整自己的配置。上萬(wàn)個(gè)BCL配置文件超過(guò)一千行長(zhǎng)，系統(tǒng)中累計(jì)跑了了千萬(wàn)行BCL。Borg的job配置很類似于Aurora配置文件 [6]。

圖2展現(xiàn)了job的和task的狀態(tài)機(jī)和生命周期。

用戶可以在運(yùn)行時(shí)改變一個(gè)job中的task的屬性，通過(guò)推送一個(gè)新的job配置給Borg。這個(gè)新的配置命令Borg更新task的規(guī)格。這就像是跑一個(gè)輕量級(jí)的，非原子性的事務(wù)，而且可以在提交后輕易再改回來(lái)。更新是滾動(dòng)式的，在更新中可以限制task重啟的數(shù)量，如果有太多task停掉，操作可以終止。

一些task更新，例如更新二進(jìn)制程序，需要task重啟;另外一些例如修改資源需求和限制會(huì)導(dǎo)致這個(gè)機(jī)器不適合跑現(xiàn)有的task，需要停止task再重新調(diào)度到別的機(jī)器上;還有一些例如修改優(yōu)先級(jí)是可以不用重啟或者移動(dòng)task的。

task需要能夠接受Unix的SIGTERM信號(hào)，在他們被強(qiáng)制發(fā)送SIGKILL之前，這樣就有時(shí)間去做清理、保存狀態(tài)、結(jié)束現(xiàn)有請(qǐng)求執(zhí)行、拒絕新請(qǐng)求。實(shí)際的notice的delay bound。實(shí)踐中，80%的task能正常處理終止信號(hào)。

2.4 Allocs

Borg的alloc(allocation的縮寫)是在單臺(tái)機(jī)器上的一組保留的資源配額，用來(lái)讓一個(gè)或更多的task跑;這些資源一直分配在那邊，無(wú)論有沒有被用。allocs可以被分配出來(lái)給未來(lái)的task，用來(lái)保持資源在停止一個(gè) task和重啟這個(gè)task之間，用來(lái)聚集不同jobs的tasks到同一臺(tái)機(jī)器上——例如一個(gè)web server實(shí)例和附加的，用于把serverURL日志發(fā)送到一個(gè)分布式文件系統(tǒng)的日志搜集實(shí)例。一個(gè)alloc的資源管理方式和一臺(tái)機(jī)器上的資源管理方式是類似的;多個(gè)tasks在一個(gè)alloc上跑并共享資源。如果一個(gè)alloc必須被重新定位到其他的機(jī)器上，那么它的task也要跟著重新調(diào)度。

一個(gè)alloc set就像一個(gè)job：它是一組allocs保留了多臺(tái)機(jī)器上的資源。一旦alloc set被創(chuàng)建，一個(gè)或多個(gè)jobs就可以被提交進(jìn)去跑。簡(jiǎn)而言之，我們會(huì)用task來(lái)表示一個(gè)alloc或者一個(gè)top-level task(一個(gè)alloc之外的)，用job來(lái)表示一個(gè)job或者alloc set。

2.5 優(yōu)先級(jí)、配額和管理控制

當(dāng)有超量的工作負(fù)載在運(yùn)行的時(shí)候會(huì)發(fā)生什么事情?我們的解決方案是優(yōu)先級(jí)和配額。

所有job都有優(yōu)先級(jí)，一個(gè)小的正整數(shù)。高優(yōu)先級(jí)的task可以優(yōu)先獲取資源，即使后面被殺掉。Borg定義了不重疊的優(yōu)先級(jí)段給不同任務(wù)用，包括(優(yōu)先級(jí)降序)：監(jiān)控、生產(chǎn)、批任務(wù)、高性能(測(cè)試或免費(fèi))。在這篇文章里面，prod的jobs是在監(jiān)控和生產(chǎn)段。

雖然一個(gè)降級(jí)的task總會(huì)在cell的其他地方找到一席之地。降級(jí)瀑布也有可能會(huì)發(fā)生，就是一個(gè)task降下來(lái)之后，把下面運(yùn)行的task再擠到別的機(jī)器上，如此往復(fù)。為了避免這種情況，我們禁止了prod級(jí)task互相排擠。合理粒度的優(yōu)先級(jí)在其他場(chǎng)景下也很有用——MapReduce的 master跑的優(yōu)先級(jí)比worker高一點(diǎn)，來(lái)保證他們的可用性。

優(yōu)先級(jí)是jobs的相對(duì)重要性，決定了jobs在一個(gè)cell里面是跑還是等(pending)。配額則是用來(lái)決定jobs是否運(yùn)行被調(diào)度。配額就是一組資源(CPU，RAM，disk)的數(shù)量在一個(gè)指定的優(yōu)先級(jí)、一個(gè)指定的時(shí)間段(月這個(gè)量級(jí))。數(shù)量決定了這個(gè)用戶的job可以用的最多資源(例子：20TB內(nèi)存和prod優(yōu)先級(jí)從現(xiàn)在到7月在xx cell內(nèi))。配額檢查是管理控制的一部分，不是調(diào)度層的：配額不足的任務(wù)在提交的時(shí)候就會(huì)被拒絕。

高優(yōu)先級(jí)的配額總是花費(fèi)的比低優(yōu)先級(jí)要多。prod級(jí)的配額是被限制為一個(gè)cell里面實(shí)際的資源量，所以用戶提交了prod級(jí)的job的配額時(shí)，可以期待這個(gè)job一定會(huì)跑，去掉一些碎片外。即使這樣，我們鼓勵(lì)用戶多買一點(diǎn)比自己需要多一點(diǎn)的配額，很多用戶超買是因?yàn)樗麄兊膽?yīng)用程序的用戶數(shù)量增長(zhǎng)后需要的配額就大了。對(duì)于超買，我們的應(yīng)對(duì)方案是低優(yōu)先級(jí)資源的超售：所有用戶在0優(yōu)先級(jí)都可以用***的配額，雖然在實(shí)際運(yùn)行中這種情況很難跑起來(lái)。一個(gè)低優(yōu)先級(jí)的job在資源不足時(shí)會(huì)保持等(pending)狀態(tài)。

配額分配在Borg系統(tǒng)之外，和我們的物理資源計(jì)劃有關(guān)。這些資源計(jì)劃在不同的數(shù)據(jù)中心產(chǎn)生不同的價(jià)格和配額。用戶jobs只在有足夠配額和足夠優(yōu)先級(jí)之后才能啟動(dòng)。配額的使用讓Dominant Resource Fairness(DRF)[29, 35, 36, 66]不是那么必要了。

Borg有一個(gè)容量系統(tǒng)給一些特殊權(quán)限給某些用戶，例如，允許管理員刪除或修改cell里面的job，或者允許用戶區(qū)訪問(wèn)特定的內(nèi)核特性或者讓Borg對(duì)自己的job不做資源估算($5.5)。

2.6 命名和監(jiān)控

光是創(chuàng)建和部署task是不夠的：一個(gè)服務(wù)的客戶端和其他系統(tǒng)需要能找到它們，即使它換了個(gè)地方。為了搞定這一點(diǎn)，Borg創(chuàng)造了一個(gè)穩(wěn)定的“Borg name Service”(BNS)名字給每個(gè)task，這個(gè)名字包括了cell名字，job名字，和task編號(hào)。Borg把task的主機(jī)名和端口寫入到一個(gè)持久化高可用文件里，以BNS名為文件名，放在Chubby[14]上。這個(gè)文件被我們的RPC系統(tǒng)使用，用來(lái)發(fā)現(xiàn)task的終端地址。BNS名稱也是 task的DNS名的基礎(chǔ)構(gòu)成部分，所以，cc cell的ubar用戶的jfoo job的第50個(gè)task的DNS名稱會(huì)是50.jfoo.ubar.cc.borg.google.com。Borg同時(shí)還會(huì)把job的大小和task 的健康信息寫入到Chubby在任何情況改變時(shí)，這樣負(fù)載均衡就能知道怎么去路由請(qǐng)求了。

幾乎所有的Borg的task都會(huì)包含一個(gè)內(nèi)置的HTTP服務(wù)，用來(lái)發(fā)布健康信息和幾千個(gè)性能指標(biāo)(例如RPC延時(shí))。Borg監(jiān)控這些健康檢查 URL，把其中響應(yīng)超時(shí)的和error的task重啟。其他數(shù)據(jù)也被監(jiān)控工具追蹤并在Dashboard上展示，當(dāng)服務(wù)級(jí)別對(duì)象(SLO)出問(wèn)題時(shí)就會(huì)報(bào)警。

用戶可以使用一個(gè)名叫Sigma的web UI，用來(lái)檢查他們所有的job狀態(tài)，一個(gè)特殊的cell，或者深入到某個(gè)job的某個(gè)task的資源用率，詳細(xì)日志，操作歷史，和最終命運(yùn)。我們的應(yīng)用產(chǎn)生大量的日志，都會(huì)被自動(dòng)的滾動(dòng)來(lái)避免塞滿硬盤，會(huì)在一個(gè)task結(jié)束后保留一小段時(shí)間用來(lái)debug。如果一個(gè)job沒有被跑起來(lái)，Borg會(huì)提供一個(gè)為什么掛起的解釋，指導(dǎo)用戶怎么修改這個(gè)job的資源需求來(lái)符合目前這個(gè)cell的情況。我們發(fā)布資源的使用方針，按照這個(gè)方針來(lái)做就容易被調(diào)度起來(lái)。

Borg記錄所有的job提交和task時(shí)間，以及每task的資源使用細(xì)節(jié)在基礎(chǔ)存儲(chǔ)服務(wù)里面。這個(gè)存儲(chǔ)服務(wù)有一個(gè)分布式的只讀的SQL- like的交互式接口，通過(guò)Dremel[61]提供出來(lái)。這些數(shù)據(jù)在實(shí)時(shí)使用、debug、系統(tǒng)查錯(cuò)和長(zhǎng)期容量規(guī)劃上都很有用。這些數(shù)據(jù)也是 Google集群負(fù)載追蹤的數(shù)據(jù)來(lái)源之一[80]。

所有這些特性幫助用戶理解和debug Borg的行為和管理他們的job，并且?guī)椭覀兊腟RE每個(gè)人管理超過(guò)上萬(wàn)臺(tái)機(jī)器。

原文鏈接：http://dockone.io/article/726