基于利用率的容器云彈性資源調度算法*

徐勝超 陳 剛

（廣州華商學院數據科學學院 廣州 511300）

1 引言

隨著云計算技術的進一步發展［1～3］，網絡服務器的眾多信息均存儲在容器云內，使得資源管理問題逐漸突出。容器云內資源的平均資源利用率較低，同時大部分服務器處于閑置狀態［4～5］，但卻耗用著較大功率，導致現存網絡資源調度能耗成本高而且效率低下［6］。因此國內外相關學者加強容器云資源調度問題研究。

文獻［7］研究了基于編碼染色體的遺傳算法來管理動態資源調度。該調度算法通過計算在未來所需的虛擬機數量及其預測的CPU和內存需求來調度任務。基于工作負載預測結果，提出了一種云計算環境下成本優化的資源調度策略，旨在最小化從中心云租用虛擬機的總成本，最后采用遺傳算法求解資源調度策略，但是該方法在實際應用中存在成本高、調度效率低等問題。文獻［8］研究了基于容器云隊列在線任務的資源調度方法，首先在云計算服務排隊模型的基礎上，通過分析任務隊列長度的變化，構建了資源功耗的最小化目標函數，最后獲得在線的任務和容器資源的優化調度策略，但是該方法實施資源計算時過于復雜，導致資源調度時間長。文獻［9］研究了容器云多維資源利用率均衡調度方法，其在Open Shift容器云平臺上提出了基于多維資源空閑率權重的評價函數和調度方法。該方法綜合考慮物理節點CPU、內存、磁盤、網絡帶寬空閑率和已部署的容器應用個數等因素，利用模糊層次分析法自動建模求解容器應用多維資源權重參數，該方法能夠使集群多維資源利用率更加均衡，從而提升資源的利用率和集群性能，但是該方法忽略資源調度的實質目標導致資源調度效果不佳。

綜上所敘，本文充分考慮資源的利用率情況，研究容器云彈性資源調度算法，通過彈性地調度容器云中資源，提升資源利用率，最大程度滿足用戶個性化需求。

2 容器云彈性資源調度算法

2.1 容器云調度模型

Pod是容器云資源調度的最基本單位。引入Pod概念可以解決多個容器之間的通信問題，也提高了容器間數據共享能力，Pod還可以讓集群快速地判斷獲取容器的運行狀態［10］。

根據上述分析，分析容器云彈性資源調度原理與過程，如圖1所示。

圖1 容器云彈性資源調度過程

容器云當前默認的調度過程分為預選調度過程和優選調度過程。API服務器在接收客戶端轉送的Pod對象創建請求后，然后就通過調度器從集群中選擇一個合適的最優節點初始化并運行Pod。而在調度過程中有三個階段：節點預選階段、節點優選階段、節點選定階段，最后篩選出最佳的節點。

綜合上述分析，構建資源調度模型，如式（1）～式（2）所示：

式中：集群節點內存使用率用Qm表示；在設置容器i后節點綜合負載用Q*i表示；CPU使用率用Qc表示；綜合負載使用情況用Qi表示；網絡帶寬使用率用Qn表示；因各應用資源的負載狀態不同［11］，通過引入參數λ、α、β調整Qi。

容器云彈性資源調度的子任務在虛擬資源中進行計算時是并行獨立完成的，因此子任務在各虛擬資源中執行時間的最大值為彈性資源調度的執行時間花費，彈性資源調度任務在各虛擬資源的執行成本花費k1與傳輸成本花費k2的和即為任務調度總成本花費k，即任務調度總成本花費k=k1+k2。

分析上述公式可知，容器云彈性資源默認調度算法相對簡單，僅考慮CPU和內存，忽視了其他資源過度消耗，使數據中心產生巨大的資源浪費。例如，一個節點上的硬盤負荷接近滿載但是的內存使用率很低，而像現有解決算法只解決了CPU和內存能耗，但依舊很有可能將Pod調度到該節點，導致該節點上大多數應用由于節點硬盤資源的不足而難以運行，同時剩余的內存資源亦無法被使用而浪費，從而降低集群的資源使用效率，造成能量過度消耗。

