CN106776005A - 一种面向容器化应用的资源管理***及方法 - Google Patents

Abstract

本发明公开了一种面向容器化应用的资源管理***及方法，其中，该***由管理节点和至少一个计算节点组成。管理节点提供应用管理和资源监控功能，根据应用需求的资源和计算节点能提供的资源来按需调度任务，同时监控各计算节点的CPU、I/O设备以及网络设备的资源利用率，来指导应用调度的准确执行。计算节点中的容器状态分析器对当前运行的容器进行资源消耗统计与分析，基于SVM的干扰检测模块判别和量化分析当前运行容器是否产生性能干扰，容器资源调度模块在产生性能干扰时对容器进行各项资源的动态调整。针对云环境下容器化应用提供了高效的部署和编排方案，能够根据应用工作负载的动态变化调整计算资源，自适应的进行弹性伸缩。

Description

一种面向容器化应用的资源管理***及方法

技术领域

本发明属于云计算与虚拟化技术领域，更具体地，涉及一种面向容器化应用的资源管理***及方法。

背景技术

云计算提供了一种弹性的资源供应模式，用户通过按需请求分配的方式来获取资源的使用权限，从而为自己的应用提供服务。传统的云计算平台通过虚拟机的形式租赁给用户，用户通过配置虚拟机的CPU个数、内存体积、磁盘容量以及网络带宽来获取自己需求的硬件资源。随着以Docker为代表的容器技术兴起，开发者能够将应用封装成标准的容器镜像然后统一发布到不同的平台。因为容器隔离了底层操作***并且提供应用所需的运行环境，所以将应用放到容器中运行能够克服跨平台的任务分发问题。

目前的容器管理***提供了容器的编排以及监控功能，用户在提交任务时就必须指定容器需求的资源消耗，然后交给管理***进行调度。但是在实际的运行过程中，应用工作负载的动态变化使得管理***不能及时的调整容器所需的计算资源，从而违背了应用的性能目标。虽然目前的容器管理***提供了横向扩展功能，允许应用增加或减少服务器的计算资源，但是需要用户手动指定每次伸缩时的改变资源量。这种管理方式缺乏足够的灵活性，不能及时的、适量的满足应用的资源需求。

发明内容

针对现有技术的以上缺陷或改进需求，本发明提供了一种面向容器化应用的资源管理***及方法，针对云环境下容器化应用提供了高效的部署和编排方案，并且能够根据应用工作负载的动态变化调整容器所需的计算资源，自适应的进行弹性伸缩。由此解决现有技术中不能灵活、及时、适量地满足应用的资源需求的技术问题。

为实现上述目的，按照本发明的一个方面，提供了一种面向容器化应用的资源管理***，包括：

管理节点和至少一个计算节点；所述管理节点包括管理模块和监控模块，所述管理模块包括应用管理模块、应用调度模块以及服务发现模块；所述计算节点包括容器状态分析器、基于SVM的干扰检测模块以及容器资源调度模块；

所述应用管理模块用于接收用户提供的应用定义文件，以及向用户提供应用状态的查询和修改功能，所述应用定义文件用于指定容器化应用的工作模式；

所述应用调度模块用于接收所述应用管理模块发送的应用的详细信息，以及接收所述监控模块反馈的对各计算节点的实时监控数据，并采用预设算法根据所述应用的详细信息以及各计算节点的实时监控数据将应用调度到目标计算节点上；

所述服务发现模块用于监测是否有计算节点加入集群，并在有计算节点加入集群时，将该计算节点的详细信息注册到数据库之中；

所述服务发现模块还用于监测是否有应用任务提交到所述管理模块，并在有应用任务提交到所述管理模块时，将与该应用任务对应的应用的详细信息存储到数据库之中；

所述监控模块用于监控集群中各计算节点的CPU、I/O设备以及网络设备的资源利用率，并将监控结果发送给所述应用调度模块；

所述容器状态分析器用于在所述应用调度模块将应用调度到目标计算节点上之后，对所述目标计算节点中当前运行的容器进行资源消耗统计与分析得到当前运行的容器的运行状况；

