黃 凱，孟慶永，謝雨來，2* ，馮 丹，2，秦磊華，2

0 引言

由于Docker相對于傳統(tǒng)虛擬機的優(yōu)勢，越來越多的研究工作者開始使用 Docker來代替虛擬機［1］:Tihfon等［2］借助于Docker實現(xiàn)了多任務(wù)PaaS(Platform as a Service)云基礎(chǔ)架構(gòu)，通過Docker實現(xiàn)了應(yīng)用的快速部署，應(yīng)用程序的優(yōu)化和隔離;Nguyen等［3］通過Docker，實現(xiàn)了用于高性能計算的分布式MPI(Message Passing Interface)集群，借助于Docker，使原本耗時的設(shè)置MPI集群工作變得相對簡便;Julian等［4］借助于Docker優(yōu)化了自動縮放網(wǎng)絡(luò)集群，而且他們認(rèn)為Docker容器可以在更大規(guī)模的生產(chǎn)環(huán)境中進(jìn)行更廣泛的應(yīng)用。

目前Docker swarm提供的資源調(diào)度策略比較單一，只考慮節(jié)點能否滿足任務(wù)需求和節(jié)點上的容器數(shù)量，沒有在節(jié)點之間進(jìn)行負(fù)載比較來選出最合適的節(jié)點來部署容器，因此會出現(xiàn)節(jié)點上資源使用率不均衡的情況［5］。

針對Docker集群網(wǎng)絡(luò)負(fù)載的資源調(diào)度，Dusia等［6］提出一種調(diào)度策略，可以保證不同優(yōu)先級的應(yīng)用容器享有不同比重的帶寬，在盡量滿足高優(yōu)先級網(wǎng)絡(luò)服務(wù)的同時，將剩余帶寬盡可能分配給低優(yōu)先級的服務(wù)，從而保證網(wǎng)絡(luò)上的服務(wù)質(zhì)量(Quality of Service，QoS)。這種調(diào)度策略，通過在原Docker架構(gòu)中增加分組分類器和優(yōu)先級調(diào)度器來實現(xiàn)網(wǎng)絡(luò)資源調(diào)度。流中的分組被分類并添加到三個可用優(yōu)先級隊列中的一個。調(diào)度器對數(shù)據(jù)包進(jìn)行出隊，并根據(jù)隊列的優(yōu)先級將每個數(shù)據(jù)包發(fā)送到容器。同時，該調(diào)度策略通過對每個優(yōu)先級類的流執(zhí)行隨機排隊規(guī)則，使得每個優(yōu)先級內(nèi)各容器能夠依次發(fā)送數(shù)據(jù)，保證流傳輸?shù)墓叫?。此外，該調(diào)度策略增加了一個限制容器發(fā)送數(shù)據(jù)包速率的功能，通過這個功能，就可以為容器分配精確的網(wǎng)絡(luò)上下限，限制容器的網(wǎng)絡(luò)占用，實現(xiàn)更好的資源調(diào)度。

McDaniel等［7］對于容器的 I/O爭用提出了一種擴展Docker和Docker swarm的雙層方法(即在集群和節(jié)點級別)，使得它們能夠監(jiān)視和控制Docker容器的I/O。在節(jié)點級，通過設(shè)置容器的優(yōu)先級來分配給容器對應(yīng)比例的I/O;而在集群級則通過對節(jié)點I/O資源的使用分析，實現(xiàn)更好的負(fù)載平衡。

Monsalve等［8］通過將時間切片的概念擴展到虛擬化容器的級別來解決計算資源過度使用的問題。他們使用觀察決定法(Observe Decide Act，ODA)控制循環(huán)來擴展Docker，實現(xiàn)了一個簡單的roundrobin時間切片策略。他們?yōu)閱蝹€容器保留整個系統(tǒng)的CPU資源，然后每個容器只運行一段時間間隔。這種類型的策略在容器級別具有與組調(diào)度相同的優(yōu)點。