2.2 彈性資源調度算法

本節構建調度模型采用基于資源權重的最大利用率算法實現容器云彈性資源調度。

假設在T時間內，系統任務必須完成，且同一任務不可被替代［12～14］。其中，用t表示最小時隙，另外等待隊列集是空。各時隙對應與之數量相同的虛擬機資源配置類型［15］。假設有n個時隙，在物理主機Hj內任務m的數量用Hjm表示，則此時資源利用率φ最大，同時符合0≤n≤T，具體如式（3）～式（4）所示：

式中，容器i的利用率用φi表示；容器云彈性資源權重用ω(i)表示；物理主機最大可行的配置用Hj=(H1，H2，H3，…，HM)表示；在物理主機Hj內任務m的最大數量用H(j)max表示；資源需求用ami表示。

經分析可知，資源需求與虛擬機內任務m數量乘積最大，因ami值固定，為保證H(j)max最大，需要確保m數量最大。t時刻資源利用率配置Hˉr(t)需滿足如下條件，如式（5）所示：

式中：最大虛擬機分配集用Ωr表示，權重用w(i)表示，虛擬機任務數量用Hm表示，最大可行配置用Dri表示。

因不同間隙隊列Wm(t)長度存在差異，其不同時刻時隙變化如下：

式中：t時刻集群節點內存使用率用Qm(t)表示，t時刻集群節點調度負載率用Zm(t)表示。

為了保證容器云彈性資源調度穩定性，當隊列中資源利用率大于閾值時，需要依據上述方法降低工作負載。根據上述過程設計云彈性資源調度算法流程如下。

按照重要程度得出i類資源平均利用率wei將其作為輸入，將虛擬機配置作為輸出。

步驟1：明確m類資源權重值。

步驟2：按照負載均衡原則選擇物理主機。

步驟3：面對集合內各物理主機實施如下流程：

若物理主機內某任務隊列集群節點內存使用率Qm＞閾值；返回任務隊列最大配置；跳轉至結束。

步驟4：對容器i后節點host綜合負載實施初始化賦值。

步驟5：判斷虛擬機配置。

步驟6：如果當前的集群節點內存使用率Qm大于容器i后節點host綜合負載，則將當前的集群節點內存使用率Qm視為綜合負載。

步驟7：將最佳的集群節點內存使用率Qm對應的虛擬機配置視為最佳配置。

步驟8：保存當前最佳配置，結束算法運行。

3 實驗分析

為驗證本文算法的性能，通過CloudSim平臺實施實驗，按照應用程序配置云數據中心，物理機與虛擬機數量分別為200臺、500臺。

3.1 實驗設置

3.1.1 實驗環境設置

實驗環境為真實的物理環境，7臺dell R720作為計算節點，采用共享存儲機制，服務器上安裝OpenStack開源云。實驗系統鏡像中集成自主開發的運行參數監控軟件。

初始狀態下，隨機申請150臺虛擬機（VM1～VM150）。其中物理機1分配17臺，物理機2分配16臺，物理機3分配18臺，物理機4分配10臺，物理機5分配14臺，物理機6分配16臺和物理機7分配14臺。在實驗中，網絡都采用百兆網絡帶寬分配。

3.1.2 實驗過程設置

在模擬整合過程中，數據中心將創建200臺物理主機。物理主機分別對應于CloudSim平臺中某一天每個虛擬機CPU資源利用率記錄，數據中心會創建相應個數的虛擬機，這些虛擬機分成不同大小的多個種類。通過上述過程，以綜合負載、資源利用率、Pod搶占調度和任務調度總成本四個評價指標設計實驗。

