彭麗蘋，呂曉丹，蔣朝惠，彭成輝

(貴州大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，貴陽 550025)(*通信作者電子郵箱18984170078@126.com)

0　引言

云計(jì)算技術(shù)迅速發(fā)展，基于云平臺的應(yīng)用也層出不窮。云平臺通過虛擬化技術(shù)將計(jì)算機(jī)資源整合成資源池，以按需付費(fèi)的方式實(shí)現(xiàn)了用戶對計(jì)算資源的彈性需求[1]。云計(jì)算發(fā)展至今，虛擬化技術(shù)一直是云平臺中的關(guān)鍵技術(shù)，而容器技術(shù)則是近年來興起的一種虛擬化技術(shù)[2]，它的出現(xiàn)給傳統(tǒng)虛擬化技術(shù)帶來了挑戰(zhàn)，為構(gòu)建高效的云平臺提供了新思路[3-6]。在Docker、Linux Container(LXC)、Warden、OpenVZ等眾多容器技術(shù)中，人們最為看好的是Docker 容器技術(shù)[7]，阿里巴巴、京東、亞馬遜、谷歌、微軟等國內(nèi)外大型運(yùn)營商已經(jīng)建立了基于Docker容器技術(shù)的云平臺。Docker容器技術(shù)是一種操作系統(tǒng)層虛擬化技術(shù)，與傳統(tǒng)的虛擬機(jī)技術(shù)不同，它不需要運(yùn)行客戶機(jī)操作系統(tǒng)，容器以進(jìn)程的形式運(yùn)行在宿主機(jī)操作系統(tǒng)中，這也使得容器具有比傳統(tǒng)虛擬機(jī)更輕便、靈活、快速部署的優(yōu)點(diǎn)[8]。另外，Docker利用Union FS 技術(shù)，采用分層存儲架構(gòu)，實(shí)現(xiàn)了計(jì)算資源的復(fù)用，大大提高了計(jì)算機(jī)資源利用率[9]。武志學(xué)[10]詳細(xì)介紹了Docker技術(shù)，并將Docker和虛擬機(jī)兩種虛擬化技術(shù)進(jìn)行了對比，最后指出Docker技術(shù)將會成為云計(jì)算的核心技術(shù)。事實(shí)表明他這種說法是正確的，現(xiàn)今各大云計(jì)算運(yùn)營商正在大量地構(gòu)建基于Docker容器技術(shù)的云平臺。云平臺資源的彈性調(diào)度問題一直是云計(jì)算發(fā)展過程中的熱點(diǎn)問題，而應(yīng)用在線遷移技術(shù)是實(shí)現(xiàn)云平臺彈性擴(kuò)展的重要技術(shù)，因此，研究Docker云平臺應(yīng)用的在線遷移技術(shù)，進(jìn)而實(shí)現(xiàn)云平臺資源的彈性調(diào)度具有重大意義。

存儲系統(tǒng)是云計(jì)算數(shù)據(jù)中心最主要的資源，因此如何合理運(yùn)用云平臺存儲資源就顯得尤為重要。Ceph[11]是一個開源的軟件定義分布式文件存儲系統(tǒng)，被廣泛用于構(gòu)建大型云平臺的后端存儲系統(tǒng)[12]。它不僅支持塊存儲、文件存儲和對象存儲三種存儲模式，還具有低成本、高可擴(kuò)展性、高可靠性等優(yōu)點(diǎn)，但Ceph的數(shù)據(jù)副本存儲算法——CRUSH算法[13]在合理利用資源方面存在著不足，沈良好等[14]就從節(jié)約系統(tǒng)能耗的角度對這一問題進(jìn)行了闡述。CRUSH算法是一種偽隨機(jī)Hash散列算法，總是盡可能地將數(shù)據(jù)平均存儲到Ceph集群的對象存儲設(shè)備(Object-based Storage Device, OSD)中，使得除了在應(yīng)用高峰期以外，集群中大多數(shù)點(diǎn)都處于低負(fù)載狀態(tài)，這就造成了資源的浪費(fèi)，并增加了系統(tǒng)能耗[15]。

