王小雪，王曉鋒，劉 淵

（江南大學(xué)人工智能與計(jì)算機(jī)學(xué)院，江蘇無(wú)錫 214122）

0 概述

隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展和硬件設(shè)施的迭代更新，為滿(mǎn)足人們對(duì)數(shù)據(jù)處理能力、資源利用率、資源集中化的迫切需求，云計(jì)算［1］技術(shù)應(yīng)運(yùn)而生。OpenStack 是云計(jì)算基礎(chǔ)設(shè)施即服務(wù)（Infrastructure as a Service，IaaS）中重要的云計(jì)算管理平臺(tái)［2］，具備開(kāi)源性、兼容性、靈活性和可擴(kuò)展性。OpenStack 默認(rèn)以虛擬機(jī)為載體發(fā)布和交付服務(wù)應(yīng)用，虛擬機(jī)由全虛擬化技術(shù)等傳統(tǒng)虛擬化技術(shù)生成，需要安裝完整的操作系統(tǒng)，會(huì)消耗大量資源與時(shí)間［3］。近年來(lái)，以Docker 容器為代表的操作系統(tǒng)級(jí)虛擬化技術(shù)因其輕量高效而備受關(guān)注［4］。容器相較于虛擬機(jī)具有更快的部署和銷(xiāo)毀速度、更好的服務(wù)性能以及更高的資源利用率等優(yōu)點(diǎn)［5］。鑒于OpenStack 與Docker 的優(yōu)勢(shì)，兩者的集成是云計(jì)算發(fā)展的必然，OpenStack可以為容器提供更加靈活、細(xì)粒度的管控，Docker 可以豐富OpenStack 生態(tài)系統(tǒng)，提高云平臺(tái)的資源利用率并優(yōu)化云平臺(tái)的整體性能［6-7］。目前，OpenStack與Docker 的集成已廣泛應(yīng)用于大數(shù)據(jù)分析［8］、網(wǎng)絡(luò)仿真［9］、云邊協(xié)同計(jì)算［10］等領(lǐng)域。

資源利用率的提高可以降低能耗并節(jié)約成本［11-12］。面向云計(jì)算領(lǐng)域的高資源利用率和低成本需求［13］，設(shè)計(jì)高效的調(diào)度模型受到了學(xué)者們的廣泛關(guān)注。文獻(xiàn)［14］從CPU、內(nèi)存、網(wǎng)絡(luò)帶寬和磁盤(pán)4 個(gè)維度出發(fā)，建立基于最小化數(shù)據(jù)中心能耗、最大化數(shù)據(jù)中心效用以及最小化服務(wù)器數(shù)量的多目標(biāo)優(yōu)化的虛擬機(jī)調(diào)度模型，能在降低能耗的同時(shí)提高數(shù)據(jù)中心效用。文獻(xiàn)［15］通過(guò)監(jiān)控和預(yù)測(cè)虛擬機(jī)的資源使用，降低了物理機(jī)過(guò)載情況的發(fā)生，并通過(guò)虛擬機(jī)遷移與調(diào)度有效減少了運(yùn)行的物理機(jī)數(shù)量，實(shí)現(xiàn)了云數(shù)據(jù)中心能耗的降低和資源利用率的提高。文獻(xiàn)［16］針對(duì)資源受限云系統(tǒng)中具有時(shí)間約束的用戶(hù)請(qǐng)求，提出一種時(shí)間敏感的資源分配和虛擬機(jī)調(diào)度方法，實(shí)現(xiàn)了多個(gè)異構(gòu)節(jié)點(diǎn)之間的資源高效利用。文獻(xiàn)［17］基于OpenStack 云平臺(tái)，使用動(dòng)態(tài)資源分配與節(jié)能算法，釋放了虛擬機(jī)占用的空閑資源，提高了云平臺(tái)的資源利用率并降低了系統(tǒng)能耗。以上文獻(xiàn)均是基于虛擬機(jī)對(duì)系統(tǒng)資源利用率提高問(wèn)題進(jìn)行研究。

在基于云計(jì)算的Docker 容器調(diào)度模型方面，學(xué)者們也進(jìn)行大量研究并取得了一定的研究成果。文獻(xiàn)［3］將容器到虛擬機(jī)的部署問(wèn)題轉(zhuǎn)化為容器集合與虛擬機(jī)集合之間的穩(wěn)定匹配問(wèn)題，并設(shè)計(jì)了相應(yīng)的匹配規(guī)則，以實(shí)現(xiàn)通過(guò)容器提高云環(huán)境資源利用率并降低能耗，但該方案中虛擬機(jī)對(duì)容器的偏好規(guī)則僅考慮CPU 資源。文獻(xiàn)［18］以最大化設(shè)備資源利用率以及Docker 容器性能為目標(biāo)，提出一種基于深度學(xué)習(xí)的容器調(diào)度方法，可自動(dòng)為容器分配最優(yōu)CPU 資源，但是該方法需要提前采集大量的訓(xùn)練數(shù)據(jù)集進(jìn)行建模，這會(huì)增加容器調(diào)度的實(shí)際應(yīng)用難度?？傮w看來(lái)，當(dāng)前基于云計(jì)算的Docker 容器調(diào)度研究較少，在資源利用率提升方面需做進(jìn)一步研究。

