开放科学（资源服务）标志码（OSID）：

0 概述

随着互联网技术的不断发展和硬件设施的迭代更新，为满足人们对数据处理能力、资源利用率、资源集中化的迫切需求，云计算^[1]技术应运而生。OpenStack是云计算基础设施即服务（Infrastructure as a Service，IaaS）中重要的云计算管理平台^[2]，具备开源性、兼容性、灵活性和可扩展性。OpenStack默认以虚拟机为载体发布和交付服务应用，虚拟机由全虚拟化技术等传统虚拟化技术生成，需要安装完整的操作系统，会消耗大量资源与时间^[3]。近年来，以Docker容器为代表的操作系统级虚拟化技术因其轻量高效而备受关注^[4]。容器相较于虚拟机具有更快的部署和销毁速度、更好的服务性能以及更高的资源利用率等优点^[5]。鉴于OpenStack与Docker的优势，两者的集成是云计算发展的必然，OpenStack可以为容器提供更加灵活、细粒度的管控，Docker可以丰富OpenStack生态系统，提高云平台的资源利用率并优化云平台的整体性能^[6-7]。目前，OpenStack与Docker的集成已广泛应用于大数据分析^[8]、网络仿真^[9]、云边协同计算^[10]等领域。

资源利用率的提高可以降低能耗并节约成本^[11-12]。面向云计算领域的高资源利用率和低成本需求^[13]，设计高效的调度模型受到了学者们的广泛关注。文献[14]从CPU、内存、网络带宽和磁盘4个维度出发，建立基于最小化数据中心能耗、最大化数据中心效用以及最小化服务器数量的多目标优化的虚拟机调度模型，能在降低能耗的同时提高数据中心效用。文献[15]通过监控和预测虚拟机的资源使用，降低了物理机过载情况的发生，并通过虚拟机迁移与调度有效减少了运行的物理机数量，实现了云数据中心能耗的降低和资源利用率的提高。文献[16]针对资源受限云系统中具有时间约束的用户请求，提出一种时间敏感的资源分配和虚拟机调度方法，实现了多个异构节点之间的资源高效利用。文献[17]基于OpenStack云平台，使用动态资源分配与节能算法，释放了虚拟机占用的空闲资源，提高了云平台的资源利用率并降低了系统能耗。以上文献均是基于虚拟机对系统资源利用率提高问题进行研究。

在基于云计算的Docker容器调度模型方面，学者们也进行大量研究并取得了一定的研究成果。文献[3]将容器到虚拟机的部署问题转化为容器集合与虚拟机集合之间的稳定匹配问题，并设计了相应的匹配规则，以实现通过容器提高云环境资源利用率并降低能耗，但该方案中虚拟机对容器的偏好规则仅考虑CPU资源。文献[18]以最大化设备资源利用率以及Docker容器性能为目标，提出一种基于深度学习的容器调度方法，可自动为容器分配最优CPU资源，但是该方法需要提前采集大量的训练数据集进行建模，这会增加容器调度的实际应用难度。总体看来，当前基于云计算的Docker容器调度研究较少，在资源利用率提升方面需做进一步研究。

鉴于OpenStack与Docker集成的优势，如何有效调度Docker容器以保障OpenStack中资源的高效利用成为亟需解决的问题。Nova-Docker^[19]采用OpenStack中Nova组件的调度模型，将容器作为虚拟机进行调度，首先使用过滤算法从OpenStack的所有计算节点中选出满足容器资源请求的节点作为候选节点，然后通过计算各个节点的权值为容器选择最优计算节点。然而，与虚拟机不同，Docker通过共享Linux内核的方式来提供操作系统级别的虚拟化，将基于虚拟机的调度模型直接应用于Docker具有不确定性^[20]。Zun^[21]作为Nova-Docker的替代，在进行容器调度时随机选取最优计算节点，未能考虑OpenStack中资源的合理利用。Yun^[22]进一步对Nova-Docker和Zun的调度模型进行改进，针对容器的多样化资源需求为容器选取最优计算节点，实现了OpenStack中资源的合理利用。但是，以上3种Docker容器调度模型均基于用户对容器的初始资源请求对容器进行调度并分配资源，未充分考虑容器运行时的实际资源使用情况。在多数情况下容器并不会以满载的状态运行，根据容器的初始资源请求对容器分配的资源在大部分时间内都是空闲的，这会导致严重的资源浪费^[23]。