以上調(diào)度方式都只針對某一資源作了優(yōu)化，應(yīng)用在對此資源偏重的負(fù)載下能起到不錯的優(yōu)化作用，但是也存在著問題，優(yōu)化都是針對于節(jié)點內(nèi)部的，在集群的角度，沒有根據(jù)應(yīng)用的資源偏重，將不同偏重的應(yīng)用混合放在一個節(jié)點上，來從源頭上減少資源爭用的開銷。

為了改善Docker集群的資源調(diào)度，盧勝林等［5］提出了另外一種基于Docker swarm集群的容器加權(quán)調(diào)度策略。通過對節(jié)點分配和消耗資源的分析，計算出節(jié)點權(quán)值，然后將新的容器部署在低權(quán)值的節(jié)點上，以實現(xiàn)集群的負(fù)載均衡。在這種調(diào)度策略下，系統(tǒng)統(tǒng)計了4項參數(shù)指標(biāo)。針對不同的集群，對參數(shù)分配以不同的權(quán)重，以適應(yīng)不同側(cè)重的應(yīng)用系統(tǒng)，大大改善了Docker swarm的集群調(diào)度策略;然而，這種調(diào)度策略雖然改善了Docker集群的負(fù)載均衡問題，但并沒有對應(yīng)用的資源偏重進(jìn)行分析，因為對于集群來說，很難保證各個服務(wù)的資源偏重會和已經(jīng)分配的權(quán)重吻合，這樣就存在很大可能當(dāng)前服務(wù)是CPU偏向的，但是被分配到內(nèi)存占用少的節(jié)點上。這樣結(jié)果就是某些節(jié)點權(quán)值高，但只有某項資源消耗很高，其余資源并沒有太多的占用。

在實際應(yīng)用中，許多工作使用了機器學(xué)習(xí)的算法，對系統(tǒng)應(yīng)用的資源需求進(jìn)行預(yù)測，從而提前進(jìn)行資源分配調(diào)度，讓資源在對應(yīng)時間段分配給不同的服務(wù)，從而實現(xiàn)資源的充分利用。

Kang等［9］提出了一種高效的異構(gòu)Docker容器資源管理策略，使用k-medoid算法、分割周圍類算法等方法，實現(xiàn)了工作負(fù)載能效感知的容器代理系統(tǒng)，并通過這個系統(tǒng)既降低了由運行容器應(yīng)用程序引起的能耗，又保證了系統(tǒng)性能。Calheiros等［10］提出了一個基于自回歸積分滑動平均模型(Autoregressive Integrated Moving Average model，ARIMA)的云計算負(fù)載預(yù)測模型，平均準(zhǔn)確率達(dá)到了91%。

機器學(xué)習(xí)的調(diào)度策略能夠?qū)崿F(xiàn)更加優(yōu)秀的資源利用，但是相對也更為復(fù)雜，需要依據(jù)具體的集群設(shè)計算法模型，對于大型的項目而言，其優(yōu)勢明顯;而對于簡單的集群則有些得不償失，因為機器學(xué)習(xí)算法需要有足夠樣本的訓(xùn)練集，對于容器集群，則需要收集大量的時間序列的容器資源使用量，有著不小的存儲和計算開銷。

因此本文綜合考慮服務(wù)對資源的偏向以及節(jié)點上資源利用情況，提出了一種動態(tài)加權(quán)調(diào)度算法。該算法能根據(jù)服務(wù)對資源的偏向性，動態(tài)調(diào)整資源權(quán)重，由資源利用率和權(quán)重計算出代表節(jié)點負(fù)載的權(quán)值，以此來進(jìn)行調(diào)度。該算法既能實現(xiàn)更準(zhǔn)確的資源調(diào)度，也避免了機器學(xué)習(xí)調(diào)度帶來的巨大開銷。

1 Docker的資源調(diào)度策略

1．1 Docker整體架構(gòu)

Docker整體是一個 C/S模式的架構(gòu)［11］，而 Docker的后端屬于松耦合架構(gòu)，這使得Docker的各個模塊相對獨立，不會因為對于某些模塊的修改或者添加模塊對其余模塊造成很大影響，因此，在對Docker源代碼進(jìn)行相關(guān)改動，修改添加功能時，不會對其他功能造成太大影響。

Docker主要由Docker Client和Docker Daemon兩部分組成，兩者通過相互通信協(xié)作，共同實現(xiàn)Docker系統(tǒng)的功能，進(jìn)行容器管理。

