CN111580951B - 一种任务分配方法及资源管理平台 - Google Patents

一种任务分配方法及资源管理平台 Download PDF

Info

Publication number
CN111580951B
CN111580951B CN201910118082.2A CN201910118082A CN111580951B CN 111580951 B CN111580951 B CN 111580951B CN 201910118082 A CN201910118082 A CN 201910118082A CN 111580951 B CN111580951 B CN 111580951B
Authority
CN
China
Prior art keywords
resource
task
resources
resource pool
amount
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910118082.2A
Other languages
English (en)
Other versions
CN111580951A (zh
Inventor
李金龙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Hikvision Digital Technology Co Ltd
Original Assignee
Hangzhou Hikvision Digital Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou Hikvision Digital Technology Co Ltd filed Critical Hangzhou Hikvision Digital Technology Co Ltd
Priority to CN201910118082.2A priority Critical patent/CN111580951B/zh
Publication of CN111580951A publication Critical patent/CN111580951A/zh
Application granted granted Critical
Publication of CN111580951B publication Critical patent/CN111580951B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请实施例提供了一种任务分配方法及资源管理平台，其中，方法包括：从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池；获取待分配资源池的可用资源量；在待分配资源池的可用资源量满足待下发任务所需的资源量时，将待下发任务下发至待分配资源池所属的服务器集群。本方案中，资源管理平台连接各服务器集群，管理员可以通过资源管理平台将任务统一下发至服务器集群。基于资源管理平台记录有每一资源池的可用资源量，资源管理平台可以对每一待下发任务所需的资源量和针对该待下发任务的待分配资源池的可用资源量进行比较，进而避免了管理员对每一待下发任务逐一进行判断，节省了人力资源，且提高了任务下发效率。

Description

一种任务分配方法及资源管理平台
技术领域
本申请涉及大数据技术领域，特别是涉及一种任务分配方法及资源管理平台。
背景技术
Hadoop是一种分布式系统基础架构，基于Hadoop可以提供高吞吐量来访问数据的优点，Hadoop广泛应用于大数据领域。在Hadoop的基础上可以进一步开发更多功能的框架系统。其中，Hadoop的框架中重要的一部分为HDFS(Hadoop Distributed File System，分布式文件系统)，HDFS为大量的数据提供了分布式存储。
YARN(Yet Another Resource Negotiator，通用的资源管理平台)是一种的Hadoop资源管理器，它是一个通用资源管理系统，可为服务器集群提供统一的资源管理和调度。通过YARN对服务器集群中的资源进行统一管理，使得服务器集群在资源利用率、资源统一管理和数据共享等方面均有较好的效果。另外，Hadoop生态圈还提供MapReduce和Spark等多种分布式计算的框架，基于这些分布式计算框架编写的应用均可以在YARN上运行。
目前Hadoop框架下的YARN和HDFS均只针对一个服务器集群进行资源管理，也就是说，每一个服务器集群会部署一个YARN和一个HDFS，每一个YARN仅负责对所在服务器集群中的资源进行管理，每一个HDFS仅负责对所在服务器集群中的数据进行存储。当管理员下发任务时，需要确定运行每一任务的服务器集群，以及该服务器集群中的可用资源是否满足该任务所需资源，在服务器集群中的可用资源满足的情况下再将任务下发至服务器集群中，接收到任务的服务器集群再为所接收到的任务分配资源并运行该任务。例如，待下发的任务包括任务1和任务2，其中，任务1指定由集群1运行，任务2指定由集群2运行，则管理员需先判断服务器集群1中的可用资源是否满足任务1所需的资源，以及判断服务器集群2中的可用资源是否满足任务2所需的资源，在服务器集群1和服务器集群2的可用资源均满足的情况，再分别将任务1下发至服务器集群1中，将任务2下发至服务器集群2中。尤其是待下发的任务较多时，管理员需要对每一任务所指定的服务器集群中的可用资源进行判断，在服务器集群中的可用资源满足任务的所需资源的情况下再将任务一一下发至对应的服务器集群中，这样不仅耗时而且浪费了人力资源。
发明内容
本申请实施例的目的在于提供一种任务分配方法及资源管理平台，以解决任务下发耗时且浪费人力资源的问题。具体技术方案如下：
第一方面，本申请实施例提供了一种任务分配方法，所述方法包括：
从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池，其中，所述资源管理平台连接的每一服务器集群的资源被划分为一个或多个资源池；
获取所述待分配资源池的可用资源量；
判断所述待分配资源池的可用资源量是否满足所述待下发任务所需的资源量；
若满足，则按照由所述待分配资源池中的资源执行所述待下发任务的策略，将所述待下发任务下发至所述待分配资源池所属的服务器集群。
可选地，所述方法还包括：
获取待处理任务；
将所述待处理任务存储于缓存中，所述缓存用于存储需要服务器集群处理的任务；
按照预设调度策略从所述缓存中获取任务，并将所获取的任务作为待下发任务。
可选地，将所述待下发任务下发至所述待分配资源池所属的服务器集群的步骤之前，还包括：
检测所述待分配资源池所属的服务器集群中当前运行的任务数量；
判断所述任务数量是否小于预设数量阈值；
如果否，则确定所述待下发任务下发失败；
如果是，执行将所述待下发任务下发至所述待分配资源池所属的服务器集群的步骤。
可选地，所述方法还包括：
对每一任务进行监测；
当监测到有任务结束时，将该任务从监测名单中删除，其中，任务结束为以下情况中的任一种：任务执行成功、任务执行失败和任务取消。
可选地，所述方法还包括：
接收服务器集群在任务执行成功后发送的任务执行结果；
将所接收到的任务执行结果存储于预设的存储区域，所述存储区域中记录有任务的标识与任务执行结果的对应关系；
当需要获取待查询任务的任务执行结果时，从所述对应关系中查找所述待查询任务的标识，并获取所查找到的标识对应的任务执行结果。
可选地，所述资源管理平台连接的每一服务器集群的资源被划分为一个或多个资源队列，每一资源队列的资源被划分为一个或多个资源池；所述资源管理平台记录有每一资源池的资源总量和可用资源量。
可选地，所述方法还包括：
向所述每一服务器集群发送资源汇总请求信息；
接收所述每一服务器集群反馈的针对服务器集群的资源总量和可用资源量，以及每一资源队列中各任务的运行所需资源量；
将属于同一资源队列的任务的运行所需资源量进行求和计算，并将所得到的计算结果确定为该资源队列的已用资源量；
检测资源队列中的每一任务是否被指定有资源池；
如果是，将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量，将该资源池的资源总量减去所述已用资源量，将所得到的结果更新为该资源池的可用资源量；
如果否，将未被指定资源池的任务的运行所需资源量，按照该任务所属资源队列的资源被划分时的比例分配至该资源队列对应的资源池中；将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量，将该资源池的资源总量减去所述已用资源量，将所得到的结果更新为该资源池的可用资源量。
可选地，所述方法还包括：
当有新资源池增加时，确定所述新资源池所属的服务器集群，作为目标服务器集群，并判断所述目标服务器集群是否与所述资源管理平台建立连接；
如果是，从所述目标服务器集群的资源队列中确定所述新资源池所属的资源队列，对所确定出的资源队列的资源按照预设比例重新划分；
如果否，获取所述目标服务器集群的配置文件，并安装所述配置文件；从所述目标服务器集群的资源队列中确定所述新资源池所属的资源队列；对所确定出的资源队列的资源按照预设比例重新划分。
可选地，所述方法还包括：
每隔预设时长，获取针对服务器集群、资源队列和资源池中的至少一种的已用资源量和可用资源量；
按照预设维度，对所获取的已用资源量和可用资源量进行统计。
第二方面，本申请实施例提供了一种资源管理平台，所述资源管理平台包括：
确定模块，用于从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池，其中，所述资源管理平台连接的每一服务器集群的资源被划分为一个或多个资源池；
资源量获取模块，用于获取所述待分配资源池的可用资源量；
判断模块，用于判断所述待分配资源池的可用资源量是否满足所述待下发任务所需的资源量；
下发模块，用于当所述判断模块的判断结果为是时，则按照由所述待分配资源池中的资源执行所述待下发任务的策略，将所述待下发任务下发至所述待分配资源池所属的服务器集群。
可选地，所述资源管理平台还包括缓存模块，所述缓存模块用于：
获取待处理任务；
将所述待处理任务存储于缓存中，所述缓存用于存储需要服务器集群处理的任务；
按照预设调度策略从所述缓存中获取任务，并将所获取的任务作为待下发任务。
可选地，所述资源管理平台还包括仲裁模块，所述仲裁模块用于：
检测所述待分配资源池所属的服务器集群中当前运行的任务数量；
判断所述任务数量是否小于预设数量阈值；
如果否，则确定所述待下发任务下发失败；
如果是，执行将所述待下发任务下发至所述待分配资源池所属的服务器集群的步骤。
可选地，所述资源管理平台还包括监测模块，所述监测模块用于：
对每一任务进行监测；
当监测到有任务结束时，将该任务从监测名单中删除，其中，任务结束为以下情况中的任一种：任务执行成功、任务执行失败和任务取消。
可选地，所述资源管理平台还包括结果获取模块，所述结果获取模块用于：
接收服务器集群在任务执行成功后发送的任务执行结果；
将所接收到的任务执行结果存储于预设的存储区域，所述存储区域中记录有任务的标识与任务执行结果的对应关系；
当需要获取待查询任务的任务执行结果时，从所述对应关系中查找所述待查询任务的标识，并获取所查找到的标识对应的任务执行结果。
可选地，所述资源管理平台连接的每一服务器集群的资源被划分为一个或多个资源队列，每一资源队列的资源被划分为一个或多个资源池；所述资源管理平台记录有每一资源池的资源总量和可用资源量。
可选地，所述资源管理平台还包括汇总模块，所述汇总模块用于：
向所述每一服务器集群发送资源汇总请求信息；
接收所述每一服务器集群反馈的针对服务器集群的资源总量和可用资源量，以及每一资源队列中各任务的运行所需资源量；
将属于同一资源队列的任务的运行所需资源量进行求和计算，并将所得到的计算结果确定为该资源队列的已用资源量；
检测资源队列中的每一任务是否被指定有资源池；
如果是，将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量，将该资源池的资源总量减去所述已用资源量，将所得到的结果更新为该资源池的可用资源量；
如果否，将未被指定资源池的任务的运行所需资源量，按照该任务所属资源队列的资源被划分时的比例分配至该资源队列对应的资源池中；将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量，将该资源池的资源总量减去所述已用资源量，将所得到的结果更新为该资源池的可用资源量。
可选地，所述资源管理平台还包括新增模块，所述新增模块用于：
当有新资源池增加时，确定所述新资源池所属的服务器集群，作为目标服务器集群，并判断所述目标服务器集群是否与所述资源管理平台建立连接；
如果是，从所述目标服务器集群的资源队列中确定所述新资源池所属的资源队列，对所确定出的资源队列的资源按照预设比例重新划分；
如果否，获取所述目标服务器集群的配置文件，并安装所述配置文件；从所述目标服务器集群的资源队列中确定所述新资源池所属的资源队列；对所确定出的资源队列的资源按照预设比例重新划分。
可选地，所述资源管理平台还包括统计模块，所述统计模块用于：
每隔预设时长，获取针对服务器集群、资源队列和资源池中的至少一种的已用资源量和可用资源量；
按照预设维度，对所获取的已用资源量和可用资源量进行统计。
第三方面，本申请实施例提供了一种机器可读存储介质，所述机器可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一所述的任务分配方法步骤。
本申请实施例提供的技术方案中，从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池；判断待分配资源池的可用资源量是否满足待下发任务所需的资源量；若满足，则按照由待分配资源池中的资源执行待下发任务的策略，将待下发任务下发至待分配资源池所属的服务器集群。通过本申请实施例提供的技术方案，资源管理平台连接各服务器集群，管理员可以通过资源管理平台将任务统一下发至服务器集群进行处理。基于资源管理平台记录有每一资源池的可用资源量，资源管理平台可以对每一待下发任务所需的资源量和针对该待下发任务的待分配资源池的可用资源量进行比较，进而避免了管理员对每一待下发任务逐一进行判断，节省了人力资源，且提高了任务下发效率。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的任务分配方法的一种流程图；
图2为资源管理平台记录资源池的一种示意图；
图3为本申请实施例提供的资源管理平台的一种结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
为了解决任务下发耗时且浪费人力资源的问题，本申请实施例提供了一种任务分配方法及装置，其中，任务分配方法包括：
从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池，其中，资源管理平台连接的每一服务器集群的资源被划分为一个或多个资源池，资源管理平台记录有每一资源池的可用资源量；
判断待分配资源池的可用资源量是否满足待下发任务所需的资源量；
若满足，则按照由待分配资源池中的资源执行待下发任务的策略，将待下发任务下发至待分配资源池所属的服务器集群。
本申请实施例提供的技术方案中，从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池；判断待分配资源池的可用资源量是否满足待下发任务所需的资源量；若满足，则按照由待分配资源池中的资源执行待下发任务的策略，将待下发任务下发至待分配资源池所属的服务器集群。通过本申请实施例提供的技术方案，资源管理平台连接各服务器集群，管理员可以通过资源管理平台将任务统一下发至服务器集群进行处理。基于资源管理平台记录有每一资源池的可用资源量，资源管理平台可以对每一待下发任务所需的资源量和针对该待下发任务的待分配资源池的可用资源量进行比较，进而避免了管理员对每一待下发任务逐一进行判断，节省了人力资源，且提高了任务下发效率。
下面首先对本申请实施例提供的一种任务分配方法进行介绍，其中，本申请实施例提供的任务分配方法应用于资源管理平台，该资源管理平台可以与多个服务器集群连接，并可以与所连接的服务器集群进行通信。资源管理平台可以作为下发任务的平台，也就是说，当存在待处理任务时，管理员先将这些待处理任务下发至资源管理平台，由资源管理平台再将所接收到的任务下发至对应的服务器集群进行处理，这样通过资源管理平台便实现对任务的统一下发，提高任务下发效率。
另外，资源管理平台还可以配置有配制层，配制层用于维护资源管理平台连接的每一服务器集群的相关配置。在配制层中每一个服务器集群的配置是相互独立的，可以认为，配制层中服务器集群的配置是资源管理平台与服务器集群连接的基础。
如图1所示，本申请实施例提供的任务分配方法包括如下步骤。
S101，从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池。
其中，资源管理平台连接的每一服务器集群的资源被划分为一个或多个资源池。每一服务器集群的资源的划分规则可以是自定义设定的，例如，可以将服务器集群的资源平均划分为多个资源池，这样，各资源池的资源量相等。还可以按照1:2的权重将服务器集群的资源划分为2个资源池，这样，其中一个资源池的资源量为服务器集群的资源量的1/3，另一个资源池的资源量为服务器集群的资源量的2/3。
资源管理平台可以对每一个资源池均进行记录。例如，资源管理平台连接有服务器集群1、服务器集群2和服务器集群3，其中，服务器集群1的资源被划分为资源池1和资源池2，服务器集群2的资源被划分为资源池3、资源池4和资源池5，服务器集群3的资源被划分为资源池6和资源池7，则资源管理平台可以对资源池1、资源池2、资源池3、资源池4、资源池5、资源池6和资源池7均进行记录。
资源管理平台可以记录每一资源池所属的服务器集群、资源总量、可用资源量等中的至少一种信息。当资源池的资源被使用时，资源管理平台可以对该资源池的可用资源量进行更新。
待下发任务中可以携带待分配资源池信息，待下发任务的待分配资源池可以是管理员指定的，待下发任务被指定待分配资源池之后，该待下发任务运行所需的资源则是待分配资源池的资源。对于资源管理平台来说，在获取到待下发任务之后，可以从该待下发任务所携带的信息中确定该待下发任务的待分配资源池。
S102，获取待分配资源池的可用资源量。
一种实现方式中，资源管理平台可以记录有每一资源池的可用资源量。基于此，资源管理平台在确定出待分配资源池之后，从所记录的资源池中寻找到待分配资源池，进而可以获取到该待分配资源池的可用资源量。
另一种实现方式中，资源管理平台在确定出待分配资源池之后，可以向该待分配资源池所属的服务器集群发送请求，服务器集群接收到请求后，向资源管理平台反馈该待分配资源池的可用资源量。这样，资源管理平台也可以获取到待分配资源池的可用资源量。
资源管理平台获取待分配资源池的可用资源量的方式并不仅限于以上两种实现方式，还可以包括其他的实现方式，在此不作限定。
S103，判断待分配资源池的可用资源量是否满足待下发任务所需的资源量，如果是，执行步骤S104。
待下发任务所需的资源量即为运行该待下发任务所需的资源，只有待分配资源池的可用资源量大于待下发任务所需的资源量的情况下，待下发任务才有可能运行成功，否则在资源不够的情况待下发任务会运行失败。
因此，若判断出待分配资源池的可用资源量满足待下发任务所需的资源量，即待分配资源池的可用资源量大于待下发任务所需的资源量，则可以执行下发的操作。而若判断出待分配资源池的可用资源量不满足待下发任务所需的资源量，即待分配资源池的可用资源量不大于待下发任务所需的资源量，则不将待下发任务下发至服务器集群，可以确定针对该待下发任务的下发失败。
S104，按照由待分配资源池中的资源执行待下发任务的策略，将待下发任务下发至待分配资源池所属的服务器集群。
在判断出待分配资源池的可用资源量满足待下发任务所需的资源量的情况下，将待下发任务下发至待分配资源池所属的服务器集群。
一种实现方式中，基于待下发任务中携带有待分配资源池信息，服务器集群接收到待下发任务之后，可以从待下发任务中获取到待分配资源池信息，进而可以确定待分配资源池，利用该待分配资源池中的资源执行该待下发任务。
另一种实现方式中，资源管理平台将待下发任务下发至服务器集群之后，还可以将待分配资源池信息发送至该服务器集群，进而指导该服务器集群利用该待分配资源池中的资源执行该待下发任务。
除了以上两种实现方式以外，资源管理平台还可以通过其他实现方式按照由待分配资源池中的资源执行待下发任务的策略，将待下发任务下发至待分配资源池所属的服务器集群。
一种实施方式中，资源管理平台作为下发任务的统一平台，还可以获取待处理任务。其中，待处理任务是需要服务器集群执行的任务，待处理任务可以是由管理员下发至资源管理平台。
资源管理平台获取到待处理任务之后，可以将所获取到的待处理任务存储于缓存中。其中，缓存可以预设的，用于存储需要服务器集群处理的任务。在缓存中，可以按照任务获取的时间顺序对各任务进行存储。
例如，资源管理平台在7点获取到待处理任务1，在7点15分获取到待处理任务2，在8点获取到待处理任务3，则在缓存中按照待处理任务1、待处理任务2和待处理任务3的队列顺序进行存储。
资源管理平台需要下发任务时，则可以从缓存中获取任务。资源管理平台可以按照预设调度策略从缓存中获取任务，并将所获取的任务作为待下发任务。确定为待下发任务后，则可以对待下发任务执行上述实施例中的步骤。
其中，预设调度策略可以是自定义设定的，例如，预设调度策略可以是FIFO(FirstInput First Output，先进先出)策略，即先存储至缓存中的任务会优先被资源管理平台确定为待下发任务而获取。资源管理平台从缓存中获取任务时，优先获取缓存中最先存储的任务。
例如，预设调度策略为FIFO策略，当资源管理平台需要从缓存中获取待下发任务时，缓存中存储有任务1、任务2、任务3和任务4，其中，任务1是9点存储至缓存中的，任务2是10点存储至缓存中的，任务3是7点存储至缓存中的，任务4是14点存储至缓存中的，由此可知任务3是最先存储的，那么资源管理平台从缓存中获取任务3作为待下发任务。
通过设置用于存储待处理任务的缓存，可以使得资源管理平台有序地对待处理任务进行下发。尤其是待处理任务较多的情况下，资源管理平台可以按照调度策略依次获取任务并下发至服务器集群进行处理，进而可以有效地避免出现任务下发堵塞。
一种实施方式中，将待下发任务下发至待分配资源池所属的服务器集群的步骤(S104)之前，还可以包括如下步骤。
检测待分配资源池所属的服务器集群中当前运行的任务数量，并判断任务数量是否小于预设数量阈值。
其中，资源管理平台获取服务器集群运行的任务数量的一种方式中，资源管理平台可以向服务器集群发送请求，服务器集群接收根据该请求向资源管理平台反馈当前所运行的任务数量，这样，资源管理平台可以获取到待分配资源池所属的服务器集群中当前运行的任务数量。
另一种方式中，每隔预设时长，资源管理平台的每一服务器集群会向资源管理平台反馈各自运行的任务情况，资源管理平台接收到各服务器集群反馈的任务情况之后，记录各服务器集群对应的任务情况。资源管理平台可以从所记录的任务情况中获取待分配资源池所属的服务器集群中的任务数量。
除了上述两个获取方式以外，资源管理平台还可以通过其他方式获取服务器集群运行的任务数量，在此不作限定。
其中，预设数量阈值可以是自定义设定的。不同的服务器集群对应的预设数量阈值可以是相同的，也可以不相同的。例如，服务器集群1对应的预设数量阈值为阈值1，即判断服务器集群1中运行的任务数量是否小于阈值1，服务器集群2对应的预设数量阈值为阈值2，即判断服务器集群2中运行的任务数量是否小于阈值2，其中，阈值1和阈值2可以是相同的，也可以是不相同的。
若判断出任务数量小于预设数量阈值，则执行将待下发任务下发至待分配资源池所属的服务器集群的步骤。若判断出任务数量不小于预设数量阈值，则可以确定待下发任务下发失败。
在确定待下发任务下发失败之后，则将该待下发任务不进行下发，并且可以将该待下发任务重新存储至缓存中，或者，还可以将该待下发任务标记为下发失败，并上报至管理员，管理员可以对该待下发任务重新进行配置。当然，对于下发失败的任务进行其他处理，处理的方式可以自定义，在此不作限定。
一种实施方式中，资源管理平台可以对每一任务进行监测，所监测的任务包括资源管理平台未下发的任务和服务器集群中运行的任务，资源管理平台将监测的任务记录在预设的监测名单上。也就是说，监测名单上记录的任务可以是当前正在运行的任务，还可以是未下发的任务。其中，监测名单上可以记录任务的标识信息、运行所需的资源量、任务当前的状态、执行该任务的服务器集群标识等。当监测到有任务结束时，将该任务从监测名单中删除。
其中，任务结束为以下情况中的任一种：任务执行成功、任务执行失败和任务取消。例如，服务器集群执行任务1完成之后，该服务器集群可以将任务1执行成功的信息反馈至资源管理平台，资源管理平台获取到任务1执行成功的信息后，将该任务1从监测名单上删除。
其中，任务取消可以是管理员执行的。当管理员执行取消操作的任务是未下发任务时，即该任务还在资源管理平台中，则资源管理平台对该任务进行取消操作，并将该任务从监测名单中删除。当管理员执行取消操作的任务是正在运行的任务时，即该任务在服务器集群中运行，则该服务器集群对该任务进行取消操作，在服务器集群完全取消操作之后，资源管理平台将该任务从监测名单中删除。
通过监测名单，资源管理平台可以获取到每一服务器集群中运行的任务数量。在资源管理平台下发任务时，可以根据监测名单中记录的任务数量下发任务，进而可以避免任务阻塞。
一种实施方式中，服务器集群在对任务执行成功后可以向资源管理平台发送任务执行结果，其中，任务执行结果中包括任务执行的时长、执行的相关数据等。
资源管理平台接收到服务器集群发送的任务执行结果之后，可以将所接收到的任务执行结果存储于预设的存储区域。其中，存储区域可以是自定义设定的，存储区域用于存储各服务器集群发送的任务执行结果。另外，存储区域中还存储有任务的标识与任务执行结果的对应关系，每一任务的标识与该任务的任务执行结果是一一对应的。
资源管理平台还可以为用户提供任务执行结果查询服务，当资源管理平台接收到针对任务执行结果的查询指令时，可以从存储区域中获取待查询任务的任务执行结果。具体地，资源管理平台从查询指令中获取待查询任务的标识，并在存储区域记录的对应关系中查找是否存在待查询任务的标识，若存在，则从对应关系中获取所查找到的标识对应的任务执行结果，即待查询任务的任务执行结果。
一种实施方式中，资源管理平台连接的每一服务器集群的资源被划分为一个或多个资源队列，每一资源队列的资源被划分为一个或多个资源池。资源管理平台对每一个资源池进行记录。其中，对服务器集群的资源进行划分的规则可以是自定义的，对资源队列的资源进行划分的规则也可以是自定义的。
以图2为例，资源管理平台连接的一个服务器集群的资源被划分为3个资源队列，分别为资源队列A、资源队列B和资源队列C，其中，资源队列A的资源被划分为2个资源池：资源池A1和资源池A2，资源队列B的资源被划分为3个资源池：资源池B1、资源池B2和资源池B3，资源队列C的资源被划分为1个资源池：资源池C1。资源管理平台对资源池A1、资源池A2、资源池B1、资源池B2、资源池B3和资源池C1均进行记录，记录各资源池所属的资源队列，以及各资源池的资源总量等信息。
基于上述例子，若服务器集群1的资源包括100GB内存和20CPU内核，对服务器集群的资源按照2:2:1进行划分后，其中，资源队列A的资源包括40GB内存和8CPU内核，资源队列B的资源包括40GB内存和8CPU内核，资源队列C的资源包括20GB内存和4CPU内核。对资源队列A的资源按照2:3进行划分，资源池A1的资源包括16GB内存和3CPU内核，资源池A2的资源包括24GB内存和5CPU内核。对资源队列B的资源按照2:1:1进行划分，资源池B1的资源包括20GB内存和4CPU内核，资源池B2的资源包括10GB内存和2CPU内核，资源池B3的资源包括10GB内存和2CPU内核。资源池C1独自占有资源队列C的资源：20GB内存和4CPU内核。
资源管理平台对每一资源池均有记录，可以记录每一资源池的可用资源量、资源总量等，还可以记录每一资源池所属的服务器集群、所属的资源队列以及所包含的资源总量占所属资源队列的资源总量的比例。
例如，资源管理平台记录有资源池A1的资源总量为16GB内存和3CPU内核，可用资源量为10GB内存和3CPU内核，所属的资源队列为资源队列A，所属的服务器集群为服务器集群1，所包含的资源总量占所属资源队列的资源总量的比例为2/5。
在该实施方式中，每一服务器集群的资源按照层次进行划分，在实际应用中可以按照资源队列或资源池进行资源分配，使得对服务器集群中的资源利用得更合理。比如，一个公司拥有一个服务器集群的资源，将该服务器集群中的资源按照公司的部门划分，每一个部门对应有一个资源队列的资源，若一个部门包括多个小组时，可以将该部门对应的资源队列的资源进一步进行划分，划分为若干个资源池，每一个小组对应一个资源池的资源。
一种实施方式中，资源管理平台可以向所连接的每一服务器集群发送资源汇总请求信息。其中，资源管理平台发送资源汇总请求信息的时机可以是根据用户的指令，即用户可以在资源管理平台下发资源汇总指令，资源管理平台获取到资源汇总指令后可以向每一服务器集群发送资源汇总请求信息。另外，资源管理平台还可以每隔预设时长向每一服务器集群发送资源汇总请求信息，其中，预设时长可以是自定义设定的。例如，预设时长为一个月，则资源管理平台每隔一个月可以向每一服务器集群发送资源汇总请求信息。
服务器集群接收到资源管理平台发送的资源汇总请求信息之后，可以将自身的资源汇总情况发送至资源管理平台。其中，资源汇总情况包括针对服务器集群的资源总量和可用资源量，以及服务器集群所包括的每一资源队列中各任务的运行所需资源量。
例如，服务器集群1的资源被划分为资源队列A和资源队列B，服务器集群1发送的资源汇总情况包括：该服务器集群1的资源总量为10GB内存和3CPU内核，可用资源量为8GB内存和3CPU内核，资源队列A中的任务1的运行所需资源量为1GB内存和1CPU内核，资源队列A中的任务2的运行所需资源量为2GB内存和1CPU内核，资源队列B中的任务3的运行所需资源量为1GB内存和1CPU内核。
资源管理平台可以接收各服务器集群反馈的各自的资源汇总情况，即接收针对服务器集群的资源总量和可用资源量，以及每一资源队列中各任务的运行所需资源量。
针对所接收到的各任务的运行所需资源量，资源管理平台可以将属于同一资源队列的任务的运行所需资源量进行求和计算，属于同一资源队列的任务在运行过程中所利用的资源均为该资源队列的资源，并且可以认为，资源队列的资源均用于分配给各任务。因此，所得到的计算结果即可以认为是该资源队列的已用资源量。
例如，任务1、任务2和任务3均属于资源队列A，其中，任务1的运行所需资源量为1GB内存和1CPU内核，任务2的运行所需资源量为2GB内存和1CPU内核，任务3的运行所需资源量为3GB内存和1CPU内核，则该资源队列A的已用资源量为6GB内存和3CPU内核。
在确定出每一资源队列中的任务之后，可以进一步地检测每一任务是否被指定有资源池。一般来说，任务下发至资源管理平台均被指定有资源池，任务被指定的资源池可以是管理员自定义指定的。当然，管理员也可以不指定，或者将任务直接下发至服务器集群中，这种情况下，任务是没有被指定资源池的。
若每一任务均被指定有资源池，则可以将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量。从针对各资源池的记录中获取该资源池的资源总量，并利用该资源总量减去已用资源量，将所得到的结果更新为该资源池的可用资源量。
例如，资源队列A的资源被划分为资源池A1和资源池A2，资源队列A包括有任务1、任务2、任务3、任务4和任务5，其中，任务1、任务2和任务3被指定的资源池为资源池A1，任务4和任务5被指定的资源池为资源池A2。任务1的运行所需资源量为1GB内存和1CPU内核，任务2的运行所需资源量为2GB内存和1CPU内核，任务3的运行所需资源量为1GB内存和1CPU内核，任务4的运行所需资源量为1GB内存和1CPU内核，任务5的运行所需资源量为2GB内存和1CPU内核，则任务1、任务2和任务3的运行所需资源量之和为4GB内存和3CPU内核，即为资源池A1的已用资源量，任务4和任务5的运行所需资源量之和为3GB内存和2CPU内核，即为资源池A2的已用资源量。若资源池A1的资源总量为15GB内存和8CPU内核，则资源池A1的可用资源量为11GB内存和5CPU内核，若资源池A2的资源总量为20GB内存和8CPU内核，则资源池A2的可用资源量为17GB内存和6CPU内核。
若存在任务未被指定有资源池，则将未被指定资源池的任务的运行所需资源量，按照该任务所属资源队列的资源被划分时的权重分配至该资源队列对应的资源池中。
例如，任务1属于资源队列A，当任务1未被指定资源池，其中，资源队列A的资源按照1：2的比例被划分为资源池A1和资源池A2，即可以认为资源队列A与资源池A1、资源池A2均存在对应关系，资源队列中1/3的资源为资源池A1的资源，资源队列中2/3的资源为资源池A2的资源。当任务1的运行所需资源量为6GB时，则按照1：2的比例进行分配，将其中的2GB分配至资源池A1中，即认为任务1运行时需要2GB资源池A1的资源，将其中的4GB分配至资源池A2中，即认为任务1运行时需要4GB资源池A2的资源。
在对未被指定资源池的任务的运行所需资源量重新进行分配之后，将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量，将该资源池的资源总量减去所述已用资源量，将所得到的结果更新为该资源池的可用资源量。
在上述举例的基础上，任务2和任务3被指定的资源池为资源池A1，任务2的运行所需资源量为2GB内存和1CPU内核，任务3的运行所需资源量为1GB内存和1CPU内核，则此时被指定为资源池A1的任务的运行所需资源量包括：任务1的2GB内存和1CPU内核、任务2的2GB内存和1CPU内核以及任务3的1GB内存和1CPU内核，则资源池A1的已用资源量为5GB内存和3CPU内核。
一种实施方式中，当需要增加新资源池时，可以先确定该新资源池所属的服务器集群，并作为目标服务器集群。其中，新资源池所属的服务器集群可以是自定义指定的。
在确定出目标服务器集群后，判断目标服务器集群是否与资源管理平台建立连接。其中，可以认为，已与资源管理平台建立连接的服务器集群是当前已存在的服务器集群，而未与资源管理平台建立连接的服务器集群当前不存在的服务器集群。
若判断出目标服务器集群已与资源管理平台建立连接，则可以从目标服务器集群的资源队列中确定新资源池所属的资源队列。其中，新资源池所属的资源队列可以是自定义指定的。
在确定出资源队列之后，按照预设比例，将资源队列中的资源重新划分至该资源队列原对应资源池和新资源池中。其中，预设比例可以是自定义设定的。例如，所确定出的资源队列为资源队列A，该资源队列中的资源为60GB内存内存和24CPU内核，按照1：2的比例被划分为资源池A1和资源池A2，即资源池A1的资源为20GB内存和8CPU内核，资源池A2的资源为40GB内存和16CPU内核。预设比例为1：1：2，则按照1：1：2将资源队列A的资源重新进行划分为资源池A1、资源池A2和新资源池，即资源池A1的资源为15GB内存和6CPU内核，资源池A2的资源为15GB内存和6CPU内核，新资源池的资源为30GB内存和12CPU内核。
若判断出目标服务器集群未与资源管理平台建立连接，则先获取目标服务器集群的配置文件，并安装该配置文件，在安装完成该配置文件后，目标服务器集群即与资源管理平台建立连接。一种实现方式中，资源管理平台获取到配置文件后，可以对配置文件进行解析，解析出该目标服务器集群的Rest-Api地址，通过访问该Rest-Api地址即可以与目标服务器集群进行通信。
在资源管理平台与目标服务器集群建立连接之后，可以从目标服务器集群的资源队列中确定新资源池所属的资源队列，对所确定出的资源队列的资源按照预设比例重新划分，并将划分后的资源对应分配给该资源队列对应的资源池。
一种实施方式中，每隔预设时长，可以获取针对服务器集群、资源队列和资源池中的至少一种的已用资源量和可用资源量。
其中，预设时长可以是自定义设定的。例如，预设时长可以是一周，还可以是一个月。根据已用资源量和可用资源量，可以得到资源的平均使用量及平均使用量比例、资源的峰值使用量及峰值使用量比例等信息。
按照预设维度，对所获取的已用资源量和可用资源量进行统计。其中，预设维度可以是自定义设定的。一种实现方式中，可以根据所针对的不同对象进行统计，例如，获取针对服务器集群的已用资源量和可用资源量之后，则对服务器集群的已用资源量和可用资源量进行统计，如下表1所示：
表1
另一种实现方式中，可以针对时间维度进行统计。例如，预设时长为一个月，针对服务器集群1的资源的平均使用量及平均使用量比例、资源的峰值使用量及峰值使用量比例进行统计，如下表2所示：
表2
本申请实施例提供的技术方案中，从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池；判断待分配资源池的可用资源量是否满足待下发任务所需的资源量；若满足，则按照由待分配资源池中的资源执行待下发任务的策略，将待下发任务下发至待分配资源池所属的服务器集群。通过本申请实施例提供的技术方案，资源管理平台连接各服务器集群，管理员可以通过资源管理平台将任务统一下发至服务器集群进行处理。基于资源管理平台记录有每一资源池的可用资源量，资源管理平台可以对每一待下发任务所需的资源量和针对该待下发任务的待分配资源池的可用资源量进行比较，进而避免了管理员对每一待下发任务逐一进行判断，节省了人力资源，且提高了任务下发效率。
相应于上述任务分配方法实施例，本申请实施例还提供一种资源管理平台，如图3所示，该资源管理平台包括：
确定模块310，用于从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池，其中，资源管理平台连接的每一服务器集群的资源被划分为一个或多个资源池；
资源量获取模块320，用于获取待分配资源池的可用资源量；
判断模块330，用于判断待分配资源池的可用资源量是否满足待下发任务所需的资源量；
下发模块340，用于当判断模块的判断结果为是时，则按照由待分配资源池中的资源执行待下发任务的策略，将待下发任务下发至待分配资源池所属的服务器集群。
一种实施方式中，资源管理平台还包括缓存模块，缓存模块用于：
获取待处理任务；
将待处理任务存储于缓存中，缓存用于存储需要服务器集群处理的任务；
按照预设调度策略从缓存中获取任务，并将所获取的任务作为待下发任务。
一种实施方式中，资源管理平台还包括仲裁模块，仲裁模块用于：
检测待分配资源池所属的服务器集群中当前运行的任务数量；
判断任务数量是否小于预设数量阈值；
如果否，则确定待下发任务下发失败；
如果是，执行将待下发任务下发至待分配资源池所属的服务器集群的步骤。
一种实施方式中，资源管理平台还包括监测模块，监测模块用于：
对每一任务进行监测；
当监测到有任务结束时，将该任务从监测名单中删除，其中，任务结束为以下情况中的任一种：任务执行成功、任务执行失败和任务取消。
一种实施方式中，资源管理平台还包括结果获取模块，结果获取模块用于：
接收服务器集群在任务执行成功后发送的任务执行结果；
将所接收到的任务执行结果存储于预设的存储区域，存储区域中记录有任务的标识与任务执行结果的对应关系；
当需要获取待查询任务的任务执行结果时，从对应关系中查找待查询任务的标识，并获取所查找到的标识对应的任务执行结果。
一种实施方式中，所述资源管理平台连接的每一服务器集群的资源被划分为一个或多个资源队列，每一资源队列的资源被划分为一个或多个资源池；资源管理平台记录有每一资源池的资源总量和可用资源量。
一种实施方式中，资源管理平台还包括汇总模块，汇总模块用于：
向每一服务器集群发送资源汇总请求信息；
接收每一服务器集群反馈的针对服务器集群的资源总量和可用资源量，以及每一资源队列中各任务的运行所需资源量；
将属于同一资源队列的任务的运行所需资源量进行求和计算，并将所得到的计算结果确定为该资源队列的已用资源量；
检测资源队列中的每一任务是否被指定有资源池；
如果是，将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量，将该资源池的资源总量减去所述已用资源量，将所得到的结果更新为该资源池的可用资源量；
如果否，将未被指定资源池的任务的运行所需资源量，按照该任务所属资源队列的资源被划分时的比例分配至该资源队列对应的资源池中；将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量，将该资源池的资源总量减去所述已用资源量，将所得到的结果更新为该资源池的可用资源量。
一种实施方式中，资源管理平台还包括新增模块，新增模块用于：
当有新资源池增加时，确定新资源池所属的服务器集群，作为目标服务器集群，并判断目标服务器集群是否与资源管理平台建立连接；
如果是，从目标服务器集群的资源队列中确定新资源池所属的资源队列，对所确定出的资源队列的资源按照预设比例重新划分；
如果否，获取目标服务器集群的配置文件，并安装配置文件；从目标服务器集群的资源队列中确定新资源池所属的资源队列；对所确定出的资源队列的资源按照预设比例重新划分。
一种实施方式中，资源管理平台还包括统计模块，统计模块用于：
每隔预设时长，获取针对服务器集群、资源队列和资源池中的至少一种的已用资源量和可用资源量；
按照预设维度，对所获取的已用资源量和可用资源量进行统计。
本申请实施例提供的技术方案中，从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池；判断待分配资源池的可用资源量是否满足待下发任务所需的资源量；若满足，则按照由待分配资源池中的资源执行待下发任务的策略，将待下发任务下发至待分配资源池所属的服务器集群。通过本申请实施例提供的技术方案，资源管理平台连接各服务器集群，管理员可以通过资源管理平台将任务统一下发至服务器集群进行处理。基于资源管理平台记录有每一资源池的可用资源量，资源管理平台可以对每一待下发任务所需的资源量和针对该待下发任务的待分配资源池的可用资源量进行比较，进而避免了管理员对每一待下发任务逐一进行判断，节省了人力资源，且提高了任务下发效率。
相应于上述任务分配方法实施例，本申请实施例还提供了一种机器可读存储介质，机器可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一所述的任务分配方法步骤。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于资源管理平台和机器可读存储介质实施例而言，由于其基本相似于任务分配方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本申请的保护范围内。

Claims (17)

1.一种任务分配方法，其特征在于，所述方法包括：
从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池，其中，所述资源管理平台连接的每一服务器集群的资源被划分为一个或多个资源队列，每一资源队列的资源被划分为一个或多个资源池；所述资源管理平台记录有每一资源池的资源总量和可用资源量；
获取所述待分配资源池的可用资源量；
判断所述待分配资源池的可用资源量是否满足所述待下发任务所需的资源量；
若满足，则按照由所述待分配资源池中的资源执行所述待下发任务的策略，将所述待下发任务下发至所述待分配资源池所属的服务器集群；
所述方法还包括：
检测资源队列中的每一任务是否被指定有资源池；
如果否，将未被指定资源池的任务的运行所需资源量，按照该任务所属资源队列的资源被划分时的比例分配至该资源队列对应的资源池中。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
获取待处理任务；
将所述待处理任务存储于缓存中，所述缓存用于存储需要服务器集群处理的任务；
按照预设调度策略从所述缓存中获取任务，并将所获取的任务作为待下发任务。
3.根据权利要求1所述的方法，其特征在于，将所述待下发任务下发至所述待分配资源池所属的服务器集群的步骤之前，还包括：
检测所述待分配资源池所属的服务器集群中当前运行的任务数量；
判断所述任务数量是否小于预设数量阈值；
如果否，则确定所述待下发任务下发失败；
如果是，执行将所述待下发任务下发至所述待分配资源池所属的服务器集群的步骤。
4.根据权利要求1所述的方法，其特征在于，所述方法还包括：
对每一任务进行监测；
当监测到有任务结束时，将该任务从监测名单中删除，其中，任务结束为以下情况中的任一种：任务执行成功、任务执行失败和任务取消。
5.根据权利要求1所述的方法，其特征在于，所述方法还包括：
接收服务器集群在任务执行成功后发送的任务执行结果；
将所接收到的任务执行结果存储于预设的存储区域，所述存储区域中记录有任务的标识与任务执行结果的对应关系；
当需要获取待查询任务的任务执行结果时，从所述对应关系中查找所述待查询任务的标识，并获取所查找到的标识对应的任务执行结果。
6.根据权利要求1所述的方法，其特征在于，所述方法还包括：
向所述每一服务器集群发送资源汇总请求信息；
接收所述每一服务器集群反馈的针对服务器集群的资源总量和可用资源量，以及每一资源队列中各任务的运行所需资源量；
将属于同一资源队列的任务的运行所需资源量进行求和计算，并将所得到的计算结果确定为该资源队列的已用资源量；
检测资源队列中的每一任务是否被指定有资源池；
如果是，将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量，将该资源池的资源总量减去所述已用资源量，将所得到的结果更新为该资源池的可用资源量；
如果否，执行所述将未被指定资源池的任务的运行所需资源量，按照该任务所属资源队列的资源被划分时的比例分配至该资源队列对应的资源池中的步骤；将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量，将该资源池的资源总量减去所述已用资源量，将所得到的结果更新为该资源池的可用资源量。
7.根据权利要求1所述的方法，其特征在于，所述方法还包括：
当有新资源池增加时，确定所述新资源池所属的服务器集群，作为目标服务器集群，并判断所述目标服务器集群是否与所述资源管理平台建立连接；
如果是，从所述目标服务器集群的资源队列中确定所述新资源池所属的资源队列，对所确定出的资源队列的资源按照预设比例重新划分；
如果否，获取所述目标服务器集群的配置文件，并安装所述配置文件；从所述目标服务器集群的资源队列中确定所述新资源池所属的资源队列；对所确定出的资源队列的资源按照预设比例重新划分。
8.根据权利要求1所述的方法，其特征在于，所述方法还包括：
每隔预设时长，获取针对服务器集群、资源队列和资源池中的至少一种的已用资源量和可用资源量；
按照预设维度，对所获取的已用资源量和可用资源量进行统计。
9.一种资源管理平台，其特征在于，所述资源管理平台包括：
确定模块，用于从资源管理平台所记录的多个资源池中，确定针对待下发任务的待分配资源池，其中，所述资源管理平台连接的每一服务器集群的资源被划分为一个或多个资源队列，每一资源队列的资源被划分为一个或多个资源池；所述资源管理平台记录有每一资源池的资源总量和可用资源量；
资源量获取模块，用于获取所述待分配资源池的可用资源量；
判断模块，用于判断所述待分配资源池的可用资源量是否满足所述待下发任务所需的资源量；
下发模块，用于当所述判断模块的判断结果为是时，则按照由所述待分配资源池中的资源执行所述待下发任务的策略，将所述待下发任务下发至所述待分配资源池所属的服务器集群；
所述资源管理平台还包括汇总模块，所述汇总模块用于：
检测资源队列中的每一任务是否被指定有资源池；
如果否，将未被指定资源池的任务的运行所需资源量，按照该任务所属资源队列的资源被划分时的比例分配至该资源队列对应的资源池中。
10.根据权利要求9所述的资源管理平台，其特征在于，所述资源管理平台还包括缓存模块，所述缓存模块用于：
获取待处理任务；
将所述待处理任务存储于缓存中，所述缓存用于存储需要服务器集群处理的任务；
按照预设调度策略从所述缓存中获取任务，并将所获取的任务作为待下发任务。
11.根据权利要求9所述的资源管理平台，其特征在于，所述资源管理平台还包括仲裁模块，所述仲裁模块用于：
检测所述待分配资源池所属的服务器集群中当前运行的任务数量；
判断所述任务数量是否小于预设数量阈值；
如果否，则确定所述待下发任务下发失败；
如果是，执行将所述待下发任务下发至所述待分配资源池所属的服务器集群的步骤。
12.根据权利要求9所述的资源管理平台，其特征在于，所述资源管理平台还包括监测模块，所述监测模块用于：
对每一任务进行监测；
当监测到有任务结束时，将该任务从监测名单中删除，其中，任务结束为以下情况中的任一种：任务执行成功、任务执行失败和任务取消。
13.根据权利要求9所述的资源管理平台，其特征在于，所述资源管理平台还包括结果获取模块，所述结果获取模块用于：
接收服务器集群在任务执行成功后发送的任务执行结果；
将所接收到的任务执行结果存储于预设的存储区域，所述存储区域中记录有任务的标识与任务执行结果的对应关系；
当需要获取待查询任务的任务执行结果时，从所述对应关系中查找所述待查询任务的标识，并获取所查找到的标识对应的任务执行结果。
14.根据权利要求9所述的资源管理平台，其特征在于，所述汇总模块还用于：
向所述每一服务器集群发送资源汇总请求信息；
接收所述每一服务器集群反馈的针对服务器集群的资源总量和可用资源量，以及每一资源队列中各任务的运行所需资源量；
将属于同一资源队列的任务的运行所需资源量进行求和计算，并将所得到的计算结果确定为该资源队列的已用资源量；
检测资源队列中的每一任务是否被指定有资源池；
如果是，将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量，将该资源池的资源总量减去所述已用资源量，将所得到的结果更新为该资源池的可用资源量；
如果否，执行所述将未被指定资源池的任务的运行所需资源量，按照该任务所属资源队列的资源被划分时的比例分配至该资源队列对应的资源池中的步骤；将被指定为同一资源池的任务的运行所需资源量进行求和计算，并将得到的计算结果作为该资源池的已用资源量，将该资源池的资源总量减去所述已用资源量，将所得到的结果更新为该资源池的可用资源量。
15.根据权利要求9所述的资源管理平台，其特征在于，所述资源管理平台还包括新增模块，所述新增模块用于：
当有新资源池增加时，确定所述新资源池所属的服务器集群，作为目标服务器集群，并判断所述目标服务器集群是否与所述资源管理平台建立连接；
如果是，从所述目标服务器集群的资源队列中确定所述新资源池所属的资源队列，对所确定出的资源队列的资源按照预设比例重新划分；
如果否，获取所述目标服务器集群的配置文件，并安装所述配置文件；从所述目标服务器集群的资源队列中确定所述新资源池所属的资源队列；对所确定出的资源队列的资源按照预设比例重新划分。
16.根据权利要求9所述的资源管理平台，其特征在于，所述资源管理平台还包括统计模块，所述统计模块用于：
每隔预设时长，获取针对服务器集群、资源队列和资源池中的至少一种的已用资源量和可用资源量；
按照预设维度，对所获取的已用资源量和可用资源量进行统计。
17.一种机器可读存储介质，其特征在于，所述机器可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-8任一所述的方法步骤。
CN201910118082.2A 2019-02-15 2019-02-15 一种任务分配方法及资源管理平台 Active CN111580951B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910118082.2A CN111580951B (zh) 2019-02-15 2019-02-15 一种任务分配方法及资源管理平台

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910118082.2A CN111580951B (zh) 2019-02-15 2019-02-15 一种任务分配方法及资源管理平台

Publications (2)

Publication Number Publication Date
CN111580951A CN111580951A (zh) 2020-08-25
CN111580951B true CN111580951B (zh) 2023-10-10

Family

ID=72111365

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910118082.2A Active CN111580951B (zh) 2019-02-15 2019-02-15 一种任务分配方法及资源管理平台

Country Status (1)

Country Link
CN (1) CN111580951B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110647440A (zh) * 2019-08-23 2020-01-03 北京浪潮数据技术有限公司 一种基于状态机的大数据任务处理方法及系统
CN111813564B (zh) * 2020-09-11 2020-12-18 北京达佳互联信息技术有限公司 集群资源管理方法、装置及容器集群管理系统
CN112948113A (zh) * 2021-03-01 2021-06-11 上海微盟企业发展有限公司 一种集群资源管理调度方法、装置、设备及可读存储介质

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1836212A (zh) * 2003-08-14 2006-09-20 甲骨文国际公司 在多节点系统中资源动态分配的分层管理
CN102866920A (zh) * 2012-08-02 2013-01-09 杭州海康威视系统技术有限公司 主从结构分布式视频处理系统及其调度方法
CN105718316A (zh) * 2014-12-01 2016-06-29 中国移动通信集团公司 一种作业调度的方法及装置
WO2017107456A1 (zh) * 2015-12-25 2017-06-29 乐视控股（北京）有限公司 确定任务消耗资源的方法及装置
CN107291545A (zh) * 2017-08-07 2017-10-24 星环信息科技（上海）有限公司 计算集群中多用户的任务调度方法及设备
CN107589980A (zh) * 2017-08-01 2018-01-16 佛山市深研信息技术有限公司 一种云计算资源的调度方法
CN108121599A (zh) * 2016-11-30 2018-06-05 杭州海康威视数字技术股份有限公司 一种资源管理方法、装置及系统
CN108469988A (zh) * 2018-02-28 2018-08-31 西北大学 一种基于异构Hadoop集群的任务调度方法
CN109034396A (zh) * 2018-07-11 2018-12-18 北京百度网讯科技有限公司 用于处理分布式集群中的深度学习作业的方法和装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7516221B2 (en) * 2003-08-14 2009-04-07 Oracle International Corporation Hierarchical management of the dynamic allocation of resources in a multi-node system
US8291424B2 (en) * 2007-11-27 2012-10-16 International Business Machines Corporation Method and system of managing resources for on-demand computing
US8782240B2 (en) * 2010-10-18 2014-07-15 Avaya Inc. Resource allocation using shared resource pools
KR20180086791A (ko) * 2017-01-23 2018-08-01 한국전자통신연구원 빅 데이터 처리 지원을 위한 클라우드 시스템 및 그 운영 방법

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1836212A (zh) * 2003-08-14 2006-09-20 甲骨文国际公司 在多节点系统中资源动态分配的分层管理
CN102866920A (zh) * 2012-08-02 2013-01-09 杭州海康威视系统技术有限公司 主从结构分布式视频处理系统及其调度方法
CN105718316A (zh) * 2014-12-01 2016-06-29 中国移动通信集团公司 一种作业调度的方法及装置
WO2017107456A1 (zh) * 2015-12-25 2017-06-29 乐视控股（北京）有限公司 确定任务消耗资源的方法及装置
CN108121599A (zh) * 2016-11-30 2018-06-05 杭州海康威视数字技术股份有限公司 一种资源管理方法、装置及系统
CN107589980A (zh) * 2017-08-01 2018-01-16 佛山市深研信息技术有限公司 一种云计算资源的调度方法
CN107291545A (zh) * 2017-08-07 2017-10-24 星环信息科技（上海）有限公司 计算集群中多用户的任务调度方法及设备
CN108469988A (zh) * 2018-02-28 2018-08-31 西北大学 一种基于异构Hadoop集群的任务调度方法
CN109034396A (zh) * 2018-07-11 2018-12-18 北京百度网讯科技有限公司 用于处理分布式集群中的深度学习作业的方法和装置

Also Published As

Publication number Publication date
CN111580951A (zh) 2020-08-25

Similar Documents

Publication Publication Date Title
US11593152B1 (en) Application hosting in a distributed application execution system
CN105357296B (zh) 一种Docker云平台下弹性缓存系统
US10241836B2 (en) Resource management in a virtualized computing environment
CN111580951B (zh) 一种任务分配方法及资源管理平台
US10831387B1 (en) Snapshot reservations in a distributed storage system
US10191771B2 (en) System and method for resource management
Chatzistergiou et al. Fast heuristics for near-optimal task allocation in data stream processing over clusters
US8458712B2 (en) System and method for multi-level preemption scheduling in high performance processing
US11411798B2 (en) Distributed scheduler
US20210247903A1 (en) Dynamically adjusting storage capacity
US8914582B1 (en) Systems and methods for pinning content in cache
US20170019345A1 (en) Multi-tenant resource coordination method
US20180041600A1 (en) Distributed processing system, task processing method, and storage medium
US10884667B2 (en) Storage controller and IO request processing method
US10148531B1 (en) Partitioned performance: adaptive predicted impact
US10810054B1 (en) Capacity balancing for data storage system
US10142195B1 (en) Partitioned performance tracking core resource consumption independently
US10705876B2 (en) Operation management system and operation management method
US9385964B2 (en) Resource management method and management server
JP2011197852A (ja) 仮想計算機システムの管理プログラム，管理装置及び管理方法
CN110914805A (zh) 用于分层任务调度的计算系统
US20080192643A1 (en) Method for managing shared resources
US10033620B1 (en) Partitioned performance adaptive policies and leases
JP6279816B2 (ja) ストレージ監視システムおよびその監視方法
US20230063541A1 (en) Determining computer resource usage at multiple levels of a container orchestration system hierarchy

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant