3、Borg 架構

　　一個Borg的cell由一系列的機器組成，通常在cell運行著一個邏輯的中央控制器叫做Borgmaster，在cell中的每臺機器上則運行著一個叫Borglet的代理進程。而Borg的所有組件都是用C++編寫的。

3.1、Borgmaster

　　每個cell的Borgmaster主要由兩個進程組成：一個主Borgmaster進程以及一個分離的調度器。主Borgmaster進程用于處理各種客戶的RPC請求，這些請求無非包括狀態變更（用于創建job）或者對數據的只讀訪問（用于查詢的job）。它還用于管理系統中各個對象（機器，task，alloc等）的狀態機，和Borglets之間的交互以及提供一個web的UI作為Sigma的備份。

　　從邏輯上來說，Borgmaster是一個單一的進程，但事實上它有五個重復單元。每個重復單元都維護了一個cell在內存中的大部分狀態，并且這些狀態同時用高可用的，分布式的，基于Paxos算法的手法記錄在重復單元的本地磁盤上。每一個當選的master都同時作為Paxos leader以及狀態變更者，用于處理所有改變cell狀態的操作，例如提交一個job或者終止一臺機器上的一個task。當一個cell剛剛啟動或者當選的master故障的時候，我們需要利用Paxos算法選舉出新的master，在這個過程中我們需要獲取一個Chubby鎖，從而能讓其他系統發現它。選舉一個master節點通常需要10s鐘的時間，但是對于一些比較大的cell，這可能需要花上一分鐘，因為許多在內存中的狀態信息需要進行重構。當一個重復單元從故障中恢復過來的時候，它需要動態地與其他的重復單元進行同步，從而更新到最新的狀態。

　　Borgmaster在一個給定時間點的狀態叫做checkpoint，通常它們以定期快照加上更改日志的形式存放在Paxos store中。Checkpoint有很多的用處，包括將Borgmaster的狀態恢復到之前任意的一個時間點（比如回到接收觸發Borg缺陷的請求之前的狀態，因此我們就能據此進行調試）；在極端情況下進行手動修復；構建一個持久性的事件日志用于以后的查詢；以及用于離線的模擬。

　　有一個高保真的Borgmaster模擬器叫做Fauxmaster可以用來讀取checkpoints文件，存放完整的Borgmaster代碼拷貝，以及廢棄的Borglets接口。它能夠接收RPC用于狀態機的轉換并且執行一些操作，例如，“調度所有掛起的task”，我們還可以用它來調試錯誤，通過與它交互，仿佛它是一個真的Borgmaster一樣，然后再通過模擬的Borglet從而重現checkpoint中所有的真實交互。這樣用戶就能一步一步地分析觀察在過去真實發生的系統的變化。Fauxmaster同樣對于容量計劃非常有用（比如對于“這種類型創建多少新的job比較合適”這樣的問題），而且還能在對一個cell的配置進行更改前進行完整性檢查（比如“這樣的更改會不會對一些重要的job產生影響”）。

?

3.2、調度

　　當一個job被提交的時候，Borgmaster會將它持續性地記錄在Paxos中，并且將該job中的task都加入掛起隊列中。這些都是由調度器異步掃描完成的，它會在有足夠資源并且符合job的限制條件的時候將task部署到機器上。（調度器主要操作的是task，而不是job）。掃描根據優先級從高到底進行，在同一優先級內按照輪轉法進行調節從而確保各用戶間的公平性并且避免大型job的頭端阻塞。調度算法主要由兩部分組成：feasibility checking，用于發現task可以運行的機器，和scoring，選取其中一個可行的機器。

　　在feasibility checking中，調度器會找到一系列的機器，這些機器符合task限制條件并且擁有足夠的可用的資源（包括那些被分配給低優先級task的資源）。在scoring中，調度器會再對那些滿足基本要求的機器進行打分評判。打分會考慮不同用戶的偏好，但主要還是由一些內置的標準決定的：例如最小化被搶占進程的數目和優先級，選取那些已經有該task包的機器，在電源和失敗域內傳播task，以及打包質量包括將高優先級和低優先級的task混合放在一臺機器中從而讓那些高優先級的task能擴展它們的負載峰值。

　　Borg原生使用的是一種E-PVM的變體用于scoring。它能夠用來對各種各樣的資源產生一個單一的成本價值并且最小化部署一個task帶來的改變成本。事實上，E-PVM在所有機器上分布負載，而是將留下的余量用于負載峰值，這是以增加碎片為代價的，特別是對于那些需要占用機器大部分資源的大型task來說，我們通常叫這種做法為“worst fit"。

　　“worst fit”的對立面自然是"best fit"：它試圖將機器塞得越滿越好。這通常會給用戶job留下不少空的機器（當然這些機器上面依然運行著存儲服務器），因此對于大型task的部署就非常容易了，但是這種緊密的打包方式會使任何用戶或者Borg對于資源請求的錯誤估計都帶來不利的影響。這會對有著突發負載的應用造成傷害，對于批處理job是尤其不利的，因為它們會指定很低的CPU需求從而使它們能被輕松調度，在一些資源不被使用的時候趁機運行：通常20%的non-prod job都只需要不到0.1的CPU核。

　　我們現在使用的scoring模型是一種混合體。它試著減少標準資源的數量-----它們不能被使用，因為該機器上的另外一種資源已經全部被分配了。它能夠提供比“best fit”好大概3%-5%的打包效率。

　　如果通過scoring被選中的機器沒有足夠的可用資源去運行新的task。Borg就會搶占（甚至殺死）低優先級的task，按照優先級從低到高的順序，直到滿足條件為止。我們將被搶占的task放到調度器的掛起隊列中，而不是遷移或者讓它們休眠。

