一種適用于Docker Swarm集群的調(diào)度策略和算法

馬曉光 劉釗遠(yuǎn)

(西安郵電大學(xué)計算機(jī)學(xué)院 陜西 西安 710061)

一種適用于Docker Swarm集群的調(diào)度策略和算法

馬曉光 劉釗遠(yuǎn)

(西安郵電大學(xué)計算機(jī)學(xué)院 陜西 西安 710061)

Swarm是基于Docker容器的集群管理工具。通過分析研究Swarm整體架構(gòu)和調(diào)度策略，針對集群的資源碎片問題和負(fù)載均衡問題，提出一種靜態(tài)平衡和動態(tài)預(yù)測相結(jié)合的容器調(diào)度算法。通過測試，該算法能夠減少集群的靜態(tài)資源碎片，提高集群資源的利用率，并能維持集群的負(fù)載均衡。

云計算 資源碎片 負(fù)載均衡 Docker容器 Swarm

0 引 言

Docker[1-4]自開源以來，就受到了廣泛的關(guān)注和討論，由于眾多新穎的特性以及項目本身的開放性，Docker迅速獲得包括Google、Microsoft、VMware等業(yè)界行業(yè)領(lǐng)導(dǎo)者的青睞，并對其提供支持。Docker公司隨之迎來了巨大的發(fā)展機(jī)遇，并在2014年12月發(fā)布了原生態(tài)容器集群管理工具Swarm。Swarm基于Go語言進(jìn)行開發(fā)，用于管理Docker集群，使Docker集群對于用戶而言當(dāng)于一個虛擬的整體。

Docker在云生態(tài)中占有重要地位， Swarm在云架構(gòu)PaaS(平臺及服務(wù))/IaaS(基礎(chǔ)設(shè)施及服務(wù))層中也占有重要地位。Swarm主要完成的工作是：根據(jù)調(diào)度策略將容器運行在合適的節(jié)點上，由于節(jié)點上運行容器的不同，其資源利用率也有所差別。而每個節(jié)點的資源利用率又決定了整個集群的負(fù)載情況。因此，集群調(diào)度策略的優(yōu)略就顯得尤為重要。

不同的容器需求不同維度的資源，當(dāng)一個節(jié)點任意維度的資源耗盡時，如果有多維資源需求的容器被啟動，那么該節(jié)點將不能滿足創(chuàng)建容器的需求，也就不能運行此容器。在這種情況下，其他維度的剩余資源就被閑置了下來，而這些未被利用的資源就稱為資源碎片[5-6]，這是一種極大的浪費。所以，就需要減少資源碎片的大小。同時，集群整體負(fù)載的均衡情況決定了集群在服務(wù)時的整體表現(xiàn)，為了提高集群的服務(wù)質(zhì)量，需要保證整個集群的負(fù)載均衡。

本文分析研究了Swarm的整體架構(gòu)和調(diào)度策略，提出一種靜態(tài)平衡和動態(tài)預(yù)測相結(jié)合的容器調(diào)度算法。通過測試，本算法能夠減少節(jié)點的靜態(tài)資源碎片，維持整個集群的負(fù)載均衡。

1 Swarm集群框架與調(diào)度策略

1.1 Swarm架構(gòu)

Swarm采用了C/S架構(gòu)，Swarm主要架構(gòu)如圖1所示。

圖1 Swarm架構(gòu)

Docekr Client是客戶端，負(fù)責(zé)發(fā)送指令，Swarm master是服務(wù)器端，負(fù)責(zé)管理整個集群。Swarm集群分為Swarm Node和Docker Node。

Swarm master運行在Swarm node上，主要工作是完成調(diào)度任務(wù)和管理集群。用戶通過Swarm Client初始化集群各個模塊并管理集群，discovery模塊負(fù)責(zé)發(fā)現(xiàn)集群的節(jié)點并收集信息，scheduler模塊負(fù)責(zé)容器請求的調(diào)度任務(wù)，Cluster API定義了集群接口，是實際任務(wù)的完成者，leadship是Swarm的HA(高可用性)機(jī)制。

Docker Node是指運行Docker Daemon的節(jié)點。Docker Daemon根據(jù)Swarm master的任務(wù)啟動相應(yīng)容器。Docker Node通過Swarm Agent向管理節(jié)點注冊信息，以便管理節(jié)點在執(zhí)行任務(wù)的時候可以發(fā)現(xiàn)該節(jié)點。

