Kubernetes的前世Borg系統(一)

Kubernetes前世Borg②

Google的Borg系統是一個運行着成千上萬項做業的集羣管理器，它同時管理着不少個應用集羣，每一個集羣都有成千上萬臺機器，這些集羣之上運行着Google的不少不一樣的應用。Borg經過准入控制，高效的任務打包，超額的資源分配和進程級隔離的機器共享，來實現超高的資源利用率。它經過最小化故障恢復時間的運行時特性和減小相關運行時故障的調度策略來支持高可用的應用程序Borg經過提供一個做業聲明的標準語言，命名服務的集成機制，實時的做業監控，以及一套分析和模擬系統行爲的工具來簡化用戶的使用。

上文回顧：Kubernetes的前世此生 ，瞭解了Kubernetes的誕生，今天來講說Kubernetes的前世Borg；

咱們將經過此文對Borg系統的架構和主要特性進行總結，包括重要的設計決定，一些調度管理策略的定量分析，以及對十年的使用經驗中汲取的教訓的定性分析。

1 簡介

圖1 Borg的高級架構。

僅顯示了成千上萬工做節點中的一小部分。這個在咱們內部稱爲Borg的集羣管理系統，它負責權限控制、調度、啓動、從新啓動和監視所有的Google中運行的應用程序。本文將解釋它是如何作到的。

總的來講，Brog主要提供了三個主要的好處：

（1）隱藏資源管理和故障處理的細節，所以其用戶能夠專一於應用程序開發; 

（2）提供高可靠性和高可用性操做，支持的應用也是如此; 

（3）使咱們可以有效地在數萬臺機器上運行工做負載。

Borg不是解決這些問題的第一個系統，但它是在可以保證最大彈性和完整性狀況下，以大規模運行的少數幾個系統之一。本文將主要圍繞這些主題進行組織，並從Borg投入生產，這十多年來的使用經驗做爲總結。

2.用戶視圖

Borg的用戶是運行Google應用和服務的Google開發人員和系統管理員（網站可靠性工程師或SRE）。用戶以做業的形式將他們的工做提交給Borg，每一個做業包括一個或多個任務，它們都運行相同的程序（二進制）。每一個做業在一個Borg單元中運行，一組機器組織爲一個單元。本節的剩餘部分描述了Borg用戶視圖中展示的主要功能。

2.1 工做負載

Borg的全部單元都同時運行着兩種類型的異質工做負載。第一個是「永遠運行下去」的長服務，他們對延遲和性能波動敏感，此類服務用於面向終端用戶的產品，例如Gmail，Google文檔，web搜索和內部基礎設施服務（例如，BigTable）。第二個是批處理做業，須要花費從幾秒到幾天完成，這些任務對短時間性能波動的敏感性要小得多。這些工做負載混合運行在Borg的各個運行單元中，其根據其主要租戶（例如，一些單元是專門用來運行批量密集任務的）運行不一樣的混合應用，而且也隨時間變化：批處理做業完成和從新運行，許多面向終端用戶的服務做業看到平常使用模式。 Borg一樣須要處理好全部這些狀況。

Borg的表明性工做負載狀況能夠從2011年5月的一個公開的月份跟蹤中找到[80]，已經進行了普遍分析（例如[68]和[1,26,27,57]）。

在過去幾年中，許多應用程序框架已經創建在Borg之上，包括咱們內部的MapReduce系統[23]，FlumeJava [18]，Millwheel [3]和Pregel [59]。大多數都有一個控制器提交一個主做業和一個或多個工做做業; 前二者對YARN的應用程序管理器[76]起相似的做用。咱們的分佈式存儲系統如GFS [34]及其後繼CFS，Bigtable [19]和Megastore [8]都運行在Borg上。

對於本文，咱們將優先級較高的Borg做業分爲「生產」（prod）做業，其他做爲「非生產」（non-prod）做業。大多數長期運行的服務器做業是prod;大多數批處理做業是非prod的。在表明性單元中，分配給prod做業大約總CPU資源的70％，大約佔總CPU使用量的60％; 分配給它們約總內存的55％，約佔總內存使用的85％。在§5.5節，將看到分配和使用之間的差別將是很重要的。

2.2 集羣和單元

單元中的機器屬於單個集羣，由鏈接它們的高性能數據中心規模的網絡架構定義。

