基于SLA的容器资源调度方法和系统与流程

本发明涉及互联网技术领域，尤其涉及一种基于SLA的容器资源调度方法和系统。

背景技术：

LXC(Linux Container)容器是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源，而且不需要提供指令解释机制以及全虚拟化的其他复杂性。相当于C++中的命名空间(NameSpace)。容器有效地将由单个操作系统管理的资源划分到孤立的组中，以更好地在孤立的组之间平衡有冲突的资源使用需求。

如附图所示，Docker项目的目标是实现轻量级的操作系统虚拟化解决方案。在LXC的基础上，Docker进行了进一步的封装，让用户不需要去关心容器的管理，操作Docker的容器就像操作快速轻量级的虚拟机一样简单。

Docker和传统虚拟化(KVM、XEN等)方式的不同之处在于：容器是在操作系统层面上实现虚拟化，直接复用本地主机的操作系统，而传统方式则是在硬件的基础上，虚拟出自己的系统，再在系统上部署相关的APP应用。跟传统VM比较具有如下优点：1)操作启动快；2)轻量级虚拟化；3)开源免费；4)前景及云支持。

Docker核心解决的问题是利用LXC来实现类似VM的功能，从而利用更加节省的硬件资源供给用户更多的计算机资源。随着Docker的发展，在一台Docker宿主机中启动的容器越来越多。而且，Docker宿主机内部的容器数量和状态经常发生变化。如何对其进行性能管理及体验保证成为越来越需要关注的问题。现有技术中，性能管理仅仅针对少数VIP用户所对应的少数资源，绝大多数的用户的性能管理是无法被保证的，用户体验较差。

技术实现要素：

鉴于上述问题，提出了本发明以便提供一种基于SLA的容器资源调度方法和系统，能够按照服务等级进行性能管理和资源调度，提高用户体验。

根据本发明的一个方面，提供了一种基于SLA的容器资源调度方法，包括以下步骤：

基于SLA对Docker中的容器进行用户服务等级划分；

选取资源管理对象；

确定资源管理对象的目标性能；

进行容器初始化，根据用户服务等级在宿主机中对容器进行资源初始分配；

对宿主机中容器进行监视；

对监测到的实际性能的数据结合资源管理对象的目标性能进行分析，判断实际性能是否达到目标性能，根据判断结果进行调度。

可选地，所述资源管理对象为向用户的应用程序提供服务的至少一个资源单元。

可选地，所述资源单元分为CPU资源单元、内存资源单元、磁盘资源单元、网络资源单元。

可选地，所述确定资源管理对象的目标性能包括以下中的至少一种：

根据系统中预设的性能策略文件，通过管理对象的某些属性结合性能策略文件确定管理对象能够得到性能保证的目标性能；由管理人员通过管理界面手动设置管理对象的目标性能。

可选地，所述对宿主机中容器进行监视包括：

周期性或持续性地监测宿主机中各个容器的实际性能。

可选地，所述对宿主机中容器进行监视包括：

扫描宿主机内的容器，为每个容器配置对应的进程；

各个进程同步抽取各自容器的状态信息；

对各容器的状态信息进行处理，得到监控信息；

将各容器的监控信息汇总到数据队列中，每个容器的监控信息利 用容器标识进行区分。

可选地，所述各个进程同步抽取各自容器的状态信息包括以下一项或多项：

cpu占用信息、内存占用信息、网络流量信息以及磁盘占用信息。

可选地，所述对监测到的实际性能的数据结合资源管理对象的目标性能进行分析，判断实际性能是否达到目标性能，根据判断结果进行调度包括：

如果不满足目标性能，则需要确定进行资源调度；根据用户服务等级，优先保证优先级较高的用户的容器的性能；

如果满足目标性能，则继续进行监测。

根据本发明的另一个方面，提供了一种基于SLA的容器资源调度系统，包括：

服务等级划分模块，基于SLA对Docker中的容器进行用户服务等级划分；

资源管理对象选取模块，选取资源管理对象；

目标性能确定模块，确定资源管理对象的目标性能；

容器初始化模块，进行容器初始化，根据用户服务等级在宿主机中对容器进行资源初始分配；

监视模块，对宿主机中容器进行监视；

调度模块，对监测到的实际性能的数据结合资源管理对象的目标性能进行分析，判断实际性能是否达到目标性能，根据判断结果进行调度。

可选地，所述资源管理对象为向用户的应用程序提供服务的至少一个资源单元。

可选地，所述资源单元分为CPU资源单元、内存资源单元、磁盘资源单元、网络资源单元。