針對上述問題，結(jié)合Ceph和Docker容器的特點(diǎn)，提出了一種基于Docker的云平臺資源彈性調(diào)度策略。首先對前人的工作進(jìn)行總結(jié)，并指出其中的不足；然后對Ceph集群的數(shù)據(jù)副本存儲策略進(jìn)行改進(jìn)，并建立了一個資源調(diào)度優(yōu)化模型；在此基礎(chǔ)之上，提出了基于Docker云平臺的應(yīng)用容器部署算法和應(yīng)用在線遷移算法；最后，在綜合考慮數(shù)據(jù)存儲、資源負(fù)載和應(yīng)用服務(wù)性能的基礎(chǔ)上，利用Docker Swarm容器編排工具，實(shí)現(xiàn)了應(yīng)用容器的動態(tài)部署和應(yīng)用的在線遷移，從而達(dá)到了對云資源進(jìn)行彈性調(diào)度的目的。

1　相關(guān)工作

針對云平臺資源調(diào)度問題，學(xué)者們做了大量研究。Kang等[16]針對Docker云平臺數(shù)據(jù)中心的能耗問題，提出了一種負(fù)載感知的異構(gòu)容器集群能效管理方法。該方法利用K-medoid算法對云平臺應(yīng)用進(jìn)行分類，并在此基礎(chǔ)上建立了一個異構(gòu)集群的能效模型，最后用不同類型的應(yīng)用進(jìn)行實(shí)驗(yàn)測試，表明該調(diào)度方法能在保證服務(wù)性能的情況下節(jié)約數(shù)據(jù)中心能耗，降低云平臺運(yùn)營成本。Meng等[17]針對容器應(yīng)用在不同階段所需計(jì)算資源不同所造成的資源浪費(fèi)以及集群動態(tài)擴(kuò)展帶來的性能損失問題，提出了一種基于時序分析的資源預(yù)測模型。該模型根據(jù)歷史負(fù)載數(shù)據(jù)對容器下一時隙所需的計(jì)算資源進(jìn)行預(yù)測，然后根據(jù)預(yù)測值利用容器技術(shù)實(shí)現(xiàn)應(yīng)用的快速彈性收縮，達(dá)到了合理部署云平臺資源的目的。Guan等[18]提出了一種基于Docker容器的面向應(yīng)用的數(shù)據(jù)中心資源分配方法。該方法針對不同應(yīng)用的資源使用情況，綜合考慮物理機(jī)資源和容器資源，建立了一個資源優(yōu)化模型，并考慮到Docker容器資源分層復(fù)用的特點(diǎn)，實(shí)現(xiàn)了對數(shù)據(jù)中心資源的合理調(diào)度。何松林[19]利用Docker虛擬化技術(shù)構(gòu)建了一個可彈性擴(kuò)展的彈性集群，并針對集群的資源使用率問題提出了基于容器和集群節(jié)點(diǎn)負(fù)載數(shù)據(jù)的調(diào)度策略、彈性收縮容器時的宿主機(jī)調(diào)度策略和改善用戶響應(yīng)延遲的負(fù)載預(yù)測調(diào)度策略。

以上學(xué)者們提出的調(diào)度策略雖然在一定程度上提高了數(shù)據(jù)中心資源的利用率，但他們要么只考慮容器部署時的資源調(diào)度問題，要么只考慮了容器應(yīng)用遷移過程中的資源調(diào)度問題，都沒有考慮到集群應(yīng)用數(shù)據(jù)存儲對容器部署和應(yīng)用遷移造成的影響。本文從應(yīng)用容器部署和應(yīng)用遷移的角度出發(fā)，在同時考慮數(shù)據(jù)存儲和集群節(jié)點(diǎn)負(fù)載并保證服務(wù)性能的前提下，實(shí)現(xiàn)了云平臺資源的彈性調(diào)度。

2　問題描述與建模

2.1　改進(jìn)的Ceph集群數(shù)據(jù)存儲策略

