CN109347974B - 提高在线服务质量和集群资源利用率的混合调度系统 - Google Patents

Abstract

本发明提出一种提高在线服务质量和集群资源利用率的在线离线混合调度系统，包括信息采集模块，在线AM模块，离线AM模块，客户端模块，调度器模块；所述信息采集模块收集系统中各在线服务之间的调用关系，并存储到Redis中；当用户提交在线应用时，所述在线AM模块解析每个组件的依赖关系，并将所述组件按照所述依赖关系依次部署在集群中；当用户提交离线作业时，所述离线AM模块向RM申请资源，并将离线作业调度到集群中运行；所述客户端模块解析处理用户提交的作业，将所述作业转化为对应的请求向RM申请资源，并负责拉起所述在线AM模块向客户展示应用运行情况；所述调度器模块位于RM中，所述调度器模块会定时根据所述在线AM模块汇报的各容器关键度计算各服务器节点的关键度，并在调度离线作业时根据所述计算出的服务器关键度进行调度。

Description

提高在线服务质量和集群资源利用率的混合调度系统

技术领域

本发明涉及集群资源任务调度领域，主要涉及一种提高在线服务质量和集群资源利用率的在线离线混合调度系统。

背景技术

随着云计算技术的蓬勃发展，越来越多的计算和应用托管在共有云上。通过云平台，用户可以快速方便地将简单的应用扩展为大型的复杂应用，并且按需付费，在每个时间节点仅支出与其规模相当的成本。而供应商可以通过构建大规模数据中心和多租户共享资源等方式来获得规模经济效益。

然而，大多数云设施中的集群资源利用率非常低下，这极大地降低了成本效率。研究人员为Twitter上的一个数千台规模的生产集群进行了资源利用率分析，这个集群使用Mesos管理一个月，主要托管面向用户的、延迟敏感的在线服务。分析结果表明，CPU的总利用率始终低于20％，即使查看单个服务器，它们中的绝大多数在任何一周的CPU利用率都不超过50％。另一份研究结果表明，使用更成熟的Borg系统管理的12000台服务器规模的Google集群的CPU 利用率为25％，内存利用率为40％。服务器集群需要高昂的电力、网络和维护费用，低资源利用率意味着数据中心中的大量服务器处于空闲状态，将产生巨量的经济损失。

另一方面，世界正在加速进入数据爆炸的时代。大数据处理的规模已经从 TB级别进入到PB级别，随着物联网技术的蓬勃发展，未来将达到ZB甚至更高的级别。为了从这些海量的、异构的数据中挖掘价值、训练模型，大数据处理技术在不断演进，从Google提出MapReduce计算模型，到集群资源管理框架 Apache Mesos和Apache Hadoop YARN、内存计算框架Spark、容器管理框架 Kubernetes。但是，计算框架仅仅提供了工具，为了处理海量数据，仍需要大量CPU和内存提供足够的计算能力。面对巨大的计算能力缺口，现有的离线计算集群已经满负荷运行，仍无法满足需求。

在线服务和离线作业具有诸多不同的特征。在线服务(比如电子商务网站) 是延迟敏感的，并且其业务量与时间密切相关，白天的流量会明显高于夜晚。离线作业(比如训练机器学习模型)是延迟不敏感的，其本身的处理时间就在分钟级以上，甚至小时级、天级。并且离线作业与时间的关系不明显，全天时间都可以进行计算。研究人员分析负载特征发现，在线服务和离线作业具备压力错峰和资源错峰的条件，可以在一个统一的集群资源管理系统中混合调度，以提高集群资源利用率，减少资源浪费。然而，现有的研究成果中，在调度离线作业时，缺乏对在线服务运行状态的感知，可能将离线作业调度到对用户体验影响非常大的节点上，从而影响关键在线服务的响应时间。由于在线服务是延迟敏感的，不能容忍服务质量的大幅度下降，因此研究能够保障在线服务服务质量的混合调度方法势在必行。

现有的集群调度管理系统Apache Hadoop YARN支持调度离线作业，它可以将大作业切分为小作业调度到集群中的不同服务器上计算，并通过汇总得到最终结果。然而现有技术仅支持调度离线作业，不能足现代数据中心同时混合调度在线服务和离线作业的需要；对于系统中部署的多个组件，有的非常繁忙，而有的十分空闲，缺乏一种准确的方法定位系统中对用户体验影响最大的关键组件；另外，系统中没有考虑对这些关键组件进行优待，缺乏一种保障在线服务质量的方法。