由于Yun不仅实现了OpenStack与Docker的集成，而且在部署效率、吞吐量、资源限制和兼容性方面均优于Nova-Docker和Zun，因此本文基于Yun设计并实现Docker调度模型（Docker Scheduling Model，DSM）。该模型针对现有OpenStack与Docker集成方案采用的调度模型存在资源利用率不高的问题，设计资源可用度评估与优先级决策（Resource Availability-evaluation and Priority Decision-making，RAPD）调度机制对容器实施调度。

1 基于OpenStack的Docker调度模型

本文基于OpenStack的Docker调度模型如图 1所示。DSM通过与OpenStack的Keystone、Glance以及Neutron组件的API进行交互，获取创建容器所需的镜像、网络等资源；通过调用Docker Engine提供的API部署容器，实现对容器生命周期的高效灵活管控。DSM主要包含初始化模块、资源实时感知模块、容器调度模块、资源实时监测模块和容器迁移模块。

1.1 初始化模块

初始化模块负责接收用户发送的创建容器所需的相关参数，详细的用户请求参数信息如表 1所示。通过对用户请求参数进行解析，可以得到容器的基本配置参数（容器名称、容器镜像、容器初始运行命令、容器的网络信息及容器的特权模式是否开启）和容器的初始资源请求参数（CPU请求规格和内存请求规格）。DSM可基于容器的基本配置参数获取创建容器所需的资源，容器的初始资源请求参数将作为容器资源请求参数，为容器调度模块提供支持。

1.2 资源实时感知模块

DSM引入资源实时感知模块，如图 2所示。资源实时感知模块负责采集OpenStack中各个计算节点的资源信息，包括可用资源信息和资源利用率信息，并将各个计算节点的资源信息进行汇总。

资源实时感知模块基于消息队列实现对OpenStack中计算节点资源信息的采集。消息队列由消息中间件实现，基于高级消息队列协议（Advanced Message Queuing Protocol，AMQP）开发。消息队列的存在可以使消息发送方和消息接收方在时间、空间和同步等方面解耦，从而实现发送方和接收方消息的异步传输、数据流量缓冲和数据持久化^[24]。基于AMQP开发的消息队列主要由消息发送方（Producer）、交换机（Exchange）、绑定（Binding）、队列（Queue）和消息接收方（Consumer）构成。资源实时感知模块的消息队列设计如图 3所示。资源实时感知模块作为Consumer监听名为“dsm_awareness”的Queue，该Queue以“dsm_resources_awareness”为binding key与名为“dsm_resources”的Exchange绑定。各个计算节点作为Producer将routing key为“dsm_resources_awareness”的消息（记录了该计算节点的资源信息）发送至“dsm_resources”，“dsm_resources”会将该消息转发至“dsm_awareness”进行保存，等待资源实时感知模块从中获取消息。

同时，资源实时感知模块会根据各个节点的资源利用率信息，计算该节点对应的负载，假设OpenStack中所有计算节点的资源利用率为$ {U}_{t}=\{{U}_{t}^{1}, {U}_{t}^{2}, \cdots , {U}_{t}^{i}，\cdots , {U}_{t}^{m}\} $，$ t $为资源的类型，$ m $为计算节点的个数，$ {U}_{t}^{i} $为第$ i $个计算节点的资源$ t $的利用率，则计算节点$ i $的负载可通过式（1）计算得出：

$ {l}_{i}=\sum\limits_{t=1}^{n}({w}_{t}\times {U}_{t}^{i}), \forall i\in \{\mathrm{1, 2}, \cdots , m\}, \sum\limits_{t=1}^{n}{w}_{t}=1 $