在基于Ceph集群的Docker容器云平臺中，假設(shè)Ceph集群采用三個副本的數(shù)據(jù)存儲策略，集群中的節(jié)點(diǎn)分為A區(qū)和B區(qū)，A區(qū)用于應(yīng)用平穩(wěn)期的業(yè)務(wù)需求，B區(qū)用于應(yīng)用高峰期的業(yè)務(wù)需求。其中：A區(qū)有2R個機(jī)架，編號為racki(0≤i<2R,i∈Z)；B區(qū)有R個機(jī)架，編號為rackj(0≤j

圖1　數(shù)據(jù)中心目錄樹結(jié)構(gòu)Fig. 1　Directory tree structure of datacenter

圖2　改進(jìn)的Docker云平臺架構(gòu)及數(shù)據(jù)存儲策略Fig. 2　Architecture and data storage strategy of improved Docker cloud platform

圖3　應(yīng)用i容器部署流程Fig. 3　Flow chart of container deployment for application i

2.2　系統(tǒng)建模

基于2.1節(jié)改進(jìn)了數(shù)據(jù)存儲策略的Ceph集群和各個集群節(jié)點(diǎn)的資源負(fù)載情況，建立了一個資源調(diào)度優(yōu)化模型，具體如下：

(1)

Wi=λWm+αWc+βWn;

(2)

λ+α+β=1;

(3)

(4)

3　調(diào)度策略

3.1　應(yīng)用容器部署算法

基于第2章的內(nèi)容，以下將給出一種既考慮數(shù)據(jù)存儲、又考慮節(jié)點(diǎn)負(fù)載情況的應(yīng)用容器部署方法。在云平臺采集內(nèi)存、CPU和網(wǎng)絡(luò)利用率的具體數(shù)據(jù)，假設(shè)采集數(shù)據(jù)的時間間隔為S，一共采集D次，對采集的數(shù)據(jù)進(jìn)行整理和計(jì)算，求得各種資源使用率的平均值即為Wm、Wc、Wn的值。對將要部署的應(yīng)用進(jìn)行類型判斷，看該應(yīng)用對內(nèi)存、CPU和網(wǎng)絡(luò)帶寬的需求情況，分別設(shè)置參數(shù)λ、α、β的比例。例如對于CPU密集型應(yīng)用可設(shè)置λ∶α∶β=3∶5∶2，則由式(3)可以計(jì)算出λ、α、β的具體值，再結(jié)合式(2)便可計(jì)算出Wi的值。在得到Wi的值后，便可根據(jù)式(4)將集群中的節(jié)點(diǎn)進(jìn)行分類，盡量將應(yīng)用部署在color=blue的節(jié)點(diǎn)上，為了保證應(yīng)用性能，可在同一個主機(jī)上運(yùn)行多個應(yīng)用i的容器。將color=green的節(jié)點(diǎn)在Docker Swarm中的狀態(tài)設(shè)置為drain，這樣Swarm便不會將容器應(yīng)用部署到該節(jié)點(diǎn)上，之后將該類節(jié)點(diǎn)設(shè)置為休眠狀態(tài)，以節(jié)約數(shù)據(jù)中心資源。關(guān)于color=red的集群節(jié)點(diǎn)，將不會部署新的應(yīng)用到該類節(jié)點(diǎn)上。應(yīng)用i容器部署算法如圖3所示。圖中應(yīng)用i容器會部署失敗，是因?yàn)樵破脚_中沒有滿足該資源調(diào)度模型的節(jié)點(diǎn)，此時應(yīng)添加更多的物理服務(wù)器到云平臺中。此外把應(yīng)用i容器部署在節(jié)點(diǎn)rackk.hostj(第k+1個機(jī)架上的第j+1臺主機(jī))上之前，要把該應(yīng)用的數(shù)據(jù)副本M1存儲在該節(jié)點(diǎn)上，剩下的M2和M3按照2.1節(jié)提出的數(shù)據(jù)存儲策略存儲到相應(yīng)的云平臺節(jié)點(diǎn)中。

3.2　應(yīng)用遷移算法