1.2 Swarm調(diào)度策略及資源碎片問題

Swarm的scheduler模塊分為filter組件和strategy組件。filter組件通過標(biāo)簽對節(jié)點進(jìn)行過濾。用戶在創(chuàng)建集群時，需要根據(jù)節(jié)點的不同功能給與節(jié)點不同的標(biāo)簽，用戶一旦啟動容器，scheduler會根據(jù)用戶提供的標(biāo)簽，過濾出匹配標(biāo)簽的節(jié)點集合供strategy組件處理。

strategy組件對集群提供邏輯調(diào)度功能。主要有以下三種策略：spread、binpack和random。用戶選擇的策略將會決定集群如何計算節(jié)點的權(quán)重，集群默認(rèn)使用spread策略。其中random策略用來對程序進(jìn)行測試，僅對節(jié)點進(jìn)行隨機(jī)選擇；spread和binpack策略首先計算節(jié)點的權(quán)重，然后選擇合適的節(jié)點運行容器。

節(jié)點權(quán)重的計算策略為：首先根據(jù)用戶申請的容器配制信息計算CPU和內(nèi)存的利用率，并將其結(jié)果求和，隨后，spread策略會優(yōu)先選擇權(quán)重小的節(jié)點運行容器，而binpack會優(yōu)先選擇權(quán)重大的節(jié)點運行容器。前者的優(yōu)點是，如果節(jié)點出現(xiàn)故障，將會損失少量的容器。后者的優(yōu)點是將更多的容器運行在較少的機(jī)器上，節(jié)省物理資源。

盡管swarm調(diào)度策略簡單而有效，但是其忽略了一個重要問題，資源碎片問題。由于不同的容器需求不同維度的資源，當(dāng)一個節(jié)點的任意維度資源耗盡時，如果有多維資源需求的容器被啟動，那么該節(jié)點將不能滿足創(chuàng)建容器的需求，也就不能運行此容器。在這種情況下，其他維度的剩余資源就被閑置了下來，而這些未被利用的資源就被稱為資源碎片，這是一種極大的浪費。所以就需要減少資源碎片的大小來提高節(jié)點的資源利用率。

同時Swarm在計算節(jié)點優(yōu)先級時，由于計算方法的簡單，隨著集群的規(guī)模的擴(kuò)大，就會產(chǎn)生相同優(yōu)先級的節(jié)點。現(xiàn)有的容器調(diào)度策略只是對相同優(yōu)先級的節(jié)點進(jìn)行了隨機(jī)的分配，并沒有對相同優(yōu)先級節(jié)點進(jìn)行再次比較，但是，容器在運行時是動態(tài)地申請節(jié)點上的資源，這會造成在實際運行環(huán)境中，集群負(fù)載的不均衡。由于集群整體負(fù)載的均衡情況決定了集群在服務(wù)時的整體表現(xiàn)，相同優(yōu)先級節(jié)點的資源負(fù)載并不相同，因此，用戶體驗也不相同，這就降低了集群提供服務(wù)的質(zhì)量。

2 Swarm調(diào)度策略的優(yōu)化

根據(jù)上述情況，本文提出了靜態(tài)資源平衡和動態(tài)資源預(yù)測的策略對Swarm調(diào)度策略進(jìn)行優(yōu)化。

2.1 靜態(tài)資源平衡策略

多維資源的存在引發(fā)了資源碎片的問題。由1.2節(jié)可知，在一個滿負(fù)載的節(jié)點上，資源碎片顯然存在，節(jié)點資源分配是否平衡則關(guān)系到資源碎片的大小。為了減小資源碎片，需要改進(jìn)Swarm現(xiàn)有調(diào)度策略，在集群分配容器時，需要度量容器分配后多維資源的平衡情況，從而選擇平衡情況最好的節(jié)點啟動容器。

2.2 動態(tài)資源調(diào)度策略

雖然靜態(tài)資源平衡策略考慮了靜態(tài)資源碎片的問題。但是，并沒有考慮資源動態(tài)的變化問題，容易造成集群負(fù)載不均的情況。因此，根據(jù)這種情況，需要在靜態(tài)平衡策略的基礎(chǔ)上增加動態(tài)調(diào)度策略作為補(bǔ)充。分析Swarm整體架構(gòu)，其中并沒有提供動態(tài)收集節(jié)點信息的模塊，這就需要增加此模塊實現(xiàn)動態(tài)資源調(diào)度策略，修改后Swarm框架如圖2所示。