鑒于OpenStack 與Docker 集成的優(yōu)勢(shì)，如何有效調(diào)度Docker 容器以保障OpenStack 中資源的高效利用成為亟需解決的問(wèn)題。Nova-Docker［19］采用OpenStack 中Nova 組件的調(diào)度模型，將容器作為虛擬機(jī)進(jìn)行調(diào)度，首先使用過(guò)濾算法從OpenStack 的所有計(jì)算節(jié)點(diǎn)中選出滿(mǎn)足容器資源請(qǐng)求的節(jié)點(diǎn)作為候選節(jié)點(diǎn)，然后通過(guò)計(jì)算各個(gè)節(jié)點(diǎn)的權(quán)值為容器選擇最優(yōu)計(jì)算節(jié)點(diǎn)。然而，與虛擬機(jī)不同，Docker 通過(guò)共享Linux 內(nèi)核的方式來(lái)提供操作系統(tǒng)級(jí)別的虛擬化，將基于虛擬機(jī)的調(diào)度模型直接應(yīng)用于Docker 具有不確定性［20］。Zun［21］作為Nova-Docker 的替代，在進(jìn)行容器調(diào)度時(shí)隨機(jī)選取最優(yōu)計(jì)算節(jié)點(diǎn)，未能考慮OpenStack中資源的合理利用。Yun［22］進(jìn)一步對(duì)Nova-Docker 和Zun 的調(diào)度模型進(jìn)行改進(jìn)，針對(duì)容器的多樣化資源需求為容器選取最優(yōu)計(jì)算節(jié)點(diǎn)，實(shí)現(xiàn)了OpenStack 中資源的合理利用。但是，以上3 種Docker 容器調(diào)度模型均基于用戶(hù)對(duì)容器的初始資源請(qǐng)求對(duì)容器進(jìn)行調(diào)度并分配資源，未充分考慮容器運(yùn)行時(shí)的實(shí)際資源使用情況。在多數(shù)情況下容器并不會(huì)以滿(mǎn)載的狀態(tài)運(yùn)行，根據(jù)容器的初始資源請(qǐng)求對(duì)容器分配的資源在大部分時(shí)間內(nèi)都是空閑的，這會(huì)導(dǎo)致嚴(yán)重的資源浪費(fèi)［23］。

由于Yun不僅實(shí)現(xiàn)了OpenStack與Docker的集成，而且在部署效率、吞吐量、資源限制和兼容性方面均優(yōu)于Nova-Docker 和Zun，因此本文基于Yun 設(shè)計(jì)并實(shí)現(xiàn)Docker 調(diào)度模型（Docker Scheduling Model，DSM）。該模型針對(duì)現(xiàn)有OpenStack 與Docker 集成方案采用的調(diào)度模型存在資源利用率不高的問(wèn)題，設(shè)計(jì)資源可用度評(píng)估與優(yōu)先級(jí)決策（Resource Availability-evaluation and Priority Decision-making，RAPD）調(diào)度機(jī)制對(duì)容器實(shí)施調(diào)度。

1 基于OpenStack 的Docker 調(diào)度模型

本文基于OpenStack 的Docker 調(diào)度模型如圖1所 示。DSM 通過(guò)與OpenStack 的Keystone、Glance以及Neutron 組件的API 進(jìn)行交互，獲取創(chuàng)建容器所需的鏡像、網(wǎng)絡(luò)等資源；通過(guò)調(diào)用Docker Engine 提供的API 部署容器，實(shí)現(xiàn)對(duì)容器生命周期的高效靈活管控。DSM 主要包含初始化模塊、資源實(shí)時(shí)感知模塊、容器調(diào)度模塊、資源實(shí)時(shí)監(jiān)測(cè)模塊和容器遷移模塊。

圖1 基于OpenStack 的Docker 調(diào)度模型Fig.1 Docker scheduling model based on OpenStack

1.1 初始化模塊

