CN107734052A - 面向组件依赖的负载均衡容器调度方法 - Google Patents

Abstract

本发明公开了一种面向组件依赖的负载均衡容器调度方法，包括以下步骤：(1)周期采集主机集群上各主机的资源负载信息；(2)将各主机的资源负载信息发送到资源管理器进行统一存储管理；(3)生成通信矩阵；(4)生成依赖矩阵；(5)容器调度模块根据通信矩阵、依赖矩阵以及从资源管理器读取的各主机资源负载信息对各主机进行评分，根据得分结果选择最优主机进行容器组件的部署分配；(6)当有新的容器组件需要分配时，重复执行以上第一至第五步骤。该发明具有使得运行在所有容器中的应用的性能达到总体最优化，同时兼顾主机集群的资源负载均衡等优点。

Description

面向组件依赖的负载均衡容器调度方法

技术领域

本发明涉及一种负载均衡容器调度方法，特别涉及一种面向组件依赖的负载均衡容器调度方法。

背景技术

近年来，随着云计算概念的推广与发展，云计算无论是在科学界以及产业界都得到了空前火热的研究与应用，经典的云计算架构包含IaaS、PaaS以及SaaS三层服务。但随着计算机技术的不断革新，应用版本迭代更新愈发频繁，此时传统云计算以虚拟机技术为最小粒度的资源调度单位的做法已经暴露出了各种各样的问题，比如资源利用率低下、调度分发缓慢、软件栈环境不统一等问题。而当下流行的容器技术凭借其轻量级、灵活使用、高资源利用率等特点恰好能够解决这样的问题，以Docker为代表的容器技术已经给云计算乃至整个IT界带来了深远的影响。在2014年召开的AWS re:Invent云计算大会上，Amazon宣布发布AWS EC2Container服务，支持Docker容器，并能够让AWS用户在托管的Amazon EC2实例群集上轻松运行应用程序。国内如腾讯、阿里巴巴等公司也已经在大规模地将Docker容器技术应用于实践中，种种事实说明容器技术已经崛起并得到广泛地使用。但是容器的兴起为云计算带来新机遇的同时，实际场景中应用的规模愈发庞大，应用间的相关依赖关系复杂，如何在集群环境中有效地对容器进行合理的部署分配成为了当前容器研究的主要问题之一。

在2014年12月的DockerCon大会上，Docker公司发布了一个原生的Docker集群管理工具Docker Swarm，Swarm基于简单的C/S架构，并内置了三种容器调度方法，分别是spread策略、binpack策略以及random策略。其中，spread策略会根据节点CPU与内存的占用率，以及该主机节点所拥有容器数量(不管是启动的还是未启动的)进行权衡，尝试把每个容器“平均”地部署到每个主机节点上，binpack策略同样会根据主机节点上CPU与内存资源的占用率为所有主机节点打分，但是返回的是使用最紧凑的主机节点，random策略会随机地在候选宿主机中选择一台来运行容器，而不管其可用的CPU或内存资源，主要用于调试。在Swarm工具的基础上，马晓光和刘钊远分析研究Swarm整体架构和调度策略，针对集群的资源碎片问题和负载均衡问题，提出一种静态平衡和动态预测相结合的容器调度算法。卢胜林等人提出了权值调度策略，依据Docker节点内的CPU，内存，网络负载以及该节点已经为容器分配出去但未被使用的内存占比作为衡量节点性能的重要参数，并通过C(N_i)，M(N_i)，N(N_i)和D(N_i)来分别表示以上几个参数，最后根据加权公式计算出节点的负载W(N_i)，给出了负载公式W(N_i)＝α*k1*C(N_i)+β*k2*M(N_i)+γ*k3*N(N_i)+α*k4*D(N_i)。为了进一步提高容器调度的性能，林伟伟团队提出了一种基于遗传算法的Docker集群容器调度优化策略，利用遗传算法搜索全局解空间的特性，在所有可能的分配列表中找出使集群负载最均衡的结果，但是，在计算个体适应度时，用到的模拟计算节点运行某容器时资源负载变化的函数不能完全贴近实际的运行情况，还有待进一步改进。Jose Monsalve等人提出了一种动态的CPU资源分配方法，作者认为，对于某些应用而言，过大的资源使用率会严重影响性能，并将时间序列的概念扩展到虚拟化容器的级别来为这个问题提供解决方案，但是有个比较缺陷在于，该文献旨在研究提高CPU的资源利用率，缺乏对其他资源利用率如内存等的研究与改进，具有一定的局限性。