可选地，所述目标性能确定模块确定资源管理对象的目标性能包括以下中的至少一种：

根据系统中预设的性能策略文件，通过管理对象的某些属性结合性能策略文件确定管理对象能够得到性能保证的目标性能；由管理人员通过管理界面手动设置管理对象的目标性能。

可选地，所述监视模块对宿主机中容器进行监视包括：

周期性或持续性地监测宿主机中各个容器的实际性能。

可选地，所述监视模块包括：

扫描子模块，扫描宿主机内的容器，为每个容器配置对应的进程；

抽取子模块，各个进程同步抽取各自容器的状态信息；

处理子模块，对各容器的状态信息进行处理，得到监控信息；

汇总子模块，将各容器的监控信息汇总到数据队列中，每个容器的监控信息利用容器标识进行区分。

可选地，所述各个进程同步抽取各自容器的状态信息包括以下一项或多项：

cpu占用信息、内存占用信息、网络流量信息以及磁盘占用信息。

可选地，所述调度模块对监测到的实际性能的数据结合资源管理对象的目标性能进行分析，判断实际性能是否达到目标性能，根据判断结果进行调度包括：

如果不满足目标性能，则需要确定进行资源调度；根据用户服务等级，优先保证优先级较高的用户的容器的性能；

如果满足目标性能，则继续进行监测。

通过本发明提供的基于SLA的容器资源调度方法和系统，根据每个容器的用户优先级建立目标性能；为每个容器创建各自的进程，采用多进程并行运行的方式，抽取处理得到各个容器的监控信息，更有利于反映出宿主机内各个容器的运行状态；进而根据每个容器的用户优先级进行资源调度。利用本方法或系统，打破了Docker固定分配资源的做法，更加灵活地利用了分布式系统资源，有效地提高了资源利用率；通过用户优先级，保证了不同用户的性能目标，增强了用户体验。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示意性示出了现有技术中Docker与VM对比图；

图2示意性示出了根据本发明一个实施例的基于SLA的容器资源调度方法的流程图；

图3示意性示出了根据本发明一个实施例的基于SLA的容器资源调度中对宿主机中容器进行监视的流程图；

图4示意性示出了根据本发明一个实施例的基于SLA的容器资源调度系统的框图。

图5示意性示出了根据本发明一个实施例的基于SLA的容器资源调度系统的监视模块框图。

具体实施例

下面结合附图和具体的实施方式对本发明作进一步的描述。

如图2所示，本发明一个实施例的基于SLA的容器资源调度方法包括以下步骤：

101，服务等级划分

在选取资源管理对象之前通过SLA(Service Level Agrement，服务等级协议)来对Docker中的用户的应用程序进行服务等级的划分，所述服务等级的划分的对象为向用户的应用程序提供服务的至少一个资源单元，即管理对象。不同的服务等级对应不同的QoS(Quality of Service,服务质量)。

102，选取管理对象

在Docker中选取管理对象，所述管理对象为Docker中为用户的应用程序提供服务的资源单元。具体地，所述资源单元可以分为CPU资源单元、内存资源单元、磁盘资源单元、网络资源单元等，用于为用户的应用程序提供计算、存储、传输等服务。

103，确定目标性能

在确定管理对象后，确定管理对象的目标性能。

具体地，可以根据系统中预设的性能策略文件，通过管理对象的某些属性结合性能策略文件确定管理对象能够得到性能保证的目标性能，也可以由管理人员通过管理界面手动设置管理对象的目标性能。

此外，还有可能服务等级中已经预先确定了QoS，例如，在上述步骤101中划分服务等级时如果已经确定了服务等级的目标性能，则可将所述服务等级的目标性能确定为所述服务等级中选取的管理对象的目标性能。

目标性能的类型很多，可以包括但不限于CPU占用率、响应时延、每秒读写次数、数据传输速率等；可以是单一参数，也可以是多种参数的组合。

104，进行容器初始化，根据用户服务等级在宿主机中对容器进行资源初始分配；

用户的应用程序在Docker技术中都是以容器的形式存在的，容器之间彼此隔离，互不可见。

105，对宿主机中容器进行监视

周期性或持续性地监测宿主机中各个容器的实际性能。监测的实际性能的类型可以与目标类型相同，也可以不同。具体地，如目标性能为传输时延小于1ms，监测的实际性能信息的类型也可是时延，如监测到管理对象的实际时延为0.5ms。此外，监测的实际性能信息与目标类型不同的情况也可能存在。

如图3所示，在本实施例中，对宿主机中容器进行监视包括以下子步骤：

1051，扫描宿主机内的容器，为每个容器配置对应的进程；