初始化模塊負(fù)責(zé)接收用戶(hù)發(fā)送的創(chuàng)建容器所需的相關(guān)參數(shù)，詳細(xì)的用戶(hù)請(qǐng)求參數(shù)信息如表1 所示。通過(guò)對(duì)用戶(hù)請(qǐng)求參數(shù)進(jìn)行解析，可以得到容器的基本配置參數(shù)（容器名稱(chēng)、容器鏡像、容器初始運(yùn)行命令、容器的網(wǎng)絡(luò)信息及容器的特權(quán)模式是否開(kāi)啟）和容器的初始資源請(qǐng)求參數(shù)（CPU 請(qǐng)求規(guī)格和內(nèi)存請(qǐng)求規(guī)格）。DSM 可基于容器的基本配置參數(shù)獲取創(chuàng)建容器所需的資源，容器的初始資源請(qǐng)求參數(shù)將作為容器資源請(qǐng)求參數(shù)，為容器調(diào)度模塊提供支持。

表1 用戶(hù)請(qǐng)求參數(shù)信息Table 1 User request parameter information

1.2 資源實(shí)時(shí)感知模塊

DSM 引入資源實(shí)時(shí)感知模塊，如圖2 所示。資源實(shí)時(shí)感知模塊負(fù)責(zé)采集OpenStack 中各個(gè)計(jì)算節(jié)點(diǎn)的資源信息，包括可用資源信息和資源利用率信息，并將各個(gè)計(jì)算節(jié)點(diǎn)的資源信息進(jìn)行匯總。

圖2 資源實(shí)時(shí)感知模塊Fig.2 Real-time resource awareness module

資源實(shí)時(shí)感知模塊基于消息隊(duì)列實(shí)現(xiàn)對(duì)OpenStack 中計(jì)算節(jié)點(diǎn)資源信息的采集。消息隊(duì)列由消息中間件實(shí)現(xiàn)，基于高級(jí)消息隊(duì)列協(xié)議（Advanced Message Queuing Protocol，AMQP）開(kāi)發(fā)。消息隊(duì)列的存在可以使消息發(fā)送方和消息接收方在時(shí)間、空間和同步等方面解耦，從而實(shí)現(xiàn)發(fā)送方和接收方消息的異步傳輸、數(shù)據(jù)流量緩沖和數(shù)據(jù)持久化［24］?；贏(yíng)MQP 開(kāi)發(fā)的消息隊(duì)列主要由消息發(fā)送方（Producer）、交換機(jī)（Exchange）、綁定（Binding）、隊(duì)列（Queue）和消息接收方（Consumer）構(gòu)成。資源實(shí)時(shí)感知模塊的消息隊(duì)列設(shè)計(jì)如圖3 所示。資源實(shí)時(shí)感知模塊作為Consumer 監(jiān)聽(tīng)名為“dsm_awareness”的Queue，該Queue 以“dsm_resources_awareness”為binding key 與名為“dsm_resources”的Exchange 綁定。各個(gè)計(jì)算節(jié)點(diǎn)作為Producer 將routing key 為“dsm_resources_awareness”的消息（記錄了該計(jì)算節(jié)點(diǎn)的資源信息）發(fā)送至“dsm_resources”，“dsm_resources”會(huì)將該消息轉(zhuǎn)發(fā)至“dsm_awareness”進(jìn)行保存，等待資源實(shí)時(shí)感知模塊從中獲取消息。

圖3 消息隊(duì)列設(shè)計(jì)Fig.3 Message queue design

同時(shí)，資源實(shí)時(shí)感知模塊會(huì)根據(jù)各個(gè)節(jié)點(diǎn)的資源利用率信息，計(jì)算該節(jié)點(diǎn)對(duì)應(yīng)的負(fù)載，假設(shè)OpenStack 中所有計(jì)算節(jié)點(diǎn)的資源利用率為Ut=，t為資源的類(lèi)型，m為計(jì)算節(jié)點(diǎn)的個(gè)數(shù)，Uti為第i個(gè)計(jì)算節(jié)點(diǎn)的資源t的利用率，則計(jì)算節(jié)點(diǎn)i的負(fù)載可通過(guò)式（1）計(jì)算得出：

其中：n為資源類(lèi)型的數(shù)目；wt為用戶(hù)為資源t定義的優(yōu)先級(jí)乘數(shù)，本文設(shè)置wcpu=wmemory=0.5，用戶(hù)可根據(jù)業(yè)務(wù)需求，通過(guò)配置文件修改wt值，使得某項(xiàng)資源的優(yōu)先級(jí)高于其他資源。資源實(shí)時(shí)感知模塊通過(guò)匯總OpenStack 中各個(gè)計(jì)算節(jié)點(diǎn)的資源信息并計(jì)算各個(gè)節(jié)點(diǎn)的負(fù)載，為容器調(diào)度模塊提供支持。

1.3 容器調(diào)度模塊

