基于用戶云服務集群的資源動態調度研究?

馬 龍 陳慶奎

（上海理工大學光電信息與計算機工程學院 上海 200093）

1 引言

近年來，由于云計算的穩步發展。云服務設備有著可按需配置的便捷性以及廉價的優勢得到了公司和企業的青睞［1］。越來越多的公司和企業拋棄傳統的服務器設施，將服務集群部署在云服務器上［2］。

然而，用戶（公司和企業）購買云服務器并將傳統的基礎設施服務器集群遷移到云服務器上后，很多程度上都沒有最大化利用購買的資源［3~4］。據調查顯示，用戶購買的云服務器設備的CPU利用率和內存的利用率經常達不到50%［5~6］。

現有的很多研究是為了提高云服務器平臺的整體資源利用率，將用戶的閑置資源利用起來，從而降低云服務器提供商的成本［7~13］。而站在用戶角度，用戶購買了云服務器的計算資源后，如何最大化利用這些自己的計算資源是一個值得研究和有意義課題。當用戶集群（用戶購買的多個計算節點形成的集合）中配置的某些服務發生大規模訪問時，可以動態調整這些服務在用戶集群中的分配和并行運行的數量，以便充分利用用戶購買的其他計算節點上的空閑資源，達到集群私有資源的有效利用。用戶無需再購買多余的計算節點就可以適應峰值服務訪問，從而節約用戶的成本。

為了解決上述問題，本文基于對用戶集群計算資源的使用和集群中應用的調度方案進行研究。在用戶集群中加入了集群監控模塊和動態資源調度模塊，來調度用戶集群中的應用服務的配置和啟動，例如在www 服務器訪問峰值的時候，可以動態配置多個以上的節點作為www服務器，而在訪問低谷的時期可以將www 服務器減少為單個。為了實現集群中應用的動態配置和優化，我們在對用戶集群服務器監控的數據資源進行研究后，基于TOPSIS 算法［14~16］提出了一個新的集群調度策略。實驗表明，在發生峰值訪問時，通過這些模塊的監控和調度，用戶集群可以適應突發的大規模訪問并且提高用戶服務器整體的資源利用率。

2 模型設計

本方案中，系統的整體結構圖如圖1 所示。部署在節點上的監控模塊采集節點中的節點數據，并將數據傳輸給數據處理節點，數據處理節點會對源數據進行處理分析并為調度模塊提供數據支持，最后動態調度模塊結合監控數據和歷史數據動態的調度集群中節點中的應用。

圖1 整體模型

監控模塊：監控模塊部署在每個集群節點中。除了像傳統監控方案一樣采集節點的系統信息，包括不限于CPU使用率、內存使用率、網絡和磁盤I/O等參數外，監控模塊還需采集各節點中運行各應用實例的個數以及單位時間內訪問各個應用的次數，監控模塊采集的原始數據信息傳輸到數據處理節點。

數據處理節點：負責將采集的原始監控數據處理后，變成易于分析的二元時間序列資源組nodeR（CPU 信息、內存信息、磁盤IO…）。其中每一項可用如下資源組表示，如nodeRScpu（cpu主頻、cpu 核心數、cpu 利用率、cpu 空閑率）、nodeRSmemory（內存大小、可用內存、內存利用率）、nodeRSIO（每秒IO 數、吞吐量、磁盤利用率）等。數據處理節點以接口的形式來提供監控數據的實時訪問，可以對接數據庫對數據進行持久化存儲。

資源調度模塊：該模塊負責通過本文中的調度算法選出最優的節點，并將應用合理的增加或者減少在對應的節點上。合適的分配應用在節點中的部署，最大化利用用戶集群的私有計算資源。

3 關鍵技術

3.1 監控模塊

如圖2 所示，監控模塊部署在節點中進行數據采集，除了收集各個節點的時序資源使用情況外，還特別記錄節點中各應用的每秒對外訪問次數。這些數據以供動態調度模塊進行計算使用。

圖2 監控模型