Client主要負(fù)責(zé)用戶交互，通過用戶指令與Daemon通信，顯示Daemon的執(zhí)行信息;Daemon屬于主要執(zhí)行模塊，Docker的容器管理和集群管理等大部分功能都在該部分實現(xiàn)。

1．2 Docker swarm的資源調(diào)度

Docker swarm提供了 Random(隨機)、Spread(擴散)和Binpack(裝箱)三種資源調(diào)度的方法［12］:Random調(diào)度策略隨機選擇容器的部署位置，這種調(diào)度顯然問題很大，一般只用于集群的測試;Spread調(diào)度策略，按照各節(jié)點總內(nèi)存和CPU內(nèi)核數(shù)來部署容器，這樣能夠讓容器相對均勻地分散在每一個節(jié)點上;Binpack調(diào)度策略，先把一個節(jié)點的資源使用完后再向別的節(jié)點部署容器，這種調(diào)度方式可以盡可能地使用每個節(jié)點的資源，節(jié)省未啟動節(jié)點的資源。

Docker swarm自帶的這三種資源調(diào)度方式，可以滿足一些對集群的工作效率要求不是很高的應(yīng)用，但是對于有些應(yīng)用(如云平臺)，需要充分使用集群的整體性能，其對于負(fù)載均衡、資源利用率要求會比較高。在這些情況下，Docker swarm自帶的調(diào)度策略則存在明顯的不足。

首先，Docker swarm主要根據(jù)各個節(jié)點的全部內(nèi)存大小這一參數(shù)來分配任務(wù)。因為對于Docker容器來說，內(nèi)存資源是可以準(zhǔn)確統(tǒng)計的，但是對于CPU的資源分配則只能指定內(nèi)核數(shù)或者指定使用的權(quán)重大小，并不能準(zhǔn)確統(tǒng)計CPU的使用情況。

然后，Docker swarm并沒有考慮每個節(jié)點實際的可用資源，以及分配出去的資源使用情況。例如，Docker swarm所存儲的節(jié)點內(nèi)存總量來自節(jié)點計算機的內(nèi)存總量，但是在節(jié)點機器自身運行操作系統(tǒng)和軟件都是會占用內(nèi)存的，這導(dǎo)致節(jié)點實際可用內(nèi)存會比Docker swarm所統(tǒng)計的要少。此外，一般情況下，為了應(yīng)用能夠穩(wěn)定運行，都會為應(yīng)用分配足夠多的資源，但是實際上，大多時候應(yīng)用都不是在以最高的負(fù)載在運行，而且CPU、內(nèi)存、網(wǎng)絡(luò)等也不會同時處在最高負(fù)載，這樣分配的資源很多時候都不會用盡，而Docker swarm并不會對未使用的資源重新分配，造成了資源的浪費。

2 動態(tài)加權(quán)資源調(diào)度策略

加權(quán)調(diào)度算法采取以下的計算方式，選擇4項參數(shù):CPU使用率N(c)、內(nèi)存使用率N(m)、網(wǎng)絡(luò)負(fù)載N(n)和已分配內(nèi)存的平均使用率N(u)。使用W(k)代表節(jié)點k的總權(quán)值來反映節(jié)點負(fù)載，權(quán)值越高，說明節(jié)點負(fù)載越高。k1、k2、k3、k4來代表4項參數(shù)初始所占權(quán)重。為了解決某參數(shù)值偏大而總權(quán)值不高無法準(zhǔn)確反映節(jié)點負(fù)載的情況，引入α、β、γ三項參數(shù)進(jìn)行權(quán)值調(diào)整。α、β、γ 原值為1，當(dāng) N(c)、N(m)、N(n) 有一項超過0．8后，增大對應(yīng)α、β、γ的值為h(h＞1)，通過增大該項資源權(quán)值以修正節(jié)點權(quán)值，更確切地反映節(jié)點負(fù)載。節(jié)點k權(quán)值計算公式如式(1)所示:

W(k)=k1αN(c)+k2βN(m)+k3γN(n)+k4N(u) (1)

