劉殊旸，張曼怡，曹 強

(華中科技大學武漢光電國家研究中心，湖北武漢430074)

1 引言

虛擬化技術［1］已經(jīng)成為云計算領域中不可或缺的一部分。容器［2，3］作為一種輕量虛擬化技術，相較于基于虛擬機的全虛擬化方式，可以更細粒度地高效使用資源［4］。近幾年來，以 Docker為代表的多種容器工具發(fā)展迅猛［5，6］。Docker是一個部署、執(zhí)行和管理容器的工具，使用官方的Docker hub所提供的標準鏡像可以快速構建容器，實現(xiàn)秒級啟動，在版本保存上更加輕便和低成本［7］。Docker的資源管理機制提供了默認資源設置和手動資源配置這兩種途徑，用戶在創(chuàng)建容器時可以使用默認資源配置，也可以根據(jù)需求分配CPU、內(nèi)存和I/O資源，但是無法在運行過程中根據(jù)應用容器的實際資源需求來調(diào)整資源配置。Docker對所有容器的資源分配采用公平策略，不區(qū)分其中運行的應用類型。然而，在實時型應用容器和批處理型應用容器同時運行時，可能會由于資源分配不足或者不平衡導致實時型應用的性能無法達到服務要求;在服務強度(每秒最大請求數(shù))變化時，無法及時調(diào)整資源配置。另外，Docker不限制容器實例的增加，其占用的總資源可能會超過物理機資源限制，使得一些正常運行的容器實例由于資源不足而異常中斷。當運行中的容器實例都偏向使用某種單一資源時，會造成該資源競爭激烈，而其他資源都處于空閑狀態(tài)的現(xiàn)象，導致物理機的整體資源利用率比較低。

目前已有一些針對實現(xiàn)Docker調(diào)度的研究工作。Monsalve等人［8］針對Docker集群環(huán)境提出使用CFS(Completely Fair Scheduler)調(diào)度模式，將切分時間片的概念擴展到虛擬化容器層級，解決CPU資源過度使用的問題。Dusia等人［9］針對Docker集群網(wǎng)絡負載的資源分配提出對應用容器設置不同的優(yōu)先級，保證優(yōu)先級高的應用容器可以獲得更多的網(wǎng)絡資源。Mcdaniel等人［10］提出設置容器優(yōu)先級來為容器分配對應比例的I/O資源。Meng等人［11］基于時序分析提出了一種資源預測模型，避免計算資源浪費以及集群動態(tài)擴展中可能帶來的性能損失。Guan等人［12］提出了一種基于Docker容器的數(shù)據(jù)中心資源分配方法，合理調(diào)度數(shù)據(jù)中心資源。上述研究并沒有清楚地分析同構和異構容器下Docker運行時的資源-性能關系，也沒有提出基于異構容器類型的運行時精確動態(tài)調(diào)度機制，在保證性能的前提下，最大化資源利用率。

本文通過實驗分析了標準容器的資源使用情況和不同類型應用容器的運行特征，提出一種基于運行時的Docker動態(tài)調(diào)度算法，在容器實例運行過程中對其實際資源使用情況進行實時監(jiān)控，根據(jù)應用容器的運行特征及當前資源使用情況判斷是否產(chǎn)生資源競爭，然后動態(tài)調(diào)整容器的資源分配，在保證實時型應用容器性能滿足服務要求的前提下，盡量減少對其他運行容器的性能影響。算法還根據(jù)節(jié)點運行現(xiàn)狀，推薦可運行的應用容器，提升整體資源利用率。

2 容器運行時資源使用分析

首先通過實驗測試方法，對于代表性應用的Docker實例，進行資源分配和性能實驗分析，為后續(xù)調(diào)度打下基礎。

2．1 實驗平臺

實驗具體配置情況如表1所示。

Table 1 Configuration information of the test machine表1 測試機器配置信息

2．2 容器性能評價指標