虽然最近几年在容器调度方法上已经开展了不少研究工作，但是目前的容器调度方法都是将注意力局限在各种资源的利用率上，从而实现负载均衡，而忽略了运行在不同容器上的应用往往具有关联这一特点，尤其是在当前的大数据环境下，一个项目常常需要分割成多个小的应用组件，这些应用组件之间关系密切，需要共同协作完成任务，有些方法甚至考虑的是某种单独资源利用率的提升，在实际应用上具有比较大的局限性，这些方法都没有面向具体应用，从而使得在实际的应用场景上不会取得较为良好的性能效果。

发明内容

鉴于上述现有技术存在的不足，本发明目的是提供一种面向组件依赖的负载均衡容器调度方法，能根据当前待分配容器中运行的应用组件与运行于已分配容器上的应用组件的依赖关系，以及考虑各种资源利用率，从而实现所有运行在容器中的应用的性能达到总体最优化，同时兼顾主机集群的资源负载均衡。

为实现以上目的，本发明采取如下技术方案：

本发明的一种面向组件依赖的负载均衡容器调度方法，包括以下步骤：

第一步骤：主机集群中各主机上的资源负载监控器周期采集其主机的资源负载信息；

第二步骤：各资源负载监控器将各自主机的资源负载信息发送到资源管理器进行统一存储管理；

第三步骤：测算主机集群中各主机内部容器之间，以及两两主机容器之间传输数据的成本，并根据测算结果生成通信矩阵；

第四步骤：用户将当前需要分配的容器组件与已分配的容器组件进行比较，确定其依赖性，生成依赖矩阵；

第五步骤：将当前需要分配的容器组件提交到容器调度模块，容器调度模块根据通信矩阵、依赖矩阵以及从资源管理器读取的各主机资源负载信息对各主机进行评分，根据得分结果选择最优主机进行容器组件的部署分配；

第六步骤：当有新的容器组件需要分配时，重复执行以上第一至第五步骤。

作为优选的技术方案，第一步骤中，各资源负载监控器周期采集其主机上的资源负载信息，具体需要采集主机的CPU利用率、内存使用率、以及IO负载情况。

作为优选的技术方案，第二步骤中，所述资源管理器进行统一存储管理的方法为：

采用分布式键值存储仓库Etcd作为资源管理器，基于Raft算法提供强一致性、高可用的存储目录。

作为优选的技术方案，第三步骤中，所述测算主机集群中各主机内部容器之间，以及两两主机容器之间传输数据的成本的方法为：

以同一主机容器之间以及不同主机容器之间的小文件传输所需的时间延迟作为衡量主机集群中各主机内部容器之间，以及两两主机容器之间传输数据的成本的标准，结果表示为通信矩阵T，并设定通信矩阵T是对称的。

作为优选的技术方案，第四步骤中，所述将当前需要分配的容器组件与已分配容器组件进行比较，确定其依赖性，生成依赖矩阵的方法为：

设当前需要分配的容器组件为第i个容器组件，当容器组件i依赖于已分配的容器组件j，0<j<i时，则表示为D_i,j＝1，反之，容器组件i不依赖于已分配的容器组件j，0<j<i时，则表示为D_i,j＝0，其中矩阵D为依赖矩阵。

作为优选的技术方案，第五步骤中，所述容器调度模块根据通信矩阵、依赖矩阵、以及从资源管理器读取的各主机资源负载信息对各主机进行评分，根据得分结果选择最优主机进行容器组件的部署分配的步骤为：

设当前需要分配的容器组件为第i个容器组件，A_i,j代表容器i部署在主机j上，N_j表示主机集群中的第j个主机，矩阵T为通信矩阵，矩阵D为依赖矩阵，用C(N_j)、M(N_j)、I(N_j)分别表示第j个主机的CPU使用率、内存使用率、以及IO负载使用情况，函数location(A_k)返回容器k当前所在的主机节点的序号，max(T)返回通信矩阵T中所有组成元素的最大值，函数表示按照A_i,j部署策略计算出来的通信阻塞指数，而函数表示按照A_i,j部署策略的资源负载指数，ω₁、ω₂、ω₃分别表示CPU使用率、内存使用率、以及IO负载的权重，且有ω₁+ω₂+ω₃＝1，对主机的评分函数为F(A_i,j)＝α×nt(A_i,j)+β×lb(A_i,j)，其中，α与β表示两函数的权值因子，并有α+β＝1，最终将容器分配在评分函数值最少的主机中。

本发明相对于现有技术具有如下的优点和效果：