(1)

其中：$ n $为资源类型的数目；$ {w}_{t} $为用户为资源$ t $定义的优先级乘数，本文设置$ {w}_{\mathrm{c}\mathrm{p}\mathrm{u}} $=$ {w}_{\mathrm{m}\mathrm{e}\mathrm{m}\mathrm{o}\mathrm{r}\mathrm{y}} $=0.5，用户可根据业务需求，通过配置文件修改$ {w}_{t} $值，使得某项资源的优先级高于其他资源。资源实时感知模块通过汇总OpenStack中各个计算节点的资源信息并计算各个节点的负载，为容器调度模块提供支持。

1.3 容器调度模块

容器调度模块首先将容器的初始资源请求参数作为容器资源请求参数，并通过与资源实时感知模块交互获取OpenStack中各个计算节点的资源信息以及负载信息，将三者作为容器调度依据；然后采用RAPD调度机制对容器进行调度，通过资源可用度评估从所有计算节点中选出满足容器资源请求规格的节点作为候选节点，并利用优先级决策从所有候选节点中为容器选择最优计算节点，调用Docker Engine提供的API部署容器。

在容器部署成功后，资源实时监测模块会获取容器的实际资源使用参数，容器调度模块将该参数作为容器资源请求参数，对容器实施重新调度，为其选取新的最优计算节点。将容器当前所在的计算节点记为源节点，将对容器重新调度后选取的最优计算节点记为目的节点，如果源节点和目的节点相同，则在不停止容器运行的情况下通过调用Docker Engine提供的API更新容器的资源规格为其实际资源使用规格，释放容器占用的空闲资源，否则需要对容器执行迁移操作。

1.4 资源实时监测模块

在容器部署成功后，资源实时监测模块通过Docker自身提供的“docker stats”命令实时获取容器的资源使用信息。由于容器内服务的工作负载随时间动态变化会呈现不同的资源需求^[25]，因此需要设定一个长时间间隔（本文设置为1 h，用户可根据业务需求，通过配置文件自定义该时间间隔），资源实时监测模块采集该时间间隔内容器的各项资源使用信息，最终各项资源数值的抖动分别稳定在一个固定区间内，资源实时监测模块将每个区间的峰值作为容器对应资源的实际使用参数，并将容器的实际资源使用参数作为容器的资源请求参数，为容器调度模块提供支持。

1.5 容器迁移模块

如果容器当前所在的计算节点（源节点）与对容器重新调度后选取的最优计算节点（目的节点）不一致，则需要触发容器迁移模块。该模块负责将容器从源节点迁移到目的节点，保证迁移前后容器的基本配置、文件系统^[26]、内存状态和网络环境的一致性。容器迁移的执行流程如图 4所示。首先，源节点与目的节点建立连接，发送当前待迁移容器的基本配置信息，目的节点基于此信息，调用Docker Engine提供的API创建一个与源节点相同配置的容器。然后，在源节点上对容器设置检查点，并向目的节点依次发送容器的文件系统和内存状态信息，目的节点依次接收容器的文件系统数据和内存状态信息文件，并恢复容器的运行。最后，目的节点在恢复容器的网络环境后，会断开与源节点的连接，至此，容器迁移实施完成。

2 资源可用度评估与优先级决策调度机制

DSM采用RAPD调度机制对Docker容器实施调度，该机制主要包含两个阶段：1）通过资源可用度评估阶段对OpenStack中所有的计算节点进行评估，选择可满足容器资源请求规格的计算节点作为候选节点；2）通过优先级决策阶段从所有的候选节点中选择优先级最高的计算节点作为最优计算节点。

2.1 资源可用度评估阶段