但是為了實現(xiàn)更好的節(jié)點資源利用和負(fù)載均衡，需要避免出現(xiàn)某項資源利用率過高而其余資源利用較低的情況，在加權(quán)調(diào)度算法的基礎(chǔ)上對調(diào)度策略進(jìn)行優(yōu)化。

普通的加權(quán)調(diào)度算法會出現(xiàn)節(jié)點資源使用不平衡的情況，主要是沒有考慮到實際的服務(wù)占各類資源的比重和集群設(shè)定的資源權(quán)重不是一直近似的。因此針對這類特定服務(wù)，需要對權(quán)重進(jìn)行重新調(diào)整。引入新的參數(shù)bias，當(dāng)創(chuàng)建的服務(wù)對資源的需求權(quán)重和集群分配的權(quán)重近似時，設(shè)置bias為空值;當(dāng)兩者權(quán)重不相近時，通過指令對這兩個參數(shù)進(jìn)行動態(tài)調(diào)節(jié)。

例如當(dāng)前集群的CPU資源權(quán)重為0．4，內(nèi)存資源權(quán)重為0．6，而新創(chuàng)建的服務(wù)對CPU資源需求比較高，如果按照原本的權(quán)重進(jìn)行調(diào)度，因為內(nèi)存資源占比重較大，所以這個服務(wù)很可能被分配到一個內(nèi)存剩余資源比較多的節(jié)點上面去，但是這個節(jié)點的CPU資源未必是豐富的。這時通過參數(shù)bias告訴系統(tǒng)當(dāng)前應(yīng)用服務(wù)對CPU資源需求高，將CPU的權(quán)值調(diào)整為2×0．4，這樣最終CPU資源與內(nèi)存資源的比重就會變?yōu)?∶6，只針對于這個服務(wù)而言，本次調(diào)度會把其分配到一個CPU資源充分的節(jié)點上。這樣不僅能夠?qū)m合集群資源偏向的普通服務(wù)進(jìn)行調(diào)度，對于那些資源偏向特殊的服務(wù)，也能實現(xiàn)良好的負(fù)載均衡。

改進(jìn)后的節(jié)點k權(quán)值計算公式如式(2)所示，b1、b2、b3代表創(chuàng)建服務(wù)時指定的對應(yīng)資源的偏向性，在創(chuàng)建服務(wù)時由用戶指定，會直接和權(quán)重相乘。其他參數(shù)同式(1)。

W(k)=b1k1αN(c)+b2k2βN(m)+b3k3γN(n)+k4N(u)

(2)

設(shè)計系統(tǒng)整體模塊如圖1，圖中陰影部分為需要增加或修改部分。其中:集群資源獲取模塊，為自行設(shè)計實現(xiàn);指令相關(guān)模塊在原本的基礎(chǔ)上修改添加部分功能;而Filter模塊和Scheduler模塊則在源代碼的基礎(chǔ)上進(jìn)行修改。

指令相關(guān)模塊，通過接口函數(shù)調(diào)用相關(guān)服務(wù)，實現(xiàn)對系統(tǒng)的調(diào)用和控制;Swarmkit接口模塊，屬于指令模塊的一部分，通過添加指令參數(shù)和接口函數(shù)，實現(xiàn)新指令對服務(wù)的調(diào)用的通道;集群資源獲取模塊，結(jié)合原節(jié)點管理模塊，通過節(jié)點資源獲取模塊和TCP通信，將各個節(jié)點信息發(fā)送到主節(jié)點，實現(xiàn)對集群資源信息的獲取;調(diào)度相關(guān)模塊中，Event進(jìn)行事件監(jiān)測，觸發(fā)事件后通過集群資源獲取模塊獲取集群節(jié)點資源信息，而后Filter模塊進(jìn)行節(jié)點過濾，Schedule模塊在過濾后的可用節(jié)點上進(jìn)行服務(wù)部署，完成調(diào)度。