對于處于color=red狀態(tài)的節(jié)點(diǎn)，當(dāng)該類節(jié)點(diǎn)在一段時間內(nèi)的平均資源利用率出現(xiàn)大于一定量W(W為常量，可由云平臺管理員根據(jù)云平臺情況設(shè)定)時，要對應(yīng)用進(jìn)行遷移，否則會因?yàn)楦鲬?yīng)用容器計(jì)算資源匱乏而使得應(yīng)用性能下降，具體的應(yīng)用遷移算法如下：

輸入S、P、μ、ε；

輸出hostd。

步驟4若S=P，則令y=0,T=t[y++]；

步驟6若y=Ct+1，查找結(jié)束。

4　實(shí)驗(yàn)及對比分析

4.1　實(shí)驗(yàn)環(huán)境

為了驗(yàn)證該調(diào)度策略的可行性和有效性，在基于Ceph集群的Docker云平臺上進(jìn)行了實(shí)驗(yàn)測試。實(shí)驗(yàn)中使用9臺戴爾R710服務(wù)器。服務(wù)器的部署環(huán)境如下：A區(qū)包括2R=6臺物理服務(wù)器，分別位于三個不同的機(jī)架(Rack)中，則每個機(jī)架中2臺，即h=2；B區(qū)包括R=3臺物理服務(wù)器，位于3個不同的機(jī)架中；服務(wù)器均采用Centos7(64位)操作系統(tǒng)，8核處理器，2張千兆網(wǎng)卡和32 GB內(nèi)存，磁盤容量為1 TB，做了RAID5。所使用的Ceph版本為Jewel(10.2.9)，每個服務(wù)器中將3個目錄文件作為node節(jié)點(diǎn)的OSD，則N=3，數(shù)據(jù)副本數(shù)為3，使用的Docker 版本為17.06.0-ce，每臺服務(wù)器既是Ceph集群的node節(jié)點(diǎn)，也是Swarm集群的Docker節(jié)點(diǎn)。為了更真實(shí)地模擬云平臺環(huán)境，在某些服務(wù)器上運(yùn)行了占用不同服務(wù)器計(jì)算資源的虛擬機(jī)，并用以下兩個應(yīng)用進(jìn)行實(shí)驗(yàn)：

①用Java語言編寫簡單的計(jì)算程序，該程序中用到了乘法、除法和開根號的算數(shù)運(yùn)算，將程序所需的數(shù)據(jù)先存放在文件中，將中間計(jì)算結(jié)果寫入OSD中，數(shù)據(jù)大小約為8.5 GB，并將開始時間和結(jié)束時間輸出到屏幕上；

②用Tomcat部署一個Java Web應(yīng)用，該應(yīng)用實(shí)現(xiàn)對磁盤中文檔的搜索功能，實(shí)驗(yàn)用的數(shù)據(jù)文檔存放在集群節(jié)點(diǎn)的OSD中，并將搜索到的文檔路徑返回到屏幕上。

4.2　實(shí)驗(yàn)過程及對比分析

表1　集群節(jié)點(diǎn)資源平均使用率　%Tab. 1　Average resource usage of cluster nodes　%

gRoot setA1{

id -1

alg straw

hash 0

item osd.0 weight 0.010

item osd.1 weight 0.010

item osd.2 weight 0.010

…

item osd.6 weight 0.010

item osd.7 weight 0.010

item osd.8 weight 0.010

…

item osd.18 weight 0.010

item osd.19 weight 0.010

item osd.20 weight 0.010

…

item osd.26 weight 0.000

}

表2　應(yīng)用①完成時間對比Tab. 2　Completion time comparison of application ①