　　　　task的啟動延遲（從job提交到task運行的時間）是一個持續受到重視的領域。它的變化會比較大，平均值大概在25s左右。包的安裝大概占到了總時間的80%左右：一個已知的瓶頸是用于寫入包的本地磁盤的爭奪。為了減少task的啟動時間，調度器往往更愿意將task部署在已經安裝了相應包（包括程序和數據）的機器；大多數包都是一成不變的，因此能夠被共享和緩存（這是Borg調度器唯一支持的數據局部性的形式）。另外，Borg通過tree and torrent-like 協議將包并行地分發到機器上。

　　最后，調度器使用另外一些技術使它能擴展到那些有著成千上萬臺機器的cell上。

?

3.3、Borglet

　　　Borglet是一個本地的Borg代理，它會出現在cell中的每一臺機器上。它啟動，停止task；在task失敗的時候重啟它們，通過控制操作系統內核設置來管理本地資源以及向Borgmaster和其他監視系統報告機器狀態。

　　Borgmaster每過幾分鐘就輪詢每個Borglet獲取機器的當前狀態，同時向它們發送外部的請求。這能夠讓Borgmaster控制交互的速率，避免了顯示的流量控制和恢復風暴。

　　被選中的master用于準備發送給Borglet的信息以及利用Borglet的反饋更新cell的狀態。為了性能的擴展性，每個Borgmaster重復單元都運行了一個link shard，用來處理和一些Borglet的交互；通常在Borgmaster的選舉到來的時候，分區會被重新計算。為了彈性，Borglet通常會匯報它的全部狀態，但是link shard會匯聚并且壓縮這些信息，只匯報各個狀態機的改變，從而降低選中的master的更新負載。

　　如果一個Borglet接連沒有回復好幾條輪詢信息，那么相應的機器就被標志為down，并且它上面運行的任何task都將被重新調度到其他機器上。假如交互又恢復了，那么Borgmaster就會告訴對應的Borglet殺死那些已經被重新調度的task，從而避免重復。當Borglet失去了與Borgmaster的聯系的時候，它依舊繼續執行正常的操作，所以即使在所有的Borgmaster重復單元都掛掉之后，正在運行狀態的task和服務依舊保持正常運行。

?

3.4、可擴展性

　　我們并不確定最終的擴展性限制會來自Borg中心化結構的什么地方；至今為止，每次我們感到到達了一個極限的時候，我們總能夠最終消除它。一個單一的Borgmaster可以管理一個cell中許許多多的機器，而一些cell每分鐘要接收超過1000個的task。一個忙碌的Borgmaster會使用10-14個CPU核心以及搞到50G的RAM。我們使用了多項技術來實現這樣的擴展性。

　　　　早期的Borgmaster只有一個單一的，同步的循環用于接收請求，調度task以及和Borglet進行通信。為了應付大型的cell，我們將調度器分配到一個獨立進程中，從而使它能夠和其他用于異常處理的Borgmaster函數并行工作。一個調度器的重復單元通常在一個緩存的cell狀態拷貝上進行操作。它循環執行以下操作：從當選的master中獲取狀態改變（包括已經被部署以及掛起的工作）；更新它的本地緩存；向已經部署的task做一輪調度；并且將這些部署操作通知當前當選的master。master會接收并且應用這些部署，除非它們是不恰當的（比如它們基于的是已經過時的狀態），這樣它們在下一輪調度中被重新考慮。這和Omega中的樂觀并發控制是非常類似的。事實上，現在我們已經能讓Borg針對不同的負載類型使用不同的調度器了。

　　為了提高響應時間，我們添加了額外的線程用于和Borglet的交互以及響應只讀的RPC。為了提高性能，我們在五個Borgmaster重復單元間共享（部分地）這些功能。上述這些改進讓99%的UI相應時間降低到1s以下，而讓95%的Borglet輪詢間隔降低到10s以下。而以下的幾項技術讓Borg的調度器更具擴展性：

Score caching：評估一臺機器的可用性并為它評分是非常昂貴的，因此Borg會緩存它們直到機器或者task的特性發生改變，例如，機器上的一個task終止，屬性的改變或者task的請求改變。忽略小的資源請求數量的改變有利于降低緩存的失效。

Equivalence classes：一個Borg job里的task通常擁有相同的要求和限制條件。因此Borg并不會對每個掛起的task，對每臺機器做可行性分析，并且為每臺可行的機器打分。Borg只會對每個Equivalence classes里的一個task做可行性分析以及打分操作，而Equivalence classes其實就是一組具有相同請求的task。

Relaxed randomization：對一個大的cell中的每臺機器都進行可行性計算和打分是非常浪費的，因此調度器會對機器進行隨機的測試直到找到足夠多可行的機器用于打分，然后再在其中挑選出最好的。這樣做就降低了在task進入以及離開系統時，帶來的打分以及緩存失效的數目，并且加速了task到機器上的部署。Relaxed randomization有點類似于Sparrow中的批量采樣，同時它還能處理優先級，搶占，異質性以及包安裝帶來的開銷。

　　在我們的實驗中，從零開始調度一個cell的全部負載需要花費數百秒的時間，但是如果禁用上面這些技術，那么用三天的時間也完成不了。然而，一般來說，對于掛起隊列的一次調度循環往往能在不到半秒的時間內完成。

?

注：翻譯中部分內容可能比較晦澀或者并非十分流暢，歡迎指正

原文地址：http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/43438.pdf

轉載于:https://www.cnblogs.com/YaoDD/p/5374393.html

總結

以上是生活随笔為你收集整理的译：Google的大规模集群管理工具Borg（二）------ Borg架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。