基于Docker的云资源弹性调度策略

彭丽苹，吕晓丹，蒋朝惠，彭成辉

(贵州大学 计算机科学与技术学院，贵阳 550025)(*通信作者电子邮箱18984170078@126.com)

0　引言

云计算技术迅速发展，基于云平台的应用也层出不穷。云平台通过虚拟化技术将计算机资源整合成资源池，以按需付费的方式实现了用户对计算资源的弹性需求[1]。云计算发展至今，虚拟化技术一直是云平台中的关键技术，而容器技术则是近年来兴起的一种虚拟化技术[2]，它的出现给传统虚拟化技术带来了挑战，为构建高效的云平台提供了新思路[3-6]。在Docker、Linux Container(LXC)、Warden、OpenVZ等众多容器技术中，人们最为看好的是Docker 容器技术[7]，阿里巴巴、京东、亚马逊、谷歌、微软等国内外大型运营商已经建立了基于Docker容器技术的云平台。Docker容器技术是一种操作系统层虚拟化技术，与传统的虚拟机技术不同，它不需要运行客户机操作系统，容器以进程的形式运行在宿主机操作系统中，这也使得容器具有比传统虚拟机更轻便、灵活、快速部署的优点[8]。另外，Docker利用Union FS 技术，采用分层存储架构，实现了计算资源的复用，大大提高了计算机资源利用率[9]。武志学[10]详细介绍了Docker技术，并将Docker和虚拟机两种虚拟化技术进行了对比，最后指出Docker技术将会成为云计算的核心技术。事实表明他这种说法是正确的，现今各大云计算运营商正在大量地构建基于Docker容器技术的云平台。云平台资源的弹性调度问题一直是云计算发展过程中的热点问题，而应用在线迁移技术是实现云平台弹性扩展的重要技术，因此，研究Docker云平台应用的在线迁移技术，进而实现云平台资源的弹性调度具有重大意义。

存储系统是云计算数据中心最主要的资源，因此如何合理运用云平台存储资源就显得尤为重要。Ceph[11]是一个开源的软件定义分布式文件存储系统，被广泛用于构建大型云平台的后端存储系统[12]。它不仅支持块存储、文件存储和对象存储三种存储模式，还具有低成本、高可扩展性、高可靠性等优点，但Ceph的数据副本存储算法——CRUSH算法[13]在合理利用资源方面存在着不足，沈良好等[14]就从节约系统能耗的角度对这一问题进行了阐述。CRUSH算法是一种伪随机Hash散列算法，总是尽可能地将数据平均存储到Ceph集群的对象存储设备(Object-based Storage Device, OSD)中，使得除了在应用高峰期以外，集群中大多数点都处于低负载状态，这就造成了资源的浪费，并增加了系统能耗[15]。

针对上述问题，结合Ceph和Docker容器的特点，提出了一种基于Docker的云平台资源弹性调度策略。首先对前人的工作进行总结，并指出其中的不足；然后对Ceph集群的数据副本存储策略进行改进，并建立了一个资源调度优化模型；在此基础之上，提出了基于Docker云平台的应用容器部署算法和应用在线迁移算法；最后，在综合考虑数据存储、资源负载和应用服务性能的基础上，利用Docker Swarm容器编排工具，实现了应用容器的动态部署和应用的在线迁移，从而达到了对云资源进行弹性调度的目的。

1　相关工作

针对云平台资源调度问题，学者们做了大量研究。Kang等[16]针对Docker云平台数据中心的能耗问题，提出了一种负载感知的异构容器集群能效管理方法。该方法利用K-medoid算法对云平台应用进行分类，并在此基础上建立了一个异构集群的能效模型，最后用不同类型的应用进行实验测试，表明该调度方法能在保证服务性能的情况下节约数据中心能耗，降低云平台运营成本。Meng等[17]针对容器应用在不同阶段所需计算资源不同所造成的资源浪费以及集群动态扩展带来的性能损失问题，提出了一种基于时序分析的资源预测模型。该模型根据历史负载数据对容器下一时隙所需的计算资源进行预测，然后根据预测值利用容器技术实现应用的快速弹性收缩，达到了合理部署云平台资源的目的。Guan等[18]提出了一种基于Docker容器的面向应用的数据中心资源分配方法。该方法针对不同应用的资源使用情况，综合考虑物理机资源和容器资源，建立了一个资源优化模型，并考虑到Docker容器资源分层复用的特点，实现了对数据中心资源的合理调度。何松林[19]利用Docker虚拟化技术构建了一个可弹性扩展的弹性集群，并针对集群的资源使用率问题提出了基于容器和集群节点负载数据的调度策略、弹性收缩容器时的宿主机调度策略和改善用户响应延迟的负载预测调度策略。

以上学者们提出的调度策略虽然在一定程度上提高了数据中心资源的利用率，但他们要么只考虑容器部署时的资源调度问题，要么只考虑了容器应用迁移过程中的资源调度问题，都没有考虑到集群应用数据存储对容器部署和应用迁移造成的影响。本文从应用容器部署和应用迁移的角度出发，在同时考虑数据存储和集群节点负载并保证服务性能的前提下，实现了云平台资源的弹性调度。

2　问题描述与建模

2.1　改进的Ceph集群数据存储策略

在基于Ceph集群的Docker容器云平台中，假设Ceph集群采用三个副本的数据存储策略，集群中的节点分为A区和B区，A区用于应用平稳期的业务需求，B区用于应用高峰期的业务需求。其中：A区有2R个机架，编号为racki(0≤i<2R,i∈Z)；B区有R个机架，编号为rackj(0≤j

图1　数据中心目录树结构Fig. 1　Directory tree structure of datacenter

图2　改进的Docker云平台架构及数据存储策略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　系统建模

基于2.1节改进了数据存储策略的Ceph集群和各个集群节点的资源负载情况，建立了一个资源调度优化模型，具体如下：

(1)

Wi=λWm+αWc+βWn;

(2)

λ+α+β=1;

(3)

(4)

3　调度策略

3.1　应用容器部署算法

基于第2章的内容，以下将给出一种既考虑数据存储、又考虑节点负载情况的应用容器部署方法。在云平台采集内存、CPU和网络利用率的具体数据，假设采集数据的时间间隔为S，一共采集D次，对采集的数据进行整理和计算，求得各种资源使用率的平均值即为Wm、Wc、Wn的值。对将要部署的应用进行类型判断，看该应用对内存、CPU和网络带宽的需求情况，分别设置参数λ、α、β的比例。例如对于CPU密集型应用可设置λ∶α∶β=3∶5∶2，则由式(3)可以计算出λ、α、β的具体值，再结合式(2)便可计算出Wi的值。在得到Wi的值后，便可根据式(4)将集群中的节点进行分类，尽量将应用部署在color=blue的节点上，为了保证应用性能，可在同一个主机上运行多个应用i的容器。将color=green的节点在Docker Swarm中的状态设置为drain，这样Swarm便不会将容器应用部署到该节点上，之后将该类节点设置为休眠状态，以节约数据中心资源。关于color=red的集群节点，将不会部署新的应用到该类节点上。应用i容器部署算法如图3所示。图中应用i容器会部署失败，是因为云平台中没有满足该资源调度模型的节点，此时应添加更多的物理服务器到云平台中。此外把应用i容器部署在节点rackk.hostj(第k+1个机架上的第j+1台主机)上之前，要把该应用的数据副本M1存储在该节点上，剩下的M2和M3按照2.1节提出的数据存储策略存储到相应的云平台节点中。

3.2　应用迁移算法

对于处于color=red状态的节点，当该类节点在一段时间内的平均资源利用率出现大于一定量W(W为常量，可由云平台管理员根据云平台情况设定)时，要对应用进行迁移，否则会因为各应用容器计算资源匮乏而使得应用性能下降，具体的应用迁移算法如下：

输入S、P、μ、ε；

输出hostd。

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

步骤6若y=Ct+1，查找结束。

4　实验及对比分析

4.1　实验环境

为了验证该调度策略的可行性和有效性，在基于Ceph集群的Docker云平台上进行了实验测试。实验中使用9台戴尔R710服务器。服务器的部署环境如下：A区包括2R=6台物理服务器，分别位于三个不同的机架(Rack)中，则每个机架中2台，即h=2；B区包括R=3台物理服务器，位于3个不同的机架中；服务器均采用Centos7(64位)操作系统，8核处理器，2张千兆网卡和32 GB内存，磁盘容量为1 TB，做了RAID5。所使用的Ceph版本为Jewel(10.2.9)，每个服务器中将3个目录文件作为node节点的OSD，则N=3，数据副本数为3，使用的Docker 版本为17.06.0-ce，每台服务器既是Ceph集群的node节点，也是Swarm集群的Docker节点。为了更真实地模拟云平台环境，在某些服务器上运行了占用不同服务器计算资源的虚拟机，并用以下两个应用进行实验：

①用Java语言编写简单的计算程序，该程序中用到了乘法、除法和开根号的算数运算，将程序所需的数据先存放在文件中，将中间计算结果写入OSD中，数据大小约为8.5 GB，并将开始时间和结束时间输出到屏幕上；

②用Tomcat部署一个Java Web应用，该应用实现对磁盘中文档的搜索功能，实验用的数据文档存放在集群节点的OSD中，并将搜索到的文档路径返回到屏幕上。

4.2　实验过程及对比分析

表1　集群节点资源平均使用率　%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云平台上运行不同数量的应用①容器，对集群中处于运行状态的服务器数量进行了对比，对比结果如表3所示。从表3可以看出，在部署相同数量应用的情况下，优化后集群中处于运行态的节点数量要比优化前的少。优化前的集群在部署第8个应用时开始启用B区的服务器，而优化后的集群在部署第12个应用时，运行态的节点数突然快速增加，并开始启用B区的服务器，这是因为A区有一台节点宕机，而且此时A区没有满足条件的目的主机，所以需要把应用迁移到B区。而优化前的集群在部署第8个应用时就启用B区的服务器，可能是因为容器编排器Swarm的平均部署算法所致，从这里也可以看出，本文提出的调度算法对集群资源进行了更细粒度的划分，并能够在一定程度上减少数据中心处于运行态的服务器数量，以此达到了降低数据中心运营成本的目的，而且在集群相对稳定的情况下节约效果更明显。

表3　集群中处于运行态节点数对比Tab. 3　Comparison of the number of cluster nodes in running state

Docker有Compose、Machine和Swarm三种官方容器编排工具，但前两种都是对单主机上的容器进行编排，而本文研究的是集群Docker容器的调度问题，所以这里不作讨论。另外，Kubernetes是现今比较流行的一种开源集群容器编排工具，它与Swarm都采用Go语言开发，两者具有可比性。因此，为了测试本文提出的Docker Swarm容器编排工具与其他几种编排工具的性能差异，将其与原生Swarm和Kubernetes(V1.7)进行了实验和对比。在改进了存储方案的Ceph集群中进行实验，将10个应用①容器部署在该集群中，实验共进行了30次，对采集到的数据分别求平均值，结果如表4所示，其中Swarm_opt表示本文改进的Swarm容器编排工具。需要指出的是，由于Kubernetes的容器复制控制器(Replication Controller)可以通过复制而产生相同的容器副本，而Swarm是从仓库中拉取镜像生成容器，两者的差异对应用的完成时间影响很大，为了避免这种差异对实验结果造成的影响，实验中并没有使用Kubernetes的容器复制控制器功能。此外，Kubernetes中的最小调度单位是Pod，而Swarm是以Container为最小调度单位的，因此实验中，每个Pod中只包含一个Container,每个应用都是一个作业(job)。

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

由表4可以看到，当在集群中部署10个应用①时，使用Swarm、Swarm_opt、Kubernetes三种不同容器编排工具，集群中开启的节点数分别为M(Swarm)=7，M(Swarm_opt)=5，M(Kubernetes)=7，结合集群负载来看，这也体现了本文提出的容器编排器Swarm_opt在提高资源利用率上具有一定的优势。而在M(Swarm)=M(Kubernetes)=7的情况下，集群负载P(Kubernetes)>P(Swarm)，这可能是因为两者的实现机制决定的，因为Kubernetes比Swarm的实现机制更复杂。另外，在应用不发生迁移时，应用的完成时间从小到大依次为T(Swarm_opt)>T(Kubernetes)>T(Swarm)，本文提出的容器调度算法用的时间较长，这是由于集群中开启的节点数较少，各节点的资源在达到更高利用率的同时也稍微降低了节点的性能，故应用完成时间较长，但在节点开启数量减少25.87%的情况下，每个应用增加的完成时间仅增长了4%，而在非实时的应用中这种结果是很可观的。而T(Kubernetes)>T(Swarm)是因为Kubernetes中容器的启动速度比在Swarm中小，从而使得Kubernetes中应用的完成时间更长。而在应用发生迁移的情况下，与不发生应用迁移时的应用完成时间的增长量从小到大依次为：

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

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

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

从这里可以看出本文提出的调度算法在应用发生迁移时付出的代价最小，而由于Kubernetes中的容器启动慢问题，在应用发生迁移时，它付出的代价最大。

5　结语

本文改进了Ceph集群的存储策略，建立了一个资源调度优化模型，并在此基础上提出了云资源弹性调度策略，针对每个应用对资源需求情况的不同，对云平台资源进行了细粒度的划分，实现了云资源的弹性调度。该策略在迁移应用不发生迁移的情况下，一定程度上节约了集群资源，达到了合理利用云资源和降低数据中心运营成本的目的；而在发生应用迁移时，应用的性能虽稍有所下降，但与原生的Swarm和Kubernetes容器编排工具相比，仍能体现一定的优势。如何选择应用迁移时机，进一步减少应用迁移代价，是将来要做的工作。

参考文献:

[1]刘鹏.云计算[M].3版.北京:电子工业出版社,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].计算机研究与发展,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的虚拟化应用平台设计与实现[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技术入门与实战[M].2版.北京:机械工业出版社,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]武志学.云计算虚拟化技术的发展与趋势[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的分布式存储节能技术研究[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.)