所述基于SVM的干扰检测模块用于接收所述容器状态分析器在预设周期发送的所述当前运行的容器的运行状况数据，并检测是否发生性能干扰；

所述容器资源调度模块用于在发生性能干扰时，按照应用对资源消耗的实际需求对异常状态的容器进行动态调整。

优选地，所述监控模块包括CPU监控模块、I/O监控模块以及网络监控模块：

所述CPU监控模块用于监控各计算节点中的CPU的个数以及各CPU的资源利用率；

所述I/O监控模块用于监控各计算节点中的I/O设备的读写请求数、数据量以及排队时间；

所述网络监控模块用于监控各计算节点中的网络设备的上传/下载数据包个数以及网络速率。

按照本发明的另一方面，提供了一种面向容器化应用的资源管理方法，应用于包括管理节点和至少一个计算节点的面向容器化应用的资源管理***，所述方法包括：

S1、所述管理节点接收用户提交的应用任务；

S2、若所述应用任务是一个已经执行过的任务，则执行步骤S4，否则，提示用户提交应用定义文件，所述应用定义文件用于指定容器化应用的工作模式；

S3、接收用户输入的运行与所述应用任务对应的应用所需要的资源上限；

S4、获取与所述应用任务对应的应用的详细信息；

S5、请求获取各计算节点的实时监控结果，所述实时监控结果包括各计算节点的CPU、I/O设备以及网络设备的资源利用率；

S6、若管理节点中存在最新的监控结果，则执行步骤S7，否则获取各计算节点的CPU、I/O设备以及网络设备的资源利用率；

S7、采用预设算法根据所述应用的详细信息以及各计算节点的实时监控数据对所述应用任务进行调度；

S8、若存在合适的执行所述应用任务的目标计算节点，则执行步骤S10，否则所述应用任务进入等待状态；

S9、若有任务执行结束退出或者有计算节点加入集群，则重新启动所述应用任务；

S10、将所述应用任务调度到所述目标计算节点；

S11、在所述管理节点将所述应用任务调度到所述目标计算节点之后，所述目标计算节点中的容器状态分析器持续跟踪和分析所述目标计算节点中每个容器的运行状态；

S12、根据所述每个容器的运行状态数据采用基于SVM的干扰检测模型检测是否发生性能干扰；

S13、若没有发生性能干扰，则执行步骤S15，否则，按照应用对资源消耗的实际需求对异常状态的容器进行动态调整；

S14、根据动态调整结果，修改所述应用任务对应的应用的资源占用上限；

S15、所述应用任务对应的应用处于正常运行状态，如果该应用没有结束运行，则跳往步骤S11，否则，结束流程。

总体而言，通过本发明所构思的以上技术方案与现有技术相比，具有以下有益效果：

(1)基于容器资源消耗的状态分析器：为了分析容器当前的运行状况，不仅需要收集CGroups产生的资源消耗数据，同时也需要考虑设备的资源利用率和排队时间。***通过访问CGroups中的cpuacct、memory、blkio以及net_cls等子***，收集每个容器当前的资源消耗数据。***同时也监控了每个计算节点的CPU、内存、I/O设备和网络设备的资源利用率和排队时间，综合这两者数据分析出容器的运行状态。相比传统的监控***，基于容器资源消耗的状态分析器能够更精准的刻画出容器的运行状态。

(2)基于SVM的自适应的干扰检测模型：容器状态分析器在每一个时间段的分析结果都将作为历史数据传递给SVM进行自适应的学习，通过不断的修正模型的训练参数来尽可能的拟合容器正常的运行状况。SVM将落在判定区域外的分析结果视为容器干扰情况的发生，并且将异常分析结果与正常状态结果的差值作为干扰的实际测量值。相比其他的干扰检测模型，基于SVM的干扰检测模型能够自适应的学习和调整，判别和量化分析当前运行容器受到的性能干扰程度。

(3)双层次资源调度策略：为了能够准确的对容器化应用进行资源调度，***采用了应用和容器双层次的资源动态调度策略。在应用级别，管理节点在运行过程中能够对用户事先设定的资源上限进行分析和调整，并且保证该应用调度到合适的计算节点上进行工作。在容器级别，一个应用通常由多个容器组成，而每个容器在不同的时间段里对资源消耗的需求也不同，因此***将按需给容器分配资源。如此，通过应用和容器双层次的资源动态调整，管理***中的容器化应用能够在最大程度上保障正常运行。

