馬曉光 劉釗遠(yuǎn)
(西安郵電大學(xué)計(jì)算機(jī)學(xué)院 陜西 西安 710061)
一種適用于Docker Swarm集群的調(diào)度策略和算法
馬曉光 劉釗遠(yuǎn)
(西安郵電大學(xué)計(jì)算機(jī)學(xué)院 陜西 西安 710061)
Swarm是基于Docker容器的集群管理工具。通過分析研究Swarm整體架構(gòu)和調(diào)度策略,針對集群的資源碎片問題和負(fù)載均衡問題,提出一種靜態(tài)平衡和動態(tài)預(yù)測相結(jié)合的容器調(diào)度算法。通過測試,該算法能夠減少集群的靜態(tài)資源碎片,提高集群資源的利用率,并能維持集群的負(fù)載均衡。
云計(jì)算 資源碎片 負(fù)載均衡 Docker容器 Swarm
Docker[1-4]自開源以來,就受到了廣泛的關(guān)注和討論,由于眾多新穎的特性以及項(xiàng)目本身的開放性,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)于一個(gè)虛擬的整體。
Docker在云生態(tài)中占有重要地位, Swarm在云架構(gòu)PaaS(平臺及服務(wù))/IaaS(基礎(chǔ)設(shè)施及服務(wù))層中也占有重要地位。Swarm主要完成的工作是:根據(jù)調(diào)度策略將容器運(yùn)行在合適的節(jié)點(diǎn)上,由于節(jié)點(diǎn)上運(yùn)行容器的不同,其資源利用率也有所差別。而每個(gè)節(jié)點(diǎn)的資源利用率又決定了整個(gè)集群的負(fù)載情況。因此,集群調(diào)度策略的優(yōu)略就顯得尤為重要。
不同的容器需求不同維度的資源,當(dāng)一個(gè)節(jié)點(diǎn)任意維度的資源耗盡時(shí),如果有多維資源需求的容器被啟動,那么該節(jié)點(diǎn)將不能滿足創(chuàng)建容器的需求,也就不能運(yùn)行此容器。在這種情況下,其他維度的剩余資源就被閑置了下來,而這些未被利用的資源就稱為資源碎片[5-6],這是一種極大的浪費(fèi)。所以,就需要減少資源碎片的大小。同時(shí),集群整體負(fù)載的均衡情況決定了集群在服務(wù)時(shí)的整體表現(xiàn),為了提高集群的服務(wù)質(zhì)量,需要保證整個(gè)集群的負(fù)載均衡。
本文分析研究了Swarm的整體架構(gòu)和調(diào)度策略,提出一種靜態(tài)平衡和動態(tài)預(yù)測相結(jié)合的容器調(diào)度算法。通過測試,本算法能夠減少節(jié)點(diǎn)的靜態(tài)資源碎片,維持整個(gè)集群的負(fù)載均衡。
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é)管理整個(gè)集群。Swarm集群分為Swarm Node和Docker Node。
Swarm master運(yùn)行在Swarm node上,主要工作是完成調(diào)度任務(wù)和管理集群。用戶通過Swarm Client初始化集群各個(gè)模塊并管理集群,discovery模塊負(fù)責(zé)發(fā)現(xiàn)集群的節(jié)點(diǎn)并收集信息,scheduler模塊負(fù)責(zé)容器請求的調(diào)度任務(wù),Cluster API定義了集群接口,是實(shí)際任務(wù)的完成者,leadship是Swarm的HA(高可用性)機(jī)制。
Docker Node是指運(yùn)行Docker Daemon的節(jié)點(diǎn)。Docker Daemon根據(jù)Swarm master的任務(wù)啟動相應(yīng)容器。Docker Node通過Swarm Agent向管理節(jié)點(diǎn)注冊信息,以便管理節(jié)點(diǎn)在執(zhí)行任務(wù)的時(shí)候可以發(fā)現(xiàn)該節(jié)點(diǎn)。
1.2 Swarm調(diào)度策略及資源碎片問題
Swarm的scheduler模塊分為filter組件和strategy組件。filter組件通過標(biāo)簽對節(jié)點(diǎn)進(jìn)行過濾。用戶在創(chuàng)建集群時(shí),需要根據(jù)節(jié)點(diǎn)的不同功能給與節(jié)點(diǎn)不同的標(biāo)簽,用戶一旦啟動容器,scheduler會根據(jù)用戶提供的標(biāo)簽,過濾出匹配標(biāo)簽的節(jié)點(diǎn)集合供strategy組件處理。
strategy組件對集群提供邏輯調(diào)度功能。主要有以下三種策略:spread、binpack和random。用戶選擇的策略將會決定集群如何計(jì)算節(jié)點(diǎn)的權(quán)重,集群默認(rèn)使用spread策略。其中random策略用來對程序進(jìn)行測試,僅對節(jié)點(diǎn)進(jìn)行隨機(jī)選擇;spread和binpack策略首先計(jì)算節(jié)點(diǎn)的權(quán)重,然后選擇合適的節(jié)點(diǎn)運(yùn)行容器。
節(jié)點(diǎn)權(quán)重的計(jì)算策略為:首先根據(jù)用戶申請的容器配制信息計(jì)算CPU和內(nèi)存的利用率,并將其結(jié)果求和,隨后,spread策略會優(yōu)先選擇權(quán)重小的節(jié)點(diǎn)運(yùn)行容器,而binpack會優(yōu)先選擇權(quán)重大的節(jié)點(diǎn)運(yùn)行容器。前者的優(yōu)點(diǎn)是,如果節(jié)點(diǎn)出現(xiàn)故障,將會損失少量的容器。后者的優(yōu)點(diǎn)是將更多的容器運(yùn)行在較少的機(jī)器上,節(jié)省物理資源。
盡管swarm調(diào)度策略簡單而有效,但是其忽略了一個(gè)重要問題,資源碎片問題。由于不同的容器需求不同維度的資源,當(dāng)一個(gè)節(jié)點(diǎn)的任意維度資源耗盡時(shí),如果有多維資源需求的容器被啟動,那么該節(jié)點(diǎn)將不能滿足創(chuàng)建容器的需求,也就不能運(yùn)行此容器。在這種情況下,其他維度的剩余資源就被閑置了下來,而這些未被利用的資源就被稱為資源碎片,這是一種極大的浪費(fèi)。所以就需要減少資源碎片的大小來提高節(jié)點(diǎn)的資源利用率。
同時(shí)Swarm在計(jì)算節(jié)點(diǎn)優(yōu)先級時(shí),由于計(jì)算方法的簡單,隨著集群的規(guī)模的擴(kuò)大,就會產(chǎn)生相同優(yōu)先級的節(jié)點(diǎn)?,F(xiàn)有的容器調(diào)度策略只是對相同優(yōu)先級的節(jié)點(diǎn)進(jìn)行了隨機(jī)的分配,并沒有對相同優(yōu)先級節(jié)點(diǎn)進(jìn)行再次比較,但是,容器在運(yùn)行時(shí)是動態(tài)地申請節(jié)點(diǎn)上的資源,這會造成在實(shí)際運(yùn)行環(huán)境中,集群負(fù)載的不均衡。由于集群整體負(fù)載的均衡情況決定了集群在服務(wù)時(shí)的整體表現(xiàn),相同優(yōu)先級節(jié)點(diǎn)的資源負(fù)載并不相同,因此,用戶體驗(yàn)也不相同,這就降低了集群提供服務(wù)的質(zhì)量。
根據(jù)上述情況,本文提出了靜態(tài)資源平衡和動態(tài)資源預(yù)測的策略對Swarm調(diào)度策略進(jìn)行優(yōu)化。
2.1 靜態(tài)資源平衡策略
多維資源的存在引發(fā)了資源碎片的問題。由1.2節(jié)可知,在一個(gè)滿負(fù)載的節(jié)點(diǎn)上,資源碎片顯然存在,節(jié)點(diǎn)資源分配是否平衡則關(guān)系到資源碎片的大小。為了減小資源碎片,需要改進(jìn)Swarm現(xiàn)有調(diào)度策略,在集群分配容器時(shí),需要度量容器分配后多維資源的平衡情況,從而選擇平衡情況最好的節(jié)點(diǎn)啟動容器。
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é)點(diǎn)信息的模塊,這就需要增加此模塊實(shí)現(xiàn)動態(tài)資源調(diào)度策略,修改后Swarm框架如圖2所示。
圖2 動態(tài)資源調(diào)度框架
首先在Swarm中添加receiver模塊,供scheduler模塊調(diào)用,receiver模塊用來接收monitor模塊傳輸?shù)墓?jié)點(diǎn)實(shí)時(shí)預(yù)測信息。monitor模塊運(yùn)行在每個(gè)節(jié)點(diǎn)上,實(shí)時(shí)監(jiān)控節(jié)點(diǎn)多維資源的使用情況。由于每個(gè)節(jié)點(diǎn)資源使用情況會隨著時(shí)間產(chǎn)生不同的波動。僅僅提供當(dāng)前節(jié)點(diǎn)信息并不能代表節(jié)點(diǎn)資源的實(shí)際使用情況。所以需要研究監(jiān)控節(jié)點(diǎn)的變化趨勢和時(shí)間關(guān)系,可以有效地預(yù)測出未來節(jié)點(diǎn)的資源使用情況,完成調(diào)度功能。
3.1 優(yōu)化調(diào)度算法的設(shè)計(jì)流程
總結(jié)上述策略,本文提出靜態(tài)動態(tài)相結(jié)合和的優(yōu)化調(diào)度算法,該算法流程如圖3所示。
圖3 優(yōu)化調(diào)度算法流程
(1) scheduler模塊獲取申請容器的配制信息。
(2) 靜態(tài)資源平衡算法計(jì)算靜態(tài)權(quán)值。
(3) receiver模塊獲取monitor模塊動態(tài)預(yù)測的節(jié)點(diǎn)的信息。
(4) scheduler模塊獲取receiver模塊的節(jié)點(diǎn)信息,計(jì)算動態(tài)權(quán)值。
(5) scheduler模塊根據(jù)靜態(tài)權(quán)值對節(jié)點(diǎn)排序。
(6) scheduler模塊對靜態(tài)權(quán)值相等的節(jié)點(diǎn)根據(jù)動態(tài)權(quán)值進(jìn)行二次排序。
(7) scheduler模塊選擇權(quán)值最小的節(jié)點(diǎn)分配容器。
3.2 靜態(tài)資源平衡算法
這里通過計(jì)算CPU資源和內(nèi)存資源之間的方差來度量節(jié)點(diǎn)資源的平衡情況。因?yàn)榉讲疃攘苛艘唤M數(shù)據(jù)的離散程度。方差越小代表這組數(shù)據(jù)越穩(wěn)定,反之,則越不穩(wěn)定。
靜態(tài)資源平衡算法如下:
設(shè)節(jié)點(diǎn)的資源維度為D[1,2,…,d],節(jié)點(diǎn)已分配的資源為U[u1,u2…,ud],節(jié)點(diǎn)的資源總量為T[t1,t2,…,td],節(jié)點(diǎn)即將分配的資源為P[p1,p2,…,pd],節(jié)點(diǎn)的資源利用率R[r1,r2,…,rd]。
當(dāng)用戶向集群申請一個(gè)容器。首先集群調(diào)度模塊獲取容器的配制信息,使用式(1)計(jì)算出每個(gè)節(jié)點(diǎn)在分配此容器后的靜態(tài)資源利用率。
(1)
然后使用式(2)計(jì)算每個(gè)節(jié)點(diǎn)的平均資源利用率:
(2)
最后使用式(3)計(jì)算每個(gè)節(jié)點(diǎn)的CPU資源和內(nèi)存資源的方差S2,方差即為節(jié)點(diǎn)的靜態(tài)權(quán)值:
(3)
3.3 動態(tài)資源調(diào)度算法
1) 預(yù)測模型的選取
在選取預(yù)測算法時(shí),需要考慮預(yù)測模型是否能夠反映節(jié)點(diǎn)負(fù)載的真實(shí)情況,同時(shí)又要求算法應(yīng)具有較小的時(shí)間復(fù)雜度[7]。由于Swarm是基于Docker的原生態(tài)集群,其Docker輕量級和便攜性的優(yōu)勢在Swarm中體現(xiàn)的非常突出。通過綜合考量,應(yīng)該避免使用時(shí)間復(fù)雜度高的高次曲線對節(jié)點(diǎn)負(fù)載情況進(jìn)行模擬,以免過度消耗集群的整體資源,削弱Swarm集群的整體表現(xiàn)。基于上述原因,本文采用灰色模型GM(1,1)[8-9]對節(jié)點(diǎn)的狀態(tài)變化進(jìn)行模擬預(yù)測。
灰色系統(tǒng)理論是鄧聚龍?jiān)?982年創(chuàng)立的一門新興橫斷學(xué)科,它以“部分信息已知,部分信息未知”的“小樣本”、“貧信息”不確定性系統(tǒng)為研究對象,主要通過對部分已知信息的生成、開發(fā),提取有價(jià)值的信息,實(shí)現(xiàn)對系統(tǒng)運(yùn)行規(guī)律的正確認(rèn)識和確切描述,并據(jù)以進(jìn)行科學(xué)預(yù)測。其主要優(yōu)點(diǎn)包括以下幾點(diǎn):需求樣本量小,樣本不需要有規(guī)律性分布,計(jì)算工作量小,定量分析結(jié)果與定性分析結(jié)果一致,預(yù)測準(zhǔn)確度高。
2) 基于灰色模型的節(jié)點(diǎn)負(fù)載預(yù)測
由于Swarm原有調(diào)度策略中只計(jì)算了CPU和內(nèi)存兩個(gè)維度的資源,因此這里假設(shè)節(jié)點(diǎn)的CPU利用率為Uc,內(nèi)存利用率為Um。首先通過monitor獲得節(jié)點(diǎn)的前n時(shí)刻的Uc={Uc(1),Uc(2),…,Uc(n)}和Um={Um(1),Um(2),…,Um(n)}后,采用GM(1,1)預(yù)測算法模擬,然后對n+1時(shí)刻的Uc和Um值進(jìn)行預(yù)測。計(jì)算方法如下:
步驟1 設(shè)時(shí)間序列x(0)={x(0)(1),x(0)(2),…,x(0)(n)}有n個(gè)原始值,使用式(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 精度檢驗(yàn),根據(jù)式(11)計(jì)算原始數(shù)據(jù)和預(yù)測數(shù)據(jù)的相對殘差:
(11)
3) 基于灰色模型的動態(tài)資源調(diào)度算法
步驟1 獲得當(dāng)前的CPU和內(nèi)存利用率的時(shí)間序列x(0),并根據(jù)式(4)對其進(jìn)行一次累加計(jì)算,得到一次處理的數(shù)據(jù)序列x(1)。
步驟2 根據(jù)B和Y的計(jì)算公式(式(7)和式(8)),形成B矩陣和Y矩陣。
步驟3 對B和Y矩陣進(jìn)行矩陣運(yùn)算,根據(jù)式(6)求出發(fā)展灰數(shù)α和內(nèi)生控制灰數(shù)μ。
步驟6 根據(jù)式(11)對預(yù)測模型進(jìn)行殘差檢驗(yàn),評估模型是否達(dá)到要求。
步驟7 對n+1時(shí)間節(jié)點(diǎn)的CPU和內(nèi)存預(yù)測值求和得出節(jié)點(diǎn)的動態(tài)權(quán)值。
本實(shí)驗(yàn)搭建2個(gè)Swarm集群,集群1使用Swarm1.0.1搭建,集群2使用修改后的Swarm1.01源碼包重新編譯并搭建。每個(gè)集群由3臺普通PC組成。其組成如表1所示。
表1 集群配制
由于實(shí)驗(yàn)條件限制,現(xiàn)設(shè)計(jì)實(shí)驗(yàn)如下:
實(shí)驗(yàn)一 對兩個(gè)Swarm集群申請如表2序列容器。集群1算法為Swarm原算法,集群2算法為靜態(tài)資源平衡算法。每個(gè)集群容器的運(yùn)行情況如表3所示。
表2 容器申請序列
表3 容器運(yùn)行對比結(jié)果
圖4 集群資源碎片對比圖
由圖4可知,集群2中的靜態(tài)資源碎片相比集群1有明顯下降,由表3可知,集群2相比集群1可以多運(yùn)行一個(gè)維度為[1,2]的容器。改進(jìn)算法能夠減少靜態(tài)資源碎片,增加資源的利用率。
實(shí)驗(yàn)二 為方便計(jì)算,本文定義動態(tài)資源度量單位S=(Uc+Um)×100。每個(gè)節(jié)點(diǎn)的初始狀態(tài)如表4所示。
表4 節(jié)點(diǎn)初始狀態(tài)
本實(shí)驗(yàn)通過在集群2上增加動態(tài)預(yù)測算法和靜態(tài)資源平衡算法作比較,表5為每個(gè)節(jié)點(diǎn)的運(yùn)行容器的情況。本文通過模擬程序給予node1中單核滿負(fù)載,其他節(jié)點(diǎn)為初始狀態(tài)。同時(shí),給予容器1、3和5號容器CPU滿載,2號容器CPU滿載并使用1GB的內(nèi)存,容器運(yùn)行情況如表5所示。
表5 容器運(yùn)行對比結(jié)果
集群負(fù)載對比情況如圖5所示。由圖5可知,靜態(tài)平衡算法會出現(xiàn)集群整體負(fù)載不均衡的情況,增加動態(tài)預(yù)測算法后,集群整體負(fù)載相對均衡。
圖5 集群負(fù)載均衡對比圖
總結(jié)上述實(shí)驗(yàn),優(yōu)化調(diào)度算法不僅可以減少集群的靜態(tài)資源碎片,提高資源利用率,而且可以均衡集群的動態(tài)負(fù)載。
Docker容器隨著其生態(tài)圈的完善,越來越受到大家的青睞。Swarm作為Docker的原生態(tài)集群管理工具也顯得更加重要。本文在分析Swarm集群框架和調(diào)度策略的基礎(chǔ)上,針對原有調(diào)度策略在解決靜態(tài)資源碎片問題上存在的不足,提出靜態(tài)平衡算法,并在此基礎(chǔ)上增加動態(tài)預(yù)測算法均衡集群的動態(tài)負(fù)載。實(shí)驗(yàn)表明,優(yōu)化調(diào)度算法能改善集群資源碎片過多的問題,提高資源利用率,同時(shí)能夠均衡集群的動態(tài)負(fù)載。
[1] 楊保華,戴王劍,曹亞侖.Docker技術(shù)入門與實(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ì)算機(jī)應(yīng)用研究,2014,31(7):2178-2182.
[8] 段峰,楊芬.灰色預(yù)測模型的研究及應(yīng)用[J].湘南學(xué)院學(xué)報(bào),2008,29(2):17-21.
[9] 郭正紅,馬辛華,蘭安怡.基于層次分析法權(quán)重和灰色服務(wù)器負(fù)載預(yù)測的云計(jì)算on-line遷移策略[J].計(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ì)算機(jī)技術(shù)。劉釗遠(yuǎn),教授。
TP338.8
A
10.3969/j.issn.1000-386x.2017.05.049