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

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

0　引言

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

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

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

1　相關工作

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

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

2　問題描述與建模

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

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

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

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

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

2.2　系統(tǒng)建模

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

(1)

Wi=λWm+αWc+βWn;

(2)

λ+α+β=1;

(3)

(4)

3　調度策略

3.1　應用容器部署算法

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

3.2　應用遷移算法

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

輸入S、P、μ、ε；

輸出hostd。

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

步驟6若y=Ct+1，查找結束。

4　實驗及對比分析

4.1　實驗環(huán)境

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

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

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

4.2　實驗過程及對比分析

表1　集群節(jié)點資源平均使用率　%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　應用①完成時間對比Tab. 2　Completion time comparison of application ①

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

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

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

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

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

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

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

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

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

5　結語

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

參考文獻:

[1]劉鵬.云計算[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]郝庭毅,吳恒,吳國全,等.面向微服務架構的容器級彈性資源供給方法[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的虛擬化應用平臺設計與實現(xiàn)[D].廣州:華南理工大學軟件學院,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技術入門與實戰(zhàn)[M].2版.北京:機械工業(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]武志學.云計算虛擬化技術的發(fā)展與趨勢[J].計算機應用,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é)能技術研究[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]. 計算機工程與應用 (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的資源預調度策略構建彈性集群的研究[D].杭州:浙江理工大學信息學院,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.)