權(quán)值的計算主要包括3部分。首先，通過集群資源獲取模塊收集集群資源信息;然后，將獲取到的資源信息按照發(fā)送規(guī)則進(jìn)行解析，同時依據(jù)資源利用情況進(jìn)行權(quán)重調(diào)整:當(dāng)資源利用率達(dá)到0．8后，對權(quán)重進(jìn)行自動調(diào)整，提升權(quán)值，從而提升節(jié)點的權(quán)值，防止單項資源占用過高，而整體權(quán)值較低不能反映節(jié)點實際負(fù)載;另外，根據(jù)指令參數(shù)bias，主動調(diào)整資源權(quán)重，針對一些對資源有明顯偏向性的服務(wù)，可以將服務(wù)分配到需求資源最充足的節(jié)點上。

Docker在Scheduler模塊下用函數(shù)聲明了節(jié)點調(diào)整規(guī)則和任務(wù)部署規(guī)則。內(nèi)容如下:首先判斷兩個節(jié)點在規(guī)定時間內(nèi)的失敗次數(shù)，如果有節(jié)點失敗次數(shù)達(dá)到了規(guī)定的失敗上限，就優(yōu)先返回失敗次數(shù)少的節(jié)點，但是如果兩個節(jié)點失敗次數(shù)相同，就執(zhí)行后續(xù)的比較;然后比較節(jié)點上運行的當(dāng)前服務(wù)的任務(wù)數(shù)量，優(yōu)先調(diào)度當(dāng)前運行任務(wù)量少的節(jié)點，如果兩節(jié)點任務(wù)數(shù)量仍然相同，則比較兩個節(jié)點運行的任務(wù)總數(shù)，優(yōu)先調(diào)度總?cè)蝿?wù)量少的節(jié)點。如果任務(wù)總量仍然相同，就返回false調(diào)度當(dāng)前節(jié)點，在完成本次調(diào)度后，當(dāng)前節(jié)點服務(wù)對應(yīng)任務(wù)數(shù)量就會超過下一個節(jié)點，在下次調(diào)度時就會優(yōu)先使用后續(xù)節(jié)點。而動態(tài)加權(quán)調(diào)度算法則是將原本以運行任務(wù)總量為依據(jù)的判斷改為以權(quán)值大小為判斷依據(jù)。

相對Docker swarm提供的調(diào)度策略而言，優(yōu)化的動態(tài)加權(quán)調(diào)度算法存在以下優(yōu)勢:

首先，增加了集群節(jié)點資源獲取的功能，所以在進(jìn)行節(jié)點過濾時，可以根據(jù)實際資源利用情況選出滿足資源需求的節(jié)點，避免了因為節(jié)點分配的資源沒有完全使用而造成浪費。

其次，因為對調(diào)度策略進(jìn)行了改進(jìn)，綜合考慮各項資源利用情況，在將任務(wù)分配到節(jié)點時，會根據(jù)節(jié)點實際資源使用率進(jìn)行分配，使得最終各個節(jié)點的資源使用率相對接近，實現(xiàn)了更好的負(fù)載均衡。

最后，通過參數(shù)bias對資源占用權(quán)重進(jìn)行動態(tài)調(diào)整，這樣在部署某些對資源需求比較特殊的服務(wù)時，也能夠通過改變資源權(quán)重，將服務(wù)分配到對應(yīng)資源豐富的節(jié)點上，實現(xiàn)節(jié)點各項資源使用的相對平衡，充分使用了集群的資源。

3 實驗與結(jié)果

3．1 測試平臺搭建

本次測試在一臺物理機創(chuàng)建兩個ubuntu虛擬機作為子節(jié)點，將本機作為管理節(jié)點，這樣一共3臺計算機，構(gòu)成了一個簡單的集群。各節(jié)點信息如表1。

表1 集群節(jié)點信息Tab．1 Information of nodes in cluster

3．2 服務(wù)調(diào)度測試

分別對Docker的原本調(diào)度策略、無參數(shù)調(diào)整的加權(quán)調(diào)度策略和動態(tài)加權(quán)調(diào)度策略3種調(diào)度方式進(jìn)行測試，統(tǒng)計各個節(jié)點的CPU資源和內(nèi)存使用情況，來分析各調(diào)度策略的優(yōu)劣。