為了進(jìn)一步驗(yàn)證該調(diào)度策略的有效性，在改進(jìn)前和改進(jìn)后的Docker云平臺上運(yùn)行不同數(shù)量的應(yīng)用①容器，對集群中處于運(yùn)行狀態(tài)的服務(wù)器數(shù)量進(jìn)行了對比，對比結(jié)果如表3所示。從表3可以看出，在部署相同數(shù)量應(yīng)用的情況下，優(yōu)化后集群中處于運(yùn)行態(tài)的節(jié)點(diǎn)數(shù)量要比優(yōu)化前的少。優(yōu)化前的集群在部署第8個應(yīng)用時開始啟用B區(qū)的服務(wù)器，而優(yōu)化后的集群在部署第12個應(yīng)用時，運(yùn)行態(tài)的節(jié)點(diǎn)數(shù)突然快速增加，并開始啟用B區(qū)的服務(wù)器，這是因?yàn)锳區(qū)有一臺節(jié)點(diǎn)宕機(jī)，而且此時A區(qū)沒有滿足條件的目的主機(jī)，所以需要把應(yīng)用遷移到B區(qū)。而優(yōu)化前的集群在部署第8個應(yīng)用時就啟用B區(qū)的服務(wù)器，可能是因?yàn)槿萜骶幣牌鱏warm的平均部署算法所致，從這里也可以看出，本文提出的調(diào)度算法對集群資源進(jìn)行了更細(xì)粒度的劃分，并能夠在一定程度上減少數(shù)據(jù)中心處于運(yùn)行態(tài)的服務(wù)器數(shù)量，以此達(dá)到了降低數(shù)據(jù)中心運(yùn)營成本的目的，而且在集群相對穩(wěn)定的情況下節(jié)約效果更明顯。

表3　集群中處于運(yùn)行態(tài)節(jié)點(diǎn)數(shù)對比Tab. 3　Comparison of the number of cluster nodes in running state

Docker有Compose、Machine和Swarm三種官方容器編排工具，但前兩種都是對單主機(jī)上的容器進(jìn)行編排，而本文研究的是集群Docker容器的調(diào)度問題，所以這里不作討論。另外，Kubernetes是現(xiàn)今比較流行的一種開源集群容器編排工具，它與Swarm都采用Go語言開發(fā)，兩者具有可比性。因此，為了測試本文提出的Docker Swarm容器編排工具與其他幾種編排工具的性能差異，將其與原生Swarm和Kubernetes(V1.7)進(jìn)行了實(shí)驗(yàn)和對比。在改進(jìn)了存儲方案的Ceph集群中進(jìn)行實(shí)驗(yàn)，將10個應(yīng)用①容器部署在該集群中，實(shí)驗(yàn)共進(jìn)行了30次，對采集到的數(shù)據(jù)分別求平均值，結(jié)果如表4所示，其中Swarm_opt表示本文改進(jìn)的Swarm容器編排工具。需要指出的是，由于Kubernetes的容器復(fù)制控制器(Replication Controller)可以通過復(fù)制而產(chǎn)生相同的容器副本，而Swarm是從倉庫中拉取鏡像生成容器，兩者的差異對應(yīng)用的完成時間影響很大，為了避免這種差異對實(shí)驗(yàn)結(jié)果造成的影響，實(shí)驗(yàn)中并沒有使用Kubernetes的容器復(fù)制控制器功能。此外，Kubernetes中的最小調(diào)度單位是Pod，而Swarm是以Container為最小調(diào)度單位的，因此實(shí)驗(yàn)中，每個Pod中只包含一個Container,每個應(yīng)用都是一個作業(yè)(job)。

表4　不同容器編排工具性能對比Tab. 4　Performance comparison of different Docker orchestration

由表4可以看到，當(dāng)在集群中部署10個應(yīng)用①時，使用Swarm、Swarm_opt、Kubernetes三種不同容器編排工具，集群中開啟的節(jié)點(diǎn)數(shù)分別為M(Swarm)=7，M(Swarm_opt)=5，M(Kubernetes)=7，結(jié)合集群負(fù)載來看，這也體現(xiàn)了本文提出的容器編排器Swarm_opt在提高資源利用率上具有一定的優(yōu)勢。而在M(Swarm)=M(Kubernetes)=7的情況下，集群負(fù)載P(Kubernetes)>P(Swarm)，這可能是因?yàn)閮烧叩膶?shí)現(xiàn)機(jī)制決定的，因?yàn)镵ubernetes比Swarm的實(shí)現(xiàn)機(jī)制更復(fù)雜。另外，在應(yīng)用不發(fā)生遷移時，應(yīng)用的完成時間從小到大依次為T(Swarm_opt)>T(Kubernetes)>T(Swarm)，本文提出的容器調(diào)度算法用的時間較長，這是由于集群中開啟的節(jié)點(diǎn)數(shù)較少，各節(jié)點(diǎn)的資源在達(dá)到更高利用率的同時也稍微降低了節(jié)點(diǎn)的性能，故應(yīng)用完成時間較長，但在節(jié)點(diǎn)開啟數(shù)量減少25.87%的情況下，每個應(yīng)用增加的完成時間僅增長了4%，而在非實(shí)時的應(yīng)用中這種結(jié)果是很可觀的。而T(Kubernetes)>T(Swarm)是因?yàn)镵ubernetes中容器的啟動速度比在Swarm中小，從而使得Kubernetes中應(yīng)用的完成時間更長。而在應(yīng)用發(fā)生遷移的情況下，與不發(fā)生應(yīng)用遷移時的應(yīng)用完成時間的增長量從小到大依次為：