容器中運行的測試程序可以分為批處理型程序和實時型程序，根據(jù)其特征，分別選取了針對性的監(jiān)控性能指標。對于批處理型程序，主要的監(jiān)控性能指標有CPU利用率、內(nèi)存占用量、讀磁盤數(shù)據(jù)量、寫磁盤數(shù)據(jù)量、執(zhí)行時間和吞吐率;對于實時型程序，主要的監(jiān)控性能指標有CPU利用率、內(nèi)存占用量、實時平均響應時間、讀磁盤數(shù)據(jù)總量和寫磁盤數(shù)據(jù)總量。

執(zhí)行時間只針對批處理型程序，是程序從開始到完成的總執(zhí)行時間;實時平均響應時間只針對實時型程序，是每秒內(nèi)測試程序對請求作出響應的平均時間。將測試程序運行中的每周期執(zhí)行指令數(shù)IPC(Instructions Per Circle)和每秒執(zhí)行的指令數(shù)IPS(Instructions Per Second)作為吞吐率的參考值。

2．3 標準測試容器的資源使用情況

為了了解測試程序在容器環(huán)境下的實際資源使用情況，本文選取Linux系統(tǒng)下的一個標準壓力測試程序Stress作為測試程序，對其容器化，分析CPU利用率和內(nèi)存占用量。

Stress程序運行時，設置-c參數(shù)指定產(chǎn)生n個進程，每個進程反復計算隨機數(shù)的平方根，長時間占用CPU資源，模擬CPU密集型程序;設置-m參數(shù)指定產(chǎn)生n個進程，每個進程不斷調(diào)用內(nèi)存分配malloc和內(nèi)存釋放free函數(shù)，長時間占用內(nèi)存資源，模擬內(nèi)存密集型程序。

(1)模擬CPU密集型程序。

對容器實例采用默認資源配置，分別運行單個和4個標準測試容器(每個容器8進程)，在運行過程中，對每一個容器實例的CPU資源使用情況進行實時監(jiān)測。

圖1為單個和4個標準測試容器運行時的CPU利用率對比圖。圖1a中，當進程數(shù)為8時，單個容器的CPU利用率達到了800%;圖1b中，每個容器的CPU利用率在400%上下浮動，相比單個容器，CPU利用率下降了400%，這說明此時已經(jīng)出現(xiàn)了CPU資源競爭的現(xiàn)象。

(2)模擬內(nèi)存密集型程序。

設置 malloc內(nèi)存的字節(jié)數(shù)為3 GB，在運行240 s后釋放內(nèi)存。對容器實例采用默認資源配置，分別運行單個和4個標準測試容器(每個容器1進程)，在運行過程中，對每一個容器實例的內(nèi)存資源使用情況進行實時監(jiān)測。

圖2為單個和4個標準測試容器時的實時內(nèi)存占用量。由圖2可知，在內(nèi)存資源充足時，每個標準測試容器在同一時間使用內(nèi)存大小基本一致。因此，當多個容器同時運行時，需要對其內(nèi)存需求量進行提前計算，以避免出現(xiàn)物理機內(nèi)存空間不足的情況。

2．4 基于容器的應用運行時特征

Docker為用戶提供了對CPU份額和塊I/O權重的設置方式，但是在使用過程中，如果不清楚測試程序的資源使用特征，很難確定設置資源類型和具體值。因此，在多個容器實例同時運行時，需要根據(jù)每個容器中運行程序的實際運行特征，來實時動態(tài)調(diào)整其資源分配情況，在資源有限的情況下，最大化物理機的整體資源利用率。

本文在容器環(huán)境下運行4個典型應用(Memcached［13］、 Speccpu2006［14］、 Parsec［15］、 Filebench［16］)，并根據(jù)選取的性能指標總結它們的性能特征。

特征表如表2所示，其中最小CPU需求量指物理機上運行的同種應用容器的個數(shù)滿足服務品質(zhì)協(xié)議SLA(Service-Level Agreement)要求的前提下，單個容器需要的最小CPU資源。表2中“－”表示該應用容器不存在該特征指標。

Table 2 Operating characteristics of a single application under containers表2 容器環(huán)境下單個應用運行特征表