在調(diào)度開始之前，查看當(dāng)前節(jié)點的資源利用狀況，如表2。其中節(jié)點Manager的權(quán)值明顯高于其余兩個節(jié)點，是因為這個節(jié)點是本機，運行著虛擬機和其他的各種軟件，所以資源占用一開始就高，不過這樣反而更能測試調(diào)度策略的資源調(diào)度能力。

測試分為A、B兩組進(jìn)行，在A、B兩組各部署30個服務(wù):其中A組部署了20個CPU偏向的應(yīng)用服務(wù)，10個內(nèi)存偏向的應(yīng)用服務(wù)，這個集群對CPU的資源需求更高;而B組部署10個CPU偏向的應(yīng)用服務(wù)，20個內(nèi)存偏向的應(yīng)用服務(wù)，該集群對內(nèi)存資源的需求更高。

表2 節(jié)點初始資源信息Tab．2 Information of nodes initial resources

因為集群的調(diào)度結(jié)果和應(yīng)用服務(wù)部署順序有關(guān)，所以在A、B兩組內(nèi)分別按照不同順序?qū)Ψ?wù)進(jìn)行兩次部署，避免部署順序?qū)е碌呐既恍裕@樣一共進(jìn)行4組對比實驗。具體測試應(yīng)用服務(wù)部署如表3。

3．3 調(diào)度結(jié)果分析

3．3．1 A 組測試結(jié)果分析

3種調(diào)度策略的A-1組和A-2組測試數(shù)據(jù)如表4，5所示。可以發(fā)現(xiàn)，不論是在A-1組的測試還是A-2組測試，動態(tài)加權(quán)調(diào)度策略的CPU使用率和內(nèi)存使用率都更加均衡，優(yōu)于Docker的調(diào)度策略和普通加權(quán)調(diào)度策略。

表3 應(yīng)用服務(wù)測試部署順序Tab．3 Order of deployment

3．3．2 B 組測試結(jié)果分析

3種調(diào)度策略的B-1組和B-2組測試數(shù)據(jù)如表6，7所示?？梢钥闯觯瑒討B(tài)加權(quán)調(diào)度策略的調(diào)度結(jié)果資源使用率最均衡。Docker原調(diào)度和普通加權(quán)調(diào)度策略都出現(xiàn)了節(jié)點內(nèi)存資源占用超過0．8，然而優(yōu)化的調(diào)度策略內(nèi)存使用率都保持在0．6～0．7，避免了節(jié)點負(fù)載過重，優(yōu)化了資源利用。

表4 A-1組測試結(jié)果Tab．4 Test results of group A-1

表5 A-2組測試結(jié)果Tab．5 Test results of group A-2

表6 B-1組測試結(jié)果Tab．6 Test results of group B-1

表7 B-2組測試結(jié)果Tab．7 Test results of group B-2

3．3．3 服務(wù)運行速度的影響

從上述測試可以看出，優(yōu)化的調(diào)度策略實現(xiàn)了更優(yōu)秀的資源負(fù)載均衡，然而為了證明新的調(diào)度策略不會對服務(wù)的運行速度產(chǎn)生負(fù)面影響，進(jìn)行服務(wù)運行速度測試。

編寫兩個循環(huán)計算程序作為兩個子服務(wù)，一個控制程序作為主服務(wù)。兩個計算程序在完成計算后，將計算時間發(fā)送到主服務(wù)，只有在兩個計算都完成之后，才算完成了完整的服務(wù)。通過這樣的測試程序來測試調(diào)度策略對服務(wù)整體運行速度的影響。

當(dāng)集群資源充足時，難以看出服務(wù)執(zhí)行速度的差異。因此，在進(jìn)行服務(wù)速度測試前，先按照各調(diào)度策略在集群上部署10個內(nèi)存偏向的服務(wù)和30個CPU偏向的服務(wù)，提高集群的CPU使用率，然后再進(jìn)行測試服務(wù)的部署。

對40個服務(wù)的不同部署導(dǎo)致的節(jié)點資源利用狀況，分別對3種調(diào)度策略進(jìn)行測試，結(jié)果如表8。

表8 各調(diào)度策略的服務(wù)運行時間測試表 s Tab．8 Operating time of 3 scheduling strategies s