发明内容

针对以上问题，本发明提出一种提高在线服务质量和集群资源利用率的在线离线混合调度系统。在线服务支持所有常见的延迟敏感服务，比如web服务器、消息队列、数据库等。用户将部署服务所需的环境和应用打包提交，系统即可将此服务调度到集群中合适的服务器上部署。系统也支持离线作业的调度运行，并且在调度离线作业时可以感知在线服务的运行状况，从而调整调度算法，避开那些繁忙的关键组件，减少离线作业对在线服务的影响，提高用户体验。

本发明的技术效果为：

1.支持在线离线混合调度

现有的开源大数据处理系统已经相对成熟，但它们都仅为离线批处理作业提供了支持。为了解决在线服务和离线作业同时混合调度的问题，必须引入新的机制来满足在线服务的新需求。本发明设计了双容器模型。系统中存在两种不同的容器：一种容器隔离较好且便于打包部署，作为延迟敏感的在线服务的运行环境；另一种容器隔离较差但启动迅速，作为平均运行时间较短的离线作业的运行环境。此外，在两层调度架构的系统中，每个应用都存在一个应用调度器角色。由于引入了新的容器类型，本发明也为其设计了新的在线应用调度器，它除了完成生命周期管理、申请资源、拉起容器等常规工作以外，还完成在线服务特有的分配端口等工作。

2.支持准确分析系统中的关键组件

为了分析用户请求中的关键组件，首先需要设计一套分布式追踪系统用于搜集请求的调用信息。为了在运行时准确无误地搜集信息，本发明设计了一个库用于方便开发人员记录信息，称为Tracker。Tracker作用于Http层之上，开发人员只需要在发起Http请求的时候多传入一些参数，就可以轻松记录下服务运行时信息。搜集到的信息存储在在线应用调度器的Redis中，计算模块会定时生成组件间的调用关系图，然后根据请求在各组件逗留的时间计算关键路径，最后对于关键路径上的组件，综合时间、访问频次和错误率等因素计算出最关键的组件。

3.基于关键组件调度离线作业，保障在线服务质量

为了解决盲目调度离线作业对在线服务的服务质量造成巨大干扰的问题，本发明基于避让的离线调度算法。在调度离线作业时，首先考虑数据本地性，将计算容器调度到离数据较近的节点，其次考虑离线避让性，即避开那些部署着较多关键组件的服务器，减少这些服务器上离线作业的数量，以此来减少在线服务收到的干扰。

附图说明

图1为本发明的整体结构图；

图2为本发明的信息采集模块架构图；

图3为本发明的调度算法流程图。

具体实施方式

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

本发明中包括的组件有，一是资源管理器ResourceManager(RM)，是集群资源的仲裁者，它的核心组件是一个可插拔的调度器，用于管理集群中的用户作业。二是组件是位于每个节点上的节点管理器NodeManager(NM)，管理该节点上的用户作业和工作流。RM和所有NM创建了集群统一的计算基础设施。三是组件是应用管理器ApplicationManager(AM)，用户作业生命周期的管理者。 AM是用户应用程序驻留的地方。系统中存在两类AM，在线AM和离线AM，分别负责在线服务的调度和离线作业的调度。这三个组件共同提供了一个可扩展的、灵活的、高效的环境,来运行各种类型的大数据处理作业。后文中RM、AM、NM 均为此段中的含义

本发明的系统架构图如图1所示，包括以下几个模块：

信息采集模块：负责收集系统中各在线服务之间的调用关系，并存储到 Redis中。它与在线AM模块进行通信。

在线AM模块：在线AM是专门为在线容器设计的模块。当用户提交在线应用时，在线AM负责解析个组件的依赖关系，并将它们按照依赖关系依次部署在集群中。在线AM还负责在线容器的生命周期管理、申请资源等工作，当多个在线服务部署在同一服务器时，需要处理端口冲突的问题。另外在线AM模块还包括存储调用关系的Redis模块，定时计算关键组件的组件计算模块，与RM、NM 通信的通信模块等部分。

离线AM模块：离线AM是管理离线容器(例如MapReduce作业)设计的模块，它主要负责调度离线作业并管理他们的生命周期，还负责与RM、NM进行通信。

客户端模块：客户端模块主要解析处理用户提交的作业，将其转化为对应的请求向RM申请资源，并负责拉起在线AM，向客户展示应用运行情况等工作。它与RM、在线AM模块进行通信。