附图说明

图1为本发明实施例公开的一种面向容器化应用的资源管理***的结构示意图；

图2为本发明实施例公开的一种面向容器化应用的资源管理方法的流程示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

如图1所示，为本发明实施例公开的一种面向容器化应用的资源管理***的结构示意图，在图1所示的***中，包括管理节点和至少一个计算节点，管理节点包括管理模块和监控模块。管理模块包括应用管理模块、应用调度模块以及服务发现模块；计算节点包括容器状态分析器、基于SVM的干扰检测模块以及容器资源调度模块；

上述应用管理模块用于接收用户提供的应用定义文件，以及向用户提供应用状态的查询和修改功能，该应用定义文件用于指定容器化应用的工作模式；

其中，应用管理模块是管理模块的核心，用户在提交应用任务到管理节点时，需要提供一份完整的应用定义文件来指定应用的容器的工作模式。例如一个提供应用程序编程接口(Application Programming Interface，API)服务的网站包括请求处理、数据查询和负载均衡等多项功能，它们需要由应用的定义文件来保证容器间彼此的连通性以及确定外界访问API服务的访问端口。应用管理模块也同时向用户提供应用状态的查询和修改功能，简化容器化应用管理的复杂程度。

上述应用调度模块用于接收应用管理模块发送的应用的详细信息，以及接收监控模块反馈的对各计算节点的实时监控数据，并采用预设算法根据上述应用的详细信息以及各计算节点的实时监控数据将应用调度到目标计算节点上；

其中，应用调度模块关注的核心是每个应用所需求的资源和各计算节点能够提供的资源。用户在提交应用任务时需要指定应用在运行时的资源占用上限，然后应用调度模块会根据监控模块反馈的实时监控数据将应用调度到资源充足的目标计算节点上。在调度完成之后，根据应用资源需求的变化，应用调度模块会更新应用的实际资源需求，然后在需要的情况下对应用进行再次调度。

上述服务发现模块用于监测是否有计算节点加入集群，并在有计算节点加入集群时，将该计算节点的详细信息注册到数据库之中；

上述服务发现模块还用于监测是否有应用任务提交到管理模块，并在有应用任务提交到管理模块时，将与该应用任务对应的应用的详细信息存储到数据库之中；

其中，服务发现模块提供各计算节点的注册和查询功能。每当有新的计算节点加入集群时，服务发现模块就将新加入的计算节点的详细信息注册到数据库之中。每当有新的应用任务提交到管理模块时，服务发现模块也将这个应用的详细信息存储到数据库之中，方便管理员的查询工作。

上述监控模块用于监控集群中各计算节点的CPU、I/O设备以及网络设备的资源利用率，并将监控结果发送给应用调度模块；

其中，监控模块包括CPU监控模块、I/O监控模块以及网络监控模块。监控模块的职责是监控集群中每个计算节点的CPU、I/O设备以及网络设备的资源利用率，从而指导应用调度模块准确的进行调度。监控模块的每个模块既包含了各计算节点整体的数据，也包含了各计算节点中每个应用的消耗数据。其中CPU监控模块的核心指标是CPU的个数以及各CPU的资源利用率；I/O监控模块的核心指标是I/O设备的读写请求数、数据量以及排队时间；网络监控模块的核心指标是网络设备(例如网卡等)的上传/下载数据包个数和网络速率。

上述容器状态分析器用于在应用调度模块将应用调度到目标计算节点上之后，对目标计算节点中当前运行的容器进行资源消耗统计与分析得到当前运行的容器的运行状况；

其中，在计算节点中，底层的硬件资源提供着容器运行环境，在此之上包含容器状态分析器、基于SVM的干扰检测模块以及容器资源调度模块。

