基于docker弹性伸缩的大数据平台资源调度方法

【技术领域】

本发明涉及大数据资源调度技术领域，尤其涉及一种基于docker弹性伸缩的大数据平台资源调度方法。

【背景技术】

目前在大数据分析平台，Docker的使用已经逐步成熟，在Docker的环境中，分析数据的业务量及请求量会随着数据量的增加而增高,在如此庞大的业务请求下，需要有更多的容器资源给予支撑，如果资源调度不及时，最直接的影响就是导致业务应用性能下降甚至业务停顿，如果以人工的方式来进行资源调度，手动配置伸缩模式，复杂且低效，同时手动操作容易出错，直接影响业务应用。

因此，有必要研究一种基于docker弹性伸缩的大数据分析平台资源智能调度方法来应对现有技术的不足，以解决或减轻上述一个或多个问题。

【发明内容】

有鉴于此，本发明提供了一种基于docker弹性伸缩的大数据平台资源调度方法，能够实现应用系统的自动扩容和缩容，显著提高资源利用率，节约成本。

一方面，本发明提供一种基于docker弹性伸缩的大数据平台资源调度方法，其特征在于，所述调度方法的内容包括：

S1、对应用负载的资源消耗指标进行伸缩阈值设置；

S2、对实际资源消耗指标的数据进行采集；

S3、判断采集的数据与对应指标的阈值之间的关系，并触发对应的伸缩策略。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，步骤S3的内容具体包括：当采集的数据超过对应指标的阈值时，进行自动扩容；当采集的数据低于对应指标的阈值时，进行自动缩容。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，步骤S2中的数据采集具体为在特定的时间点、时间段和/或周期性地对资源消耗指标进行采集。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，资源消耗指标包括CPU占用率、内存占用率、存储占用率、网络利用率、每秒最大查询数量、每秒新建连接数量和每秒输入输出数量。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，伸缩策略的内容包括由用户定义应用的Pod资源分配量，包括最大副本数、最小副本数和伸缩步长。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，针对用户了解的场景，采用定时定量的伸缩策略，在特定的时间点或时间段，增加或减少特定的Pod数量。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，针对系统资源充足、应用负载多变的场景，采用自动弹性伸缩策略。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，自动弹性伸缩策略的具体内容包括：当触发伸缩策略后，进行一个伸缩步长的实例数量的增加或者减少，然后再次判断是否仍然需要调整，若是，则依据伸缩步长继续进行增加或减少，以此往复，直至不再满足触发条件。是否需要调整的判断依据为采集到的指标参数是否超过或低于指标阈值，超过则需缩容，低于则需扩容；在以伸缩步长为调整量的伸缩策略中还需判断超过或低于的量是否为一个伸缩步长以上，若是则进行调整，否则不调整。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，针对应用负载短暂性大幅波动的场景，采用连续检测确认方式判断对应的资源消耗指标是否为短暂性突发指标，若是，则不针对该波动进行扩容或缩容。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，连续检测确认的具体内容包括：在首次检测到应用负载大幅波动后的一个时间段内连续对该负载的对应资源消耗指标进行多次检测，若仅在某一短暂时间段内检测到超出阈值的资源消耗指标，则判定该资源消耗指标为短暂性突发指标。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，多次检测具体为周期性检测；周期性检测的间隔周期是30s。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述某一短暂时间段具体为30s。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，触发伸缩策略时，同时进行告警。

另一方面，本发明提供一种基于docker弹性伸缩的大数据平台资源调度系统，其特征在于，所述系统包括：

数据采集模块，用于对实际资源消耗指标的实时数据进行采集；

阈值设置模块，用于人机交互，对应用负载的资源消耗指标进行伸缩阈值的设置；

伸缩策略判断模块，用于判断采集的数据与对应指标的伸缩阈值之间的关系，并触发对应的伸缩策略。

与现有技术相比，本发明可以获得包括以下技术效果：通过docker弹性伸缩策略，可以降低人为反复调整资源以应对业务变化和高峰压力的工作量，帮助客户节约资源和人力成本。并且在大数据平台分析数据的增长时能够实现应用系统扩容，以满足业务需求，业务下降时能够实现应用系统减容，减少资源浪费。

当然，实施本发明的任一产品并不一定需要同时达到以上所述的所有技术效果。

【附图说明】

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是本发明一个实施例提供的基于docker弹性伸缩的大数据平台资源调度方法的流程图；

图2是本发明一个实施例提供的基于docker弹性伸缩的大数据平台资源调度方法的原理图。

【具体实施方式】

为了更好的理解本发明的技术方案，下面结合附图对本发明实施例进行详细描述。

应当明确，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

本发明通过docker弹性伸缩策略，为用户提供在大数据分析平台下，在某个时间段，如果有瞬时大规模的数据分析以及并发，根据业务需求自行定义Kubernetes实例(Pod)伸缩配置和伸缩策略，降低人为反复调整资源以应对业务变化和高峰压力的工作量，帮助客户节约资源和人力成本。

通过docker弹性伸缩策略，解决瞬时大规模的数据分析以及并发。如图1所示。调度方法具体包括；

(1)利用Kubernetes提供基于阈值的弹性伸缩策略，即基于应用负载(CPU占用率、内存占用率、存储占用率、网络利用率、每秒最大查询数量、每秒新建连接数量、每秒输入输出数量等)资源消耗等指标进行阈值设置，当触发阈值对应的伸缩策略时，发生告警，同时自动进行大数据分析平台的资源智能弹性扩缩容。