3 Docker動態(tài)調(diào)度算法設計與實現(xiàn)

動態(tài)調(diào)度算法實時監(jiān)控運行中的容器實例，并結合運行容器及系統(tǒng)狀態(tài)，快速調(diào)整容器的資源配置;同時根據(jù)當前節(jié)點資源使用情況，推薦運行最優(yōu)的實例類型。

3．1 元數(shù)據(jù)設計

通過三張元數(shù)據(jù)表來記錄調(diào)度過程中需要的數(shù)據(jù):(1)應用運行特征表:存儲不同應用在容器環(huán)境下的運行特征;(2)容器實例狀態(tài)表:存儲每個容器實例中的運行應用情況和資源分配情況;(3)物理機資源使用表:存儲每個物理機上的CPU、內(nèi)存使用情況。

3．2 優(yōu)先級設計

(1)優(yōu)先級設置。

默認設置:實時型應用的優(yōu)先級高于批處理型應用，同種類型應用的優(yōu)先級均為同一級。批處理型應用容器的優(yōu)先級默認為1，實時型應用容器的優(yōu)先級默認為2。

手動設置:用戶通過系統(tǒng)提供的接口，查看當前物理機上運行中的容器優(yōu)先級設置情況，并在新增容器時手動指定優(yōu)先級。優(yōu)先級值越大，則優(yōu)先級越高，可使用的資源數(shù)越多。在手動設置容器實例優(yōu)先級方式下，依然優(yōu)先滿足實時型應用的資源需求，將實時型應用容器的優(yōu)先級設置為指定值的兩倍。

(2)優(yōu)先級更改。

更改實時型應用優(yōu)先級:判斷當前物理機是否出現(xiàn)資源競爭，若存在資源競爭，此時實時型應用容器在運行中會進行動態(tài)調(diào)控，可以保證實時型應用在滿足服務要求的前提下，只占用盡量少的資源，用戶只需要對優(yōu)先級進行調(diào)整;若不存在，則修改容器實例狀態(tài)表中的優(yōu)先級字段為指定值的兩倍，并重新計算分配CPU份額，修改相應字段值。

更改批處理型應用優(yōu)先級:將容器實例狀態(tài)表中的指定容器的優(yōu)先級修改為指定值，然后根據(jù)該引用的偏重使用資源類型，重新計算CPU份額或塊I/O權重，修改相應字段值。

3．3 增加和刪除容器實例設計

(1)增加容器實例。

用戶通過系統(tǒng)提供的接口請求創(chuàng)建應用容器。在創(chuàng)建時需要根據(jù)應用容器的運行特征及節(jié)點資源使用情況，判斷是否可以完成新增操作。

(2)刪除容器實例。

通過系統(tǒng)提供的接口，可以根據(jù)實際需求停止并刪除正在運行的容器實例，同時刪除容器實例狀態(tài)表中對應的表項，更新物理機資源使用表。然后查詢應用狀態(tài)表獲得當前正在運行的所有應用容器的線程數(shù)之和，如果小于物理機最大線程數(shù)，則認為此時不存在資源競爭，將物理機資源使用表中的資源競爭狀態(tài)值置為0。

3．4 資源競爭調(diào)度設計

當物理機上運行環(huán)境變化時，可能會出現(xiàn)資源競爭。由于在容器實例運行前會判斷是否滿足內(nèi)存限制，因此在運行過程中會存在競爭的關鍵性資源是CPU資源。通過以下兩種方式來判斷是否已經(jīng)處于資源競爭狀態(tài):

(1)當執(zhí)行新增容器操作和刪除容器操作時，查詢并計算所有處于運行狀態(tài)的應用容器的線程數(shù)之和，如果大于物理機最大線程數(shù)，則存在資源競爭。