一個集羣位於單個數據中心大樓內，大廈集合構成一個站點。一個集羣一般承載一個大型單元，可能有一些較小規模的測試或特殊用途單元。咱們努力避免任何單點故障。

中央單元大小是排除測試單元后約10k機器; 有些會更大。一個單元中的機器在許多維度上是異構的：大小（CPU，RAM，磁盤，網絡），處理器類型，性能和功能（好比外部IP地址或閃存存儲器）。Borg經過肯定單元中的運行任務，爲任務分配資源，安裝程序和其餘的依賴，監控任務狀態並在失敗時重啓，將用戶從大多數差別中隔離出來。

2.3 做業和任務

Borg做業的屬性包括名稱，全部者及其擁有的任務數量。做業可能具備限制，使其任務在具備特定屬性（例如處理器體系結構，操做系統版本或外部IP地址）的計算機上運行。限制能夠是硬的或軟的; 軟限制就像是偏好而不是要求。做業的開始能被推遲到直到前一個做業完成。一個做業僅在一個單元中運行。

每一個任務映射到在機器上的容器中運行的一組Linux進程[62]。大多數Borg工做負載不在虛擬機（VM）內運行，由於咱們不想支付虛擬化的成本。此外，該系統是在咱們對沒有硬件的虛擬化支持的處理器進行大量投資的時候設計的。

任務也具備屬性，例如資源需求和任務在做業中的索引。大多數任務屬性對做業中的全部任務是相同的，可是能夠被重寫 - 例如，以提供指定任務的命令行標誌。每一個資源維度（CPU核，RAM，磁盤空間，磁盤訪問速率，TCP端口，等）以細粒度獨立指定; 咱們不強加固定大小的桶或槽（§5.4）。靜態連接Borg程序以減小對其運行時環境的依賴，而且Brog程序被打包爲二進制文件和數據文件，由Borg負責安裝。

用戶經過向Borg發出遠程過程調用（RPC）來操做做業，最多見的是經過命令行工具，其餘Borg做業或監視系統（§2.6）。大多數做業描述都是用聲明性配置語言BCL編寫的。BCL是GCL的一個變體[12]，它生成protobuf文件[67]，並擴展了一些Borg特定的關鍵字。GCL提供lambda函數以容許計算，應用程序可使用它們來調整環境配置; 成千上萬的BCL文件超過1k行長，咱們已經積累了數千萬行的BCL。Borg做業配置與Aurora配置文件類似[6]。

圖2說明了做業和任務在其生命週期中經歷的狀態。

圖2：做業和任務的狀態圖。用戶能夠觸發提交，終止和更新轉換。用戶能夠經過推送新的做業配置到Borg，再指示Borg將任務更新到新配置，來更改正在運行的做業中的某些任務或全部任務的屬性。這是一個輕量級的非原子事務，能夠很容易地被撤銷，直到它被關閉（提交）。更新一般以滾動方式完成，而且能夠對更新致使的任務中斷（從新計劃或搶佔）的數量加以限制; 跳過會致使更多中斷的任何更改。

某些任務更新（例如，推送新的二進制）老是須要重啓任務; 某些更新（例如，增長的資源需求增長或約束改變）可能使得任務再也不適合於這臺機器，將致使任務中止並從新調度; 而某些更新（例如，改變優先級）卻可在不從新啓動或移動任務的狀況下進行。

任務能夠要求在被SIGKILL搶佔以前經過Unix SIGTERM信號獲取通知，這樣任務就有時間進行清理，保存狀態，完成當前正在執行的請求並拒絕新的請求。若是搶佔者設置延遲界限，則實際通知可能更少。在實踐中，通知傳遞約80％的時間。

2.4 分配

Borg alloc（分配的簡稱）是能夠運行一個或多個任務的機器上的一組保留資源;不管資源是否被使用仍然被分配。Alloc能夠用於爲未來的任務設置資源，在中止和重啓任務之間保留資源，以及將不一樣做業中的任務收集到同一臺機器上 - 例如，Web服務實例和相關的日誌保存任務，這個任務將服務的URL日誌從本地磁盤複製到分佈式文件系統。 alloc的資源以相似於機器資源的方式處理; 多個任務運行在一個alloc中，共享其資源。若是一個alloc必須重定位到另外一臺機器，它的任務將被從新調度。

一個alloc集合就像一個做業：它是一組在多個機器上預留資源的alloc。一旦建立了一個alloc集，能夠提交一個或多個做業在其中運行。簡單期間，咱們通常會使用「task」來引用alloc或頂層任務（在alloc以外的）和「job」來引用一個做業或alloc集。