圖2 動態(tài)資源調(diào)度框架

首先在Swarm中添加receiver模塊，供scheduler模塊調(diào)用，receiver模塊用來接收monitor模塊傳輸?shù)墓?jié)點實時預(yù)測信息。monitor模塊運行在每個節(jié)點上，實時監(jiān)控節(jié)點多維資源的使用情況。由于每個節(jié)點資源使用情況會隨著時間產(chǎn)生不同的波動。僅僅提供當(dāng)前節(jié)點信息并不能代表節(jié)點資源的實際使用情況。所以需要研究監(jiān)控節(jié)點的變化趨勢和時間關(guān)系，可以有效地預(yù)測出未來節(jié)點的資源使用情況，完成調(diào)度功能。

3 算法的設(shè)計與實現(xiàn)

3.1 優(yōu)化調(diào)度算法的設(shè)計流程

總結(jié)上述策略，本文提出靜態(tài)動態(tài)相結(jié)合和的優(yōu)化調(diào)度算法，該算法流程如圖3所示。

圖3 優(yōu)化調(diào)度算法流程

(1) scheduler模塊獲取申請容器的配制信息。

(2) 靜態(tài)資源平衡算法計算靜態(tài)權(quán)值。

(3) receiver模塊獲取monitor模塊動態(tài)預(yù)測的節(jié)點的信息。

(4) scheduler模塊獲取receiver模塊的節(jié)點信息，計算動態(tài)權(quán)值。

(5) scheduler模塊根據(jù)靜態(tài)權(quán)值對節(jié)點排序。

(6) scheduler模塊對靜態(tài)權(quán)值相等的節(jié)點根據(jù)動態(tài)權(quán)值進(jìn)行二次排序。

(7) scheduler模塊選擇權(quán)值最小的節(jié)點分配容器。

3.2 靜態(tài)資源平衡算法

這里通過計算CPU資源和內(nèi)存資源之間的方差來度量節(jié)點資源的平衡情況。因為方差度量了一組數(shù)據(jù)的離散程度。方差越小代表這組數(shù)據(jù)越穩(wěn)定，反之，則越不穩(wěn)定。

靜態(tài)資源平衡算法如下：

設(shè)節(jié)點的資源維度為D[1,2,…,d]，節(jié)點已分配的資源為U[u1,u2…,ud]，節(jié)點的資源總量為T[t1,t2,…,td]，節(jié)點即將分配的資源為P[p1,p2,…,pd]，節(jié)點的資源利用率R[r1,r2,…,rd]。

當(dāng)用戶向集群申請一個容器。首先集群調(diào)度模塊獲取容器的配制信息，使用式(1)計算出每個節(jié)點在分配此容器后的靜態(tài)資源利用率。

(1)

然后使用式(2)計算每個節(jié)點的平均資源利用率：

(2)

最后使用式(3)計算每個節(jié)點的CPU資源和內(nèi)存資源的方差S2，方差即為節(jié)點的靜態(tài)權(quán)值：

(3)

3.3 動態(tài)資源調(diào)度算法

1) 預(yù)測模型的選取

在選取預(yù)測算法時，需要考慮預(yù)測模型是否能夠反映節(jié)點負(fù)載的真實情況，同時又要求算法應(yīng)具有較小的時間復(fù)雜度[7]。由于Swarm是基于Docker的原生態(tài)集群，其Docker輕量級和便攜性的優(yōu)勢在Swarm中體現(xiàn)的非常突出。通過綜合考量，應(yīng)該避免使用時間復(fù)雜度高的高次曲線對節(jié)點負(fù)載情況進(jìn)行模擬，以免過度消耗集群的整體資源，削弱Swarm集群的整體表現(xiàn)?；谏鲜鲈颍疚牟捎没疑Ｐ虶M(1,1)[8-9]對節(jié)點的狀態(tài)變化進(jìn)行模擬預(yù)測。