Prometheus 是一個開源的監控系統［16］，它在記錄純數字時間序列方面表現得非常好，它既適用于面向服務器等硬件指標性能，也適用于高動態的服務架構監控。本文選用Prometheus 作為數據處理模塊，Prometheus 將所有監控數據進行處理分析，將數據轉化為調度模塊所需要的時間序列數據，并將數據對外以Rest Api形式提供數據訪問。

3.2 資源敏感度計算

根據數據處理節點提供的歷史數據，分析應用App在所有節點上的單位時間內的訪問次數記為xi，并記錄此時節點上應用所占用的整體資源百分比為Rcpui，Rmemoryi，RIOi，每一類計算資源可得到對應的數據組（x1,r1),(x2,r2)…(xn,rn），由于數據分布為線性分布，故將數據按式（1）進行線性回歸分析可得到回歸系數?。可計算出對應資源的回歸系數

其中ri是實際測量值，是測量的平均值；xi是實際測量值，為測量的資源百分比的均值。?的大小反應了該應用對相應計算資源的敏感程度。

規定資源的回歸系數大于?，則規定應用App對此資源敏感（即隨著應用App的對外單位時間訪問增加，該應用會更易占用大量的此資源）。

3.3 調度模塊

本文使用“類似于理想解決方案的優先級排序技術”（TOPSIS）算法，并結合需要調度的應用對系統資源的敏感程度提出了一種調度策略。該調動策略分為三個階段：第一階段為節點預選；第二階段為節點優選；第三階段執行應用調度。

假設需要增加的應用所需的計算資源為資源組pod(rcpu,rmemeory,…) ，集群中共有N個應用節點。

算法1.調度策略

1）輸入：節點資源信息集合nodeR，所需資源組pod

2）輸出：最佳的節點nodej

3）forifrom 1 toN：

4） 判斷nodeRi中每一項剩余資源是否滿足pod

5） 若滿足則加入集合η

6）end for

7）通過改進的TOPSIS算法篩選節點集合η得到nodej

8）returnnodej

如算法1 第3 行~6 行所示，我們的調度策略的原理是，首先過濾基礎設施的所有節點，判斷節點資源組Node(rcpu,rmemory…)中的每一項是否都能滿足資源組pod，保留能夠執行應用的節點并加入集合η，此時完成第一階段預選。然后通過算法1第7行~8行從節點中選擇最佳節點來部署應用。

第二階段基于TOPSIS 算法進行篩選，通過計算選擇一個與最佳解距離最短、與最差解距離最遠的解（節點）。篩選出的此節點即為最優的調度節點。

調度算法具體流程如下，我們假設通過了第一輪篩選的集合η中有n個節點，為了選擇到最佳的節點，我們將對這n個節點使用m個資源標準進行篩選。

1）構建節點資源決策矩陣（DM）。矩陣中的每一行node(f11,f12…f1m)表示某節點中的剩余可用資源組Node(rcpu,rmemory…)。矩陣的行數為節點的個數n，列數為評測節點的m個資源標準(cpu,memory,IO…)。因此，矩陣中的fij代表第i個節點中剩余可利用j資源的數值，若f12=60，則表示第一個節點第二類可用資源為60%。

由于應用可能對單一資源依賴，故需根據資源敏感度數據計算修正后的DM'：

其中k為該應用在nodei上的運行個數，資源敏感度由式（1）計算得到，目的是使得對資源敏感的應用盡量均勻分布在Node集群節點中。

2）通過式（3）、（4）帶入式（2）中計算，得到節點資源歸一化決策矩陣（NDM）。

3）計算加權歸一化決策矩陣（WNDM）。加權歸一化值vij的計算方式如式（6）所示：

公式中wj表示的是第j個標準所占的權重而且

4）根據權重格式化的值來確定理想解（S+）和最差的解（S-）。

式中I+表示正向標準，比如剩余CPU 資源、剩余內存資源、帶寬、CPU 核心數等；I-表示反向標準，比如，IO占用率等。

5）分別計算當中的n個節點與理想節點和最差節點的距離尺度，即每個節點到最優解的距離SM+和最差結果的距離SM-，使用n維度歐式距離來計算，如式（10）~（11）所示：

6）式（12）計算理想貼近度Ci：

最后將節點根據理想解的貼近度大小進行排序，排序結果貼近度值越大，說明目標越優，將優先在此節點中分配需要增加的應用。而貼近度值越小，說明該節點上的資源最緊張，會優先減少該節點上的應用。

4 實驗與結果分析

4.1 實驗環境和實驗計劃

本次實驗中，我們使用了四臺阿里云服務器，一臺作為Master 節點，配置為1CPU（1000m CPU =1CPU）內存為1GB。其他三臺作為應用節點每臺處理器的計算資源為2CPU，內存為4GB，硬盤為256G 構建用戶集群。分別在使用默認的集群方案和本文的集群方案進行實驗測試。四臺服務器運行的應用如表1所示。

表1 服務器配置和節點角色

構建應用所需要的計算資源如表2所示。

表2 構建應用所需計算資源

“/memory”每次訪問會建立一個10KB 的數組并在40s 后釋放數組占用的內存空間和對象；“/cpu”應用執行一些CPU 密集型計算且占用很少的內存資源；“/io”應用每次請求將做一些磁盤IO 的操作，并將占用較多cpu和內存資源，持續20s。

使用Jmeter 壓力測試工具［17］創建第一個測試應用Test1。Test1測試計劃：

1）在集群中添加一個CIO；

2）使用Jmeter 啟動一個有1000 個線程的線程組A，在1min 內完成啟動，然后線程組開始訪問應用memory，時間間隔為1s，持續時間為300s。

第二個測試應用Test2，測試程序計劃：

1）使用Jmeter 創建一個有500 個線程的線程組B，和一個有100個線程的線程組C，在1min內完成啟動。

2）然后線程組B 和C 開始分別訪問應用/memory、/cpu和/io，時間間隔為1s，持續時間為200s。

4.2 性能評估

在改進前后的集群中分別部署這兩個測試應用。首先讓應用Test1 在改進后的集群中運行，集群的內存剩余百分比情況和應用A 在集群中的個數如圖3 所示。圖中可以看到集群充分利用了集群中的空閑資源來創建更多的應用A，從而使應用A 能夠一直保持健康的運行狀態。從圖4 可以看到，應用A通過使用本文的調度算法均勻的分布在各節點中，從而盡可能地避免應用對單一資源的競爭，使應用訪問速度得到來提高。

圖3 集群剩余內存百分比和應用A數量

圖4 應用A在各節點上分布圖

然后讓應用A和應用TestB在同時改進前后的集群中運行，記錄集群中的應用數量。如圖5 所示，在改進后的集群中，當應用負載增加時，改進的集群可以通過負載情況增加或減少相應的應用實例個數，且增加的集群按照本文的調度方案被均勻的分布在了節點中。而在改進前的用戶集群中，如圖6 所示，隨著測試應用的持續訪問，改進前的集群在一段時間后由于內存不足導致節點中應用重啟，在測試階段中出現了三次OOM 異常，用戶節點的內存利用率不到30%。而在改進后的集群中，隨著訪問的增多，通過我們的調度方案，用戶集群的CPU利用率、內存利用率得到了明顯的提高。隨著訪問峰值過后，調度模塊開始減少集群中的應用數量，最后訪問停止后，集群中的應用數量恢復至最初狀態。

圖5 各應用在集群中的總個數

圖6 Test2運行時集群各資源利用率

如表3 所示，應用Test2 在改進前后的集群上分別發送了約495000 次請求，在改進前的集群中運行時出現了資源不足的錯誤而導致平均72.42%的請求都是錯誤的，而在改進后的集群中，平均響應時間為17ms，且均訪問成功。

表3 改進前后系統響應狀態對照表

5 結語

本文在用戶的角度下，基于用戶服務集群加入了監控、調度系統，并考慮到集群資源的動態變化以及節點中應用對系統資源的敏感程度，提出了一種基于TOPSIS 算法的動態調度算法。通過本文對用戶集群的改進，集群在面對大規模訪問時在保證QOS的同時無需購買額外的云服務器設施，大大提高了用戶集群資源的利用率，節省了用戶的成本。本文提供的方案雖然通過了實驗時的各種測試，但考慮到真實的生產環境中的環境會更加惡劣。未來的工作將結合真實的生產環境中進一步研究和優化模型的準確性。