共計 6849 個字符，預計需要花費 18 分鐘才能閱讀完成。

本篇內容介紹了“Borg 使用策略是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

使用效率

Borg 的一個主要目的就是有效的利用 Google 的機器艦隊，這可是一大筆財務投資：讓效率提升幾個百分點就能省下幾百萬美元。

1 測度方法論

我們的 job 部署是有資源約束的，而且很少碰到負載高峰，我們的機器是異構的，我們從 service job 回收利用的資源跑 batch job。所以，為了測量我們需要一個比“平均利用率”更抽象的標準。在做了一些實驗后我們選擇了 cell 密度(cell compaction)：給定一個負載，我們不斷的從零開始(這樣可以避免被一個倒霉的配置卡住)，部署到盡可能小的 Cell 里面去，直到再也不能從這個 cell 里面抽機器出來。這提供了一個清晰的終止條件，并促進了無陷阱的自動化比較，這里的陷阱指的是綜合化的工作負載和建模[31]。一個定量的比較和估算技術可以看[78]，有不少微妙的細節。

我們不可能在線上的 cell 做性能實驗，所以我們用了 Fauxmaster 來達到高保真的模擬效果，使用了真的在線 cell 的負載數據包括所有的約束、實際限制、保留和常用數據 ($5.5)。這些數據從 2014-10-1 14:00 PDT 的 Borg 快照(checkpoints) 里面提取出來。(其他快照也產生類似的結論)。我們選取了 15 個 Borg cell 來出報告，先排除了特殊目的的、測試的、小的 (5000 機器) 的 cell，然后從剩下的各種量級大小的 cell 中平均取樣。

在壓縮 cell 實驗中為了保持機器異構性，我們隨機選擇去掉的機器。為了保持工作負載的異構性，我們保留了所有負載，除了那些對服務和存儲需要有特定需求的。我們把那些需要超過一半 cell 的 job 的硬限制改成軟的，允許不超過 0.2% 的 task 持續的 pending 如果它們過于挑剔機器；廣泛的測試表明這些結果是可重復的。如果我們需要一個大的 cell，就把原 cell 復制擴大；如果我們需要更多的 cell，就復制幾份 cell。

所有的實驗都每個 cell 重復 11 次，用不同的隨機數發生器。在圖上，我們用一個橫線來表示最少和最多需要的機器，然后選擇 90% 這個位置作為結果，平均或者居中的結論不會代表一個系統管理員會做的最優選擇。我們相信 cell 壓縮提供了一個公平一致的方式去比較調度策略：好的策略只需要更少的機器來跑相同的負載。

我們的實驗聚焦在調度 (打包) 某個時間點的一個負載，而不是重放一段長期的工作蹤跡。這部分是因為復制一個開放和關閉的隊列模型比較困難，部分是因為傳統的一段時間內跑完的指標和我們環境的長期跑服務不一樣，部分是因為這樣比較起來比較明確，部分是因為我們相信怎么整都差不多，部分是因為我們在消費 20 萬個 Borg CPU 來做測試——即使在 Google 的量級，這也不是一個小數目(譯者：就你丫理由多！)

在生產環境下，我們謹慎的留下了一些頂部空間給負載的增加，比如一些“黑天鵝”時間，負載高峰，機器故障，硬件升級，以及大范圍故障(供電進灰)。圖 4 顯示了我們在現實世界中可以把 cell 壓縮到多小。上面的基線是用來表示壓縮大小的。

2 Cell 的共享使用

幾乎我們所有的機器都同時跑 prod 和 non-prod 的 task：在共享 Borg cell 里有 98% 的機器同時跑這 2 種 task，在所有 Borg 管理的機器里面有 83% 同時跑這 2 種 task(我們有一些專用的 Cell 跑特定任務)。

鑒于很多其他的組織把面向用戶應用和批處理應用在不同的集群上運行，我們設想一下如果我們也這么干會發生什么情況。圖 5 展現了在一個中等大小的 Cell 上分開跑我們 prod 和 non-prod 的工作負載將需要 20-30% 多的機器。這是因為 prod 的 job 通常會保留一些資源來應對極少發生的負載高峰，但實際上在大多情況下不會用這些資源。Borg 把這批資源回收利用了 ($5.5) 來跑很多 non-prod 的工作，所以最終我們只需要更少的機器。

