CN108762891A - 一种云平台资源调度方法和装置 - Google Patents

Abstract

本发明实施例公开了一种云平台资源调度方法和装置，所述方法包括：在云平台openstack的计算组件nova接收到虚拟机创建的请求时，在虚拟化层，设置一个针对每个高可用集群内部所有节点node资源的全局资源视图；采用所述全局资源视图的资源调度机制，将调度请求发送到实际可用的高可用集群上。本发明实施例提出一种基于全局资源视图的资源调度机制，可以有效避免资源碎片化所带来选择错误的宿主机问题，达到资源的合理利用的目的。

Description

一种云平台资源调度方法和装置

技术领域

本发明涉及云计算技术，尤指一种云平台资源调度方法和装置。

背景技术

在云平台OpenStack对接商业虚拟化软件，如vmwarevsphere、InCloud Sphere情况下，OpenStack的计算组件Nova调度可用的宿主机资源面临资源碎片化问题。

具体地，在openstack的计算组件nova接收到虚拟机创建的请求时，需要根据一系列调度规则来选择可用的物理计算节点作为宿主机，通常情况下是根据计算节点上资源的使用情况来进行选择。但是在对接了高可用集群的情况下，由于节点(node)对一个nova的模块nova-compute是透明的，因此就变成了OpenStack的nova组件选择一个可用的集群(cluster)来进行创建虚拟机，选择了cluster之后，由虚拟化管理器来选择具体的node节点来执行创建操作。这就涉及到了如何选择一个可用的cluster集群。

当前大多数厂商的方案是仅仅对某个特定高可用集群内所有节点剩余的资源，包括中央处理器(Central Processing Unit，cpu)、内存、存储进行一个简单的累计。以一个10个node的高可用集群为例，加入10台机器上每台机器都剩余2个cpu核(core)，2G内存，那么就认为该高可用集群的对应的可用资源为20个cpu core，20G内存。对于OpenStack来说，其Nova在执行调度时，便会认为存在一个20个cpu core，20G内存的物理计算节点可用。

在现有技术节点下，根据nova的调度规则，默认选择可用资源最大的计算节点作为宿主机来创建虚拟机，这样，就无法避免资源碎片化带来的错误选择问题。例如，高可用集群1的资源使用情况为：10台机器，每台剩余2core，2G内存。高可用集群2的资源使用情况为：5台机器，其中1台剩余4个core，8G内存，另外四台资源占用率接近100％，无法再作为宿主机使用。根据上述算法，高可用集群1的剩余资源是20core，20G内存，高可用集群2的剩余资源为4core，8G内存。

当一个2core，6G内存的虚拟机创建请求抵达时，依据OpenStack Nova的调度算法，会选择高可用集群1作为备选节点，但是当实际执行创建虚拟机的操作时候，发现高可用集群里面并没有能够满足该条件的计算节点，导致创建失败。

由此可见，现有技术的资源调度机制，容易导致将调度请求发送到实际不可用的高可用集群上，引起由资源碎片化所带来选择错误的宿主机问题，资源不能合理利用。

发明内容

为了解决上述技术问题，本发明实施例提供了一种云平台资源调度方法和装置，通过基于全局资源视图的资源调度机制，可以有效避免资源碎片化所带来选择错误的宿主机问题，达到资源的合理利用的目的。

为了达到本发明目的，一方面，本发明实施例提供了一种云平台资源调度方法，包括：

在云平台openstack的计算组件nova接收到虚拟机创建的请求时，在虚拟化层，设置一个针对每个高可用集群内部所有节点node资源的全局资源视图；

采用所述全局资源视图的资源调度机制，将调度请求发送到实际可用的高可用集群上。

进一步地，所述全局资源视图为支撑虚拟机创建和运行的高可用集群的四元组视图，依据所述四元组基于筛选和调度算法选择计算节点。

进一步地，所述四元组为，C(node1)＝{Cpu(node1)，Mem(node1)，Datastore(C)，C(id)}；

其中，C代表高可用集群Cluster，一个高可用集群使用一个共享存储DataStore，C(id)表示高可用集群的ID。

进一步地，所述方法还包括：

所述Nova读取所有满足条件的高可用集群上的四元组，以预置的调度规则选择满足条件的四元组进行调度，返回四元组所在的C(id)信息。

进一步地，所述方法还包括：

