Borg使用策略是什么

本篇內(nèi)容介紹了“Borg使用策略是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

使用效率

Borg的一個(gè)主要目的就是有效的利用Google的機(jī)器艦隊(duì)，這可是一大筆財(cái)務(wù)投資：讓效率提升幾個(gè)百分點(diǎn)就能省下幾百萬美元。

1 測(cè)度方法論

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

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

在壓縮cell實(shí)驗(yàn)中為了保持機(jī)器異構(gòu)性，我們隨機(jī)選擇去掉的機(jī)器。為了保持工作負(fù)載的異構(gòu)性，我們保留了所有負(fù)載，除了那些對(duì)服務(wù)和存儲(chǔ)需要有特定需求的。我們把那些需要超過一半cell的job的硬限制改成軟的，允許不超過0.2%的task持續(xù)的pending如果它們過于挑剔機(jī)器；廣泛的測(cè)試表明這些結(jié)果是可重復(fù)的。如果我們需要一個(gè)大的cell，就把原cell復(fù)制擴(kuò)大；如果我們需要更多的cell，就復(fù)制幾份cell。

所有的實(shí)驗(yàn)都每個(gè)cell重復(fù)11次，用不同的隨機(jī)數(shù)發(fā)生器。在圖上，我們用一個(gè)橫線來表示最少和最多需要的機(jī)器，然后選擇90%這個(gè)位置作為結(jié)果，平均或者居中的結(jié)論不會(huì)代表一個(gè)系統(tǒng)管理員會(huì)做的最優(yōu)選擇。我們相信cell壓縮提供了一個(gè)公平一致的方式去比較調(diào)度策略：好的策略只需要更少的機(jī)器來跑相同的負(fù)載。

我們的實(shí)驗(yàn)聚焦在調(diào)度(打包)某個(gè)時(shí)間點(diǎn)的一個(gè)負(fù)載，而不是重放一段長期的工作蹤跡。這部分是因?yàn)閺?fù)制一個(gè)開放和關(guān)閉的隊(duì)列模型比較困難，部分是因?yàn)閭鹘y(tǒng)的一段時(shí)間內(nèi)跑完的指標(biāo)和我們環(huán)境的長期跑服務(wù)不一樣，部分是因?yàn)檫@樣比較起來比較明確，部分是因?yàn)槲覀兿嘈旁趺凑疾畈欢?，部分是因?yàn)槲覀冊(cè)谙M(fèi)20萬個(gè)Borg CPU來做測(cè)試——即使在Google的量級(jí)，這也不是一個(gè)小數(shù)目(譯者：就你丫理由多！)

在生產(chǎn)環(huán)境下，我們謹(jǐn)慎的留下了一些頂部空間給負(fù)載的增加，比如一些“黑天鵝”時(shí)間，負(fù)載高峰，機(jī)器故障，硬件升級(jí)，以及大范圍故障(供電進(jìn)灰)。圖4顯示了我們?cè)诂F(xiàn)實(shí)世界中可以把cell壓縮到多小。上面的基線是用來表示壓縮大小的。

2 Cell的共享使用

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

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

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

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

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

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

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

這些實(shí)驗(yàn)確定了倉庫級(jí)別的性能測(cè)試是比較微妙的，加強(qiáng)了[51]中的觀察，并且得出了共享并沒有顯著的增加程序運(yùn)行的開銷。

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

3 大Cell

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

4 資源請(qǐng)求粒度

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

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

5 資源再利用

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

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

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

一臺(tái)機(jī)器有可能因?yàn)樽粤舻仡A(yù)估錯(cuò)度而導(dǎo)致運(yùn)行時(shí)資源不足 —— 即使所有的task都在限制資源之內(nèi)跑。如果這種情況發(fā)生了，我們殺掉或者限制non-prod task，從來不對(duì)prod task下手。

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

圖11可以看到更多的細(xì)節(jié)，包括回收資源、實(shí)際使用資源和限制資源的比例。一個(gè)超內(nèi)存限制的task首先會(huì)被重新調(diào)度，不管優(yōu)先級(jí)有多高，所以這樣就很少有task會(huì)超過內(nèi)存限制。另一方面，CPU使用率是可以輕易被卡住的，所以短期的超過自留地資源的高峰時(shí)沒什么損害的。

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

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