(2)當查詢到數(shù)據(jù)表中資源競爭狀態(tài)為0時，表示不存在資源競爭。之后每3 s獲取一次所有運行的應用容器的CPU利用率，并查詢其在無競爭狀態(tài)下的平均CPU利用率，對比兩個值，如果其差值超過100%，則認為可能出現(xiàn)了資源競爭情況，接下來每秒監(jiān)測一次實時CPU利用率，總共監(jiān)測3次，如果每次差值都超過100%，則確定處于資源競爭狀態(tài)。

當確定出現(xiàn)了資源競爭后，將物理機整體資源狀態(tài)表中的資源競爭狀態(tài)值更新為1。

3．5 服務強度變化調(diào)度設計

在實際環(huán)境中，實時型應用容器的服務強度隨時可能發(fā)生變化，因此在服務強度發(fā)生變化時，需要及時調(diào)整資源分配。由于本文中選用的實時型應用容器的關鍵資源為CPU，因此在服務強度變化調(diào)度中，主要處理CPU資源的分配。

當沒有出現(xiàn)資源競爭時，只在服務強度增大時，增加實時型應用容器的CPU資源分配。當服務強度減小時，由于此時CPU資源充足，則不需要對分配的CPU資源進行調(diào)整。當出現(xiàn)資源競爭時，則適當減少容器實例當前的CPU份額值，僅保障其服務性能滿足SLA協(xié)議要求。

3．6 應用容器推薦設計

根據(jù)當前節(jié)點資源使用情況，推薦可運行的應用容器，減少與現(xiàn)有運行容器資源競爭的同時，充分利用空閑資源，提高整體資源利用率。針對CPU資源，當系統(tǒng)處于資源競爭狀態(tài)時，認為CPU資源已經(jīng)處于競爭狀態(tài)，而內(nèi)存資源和塊I/O資源都認為是空閑資源。查詢應用容器運行特征表，找到偏重使用空閑資源且競爭資源需求小的應用，并經(jīng)過增加容器實例算法判斷可以增加后，向用戶推薦運行該應用容器。

3．7 系統(tǒng)實現(xiàn)

使用Python語言實現(xiàn)動態(tài)調(diào)度系統(tǒng)，調(diào)度系統(tǒng)模塊圖如圖3所示。

動態(tài)調(diào)度系統(tǒng)命令接口如表3所示。

Table 3 Scheduling system command table表3 調(diào)度系統(tǒng)命令表

4 實驗結果及分析

4．1 實驗平臺

實驗平臺具體配置如表1所示。測試過程中，使用兩臺服務器分別作為測試主節(jié)點和客戶端代理。

4．2 實驗內(nèi)容

4．2．1 多容器正常運行測試

同時運行1個Memcached容器和1個Parsec容器。圖4為使用調(diào)度系統(tǒng)前后2個容器運行過程中的CPU利用率。由圖5可知，使用調(diào)度系統(tǒng)基本不會對應用運行中的CPU利用率造成影響。

圖5為使用調(diào)度前后Memcached容器(服務強度為32 000)的平均響應時間。由圖5可知，在兩種情況下，平均響應時間基本處于應用運行正常范圍內(nèi)。

表4為Parsec容器使用調(diào)度前后的運行性能情況，可以看出使用調(diào)度系統(tǒng)基本上沒有對Parsec應用運行的性能造成影響。

Table 4 Performance specifications of Parsec containers before and after scheduling表4 使用調(diào)度系統(tǒng)前后Parsec容器的運行性能指標

4．2．2 推薦新增應用容器測試

同時運行3個Parsec應用容器，根據(jù)表2，其最小CPU需求量為483%，已經(jīng)達到了CPU資源使用限制，然后通過動態(tài)調(diào)度算法推薦機制，在節(jié)點上新增4個Filebench應用容器。表5為使用調(diào)度前后的容器性能情況。

Table 5 Performance of containers before and after scheduling表5 使用調(diào)度前后的容器性能情況

平均 I/O 吞吐率/(kb/s) 4 075．599 57．22 I/O平均響應時間/(ms/op)13．6 -

從表5中可以看出，在CPU資源基本達到飽和時，算法分析現(xiàn)有空閑資源，新增偏重相應資源的應用容器，將節(jié)點上能夠運行的容器實例數(shù)增大2．3倍時，對原本運行容器只造成了9．3%的性能損耗，提高了整體資源利用率。

4．2．3 資源競爭調(diào)度測試

同時運行1個Memcached容器(服務強度為80 000)、2個 Parsec容器和1個 Speccpu2006容器。由于運行容器中的線程數(shù)之和已經(jīng)超過了測試物理機可同時運行的CPU線程數(shù)，因此在Parsec容器運行完成之前，系統(tǒng)處于資源競爭狀態(tài)。

表6為處于資源競爭狀態(tài)下，使用調(diào)度前后的性能指標對比。從表6中可以看到，在處于資源競爭狀態(tài)下的運行過程前309 s中，使用調(diào)度可以在90．29%的時間里滿足Memcached容器的響應時間小于10 ms的SLA性能要求;而不使用調(diào)度時，只有3．24%的時間內(nèi)可以滿足性能要求，因此調(diào)度對于資源競爭下實時型應用的性能提升非常明顯。同時對比其他幾個批處理型應用的運行情況，可以看出，使用調(diào)度后兩個Parsec容器運行完成的平均時間，相比不使用調(diào)度，只增加了9 s，而使用調(diào)度后Speccpu2006容器的執(zhí)行時間比不使用更短，這說明調(diào)度算法在優(yōu)先保證實時型應用容器性能的同時，對批處理型應用容器造成的性能損耗非常小。

Table 6 Container operational performance indicators before and after scheduling表6 使用調(diào)度前后的容器運行性能指標

4．2．4 服務強度變化調(diào)度測試

同時運行1個Memcached容器、2個Parsec容器和1個Speccpu2006容器，在Parsec容器運行完成之前均處于CPU資源競爭環(huán)境。在運行過程中首先將Memcached容器的服務強度設置為48 000，在180 s后增大到80 000。

圖6a為使用調(diào)度前后Memcached容器平均響應時間。服務強度比較低時，兩種方式都能滿足性能要求。服務強度增大后，不使用調(diào)度的平均響應時間基本超過了10 ms;而使用調(diào)度后可以在很短的時間內(nèi)將平均響應時間控制在10 ms內(nèi)。圖6b為使用調(diào)度前后Memcached容器和Speccpu2006容器的CPU利用率。Speccpu2006容器在服務強度變化前后CPU利用率基本不變。Memcached容器在服務強度較低時，使用調(diào)度前后的CPU利用率相差不大;服務強度變大后，使用調(diào)度后的CPU利用率比不使用時略高。圖6c為使用調(diào)度前后2個Parsec容器的CPU利用率。由圖6c可知，使用調(diào)度與否對Parsec容器的CPU利用率影響并不明顯。因此，調(diào)度算法在優(yōu)先保障實時型應用容器的性能的同時，也能保證批處理型應用容器的運行性能。

5 結束語

本文針對當前Docker的資源管理機制的不足提出了一種基于運行時的動態(tài)調(diào)度算法，在優(yōu)先保證實時型應用容器的服務性能滿足SLA協(xié)議要求的同時，也能保證其他批處理型應用容器的運行性能。另外，調(diào)度推薦機制可以根據(jù)節(jié)點的資源使用情況，推薦運行最優(yōu)實例類型，減少與現(xiàn)有運行容器的資源競爭，提高系統(tǒng)整體資源利用率。實驗表明，使用動態(tài)調(diào)度算法不會影響應用容器的正常運行。當節(jié)點上同時運行實時型和批處理型應用容器時，采用調(diào)度機制可以將實時型應用容器滿足服務要求的時間段延長87．5%，僅對同時運行的批處理型應用容器最多造成2．9%的性能開銷。此外，調(diào)度算法推薦機制將節(jié)點上能夠運行的容器實例數(shù)增大2．3倍時，對原本運行的批處理型應用容器最多只造成9．3%的性能損耗。接下來將進一步選取其他類型應用測試調(diào)度算法性能，并在該算法的基礎上研究集群的資源動態(tài)調(diào)整。