根据返回的所述四元组内的高可用集群的ID信息，将所述高可用集群发送给虚拟化管理软件，由所述虚拟化管理软件进行虚拟机创建。

另一方面，本发明实施例还提供了一种云平台资源调度装置，包括：

设置模块，用于在云平台openstack的计算组件nova接收到虚拟机创建的请求时，在虚拟化层，设置一个针对每个高可用集群内部所有节点node资源的全局资源视图；

调度模块，用于采用所述全局资源视图的资源调度机制，将调度请求发送到实际可用的高可用集群上。

进一步地，所述设置模块还用于：

使所述全局资源视图为支撑虚拟机创建和运行的高可用集群的四元组视图，依据所述四元组基于筛选和调度算法选择计算节点。

进一步地，所述四元组为，C(node1)＝{Cpu(node1)，Mem(node1)，Datastore(C)，C(id)}；

其中，C代表高可用集群Cluster，一个高可用集群使用一个共享存储DataStore，C(id)表示高可用集群的ID。

进一步地，所述调度模块还用于：

所述Nova读取所有满足条件的高可用集群上的四元组，以预置的调度规则选择满足条件的四元组进行调度，返回四元组所在的C(id)信息。

进一步地，所述调度模块还用于：

根据返回的所述四元组内的高可用集群的ID信息，将所述高可用集群发送给虚拟化管理软件，由所述虚拟化管理软件进行虚拟机创建。

本发明实施例通过在云平台openstack的计算组件nova接收到虚拟机创建的请求时，在虚拟化层，设置一个针对每个高可用集群内部所有节点node资源的全局资源视图；采用所述全局资源视图的资源调度机制，将调度请求发送到实际可用的高可用集群上。本发明实施例提出一种基于全局资源视图的资源调度机制，可以有效避免资源碎片化所带来选择错误的宿主机问题，达到资源的合理利用的目的。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

图1为本发明实施例云平台资源调度方法的流程图；

图2为本发明实施例云平台资源调度方法中云平台openstack示意图；

图3为本发明实施例云平台资源调度方法中OpenStack的Nova组件管理示意图；

图4为本发明实施例云平台资源调度方法的原理图；

图5为本发明实施例云平台资源调度装置的结构图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1为本发明实施例云平台资源调度方法的流程图，如图1所示，本发明实施例的方法包括以下步骤：

步骤100：在云平台openstack的计算组件nova接收到虚拟机创建的请求时，在虚拟化层，设置一个针对每个高可用集群内部所有节点node资源的全局资源视图；

步骤101：采用所述全局资源视图的资源调度机制，将调度请求发送到实际可用的高可用集群上。

其中，OpenStack为一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算平台。OpenStack通过各种互补的服务提供了基础设施即服务(IaaS)的解决方案，每个服务提供应用程序编程接口(Application Programming Interface,API)以进行集成。

OpenStack是一系列开源工具或称开源项目的组合，主要使用池化虚拟资源来构建和管理私有云及公共云。其中的6个项目主要负责处理核心云计算服务，包括计算、网络、存储、身份认证、镜像和对象存储服务。同时还有另外十多个可选项目，用户可通过将其捆绑一起来创建独特、可部署的云架构。

在虚拟化环境中，诸如存储、CPU和RAM等资源都是从诸多供应商特定的项目中提取出来，然后由Hypervsior(虚拟机监控程序或者虚拟化管理平台)进行拆分并按需进行分配。OpenStack使用一组一致的应用编程接口(API)，进一步将这些虚拟资源提取为离散池，用于支持标准云计算工具，供管理员和用户直接交互使用。

其中，Hypervisor是一种运行在物理服务器和操作系统之间的中间软件层,可允许多个操作系统和应用共享一套基础物理硬件，因此也可以看作是虚拟环境中的“元”操作系统，它可以协调访问服务器上的所有物理设备和虚拟机，也叫虚拟机监视器(VirtualMachine Monitor)。Hypervisor是所有虚拟化技术的核心。非中断地支持多工作负载迁移的能力是Hypervisor的基本功能。当服务器启动并执行Hypervisor时，它会给每一台虚拟机分配适量的内存、CPU、网络和磁盘，并加载所有虚拟机的客户操作系统。

图2为本发明实施例云平台资源调度方法中云平台openstack示意图，如图2所示，OpenStack和虚拟化管理平台都位于虚拟化资源层之上，可帮助用户发现、报告和自动执行位于不同供应商产品环境中的业务流程。但是虚拟化管理平台的主要目的是方便利用虚拟资源的特性和功能，而实际上，OpenStack是使用虚拟资源来运行工具组合的。