3.1.3 實驗參數設置

云數據中心負載波動較大均衡度低，集群節點內存為2GB，其中高負載物理機為39臺，最佳負載為10臺，可遷移物理機達到31臺。

3.2 綜合負載測試

以CPU、內存、網絡寬帶占用率三個指標作為衡量指標。采用本文算法進行資源調度后三個指標占用率情況，如圖2所示。

圖2 資源調度后的各指標占用率

圖2中的資源占用率情況通過式（1）得到，即設置容器i后節點host綜合負載。分析圖2可知，采用本文算法資源調度后達到最佳負載物理機數量是60臺，負載較輕物理機數量是10臺，停止物理機10臺。經計算本文算法調度后的負載不均衡度約為0.05，由此說明本文算法可平衡數據中心的負載情況，提高資源利用率。

3.3 資源利用率測試

如果存在服務器中某一資源的利用率超過90%則表明該資源占用較高負載，會導致資源負載不均衡。當資源利用率大于負載時，表明調度后的資源負載不均衡。設置該實驗的負載為16。

節點1～節點6在應用本文算法調度前，存在節點2和節點5的網絡負載的資源權重超過90%情況，同時這兩個節點的負載大于16，存在資源占用率過大現象。

采用本文算法對節點1～節點6的資源進行調度，資源調度后不同節點的資源利用率結果見圖3，節點的負載、平均資源利用率見表1。

圖3 資源調度后節點的資源利用率

表1 節點的負載、平均資源利用率

圖3中，資源利用率情況數據結果通過式（4）計算得到，表1中的負載為通過式（2）計算得到的綜合負載使用情況，平均資源利用率為圖3中不同負載的平均值。分析圖3和表1中數據可知，本文算法資源調度后不存在節點資源利用過高現象，且各節點的資源利用率均小于負載，實驗結果表明，采用本文算法實施調節調度后，可有效避免單一資源利用過高導致的負載不均衡現象。

3.4 Pod搶占調度對比

通過對比對高優先級Pod實行搶占調度后集群的各項資源使用率變化情況，評價調度算法的優劣，資源使用率通過如式（1）所示的容器i后節點host綜合負載獲取。若實行搶占調度后，節點的綜合負載較高且波動較小，說明節點的資源使用更充分、更穩定，資源使用率通過式（1）分析得到，測試實驗結果見圖4。

圖4 本文算法節點的資源使用率

通過圖4結果表明，在實施了搶占調度算法后，本文算法的資源使用數據更加平穩，資源使用率也更加高。反觀默認的搶占算法，由于該算法只考慮優先級，不考慮其他的因素，所以依舊存在使用資源不穩定的低級Pod。其主要原因是，本文在任務調度前，充分考慮資源的利用情況，針對用戶需求調度容器云彈性資源，提升了資源調度性能。

3.5 任務調度總成本測試

實驗設置三種任務，任務1中總任務數量為1000個，任務2中總任務數量為10000個，任務3中總任務數量為100000個，得出本文算法在不同任務下進行調度的總成本k，即本文算法完成三項任務時的執行成本花費k1與傳輸成本花費k2的和，如圖5所示。

圖5 本文算法任務調度總成本k

分析圖5可知，隨著任務總數量的增多，本文算法的任務調度總成本也呈上升趨勢，但單位成本控制在120元以下，說明本文算法在任務調度總成本方面合理，沒有過度浪費資源，可有效節省資源調度成本。

4 結語

本文研究基于利用率的容器云彈性資源調度算法，將最大資源利用率作為目標，合理配置物理主機，以提高容器云中資源利用率。實驗結果表明本文算法的內存占用率、CPU占用率、網絡寬帶占用率均低于10%，綜合負載較好，當節點出現資源利用率不均衡情況時，采用本文算法對其實施調節調度后，可提高資源均衡度，可較好實現資源均衡調度的目標，滿足客戶要求，適用性較強。