2.5 優先級，配額和接納控制

當更多的工做出現而超過可容納的限度時會發生什麼？咱們的解決方案是優先級和配額。

每一個做業都有一個優先級，它是一個小的正整數。高優先級任務能夠以犧牲低優先級任務爲代價而得到資源，即便這致使搶佔（殺死）後者。Borg將不一樣種類的做業分爲不一樣的領域，並給每一個領域定義了不重疊的優先權重，這些做業組包括：監視做業，生產做業，批處理做業和盡力而爲的做業（已知的包括測試程序），他們的優先級依次遞減。對於本文，prod做業是監測和生產領域的工做。

雖然被搶佔的任務一般將被從新安排在單元中的其餘地方，搶佔級聯可能發生，若是高優先級的任務碰到一個略低優先級的任務，而這個略低優先級任務又引起另外一個略低優先級的任務，等等。爲了消除大部分這種狀況，咱們不容許生產領域中的任務相互搶佔。細粒度優先級在其餘狀況下仍然有用 - 例如，MapReduce主任務以比他們控制的workers更高的優先級運行，來提升其可靠性。

優先級表示單元中正在運行或正等待運行的做業的相對重要性。配額用於決定容許進行調度的做業。配額表示爲在給定優先級上的一段時間（一般爲幾個月）內的資源量（CPU，RAM，磁盤等）的向量。數量指定用戶的做業請求能夠一次請求的資源的最大量（例如，「從如今直到7月底在單元xx中的prod優先級的20TiBRAM「）。配額檢查是許可控制的一部分，而不是調度：配額不足的做業當即拒絕提交。

較高優先級配額的成本高於較低優先級配額。生產優先級配額僅限於單元中可用的實際資源，所以，提交符合配額的生產優先級做業的用戶能夠預期運行。即便咱們鼓勵用戶購買的配額不超過他們的需求，可是許多用戶仍然過分購買，由於這幫助他們在應用程序的用戶羣增加時克服不足。咱們經過在較低優先級別上過分銷售配額來響應這一點：每一個用戶具備在優先級零的無限配額，儘管這經常難以執行，由於資源被過分訂閱。一個低優先級做業可能被容許了，可是因爲資源不足而保持等待（未調度）。

在Borg之外進行配額分配，而且與咱們的物理容量規劃密切相關，其結果反映在不一樣數據中心的配額的價格和可用性上。僅當用戶做業具備所需優先級的足夠配額時，才容許用戶做業。配額的使用減小了對優點資源公平（DRF）[29,35,36,66]等策略的須要。

Borg有一個能力系統，能給予一些用戶特殊的權限; 例如，容許管理員刪除或修改單元中的任何做業，或容許用戶訪問受限內核功能或Borg行爲（例如禁用其做業的資源估計（§5.5））。

2.6 命名和監控

僅建立和放置任務是不夠的：服務的客戶端和其餘系統須要可以找到它們，即便它們被重定位到新機器上了。要啓用此功能，Borg將爲每一個任務建立一個穩定的「Borg name service」（BNS）名稱，其中包含單元名稱，做業名稱和任務編號。Borg將任務的主機名和端口寫入一個以BNS命名的一致的高可用的Chubby [14]文件中，由咱們的RPC系統使用該文件來查找任務端點。BNS名稱還造成任務的DNS名稱的基礎，因此在cc單元中的用戶ubar擁有的做業 jfoo中的第五十個任務將經過50.jfoo.ubar.cc.borg.google.com訪問到。Borg還會在Chubby發生變化時將做業大小和任務健康信息寫入Chubby，所以負載平衡器能夠查看將請求路由到哪裏。

幾乎在Borg下運行的每一個任務都包含一個內置的HTTP服務器，它發佈有關任務運行情況的信息和成千上萬個性能指標（例如RPC延遲）。 Borg監控health-check URL，並從新啓動不會及時響應或返回HTTP錯誤代碼的任務。其餘數據由儀表盤監視工具和違反服務級別目標（SLO）的警報進行跟蹤。

稱爲Sigma的服務提供了基於Web的用戶界面（UI），經過該UI用戶能夠檢查全部做業，特定單元的狀態，或向下鑽取到單個做業和任務，以檢查其資源行爲，詳細日誌，執行歷史，和最終的結果。咱們的應用產生大量日誌; 這些被自動輪轉以免用完磁盤空間，並在任務退出後保存一段時間以協助調試。若是做業未運行，Borg提供了「爲何待處理？」註釋，以及如何修改做業的資源請求以更好地適應單元的指導。咱們發佈了「切合」更可能容易調度的資源形式的規則。