1、本发明全面地考虑了衡量节点负载状态的性能指标，现有的调度方法中关注集群各节点的负载指标主要包括CPU使用率，内存使用率。皆未考虑硬盘I/O负载的影响，对一些I/O占用高的容器任务如数据库，日志应用等，节点的I/O负载程度直接影响其运行效率。在分配容器时，本发明综合了所有这些因素，可以做到更大程度地减少资源的浪费，保证集群的负载均衡。

2、本发明的方法着眼于应用之间的依赖关系问题，尤其在当下绝大多数的工程项目场景下，项目常常需要多个应用协同工作完成任务，这些应用间显然存在这依赖关系，相互协作的应用间在分配时应该相对“靠近”，而这现有的调度方法很明显都没有考虑运行在各容器中的各应用间的关联关系，从而无法根据它们的依赖关系对容器进行合理的分配。因此，本发明能够更好地实现总体应用的性能表现最大化。

附图说明

图1为本发明方法的流程图；

图2为实施例中的按照spread算法执行的容器调度情况；

图3为实施例中的通信矩阵T；

图4为实施例中的通信矩阵D；

图5为实施例中的按照本发明执行的容器调度情况；

图6为实施例中的两种调度方法的作业用时比较；

图7为实施例中的两种调度方法的各主机节点负载情况。

具体实施方式

下面结合附图对本发明作进一步的详细描述，但本发明的实施和保护范围不限于此。

实施例

如图1所示，为本发明方法的流程图，主机集群中各主机上的资源负载监控器周期采集其主机的资源负载信息，具体需要采集主机的CPU利用率、内存使用率及IO负载情况；然后将各个资源负载监控器采集的资源负载信息发送到资源管理器进行统一存储管理；使用第三方测试工具测算主机集群中各主机内部容器之间，以及两两主机容器之间传输数据的成本，并根据测算结果生成通信矩阵；接着用户将当前需要分配的容器组件与已分配容器组件进行比较，确定在当前容器中运行的应用是否依赖于在已分配容器中运行的应用，从而生成依赖矩阵；将当前需要分配的容器组件提交到容器调度模块，容器调度模块根据通信矩阵、依赖矩阵以及从资源管理器读取的各主机资源负载信息对各主机进行评分，根据得分结果选择最优主机(评分结果最小)进行容器组件的部署分配；最后当有新的容器组件需要分配时，重复执行以上第一至第五步骤。

为了验证面向组件依赖的负载均衡容器调度算法的有效性，我们使用提出的调度方法和Swarm工具默认的spread调度算法进行性能测试比较。

设定测试情景为2个节点的Kafka集群(分别称为A₁，A₂)，3个节点的Spark集群(分别称为A₃，A₄，A₅)，Spark集群从Kafka集群接收信息并对信息进行WordCount。主机集群共有三个主机节点，配置如表1所示。

表1各宿主机节点配置

按照Swarm的spread调度算法进行容器调度，分配情况如图2所示，两个Kafka集群节点容器分别处于Node132及Node133中，三个Spark集群节点容器分别分布于Node134、Node132以及Node133中，很明显可以看出，Kafka集群及Spark集群的节点均分布在不同的宿主机中。

接下来，按照面向组件依赖的负载均衡容器调度方法进行容器调度，首先使用性能测试工具qperf测算同一主机上两容器间数据传输延迟以及不同主机上的两容器间延迟，每次发送消息的大小以倍增的方式从1个字节到64K，记录时间延迟如表2所示。

经过试验，发现三个主机的同一主机下容器间以及两两主机相互之间的容器间的数据传输延迟时间比值约为1：3，为了简单表示，所以将主机Node132、Node133和Node134设为N1、N2和N3，得出通信矩阵T如图3所示。

然后，分析这5个容器间的依赖关系可以得出如图4所示的依赖矩阵D，其中Kafka集群两节点容器A₁与A₂本应该存在依赖关系的，这里之所以有D_A1,A2＝0，是由于假定A₁先于A₂分配，此时A₂是不存在的，因此设置D_A1,A2＝1没有意义，然后Spark集群的两节点容器A₃、A₄和A₅，假定A3为主节点，则有A₃依赖于A₁与A₂，然后A₄与A₅均依赖于A₃。

表2容器间延迟

然后设定每个容器的资源需求为0.5G内存，0.5核CPU，平均IO速率为0.5mb/sec，设定α＝1/3，β＝2/3，ω₁＝ω₂＝ω₃＝1/3，最终的分配情况如图5所示，两个Kafka集群节点容器均处于Node132中，三个Spark集群节点容器分别分布于Node133以及Node134中，很明显可以看出，这次Kafka集群处于同一个宿主机节点，Spark集群的节点分布在两个宿主机中。