在原生OpenStack社区发布的开源OpenStack版本中，OpenStack通过计算组件Nova对接KVM，可以直接管理每一个物理计算节点。但是，在大规模数据中心中，用户往往需要部署一套成熟的商业虚拟化管理软件以获取底层数据面的可靠性和服务的可用性。

其中，基于内核虚拟机KVM(Kernel-based Virtual Machine)是Linux下x86硬件平台上的全功能虚拟化解决方案，包含一个可加载的内核模块kvm.ko提供和虚拟化核心架构和处理器规范模块。使用KVM，可允许运行多个虚拟机，包括Linux和Windows操作系统。每个虚拟机有私有的硬件，包括网卡、磁盘以及图形适配卡等。

图3为本发明实施例云平台资源调度方法中OpenStack的Nova组件管理示意图，如图3所示，对于商业虚拟化管理工具来说，为了追求虚拟化层面的稳定可靠，往往采用高可用集群作为资源池管理的最小单元，一个高可用集群内包括若干台物理计算节点。在这种情境下，OpenStack的计算组织控制器Nova组件直接管理的便不再是单独的物理计算节点，而是一个一个独立的高可用集群(cluster)。

在OpenStack对接商业虚拟化软件，如vmwarevsphere，InCloud Sphere情况下，针对OpenStack Nova组件调度可用的宿主机资源面临的资源碎片化问题，本发明实施例提出一种基于全局资源视图的资源调度机制，可以有效避免资源碎片化所带来选择错误的宿主机问题，达到资源的合理利用的目的。

进一步地，所述全局资源视图为支撑虚拟机创建和运行的高可用集群的四元组视图，依据所述四元组基于筛选和调度算法选择计算节点。

进一步地，所述四元组为，C(node1)＝{Cpu(node1)，Mem(node1)，Datastore(C)，C(id)}；

其中，C代表高可用集群Cluster，一个高可用集群使用一个共享存储DataStore，C(id)表示高可用集群的ID。

进一步地，所述方法还包括：

所述Nova读取所有满足条件的高可用集群上的四元组，以预置的调度规则选择满足条件的四元组进行调度，返回四元组所在的C(id)信息。

进一步地，所述方法还包括：

根据返回的所述四元组内的高可用集群的ID信息，将所述高可用集群发送给虚拟化管理软件，由所述虚拟化管理软件进行虚拟机创建。

本发明具体实施例详细描述如下：

图4为本发明实施例云平台资源调度方法的原理图，如图4所示，当一个创建虚拟机的请求到达Nova时，在虚拟化层，会形成一个针对每个高可用集群内部所有node节点资源的全局视图，该全局视图由以下四元组构成，C(node1)＝{Cpu(node1)，Mem(node1)，Datastore(C)，C(id)}(C代表高可用集群Cluster，一个高可用集群使用一个共享存储DataStore，C(id)表示高可用集群的ID)。Nova的调度器会读取所有满足条件的高可用集群上的四元组，并以内置的调度规则去选择最满足的条件的四元组进行调度。最后，返回四元组所在的C(id)信息。如果没有合适的四元组，则返回调度失败，没有有效的主机。

本发明实施例提出了支撑虚拟机创建和运行的高可用集群的四元组视图，并依据四元组基于筛选和调度算法选择合适的计算节点；

根据返回的四元组内的高可用集群ID信息，将高可用集群发送给虚拟化管理软件，最终由虚拟化管理软件进行虚拟机创建。

本发明实施例技术方案可以有效提高Nova调度的成功率，避免因资源碎片化的原因，将调度请求发送到实际不可用的高可用集群上。

图5为本发明实施例云平台资源调度装置的结构图，如图5所示，本发明实施例另一方面提供的一种云平台资源调度装置，包括：

设置模块501，用于在云平台openstack的计算组件nova接收到虚拟机创建的请求时，在虚拟化层，设置一个针对每个高可用集群内部所有节点node资源的全局资源视图；

调度模块502，用于采用所述全局资源视图的资源调度机制，将调度请求发送到实际可用的高可用集群上。

进一步地，所述设置模块501还用于：

使所述全局资源视图为支撑虚拟机创建和运行的高可用集群的四元组视图，依据所述四元组基于筛选和调度算法选择计算节点。