灰色系統(tǒng)理論是鄧聚龍在1982年創(chuàng)立的一門新興橫斷學(xué)科，它以“部分信息已知，部分信息未知”的“小樣本”、“貧信息”不確定性系統(tǒng)為研究對象，主要通過對部分已知信息的生成、開發(fā)，提取有價值的信息，實現(xiàn)對系統(tǒng)運行規(guī)律的正確認(rèn)識和確切描述，并據(jù)以進(jìn)行科學(xué)預(yù)測。其主要優(yōu)點包括以下幾點：需求樣本量小，樣本不需要有規(guī)律性分布，計算工作量小，定量分析結(jié)果與定性分析結(jié)果一致，預(yù)測準(zhǔn)確度高。

2) 基于灰色模型的節(jié)點負(fù)載預(yù)測

由于Swarm原有調(diào)度策略中只計算了CPU和內(nèi)存兩個維度的資源，因此這里假設(shè)節(jié)點的CPU利用率為Uc，內(nèi)存利用率為Um。首先通過monitor獲得節(jié)點的前n時刻的Uc={Uc(1),Uc(2),…,Uc(n)}和Um={Um(1),Um(2),…,Um(n)}后，采用GM(1，1)預(yù)測算法模擬，然后對n+1時刻的Uc和Um值進(jìn)行預(yù)測。計算方法如下：

步驟1 設(shè)時間序列x(0)={x(0)(1),x(0)(2),…,x(0)(n)}有n個原始值，使用式(4)通過一次累加生成新的序列x(1)={x(1)(1),x(1)(2),…,x(1)(n)}：

(4)

根據(jù)灰色預(yù)測方法，得出GM(1，1)模型相應(yīng)的微分方程為式(5)：

(5)

其中，α稱為發(fā)展灰數(shù)；μ稱為內(nèi)生成控制灰數(shù)。

(6)

(7)

Y=(x(0)(2),x(0)(3),…,x0(n))T

(8)

步驟3 求解微分方程，根據(jù)式(9)即可得預(yù)測模型：

(9)

步驟4 根據(jù)式(10)對預(yù)測模型值累減，得到預(yù)測值：

(10)

步驟5 精度檢驗，根據(jù)式(11)計算原始數(shù)據(jù)和預(yù)測數(shù)據(jù)的相對殘差：

(11)

3) 基于灰色模型的動態(tài)資源調(diào)度算法

步驟1 獲得當(dāng)前的CPU和內(nèi)存利用率的時間序列x(0)，并根據(jù)式(4)對其進(jìn)行一次累加計算，得到一次處理的數(shù)據(jù)序列x(1)。

步驟2 根據(jù)B和Y的計算公式(式(7)和式(8))，形成B矩陣和Y矩陣。

步驟3 對B和Y矩陣進(jìn)行矩陣運算，根據(jù)式(6)求出發(fā)展灰數(shù)α和內(nèi)生控制灰數(shù)μ。

步驟6 根據(jù)式(11)對預(yù)測模型進(jìn)行殘差檢驗，評估模型是否達(dá)到要求。

步驟7 對n+1時間節(jié)點的CPU和內(nèi)存預(yù)測值求和得出節(jié)點的動態(tài)權(quán)值。

4 實驗設(shè)計及結(jié)果分析

本實驗搭建2個Swarm集群，集群1使用Swarm1.0.1搭建，集群2使用修改后的Swarm1.01源碼包重新編譯并搭建。每個集群由3臺普通PC組成。其組成如表1所示。

表1 集群配制

由于實驗條件限制，現(xiàn)設(shè)計實驗如下：

實驗一 對兩個Swarm集群申請如表2序列容器。集群1算法為Swarm原算法，集群2算法為靜態(tài)資源平衡算法。每個集群容器的運行情況如表3所示。

表2 容器申請序列

表3 容器運行對比結(jié)果

圖4 集群資源碎片對比圖

由圖4可知，集群2中的靜態(tài)資源碎片相比集群1有明顯下降，由表3可知，集群2相比集群1可以多運行一個維度為[1,2]的容器。改進(jìn)算法能夠減少靜態(tài)資源碎片，增加資源的利用率。

實驗二 為方便計算，本文定義動態(tài)資源度量單位S=(Uc+Um)×100。每個節(jié)點的初始狀態(tài)如表4所示。

表4 節(jié)點初始狀態(tài)

