一种资源调度方法、装置、设备以及计算机存储介质与流程

1.本技术涉及云计算技术领域，尤其涉及一种资源调度方法、装置、设备以及计算机存储介质。


背景技术：

2.openstack是当前最主流的开源云计算技术，其基于类型模板(flavor)的虚拟机创建调度方案，使得用户能够在资源池里尽可能地享受云计算带来的便捷。这里，每个虚拟机都要消耗资源池的中央处理器(central processing unit，cpu)、内存以及硬盘。通常情况下，云服务商会有一套完整的监控工具，用来监控已有资源池的使用情况，或者根据历史趋势预测未来三个月的走势，又或者根据用户提前申请的使用量，来确保足够的资源应对需求。
3.在相关技术中，目前重点关注的是如何确保资源池足够大以容纳可能的请求，或者为了不让物理服务器的负荷过高，相对分散地分布虚拟机。然而，这些方案一方面由于资源碎片以及虚拟机调度不可控，仍然无法准确计算出已有资源所能提供的虚拟机容量；另一方面，由于资源使用不平衡，还容易造成资源浪费问题，导致资源使用率偏低。


技术实现要素：

4.本技术提供了一种资源调度方法、装置、设备以及计算机存储介质，可以提高服务器的资源使用率。
5.本技术的技术方案是这样实现的：
6.第一方面，本技术实施例提供了一种资源调度方法，该方法包括：
7.获取虚拟机创建请求；
8.根据所述虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划，确定所述服务器集群的资源利用率达到目标值时的规划策略；
9.根据所述规划策略，在所述服务器集群中进行虚拟机资源调度。
10.第二方面，本技术实施例提供了一种资源调度装置，该资源调度装置包括获取单元、确定单元以及调度单元，其中，
11.所述获取单元，配置为获取虚拟机创建请求；
12.所述确定单元，配制为根据所述虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划，确定所述服务器集群的资源利用率达到目标值时的规划策略；
13.所述调度单元，配置为根据所述规划策略，在所述服务器集群中进行虚拟机资源调度。
14.第三方面，本技术实施例提供了一种电子设备，该电子设备包括存储器和处理器，其中，
15.所述存储器，用于存储能够在所述处理器上运行的计算机程序；
16.所述处理器，用于在运行所述计算机程序时，执行如第一方面所述的资源调度方
法。
17.第四方面，本技术实施例提供了一种计算机存储介质，该计算机存储介质存储有计算机程序，该计算机程序被至少一个处理器执行时实现如第一方面所述的资源调度方法。
18.本技术所提供的一种资源调度方法、装置、设备以及计算机存储介质，通过获取虚拟机创建请求；根据虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划，确定服务器集群的资源利用率达到目标值时的规划策略；根据规划策略，在服务器集群中进行虚拟机资源调度。这样，通过预设规划模型对服务器集群进行资源规划，在服务器集群的资源利用率达到最大时确定规划策略，然后根据该规划策略进行虚拟机资源调度，不仅能够使得服务器集群中的服务器资源被充分利用，从而提高服务器的资源使用率，而且通过预设规划模型还可以提高服务器集群中已有资源所能够提供的虚拟机容量的计算准确度，进而达到降低硬件成本的目的。
附图说明
19.图1为本技术实施例提供的一种类比虚拟机分布的俄罗斯方块示意图；
20.图2为本技术实施例提供的一种资源调度方法的流程示意图；
21.图3为本技术实施例提供的另一种资源调度方法的流程示意图；
22.图4为本技术实施例提供的一种资源调度方法的详细流程示意图；
23.图5为本技术实施例提供的另一种资源调度方法的详细流程示意图；
24.图6为本技术实施例提供的一种资源调度装置的组成结构示意图；
25.图7为本技术实施例提供的一种电子设备的具体硬件结构示意图。
具体实施方式
26.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅仅用于解释相关申请，而非对该申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关申请相关的部分。
27.除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本技术实施例的目的，不是旨在限制本技术。
28.在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
29.需要指出，本技术实施例所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本技术实施例能够以除了在这里图示或描述的以外的顺序实施。
30.对本技术实施例进行进一步详细说明之前，对本技术实施例中涉及的名词和术语进行说明，本技术实施例中涉及的名词和术语适用于如下的解释：
31.资源碎片：指一个物理服务器剩余的资源，如cpu、内存，硬盘等，无法提供给一个
完整的虚拟机，只能被迫浪费，而不能提供任何服务。假设一个虚拟机请求4个cpu的资源，有2个物理服务器各自剩余2个cpu，那么这2个物理服务器都无法满足这个虚拟机的要求，导致这2个物理服务器上总共4个cpu都被浪费，而不是通过这两个物理服务器提供一个4cpu的虚拟机容量。因此即使有完整的监控，也很难判断是否满足用户即将到来的需求。
32.flavor：openstack中，虚拟机硬件模板称为类型模板(flavor)。创建一个flavor，该flavor包含的cpu数目，内存大小，硬盘大小都预先设置好，在创建虚拟机的时候，指定这个模板身份标识号(identity document，id)，再加上镜像id，就可以创建出一个使用了flavor里面的属性的，用该镜像创建的一个虚拟机。
33.资源使用不平衡：是创建虚拟机时的一种常见现象，因为虚拟机创建时的调度是不可控的，并且无法预测用户使用虚拟机的情况(用户可能会申请不同的虚拟机型号)，导致不同种类的虚拟机被调度到不同的物理服务器上，造成物理服务器上某种资源率先消耗完(比如cpu先用到100％，内存跟硬盘还用的很少，如使用不到30％)，其余的资源也无法提供服务。
34.巨型云服务提供商，例如亚马逊web服务(amazon web services，aws)，其本身就有深厚的硬件资源可供动态调配，即使在某组资源池出现短缺的情况下，也能迅速做出反应确保服务不会受影响。但是其主要由庞大的硬件资源来支撑，并未重点考虑如何尽可能地提高已有服务器的资源利用率。
35.换句话说，相关技术的重点是如何确保资源池足够大以容纳可能的请求，又或者是为了不让物理服务器的负荷过高，相对分散的分布虚拟机。但缺乏以下考虑：因为资源碎片的原因，基于flavor的调度不可控，无法精准计算已有资源所能提供的虚拟机容量；另外，由于资源使用不平衡，还容易导致资源浪费严重。
36.也就是说，用户需要创建什么样的虚拟机是不可预测的，可以把这个过程想象成俄罗斯方块游戏。例如，图1示出了本技术实施例提供的一种类比虚拟机分布的俄罗斯方块示意图。如图1所示，在该俄罗斯方块的游戏过程中，每一次下落的方块都是未知的。
37.因此，对虚拟机的调度策略需要适应以下场景：
38.(1)根据当前虚拟机的分布使用情况来实时规划下一次的虚拟机创建请求。由于下一次虚拟机创建请求的不可预知性，甚至前后2次请求的不同顺序都会影响到规划结果，所以动态规划必须要有广泛的最优解集合。
39.(2)每隔一段时间，可以对已创建的虚拟机进行重分布。比如图1中的俄罗斯方块，如果底层有方块的摆放不合理，那么可以通过迁移手段把这些不合理的方块(虚拟机)迁移出来，把更合适的方块(虚拟机)迁移进去。
40.基于此，本技术提供了一种资源调度方法，该方法的基本思想是：获取虚拟机创建请求；根据所述虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划，确定所述服务器集群的资源利用率达到目标值时的规划策略；根据所述规划策略，在所述服务器集群中进行虚拟机资源调度。这样，通过预设规划模型对服务器集群进行资源规划，在服务器集群的资源利用率达到最大时确定规划策略，然后根据该规划策略进行虚拟机资源调度，不仅能够使得服务器集群中的服务器资源被充分利用，提高服务器的资源使用率，而且通过预设规划模型还可以提高服务器集群中已有资源所能够提供的虚拟机容量的计算准确度，进而达到降低硬件成本的目的。
41.下面将结合附图对本技术各实施例进行详细说明。
42.本技术的一实施例中，参见图2，其示出了本技术实施例提供的一种资源调度方法的流程示意图。如图2所示，该方法可以包括：
43.s201、获取虚拟机创建请求。
44.需要说明的是，本技术实施例提供的资源调度方法可以应用于进行资源调度的装置，或者集成有该装置的电子设备。这里，电子设备可以是诸如计算机、智能手机、平板电脑、笔记本电脑、掌上电脑、个人数字助理(personal digital assistant，pda)、导航装置等等，本技术实施例对此不作具体限定。
45.还需要说明的是，获取虚拟机创建请求通常是云服务商接收到用户的虚拟机需求之后进行的步骤，其中，虚拟机创建请求用于指示用户需要什么类型的虚拟机以及对应类型虚拟机的数量。
46.示例性地，本技术实施例以openstack创建虚拟机为例对本技术实施例所提供的资源调度方法进行详细说明，在openstack中，通过创建一个包含有设置好的cpu数量、内存大小、硬盘大小的类型模板(flavor)来创建虚拟机。具体地，在创建虚拟机时，只需要指定模板id以及镜像id，就能够创建出一个使用了该flavor属性的且用该镜像创建的虚拟机。但是在创建虚拟机之前，首先需要获取虚拟机创建请求。
47.s202、根据虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划，确定服务器集群的资源利用率达到目标值时的规划策略。
48.需要说明的是，在获取虚拟机创建请求之后，就可以根据该虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划，以确定当服务器集群的资源利用率达到目标值时的规划策略。这里，目标值是指通过预设规划模型对服务器集群进行资源规划，满足虚拟机创建请求时服务器集群的资源利用率能够达到最优或者最大时的值，以使得服务器集群中的资源合理利用。其中，目标值并非是一个固定的值，而是资源利用率达到最优或者最大时的值；通常情况下，目标值可以是服务器集群的资源利用率最大化时的值，但是本技术实施例对此不作具体限定。
49.还需要说明的是，规划策略即确定在服务器集群中的每一台服务器上部署多少数量的某种类型的虚拟机。通过预设规划模型的计算，可以在满足虚拟机创建请求的同时，还能够使得服务器集群的资源得到最大化且最合理的利用。
50.另外，服务器集群可以为一个包括有多台(如20台、30台等)物理服务器的资源池。这里，物理服务器提供了创建虚拟机所需要的cpu、内存、硬盘等资源。还需要注意的是，在本技术实施例中所涉及到的服务器均指物理服务器。
51.s203、根据规划策略，在服务器集群中进行虚拟机资源调度。
52.需要说明的是，在确定出规划策略之后，就可以根据规划策略在服务器集群中进行虚拟机资源调度，即将虚拟机创建在服务器集群中最合适的服务器上，以确保服务器集群中的每台服务器的各项资源都能得到合理利用，从而大幅度减少由于资源碎片导致的价值浪费。
53.这样，在确定出规划策略之后，可以选择出服务器集群中的目标服务器以及在目标服务器上部署的虚拟机信息，比如虚拟机数量、虚拟机类型等，然后以此在对应服务器上创建虚拟机，以实现虚拟机的资源调度。
54.本实施例提供了一种资源调度方法，通过获取虚拟机创建请求；根据所述虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划，确定所述服务器集群的资源利用率达到目标值时的规划策略；根据所述规划策略，在所述服务器集群中进行虚拟机资源调度。这样，通过预设规划模型对服务器集群进行资源规划，在服务器集群的资源利用率达到最大时确定规划策略，然后根据该规划策略进行虚拟机资源调度，不仅能够使得服务器集群中的服务器资源被充分利用，提高服务器的资源使用率，而且通过预设规划模型还可以提高服务器集群中已有资源所能够提供的虚拟机容量的计算准确度，进而达到降低硬件成本的目的。
55.本技术的另一实施例中，在资源调度方法中，还可以针对预设规划模型的建立过程进行描述。如图3所示，该方法还可以包括：
56.s301、获取服务器定义信息和虚拟机定义信息。
57.需要说明的是，服务器定义信息至少可以包括服务器集群中的服务器数量、每一服务器的性能参数集合和每一服务器的价格参数集合，虚拟机定义信息至少可以包括虚拟机种类的数量、每一种类虚拟机的性能参数集合和每一种类虚拟机的价格参数集合。
58.还需要说明的是，本技术实施例提供的预设规划模型是通过对服务器和虚拟机的定义信息进行相关计算后生成规划策略的。在这里，规划策略包括在服务器集群中的每一台服务器上规划可以创建的虚拟机的种类和数量，即通过预设规划模型还可以对服务器集群能够提供的虚拟机容量进行准确计算。
59.在一些实施例中，性能参数集合可以包括：中央处理器cpu数量，内存容量和硬盘容量；价格参数集合可以包括：单位cpu价格、单位内存价格和单位硬盘价格。
60.也就是说，对于任意一台服务器而言，其性能参数集合包括：服务器cpu数量，服务器内存容量以及服务器硬盘容量；其价格参数集合包括：单位cpu价格，单位内存价格以及单位硬盘价格。
61.而对于任意一个虚拟机而言，其性能参数集合包括：虚拟cpu数量，虚拟内存容量以及虚拟硬盘容量；其价格参数集合包括：单位虚拟cpu价格，单位虚拟内存价格以及单位虚拟硬盘价格。
62.简言之，性能参数集合代表的是服务器或者虚拟机的cpu、内存以及硬盘等基础配置信息的数量或者容量；而价格参数集合则代表的是服务器或者虚拟机的这些基础配置信息的单位价格。
63.还需要说明的是，在服务器上部署虚拟机时，还会存在超分的可能。超分是指内核虚拟机(kernel-based virtual machine，kvm)，它是一个开源的系统虚拟化模块，也可以称为kvm虚拟机，能够分配给虚拟机的虚拟cpu、虚拟内存或者虚拟硬盘的数量/容量大于服务器实际的cpu、内存或者硬盘的数量/容量。
64.在这里，还可以分别定义各服务器的cpu超分率、内存超分率以及硬盘超分率。这样，服务器实际能够提供给虚拟机的虚拟cpu数量为服务器cpu数量与超分率的乘积；服务器实际能够提供给虚拟机的虚拟内存容量为服务器内存容量与内存超分率的乘积；服务器实际能够提供给虚拟机的虚拟硬盘容量为服务器硬盘容量与硬盘超分率的乘积。
65.因此，对于创建在某一服务器上的虚拟机而言，单位虚拟cpu价格为服务器单位cpu价格与cpu超分率进行除法运算得到的商；单位虚拟内存价格为服务器单位内存价格与
内存超分率进行除法运算得到的商；单位虚拟硬盘价格为服务器单位硬盘价格与硬盘超分率进行除法运算得到的商。
66.这样，通过以上步骤获取了服务器定义信息和虚拟机定义信息，以便进行后续计算。
67.s302、根据服务器定义信息和虚拟机定义信息，确定约束条件。
68.需要说明的是，根据上述获取的服务器定义信息和虚拟机定义信息，就能够确定预设规划模型的约束条件。
69.在一些具体的实施例中，约束条件可以为：每一服务器上的所有虚拟机的虚拟cpu数量总和小于或者等于该服务器的cpu数量与cpu超分率的乘积；每一服务器上的所有虚拟机的虚拟内存容量总和小于或者等于该服务器的内存容量与内存超分率的乘积；每一服务器上的所有虚拟机的虚拟硬盘容量总和小于或者等于该服务器的硬盘容量与硬盘超分率的乘积；以及服务器集群中的所有虚拟机的消费总和大于或者等于服务器集群中所有服务器的价值总和与预设比率之积。
70.具体地，定义每个服务器的价值为：(服务器cpu数量
×
单位cpu价格) (服务器内存容量
×
单位内存价格) (服务器硬盘容量
×
单位硬盘价格)。
71.定义每个虚拟机的价值为：(虚拟cpu数量
×
单位虚拟cpu价格) (虚拟内存容量
×
单位虚拟内存价格) (虚拟硬盘容量
×
单位虚拟硬盘价格)。
72.这样，服务器集群中所有虚拟机的消费总和可以通过以下方式计算：
73.首先，定义单个服务器上某一种类虚拟机的消费为：单个服务器上该种类的虚拟机的数量与该种类虚拟机的价值的乘积；然后，定义单个服务器上所有虚拟机的消费为：单个服务器上每一种类的虚拟机的消费进行加法计算得到的和值；最后，定义服务器集群中所有服务器上的所有虚拟机的总消费为：对所有服务器上的所有虚拟机的消费进行加法计算得到的和值。
74.服务器集群中所有服务器的价值总和可以通过以下方式计算：
75.将服务器集群中每个服务器的价值进行加法计算得到的和值确定为服务器集群中所有服务器的价值总和。
76.需要说明的是，在利用预设规划模型对服务器集群进行资源规划时，可能为在完全空闲的服务器上规划新的虚拟机；也可能为服务器上存在已创建的虚拟机，在服务器的剩余资源上规划新的虚拟机；也可能为对服务器上已创建的虚拟机进行重新规划等情况。也就是说，上述进行参数计算的虚拟机可以包括服务器上已创建的虚拟机、请求创建的虚拟机、仅根据服务器资源状态进行规划的虚拟机等实际已创建、请求创建或是还未请求创建的虚拟机中的一种或多种，需要结合实际的资源规划需求来进行具体计算。
77.因此，在对服务器集群进行资源规划时，约束条件还应该包括，需要创建的虚拟机的种类存在至少一个。如果在请求创建新的虚拟机之前，服务器集群中已经存在创建好的虚拟机，则需要创建的虚拟机的种类数量为已创建的该种虚拟机的数量再加一。即请求创建新的虚拟机进行资源规划时，不仅要满足当前虚拟机的创建请求，还要考虑到服务器上已创建的虚拟机已经占用的资源情况。
78.需要说明的是，约束每一服务器上所有虚拟机的各性能参数的总和分别小于或者等于该服务器的性能参数与超分率的乘积即是为了保证服务器的实际可用资源能够满足
在服务器上创建虚拟机的请求，同时最大化利用服务器资源。
79.例如，在已经考虑了超分的情况下，一个服务器最多可提供48个虚拟cpu(假设内存容量和硬盘容量都能够满足需求)，此时需要创建6个flavor f类型的虚拟机，一个flavor f类型的虚拟机需要10个虚拟cpu，这样如果将6个flavor f类型的虚拟机都创建在该服务器上，需要的虚拟cpu的数量为6
×
10＝60个，而该服务器只能提供48个虚拟cpu，数量小于虚拟机需要的cpu数量，这显然不能满足虚拟机创建需求，对于内存、硬盘等也是同理。
80.又例如，一个服务器最多可提供48个虚拟机cpu和384g虚拟机内存(假设硬盘容量总能满足需求)，此时需要创建6个flavor k类型的虚拟机，一个flavor k类型的虚拟机需要8个虚拟cpu，96g虚拟内存，这样如果将6个flavor k类型的虚拟机都创建在该服务器上，需要的虚拟cpu的数量为6
×
8＝48个，需要的虚拟内存容量为8
×
96＝768g，那么虽然cpu恰好能够满足需求，但是内存显然不能够满足需求。
81.还需要说明的是，在本技术实施例中，预设比率代表了利用预设规划模型对服务器集群进行资源规划时，各种可能的规划方式下虚拟机消费物理服务器价值比率的门限值，即虚拟机至少要消费服务器集群多少比率的价值。示例性地，可以将预设比率设置为80％、70％、60％、90％等。可以结合实际经验或者服务器集群当前资源状态等进行具体设置，本技术实施例对预设比率的值不进行具体限定。
82.这样，根据服务器定义信息和虚拟机定义信息，确定了约束条件，以便构建预设规划模型。
83.s303、在约束条件下，构建预设规划模型。
84.需要说明的是，在约束条件下，结合当前的实际需求对服务器集群进行资源规划时，可能会有多种不同的规划方式，本技术实施例的目的就在于模拟虚拟机创建在各个服务器上的各种可能的资源规划方式，从中找出在约束条件下，虚拟机消费最高的资源规划方式。
85.这样，基于上述步骤，可以构建出预设规划模型，然后从各种资源规划方式中选择出消费值最大的资源规划方式进行虚拟机资源调度。
86.在一种具体的示例中，参见图4，其示出了本技术实施例提供的一种资源调度方法的详细流程示意图。如图4所示，该详细流程可以包括：
87.s401、获取虚拟机创建请求。
88.s402、根据虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划。
89.需要说明的是，在服务器上创建虚拟机时，可能会存在有多种不同的资源规划方式。例如，假设服务器集群中存在4台服务器，在获取若干个虚拟机创建请求之后，在服务器资源足够的情况下，有可能只在其中的两台服务器上创建虚拟机，也有可能在每一台服务器上均创建虚拟机，或者在其中的三台服务器上创建虚拟机；而且在各服务器上创建的虚拟机类型也不一定相同。因此，在不同的资源规划方式下，服务器集群的资源利用率都是不同的。
90.本技术实施例是通过预设规划模型来模拟虚拟机创建在服务器上的各种可能的资源规划方式，从中选择最优的规划方式作为本技术实施例的规划策略。可以理解，在不同的规划方式下，服务器集群的资源利用率是不同的。
91.s403、判断是否存在服务器集群的资源利用率达到目标值的规划策略；
92.s404、若判断结果为是，则确定服务器集群的资源利用率达到目标值时的规划策略。
93.需要说明的是，本技术实施例的目的在于：在服务器集群中创建虚拟机时，使得在每一台服务器的资源都能够被最大化利用，使浪费的资源最少。即，在进行服务器集群的资源规划时，尽可能使得单个服务器的资源都被利用到极致。对于单个服务器而言，资源被利用到极致是指：服务器已经达到“木桶效应”时，即服务器的一项资源已经被完全利用。
94.可以理解，如果在服务器上部署最合适种类的虚拟机，使得在一项资源被用完时，其它两项资源也能够接近于被用完的状态，减少浪费。这样，对于单个服务器而言，其资源能够被充分地利用。
95.具体地，在一些实施例中，对于步骤s404来说，确定服务器集群的资源利用率达到目标值时的规划策略，可以包括：
96.在服务器集群的资源利用率达到目标值时，确定从服务器集群中选择的目标服务器以及目标服务器部署的虚拟机信息；
97.将目标服务器以及目标服务器部署的虚拟机信息确定为规划策略。
98.也就是说，根据虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划，此时可能存在有多种资源规划方式，但是每种规划方式的资源利用率必然有高有低。在本技术实施例中，当服务器的资源利用率达到目标值，即服务器的资源利用率最大时，例如，对于虚拟机创建请求，根据预设规划模型，存在三种资源规划方式：第一规划方式、第二规划方式以及第三规划方式，这三种规划方式使得服务器集群的资源利用率分别为80.2％、85.3％以及90.5％，可见，第三规划方式为资源利用率最大的规划方式。此时就可以将第三规划方式确定为本技术实施例的规划策略，从服务器集群中确定出目标服务器以及在目标服务器上部署的虚拟机信息。
99.s405、根据规划策略，在服务器集群中进行虚拟机资源调度。
100.需要说明的是，在确定规划策略之后，就可以根据确定好的规划策略在服务器集群中进行虚拟机资源调度。
101.还需要说明的是，本技术实施例提供的预设规划模型可以对虚拟机在服务器集群中的各种可能的分布情况进行模拟，准确计算出服务器集群已有资源所能提供的虚拟机容量。在一些实施例中，在根据虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划时，不仅是对请求创建的虚拟机的在服务器上的分布情况进行了规划，同时还能够准确计算在当前的资源状态下，服务器的已有资源可以提供的具体的各类型虚拟机的虚拟机容量。
102.示例性地，假设服务器集群中存在4台服务器h1、h2、h3和h4，h1上已经创建了2个flavor 1虚拟机。然后收到了2个flavor1虚拟机和2个flavor2虚拟机创建请求，在经过规划之后，将2个flavor1虚拟机创建在了h2上，并在h1和h2上分别创建了一个flavor 2虚拟机，同时还对空闲资源进行了最优规划。即此时，h1和h2上已经分别均创建了2个flavor1虚拟机和一个flavor2虚拟机，并同时对h3和h4进行了最佳规划，h3和h4分别能够提供2个flavor1虚拟机和一个flavor 2虚拟机的容量。那么，下次收到虚拟机创建请求如果4个以内的flavor1和/或者2个以内的flavor 2就可以直接对服务器集群进行资源调度，创建虚
拟机。
103.除此之外，还可以每隔一段时间对已创建的虚拟机进行重分布，以使服务器的资源利用状态保持最优。因此，在一些实施例中，该方法还可以包括：
104.开启定时器并进行计时；
105.当定时器的计时达到预设时长时，利用预设规划模型对服务器集群中的已创建虚拟机重新进行资源规划，确定服务器集群的资源利用率达到目标值时的规划策略；
106.根据规划策略，在服务器集群中进行虚拟机资源调度。
107.需要说明的是，在创建虚拟机的过程中，对于云服务商而言，在接收到客户的虚拟机创建需求之前，每一次的虚拟机创建请求都是未知的。因此，存在这种情况，规划策略对于本次资源规划而言是最佳的规划方式，能够使得服务器集群的当前资源利用率为最大，但是当有了新的虚拟机创建请求之后，本次的规划策略对于下一次的虚拟机创建请求而言，却不一定是最佳的。
108.另外，在实际应用中，还存在当根据虚拟机创建请求进行资源规划时，暂时无法达到服务器集群资源最大利用，规划人员会结合实际将资源需求不多的虚拟机临时创建在合适的服务器上等情况。
109.基于上述的图1所示，将已经存在于图中的方块视作已创建的虚拟机，可见底部有些方块的位置并不合理，那么就可以通过迁移手段把不合理的方块(虚拟机)迁移出来，并将更合适的方块(虚拟机迁移进去)。
110.示例性地，如图1所述，方框aaa组成虚拟机a，方块bbbb组成虚拟机b，可以看出，虚拟机a旁边存在两块资源浪费，此时可以将虚拟机a迁移到其它位置，并将虚拟机b迁移到虚拟机a原本的位置，这样通过虚拟机b将原本空置在虚拟机a右边的一个方块也利用了，从而提高了资源的利用率。
111.还需要说明的是，预设时长为对服务器集群上已创建的虚拟机重新进行资源规划的时间间隔，实际中，预设时长可以通过经验或者计算等方式自定义；另外，也可以在固定时间点对虚拟机重新进行资源规划，或者在任意时刻由规划人员手动启动等，本技术实施例对此不做具体限定。
112.当利用预设规划模型对服务器集群上已创建的虚拟机进行资源规划时，由于此时并没有新的虚拟机创建请求，则只需要根据各个服务器以及各个已创建的虚拟机的各种参数，通过预设规划模型进行计算，确定出虚拟机消费总和最高的规划策略。
113.也就是说，这里与前述步骤的区别仅在于所有的虚拟机都是已经成功创建在服务器集群上的，只需要根据预设规划模型对其进行计算并重新进行资源规划。在得到规划策略之后，根据规划策略，重新进行虚拟机资源调度，对需要进行迁移操作的虚拟机进行迁移处理。
114.还需要说明的是，在本技术实施例中，对虚拟机进行迁移可以通过openstack api来实现；创建新的虚拟机可以通过nova scheduler实现；在利用预设规划模型对服务器集群进行资源规划时，可以通过动态规划工具(例如matlab、cplex等)来实现。
115.s406、若判断结果为否，则判断计数值是否小于或等于预设阈值。
116.s407、当计数值小于或等于预设阈值时，对服务器集群中的已创建虚拟机进行资源迁移处理，并对计数值执行加一操作，返回执行根据虚拟机创建请求，利用预设规划模型
对服务器集群进行资源规划的步骤。
117.需要说明的是，对于步骤s403来说，如果存在服务器集群的资源利用率达到目标值的规划策略，即判断结果为是，那么可以执行步骤s404；如果不存在服务器集群的资源利用率达到目标值的规划策略，即判断结果为否，那么可以执行步骤s406。
118.还需要说明的是，在确定不存在使服务器集群的资源利用率达到目标值的规划策略时，这时候对于当前的虚拟机创建请求，意味着根据预设规划模型无法得到满足虚拟机创建请求的规划策略，说明此时服务器集群中的已有资源分配不合理，即已创建的虚拟机分布可能不合理，那么需要对服务器集群中已创建的虚拟机进行资源迁移处理，以便再次进行资源规划。但是实际应用中，不可能进行无限次的资源迁移处理，以重新规划资源；因此，本技术实施例需要针对执行资源迁移处理的次数进行计数，这时候可以设置一个计数值。
119.对于该计数值，在一些实施例中，设置计数值的初始值为零。
120.也就是说，在循环计数之前，该计数值的初始值为零。只有在重新进行一次资源迁移处理时，该计数值执行加1操作，然后返回执行步骤s402，直至计数值大于预设阈值。
121.还需要说明的是，在根据虚拟机创建请求对服务器集群进行资源规划时，有可能由于服务器资源确实无法满足创建虚拟机的请求，导致无论如何进行资源迁移都无法得到规划策略。因此，本技术实施例还需要对虚拟机进行资源迁移处理的次数进行一定限制，比如设置一个预设阈值。其中，将对虚拟机进行资源迁移的次数的上限值设置为预设阈值，例如，预设阈值可以为6次、8次、10次或者更多次，即预设阈值可以为规划人员根据实际经验设定的自定义值，或者根据不同规模或不同资源状态的服务器集群所设置的自适应值，本技术实施例对此不作具体限定。
122.这样，通过将计数值与预设阈值进行比较，对于步骤s406来说，当计数值小于或等于预设阈值时，即判断结果为是，那么可以执行步骤s407；当计数值大于预设阈值时，即判断结果为否，那么可以执行步骤s408。
123.具体来讲，如果计数值小于或者等于预设阈值，那么需要对服务器集群中已创建的虚拟机进行资源迁移处理，同时对计数值执行加一操作。也就是说，计数值代表了对服务器集群中已创建的虚拟机进行资源迁移处理的次数；或者，计数值也代表了根据预设规划模型确定不存在服务器集群的资源利用率达到目标值时的规划策略的次数。
124.也就是说，在获取虚拟机创建请求后，对服务器集群进行资源规划时，可能由于已创建的虚拟机分布得不合理，无法确定出规划策略，此时可以通过对服务器集群中已创建的虚拟机进行资源迁移处理，即可以将某些不合理的虚拟机进行迁移，再重新对服务器集群进行资源规划。以图1为例，可能由于底部的方块(虚拟机)分布不合理，导致一台服务器上虽然有空余资源，但是却无法提供给一个完整虚拟机使用。因此，本技术实施例可以对服务器上已创建的虚拟机进行资源迁移处理，例如将分布不合理的虚拟机迁移到其它服务器上。
125.示例性地，假设服务器集群中存在两台服务器，其中服务器1和服务器2均可以提供24个cpu(假设不存在超分，且硬盘和内存均能够满足虚拟机的需求)，服务器1和服务器2上均已经部署了3个flavor g类型的虚拟机，假设一个flavor g类型的虚拟机需要6个cpu，则服务器1和服务器2上的cpu均已经使用了18个，它们分别还有6个cpu可供使用。此时，收
到了一个虚拟机创建请求，需要创建一个flavor h类型的虚拟机，一个flavor h类型的虚拟机需要8个cpu。可以看出，服务器1和服务器2此时均无法单独满足该虚拟机创建请求，但是如果将服务器1上的一个flavor g类型的虚拟机迁移到服务器2上，则此时服务器1有12个可用cpu，服务器2有2个可用cpu，那么此时服务器1就可以满足一个flavor h类型的虚拟机的创建请求。
126.也就是说，在不存在服务器集群的资源利用率达到目标值的规划策略时，不一定是服务器的资源不够使用，而可能是由于资源碎片化导致无法对服务器的已有资源进行合理利用，此时，就可以通过对已创建的虚拟机进行资源迁移处理，使资源化零为整，从而重新进行资源规划，有可能能够得到规划策略。
127.在本技术实施例中，当预设参数值小于或等于预设阈值时，对服务器集群中的已创建虚拟机进行资源迁移处理，然后返回执行根据虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划的步骤，即返回执行步骤s302。
128.s408、当计数值大于预设阈值时，生成告警信息。
129.其中，告警信息用于指示服务器集群的硬件信息与虚拟机资源不匹配，使得服务器集群的资源利用率无法达到目标值。
130.需要说明的是，如果计数值大于预设阈值，说明对已创建的虚拟机进行资源迁移处理的次数已经达到了预设阈值，但是仍旧无法得到使服务器集群的资源利用率达到目标值的规划策略。例如，由于服务器资源不足，而虚拟机创建请求所需资源较多，无论如何对已创建的虚拟机进行资源迁移都无法得到使服务器集群的资源利用率达到目标值的规划策略。即服务器集群的硬件信息与虚拟机资源不匹配，使得服务器集群的资源利用率无法达到目标值，此时生成告警信息。
131.还需要说明的是，该告警信息用于告知规划人员无法实现服务器资源最大化利用，需要进行人工干预，例如对服务器集群进行扩容，采购新的服务器，或者将暂时不用的虚拟机进行迁出等处理。
132.本实施例提供了一种资源调度方法，通过上述实施例对前述实施例的具体实现进行了详细阐述，从中可以看出，通过对服务器和虚拟机的性能参数和价格参数进行计算，确定约束条件并构建出预设规划模型；这样，利用该预设规划模型进行虚拟机资源调度，不仅能够根据预设规划模型对服务器所能提供的虚拟机容量进行准确计算，而且还可以对服务器集群中已创建的虚拟机进行定期/不定期的重新规划，使得在提供虚拟机的类型和数据相同的情况下，通过合理的调度，压缩物理服务器碎片，实现了最大化利用资源，降低了硬件总成本。
133.本技术的又一实施例中，参见图5，其示出了本技术实施例提供的另一种资源调度方法的详细流程示意图。如图5所示，该详细流程可以包括：
134.s501、构建预设规划模型。
135.需要说明的是，在本技术实施例中，预设规划模型也可以称为价值模型。下面将针对预设规划模型(即价值模型)的构建过程进行详细描述：
136.(a)定义资源池中物理服务器台数以及flavor种类数。
137.其中，将资源池中物理服务器的台数定为n台，flavor种类数定为m种。
138.(b)定义每台物理服务器的要素。
139.其中，pc表示物理服务器的单位cpu的价格(price per core)；pd表示物理服务器的单位硬盘的价格(price per gb/mb)；pm表示物理服务器的单位内存的价格(price per gb/mb)；c表示物理服务器的cpu数目；d表示物理服务器的硬盘容量(gb/mb)；r表示物理服务器的内存容量(gb/mb)；
140.这样，每个物理服务器的价值ph的计算方法如下所示：
141.ph＝pc
×
c pd
×
d pm
×rꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀ
(1)
142.(c)定义flavor的信息。
143.其中，fi表示第i种flavor；fic表示fi上的cpu个数；fim表示fi上的内存大小；fid表示fi上的硬盘大小。
144.(d)定义超分的信息。
145.这里，超分是指kvm能够分配给虚拟机cpu、内存、硬盘的总数大于物理服务器实际的cpu、内存、磁盘的总数，物理服务器可能会设置cpu、内存、硬盘的超分率。即：
146.实际可分配虚拟机使用的cpu总数＝物理cpu总数
×
cpu_ratio，其中，cpu_ratio指物理服务器的cpu超分率；
147.实际可分配虚拟机使用的内存总数＝物理内存总数
×
memory_ratio，其中，memory_ratio指物理服务器的内存超分率；
148.实际可分配虚拟机使用的硬盘总数＝物理硬盘总数
×
disk_ratio，其中，disk ratio指物理服务器的硬盘超分率。
149.这样，flavor中实际单位cpu的价格为flavor中实际单位内存的价格为flavor中实际单位硬盘的价格为
150.如此，通过(a)、(b)、(c)、(d)确定出的信息即为前述实施例中的服务器定义信息和虚拟机定义信息。
151.(e)定义flavor的价格。
152.这里，第i个flavor的价格p(fi)的计算方法如下所示：
[0153][0154]
其中，每个flavor的价格p(fi)都是常量。
[0155]
(f)定义单个物理服务器上的flavor种类及数目。
[0156]
其中，hn表示第n个物理服务器；xin表示第n个物理服务器上fi的数目。
[0157]
在这里，第n个物理服务器上m种flavor的总个数为：需要注意的是，每一个物理服务器上并非一定包括有m种flavor，也可能只是包括了m种flavor中的一部分种类。
[0158]
(g)定义单个物理服务器上的flavor的消费。
[0159]
其中，第n个物理服务器上第i种flavor的总消费为xin
×
p(fi)，那么，第n个物理服务器上m种flavor的总消费cost_per_host的计算方法如下所示：
[0160][0161]
(h)定义所有物理服务器(n台)上的所有flavor的消费。
[0162]
其中，n台物理服务器上所有flavor的消费cost_total_host的计算方法如下所示：
[0163][0164]
这样，根据式(4)能够算出在某种资源规划方式下，所有物理服务器上规划的所有flavor的消费总和。
[0165]
(i)确定约束条件。
[0166]
首先，预设规划模型中的p(fi)，c，d，r，m，n，fic，fid，fim，ph，pc，pd以及pm均为常量；
[0167]
其次，xin表示fi在第n台物理服务器上的数目，需要同时满足：
[0168]
第n台物理服务器上m种flavor的cpu总数≤实际可分配虚拟机使用的cpu总数；
[0169]
第n台物理服务器上m种flavor的内存总数≤实际可分配虚拟机使用的内存总数；
[0170]
第n台物理服务器上m种flavor的硬盘总数≤实际可分配虚拟机使用的硬盘总数。即需要满足：
[0171][0172][0173][0174]
并且，所有的服务器上的消费总和需要满足：
[0175][0176]
这里，式(8)表示在预设规划模型下，flavor消费物理服务器价值需要超过服务器自身价值的比率为α，α值可以为80％，70％，60％，90％等任意符合需求的数值，本技术实施例对此不做具体限定。
[0177]
可以理解，当每台物理服务器的规格都相同时，上述的式(8)还可以如下表示：
[0178][0179]
(j)目标函数(找出实际消费最大值，即为浪费最少)。
[0180]
在约束条件下，目标函数如下所示：
[0181][0182]
这里，式(10)即为本技术实施例所构建的预设规划模型。基于该模型，就可以“模
拟虚拟机创建在各个物理服务器上的各种可能调度，从中找出最少浪费(消费物理服务器的价值超过α)的最优解”。
[0183]
s502、接收虚拟机创建请求。
[0184]
s503、根据硬件与flavor，计算利用资源最大的最优解集合。
[0185]
s504、在预设规划模型存在最优解集合的情况下，根据最优解集合创建虚拟机。
[0186]
也就是说，在得到预设规划模型的最优解集合之后，直接按照最优解集合来对虚拟机进行调度，以实现根据最优的方式在物理服务器上进行部署。这里，最优解集合即为：在约束条件下，根据预设规划模型计算出的，使得规划在物理服务器上的虚拟机的消费总和最大的规划策略。
[0187]
s505、在预设规划模型不存在最优解集合的情况下，判断n是否小于或等于n。
[0188]
s506、对已创建的虚拟机重新进行资源调度。
[0189]
s507、对n进行加1处理。
[0190]
s508、当前硬件与flavor不匹配，生成告警信息。
[0191]
需要说明的是，n表示前述实施例中的计数值，其初始值为0；n表示前述实施例中的预设阈值，n和n均是大于零的正整数。另外，在每次重新进行资源调度时，需要对n进行加1处理，然后返回步骤s503，以便重新计算预设规划模型是否有最优解。
[0192]
还需要说明的是，对于步骤s505来说，如果n小于或者n，即判断结果为是，那么可以执行步骤s506和s507，并返回执行步骤s503；如果n大于n，即判断结果为否，那么可以执行步骤s508。
[0193]
另外，在预设规划模型不存在最优解的情况下，对于步骤s506来说，其描述的是n小于或者等于n的情况，意味着当前服务器资源分配不合理，这时候需要对服务器上的当前虚拟机(如不合理虚拟机进行资源迁移)进行重新资源调度。
[0194]
对于步骤s508来说，其描述的是n大于n的情况，意味着在进行了n次对已创建的虚拟机重新进行资源调度之后，预设规划模型仍然无法得到最优解集合，表明了当前硬件与flavor不匹配，无法最大化利用资源，此时需要发出告警，然后规划人员可以结合实际需求对服务器进行扩容或者将暂时不使用的虚拟机进行迁出等。
[0195]
还需要说明的是，上述预设规划模型其实是一个多阶段决策过程，每一次虚拟机的调度，既依赖于当前状态，又随即引起状态的转移。这是一个典型的动态规划问题。要求导出最终决策的最优解，可以将其具体化成一个通用算法(这里可称为“动态规划算法”)。
[0196]
(
ⅰ
)常量为：p(fi)，c，d，r，m，n，fic，fid，fim，ph。
[0197]
(
ⅱ
)变量为：xin。
[0198]
(
ⅲ
)约束条件(边界条件)如下所示：
[0199][0200][0201]
[0202][0203][0204]
其中，在式(15)中，使用的flavor至少存在一个。
[0205]
进一步地，如果在此次虚拟机创建请求之前，服务器中存在已创建的若干虚拟机，例如已经存在了x个fi，那么边界条件应该如式(16)所示，即在进行资源规划时，不仅需要考虑虚拟机创建请求，还要考虑到已创建的虚拟机所占用的资源情况。
[0206][0207]
(
ⅳ
)，目标函数如式(17)所示，对该目标函数进行求解。
[0208][0209]
也就是说，在满足边界条件的前提下，得到每种flavor在每个服务器上面的部署数量xin，从而获得最优解，即最少浪费的资源调度方式，也就是最终采用的规划策略。
[0210]
(
ⅴ
)实现。上述预设规划模型的算法可以直接代入到一些常规的动态规划工具如matlab、cplex等进行计算，计算得到的结果就是预期的调度方案，即最终的规划策略。
[0211]
示例性地，下面以某个openstack云环境为例：环境中有若干台物理服务器(例如：4台)，每台物理服务器规格均为：48个cpu(总价4800，单价100/core)、384g内存(总价1920，单价5/g)、2t硬盘(总价1000,单价0.5/g)，则每台服务器的价值为7720。
[0212]
现有2种规格的flavor(假设不存在超分)，flavor a：8vcpu，128g内存，400g硬盘；flavor b：16vcpu，32g内存，200g硬盘。其中，vcpu即虚拟机cpu。
[0213]
结合前述预设规划模型进行计算可知：flavor a的价值为(8
×
100 128
×
5 400
×
0.5)＝1640；flavor b的价值为(16
×
100 32
×
5 200
×
0.5)＝1860。
[0214]
假设用户需要6个flavor a和6个flavor b；则用户需要的总价值为：(1640 1860)
×
6＝21000。
[0215]
在未采用本技术实施例提供的预设规划模型进行计算的情况下，可能的调度方式如表1所示。
[0216]
表1
[0217][0218][0219]
从表1可以看出，在没有采用本技术实施例提供的预设规划模型进行计算时，可能会在4台物理服务器上进行资源调度来创建用户需求的虚拟机。在这种资源调度方式下：服务器#1和服务器#2的内存资源均已耗尽，但是cpu资源和硬盘资源仍有较多富余；服务器#3和服务器#4的cpu资源均已耗尽，但是内存资源和硬盘资源仍有较多富余。即在满足用户需求的前提下，需要用满4个物理服务器，对于实际使用的物理服务器，最终的效率为21000/(7720
×
4)＝68％。
[0220]
在采用本技术实施例提供的预设规划模型进行计算的情况下，以最优解来进行资源调度的调度方式如表2所示(该结果由cplex提供)。
[0221]
表2
[0222][0223]
从表2可以看出，在采用了本技术实施例提供的预设模型进行计算时，只需要在3台物理服务器上进行资源调度来创建虚拟机就可以满足用户需求。在这种调度方式下：在3台物理服务器上均部署2个flavor a和2个flavor b。即用满3个物理服务器就可以满足用户需求，对于实际使用的物理服务器，最终的效率为：21000/(7720
×
3)＝90.7％。与采用4个物理服务器的效率为68％相比，效率大幅提高。换言之，要满足同样的用户需求，使用本
申请实施例提供的预设模型进行资源规划可以直接节省一个物理服务器的资源，大大提升了物理服务器的使用效率，从而提高了服务器集群的资源使用率。
[0224]
综上所述，本技术实施例提供的资源调度方法可以是一种基于openstack的动态资源调度策略，目的在于提高硬件资源使用率，本质上是要达到降低成本的目的。具体来说，本技术实施例的目标是：提高资源使用率，即在提供相同数目的同类型虚拟机的情况下，通过合理调度，压缩物理服务器碎片，降低硬件总成本；提高硬件-虚拟机转化比计算准确率，即根据当前剩余硬件数量，能够相当准确地计算出所能提供的虚拟机容量，有了这个计算结果，就可以预判用户的请求是否能满足，决定是否要提前采购服务器。
[0225]
也就是说，针对目前资源使用不平衡，无法精准计算已有资源所能提供的虚拟机容量，本技术实施例能够提高openstack的资源使用率。简言之，本技术实施例提高资源使用率的方法核心在于：一方面，构建预设规划模型(核心的调度算法)，通过该预设规划模型，可以确保资源池中的每个物理服务器的各项资源都能得到合理利用，大大减少由于碎片导致的价值浪费。举一个通俗的例子，芝麻，苹果，西瓜分别要放到几个筐里面，如果西瓜苹果芝麻掺杂着放，可以尽可能把每个筐都填满；如果芝麻苹果放满了一个筐，那么西瓜很难完整填充剩余的筐。另一方面，虚拟机动态调度策略，根据预设规划模型，选出资源池中最合适的物理服务器创建虚拟机，提高资源的利用率。除此之外，还可以告警告知规划人员，硬件跟flavor不匹配，无法最大化利用资源。
[0226]
与相关技术相比，本技术实施例提供的资源调度方法至少具有以下优势：(1)有效提升物理服务器的资源使用率，在大规模云环境下甚至可以达到90％以上。资源使用率(单个物理服务器已经达到木桶效应时的使用率)的提升意味着省钱，如果使用率从50％提升到90％，那么云服务商可以节约多达一半的开销。(2)基于当前资源池，预测可以支撑的虚拟机类型及数量。基于上述算法的资源调度，云服务商可以精确计算当前能支持的虚拟机种类及数目，而非如之前一样，每当接收到一批虚拟机请求就需要准别一批设备，而且无法确定设备是否足够满足要求。(3)对云环境没有任何要求，适用性极广，不依赖硬件且不限制虚拟机类型。
[0227]
本技术实施例提供了一种资源调度方法，通过上述实施例对前述实施例的具体实现进行了详细阐述，从中可以看出，通过构建预设规划模型，然后根据预设规划模型对资源池中的服务器资源进行规划，不仅能够选择出资源池中最合适的物理服务器创建虚拟机，提高资源利用率；而且基于该预设规划模型，还可以准确预测服务器可以支撑的虚拟机类型和数量；另外，在无法最大化利用资源时，还可以告警告知规划人员，当前硬件跟flavor不匹配，以使得规划人员及时做出合理应对措施。
[0228]
本技术的再一实施例中，参见图6，其示出了本技术实施例提供的一种资源调度装置60的组成结构示意图。如图6所示，所述资源调度装置60可以包括获取单元601、确定单元602以及调度单元603，其中，
[0229]
所述获取单元601，配置为获取虚拟机创建请求；
[0230]
所述确定单元602，配制为根据所述虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划，确定所述服务器集群的资源利用率达到目标值时的规划策略；
[0231]
所述调度单元603，配置为根据所述规划策略，在所述服务器集群中进行虚拟机资源调度。
[0232]
在一些实施例中，所述确定单元602，还配置为在所述服务器集群的资源利用率达到目标值时，确定从所述服务器集群中选择的目标服务器以及所述目标服务器部署的虚拟机信息；以及将所述目标服务器以及所述目标服务器部署的虚拟机信息确定为所述规划策略。
[0233]
在一些实施例中，所述确定单元602，还配置为若确定不存在所述服务器集群的资源利用率达到目标值时的规划策略，则判断计数值是否小于预设阈值；以及当所述计数值小于或等于预设阈值时，对所述服务器集群中的已创建虚拟机进行资源迁移处理，并对所述计数值执行加一操作，返回执行所述根据所述虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划的步骤。
[0234]
在一些实施例中，如图6所示，所述资源调度装置60还包括告警单元604，当所述计数值大于预设阈值时，生成告警信息；其中，所述告警信息用于指示所述服务器集群的硬件信息与虚拟机资源不匹配，使得所述服务器集群的资源利用率无法达到目标值。
[0235]
在一些实施例中，所述确定单元602，还配置为设置所述计数值的初始值为零。
[0236]
在一些实施例中，所述确定单元602，还配置为开启定时器并进行计时；以及当所述定时器的计时达到预设时长时，利用所述预设规划模型对所述服务器集群中的已创建虚拟机重新进行资源规划，确定所述服务器集群的资源利用率达到目标值时的规划策略；以及根据规划策略，在所述服务器集群中进行虚拟机资源调度。
[0237]
在一些实施例中，所述获取单元601，还配置获取服务器定义信息和虚拟机定义信息；
[0238]
所述确定单元602，还配置为根据所述服务器定义信息和所述虚拟机定义信息，确定约束条件；以及在所述约束条件下，构建所述预设规划模型；其中，所述服务器定义信息至少包括所述服务器集群中的服务器数量、每一服务器的性能参数值集合和每一服务器的价格参数集合，所述虚拟机定义信息至少包括虚拟机种类的数量、每一虚拟机种类的性能参数值集合和每一虚拟机种类的价格参数集合。
[0239]
在一些实施例中，所述性能参数集合包括：中央处理器cpu数量，内存容量和硬盘容量；所述价格参数集合包括：单位cpu价格、单位内存价格和单位硬盘价格。
[0240]
可以理解地，在本实施例中，“单元”可以是部分电路、部分处理器、部分程序或软件等等，当然也可以是模块，还可以是非模块化的。而且在本实施例中的各组成部分可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。
[0241]
所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
[0242]
因此，本实施例提供了一种计算机存储介质，该计算机存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现前述实施例中任一项所述方法的步骤。
[0243]
基于上述的一种资源调度装置60的组成以及计算机存储介质，参见图7，其示出了本技术实施例提供的一种电子设备70的具体硬件结构示意图。如图7所示，电子设备70可以包括通信接口701、存储器702和处理器703；各个组件通过总线系统704耦合在一起。可理解，总线系统704用于实现这些组件之间的连接通信。总线系统704除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图7中将各种总线都标为总线系统704。其中，
[0244]
通信接口701，用于在与其他外部网元之间进行收发信息过程中，信号的接收和发送；
[0245]
存储器702，用于存储能够在处理器703上运行的计算机程序；
[0246]
处理器703，用于在运行所述计算机程序时，执行：
[0247]
获取虚拟机创建请求；
[0248]
根据所述虚拟机创建请求，利用预设规划模型对服务器集群进行资源规划，确定所述服务器集群的资源利用率达到目标值时的规划策略；
[0249]
根据所述规划策略，在所述服务器集群中进行虚拟机资源调度。
[0250]
可以理解，本技术实施例中的存储器702可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，rom)、可编程只读存储器(programmable rom，prom)、可擦除可编程只读存储器(erasable prom，eprom)、电可擦除可编程只读存储器(electrically eprom，eeprom)或闪存。易失性存储器可以是随机存取存储器(random access memory，ram)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的ram可用，例如静态随机存取存储器(static ram，sram)、动态随机存取存储器(dynamic ram，dram)、同步动态随机存取存储器(synchronous dram，sdram)、双倍数据速率同步动态随机存取存储器(double data rate sdram，ddrsdram)、增强型同步动态随机存取存储器(enhanced sdram，esdram)、同步链动态随机存取存储器(synchronous link dram，sldram)和直接内存总线随机存取存储器(direct rambus ram，drram)。本文描述的系统和方法的存储器702旨在包括但不限于这些和任意其它适合类型的存储器。
[0251]
而处理器703可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器703中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器703可以是通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器702，处理器703读取存储器702中的信息，结合其硬件完成上述方法的步
骤。
[0252]
可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(application specific integrated circuits，asic)、数字信号处理器(digital signal processing，dsp)、数字信号处理设备(dsp device，dspd)、可编程逻辑设备(programmable logic device，pld)、现场可编程门阵列(field-programmable gate array，fpga)、通用处理器、控制器、微控制器、微处理器、用于执行本技术所述功能的其它电子单元或其组合中。
[0253]
对于软件实现，可通过执行本文所述功能的模块(例如过程、函数等)来实现本文所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。
[0254]
可选地，作为另一个实施例，处理器703还配置为在运行所述计算机程序时，执行前述实施例中任一项所述的方法的步骤。
[0255]
在这里，对于电子设备70而言，由于在创建虚拟机时，是根据预设规划模型对服务器集群进行资源规划，用以确定出能够使得服务器资源利用率达到最大的规划策略，然后根据该规划策略进行虚拟机资源调度。如此，不仅可以对服务器集群能够提供的虚拟机类型和数量进行准确计算，提高计算准确度；而且通过对服务器集群中已创建的虚拟机进行资源迁移，可以实现资源的合理调度，压缩物理服务器碎片，进而实现了最大化利用资源，降低了硬件总成本。
[0256]
以上所述，仅为本技术的较佳实施例而已，并非用于限定本技术的保护范围。
[0257]
需要说明的是，在本技术中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
[0258]
上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
[0259]
本技术所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。
[0260]
本技术所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。
[0261]
本技术所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。
[0262]
以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。