當(dāng)存在多個子服務(wù)時，服務(wù)的運行速度取決于最慢的那個子服務(wù)。從表8中數(shù)據(jù)得知，動態(tài)加權(quán)調(diào)度策略的服務(wù)執(zhí)行速度最快，而無參數(shù)調(diào)整的動態(tài)加權(quán)調(diào)度策略服務(wù)執(zhí)行卻最慢。這主要是因為節(jié)點ubuntu01的內(nèi)存使用率較低，在考慮節(jié)點整體權(quán)值的情況下，該節(jié)點被分配了更多的CPU偏向的服務(wù)，最終導(dǎo)致同樣對CPU資源需求量高的子服務(wù)1運行變慢，拖慢了整體服務(wù);而動態(tài)加權(quán)調(diào)度策略，各個節(jié)點資源利用率相對平均，因此子服務(wù)執(zhí)行時間相差不大，服務(wù)總運行時間最短;而Docker原調(diào)度策略以平均分配容器的方式進(jìn)行調(diào)度，由于節(jié)點ubuntu01和節(jié)點ubuntu02的CPU資源總量相同，因此最終這兩個節(jié)點的資源占用反而比較相近，使得兩個子服務(wù)運行速度沒有太大差異，最終服務(wù)運行速度居中。

3．3．4 測試結(jié)論

A組和B組的測試結(jié)果與調(diào)度策略相吻合。Docker原本依據(jù)各節(jié)點容器數(shù)量進(jìn)行調(diào)度，因此各個節(jié)點容器數(shù)量相同，但是因為沒有考慮節(jié)點資源情況，導(dǎo)致節(jié)點間的資源利用率不平衡。

對于無參數(shù)調(diào)整的加權(quán)調(diào)度策略，嚴(yán)格按照節(jié)點總權(quán)值進(jìn)行調(diào)度，忽視了具體任務(wù)對資源的實際需求，因此，在B組測試中出現(xiàn)了明顯的節(jié)點各項資源利用不均衡，其總權(quán)值是通過兩項資源互相補充實現(xiàn)了相對均衡，而且在B-2組測試中出現(xiàn)了內(nèi)存資源利用過高導(dǎo)致的CPU資源浪費。對于動態(tài)加權(quán)調(diào)度策略，由于在創(chuàng)建對資源有偏向性的服務(wù)時，通過參數(shù)bias調(diào)整了對應(yīng)資源的權(quán)重，使得系統(tǒng)在節(jié)點負(fù)載相差不大的情況下，優(yōu)先將服務(wù)部署在所需資源充足的節(jié)點上，這樣避免節(jié)點出現(xiàn)某項資源利用過高而另外資源利用很低的情況，在A組和B組測試中，優(yōu)化了資源的均衡利用。

同時，通過對具體服務(wù)的運行速度進(jìn)行測試，發(fā)現(xiàn)優(yōu)化的調(diào)度策略在集群負(fù)載比較高的情況下，實現(xiàn)了最快的服務(wù)運行速度。

總體而言，本次的調(diào)度策略優(yōu)化是比較成功的，實現(xiàn)了預(yù)期的目標(biāo)，相比Docker原本的調(diào)度和無參數(shù)調(diào)整的加權(quán)調(diào)度，無論是對CPU資源需求多的集群，還是內(nèi)存資源需求資源多的集群，在不同的調(diào)度順序下都實現(xiàn)了更好的負(fù)載均衡和資源利用。

4 結(jié)語

本文提出了一種優(yōu)化的動態(tài)加權(quán)調(diào)度算法。該算法在集群調(diào)度時，既綜合考慮CPU、內(nèi)存、網(wǎng)絡(luò)各項資源負(fù)載，又實現(xiàn)了節(jié)點各項資源的均衡利用，避免了單項資源使用率過高造成的資源浪費，提高了資源使用率。實驗結(jié)果表明，本文提出的動態(tài)加權(quán)算法無論在CPU資源需求高的集群服務(wù)還是內(nèi)存需求高的集群服務(wù)，優(yōu)化的調(diào)度策略都能實現(xiàn)比Docker原調(diào)度策略和普通加權(quán)調(diào)度策略更優(yōu)的集群負(fù)載均衡和資源利用，并且對正常服務(wù)運行時間的影響最小。