蟻群優(yōu)化算法的Docker集群調(diào)度策略*

李東光，劉智平，姜雨菲

(西安工業(yè)大學(xué) 計算機科學(xué)與工程學(xué)院，西安 710021)

容器技術(shù)在近年的軟件部署方面為主要的新技術(shù)，Docker[1]作為一種典型的容器技術(shù)，其自帶的集群編排工具Swarm在調(diào)度資源時存在負(fù)載不均，集群整體性能差的問題，無法完美實現(xiàn)負(fù)載均衡，在資源利用率和集群性能方面并不能很好的符合預(yù)期。

國內(nèi)外對此問題有較多的研究，在資源調(diào)度方面，文獻[2]基于原有的 Swarm 容器集群管理工具，另外加入權(quán)值調(diào)度模塊。在接收到Client的請求時，利用權(quán)值調(diào)度模塊根據(jù)各個節(jié)點的資源消耗情況計算出節(jié)點權(quán)值，按照約定，權(quán)值越高表名節(jié)點的總體資源占用率越大，鑒于此，權(quán)值調(diào)度模塊會把新的容器放在權(quán)值最小的節(jié)點來實現(xiàn)集群負(fù)載均衡。此策略在一定程度上實現(xiàn)了容器集群的負(fù)載均衡，但是此策略只考慮到了整個容器的資源分配，并未對不同的資源類型做更為詳細的權(quán)值計算，并不能保證所利用即為所分配。文獻[3]在容器虛擬化中引入了機器學(xué)習(xí)算法，利用K-Medoid算法、分割周圍類算法等實現(xiàn)了容器代理系統(tǒng)，此系統(tǒng)具有容器工作負(fù)載感知的能力，節(jié)約能耗的同時也保證了集群的整體性能。文獻[4]基于自回歸積分滑動平均模型提出了云計算負(fù)載預(yù)測模型，達到了91%的準(zhǔn)確率。然而，計算學(xué)習(xí)調(diào)度策略在容器集群調(diào)度中能否發(fā)揮其優(yōu)勢需要視情況而定，機器學(xué)習(xí)算法是依托于大量的樣本訓(xùn)練集，對于容器集群來說即是大量的時間序列和容器資源使用量，如此龐大的開銷使得其優(yōu)勢并不是十分明顯。

因此，文中綜合各個調(diào)度算法的優(yōu)劣，擬采用一種啟發(fā)式智能算法蟻群算法[5-8](Ant Colony Optimization，ACO)，其在解決這類組合優(yōu)化的問題具有一定的優(yōu)勢，文中擬通過使用蟻群算法對部署Swarm集群調(diào)度進行改進，實現(xiàn)Swarm集群各節(jié)點主機任務(wù)相對均衡分布，同時提高集群的整體性能。

1 Docker和Swarm 集群

傳統(tǒng)的虛擬機一般由兩部分構(gòu)成，虛擬硬件和操作系統(tǒng);而Docker創(chuàng)建的虛擬機即容器[9]并不需要創(chuàng)建安裝特定的操作系統(tǒng)和Hypervisor管理，而是直接共享主機操作系統(tǒng)的內(nèi)核，用Host主機的硬件和操作系統(tǒng)來執(zhí)行程序。由于容器沒有中間件消耗資源，一定程度上提高了資源的利用率，兩者的系統(tǒng)架構(gòu)對比如圖1所示。

圖1 傳統(tǒng)VM和Docker的比較

集群結(jié)構(gòu)如圖2所示，Swarm[10]使用標(biāo)準(zhǔn)的Docker API接口作為其前端訪問入口，并以守護程序的形式運行，對來自Docker Client的指令信息進行配置，并最終以代理的形式將需要處理的信息發(fā)送給不同節(jié)點的Docker Daemon進行處理并返回響應(yīng)。

Swarm中提供了三種不同的資源調(diào)度策略[11]Random、Spread和Binpack。Random策略采用隨機分配容器的部署位置，這種調(diào)度方式有很大缺點，一般僅限于集群的測試；Spread策略按照各節(jié)點資源即內(nèi)存和 CPU 內(nèi)核數(shù)來決定部署的容器數(shù)量，此方式能夠讓容器相對均勻地分布在主機各個節(jié)點上；而Binpack策略會先將一個節(jié)點的資源用盡之后再向其他的節(jié)點部署容器，此方式調(diào)度可以充分使用每個節(jié)點資源，但會導(dǎo)致各節(jié)點任務(wù)負(fù)載嚴(yán)重不均，影響集群的整體性能表現(xiàn)。Swarm內(nèi)置的這三種不同的調(diào)度方式，可以應(yīng)用在一些對集群效率要求不高的應(yīng)用中。但對于類似云平臺的應(yīng)用，對于集群的負(fù)載均衡，資源利用率要求較高，對集群的整體性能表現(xiàn)有一定的高要求，在這些情況下，Docker Swarm內(nèi)置的調(diào)度策略有明顯的缺陷[12]。

