基于OpenStack 的高资源利用率Docker 调度模型

王小雪，王晓锋，刘 渊

（江南大学人工智能与计算机学院，江苏无锡 214122）

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 基于OpenStack 的Docker 调度模型Fig.1 Docker scheduling model based on OpenStack

1.1 初始化模块

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

表1 用户请求参数信息Table 1 User request parameter information

1.2 资源实时感知模块

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

图2 资源实时感知模块Fig.2 Real-time resource awareness module

资源实时感知模块基于消息队列实现对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”进行保存，等待资源实时感知模块从中获取消息。

图3 消息队列设计Fig.3 Message queue design

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

其中：n为资源类型的数目；wt为用户为资源t定义的优先级乘数，本文设置wcpu=wmemory=0.5，用户可根据业务需求，通过配置文件修改wt值，使得某项资源的优先级高于其他资源。资源实时感知模块通过汇总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 创建一个与源节点相同配置的容器。然后，在源节点上对容器设置检查点，并向目的节点依次发送容器的文件系统和内存状态信息，目的节点依次接收容器的文件系统数据和内存状态信息文件，并恢复容器的运行。最后，目的节点在恢复容器的网络环境后，会断开与源节点的连接，至此，容器迁移实施完成。

图4 容器迁移执行流程Fig.4 Execution flow of container migration

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

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

2.1 资源可用度评估阶段

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

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

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

2.2 优先级决策阶段

在优先级决策阶段设计了CPU 决策器（CPUMaker）和内存决策器（MemoryMaker）两个决策器，分别根据每个候选计算节点的CPU 利用率和内存利用率决策该节点的优先级。将计算节点i的CPU 利用率用表示，值可以通过调用psutil［27］模块的cpu_percent（）函数获得。计算节点i的“/proc/meminfo”文件中记录了其总内存以及可用内存信息，分别记为，则计算节点i的内存利用率可通过式（2）计算：

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

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

算法2优先级决策算法

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 作为比较对象。

表2 Docker 计算节点信息Table 2 Docker compute node information

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

表3 容器资源规格及工作负载Table 3 Resource specifications and workloads of the containers

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。

图5 负载型容器的资源使用信息Fig.5 Resource usage information of load-type container

图6 应用型容器的资源使用信息Fig.6 Resource usage information of application-type container

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

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

图7 负载型容器的资源利用率测试结果Fig.7 Resource utilization test results of load-type containers

由图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，该节点的资源利用率最高。

图8 应用型容器的资源利用率测试结果Fig.8 Resource utilization test results of application-type containers

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

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

图9 最大容器部署数量下的资源利用率测试结果Fig.9 Resource utilization test results for the maximum deployment number of containers

由图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 中计算节点资源负载均衡的同时提高资源利用率。