具体地，在宿主机内部启动本地监控程序，定时扫描宿主机内处于存活状态的主机，为其创建对应的进程，并将容器名称记录在容器列表中。通过上述步骤，创建多个进程，并行执行以获取各个容器的监控信息。

步骤1052，各个进程同步抽取各自容器的状态信息；

各个进程抽取的状态信息包含但不限于以下几种：cpu状态信息、内存状态信息、网络状态信息以及磁盘状态信息，这几种信息是反映容器运行状态的关键指标信息。

Docker宿主机内具有一指定目录cgroup，cgroup目录下有一些文件是实时更新的，cpu状态信息和内存状态信息可通过读取这些文件记录的数据得到。而网络状态信息和磁盘状态信息可通过调用Docker的exec()接口得到。

所述进程在Docker应用容器引擎的指定目录cgroup下抽取所述宿主机内部所有cpu的中断值；所述进程获取对应的容器所占用的cpu总中断值；以及根据所述宿主机的cpu共享策略，对所述容器所占用的cpu总中断值进行处理得到所述容器的cpu占用信息。

所述进程在docker应用容器引擎的指定目录cgroup下抽取内存状态信息，对内存状态信息进行处理得到内存占用信息；

所述进程调用docker应用容器引擎的exec()接口，抽取得到网络状态信息和/或磁盘状态信息，对所述网络状态信息和/或磁盘状态信息进行处理得到网络流量信息和/或磁盘占用信息。

步骤1053，对各容器的状态信息进行处理，得到监控信息；

各个进程处理得到的监控信息包含但不限于以下几种：cpu占用信息、内存占用信息、网络流量信息以及磁盘占用信息。

步骤1054，将所有容器的监控信息汇总到数据队列中，每个容器的监控信息利用容器标识进行区分；

步骤106，对监测到的实际性能的数据结合目标性能进行分析，判断实际性能是否达到目标性能。

如果不满足目标性能，则需要确定进行资源调度；根据用户服务等级，优先保证优先级较高的用户的容器的性能。

比如，当实际性能IO时延超标，则进行资源调度，增加此服务登记的容器的资源配比，如CPU、缓存等，还可以通过限制较低优先级的服务等级的用户的容器的业务流量来满足较高优先级的服务等级的需求。得益于cgroup，可以很方便动态调整资源限制。

如果满足目标性能，则返回步骤105，继续进行监测，以便于在其性能不满足目标性能时进行性能管理。

本实施例也可设定资源调度的频率，例如10s/次。资源调度的频率与监视数据的更新率有关，监视数据的更新率至少高于资源调度的频率。进一步的，监视数据的更新率是由本实施例方法执行的预定时间间隔决定的，可选的，该预定时间依据系统性能而设定。在系统运行正常、资源丰富的情况下，管理人员无需经常对宿主机中容器资源进行调度，这样预定时间设定可较长；在系统运行不正常、资源紧张等情况下，管理人员需要实时调度宿主机中的容器资源，这样预定时间设定可较短，提升监视数据的更新率，进而提高资源调度的频率。

如图4所示，本发明一个实施例的基于SLA的容器资源调度系统，包括：

服务等级划分模块，

在选取资源管理对象之前通过SLA(Service Level Agrement，服务等级协议)来对Docker中的用户的应用程序进行服务等级的划分，所述服务等级的划分的对象为向用户的应用程序提供服务的至少一个资源单元，即管理对象。不同的服务等级对应不同的QoS(Quality of Service,服务质量)。

管理对象选取模块，

在Docker中选取管理对象，所述管理对象为Docker中为用户的应用程序提供服务的资源单元。具体地，所述资源单元可以分为CPU资源单元、内存资源单元、磁盘资源单元、网络资源单元等，用于为用户的应用程序提供计算、存储、传输等服务。

目标性能确定模块，在确定管理对象后，确定管理对象的目标性能。

具体地，可以根据系统中预设的性能策略文件，通过管理对象的某些属性结合性能策略文件确定管理对象能够得到性能保证的目标性能，也可以由管理人员通过管理界面手动设置管理对象的目标性能。

此外，还有可能服务等级中已经预先确定了QoS，例如，如果服务等级划分模块在划分服务等级时如果已经确定了服务等级的目标性能，则可将所述服务等级的目标性能确定为所述服务等级中选取的管理对象的目标性能。

目标性能的类型很多，可以包括但不限于CPU占用率、响应时延、每秒读写次数、数据传输速率等；可以是单一参数，也可以是多种参数的组合。

容器初始化模块，根据用户服务等级在宿主机中对容器进行资源初始分配；