圖2 Docker Swarm集群系統(tǒng)架構(gòu)圖

2 基于蟻群算法的調(diào)度優(yōu)化設(shè)計

Docker集群是由2組節(jié)點即管理節(jié)點和工作節(jié)點組成。而管理節(jié)點也負(fù)責(zé)任務(wù)管理，包括調(diào)度決策。SwarmKit為Docker集群管理背后的真正引擎。開始調(diào)度之前，所有的工作節(jié)點將通過一組過濾器進行處理，例如Constraint Filter只允許滿足指定約束的節(jié)點通過。之后使用調(diào)度算法ACO替代原始循環(huán)貪婪算法將任務(wù)組放入流水線調(diào)度，總體的結(jié)構(gòu)如圖3所示。

在Docker的最新版本中，提供了服務(wù)和任務(wù)的概念。服務(wù)由一個或多個任務(wù)組成。集群用戶將通過向調(diào)度器提交一些任務(wù)來啟動服務(wù)。調(diào)度器選擇一組符合指定約束的節(jié)點，并將任務(wù)調(diào)度到這些節(jié)點?？偸菚瑫r安排一批任務(wù)，但不一定是同時完成所有任務(wù)。在每批任務(wù)中，都可以使用他們所要獲取資源的信息來找到最佳方案，并使用ACO技術(shù)。

圖3 ACO算法下的SwarmKit調(diào)度結(jié)構(gòu)圖

調(diào)度器目標(biāo)是將任務(wù)放到可用資源上。他在每次調(diào)度時會使用可用資源。一個人工螞蟻通過觀察每一個資源的信息素軌跡來隨機尋找資源。某個節(jié)點的每個資源的計算公式為

(1)

為了初始化每個節(jié)點的信息素軌跡，在循環(huán)貪婪算法中使用R(j)，其簡單地將每個任務(wù)放在循環(huán)模式的一個節(jié)點上,τ0,j=R(j)為每個節(jié)點的起始信息素。

每個概率的計算公式為

(2)

其中ηi為節(jié)點j的啟發(fā)式值。

計算每個節(jié)點的概率p(t,j)，選擇下一個節(jié)點j

(3)

其中j∈P(k),q0為探索率。

下一步計算信息素消失。每個節(jié)點的信息素軌跡消失計算公式為

(4)

其中Δ表示信息素的變化,當(dāng)一個任務(wù)被調(diào)度程序放置到一個特定的資源，Δ的值總是小于0。信息素利用式(4)計算，為了顯著地減少所選節(jié)點的信息素水平，使其對下一個任務(wù)不那么重要，使得剩余的容器將被分配到整個資源中。

最佳的規(guī)劃Pw采用式(5)從所有任務(wù)中選出最頻繁規(guī)劃。

(5)

在實現(xiàn)真正的調(diào)度程序之前，通過模擬輸入數(shù)據(jù)并執(zhí)行單元測試將其作為模擬運行，發(fā)現(xiàn)最佳規(guī)劃的頻率范圍為0.35～0.70。

文中參數(shù)的選擇通過大量的實驗對比得來，經(jīng)過測試，使得算法在收斂度，穩(wěn)定性以及保障性能的基礎(chǔ)上，α，β,ρ分別選擇 0.7，0.3，0.6。

3 實驗與分析

SwarmKit和Docker都是使用Go編程語言編寫的。文中使用Go 1.6.2作為編譯器，利用Docker支持的主要平臺x86-64架構(gòu)完成。通過在云提供商DigitalOcean上形成SwarmKit集群來進行實驗。該集群由1個管理節(jié)點和5個在同一數(shù)據(jù)中心上運行的工作節(jié)點組成。表1為5個工作節(jié)點的資源配置情況。SwarmKit管理器將管理節(jié)點可用性設(shè)置為零，以防止將容器調(diào)度到自身。每個工作節(jié)點都連接到同一主機上的每個Docker引擎。實驗一通過使用SwarmKit附帶的原始循環(huán)貪婪算法實現(xiàn)完成，實驗二通過使用ACO算法調(diào)度器的SwarmKit容器的修改版本完成。實驗結(jié)果分別以 Spread和ACO表示。