其中，容器状态分析器的作用是对当前运行的容器进行资源消耗统计与分析，它通过综合考虑每个容器由CGroups记录的资源消耗数据以及当前计算节点整体的资源利用率，从而准确的分析出容器的运行状况。CGroups中的cpuacct、memory、blkio以及net_cls是最为关键的子***，cpuacct子***提供了容器当前占用的CPU的核心数目和运行的时间；memory子***提供了容器当前的内存消耗和页面交换的信息；blkio子***提供了容器占用I/O设备的时间和处理的请求数；net_cls子***提供了网络数据包和网络传输量的统计。计算节点提供的实施监控数据包括CPU的利用率、内存的利用率和带宽、I/O设备的排队时间以及网络设备的上传/下载速率。

上述基于SVM的干扰检测模块用于接收容器状态分析器在预设周期发送的当前运行的容器的运行状况数据，并检测是否发生性能干扰；

其中，基于SVM的干扰检测模块的作用是判别和量化分析当前运行容器受到的性能干扰程度。针对每个容器，容器状态分析器每隔固定周期(例如30秒)会将当前正在运行的容器的资源消耗数据发送给SVM模型。支持向量机(Support Vector Machine，SVM)是一个支持在线式学***面上，可以得到一个异常检测的区域图，模型的参数正是区域划分的边界。SVM将落在区域外的分析结果视为容器干扰情况的发生，并且将异常分析结果与正常状态结果的差值作为干扰的实际测量值。SVM模型能够通过不断更新历史数据进行自适应的调整，准确检测出容器是否发生状态异常。

上述容器资源调度模块用于在发生性能干扰时，按照应用对资源消耗的实际需求对异常状态的容器进行动态调整。

其中，容器资源调度模块是在容器层面对应用包含的容器进行单独调度。一个容器化应用通常由多个容器组成，而每个容器在不同的时间段里对资源消耗的需求也不同。当应用处于高性能计算阶段时，应该将应用的CPU资源尽量调整到计算相关的容器上来保障执行时间不会太长，当应用处于高并发请求阶段时，应该将应用的I/O和网络资源尽量调整到数据库相关的容器上来保证请求的延迟时间不会太高。

请参阅图2，图2是本发明实施例公开的一种面向容器化应用的资源管理方法的流程示意图，该方法应用于具有管理节点和至少一个计算节点的面向容器化应用的资源管理***，其中，该方法包括以下步骤：

S1、所述管理节点接收用户提交的应用任务；

S2、若所述应用任务是一个已经执行过的任务，则执行步骤S4，否则，提示用户提交应用定义文件，所述应用定义文件用于指定容器化应用的工作模式；

S3、接收用户输入的运行与所述应用任务对应的应用所需要的资源上限；

S4、获取与所述应用任务对应的应用的详细信息；

S5、请求获取各计算节点的实时监控结果，所述实时监控结果包括各计算节点的CPU、I/O设备以及网络设备的资源利用率；

S6、若管理节点中存在最新的监控结果，则执行步骤S7，否则获取各计算节点的CPU、I/O设备以及网络设备的资源利用率；

S7、采用预设算法根据所述应用的详细信息以及各计算节点的实时监控数据对所述应用任务进行调度；

其中，该预设算法可以是先进先出算法First in first out，最佳匹配算法Thebest fit，最差匹配算法The worst fit等，本发明实施例不作唯一性限定。

S8、若存在合适的执行所述应用任务的目标计算节点，则执行步骤S10，否则所述应用任务进入等待状态；

S9、若有任务执行结束退出或者有计算节点加入集群，则重新启动所述应用任务，执行步骤S5；

S10、将所述应用任务调度到所述目标计算节点；

S11、在所述管理节点将所述应用任务调度到所述目标计算节点之后，所述目标计算节点中的容器状态分析器持续跟踪和分析所述目标计算节点中每个容器的运行状态；

S12、根据所述每个容器的运行状态数据采用基于SVM的干扰检测模型检测是否发生性能干扰；

S13、若没有发生性能干扰，则执行步骤S15，否则，按照应用对资源消耗的实际需求对异常状态的容器进行动态调整；

S14、根据动态调整结果，修改所述应用任务对应的应用的资源占用上限；

S15、所述应用任务对应的应用处于正常运行状态，如果该应用没有结束运行，则跳往步骤S11，否则，结束流程。