该阶段负责从OpenStack的各个计算节点中找出满足容器资源请求规格的节点作为候选节点。在该阶段设计了CPU评估器（CPUEvaluator）、内存评估器（MemoryEvaluator）、负载评估器（LoadEvaluator）这3个评估器，分别根据计算节点的可用CPU、可用内存和负载评估其是否可以作为候选节点。资源可用度评估算法如算法1所示。算法的输入是所有的评估器（evaluators），待评估计算节点的对象（host，记录了计算节点的CPU、内存、资源利用率和负载等信息）以及容器的资源请求规格（specifications），算法的输出是一个布尔值（o），用于表征当前计算节点是否通过了所有的评估器成为了候选节点。

算法1  资源可用度评估算法

输入  evaluators，host，specifications

输出  o

1.为o设置初始值为True；

2.for evaluator in evaluators do

3.if evaluator == LoadEvaluator then

4.从host中获取当前待评估计算节点的负载，记为l；

5.if l > 70% then

6.将o的值设置为False；

7.break；

8.end if

9.else

10.从specifications中获取容器相应资源的请求规格，记为r；

11.从host中获取当前待评估计算节点的相应资源的逻辑剩余量，记为R；

12.if r > R then

13.将o的值设置为False；

14.break；

15.end if

16.end if

17.end for

18.返回o的值

DSM基于Yun实现，可以对容器CPU、内存使用量进行精确的限制，因此针对CPU和内存资源，对应的CPU评估器和内存评估器以计算节点的逻辑资源剩余量作为评估标准。如果容器的资源请求规格r大于计算节点相应资源的逻辑剩余量R，该计算节点将会被直接过滤。负载评估器会将当前计算节点的负载与设定的负载阈值（本文定义为70%）进行比较，如果节点的负载超过阈值，则将会被直接过滤。负载评估器的存在可以有效避免节点过载导致的系统响应时间变慢以及性能下降等问题。最终，通过所有评估器的计算节点将会作为候选节点，进入优先级决策阶段。

2.2 优先级决策阶段

在优先级决策阶段设计了CPU决策器（CPUMaker）和内存决策器（MemoryMaker）两个决策器，分别根据每个候选计算节点的CPU利用率和内存利用率决策该节点的优先级。将计算节点$ i $的CPU利用率用$ {U}_{\mathrm{c}\mathrm{p}\mathrm{u}}^{i} $表示，$ {U}_{\mathrm{c}\mathrm{p}\mathrm{u}}^{i} $值可以通过调用psutil^[27]模块的cpu_percent（）函数获得。计算节点i的“/proc/meminfo”文件中记录了其总内存以及可用内存信息，分别记为$ {M}_{\mathrm{t}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l}}^{i} $和$ {M}_{\mathrm{a}\mathrm{v}\mathrm{a}\mathrm{i}\mathrm{l}}^{i} $，则计算节点i的内存利用率可通过式（2）计算：

$ {U}_{\mathrm{m}\mathrm{e}\mathrm{m}\mathrm{o}\mathrm{r}\mathrm{y}}^{i}=\frac{{M}_{\mathrm{t}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l}}^{i}-{M}_{\mathrm{a}\mathrm{v}\mathrm{a}\mathrm{i}\mathrm{l}}^{i}}{{M}_{\mathrm{t}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l}}^{i}}\times 100\mathrm{\%} $

(2)

为防止计算节点某项资源的利用率低而优先级高，使用Yun的资源优先级系数自适应策略^[22]，默认每项资源的优先级系数为1.0，如果某项资源的利用率超过50%，则调整其优先级系数为1/2，如果利用率超过70%，则调整其优先级系数为1/4，如果利用率超过80%，则调整其优先级系数为1/8，通过实时感知当前计算节点的资源利用率，并动态调整相应资源的优先级系数，实现更均衡的资源利用，以提高计算节点的资源利用率。将计算节点$ i $的优先级转换为计算节点$ i $的得分并使用式（3）表示：

$ {s}_{i}=\sum\limits_{t=1}^{n}\left({w}_{t}\times {P}_{t}^{i}\times {U}_{t}^{i}\right), \forall i\in \left\{\mathrm{1, 2}, \cdots , m\right\}, \sum\limits_{t=1}^{n}{w}_{t}=1 $

(3)