Borg記錄全部做業提交事件和任務事件，以及每一個任務在Infrastore中詳細的資源使用信息，這是一個可擴展的只讀數據存儲，經過Dremel [61]具備一個交互式的相似SQL的界面。此數據用於基於使用的計費，做業調試和系統故障以及長期容量規劃。它還爲Google羣集工做負載跟蹤提供數據[80]。

全部這些功能都有助於用戶理解和調試Borg的行爲及用戶的做業，並幫助咱們的SREs爲每一個人管理幾萬臺機器。

3.Borg體系結構

Borg單元由一組機器，一個稱爲Borgmaster的邏輯中央控制器和單元中每臺機器上運行的稱爲Borglet的代理進程構成（參見圖1）。 Borg的全部組件都用C ++編寫。

3.1 Borgmaster

每一個單元的Borgmaster包括兩個進程：主進程Borgmaster和獨立的調度程序（§3.2）。主Borgmaster進程處理客戶端RPC，狀態變化（例如，建立做業）或提供對數據的只讀訪問（例如，查找做業）。它還管理系統中全部對象（機器，任務，分配等）的狀態機，與Borglets進行通訊，並提供Web UI做爲Sigma的備份。

Borgmaster在邏輯上是一個單一的進程，但實際上被複制了五次。每一個副本維護了一份該單元大部分狀態的內存副本，而且該狀態也記錄在該副本的本地磁盤上的高可用性，分佈式，基於Paxos的存儲[55]中。每一個單元的單個選定的master既用做Paxos的領導者又用做狀態mutator，處理改變單元狀態的全部操做（例如提交做業或在機器上終止任務）。當cell創建時或只要當選擇的master出現故障時，就會選擇一個master（使用Paxos）; 它獲取一個Chubby鎖，以便其餘系統能夠找到它。選擇一個master和故障轉移到新的master一般須要大約10s，可是在大單元中可能須要一分鐘，由於一些內存中的狀態必須重建。當副本從中斷恢復時，它將自動從新同步來自最新的其它Paxos副本的狀態。

Borgmaster在某個時間點的狀態稱爲檢查點，並採用按期快照的形式增長一條更改日誌（保存在Paxos存儲中）。檢查點有許多用途，包括將Borgmaster的狀態恢復到過去的任意一個點（例如，在接受觸發Borg中的軟件缺陷的請求以前，以即可以對其進行調試）; 構建用於將來查詢的事件的持久日誌; 以及離線模擬。

高保真的Borgmaster模擬器Faokemaster可用於讀取檢查點文件，幷包含產生Borgmaster代碼的完整副本，其中包含與Borglets的無存根接口。它接受RPC進行狀態機更改和執行操做，如「調度全部掛起的任務」，經過與它進行交互（它就像是一個活的Borgmaster，帶有模擬的Borglets可從檢查點文件重放真實的交互），可使用它來調試故障。用戶能夠逐步觀察在過去實際發生的系統狀態的改變。 Fauxmaster對於容量規劃（「符合多少這種類型的新做業？」）以及在更改單元配置以前進行完整性檢查（「這種更改是否會驅逐重要的工做？」）也頗有用。

3.2 調度

提交做業時，Borgmaster會將其持久化在Paxos存儲中，並將做業的任務添加到等待隊列。這是由調度程序異步掃描的，若是有足夠的可用資源知足做業的要求，則會將任務分配給機器。（調度程序主要操做任務，而不是做業。）掃描從高到低優先級，由優先級循環方案調度，以確保用戶之間的公平性，並避免大型做業後面的隊頭阻塞。調度算法有兩個部分：可行性檢查（用於找到任務能夠運行的機器），以及評分（用於挑選一個可行的機器）。

在可行性檢查中，調度器找到知足任務需求的一組機器，這組機器具備足夠的「可用」資源 - 這些資源中包括已經分配給能夠被搶佔的較低優先級任務的資源。在評分中，調度器肯定每一個可行機器的「良好性」。該分數考慮了用戶指定的偏好，但主要是由內置標準決定，如最大限度地減小搶佔任務的數量和優先級，選擇已經有任務包副本的機器，跨越電源和故障域傳播任務，以及打包質量（包括將高優先級任務和低優先級任務混合到單個機器上，以容許高優先級任務在負載高峯中擴展）。