依据不同的测试量开始测试作业用时，以调度1和调度2代指上述提到的两种调度情况，得到的测试结果以及各节点负载情况(依据资源负载函数如图6和图7所示。

从图6以及图7可以看出，面向组件依赖的负载均衡容器调度算法在比Swarm内置的spread策略能够更快地完成整个作业需求，而且随着数据量的增大，它们之间的差距变得越来越大，而且各主机节点的资源的负载均衡程度也能够达到比较好的效果。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。

Claims (6)

1.一种面向组件依赖的负载均衡容器调度方法，其特征在于，包括以下步骤：

第一步骤：主机集群中各主机上的资源负载监控器周期采集其主机的资源负载信息；

第二步骤：各资源负载监控器将各自主机的资源负载信息发送到资源管理器进行统一存储管理；

第三步骤：测算主机集群中各主机内部容器之间，以及两两主机容器之间传输数据的成本，并根据测算结果生成通信矩阵；

第四步骤：用户将当前需要分配的容器组件与已分配的容器组件进行比较，确定其依赖性，生成依赖矩阵；

第五步骤：将当前需要分配的容器组件提交到容器调度模块，容器调度模块根据通信矩阵、依赖矩阵以及从资源管理器读取的各主机资源负载信息对各主机进行评分，根据得分结果选择最优主机进行容器组件的部署分配；

第六步骤：当有新的容器组件需要分配时，重复执行以上第一至第五步骤。

2.根据权利要求1所述的面向组件依赖的负载均衡容器调度方法，其特征在于，第一步骤中，各资源负载监控器周期采集其主机上的资源负载信息，具体需要采集主机的CPU利用率、内存使用率、以及IO负载情况。

3.根据权利要求1所述的面向组件依赖的负载均衡容器调度方法，其特征在于，第二步骤中，所述资源管理器进行统一存储管理的方法为：

采用分布式键值存储仓库Etcd作为资源管理器，基于Raft算法提供强一致性、高可用的存储目录。

4.根据权利要求1所述的面向组件依赖的负载均衡容器调度方法，其特征在于，第三步骤中，所述测算主机集群中各主机内部容器之间，以及两两主机容器之间传输数据的成本的方法为：

以同一主机容器之间以及不同主机容器之间的小文件传输所需的时间延迟作为衡量主机集群中各主机内部容器之间，以及两两主机容器之间传输数据的成本的标准，结果表示为通信矩阵T，并设定通信矩阵T是对称的。

5.根据权利要求1所述的面向组件依赖的负载均衡容器调度方法，其特征在于，第四步骤中，所述将当前需要分配的容器组件与已分配容器组件进行比较，确定其依赖性，生成依赖矩阵的方法为：

设当前需要分配的容器组件为第i个容器组件，当容器组件i依赖于已分配的容器组件j，0<j<i时，则表示为D_i,j＝1，反之，容器组件i不依赖于已分配的容器组件j，0<j<i时，则表示为D_i,j＝0，其中矩阵D为依赖矩阵。

6.根据权利要求1所述的面向组件依赖的负载均衡容器调度方法，其特征在于，第五步骤中，所述容器调度模块根据通信矩阵、依赖矩阵、以及从资源管理器读取的各主机资源负载信息对各主机进行评分，根据得分结果选择最优主机进行容器组件的部署分配的步骤为：

设当前需要分配的容器组件为第i个容器组件，A_i,j代表容器i部署在主机j上，N_j表示主机集群中的第j个主机，矩阵T为通信矩阵，矩阵D为依赖矩阵，用C(N_j)、M(N_j)、I(N_j)分别表示第j个主机的CPU使用率、内存使用率、以及IO负载使用情况，函数location(A_k)返回容器k当前所在的主机节点的序号，max(T)返回通信矩阵T中所有组成元素的最大值，函数表示按照A_i,j部署策略计算出来的通信阻塞指数，而函数表示按照A_i,j部署策略的资源负载指数，ω₁、ω₂、ω₃分别表示CPU使用率、内存使用率、以及IO负载的权重，且有ω₁+ω₂+ω₃＝1，对主机的评分函数为F(A_i,j)＝α×nt(A_i,j)+β×lb(A_i,j)，其中，α与β表示两函数的权值因子，并有α+β＝1，最终将容器分配在评分函数值最少的主机中。