其中：$ t $为资源的类型；$ n $为资源类型的数目；$ {w}_{t} $为用户为资源$ t $定义的优先级乘数；$ {P}_{t}^{i} $为计算节点$ i $的资源$ t $的优先级系数；$ {U}_{t}^{i} $为计算节点$ i $的资源$ t $的利用率；$ m $为候选计算节点的个数。$ {s}_{i} $越大的计算节点优先级越高，决策阶段的目标是从候选节点中找出使$ {s}_{i} $最大的计算节点$ i $作为最优计算节点，如算法2所示，算法的输入是所有的决策器（makers）以及所有候选计算节点的对象（hosts），算法的输出是一个列表（S），用于记录所有候选计算节点的得分。

算法2  优先级决策算法

输入  makers，hosts

输出  S

1.创建一个空列表S；

2.初始化所有候选计算节点的得分s为0.0，并将每个候选计算节点的得分s添加到列表S中；

3.for maker in makers do

4.从配置文件中获取用户指定的相应资源的优先级乘数，记为w；

5.for host in hosts do

6.初始化当前候选计算节点针对当前决策器得分s_maker的值为0.0；

7.从host中获取相应资源的资源利用率，记为U；计算相应资源的优先级系数，记为P；

8.s_maker = w × P × U；

9.将s_maker累加到S的当前计算节点对应的得分s中；

10.end for

11.end for

12.返回S列表

3 实验结果与分析

为分析并验证DSM性能进行以下实验：1）分析DSM如何通过实时监测容器的资源使用确定容器的实际资源使用参数；2）采用Nova-Docker、Yun和DSM部署固定数量的容器，以验证DSM相比于Nova-Docker和Yun可以实现资源的高效利用；3）测试Nova-Docker、Yun和DSM可以部署的容器数量的上限以及OpenStack中各个计算节点的资源利用率的上限，以验证DSM相比于Nova-Docker和Yun可以有效提升OpenStack中计算节点的资源利用率。

3.1 实验环境设置

基于OpenStack Mitaka构建实验环境，包含1个控制节点和3个Docker计算节点。控制节点的操作系统为CentOS 7.2，各个计算节点的操作系统为CentOS 7.8，Docker版本为17.06.0-ce。每个计算节点的资源总量信息如表 2所示。需要说明的是，由于Zun在兼容性方面不支持OpenStack Mitaka，因此在此未将Zun作为比较对象。

同时，引入3种负载型容器和3种应用型容器对DSM进行验证分析，每种容器的资源请求规格及工作负载如表 3所示。负载型容器使用Linux压力测试工具生成不同的容器系统CPU和内存负载，容器会不断地释放并重新申请分配资源，以此模拟容器的资源使用随时间动态变化的情况。应用型容器内运行不同的应用程序，每种应用程序都会产生资源消耗。

3.2 容器实际资源使用参数确定

DSM资源实时监测模块通过监测容器在固定时间间隔（本文设置为1 h）内的各项资源使用信息，确定容器对应资源的实际使用参数，作为容器重新调度的依据。该实验使用DSM部署表 3中的1个负载型容器（1个工作进程，2 048 MB内存）和1个应用型容器（安装RabbitMQ，发送和接收消息），分析DSM如何通过实时监测容器的资源使用确定容器的实际资源使用参数。

图 5给出了DSM监测到的负载型容器的资源使用信息。在图 5（a）中，横坐标表示采集轮次，以10 s为1个间隔，共有360个轮次，纵坐标代表容器的CPU利用率，可以看出该容器的CPU利用率的峰值为104%，DSM会基于此信息确定该容器的实际CPU使用参数为1；在图 5（b）中，容器的内存使用量的峰值为2 053 MB，DSM会基于此信息确定该容器的实际内存使用参数为2 053。DSM监测到的应用型容器的资源使用信息如图 6所示。在图 6（a）中，该容器的CPU利用率的峰值为304%，DSM会基于此信息确定该容器的实际CPU使用参数为3；在图 6（b）中，容器的内存使用量的峰值为119 MB，DSM会基于此信息确定该容器的实际内存使用参数为119。