用户的应用程序在Docker技术中都是以容器的形式存在的，容器之间彼此隔离，互不可见。

监视模块，对宿主机中容器进行监视

周期性或持续性地监测宿主机中各个容器的实际性能。监测的实际性能的类型可以与目标类型相同，也可以不同。具体地，如目标性能为传输时延小于1ms，监测的实际性能信息的类型也可是时延，如监测到管理对象的实际时延为0.5ms。此外，监测的实际性能信息与目标类型不同的情况也可能存在。

如图5所示，在本实施例中，监视模块包括：

扫描子模块，扫描宿主机内的容器，为每个容器配置对应的进程；

具体地，在宿主机内部启动本地监控程序，定时扫描宿主机内处于存活状态的主机，为其创建对应的进程，并将容器名称记录在容器列表中。通过上述步骤，创建多个进程，并行执行以获取各个容器的监控信息。

抽取子模块，各个进程同步抽取各自容器的状态信息；

各个进程抽取的状态信息包含但不限于以下几种：cpu状态信息、内存状态信息、网络状态信息以及磁盘状态信息，这几种信息是反映容器运行状态的关键指标信息。

Docker宿主机内具有一指定目录cgroup，cgroup目录下有一些文件是实时更新的，cpu状态信息和内存状态信息可通过读取这些文件记录的数据得到。而网络状态信息和磁盘状态信息可通过调用Docker的exec()接口得到。

所述进程在Docker应用容器引擎的指定目录cgroup下抽取所述宿主机内部所有cpu的中断值；所述进程获取对应的容器所占用的cpu总中断值；以及根据所述宿主机的cpu共享策略，对所述容器所占用的cpu总中断值进行处理得到所述容器的cpu占用信息。

所述进程在docker应用容器引擎的指定目录cgroup下抽取内存状态信息，对内存状态信息进行处理得到内存占用信息；

所述进程调用docker应用容器引擎的exec()接口，抽取得到网络状态信息和/或磁盘状态信息，对所述网络状态信息和/或磁盘状态信息进行处理得到网络流量信息和/或磁盘占用信息。

处理子模块，对各容器的状态信息进行处理，得到监控信息；

各个进程处理得到的监控信息包含但不限于以下几种：cpu占用信息、内存占用信息、网络流量信息以及磁盘占用信息。

汇总子模块，将所有容器的监控信息汇总到数据队列中，每个容器的监控信息利用容器标识进行区分；

调度模块，对监测到的实际性能的数据结合目标性能进行分析，判断实际性能是否达到目标性能。

如果不满足目标性能，则需要确定进行资源调度；根据用户服务等级，优先保证优先级较高的用户的容器的性能。

比如，当实际性能IO时延超标，则进行资源调度，增加此服务登记的容器的资源配比，如CPU、缓存等，还可以通过限制较低优先级的服务等级的用户的容器的业务流量来满足较高优先级的服务等级的需求。得益于cgroup，可以很方便动态调整资源限制。

如果满足目标性能，则继续进行监测，以便于在其性能不满足目标性能时进行性能管理。

本实施例也可设定资源调度的频率，例如10s/次。资源调度的频率与监视数据的更新率有关，监视数据的更新率至少高于资源调度的 频率。进一步的，监视数据的更新率是由本实施例方法执行的预定时间间隔决定的，可选的，该预定时间依据系统性能而设定。在系统运行正常、资源丰富的情况下，管理人员无需经常对宿主机中容器资源进行调度，这样预定时间设定可较长；在系统运行不正常、资源紧张等情况下，管理人员需要实时调度宿主机中的容器资源，这样预定时间设定可较短，提升监视数据的更新率，进而提高资源调度的频率。

通过本实施例提供的基于SLA的容器资源调度方法和系统，根据每个容器的用户优先级建立目标性能；为每个容器创建各自的进程，采用多进程并行运行的方式，抽取处理得到各个容器的监控信息，更有利于反映出宿主机内各个容器的运行状态；进而根据每个容器的用户优先级进行资源调度。利用本方法或系统，打破了Docker固定分配资源的做法，更加灵活地利用了分布式系统资源，有效地提高了资源利用率；通过用户优先级，保证了不同用户的性能目标，增强了用户体验。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的基于SLA的容器资源调度系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

本文中所称的“一个实施例”、“实施例”或者“一个或者多个实施例”意味着，结合实施例描述的特定特征、结构或者特性包括在本发明的至少一个实施例中。此外，请注意，这里“在一个实施例中”的词语例子不一定全指同一个实施例。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理 解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

此外，还应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。