本文譯者：王勇橋，80后的IT攻城獅，曾供職于IBM多年，現供職于華為公司，擔任高級系統架構師。主要從事云計算領域相關的工作。Mesos和Swarm社區的貢獻者。對容器化技術，自動化部署，分布式集群管理，資源調度，存儲技術有較深的研究。
編者按：本文是對Google在分布式底層架構的經典文章的翻譯，原文可以查看這里，由于原文較長，CSDN將分上、下兩篇全文刊載此篇論文的翻譯，歡迎關注。本文為上篇。
摘要：Google的Borg系統是一個運行著成千上萬項作業的集群管理器，它同時管理著很多個應用集群，每個集群都有成千上萬臺機器，這些集群之上運行著Google的很多不同的應用。Borg通過準入控制，高效的任務打包，超額的資源分配和進程級隔離的機器共享，來實現超高的資源利用率。它通過最小化故障恢復時間的運行時特性和減少相關運行時故障的調度策略來支持高可用的應用程序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的主要論證。
京公網安備 11010502049343號