容器調(diào)度模塊首先將容器的初始資源請(qǐng)求參數(shù)作為容器資源請(qǐng)求參數(shù)，并通過(guò)與資源實(shí)時(shí)感知模塊交互獲取OpenStack 中各個(gè)計(jì)算節(jié)點(diǎn)的資源信息以及負(fù)載信息，將三者作為容器調(diào)度依據(jù)；然后采用RAPD 調(diào)度機(jī)制對(duì)容器進(jìn)行調(diào)度，通過(guò)資源可用度評(píng)估從所有計(jì)算節(jié)點(diǎn)中選出滿(mǎn)足容器資源請(qǐng)求規(guī)格的節(jié)點(diǎn)作為候選節(jié)點(diǎn)，并利用優(yōu)先級(jí)決策從所有候選節(jié)點(diǎn)中為容器選擇最優(yōu)計(jì)算節(jié)點(diǎn)，調(diào)用Docker Engine 提供的API 部署容器。

在容器部署成功后，資源實(shí)時(shí)監(jiān)測(cè)模塊會(huì)獲取容器的實(shí)際資源使用參數(shù)，容器調(diào)度模塊將該參數(shù)作為容器資源請(qǐng)求參數(shù)，對(duì)容器實(shí)施重新調(diào)度，為其選取新的最優(yōu)計(jì)算節(jié)點(diǎn)。將容器當(dāng)前所在的計(jì)算節(jié)點(diǎn)記為源節(jié)點(diǎn)，將對(duì)容器重新調(diào)度后選取的最優(yōu)計(jì)算節(jié)點(diǎn)記為目的節(jié)點(diǎn)，如果源節(jié)點(diǎn)和目的節(jié)點(diǎn)相同，則在不停止容器運(yùn)行的情況下通過(guò)調(diào)用Docker Engine 提供的API 更新容器的資源規(guī)格為其實(shí)際資源使用規(guī)格，釋放容器占用的空閑資源，否則需要對(duì)容器執(zhí)行遷移操作。

1.4 資源實(shí)時(shí)監(jiān)測(cè)模塊

在容器部署成功后，資源實(shí)時(shí)監(jiān)測(cè)模塊通過(guò)Docker 自身提供的“docker stats”命令實(shí)時(shí)獲取容器的資源使用信息。由于容器內(nèi)服務(wù)的工作負(fù)載隨時(shí)間動(dòng)態(tài)變化會(huì)呈現(xiàn)不同的資源需求［25］，因此需要設(shè)定一個(gè)長(zhǎng)時(shí)間間隔（本文設(shè)置為1 h，用戶(hù)可根據(jù)業(yè)務(wù)需求，通過(guò)配置文件自定義該時(shí)間間隔），資源實(shí)時(shí)監(jiān)測(cè)模塊采集該時(shí)間間隔內(nèi)容器的各項(xiàng)資源使用信息，最終各項(xiàng)資源數(shù)值的抖動(dòng)分別穩(wěn)定在一個(gè)固定區(qū)間內(nèi)，資源實(shí)時(shí)監(jiān)測(cè)模塊將每個(gè)區(qū)間的峰值作為容器對(duì)應(yīng)資源的實(shí)際使用參數(shù)，并將容器的實(shí)際資源使用參數(shù)作為容器的資源請(qǐng)求參數(shù)，為容器調(diào)度模塊提供支持。

1.5 容器遷移模塊

如果容器當(dāng)前所在的計(jì)算節(jié)點(diǎn)（源節(jié)點(diǎn)）與對(duì)容器重新調(diào)度后選取的最優(yōu)計(jì)算節(jié)點(diǎn)（目的節(jié)點(diǎn)）不一致，則需要觸發(fā)容器遷移模塊。該模塊負(fù)責(zé)將容器從源節(jié)點(diǎn)遷移到目的節(jié)點(diǎn)，保證遷移前后容器的基本配置、文件系統(tǒng)［26］、內(nèi)存狀態(tài)和網(wǎng)絡(luò)環(huán)境的一致性。容器遷移的執(zhí)行流程如圖4 所示。首先，源節(jié)點(diǎn)與目的節(jié)點(diǎn)建立連接，發(fā)送當(dāng)前待遷移容器的基本配置信息，目的節(jié)點(diǎn)基于此信息，調(diào)用Docker Engine 提供的API 創(chuàng)建一個(gè)與源節(jié)點(diǎn)相同配置的容器。然后，在源節(jié)點(diǎn)上對(duì)容器設(shè)置檢查點(diǎn)，并向目的節(jié)點(diǎn)依次發(fā)送容器的文件系統(tǒng)和內(nèi)存狀態(tài)信息，目的節(jié)點(diǎn)依次接收容器的文件系統(tǒng)數(shù)據(jù)和內(nèi)存狀態(tài)信息文件，并恢復(fù)容器的運(yùn)行。最后，目的節(jié)點(diǎn)在恢復(fù)容器的網(wǎng)絡(luò)環(huán)境后，會(huì)斷開(kāi)與源節(jié)點(diǎn)的連接，至此，容器遷移實(shí)施完成。

圖4 容器遷移執(zhí)行流程Fig.4 Execution flow of container migration