调度器模块：调度器模块位于RM中，它会定时根据在线AM汇报的各容器关键度计算各服务器节点的关键度，并在调度离线作业的时候根据计算出的服务器关键度进行调度，从而对部署着较多关键组件的服务器节点进行避让，保障关键在线服务的服务质量。它与离线AM模块进行通信。

发明设计并实现了分布式追踪系统用作信息采集模块。为了方便开发人员记录信息，本发明的一个库称为Tracker。Tracker作用于Http层之上，开发人员只需要在发起Http请求的时候多传入一些参数，就可以轻松记录下本发明需要的服务运行时信息。信息采集模块的架构图如图2所示，在线服务组件中的信息采集模块会记录下需要的信息并存储到在线AM中的Redis中，具体信息如下：

当微服务接受其他微服务调用或向其他微服务发出请求时，Tracker会记录下

<url,serviceName,requestID,eventType,relatedService,timestamp,statusCode>7元组，称为Trace。其中url用于标识请求的种类，serviceName 用于标识微服务的名称，requestID是全局唯一的请求统一标识符，eventType 标识此次是接受请求还是发出请求，relatedService是与之发生交互的服务名字，timestamp是事件发生的时间戳，statusCode是Http请求的状态码，用于标识请求是成功还是失败。

本发明总体实现步骤为：

(1)用户配置各服务间的依赖关系与相关配置，然后将各微服务与运行环境打包为Docker镜像，然后将应用通过客户端提交给调度系统；

(2)客户端向RM申请资源，然后在申请到的容器中拉起在线AM，并监控应用的运行情况，为用户提供实时运行信息；

(3)在线AM启动时会根据配置信息向RM申请各微服务需要的资源，并在申请到的容器中根据依赖关系依次拉起各微服务，并监控它们的运行状态向客户端汇报；

(4)在用户访问个微服务时，信息搜集模块会搜集各组件间的调用关系，并且将这些调用关系存储到在线AM中的Redis中。在线AM中的计算模块会定时生成组件间的调用关系图，然后根据请求在各组件逗留的时间计算关键路径，最后对于关键路径上的组件，综合时间、访问频次和错误率等因素计算出最关键的组件；

(5)在线AM计算出的关键组件会定时汇报到RM中，当用户提交离线作业时，RM中的调度器模块会首先考虑数据本地性，将计算容器调度到离数据较近的节点，其次考虑离线避让性，即避开那些部署着较多关键组件的服务器，减少这些服务器上离线作业的数量，以此来减少在线服务收到的干扰。

信息的存储本发明选择了Redis，Redis是一个高性能的键值存储数据库，它可以将数据全部存储在内存中，从而获得较好的性能，非常适合本发明需要快速存取的场景。

最后本发明将Redis设计库放置于在了在线AM端，是因为追根溯源AM从 RM分化出来就是为了减轻RM的压力，让RM仅处理核心的资源调度工作

AM在收集Tracker传来的所有信息之后，会定时拉取它们进行关键组件的计算，主要包含以下三个步骤

(1)构建调用关系图

为每一次请求构建调用关系图：以服务接受和发出请求的中间部分作为节点，服务耗费的时间作为节点的权重，服务间调用关系作为边构建。其中两个服务组件之间的网络开销也被算为一个“特殊”的网络节点，其权重为网络开销耗费的时间，边为两端与服务的连接关系。

(2)计算关键路径

在完成构建请求调用关系图之后，使用一个回溯的算法计算图中每条路径所耗费的总时间，耗费总时间最长的调用关系链为关键路径，它的长短是影响用户体验的决定因素。

(3)计算关键组件

在为每次请求计算关键路径之后，汇集所有的请求，除去网络节点，以服务组件为单位计算其重要程度。

本发明在线服务一共有m个微服务，n种请求，T_i,j为请求j在服务i上耗费的总时间，E_i,j为请求j在服务i上出错的次数。那么对于第i个微服务的第 j种请求而言，其关键程度为：

公式等号右边的加法式子中，加号左边部分是时间分数，它等于在服务i 上耗费的请求j的总时间除以请求j在所有服务上耗费的总时间；加号右边是可靠性分数，它等于请求j在服务i上出错的次数除以请求在所有服务上出错的总数。α和β是经验值，在现有的实现中分别为0.7和0.3。

每个服务组件的关键程度为流经它的所有请求关键程度加权求和，即:

其中weight_j是第j种请求的权重，它等于此请求在所有服务上耗费的总时间除以所有请求在所有服务上耗费的总时间，如下式：

用户通过客户端模块与系统进行交互，交互的内容主要包括提交作业、获取作业运行状态和停止作业三种。

客户端模块在处理用户提交作业的请求时，客户端会解析用户提交的 xml配置文件，并将其内容写入到在线AM的启动上下文中，然后向RM申请一个容器作为在线AM的运行环境。这个容器是在线类型的，容器为Docker。申请到容器之后在其中拉起在线AM，并维持与在线AM的通信，等待用户进一步操作。

在运行过程中，在线AM会监控各服务运行情况，包括资源是否足够、是否成功拉起等，客户端模块会处理这些来自在线AM的监控信息，并以一种用户友好的方式向用户展示。

客户端模块在处理获取服务运行状态请求和停止作业的请求时方式类似，都是将相应的请求转发给AM，AM将请求转发给RM，最终由RM做出决策并通知 NM执行。

AM会通过心跳周期性地向RM发送计算完成的组件关键程度信息，本发明结合已有的机制提出一种基于避让的离线调度算法。

(1)计算避让概率

RM会将所有AM汇报的所有组件关键程度信息汇聚在一起，每一个节点的关键程度为其上的关键组件关键程度之和，不同的AM之间没有优先级，其汇报的信息被认为是同等重要的。然后由下式进行计算。

其中i是节点，S_i是节点上所有微服务分数之和，作为节点的分数，min(S)是所有节点分数的最小值，max(S)是所有节点分数的最大值，当max(S)大于min(S) 时，使用上式进行归一化并计算离线避让概率，当max(S)等于min(S)时，离线避让概率等于avoid_factor，最终离线避让概率的范围是[0,1]，所述avoid_factor 是避让因子，其取值范围在[0,1]之间。一般而言，避让因子越大避让效果越明显。特殊的，当它等0时，其效果等同于关闭离线避让功能。(2)离线调度算法

实际的离线调度算法非常复杂，包含权限验证、安全令牌以及预留容器等多种机制，下面描述其核心的部分。计算能否将一个容器调度在一个节点上时，其流程如图3所示。

首先会计算节点的剩余容量是否满足请求的申请量，如果不满足会直接导致请求失败。如果满足，则会检查数据本地性。

请求的数据本地性有三种级别：1)节点本地性，请求要求此容器必须被调度到指定节点上；2)机架本地性，请求要求此容器必须被调度到指定机架中的节点上3)任意本地性，请求要求此容器可以被调度集群中的任意一个节点上。检查数据本地性的目的是为了使计算节点与存储节点尽可能靠近，减少大量数据传输带来的网络开销，提高作业的运行速度。

如果此节点满足请求的数据本地性要求，则会检查避让概率，避让概率由前文介绍的关键组件分析算法计算得出。如果满足，则会重置请求的机会值，然后请求成功，即将此容器调度在此机器上。

检查数据本地性失败或检查避让概率失败都会使请求的机会值自增1，然后判断是否大于阈值，如果满足，则重置请求的机会值，然后请求成功。如果不满足，则会请求失败。其中的阈值是一个经验值，在目前的实现中为2。设计此机会机制的原因是为了避免集群繁忙时调度算法长时间寻找不到理想的同时满足数据本地性和避让概率的节点，从而导致作业卡在调度阶段无法进入运行状态的情况发生。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (6)

1.一种提高在线服务质量和集群资源利用率的在线离线混合调度系统，其特征在于，包括信息采集模块，在线应用管理模块，离线应用管理模块，客户端模块，调度器模块；所述信息采集模块收集系统中各在线服务之间的调用关系，并存储到Redis中；当用户提交在线应用时，所述在线应用管理模块解析每个组件的依赖关系，并将所述组件按照所述依赖关系依次部署在集群中；当用户提交离线作业时，所述离线应用管理模块向资源管理器申请资源，并将离线作业调度到集群中运行；所述客户端模块解析处理用户提交的作业，将所述作业转化为对应的请求向资源管理器申请资源，并负责拉起所述在线应用管理模块向客户展示应用运行情况；所述调度器模块位于资源管理器中，所述调度器模块会定时根据所述在线应用管理模块汇报的组件关键程度计算服务器关键度，并在调度离线作业时根据所述计算出的服务器关键度进行调度；

在线服务一共有m个微服务，n种请求，T_i,j为请求j在服务i上耗费的总时间，E_i,j为请求j在服务i上出错的次数，对于第i个微服务的第j种请求而言，所述组件关键程度为：