[T*(Swarm_opt)-T(Swarm_opt)]>

[T*(Swarm)-T(Swarm)]>

[T*(Kubernetes)-T(Kubernetes)]

從這里可以看出本文提出的調(diào)度算法在應(yīng)用發(fā)生遷移時付出的代價最小，而由于Kubernetes中的容器啟動慢問題，在應(yīng)用發(fā)生遷移時，它付出的代價最大。

5　結(jié)語

本文改進(jìn)了Ceph集群的存儲策略，建立了一個資源調(diào)度優(yōu)化模型，并在此基礎(chǔ)上提出了云資源彈性調(diào)度策略，針對每個應(yīng)用對資源需求情況的不同，對云平臺資源進(jìn)行了細(xì)粒度的劃分，實(shí)現(xiàn)了云資源的彈性調(diào)度。該策略在遷移應(yīng)用不發(fā)生遷移的情況下，一定程度上節(jié)約了集群資源，達(dá)到了合理利用云資源和降低數(shù)據(jù)中心運(yùn)營成本的目的；而在發(fā)生應(yīng)用遷移時，應(yīng)用的性能雖稍有所下降，但與原生的Swarm和Kubernetes容器編排工具相比，仍能體現(xiàn)一定的優(yōu)勢。如何選擇應(yīng)用遷移時機(jī)，進(jìn)一步減少應(yīng)用遷移代價，是將來要做的工作。

參考文獻(xiàn):

[1]劉鵬.云計(jì)算[M].3版.北京:電子工業(yè)出版社,2015:1-2. (LIU P. Cloud Computing [M]. 3rd ed. Beijing: Publishing House of Electronic Industry, 2015: 1-2.)

[2]TURNBULL J. The Docker Book: Containerization is the New Virtualization [M]. Seattle:Amazon Digital Services Inc, 2014: 4-7.

[3]ADUFU T, CHOI J, KIM Y. Is container-based technology a winner for high performance scientific applications? [C]// APNOMS 2015: Proceedings of the IEEE 2015 17th Asia-Pacific Network Operations and Management Symposium. Piscataway, NJ: IEEE, 2015: 507-510.

[4]TIHFON G M, KIM J, KIM K J. A new virtualized environment for application deployment based on Docker and AWS [C]// ICISA 2016: Proceedings of the 2016 Information Science and Applications, LNEE 376. Singapore: Springer, 2016: 1339-1349.

[5]郝庭毅,吳恒,吳國全,等.面向微服務(wù)架構(gòu)的容器級彈性資源供給方法[J].計(jì)算機(jī)研究與發(fā)展,2017,54(3):597-608. (HAO T Y, WU H, WU G Q, et al. Elastic resource provisioning approach for container in micro-service architecture [J]. Journal of Computer Research and Development, 2017, 54(3): 597-608.)

[6]張怡.基于Docker的虛擬化應(yīng)用平臺設(shè)計(jì)與實(shí)現(xiàn)[D].廣州:華南理工大學(xué)軟件學(xué)院,2016:21-35. (ZHANG Y. The design and implementation of a virtualized application platform based on Docker [D]. Guangzhou: South China University of Technology, College of Software, 2016: 21-35)