3.3 固定容器部署数量下的资源利用率分析

DSM采用RAPD调度机制对容器进行调度，以提高OpenStack中计算节点的资源利用率，该实验分别采用Nova-Docker、Yun和DSM部署容器，通过比较部署后实验环境中各个计算节点的资源利用率情况，以验证本文提出的调度模型相比于其他两种调度模型可以实现资源的高效利用。首先分别采用Nova-Docker、Yun和DSM在实验环境中的3个Docker计算节点上各进行一组测试，每组测试分别部署9个负载型容器，涵盖负载型容器下的所有容器。然后分别统计每组测试中3个计算节点的容器数量、CPU利用率和内存利用率，结果如图 7所示。

由图 7可以看出，Nova-Docker和Yun采用基于容器初始资源请求的调度模型对容器进行调度与部署，实验环境中的3个计算节点均部署了容器并有一定的资源消耗，而DSM采用RAPD调度机制，所有的负载型容器最终均部署于计算节点3，该计算节点的资源利用率最高。换言之，在调度完成后，Nova-Docker和Yun需要同时开启3个计算节点以支持9个容器的运行，且容器会占用大量的空闲资源使其无法释放，造成资源的严重浪费，而DSM只需要开启1个计算节点便可以支持所有容器的运行，实现了资源的高效利用。

同样地，首先分别采用Nova-Docker、Yun和DSM在实验环境中的3个Docker计算节点上各进行一组测试，每组测试分别部署9个应用型容器，涵盖应用型容器下的所有容器。然后分别统计每组测试中3个计算节点的容器数量、CPU利用率和内存利用率，结果如图 8所示。由图 8可以看出，应用型容器的部署情况同负载型容器类似，相比于Nova-Docker和Yun，DSM将所有的应用型容器均调度至计算节点3，该节点的资源利用率最高。

3.4 最大容器部署数量下的资源利用率分析

Nova-Docker和Yun根据容器的初始资源请求对容器调度，未充分考虑容器运行时的实际资源使用情况，如果容器的资源使用量很小或长期未使用某项资源，则节点的资源利用率将会很低，且空闲的资源无法得到释放。DSM根据容器运行时的实际资源使用对容器进行重新调度，释放了容器占用的空闲资源，并提高了计算节点的资源利用率。该实验分别基于Nova-Docker、Yun和DSM部署3.1节中引入的3种负载型容器，测试Nova-Docker、Yun和DSM可以部署的容器数量的上限以及实验环境中各个计算节点的资源利用率上限，实验结果如图 9所示。

由图 9可以看出，相比于Nova-Docker和Yun，DSM部署了最多数量的容器，且各个计算节点的CPU利用率和内存利用率均有显著提升，实现了资源的高效利用。在CPU利用率方面，相比于Nova-Docker和Yun，DSM在节点1的CPU利用率提升最多，分别提升了42.68和46.89个百分点，在节点2的CPU利用率提升最少，分别提升了38.54和30.17个百分点；在内存利用率方面，相比于Nova-Docker和Yun，DSM在节点2的内存利用率提升最多，分别提升了53.01和53.33个百分点，在节点1的内存利用率提升最少，分别提升了38.40和28.69个百分点。

4 结束语

为满足云计算领域的高资源利用率需求及利用OpenStack与Docker集成的优势，本文设计并实现基于OpenStack的Docker调度模型，并通过实验验证了相比于经典的Nova-Docker、Yun集成方案采用的调度模型，该模型在CPU利用率和内存利用率上具有明显优势。考虑到云计算环境中容器的多样化资源需求，下一步将加入磁盘、网络带宽等资源作为Docker容器调度依据，同时针对容器的差异化资源需求，为容器设置专有资源权重，优化容器调度机制，并将对某种资源需求较多的容器调度至资源相对充分的计算节点，在实现OpenStack中计算节点资源负载均衡的同时提高资源利用率。