Borg最初使用E-PVM [4]的變體進行評分，其在不一樣資源上生成單一成本值，而且在放置任務時最小化成本的變化。在實踐中，E-PVM最終在全部機器上擴展負載，爲負載高峯留下餘量 - 可是以增長碎片爲代價，特別是對於須要大部分機器的大型任務; 咱們有時稱之爲「恰好合適」。

調度的另外一端是「最佳合適」，它試圖儘量緊密地填充機器。這使一些機器沒有用戶做業（它們仍然運行存儲服務器），所以放置大任務是簡單直接的，可是嚴格的封裝不利於用戶或Borg對資源需求的任何錯誤估計。這會傷害突發負載的應用程序，對於指定低CPU需求的批處理做業尤爲糟糕，以便他們能夠輕鬆安排並嘗試在未使用的資源中乘機運行：20％的非生產任務請求少於0.1個CPU內核。

咱們當前的評分模型是一種混合式的，它試圖減小擱置資源的數量 - 因爲機器上的另外一個資源被徹底分配而沒法使用的資源。它提供比最適合咱們工做負載約3-5％的更好的包裝效率（在[78]中定義）。

若是計分階段選擇的機器沒有足夠的可用資源來知足任務，則Borg會搶佔（殺死）較低優先級任務，從最低優先級到最高優先級，直到知足爲止。咱們將被搶佔的任務添加到調度程序的掛起隊列，而不是遷移或休眠它們。

任務啓動延遲（從做業提交到任務運行的時間）是一個已經並繼續受到極大關注的領域。它是高度可變的，中值一般約25s。軟件包安裝大約佔所有的80％：其中一個已知的瓶頸是軟件包要寫入的本地磁盤的爭用。爲了減小任務啓動時間，調度程序更傾向將任務分配給已經安裝了必要的軟件包（程序和數據）的機器：大多數軟件包是不可變的，所以能夠共享和緩存。（這是Borg調度程序支持數據本地化的惟一形式。）此外，Borg使用相似樹和torrent的協議並行地將軟件包分發到機器。

此外，調度程序使用幾種技術來擴展具備成千上萬臺機器的單元（§3.4）。

3.3 Borglet

Borglet是一個本地Borg代理，存在於單元中的每一臺機器中。它啓動和中止任務; 若是故障就重啓任務; 經過操縱操做系統內核設置來管理本地資源;翻轉調試日誌; 並向Borgmaster等監控系統報告機器的狀態。

Borgmaster每隔幾秒鐘輪詢一次Borglet以檢索機器的當前狀態，並將全部未完成的請求發送給它。這使Borgmaster控制通訊速率，避免了顯式流控制機制的須要，並防止恢復風暴[9]。

選定的master負責準備要發送到Borglets的消息，並負責根據cell的響應更新cell的狀態。爲了性能可擴展性，每一個Borgmaster副本運行無狀態連接分片來處理與一些Borglets的通訊;每當發生Borgmaster選擇時從新計算分區。對於彈性，Borglet始終報告其完整狀態，但連接分片經過僅報告狀態機間的差別來收集和壓縮此信息，以減小選定master的更新負載。

若是Borglet沒有響應幾個輪詢消息，它的機器被標記爲關閉，而且其運行的任何任務被從新安排在其餘機器上。若是通訊恢復，Borgmaster會通知Borglet要中止這些已經從新安排的任務，以免重複。即便與Borgmaster失去聯繫，Borglet也繼續正常運行，所以即便全部Borgmaster副本故障了，當前運行的任務和服務也會保持。

3.4可擴展性

咱們不肯定Borg的集中式架構的最終可擴展性限制將出如今何處; 到目前爲止，每次咱們接近一個極限，咱們已經設法消除它。一個Borgmaster能夠管理一個cell中的數千臺機器，而且幾個cell具備每分鐘超過10000個任務的到達速率。繁忙的Borgmaster使用10-14個 CPU內核和高達50GiB 的RAM。咱們使用幾種技術來實現這種規模。