表1 Docker主機各節(jié)點的資源配置

3.1 均衡性

選擇部署普通的NGINX服務(wù)器作為調(diào)度任務(wù)，NGINX服務(wù)器的CPU和內(nèi)存預(yù)留量分別為0.5和128 MB。在5個節(jié)點上部署了12個NGINX服務(wù)器任務(wù)，部署統(tǒng)一的任務(wù)可以很容易地觀察結(jié)果的調(diào)度。圖4和圖5分別顯示了由 Spread和ACO算法計算的調(diào)度計劃。將最大資源節(jié)點即節(jié)點二進行資源歸一化即為1。同樣把每個NGINX服務(wù)器所占資源進行歸一化處理?？梢缘玫讲渴鹈總€NGINX服務(wù)器所占資源為0.125，從圖4和圖5中可以看出每個節(jié)點部署的NGINX服務(wù)器個數(shù)，縱軸上的資源從式(1)中得出。

圖4 Spread策略各節(jié)點任務(wù)分配

圖4中，對于SwarmKit的Spread策略，將前10個任務(wù)平均分配給所有5個節(jié)點，對于最后2個任務(wù)，選擇分別將它們放到節(jié)點2和節(jié)點4， 這導(dǎo)致節(jié)點2和節(jié)點4在每個節(jié)點上運行3個容器。

圖5 ACO算法各節(jié)點任務(wù)分配

圖5中，只有任務(wù)被放入每個512中MB節(jié)點，節(jié)點1和節(jié)點5。具有4GB規(guī)格的節(jié)點2和具有2GB規(guī)格的節(jié)點4分別用于調(diào)度4個任務(wù)。實際上，放置在所選計劃中的序列Pw將任務(wù)放入節(jié)點2中，在節(jié)點4，節(jié)點2和節(jié)點3之間來回切換。節(jié)點3用于調(diào)度2個任務(wù)。

通過對比兩個算法的任務(wù)調(diào)度可以看出ACO相對Spread實現(xiàn)了更好的均衡負(fù)載。

3.2 工作負(fù)載性能

任務(wù)分配的結(jié)果并不是主要問題。最終目標(biāo)是提升集群的整體性能。因此，在部署之后，文中使用Apache Bench來測量NGINX服務(wù)器的性能。測試配置為“-c10-n1000”。

表2為ACO和Spread策略放置的每個 NGINX 容器壓力測試數(shù)據(jù)。此處容器對應(yīng)的兩種算法中的容器可能不是同一節(jié)點的容器，只是為了統(tǒng)計整體性能。上一節(jié)使用ACO算法放置容器可以使任務(wù)更均勻分布，雖然，不能顯示哪個容器在哪個主機節(jié)點上運行，但是通過對集群容器集群進行壓力測試可以得出優(yōu)劣，Spread中總負(fù)載為22 186.21，ACO中總負(fù)載為26 623.034，很明顯，ACO算法調(diào)度的集群的整體壓力測試性能要好于原始的調(diào)度性能。同樣的環(huán)境下，基于ACO集群QPS相對Spread集群提高約20%。

表2 Docker集群下Spreed策略和ACO算法部署容器數(shù)據(jù)對比

4 結(jié) 論

目前在Docker主機中以循環(huán)方式分發(fā)容器，循環(huán)算法導(dǎo)致資源使用并不理想。文中提出了一種基于ACO的算法用在軟件容器環(huán)境Docker中調(diào)度任務(wù)，發(fā)現(xiàn)Swarm的當(dāng)前實現(xiàn)模型與ACO非常吻合，通過搭建容器集群進行任務(wù)調(diào)度分配資源，通過單元測試進行仿真，實施是可行的。

在相同配置下，文中提出的ACO算法的工作負(fù)載比Swarm算法放置的NGINX服務(wù)器快大約20%，優(yōu)于原始調(diào)度算法。對于ACO算法，仍然有許多改進空間，例如對NGINX服務(wù)器特定參數(shù)的引入，將使調(diào)度程序?qū)γ總€特定情況都能更好地工作。