大部分 Borg cell 被幾千個用戶共享使用。圖 6 展現了為什么。對這個測試，如果一個用戶消費超過了 10TiB 內存(或 100TiB)，我們就把這個用戶的工作負載分離到一個單獨的 Cell 里面去。我們目前的策略展現了它的威力：即使我們設置了這么高的閾值(來分離)，也需要 2 -16 倍多的 Cell，和 20-150% 多的機器。資源池的方案再次有效地節省了開銷。

但是，或許把很多不相關的用戶和 job 類型打包放到一臺機器上，會造成 CPU 沖突，然后就需要更多的機器進行補償？為了驗證這一點，我們看一下在同一臺機器，鎖定時鐘周期，每指令循環數 CPI(cycles per instruction)在不同環境的 task 下是怎么變化的。在這種情況下，CPI 是一個可比較的指標而且可以代表沖突度量，因為 2 倍的 CPI 意味著 CPU 密集型程序要跑 2 倍的時間。這些數據是從一周內 12000 個隨機的 prod 的 task 中獲取的，用硬件測量工具 [83] 取的，并且對采樣做了權重，這樣每秒 CPU 都是平等的。測試結果不是非常明顯。

我們發現 CPI 在同一個時間段內和下面兩個量正相關：這臺機器上總的 CPU 使用量，以及 (強相關) 這個機器上同時跑的 task 數量；每往一臺機器上增加 1 個 task，就會增加 0.3% 的 CPI(線性模型過濾數據)；增加一臺 10% 的 CPU 使用率，就會增加小于 2% 的 CPI。即使這已經是一個統計意義顯著的正相關性，也只是解釋了我們在 CPI 度量上看到的 5% 的變化，還有其他的因素支配著這個變化，例如應用程序固有的差別和特殊的干涉圖案[24,83]。

比較我們從共享 Cell 和少數只跑幾種應用的專用 Cell 獲取的 CPI 采樣，我們看到共享 Cell 里面的 CPI 平均值為 1.58(σ=0.35, 方差)，專用 Cell 的 CPI 平均值是 1.53(σ=0.32, 方差). 也就是說，共享 Cell 的性能差 3%。

為了搞定不同 Cell 的應用會有不同的工作負載，或者會有幸存者偏差(或許對沖突更敏感的程序會被挪到專用 Cell 里面去)，我們觀察了 Borglet 的 CPI，在所有 Cell 的所有機器上都會被運行。我們發現專用 Cell 的 CPI 平均值是 1.20(σ=0.29, 方差)，而共享 Cell 里面的 CPI 平均值為 1.43(σ=0.45, 方差)，暗示了在專用 Cell 上運行程序會比在共享 Cell 上快 1.19 倍，這就超過了 CPU 使用量輕負載的這個因素，輕微的有利于專用 Cell。

這些實驗確定了倉庫級別的性能測試是比較微妙的，加強了 [51] 中的觀察，并且得出了共享并沒有顯著的增加程序運行的開銷。

不過，就算我們假設用了我們結果中最不好的數據，共享還是有益的：比起 CPU 的降速，在各個方案里面減少機器更重要，這會帶來減少所有資源的開銷，包括內存和硬盤，不僅僅是 CPU。

3 大 Cell

Google 建立了大 Cell，為了允許大的任務運行，也是為了降低資源碎片。我們通過把負載從一個 cell 分到多個小 cell 上來測試后面那個效應(降低碎片效應)，隨機的把 job 用 round-robin 方式分配出去。圖 7 展示了用很多小 cell 會明顯的需要更多機器。

4 資源請求粒度

Borg 用戶請求的 CPU 單位是千分之一核，內存和硬盤單位是 byte。(1 核是一個 CPU 的超線程，在不同機器類型中的一個通用單位)。圖 8 展現了這個粒度的好處：CPU 核和內存只有少數的“最佳擊球點”，以及這些資源很少的相關性。這個分布和 [68] 里面的基本差不多，除了我們看到大內存的請求在 90% 這個線上。

提供一個固定尺寸的容器和虛擬機，在 IaaS(infrastructure-as-a-service)提供商里面或許是比較流行的，但不符合我們的需求。為了展現這一點，我們把 CPU 核和內存限制做成一個個尺寸，然后把 prod 的 job 按照大一點最近的尺寸去跑 (取這 2 個維度的平方值之和最近，也就是 2 維圖上的直線)，0.5 核的 CPU,1G 的內存為差值。圖 9 顯示了一般情況下我們需要 30-50% 多的資源來運行。上限來自于把大的 task 跑在一整臺機器上，這些 task 即使擴大四倍也沒辦法在原有 Cell 上壓縮跑。下限是允許這些 task 等待(pending)。(這比[37] 里面的數據要大 100%，因為我們支持超過 4 中尺寸而且允許 CPU 和內存無限擴張)。

