【經典論文】Google Borg大規模集群管理(一、二章)
【編者的話】本文是對Google在分布式底層架構的經典文章的翻譯，盡可能還原Google作者的原意和了解他們設計這個系統的初衷，希望大家多多指正我的翻譯，原文較長，還在翻譯中，***會整理成一篇文章。
原作:
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系統群集管理器運行幾十萬個以上的jobs，來自幾千個不同的應用，跨多個集群，每個集群有上萬個機器。
它通過管理控制、高效的任務包裝、超售、和進程級別性能隔離實現了高利用率。它支持高可用性應用程序與運行時功能，***限度地減少故障恢復時間，減少相關故障概率的調度策略。Borg簡化了用戶生活，通過提供一個聲明性的工作規范語言，名稱服務集成，實時作業監控，和分析和模擬系統行為的工具。
我們將會展現Borg系統架構和特點，重要的設計決策，定量分析它的一些策略，和十年以來的運維經驗和學到的東西。
1. 簡介
集群管理系統我們內部叫Borg，它管理、調度、開始、重啟和監控谷歌運行的應用程序的生命周期。本文介紹它是怎么做到這些的。
Borg提供了三個主要的好處：它(1)隱藏資源管理和故障處理細節，使其用戶可以專注于應用開發;(2)高可靠性和高可用性的操作，并支持應用程序做到高可靠高可用;(3)讓我們在跨數以萬計的機器上有效運行。Borg不是***個來解決這些問題的系統，但它是在這個規模，這種程度的彈性和完整性下運行的為數不多的幾個系統之一。
本文圍繞這些主題來編寫，包括了我們在生產環境運行十年的一些功力。
2.用戶視角
Borg的用戶是谷歌開發人員和系統管理員(網站可靠性工程師 SRE)，他們運行谷歌應用與服務。用戶以job的方式提交他們的工作給Borg，job由一個或多個task組成，每個task含有同樣的二進制程序。一個job在一個Borg的Cell里面跑，一個Cell是包括了多臺機器的單元。這一節主要講用戶視角下的Borg系統。
2.1 工作負載
Borg Cell主要運行兩種異構的工作負載。***種是長期的服務，應該“永遠”運行下去，并處理短時間的敏感請求(幾微秒到幾百毫秒)。這種服務是面向終端用戶的產品如Gmail、Google Docs、網頁搜索，內部基礎設施服務(例如，Bigtable)。第二種是批處理任務，需要幾秒到幾天來完成，對短期性能波動不敏感。在一個Cell上混合運行了這兩種負載，取決于他們的主要租戶(比如說，有些Cell就是專門用來跑密集的批處理任務的)。工作負載也隨著時間會產生變化：批處理任務做完就好，終端用戶服務的負載是以每天為周期的。Borg需要把這兩種情況都處理好。
Borg有一個2011年5月的負載數據[80]，已經被廣泛的分析了[68,26，27，57，1]。
最近幾年，很多應用框架是搭建在Borg上的，包括我們內部的MapReduce[23]、flumejava[18]、 Millwheel[3]、Pregel[59]。這中間的大部分都是有一個控制器，可以提交job。前2個框架類似于YARN的應用管理器[76]。我們的分布式存儲系統，例如GFS[34]和他的后繼者CFS、Bigtable[19]、Megastore[8]都是跑在Borg上的。
在這篇文章里面，我們把高優先級的Borg的jobs定義為生產(prod)，剩下的是非生產的(non-prod)。大多長期服務是prod 的，大部分批處理任務是non-prod的。在一個典型的Cell里面，prod job分配了70%的CPU資源然后實際用了60%;分配了55%的內存資源然后實際用了85%。在$5.5會展示分配和實際值的差是很重要的。
2.2 集群和Cell
一個Cell里面的所有機器都屬于單個集群，集群是由高性能的數據中心級別的光纖網絡連接起來的。一個集群安裝在數據中心的一座樓里面，n座樓合在一起成為一個site。一個集群通常包括一個大的Cell還有一些小的或測試性質的Cell。我們盡量避免任何單點故障。
在測試的Cell之外，我們中等大小的Cell大概包括10000臺機器;一些Cell還要大很多。一個Cell中的機器在很多方面都是異構的：大小(CPU、RAM、disk、network)、處理器類型、性能以及外部IP地址或flash存儲。Borg隔離了這些差異，讓用戶單純的選擇用哪個Cell來跑任務，分配資源、安裝程序和其它依賴、監控系統的健康并在故障時重啟。
(譯者注：Cell其實就是邏輯上的集群)
#p#
2.3 job和task
一個Borg的job的屬性有：名字、擁有者和有多少個task。job可以有一些約束，來指定這個job跑在什么架構的處理器、操作系統版本、是否有外部IP。約束可以是硬的或者軟的。一個job可以指定在另一個job跑完后再開始。一個job只在一個Cell里面跑。
每個task包括了一組linux進程，跑在一臺機器的一個容器內[62]。大部分Borg的工作負載沒有跑在虛擬機(VM)里面，因為我們不想付出虛擬化的代價。而且，Borg在設計的時候還沒硬件虛擬化什么事兒哪。
task也有一些屬性，包括資源用量，在job中的排序。大多task的屬性和job的通用task屬性是一樣的，也可以被覆蓋 —— 例如，提供task專用的命令行參數，包括CPU核、內存、磁盤空間、磁盤訪問速度、TCP端口等等，這些都是可以分別設置并按照一個好的粒度提供。我們不提供固定的資源的單元。Borg程序都是靜態編譯的，這樣在跑的環境下就沒有依賴，這些程序都被打成一個包，包括二進制和數據文件，能被Borg安裝起來。
用戶通過RPC來操作Borg的job，大多是從命令行工具，或者從我們的監控系統($2.6)。大多job描述文件是用一種申明式配置文件 BCL -- GCL[12]的一個變種，會產生一個protobuf文件[67]。BCL有一些自己的關鍵字。GCL提供了lambda表達式來允許計算，這樣就能讓應用在環境里面調整自己的配置。上萬個BCL配置文件超過一千行長，系統中累計跑了了千萬行BCL。Borg的job配置很類似于Aurora配置文件 [6]。
圖2展現了job的和task的狀態機和生命周期。
用戶可以在運行時改變一個job中的task的屬性，通過推送一個新的job配置給Borg。這個新的配置命令Borg更新task的規格。這就像是跑一個輕量級的，非原子性的事務，而且可以在提交后輕易再改回來。更新是滾動式的，在更新中可以限制task重啟的數量，如果有太多task停掉，操作可以終止。
一些task更新，例如更新二進制程序，需要task重啟;另外一些例如修改資源需求和限制會導致這個機器不適合跑現有的task，需要停止task再重新調度到別的機器上;還有一些例如修改優先級是可以不用重啟或者移動task的。
task需要能夠接受Unix的SIGTERM信號，在他們被強制發送SIGKILL之前，這樣就有時間去做清理、保存狀態、結束現有請求執行、拒絕新請求。實際的notice的delay bound。實踐中，80%的task能正常處理終止信號。
2.4 Allocs
Borg的alloc(allocation的縮寫)是在單臺機器上的一組保留的資源配額，用來讓一個或更多的task跑;這些資源一直分配在那邊，無論有沒有被用。allocs可以被分配出來給未來的task，用來保持資源在停止一個 task和重啟這個task之間，用來聚集不同jobs的tasks到同一臺機器上——例如一個web server實例和附加的，用于把serverURL日志發送到一個分布式文件系統的日志搜集實例。一個alloc的資源管理方式和一臺機器上的資源管理方式是類似的;多個tasks在一個alloc上跑并共享資源。如果一個alloc必須被重新定位到其他的機器上，那么它的task也要跟著重新調度。
一個alloc set就像一個job：它是一組allocs保留了多臺機器上的資源。一旦alloc set被創建，一個或多個jobs就可以被提交進去跑。簡而言之，我們會用task來表示一個alloc或者一個top-level task(一個alloc之外的)，用job來表示一個job或者alloc set。
2.5 優先級、配額和管理控制
當有超量的工作負載在運行的時候會發生什么事情?我們的解決方案是優先級和配額。
所有job都有優先級，一個小的正整數。高優先級的task可以優先獲取資源，即使后面被殺掉。Borg定義了不重疊的優先級段給不同任務用，包括(優先級降序)：監控、生產、批任務、高性能(測試或免費)。在這篇文章里面，prod的jobs是在監控和生產段。
雖然一個降級的task總會在cell的其他地方找到一席之地。降級瀑布也有可能會發生，就是一個task降下來之后，把下面運行的task再擠到別的機器上，如此往復。為了避免這種情況，我們禁止了prod級task互相排擠。合理粒度的優先級在其他場景下也很有用——MapReduce的 master跑的優先級比worker高一點，來保證他們的可用性。
優先級是jobs的相對重要性，決定了jobs在一個cell里面是跑還是等(pending)。配額則是用來決定jobs是否運行被調度。配額就是一組資源(CPU，RAM，disk)的數量在一個指定的優先級、一個指定的時間段(月這個量級)。數量決定了這個用戶的job可以用的最多資源(例子：20TB內存和prod優先級從現在到7月在xx cell內)。配額檢查是管理控制的一部分，不是調度層的：配額不足的任務在提交的時候就會被拒絕。
高優先級的配額總是花費的比低優先級要多。prod級的配額是被限制為一個cell里面實際的資源量，所以用戶提交了prod級的job的配額時，可以期待這個job一定會跑，去掉一些碎片外。即使這樣，我們鼓勵用戶多買一點比自己需要多一點的配額，很多用戶超買是因為他們的應用程序的用戶數量增長后需要的配額就大了。對于超買，我們的應對方案是低優先級資源的超售：所有用戶在0優先級都可以用***的配額，雖然在實際運行中這種情況很難跑起來。一個低優先級的job在資源不足時會保持等(pending)狀態。
配額分配在Borg系統之外，和我們的物理資源計劃有關。這些資源計劃在不同的數據中心產生不同的價格和配額。用戶jobs只在有足夠配額和足夠優先級之后才能啟動。配額的使用讓Dominant Resource Fairness(DRF)[29, 35, 36, 66]不是那么必要了。
Borg有一個容量系統給一些特殊權限給某些用戶，例如，允許管理員刪除或修改cell里面的job，或者允許用戶區訪問特定的內核特性或者讓Borg對自己的job不做資源估算($5.5)。
2.6 命名和監控
光是創建和部署task是不夠的：一個服務的客戶端和其他系統需要能找到它們，即使它換了個地方。為了搞定這一點，Borg創造了一個穩定的“Borg name Service”(BNS)名字給每個task，這個名字包括了cell名字，job名字，和task編號。Borg把task的主機名和端口寫入到一個持久化高可用文件里，以BNS名為文件名，放在Chubby[14]上。這個文件被我們的RPC系統使用，用來發現task的終端地址。BNS名稱也是 task的DNS名的基礎構成部分，所以，cc cell的ubar用戶的jfoo job的第50個task的DNS名稱會是50.jfoo.ubar.cc.borg.google.com。Borg同時還會把job的大小和task 的健康信息寫入到Chubby在任何情況改變時，這樣負載均衡就能知道怎么去路由請求了。
幾乎所有的Borg的task都會包含一個內置的HTTP服務，用來發布健康信息和幾千個性能指標(例如RPC延時)。Borg監控這些健康檢查 URL，把其中響應超時的和error的task重啟。其他數據也被監控工具追蹤并在Dashboard上展示，當服務級別對象(SLO)出問題時就會報警。
用戶可以使用一個名叫Sigma的web UI，用來檢查他們所有的job狀態，一個特殊的cell，或者深入到某個job的某個task的資源用率，詳細日志，操作歷史，和最終命運。我們的應用產生大量的日志，都會被自動的滾動來避免塞滿硬盤，會在一個task結束后保留一小段時間用來debug。如果一個job沒有被跑起來，Borg會提供一個為什么掛起的解釋，指導用戶怎么修改這個job的資源需求來符合目前這個cell的情況。我們發布資源的使用方針，按照這個方針來做就容易被調度起來。
Borg記錄所有的job提交和task時間，以及每task的資源使用細節在基礎存儲服務里面。這個存儲服務有一個分布式的只讀的SQL- like的交互式接口，通過Dremel[61]提供出來。這些數據在實時使用、debug、系統查錯和長期容量規劃上都很有用。這些數據也是 Google集群負載追蹤的數據來源之一[80]。
所有這些特性幫助用戶理解和debug Borg的行為和管理他們的job，并且幫助我們的SRE每個人管理超過上萬臺機器。