[7]KANG D-K, CHOI G-B, KIM S-H, et al. Workload-aware resource management for energy efficient heterogeneous Docker containers [C]// TENCON 2016: Proceedings of the 2016 IEEE Region 10 Conference. Piscataway, NJ: IEEE, 2016: 2428-2431.

[8]楊保華,戴王劍,曹亞侖.Docker技術(shù)入門與實(shí)戰(zhàn)[M].2版.北京:機(jī)械工業(yè)出版社,2017:9-10. (YANG B H, DAI W J, CAO Y L. Docker Technology Entry and Actual Combat [M]. 2nd ed. Beijing: China Machine Press, 2017: 9-10.)

[9]MIELL I, SAYERS A H. Docker in Practice [M]. 2nd ed. Greenwich, Connecticut, USA: Manning Publications, 2016: 124-157.

[10]武志學(xué).云計(jì)算虛擬化技術(shù)的發(fā)展與趨勢[J].計(jì)算機(jī)應(yīng)用,2017,37(4):915-923. (WU Z X. Advances on virtualization technology of cloud computing [J]. Journal of Computer Applications, 2017, 37(4): 915-923.)

[11]WEIL S A, BRANDT S A, MILLER E L, et al. Ceph: a scalable, high-performance distributed file system [C]// OSDI ’06: Proceedings of the 7th symposium on Operating systems design and implementation. Berkeley, CA: USENIX Association, 2006: 307-320.

[12]SINGH K. Ceph Cookbook [M]. Birmingham: Packt Publishing Ltd, 2016: 53-54.

[13]WEIL S A, BRANDT S A, MILLER E L, et al. CRUSHR: controlled, scalable, decentralized placement of replicated data [C]// SC ’06: Proceedings of the 2006 ACM/IEEE Conference on Supercomputing. New York: ACM, 2006: Article No. 122.

[14]沈良好,吳慶波,楊沙洲.基于Ceph的分布式存儲節(jié)能技術(shù)研究[J].計(jì)算機(jī)工程,2015,41(8):13-17. (SHEN L H, WU Q B, YANG S Z. Research on distributed storage energy saving technologies based on Ceph [J]. Computer Engineering, 2015, 41(8): 13-17.)

[15]彭麗蘋,呂曉丹,蔣朝惠.基于Ceph集群的能耗管理策略研究[J/OL]. 計(jì)算機(jī)工程與應(yīng)用 (2017- 08- 10) [2017- 09- 22]. http://kns.cnki.net/kcms/detail/11.2127.TP.20170810.0852.004.html. (PENG L P, LYU X D, JIANG C H, Ceph cluster based energy consumption management strategy study [J/OL]. Journal of Computer Engineering and Applications (2017- 08- 10) [2017- 09- 22]. http://kns.cnki.net/kcms/detail/11.2127.TP.20170810.0852.004.html.)

[16]KANG D-K, CHOI G-B, KIM S-H, et al. Workload-aware resource management for energy efficient heterogeneous Docker containers [C]// TENCON 2016: Proceedings of the 2016 IEEE Region 10 Conference. Piscataway, NJ: IEEE, 2016: 2428-2431.

[17]MENG Y, RAO R, ZHANG X, et al. CRUPA: a container resource utilization prediction algorithm for auto-scaling based on time series analysis [C]// PIC 2016: Proceedings of the 2016 International Conference on Progress in Informatics and Computing. Piscataway, NJ: IEEE, 2016: 468-472.

[18]GUAN X, WAN X, CHOI B Y, et al. Application oriented dynamic resource allocation for data centers using Docker containers [J]. IEEE Communications Letters, 2017, 21(3): 504-507.

[19]何松林.基于Docker的資源預(yù)調(diào)度策略構(gòu)建彈性集群的研究[D].杭州:浙江理工大學(xué)信息學(xué)院,2017:36-60. (HE S L. Research on construction of elastic cluster based on Docker and resource pre-scheduling strategy [D]. Hangzhou: Zhejiang Sci-tech University, School of Information Science and Technology, 2017: 36-60.)