5 資源再利用

一個 job 可以聲明一個限制資源，是每個 task 能強制保證的資源上限。Borg 會先檢查這個限制是不是在用戶的配額內，然后檢查具體的機器是否有那么多資源來調度這個 task。有的用戶會買超過他們需要的配額，也有用戶會的 task 實際需要更多的資源去跑，因為 Borg 會殺掉那些需要更多的內存和硬盤空間的 task，或者卡住 CPU 使用率不上去。另外，一些 task 偶爾需要使用他們的所有資源(例如，在一天的高峰期或者受到了一個拒絕服務攻擊)，大多時候用不上那么多資源。

比起把那些分出來但不用的資源浪費掉，我們估計了一個 task 會用多少資源然后把其他的資源回收再利用給那些可以忍受低質量資源的工作，例如批處理 job。這整個過程被叫做資源再利用(resource reclamation)。這個估值叫做 task 自留地資源(reservation)，被 Borgmaster 每過幾秒就計算一次，是 Borglet 抓取的細粒度資源消費用率。最初的自留地資源被設置的和資源限制一樣大；在 300s 之后，也就是啟動那個階段，自留地資源會緩慢的下降到實際用量加上一個安全值。自留地資源在實際用量超過它的時候會迅速上升。

Borg 調度器 (scheduler) 使用限制資源來計算 prod task 的可用性($3.2)，所以這些 task 從來不依賴于回收的資源，也不提供超售的資源；對于 non-prod 的 task，使用了目前運行 task 的自留地資源，這么新的 task 可以被調度到回收資源。

一臺機器有可能因為自留地預估錯度而導致運行時資源不足 —— 即使所有的 task 都在限制資源之內跑。如果這種情況發生了，我們殺掉或者限制 non-prod task，從來不對 prod task 下手。

圖 10 展示了如果沒有資源再利用會需要更多的機器。在一個中等大小的 Cell 上大概有 20% 的工作負載跑在回收資源上。

圖 11 可以看到更多的細節，包括回收資源、實際使用資源和限制資源的比例。一個超內存限制的 task 首先會被重新調度，不管優先級有多高，所以這樣就很少有 task 會超過內存限制。另一方面，CPU 使用率是可以輕易被卡住的，所以短期的超過自留地資源的高峰時沒什么損害的。

圖 11 暗示了資源再利用可能是沒必要的保守：在自留地和實際使用中間有一大片差距。為了測試這一點，我們選擇了一個生產 cell 然后調試它的預估參數到一個激進策略上，把安全區劃小點，然后做了一個介于激進和基本之間的中庸策略跑，然后恢復到基本策略。

圖 12 展現了結果。第二周自留地資源和實際資源的差值是最小的，比第三周要小，最大的是第一和第四周。和預期的一樣，周 2 和周 3 的 OOM 率有一個輕微的提升。在復查了這個結果后，我們覺得利大于弊，于是把中庸策略的參數放到其他 cell 上部署運行。

隔離性

50% 的機器跑 9 個以上的 task；最忙的 10% 的機器大概跑 25 個 task，4500 個線程[83]。雖然在應用間共享機器會增加使用率，也需要一個比較好的機制來保證 task 之間不互相沖突。包括安全和性能都不能互相沖突。

1 安全隔離

我們使用 Linux chroot 監獄作為同一臺機器不同 task 之間主要的安全隔離機制。為了允許遠程 debug，我們以前會分發 ssh key 來自動給用戶權限去訪問跑他們 task 的機器，現在不這么干了。對大多數用戶來說，現在提供的是 borgssh 命令，這個程序和 Borglet 協同，來構建一個 ssh shell，這個 shell 和 task 運行在同樣的 chroot 和 cgroup 下，這樣限制就更加嚴格了。

VM 和安全沙箱技術被使用在外部的軟件上，在 Google’s AppEngine (GAE) [38]和 Google Compute Engine (GCE)環境下。我們把 KVM 進程中的每個 hosted VM 按照一個 Borg task 運行。

6.2 性能隔離