进一步地，所述四元组为，C(node1)＝{Cpu(node1)，Mem(node1)，Datastore(C)，C(id)}；

其中，C代表高可用集群Cluster，一个高可用集群使用一个共享存储DataStore，C(id)表示高可用集群的ID。

进一步地，所述调度模块502还用于：

所述Nova读取所有满足条件的高可用集群上的四元组，以预置的调度规则选择满足条件的四元组进行调度，返回四元组所在的C(id)信息。

进一步地，所述调度模块502还用于：

根据返回的所述四元组内的高可用集群的ID信息，将所述高可用集群发送给虚拟化管理软件，由所述虚拟化管理软件进行虚拟机创建。

本发明实施例通过在云平台openstack的计算组件nova接收到虚拟机创建的请求时，在虚拟化层，设置一个针对每个高可用集群内部所有节点node资源的全局资源视图；采用所述全局资源视图的资源调度机制，将调度请求发送到实际可用的高可用集群上。在OpenStack对接商业虚拟化软件vmwarevsphere，InCloud Sphere情况下，针对OpenStackNova组件调度可用的宿主机资源面临的资源碎片化问题，本发明实施例提出一种基于全局资源视图的资源调度机制，可以有效避免资源碎片化所带来选择错误的宿主机问题，达到资源的合理利用的目的。

虽然本发明所揭露的实施方式如上，但所述的内容仅为便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式及细节上进行任何的修改与变化，但本发明的专利保护范围，仍须以所附的权利要求书所界定的范围为准。

Claims (10)

1.一种云平台资源调度方法，其特征在于，包括：

在云平台openstack的计算组件nova接收到虚拟机创建的请求时，在虚拟化层，设置一个针对每个高可用集群内部所有节点node资源的全局资源视图；

采用所述全局资源视图的资源调度机制，将调度请求发送到实际可用的高可用集群上。

2.根据权利要求1所述的云平台资源调度方法，其特征在于，所述全局资源视图为支撑虚拟机创建和运行的高可用集群的四元组视图，依据所述四元组基于筛选和调度算法选择计算节点。

3.根据权利要求2所述的云平台资源调度方法，其特征在于，所述四元组为，C(node1)＝{Cpu(node1)，Mem(node1)，Datastore(C)，C(id)}；

其中，C代表高可用集群Cluster，一个高可用集群使用一个共享存储DataStore，C(id)表示高可用集群的ID。

4.根据权利要求3所述的云平台资源调度方法，其特征在于，还包括：

所述Nova读取所有满足条件的高可用集群上的四元组，以预置的调度规则选择满足条件的四元组进行调度，返回四元组所在的C(id)信息。

5.根据权利要求4所述的云平台资源调度方法，其特征在于，还包括：

根据返回的所述四元组内的高可用集群的ID信息，将所述高可用集群发送给虚拟化管理软件，由所述虚拟化管理软件进行虚拟机创建。

6.一种云平台资源调度装置，其特征在于，包括：

设置模块，用于在云平台openstack的计算组件nova接收到虚拟机创建的请求时，在虚拟化层，设置一个针对每个高可用集群内部所有节点node资源的全局资源视图；

调度模块，用于采用所述全局资源视图的资源调度机制，将调度请求发送到实际可用的高可用集群上。

7.根据权利要求6所述的云平台资源调度装置，其特征在于，所述设置模块还用于：

使所述全局资源视图为支撑虚拟机创建和运行的高可用集群的四元组视图，依据所述四元组基于筛选和调度算法选择计算节点。

8.根据权利要求7所述的云平台资源调度装置，其特征在于，所述四元组为，C(node1)＝{Cpu(node1)，Mem(node1)，Datastore(C)，C(id)}；

其中，C代表高可用集群Cluster，一个高可用集群使用一个共享存储DataStore，C(id)表示高可用集群的ID。

9.根据权利要求8所述的云平台资源调度装置，其特征在于，所述调度模块还用于：

所述Nova读取所有满足条件的高可用集群上的四元组，以预置的调度规则选择满足条件的四元组进行调度，返回四元组所在的C(id)信息。

10.根据权利要求9所述的云平台资源调度装置，其特征在于，所述调度模块还用于：

根据返回的所述四元组内的高可用集群的ID信息，将所述高可用集群发送给虚拟化管理软件，由所述虚拟化管理软件进行虚拟机创建。