2 資源可用度評(píng)估與優(yōu)先級(jí)決策調(diào)度機(jī)制

DSM 采用RAPD 調(diào)度機(jī)制對(duì)Docker 容器實(shí)施調(diào)度，該機(jī)制主要包含兩個(gè)階段：1）通過(guò)資源可用度評(píng)估階段對(duì)OpenStack 中所有的計(jì)算節(jié)點(diǎn)進(jìn)行評(píng)估，選擇可滿(mǎn)足容器資源請(qǐng)求規(guī)格的計(jì)算節(jié)點(diǎn)作為候選節(jié)點(diǎn)；2）通過(guò)優(yōu)先級(jí)決策階段從所有的候選節(jié)點(diǎn)中選擇優(yōu)先級(jí)最高的計(jì)算節(jié)點(diǎn)作為最優(yōu)計(jì)算節(jié)點(diǎn)。

2.1 資源可用度評(píng)估階段

該階段負(fù)責(zé)從OpenStack 的各個(gè)計(jì)算節(jié)點(diǎn)中找出滿(mǎn)足容器資源請(qǐng)求規(guī)格的節(jié)點(diǎn)作為候選節(jié)點(diǎn)。在該階段設(shè)計(jì)了CPU 評(píng)估器（CPUEvaluator）、內(nèi)存評(píng)估器（MemoryEvaluator）、負(fù)載評(píng)估器（LoadEvaluator）這3 個(gè)評(píng)估器，分別根據(jù)計(jì)算節(jié)點(diǎn)的可用CPU、可用內(nèi)存和負(fù)載評(píng)估其是否可以作為候選節(jié)點(diǎn)。資源可用度評(píng)估算法如算法1 所示。算法的輸入是所有的評(píng)估器（evaluators），待評(píng)估計(jì)算節(jié)點(diǎn)的對(duì)象（host，記錄了計(jì)算節(jié)點(diǎn)的CPU、內(nèi)存、資源利用率和負(fù)載等信息）以及容器的資源請(qǐng)求規(guī)格（specifications），算法的輸出是一個(gè)布爾值（o），用于表征當(dāng)前計(jì)算節(jié)點(diǎn)是否通過(guò)了所有的評(píng)估器成為了候選節(jié)點(diǎn)。

算法1資源可用度評(píng)估算法

DSM 基于Yun 實(shí)現(xiàn)，可以對(duì)容器CPU、內(nèi)存使用量進(jìn)行精確的限制，因此針對(duì)CPU 和內(nèi)存資源，對(duì)應(yīng)的CPU 評(píng)估器和內(nèi)存評(píng)估器以計(jì)算節(jié)點(diǎn)的邏輯資源剩余量作為評(píng)估標(biāo)準(zhǔn)。如果容器的資源請(qǐng)求規(guī)格r大于計(jì)算節(jié)點(diǎn)相應(yīng)資源的邏輯剩余量R，該計(jì)算節(jié)點(diǎn)將會(huì)被直接過(guò)濾。負(fù)載評(píng)估器會(huì)將當(dāng)前計(jì)算節(jié)點(diǎn)的負(fù)載與設(shè)定的負(fù)載閾值（本文定義為70%）進(jìn)行比較，如果節(jié)點(diǎn)的負(fù)載超過(guò)閾值，則將會(huì)被直接過(guò)濾。負(fù)載評(píng)估器的存在可以有效避免節(jié)點(diǎn)過(guò)載導(dǎo)致的系統(tǒng)響應(yīng)時(shí)間變慢以及性能下降等問(wèn)題。最終，通過(guò)所有評(píng)估器的計(jì)算節(jié)點(diǎn)將會(huì)作為候選節(jié)點(diǎn)，進(jìn)入優(yōu)先級(jí)決策階段。

2.2 優(yōu)先級(jí)決策階段

在優(yōu)先級(jí)決策階段設(shè)計(jì)了CPU 決策器（CPUMaker）和內(nèi)存決策器（MemoryMaker）兩個(gè)決策器，分別根據(jù)每個(gè)候選計(jì)算節(jié)點(diǎn)的CPU 利用率和內(nèi)存利用率決策該節(jié)點(diǎn)的優(yōu)先級(jí)。將計(jì)算節(jié)點(diǎn)i的CPU 利用率用表示，值可以通過(guò)調(diào)用psutil［27］模塊的cpu_percent（）函數(shù)獲得。計(jì)算節(jié)點(diǎn)i的“/proc/meminfo”文件中記錄了其總內(nèi)存以及可用內(nèi)存信息，分別記為，則計(jì)算節(jié)點(diǎn)i的內(nèi)存利用率可通過(guò)式（2）計(jì)算：

為防止計(jì)算節(jié)點(diǎn)某項(xiàng)資源的利用率低而優(yōu)先級(jí)高，使用Yun 的資源優(yōu)先級(jí)系數(shù)自適應(yīng)策略［22］，默認(rèn)每項(xiàng)資源的優(yōu)先級(jí)系數(shù)為1.0，如果某項(xiàng)資源的利用率超過(guò)50%，則調(diào)整其優(yōu)先級(jí)系數(shù)為1/2，如果利用率超過(guò)70%，則調(diào)整其優(yōu)先級(jí)系數(shù)為1/4，如果利用率超過(guò)80%，則調(diào)整其優(yōu)先級(jí)系數(shù)為1/8，通過(guò)實(shí)時(shí)感知當(dāng)前計(jì)算節(jié)點(diǎn)的資源利用率，并動(dòng)態(tài)調(diào)整相應(yīng)資源的優(yōu)先級(jí)系數(shù)，實(shí)現(xiàn)更均衡的資源利用，以提高計(jì)算節(jié)點(diǎn)的資源利用率。將計(jì)算節(jié)點(diǎn)i的優(yōu)先級(jí)轉(zhuǎn)換為計(jì)算節(jié)點(diǎn)i的得分并使用式（3）表示：

其中：t為資源的類(lèi)型；n為資源類(lèi)型的數(shù)目；wt為用戶(hù)為資源t定義的優(yōu)先級(jí)乘數(shù)；為計(jì)算節(jié)點(diǎn)i的資源t的優(yōu)先級(jí)系數(shù)；為計(jì)算節(jié)點(diǎn)i的資源t的利用率；m為候選計(jì)算節(jié)點(diǎn)的個(gè)數(shù)。si越大的計(jì)算節(jié)點(diǎn)優(yōu)先級(jí)越高，決策階段的目標(biāo)是從候選節(jié)點(diǎn)中找出使si最大的計(jì)算節(jié)點(diǎn)i作為最優(yōu)計(jì)算節(jié)點(diǎn)，如算法2 所示，算法的輸入是所有的決策器（makers）以及所有候選計(jì)算節(jié)點(diǎn)的對(duì)象（hosts），算法的輸出是一個(gè)列表（S），用于記錄所有候選計(jì)算節(jié)點(diǎn)的得分。

算法2優(yōu)先級(jí)決策算法

3 實(shí)驗(yàn)結(jié)果與分析

為分析并驗(yàn)證DSM 性能進(jìn)行以下實(shí)驗(yàn)：1）分析DSM 如何通過(guò)實(shí)時(shí)監(jiān)測(cè)容器的資源使用確定容器的實(shí)際資源使用參數(shù)；2）采用Nova-Docker、Yun 和DSM 部署固定數(shù)量的容器，以驗(yàn)證DSM 相比于Nova-Docker 和Yun 可以實(shí)現(xiàn)資源的高效利用；3）測(cè)試Nova-Docker、Yun 和DSM可以部署的容器數(shù)量的上限以及OpenStack 中各個(gè)計(jì)算節(jié)點(diǎn)的資源利用率的上限，以驗(yàn)證DSM 相比于Nova-Docker 和Yun可以有效提升OpenStack 中計(jì)算節(jié)點(diǎn)的資源利用率。

3.1 實(shí)驗(yàn)環(huán)境設(shè)置

基于OpenStack Mitaka 構(gòu)建實(shí)驗(yàn)環(huán)境，包含1 個(gè)控制節(jié)點(diǎn)和3 個(gè)Docker 計(jì)算節(jié)點(diǎn)?？刂乒?jié)點(diǎn)的操作系統(tǒng)為CentOS 7.2，各個(gè)計(jì)算節(jié)點(diǎn)的操作系統(tǒng)為CentOS 7.8，Docker 版本為17.06.0-ce。每個(gè)計(jì)算節(jié)點(diǎn)的資源總量信息如表2 所示。需要說(shuō)明的是，由于Zun 在兼容性方面不支持OpenStack Mitaka，因此在此未將Zun 作為比較對(duì)象。

表2 Docker 計(jì)算節(jié)點(diǎn)信息Table 2 Docker compute node information

同時(shí)，引入3 種負(fù)載型容器和3 種應(yīng)用型容器對(duì)DSM 進(jìn)行驗(yàn)證分析，每種容器的資源請(qǐng)求規(guī)格及工作負(fù)載如表3 所示。負(fù)載型容器使用Linux 壓力測(cè)試工具生成不同的容器系統(tǒng)CPU 和內(nèi)存負(fù)載，容器會(huì)不斷地釋放并重新申請(qǐng)分配資源，以此模擬容器的資源使用隨時(shí)間動(dòng)態(tài)變化的情況。應(yīng)用型容器內(nèi)運(yùn)行不同的應(yīng)用程序，每種應(yīng)用程序都會(huì)產(chǎn)生資源消耗。

表3 容器資源規(guī)格及工作負(fù)載Table 3 Resource specifications and workloads of the containers

3.2 容器實(shí)際資源使用參數(shù)確定

DSM 資源實(shí)時(shí)監(jiān)測(cè)模塊通過(guò)監(jiān)測(cè)容器在固定時(shí)間間隔（本文設(shè)置為1 h）內(nèi)的各項(xiàng)資源使用信息，確定容器對(duì)應(yīng)資源的實(shí)際使用參數(shù)，作為容器重新調(diào)度的依據(jù)。該實(shí)驗(yàn)使用DSM 部署表3 中的1 個(gè)負(fù)載型容器（1 個(gè)工作進(jìn)程，2 048 MB 內(nèi)存）和1 個(gè)應(yīng)用型容器（安裝RabbitMQ，發(fā)送和接收消息），分析DSM 如何通過(guò)實(shí)時(shí)監(jiān)測(cè)容器的資源使用確定容器的實(shí)際資源使用參數(shù)。

圖5 給出了DSM 監(jiān)測(cè)到的負(fù)載型容器的資源使用信息。在圖5（a）中，橫坐標(biāo)表示采集輪次，以10 s為1 個(gè)間隔，共有360 個(gè)輪次，縱坐標(biāo)代表容器的CPU 利用率，可以看出該容器的CPU 利用率的峰值為104%，DSM 會(huì)基于此信息確定該容器的實(shí)際CPU使用參數(shù)為1；在圖5（b）中，容器的內(nèi)存使用量的峰值為2 053 MB，DSM 會(huì)基于此信息確定該容器的實(shí)際內(nèi)存使用參數(shù)為2 053。DSM 監(jiān)測(cè)到的應(yīng)用型容器的資源使用信息如圖6 所示。在圖6（a）中，該容器的CPU 利用率的峰值為304%，DSM 會(huì)基于此信息確定該容器的實(shí)際CPU 使用參數(shù)為3；在圖6（b）中，容器的內(nèi)存使用量的峰值為119 MB，DSM 會(huì)基于此信息確定該容器的實(shí)際內(nèi)存使用參數(shù)為119。

圖5 負(fù)載型容器的資源使用信息Fig.5 Resource usage information of load-type container

圖6 應(yīng)用型容器的資源使用信息Fig.6 Resource usage information of application-type container

3.3 固定容器部署數(shù)量下的資源利用率分析

DSM 采用RAPD 調(diào)度機(jī)制對(duì)容器進(jìn)行調(diào)度，以提高OpenStack 中計(jì)算節(jié)點(diǎn)的資源利用率，該實(shí)驗(yàn)分別采用Nova-Docker、Yun 和DSM 部署容器，通過(guò)比較部署后實(shí)驗(yàn)環(huán)境中各個(gè)計(jì)算節(jié)點(diǎn)的資源利用率情況，以驗(yàn)證本文提出的調(diào)度模型相比于其他兩種調(diào)度模型可以實(shí)現(xiàn)資源的高效利用。首先分別采用Nova-Docker、Yun 和DSM在實(shí)驗(yàn)環(huán)境中的3 個(gè)Docker 計(jì)算節(jié)點(diǎn)上各進(jìn)行一組測(cè)試，每組測(cè)試分別部署9 個(gè)負(fù)載型容器，涵蓋負(fù)載型容器下的所有容器。然后分別統(tǒng)計(jì)每組測(cè)試中3 個(gè)計(jì)算節(jié)點(diǎn)的容器數(shù)量、CPU 利用率和內(nèi)存利用率，結(jié)果如圖7 所示。

圖7 負(fù)載型容器的資源利用率測(cè)試結(jié)果Fig.7 Resource utilization test results of load-type containers

由圖7 可以看出，Nova-Docker 和Yun 采用基于容器初始資源請(qǐng)求的調(diào)度模型對(duì)容器進(jìn)行調(diào)度與部署，實(shí)驗(yàn)環(huán)境中的3 個(gè)計(jì)算節(jié)點(diǎn)均部署了容器并有一定的資源消耗，而DSM 采用RAPD 調(diào)度機(jī)制，所有的負(fù)載型容器最終均部署于計(jì)算節(jié)點(diǎn)3，該計(jì)算節(jié)點(diǎn)的資源利用率最高。換言之，在調(diào)度完成后，Nova-Docker 和Yun 需要同時(shí)開(kāi)啟3 個(gè)計(jì)算節(jié)點(diǎn)以支持9 個(gè)容器的運(yùn)行，且容器會(huì)占用大量的空閑資源使其無(wú)法釋放，造成資源的嚴(yán)重浪費(fèi)，而DSM 只需要開(kāi)啟1 個(gè)計(jì)算節(jié)點(diǎn)便可以支持所有容器的運(yùn)行，實(shí)現(xiàn)了資源的高效利用。

同樣地，首先分別采用Nova-Docker、Yun 和DSM 在實(shí)驗(yàn)環(huán)境中的3 個(gè)Docker 計(jì)算節(jié)點(diǎn)上各進(jìn)行一組測(cè)試，每組測(cè)試分別部署9 個(gè)應(yīng)用型容器，涵蓋應(yīng)用型容器下的所有容器。然后分別統(tǒng)計(jì)每組測(cè)試中3 個(gè)計(jì)算節(jié)點(diǎn)的容器數(shù)量、CPU 利用率和內(nèi)存利用率，結(jié)果如圖8 所示。由圖8 可以看出，應(yīng)用型容器的部署情況同負(fù)載型容器類(lèi)似，相比于Nova-Docker 和Yun，DSM 將所有的應(yīng)用型容器均調(diào)度至計(jì)算節(jié)點(diǎn)3，該節(jié)點(diǎn)的資源利用率最高。

圖8 應(yīng)用型容器的資源利用率測(cè)試結(jié)果Fig.8 Resource utilization test results of application-type containers

3.4 最大容器部署數(shù)量下的資源利用率分析

Nova-Docker 和Yun 根據(jù)容器的初始資源請(qǐng)求對(duì)容器調(diào)度，未充分考慮容器運(yùn)行時(shí)的實(shí)際資源使用情況，如果容器的資源使用量很小或長(zhǎng)期未使用某項(xiàng)資源，則節(jié)點(diǎn)的資源利用率將會(huì)很低，且空閑的資源無(wú)法得到釋放。DSM 根據(jù)容器運(yùn)行時(shí)的實(shí)際資源使用對(duì)容器進(jìn)行重新調(diào)度，釋放了容器占用的空閑資源，并提高了計(jì)算節(jié)點(diǎn)的資源利用率。該實(shí)驗(yàn)分別基于Nova-Docker、Yun 和DSM 部 署3.1 節(jié)中引 入的3 種負(fù)載型容器，測(cè)試Nova-Docker、Yun 和DSM 可以部署的容器數(shù)量的上限以及實(shí)驗(yàn)環(huán)境中各個(gè)計(jì)算節(jié)點(diǎn)的資源利用率上限，實(shí)驗(yàn)結(jié)果如圖9 所示。

圖9 最大容器部署數(shù)量下的資源利用率測(cè)試結(jié)果Fig.9 Resource utilization test results for the maximum deployment number of containers

由圖9 可以看出，相比于Nova-Docker 和Yun，DSM 部署了最多數(shù)量的容器，且各個(gè)計(jì)算節(jié)點(diǎn)的CPU 利用率和內(nèi)存利用率均有顯著提升，實(shí)現(xiàn)了資源的高效利用。在CPU 利用率方面，相比于Nova-Docker 和Yun，DSM 在節(jié)點(diǎn)1的CPU利用率提升最多，分別提升了42.68 和46.89 個(gè)百分點(diǎn)，在節(jié)點(diǎn)2 的CPU 利用率提升最少，分別提升了38.54 和30.17 個(gè)百分點(diǎn)；在內(nèi)存利用率方面，相比于Nova-Docker 和Yun，DSM 在節(jié)點(diǎn)2 的內(nèi)存利用率提升最多，分別提升了53.01 和53.33 個(gè)百分點(diǎn)，在節(jié)點(diǎn)1 的內(nèi)存利用率提升最少，分別提升了38.40 和28.69 個(gè)百分點(diǎn)。

4 結(jié)束語(yǔ)

為滿(mǎn)足云計(jì)算領(lǐng)域的高資源利用率需求及利用OpenStack 與Docker 集成的優(yōu)勢(shì)，本文設(shè)計(jì)并實(shí)現(xiàn)基于OpenStack 的Docker 調(diào)度模型，并通過(guò)實(shí)驗(yàn)驗(yàn)證了相比于經(jīng)典的Nova-Docker、Yun 集成方案采用的調(diào)度模型，該模型在CPU 利用率和內(nèi)存利用率上具有明顯優(yōu)勢(shì)?？紤]到云計(jì)算環(huán)境中容器的多樣化資源需求，下一步將加入磁盤(pán)、網(wǎng)絡(luò)帶寬等資源作為Docker 容器調(diào)度依據(jù)，同時(shí)針對(duì)容器的差異化資源需求，為容器設(shè)置專(zhuān)有資源權(quán)重，優(yōu)化容器調(diào)度機(jī)制，并將對(duì)某種資源需求較多的容器調(diào)度至資源相對(duì)充分的計(jì)算節(jié)點(diǎn)，在實(shí)現(xiàn)OpenStack 中計(jì)算節(jié)點(diǎn)資源負(fù)載均衡的同時(shí)提高資源利用率。