早期的 Borglet 使用了一種相對原始粗暴的資源隔離措施：事后內存、硬盤、CPU 使用率檢查，然后終止使用過多內存和硬盤的 task，或者把用太多 CPU 的激進 task 通過 Linux CPU 優先級降下來。不過，很多粗暴的 task 還是很輕易的能影響同臺機器上其他 task 的性能，然后很多用戶就會多申請資源來讓 Borg 減少調度的 task 數量，然后會導致系統資源利用率降低。資源回收可以彌補一些損失，但不是全部，因為要保證資源安全紅線。在極端情況下，用戶請求使用專用的機器或者 cell。

目前，所有 Borg task 都跑在 Linux cgroup-based 資源容器 [17,58,62] 里面，Borglet 操作這些容器的設置，這樣就增強了控制因為操作系統內核在起作用。即使這樣，偶爾還是有低級別的資源沖突 (例如內存帶寬和 L3 緩存污染) 還是會發生，見[60,83]

為了搞定超負荷和超請求，Borg task 有一個應用階級 (appclass)。最主要的區分在于延遲敏感 latency-sensitive (LS) 的應用和其他應用的區別，其他應用我們在文章里面叫 batch。LS task 是包括面向用戶的應用和需要快速響應的共享基礎設施。高優先級的 LS task 得到最高有待，可以為了這個把 batch task 一次餓個幾秒種。

第二個區分在于可壓縮資源 (例如 CPU 循環，disk I/ O 帶寬) 都是速率性的可以被回收的，對于一個 task 可以降低這些資源的量而不去殺掉 task；和不可壓縮資源 (例如內存、硬盤空間) 這些一般來說不殺掉 task 就沒法回收的。如果一個機器用光了不可壓縮資源，Borglet 馬上就會殺掉 task，從低優先級開始殺，直到剩下的自留地資源夠用。如果機器用完了可壓縮資源，Borglet 會卡住使用率這樣當短期高峰來到時不用殺掉任何 task。如果情況沒有改善，Borgmaster 會從這個機器上去除一個或多個 task。

Borglet 的用戶空間控制循環在未來預期的基礎上給 prod task 分配內存，在內存壓力基礎上給 non-prod task 分配內存；從內核事件來處理 Out-of-Memory (OOM)；殺掉那些想獲取超過自身限制內存的 task，或者在一個超負載的機器上實際超過負載時。Linux 的積極文件緩存策略讓我們的實現更負載一點，因為精確計算內存用量會麻煩很多。

為了增強性能隔離，LS task 可以獨占整個物理 CPU 核，不讓別的 LS task 來用他們。batch task 可以在任何核上面跑，不過他們只被分配了很少的和 LS task 共享的資源。Borglet 動態的調整貪婪 LS task 的資源限制來保證他們不會把 batch task 餓上幾分鐘，有選擇的在需要時使用 CFS 帶寬控制[75]；光有共享是不行的，我們有多個優先級。

就像 Leverich [56]，我們發現標準的 Linux CPU 調度 (CFS) 需要大幅調整來支持低延遲和高使用率。為了減少調度延遲，我們版本的 CFS 使用了額外的每 cgroup 歷史[16]，允許 LS task 驅逐 batch task，并且避免多個 LS task 跑在一個 CPU 上的調度量子效應(scheduling quantum，譯者：或許指的是互相沖突？)。幸運的是，大多我們的應用使用的每個線程處理一個請求模型，這樣就緩和了持久負載不均衡。我們節儉地使用 cpusets 來分配 CPU 核給有特殊延遲需求的應用。這些措施的一部分結果展現在圖 13 里面。我們持續在這方面投入，增加了線程部署和 CPU 管理包括 NUMA 超線程、能源覺察(例如[81])，增加 Borglet 的控制精確度。

Task 被允許在他們的限制范圍內消費資源。其中大部分 task 甚至被允許去使用更多的可壓縮資源例如 CPU，充分利用沒有被使用的資源。大概 5% 的 LS task 禁止這么做，主要是為了增加可預測性；小于 1% 的 batch task 也禁止。使用超量內存默認是被禁止的，因為這會增加 task 被殺的概率，不過即使這樣，10% 的 LS task 打開了這個限制，79% 的 batch task 也開了因為這事 MapReduce 框架默認的。這事對資源再回收 ($5.5) 的一個補償。Batch task 很樂意使用沒有被用起來的內存，也樂意不時的釋放一些可回收的內存：大多情況下這跑的很好，即使有時候 batch task 會被急需資源的 LS task 殺掉。

“Borg 使用策略是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站，丸趣 TV 小編將為大家輸出更多高質量的實用文章！