所述α，β为经验值，

所述服务器关键度为流经组件的所有组件关键程度加权求和；

所述系统进行调度的具体实现方式包括以下步骤：

步骤1，配置各微服务间的依赖关系与相关配置，将各微服务与运行环境打包为Docker镜像，并通过所述客户端提交给调度系统；

步骤2，所述客户端向资源管理器申请资源，然后在申请到的容器中拉起所述在线应用管理模块，并监控所述应用的运行情况；

步骤3，所述在线应用管理模块启动时根据配置信息向资源管理器申请各微服务需要的资源，并在申请到的容器中根据依赖关系依次拉起各微服务，并监控各微服务的运行状态向客户端汇报；

步骤4，在用户访问各微服务时，所述信息采集模块会采集各组件间的调用关系，并且将这些调用关系存储到在线应用管理模块中的Redis中，在线应用管理模块中的计算模块会定时生成组件间的调用关系图，然后根据请求在各组件逗留的时间计算关键路径，最后计算出关键组件；

步骤5，在线应用管理模块计算出的关键组件定时汇报到资源管理器，当用户提交离线作业时，资源管理器中的所述调度器模块对容器能否调度在节点上进行计算。

2.如权利要求1所述的系统，其特征在于，所述信息采集模块中具有Tracker库，当微服务接受其他微服务调用或向其他微服务发出请求时，Tracker会记录下7元组<url,serviceName,requestID,eventType,relatedService,timestamp,statusCode>，其中url用于标识请求的种类，serviceName用于标识微服务的名称，requestID是全局唯一的请求统一标识符，eventType标识此次是接受请求还是发出请求，relatedService是与之发生交互的服务名字，timestamp是事件发生的时间戳，statusCode是Http请求的状态码，用于标识请求是成功还是失败。

3.如权利要求1所述的系统，其特征在于，所述Redis是一个高性能的键值存储数据库，它可以将数据全部存储在内存中。

4.如权利要求2所述的系统，其特征在于，在所述步骤4中，所述在线应用管理模块计算出关键组件的步骤为：步骤4-1，为每一次请求构建调用关系图，所述构建方式为以服务接受和发出请求的中间部分作为节点，服务耗费的时间作为节点的权重，服务间调用关系作为边进行构建；步骤4-2，使用回溯算法计算图中每条路径所耗费的总时间，耗费总时间最长的调用关系链为关键路径；步骤4-3，在为每次请求计算关键路径之后，汇集所有的请求，除去网络节点，以服务组件为单位计算请求的重要程度。

5.如权利要求4所述的系统，其特征在于，所述调度器模块计算容器能否调度在节点上的具体方式为，首先会计算节点的剩余容量是否满足请求的申请量，如果不满足会直接导致请求失败，如果满足，则会检查数据本地性，所述请求的数据本地性包括节点本地性，机架本地性和任意本地性，所述节点本地性是请求要求此容器必须被调度到指定节点上，所述机架本地性是请求要求此容器必须被调度到指定机架中的节点上，所述任意本地性是请求要求此容器可以被调度到集群中的任意一个节点上；如果此节点满足请求的数据本地性要求，则会检查避让概率，如果满足，则会重置请求的机会值，即请求成功，即将此容器调度在此机器上；检查数据本地性失败或检查避让概率失败都会使请求的机会值自增1，并判断所述机会值是否大于阈值，如果大于阈值，则重置请求的机会值；如果不大于阈值，则请求失败。

6.如权利要求5所述的系统，其特征在于，所述避让概率的计算方式为资源管理器会将所有在线应用管理模块汇报的所有组件关键程度信息汇聚在一起，每一个节点的关键程度为其上的关键组件关键程度之和，不同的在线应用管理模块之间没有优先级，其汇报的信息被认为是同等重要的，所述避让概率的计算为：

其中i是节点，S_i是节点上所有组件关键程度之和，作为服务器关键度，min(S)是所有服务器关键度的最小值，max(S)是所有服务器关键度的最大值，当max(S)大于min(S)时，使用上式进行归一化并计算离线避让概率，当max(S)等于min(S)时，离线避让概率等于avoid_factor，最终离线避让概率的范围是[0,1]，所述avoid_factor是避让因子，其取值范围在[0,1]之间，避让因子越大避让效果越明显，当它等0时，其效果等同于关闭离线避让功能。

Images