隔離性

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

1 安全隔離

我們使用Linux chroot監(jiān)獄作為同一臺(tái)機(jī)器不同task之間主要的安全隔離機(jī)制。為了允許遠(yuǎn)程debug，我們以前會(huì)分發(fā)ssh key來自動(dòng)給用戶權(quán)限去訪問跑他們task的機(jī)器，現(xiàn)在不這么干了。對(duì)大多數(shù)用戶來說，現(xiàn)在提供的是borgssh命令，這個(gè)程序和Borglet協(xié)同，來構(gòu)建一個(gè)ssh shell，這個(gè)shell和task運(yùn)行在同樣的chroot和cgroup下，這樣限制就更加嚴(yán)格了。

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

6.2 性能隔離

早期的Borglet使用了一種相對(duì)原始粗暴的資源隔離措施：事后內(nèi)存、硬盤、CPU使用率檢查，然后終止使用過多內(nèi)存和硬盤的task，或者把用太多CPU的激進(jìn)task通過Linux CPU優(yōu)先級(jí)降下來。不過，很多粗暴的task還是很輕易的能影響同臺(tái)機(jī)器上其他task的性能，然后很多用戶就會(huì)多申請(qǐng)資源來讓Borg減少調(diào)度的task數(shù)量，然后會(huì)導(dǎo)致系統(tǒng)資源利用率降低。資源回收可以彌補(bǔ)一些損失，但不是全部，因?yàn)橐ＷC資源安全紅線。在極端情況下，用戶請(qǐng)求使用專用的機(jī)器或者cell。

目前，所有Borg task都跑在Linux cgroup-based資源容器[17,58,62]里面，Borglet操作這些容器的設(shè)置，這樣就增強(qiáng)了控制因?yàn)椴僮飨到y(tǒng)內(nèi)核在起作用。即使這樣，偶爾還是有低級(jí)別的資源沖突(例如內(nèi)存帶寬和L3緩存污染)還是會(huì)發(fā)生，見[60,83]

為了搞定超負(fù)荷和超請(qǐng)求，Borg task有一個(gè)應(yīng)用階級(jí)(appclass)。最主要的區(qū)分在于延遲敏感l(wèi)atency-sensitive (LS)的應(yīng)用和其他應(yīng)用的區(qū)別，其他應(yīng)用我們?cè)谖恼吕锩娼衎atch。LS task是包括面向用戶的應(yīng)用和需要快速響應(yīng)的共享基礎(chǔ)設(shè)施。高優(yōu)先級(jí)的LS task得到最高有待，可以為了這個(gè)把batch task一次餓個(gè)幾秒種。

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

Borglet的用戶空間控制循環(huán)在未來預(yù)期的基礎(chǔ)上給prod task分配內(nèi)存，在內(nèi)存壓力基礎(chǔ)上給non-prod task分配內(nèi)存；從內(nèi)核事件來處理Out-of-Memory (OOM)；殺掉那些想獲取超過自身限制內(nèi)存的task，或者在一個(gè)超負(fù)載的機(jī)器上實(shí)際超過負(fù)載時(shí)。Linux的積極文件緩存策略讓我們的實(shí)現(xiàn)更負(fù)載一點(diǎn)，因?yàn)榫_計(jì)算內(nèi)存用量會(huì)麻煩很多。

為了增強(qiáng)性能隔離，LS task可以獨(dú)占整個(gè)物理CPU核，不讓別的LS task來用他們。batch task可以在任何核上面跑，不過他們只被分配了很少的和LS task共享的資源。Borglet動(dòng)態(tài)的調(diào)整貪婪LS task的資源限制來保證他們不會(huì)把batch task餓上幾分鐘，有選擇的在需要時(shí)使用CFS帶寬控制[75]；光有共享是不行的，我們有多個(gè)優(yōu)先級(jí)。

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

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

“Borg使用策略是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！