本實驗通過在集群2上增加動態(tài)預(yù)測算法和靜態(tài)資源平衡算法作比較，表5為每個節(jié)點的運行容器的情況。本文通過模擬程序給予node1中單核滿負(fù)載，其他節(jié)點為初始狀態(tài)。同時，給予容器1、3和5號容器CPU滿載，2號容器CPU滿載并使用1GB的內(nèi)存，容器運行情況如表5所示。

表5 容器運行對比結(jié)果

集群負(fù)載對比情況如圖5所示。由圖5可知，靜態(tài)平衡算法會出現(xiàn)集群整體負(fù)載不均衡的情況，增加動態(tài)預(yù)測算法后，集群整體負(fù)載相對均衡。

圖5 集群負(fù)載均衡對比圖

總結(jié)上述實驗，優(yōu)化調(diào)度算法不僅可以減少集群的靜態(tài)資源碎片，提高資源利用率，而且可以均衡集群的動態(tài)負(fù)載。

5 結(jié) 語

Docker容器隨著其生態(tài)圈的完善，越來越受到大家的青睞。Swarm作為Docker的原生態(tài)集群管理工具也顯得更加重要。本文在分析Swarm集群框架和調(diào)度策略的基礎(chǔ)上，針對原有調(diào)度策略在解決靜態(tài)資源碎片問題上存在的不足，提出靜態(tài)平衡算法，并在此基礎(chǔ)上增加動態(tài)預(yù)測算法均衡集群的動態(tài)負(fù)載。實驗表明，優(yōu)化調(diào)度算法能改善集群資源碎片過多的問題，提高資源利用率，同時能夠均衡集群的動態(tài)負(fù)載。

[1] 楊保華,戴王劍,曹亞侖.Docker技術(shù)入門與實戰(zhàn)[M].北京:機(jī)械工業(yè)出版社,2015.

[2] 孫宏亮.Docker源碼分析[M].北京:機(jī)械工業(yè)出版社,2015.

[3]LiuD,ZhaoL.Theresearchandimplementationofcloudcomputingplatformbasedondocker[C]//2014 11thInternationalComputerConferenceonWaveletActiveMediaTechnologyandInformationProcessing,2014:475-478.

[4]BernsteinD.Containersandcloud:fromLXCtoDockertoKubernetes[J].IEEECloudComputing,2014,1(3):81-84.

[5]HuangW,LiX,QianZ.Anenergyefficientvirtualmachineplacementalgorithmwithbalancedresourceutilization[C]//2013SeventhInternationalConferenceonInnovativeMobileandInternetServicesinUbiquitousComputing(IMIS),2013:313-319.

[6]TsengHW,WuRY,ChangTS.AneffectiveVMmigrationschemeforreducingresourcefragmentsinclouddatacenters[C]//Proceedingsofthe2014ConferenceonResearchinAdaptiveandConvergentSystems,2014:320-325.

[7] 李丹程,王曉晨,宋曉雪,等.基于OpenStack的資源負(fù)載預(yù)測方法研究[J].計算機(jī)應(yīng)用研究,2014,31(7):2178-2182.

[8] 段峰,楊芬.灰色預(yù)測模型的研究及應(yīng)用[J].湘南學(xué)院學(xué)報,2008,29(2):17-21.

[9] 郭正紅,馬辛華,蘭安怡.基于層次分析法權(quán)重和灰色服務(wù)器負(fù)載預(yù)測的云計算on-line遷移策略[J].計算機(jī)測量與控制,2015,23(3):1002-1004,1007.

A SCHEDULING STRATEGY AND ALGORITHM FOR DOCKER SWARM CLUSTER

Ma Xiaoguang Liu Zhaoyuan

(SchoolofComputerScience,Xi’anUniversityofPostsandTelecommunications,Xi’an710061,Shaanxi,China)

Swarm is a cluster management tool based on the Docker container. Aiming at the problem of resource fragment and load balancing of cluster, container scheduling algorithm combining static balance and dynamic prediction is proposed by analyzing the overall structure and scheduling strategy of Swarm. Through testing, the algorithm can reduce the static resource fragment of the cluster, improve the utilization rate of the cluster resource, and maintain the cluster load balance.

Cloud computing Resource fragment Load balancing Docker container Swarm

2016-05-18。馬曉光，碩士生，主研領(lǐng)域：計算機(jī)技術(shù)。劉釗遠(yuǎn)，教授。

TP338.8

A

10.3969/j.issn.1000-386x.2017.05.049