早期版本的Borgmaster有一個簡單的，同步的循環：接受請求，計劃任務，並與Borglets通訊。爲了處理更大的cell，咱們將調度程序分離出來做爲一個單獨的進程，這樣它能夠與其餘Borgmaster函數並行操做故障容限。調度器副本對單元狀態的高速緩存副本進行操做。它反覆：從選定的主機檢索狀態更改（包括已分配和掛起的工做）; 更新其本地副本;執行調度傳遞以分配任務; 並將這些分配通知選定的主機。master將接受並採用這些分配，除非它們是不適當的（例如，基於過時狀態），這將致使它們在調度程序的下一次傳遞中被從新考慮。這在靈魂上與在Omega [69]中使用的樂觀併發控制很是類似，事實上，咱們最近爲Borg添加了針對不一樣工做負載類型使用不一樣調度程序（schedulers）的能力。

爲了提升響應時間，咱們添加了單獨的線程來與Borglets進行通訊並響應只讀RPC。爲了更好的性能，咱們在五個Borgmaster副本（§3.3）中分割（分區）這些功能。同時，這保持了UI上99％ile的響應時間低於1s和95％ile 的Borglet輪詢間隔低於10s。

圖3：針對生產和非生產工做負載的任務驅逐率及緣由。

數據自2013年8月1日起。

有幾點使Borg調度器更具可擴展性：

分數緩存：評估可行性和評價機器是昂貴的，所以Borg緩存分數直到機器或任務的屬性改變 - 例如，機器上的任務終止，屬性改變或任務的需求改變。忽略資源數量的小變化可減小高速緩存失效。

等價類：Borg做業中的任務一般具備相同的需求和約束，所以並非肯定每一個機器上的每一個掛起任務的可行性，並對全部可行的機器進行評分，Borg只對每一個等價類的一個任務進行可行性分析和評分 - 一組具備相同需求的任務。

輕鬆隨機化：計算大cell中全部機器的可行性和分數是浪費的，所以調度程序以隨機順序檢查機器，直到找到「足夠」可行的機器進行評分，而後選擇該集合中的最佳機器。這減小了任務進入和離開系統時所需的評分和高速緩存失效的數量，並加快了任務到機器的分配。放鬆隨機化有時相似於Sparrow [65]的批量採樣，同時還處理優先級，搶佔，異質性和軟件包安裝的成本。

在咱們的實驗（§5）中，從頭開始安排單元的整個工做負載一般須要幾百秒，可是在禁用上述技術後超過3天后尚未完成。一般，在等待隊列上的在線調度傳遞在不到半秒內完成。

4.可用性

故障是大規模系統中的常態[10,11,22]。圖3提供了15個樣本cell中任務驅逐緣由的分解。運行在Borg上的應用程序應能使用諸如複製，在分佈式文件系統中存儲持久狀態並（若是適當的話）捕捉臨時檢查點等技術來處理此類事件。即便如此，咱們也試圖減輕這些事件的影響。例如，Borg：

• 若有必要，在新機器上自動從新安排逐出的任務;

• 經過在諸如機器，機架和電源域之類的故障域中擴展做業的任務，減小相關故障;

• 限制任務中斷的容許速率和任務數量，這些任務能夠在維護活動（例如操做系統或機器更新）期間同時關閉；

圖4：壓縮的效果。

對15個cell，在壓縮後得到的原始cell大小的百分比的CDF。

• 使用聲明性指望狀態表示和冪等變換操做，使得失敗的客戶端能夠無損地從新提交任何被遺忘的請求;

• rate-limits找到沒法訪問的機器的任務的新位置，由於它沒法區分大型機器故障和網絡分區;

• 避免重複任務::致使任務或機器崩潰的機器配對;

• 經過不斷從新運行日誌記錄器任務（§2.4）來恢復寫入本地磁盤的關鍵中間數據，即便所鏈接的alloc已終止或移動到了另外一臺機器。用戶能夠設置系統持續嘗試的時間;通常是幾天。

Borg的一個關鍵設計特色是，即便Borgmaster或任務的Borglet關閉，已經運行的任務也會繼續運行。可是保持master仍然很重要，由於當它關閉時，沒法提交新做業或更新現有的做業，而且沒法從新計劃故障的計算機上的任務。

Borgmaster使用的技術組合，使其在實踐中達到了99.99％的可用性：機器故障複製; 准入控制避免過載; 並使用簡單的低級工具部署實例以最小化外部依賴性。每一個單元獨立於其餘單元，以最小化關聯的操做者錯誤和故障傳播的機會。這些目標，不是可擴展性限制，而是反對較大cell的主要論證。

文章來源：http://javajgs.com/archives/6307