本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (3)

1.一种面向容器化应用的资源管理***，其特征在于，包括：管理节点和至少一个计算节点；所述管理节点包括管理模块和监控模块，所述管理模块包括应用管理模块、应用调度模块以及服务发现模块；所述计算节点包括容器状态分析器、基于SVM的干扰检测模块以及容器资源调度模块；

所述应用管理模块用于接收用户提供的应用定义文件，以及向用户提供应用状态的查询和修改功能，所述应用定义文件用于指定容器化应用的工作模式；

所述应用调度模块用于接收所述应用管理模块发送的应用的详细信息，以及接收所述监控模块反馈的对各计算节点的实时监控数据，并采用预设算法根据所述应用的详细信息以及各计算节点的实时监控数据将应用调度到目标计算节点上；

所述服务发现模块用于监测是否有计算节点加入集群，并在有计算节点加入集群时，将该计算节点的详细信息注册到数据库之中；

所述服务发现模块还用于监测是否有应用任务提交到所述管理模块，并在有应用任务提交到所述管理模块时，将与该应用任务对应的应用的详细信息存储到数据库之中；

所述监控模块用于监控集群中各计算节点的CPU、I/O设备以及网络设备的资源利用率，并将监控结果发送给所述应用调度模块；

所述容器状态分析器用于在所述应用调度模块将应用调度到目标计算节点上之后，对所述目标计算节点中当前运行的容器进行资源消耗统计与分析得到当前运行的容器的运行状况；

所述基于SVM的干扰检测模块用于接收所述容器状态分析器在预设周期发送的所述当前运行的容器的运行状况数据，并检测是否发生性能干扰；

所述容器资源调度模块用于在发生性能干扰时，按照应用对资源消耗的实际需求对异常状态的容器进行动态调整。

2.根据权利要求1所述的***，其特征在于，所述监控模块包括CPU监控模块、I/O监控模块以及网络监控模块：

所述CPU监控模块用于监控各计算节点中的CPU的个数以及各CPU的资源利用率；

所述I/O监控模块用于监控各计算节点中的I/O设备的读写请求数、数据量以及排队时间；

所述网络监控模块用于监控各计算节点中的网络设备的上传/下载数据包个数以及网络速率。

3.一种面向容器化应用的资源管理方法，其特征在于，应用于包括管理节点和至少一个计算节点的面向容器化应用的资源管理***，所述方法包括：

S1、所述管理节点接收用户提交的应用任务；

S2、若所述应用任务是一个已经执行过的任务，则执行步骤S4，否则，提示用户提交应用定义文件，所述应用定义文件用于指定容器化应用的工作模式；

S3、接收用户输入的运行与所述应用任务对应的应用所需要的资源上限；

S4、获取与所述应用任务对应的应用的详细信息；

S5、请求获取各计算节点的实时监控结果，所述实时监控结果包括各计算节点的CPU、I/O设备以及网络设备的资源利用率；

S6、若管理节点中存在最新的监控结果，则执行步骤S7，否则获取各计算节点的CPU、I/O设备以及网络设备的资源利用率；

S7、采用预设算法根据所述应用的详细信息以及各计算节点的实时监控数据对所述应用任务进行调度；

S8、若存在合适的执行所述应用任务的目标计算节点，则执行步骤S10，否则所述应用任务进入等待状态；

S9、若有任务执行结束退出或者有计算节点加入集群，则重新启动所述应用任务；

S10、将所述应用任务调度到所述目标计算节点；

S11、在所述管理节点将所述应用任务调度到所述目标计算节点之后，所述目标计算节点中的容器状态分析器持续跟踪和分析所述目标计算节点中每个容器的运行状态；

S12、根据所述每个容器的运行状态数据采用基于SVM的干扰检测模型检测是否发生性能干扰；

S13、若没有发生性能干扰，则执行步骤S15，否则，按照应用对资源消耗的实际需求对异常状态的容器进行动态调整；

S14、根据动态调整结果，修改所述应用任务对应的应用的资源占用上限；

S15、所述应用任务对应的应用处于正常运行状态，如果该应用没有结束运行，则跳往步骤S11，否则，结束流程。