Docker 動態(tài)調(diào)度算法的設(shè)計(jì)與實(shí)現(xiàn)*

劉殊旸，張曼怡，曹 強(qiáng)

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

1 引言

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

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

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

2 容器運(yùn)行時(shí)資源使用分析

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

2．1 實(shí)驗(yàn)平臺

實(shí)驗(yàn)具體配置情況如表1所示。

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

2．2 容器性能評價(jià)指標(biāo)

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

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

2．3 標(biāo)準(zhǔn)測試容器的資源使用情況

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

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

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

對容器實(shí)例采用默認(rèn)資源配置，分別運(yùn)行單個(gè)和4個(gè)標(biāo)準(zhǔn)測試容器(每個(gè)容器8進(jìn)程)，在運(yùn)行過程中，對每一個(gè)容器實(shí)例的CPU資源使用情況進(jìn)行實(shí)時(shí)監(jiān)測。

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

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

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

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

2．4 基于容器的應(yīng)用運(yùn)行時(shí)特征

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

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

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

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

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

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

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

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

3．2 優(yōu)先級設(shè)計(jì)

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

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

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

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

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

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

3．3 增加和刪除容器實(shí)例設(shè)計(jì)

(1)增加容器實(shí)例。

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

(2)刪除容器實(shí)例。

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

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

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

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

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

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

3．5 服務(wù)強(qiáng)度變化調(diào)度設(shè)計(jì)

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

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

3．6 應(yīng)用容器推薦設(shè)計(jì)

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

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

使用Python語言實(shí)現(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 實(shí)驗(yàn)結(jié)果及分析

4．1 實(shí)驗(yàn)平臺

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

4．2 實(shí)驗(yàn)內(nèi)容

4．2．1 多容器正常運(yùn)行測試

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

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

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

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

4．2．2 推薦新增應(yīng)用容器測試

同時(shí)運(yùn)行3個(gè)Parsec應(yīng)用容器，根據(jù)表2，其最小CPU需求量為483%，已經(jīng)達(dá)到了CPU資源使用限制，然后通過動態(tài)調(diào)度算法推薦機(jī)制，在節(jié)點(diǎn)上新增4個(gè)Filebench應(yīng)用容器。表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平均響應(yīng)時(shí)間/(ms/op)13．6 -

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

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

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

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

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

4．2．4 服務(wù)強(qiáng)度變化調(diào)度測試

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

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

5 結(jié)束語

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