根据策略工作流，在特定时间点、时间段，或者周期性地，对大数据分析平台应用的负载指标进行采集。判断采集到的指标参数是否超过或低于指标阈值，如果满足条件则触发对应伸缩策略和告警。当应用负载高于指标阈值情况下进行自动扩容，低于阈值情况下进行自动缩容。

(2)在Kubernetes提供的弹性伸缩服务中，Pod是弹性伸缩的基本实例单位，应用部署运行在1个或多个Pod中。伸缩策略主要是Pod数量的增加或减少，以及Pod内各种服务模块对应的容器数量的增加或者减少，满足应用服务，提高资源利用率，节约成本。伸缩策略可以由用户定义应用的Pod资源分配量，如最大副本数、最小副本数、伸缩步长等参数。

(3)弹性伸缩服务可以进行定时定量操作，即对某个特定时间点、时间段进行某个特定的伸缩策略配置。例如每天早上9点增加指定实例数量，每天晚上11点减少指定实例数量。指定增加或减少的数量可以由用户设置，具体大小取决于实际的应用负载情况。定时操作适用于对具体应用的负载周期及服务器资源消耗压力周期比较了解的场景。

弹性伸缩服务增加或减少的实例数量也可以动态计算，即要伸缩的实例数量是由程序计算。程序计算的主要方式是，当指标触发阈值后，通过预先设置的伸缩策略进行首次实例数量的增加或者减少操作，即一个伸缩步长，操作调整完成后，会继续检测阈值指标，如果仍然需要调整，则依据伸缩步长继续进行增加或减少，以此往复。该方式适用于系统资源充足、应用负载多变的场景，通过自动弹性伸缩满足应用服务，提高资源利用率，节约成本。

(4)遇到应用负载短暂性大幅波动时，如指标突发性地超出或者低于指标阈值，则拥有相应地连续检测确认机制。比如在周期性指标检测方式下，检测周期是30秒，如果在接下来连续5个30秒的检测周期中，未再次检测到超出阈值的指标，即连续3分钟内只有第一个30s检测出了超出指标阈值，就可以认为是短暂性突发指标。短暂性突发造成的超出指标阈值，可以采用上述连续检测确认的方法，规避短时反复弹性伸缩，减少资源消耗的不稳定性。连续检测确认策略可以在弹性伸缩策略中提前设置，结合应用负载指标阈值来决定是否触发伸缩。

如图2所示。当建立用户数据数增加，资源内的CPU、内存或者网络发出警告，给予的Pod资源进行增加。当建立用户的数据量变为原来的量后，其Pod进行减少，通过应用系统减容，减少资源浪费。对业务在某个时间点、或者时间段进行设置，当建立用户数据数增加，给予的Pod资源进行增加；当建立用户的数据量减少时，其Pod进行减少。

实施例1：

(1)为Kubernetes定义应用A的Pod，同时设置Pod的资源分配量为3个容器，预先确定好相应的负载指标阈值：CPU使用率指标阈值上限为80％以上，阈值下限为30％；预先设置连续检测策略：每20s检测一次，连续检测3次达到阈值指标，则进行告警和伸缩操作；

(2)设置Pod伸缩阈值：最大的副本数10个、最小的副本数2个、伸缩步长为2个，设置完成后，根据策略工作流每隔20s进行一次指标检测；

(3)应用A的Pod数量初始值为2个，CPU使用率为25％，处于正常工作状态；随着大数据分析平台建立用户数据不断增加，应用A的CPU使用率持续变高，并且在连续3个20s的检测周期中，CPU使用率均在80％以上；系统发出告警“应用A的CPU资源紧张”，并自动为应用A增加2个Pod实例，增加完成后，应用A的CPU使用率变为60％，应用A的CPU资源再次充足，处于正常工作状态；

(4)当大数据分析平台应用A的数据分析处理减少时，CPU使用率持续降低，并且在连续3个20s的检测周期中，CPU使用率均在30％以下；系统提示“应用A的CPU资源冗余”，并自动为应用A减少2个Pod实例，减少完成后，应用A的CPU使用率变为50％，应用A的冗余CPU资源被释放，应用A仍处于正常工作状态。

通过docker弹性伸缩策略，可以降低人为反复调整资源以应对业务变化和高峰压力的工作量，帮助客户节约资源和人力成本。并且在大数据平台分析数据的增长时能够实现应用系统扩容，以满足业务需求，业务下降时能够实现应用系统减容，减少资源浪费。

以上对本申请实施例所提供的一种基于docker弹性伸缩的大数据平台资源调度方法，进行了详细介绍。以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

如在说明书及权利要求书当中使用了某些词汇来指称特定组件。本领域技术人员应可理解，硬件制造商可能会用不同名词来称呼同一个组件。本说明书及权利要求书并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求书当中所提及的“包含”、“包括”为一开放式用语，故应解释成“包含/包括但不限定于”。“大致”是指在可接收的误差范围内，本领域技术人员能够在一定误差范围内解决所述技术问题，基本达到所述技术效果。说明书后续描述为实施本申请的较佳实施方式，然所述描述乃以说明本申请的一般原则为目的，并非用以限定本申请的范围。本申请的保护范围当视所附权利要求书所界定者为准。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

上述说明示出并描述了本申请的若干优选实施例，但如前所述，应当理解本申请并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述申请构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本申请的精神和范围，则都应在本申请所附权利要求书的保护范围内。