CN117785372A - 一种资源管理方法及装置 - Google Patents

Abstract

一种资源管理方法及装置，该方法包括：接收第一实例发放请求，第一实例发放请求用于请求在第一计算节点上创建第一实例，第一计算节点包括多个第一处理簇；基于资源优化算法和第一计算节点的拓扑结构，确定用于创建第一实例的至少一个第一处理簇；接收第二请求，第二请求用于请求在第二计算节点上创建第二实例，第二计算节点包括多个第二处理簇，第一计算节点的拓扑结构不同于第二计算节点的拓扑结构；基于资源优化算法和第二计算节点的拓扑结构，确定用于创建第二实例的至少一个第二处理簇。本申请提供一种适用于不同CPU架构的资源管理方法，可减少管理开销，且能够针对CPU的架构来创建实例，有利于提升CPU的性能。

Description

一种资源管理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种资源管理方法及装置。

背景技术

一个物理服务器上可承载多个虚拟机，虚拟机可以有多个虚拟中央处理器(virtual central processing unit，vCPU)，多个vCPU可以共享物理服务器上的资源，如物理CPU中的核(core)。一个core上可以“摆放”一个或多个vCPU。

现有多厂商服务器混部如“一云多芯”的场景越来越多，对于不同厂商的物理CPU，通常采用不同的资源管理方法来“摆放”vCPU，或者，采用其中一种厂商的物理CPU所适用的资源管理方法来管理其余厂商的物理CPU，可能导致其余厂商的物理CPU的性能变差。

目前，提供一种适用于不同厂商的物理CPU的资源管理方法是亟待解决的问题。

发明内容

本申请提供一种资源管理方法及装置，提供一种可适用于多架构CPU的通用的资源管理方法，减少管理开销，提升CPU性能。

第一方面，本申请提供一种资源管理方法，下述方法中的第一计算节点和第二计算节点均可以通过云平台进行资源管理。其中，第一计算节点包括至少一个第一处理簇，第二计算节点包括至少一个第二处理簇，第一计算节点的拓扑结构和第二计算节点的拓扑结构不同。

以该方法由云管理平台执行为例，在该方法中，云管理平台接收第一实例发放请求，第一实例发放请求可以客户端向云管理平台发送的，用于请求在第一计算节点上创建第一实例，如第一实例可以为虚拟机、容器、裸金属服务器等；云管理平台基于资源优化算法和第一计算节点的拓扑结构，确定用于创建第一实例的至少一个第一处理簇。

云管理平台接收第二实例发放请求，第二实例发放请求用于请求在第二计算节点上创建第二实例；云管理平台基于同一资源优化算法和第二计算节点的拓扑结构，确定用于创建第二实例的至少一个第二处理簇。

通过上述方法，云管理平台接收第一实例发放请求后，基于第一计算节点所采用的处理器架构和资源优化算法确定在第一计算节点内如何“摆放”第一实例的vCPU，即确定用于运行第一实例的处理器资源。当接收到第二请求后，基于第二计算节点所采用的处理器架构和同样的资源优化算法确定在第二计算节点内如何“摆放”第二实例的vCPU，即确定用于运行第二实例的处理器资源。提供一种适用于不同厂商的通用的物理CPU的资源管理方法，可减少管理开销，适用性强，且能够针对CPU的架构来“摆放”实例的vCPU，有利于提升CPU的性能。

在一种可能的实现方式中，计算节点包括一个或多个处理器，一个处理器可包括一个或多个处理簇，一个处理簇包括多个处理单元，一个处理单元包括多个处理器核。示例性的，多个CPU核可封装为一个处理单元，多个处理单元可封装为一个处理簇，多个处理簇可封装为一个CPU芯片，一个服务器主板可包括多个插槽(socker)，一个插槽用于安插一个CPU芯片，也即一个服务器可包括一个或多个CPU。

在一种可能的实现方式中，拓扑结构包括下列中的一项或多项：第一计算节点所包括的处理单元的数目、多个处理单元之间的连接关系、每个处理簇所包括的处理单元的数量、多个处理簇之间的连接关系、每个处理单元所包括的处理器核的数量。

在一种可能的实现方式中，云管理平台获取第一计算节点的资源使用情况，第一计算节点的资源使用情况包括第一计算节点中各个资源对象的可用状态，每个资源对象包括至少一个处理器核。例如所述资源对象包括下述的一种或多种：处理器核、处理单元、处理簇、处理器。云管理平台基于资源优化算法、所述第一计算节点的拓扑结构和所述第一计算节点的资源使用情况，确定用于创建第一实例的至少一个第一处理簇。

通过上述方法，云管理平台获取第一计算节点的资源使用情况，结合第一计算节点的拓扑结构可获知第一计算节点的各个资源对象的空闲资源。云管理平台基于资源优化算法和第一计算节点的拓扑结构，在第一计算节点的空闲资源中确定运行第一实例的至少一个第一处理簇。

在一种可能的实现方式中，资源优化算法的优化目标参数包括下述的一种或多种：

计算节点包括的资源碎片数、计算节点的单实例处理簇距离、计算节点的处理簇距离之和；其中，资源碎片数用于指示部分处理器资源被占用的资源对象的数量，资源对象包括至少一个处理器核；单实例处理簇距离为用于运行该实例的处理簇的距离之和，处理簇距离之和指示运行在计算节点上的全部实例的单实例处理簇距离的和。

通过上述方法，提供一种适用于不同CPU架构的物理CPU的资源优化算法，基于上述资源优化参数可提供满足多种场景/需求的优化指标，如优化指标包括创建第一实例后，资源碎片数少，第一实例的单实例处理簇距离短等，从而减少CPU的碎片率，提高处理器的资源利用率，减少跨处理簇通信，多方面提高CPU的性能。

在一种可能的实现方式中，第一计算节点所属厂商和第二计算节点所属厂商不相同。

通过上述方法，可兼容不同厂商的服务器，适用性强，应用场景广。

在一种可能的实现方式中，所述实例包括下述中的一种或多种：容器、虚拟机、裸金属服务器。

第二方面，本申请还提供了一种计算装置，该计算装置具有实现上述第一方面的方法实例中云管理平台相应的功能，有益效果可以参见第一方面的描述此处不再赘述。功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块。在一个可能的设计中，装置的结构中包括第一接收模块、第一确定模块、第二接收模块及第二确定模块。在一个可能的设计中，第一接收模块和第二接收模块还可以是同一个模块，第一确定模块和第二确定模块可以是同一个模块。这些模块可以执行上述第一方面方法示例中云管理平台相应的功能，具体参见方法示例中的详细描述，此处不做赘述。

第三方面，本申请还提供了一种计算设备集群，该计算设备集群包括至少一个计算设备，该至少一个计算设备具有实现上述第一方面的方法实例中云管理平台的相应功能，有益效果可以参见第一方面的描述此处不再赘述。每个计算设备的结构中包括处理器和存储器，处理器被配置为支持计算设备执行上述第一方面方法中云管理平台相应的部分或全部功能。存储器与处理器耦合，其保存计算设备必要的程序指令和数据。计算设备的结构中还包括通信接口，用于与其他设备进行通信。

第四方面，本申请还提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面以及第一方面的各个可能的设计中的方法。

第五方面，本申请还提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面以及第一方面的各个可能的设计中的方法。

第六方面，本申请还提供一种计算机芯片，芯片与存储器相连，芯片用于读取并执行存储器中存储的软件程序，执行上述第一方面以及第一方面的各个可能的实现方式中的方法。

附图说明

图1为本申请实施例提供的一种可能的系统架构示意图；

图2为本申请实施例提供的一种物理CPU与超线程的关系示意图；

图3为本申请实施例提供的一种物理CPU核与vCPU的关系示意图；

图4为一种CPU的结构示意图；

图5为另一种CPU的结构示意图；

图6为第三种CPU的结构示意图；

图7为本申请实施例提供的一种资源管理方法所对应的流程示意图；

图8的(a)、图8的(b)为第一计算节点内处理簇之间距离示意图；

图9为本申请实施例提供的一种计算装置的结构示意图；

图10为本申请实施例提供的一种计算设备的结构示意图；

图11为本申请实施例提供的一种计算设备集群的结构示意图；

图12为本申请实施例提供的另一种计算设备集群的结构示意图。

具体实施方式

为方便理解，首先对本申请实施例中的部分技术用语进行解释说明。

(1)实例，可指用于运行业务的软件程序或计算资源，还可以称为计算实例、计算模块、算法实例等。

(2)虚拟机(Virtual Machine，VM)，是指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。在实体计算机(简称实体机)中能够完成的工作在虚拟机中都能够实现。在实体机中创建虚拟机时，需要将实体机的部分硬件资源(如CPU、内存、硬盘等)作为虚拟机的硬件资源。每个虚拟机都有独立的操作系统，可以像使用实体机一样对虚拟机进行操作。在实际应用中，一台物理主机可以通过虚拟化技术虚拟出多台虚拟机。虚拟机也可称为云服务器(Elastic Compute Service,ECS)、弹性实例(不同的云服务提供商有不同的叫法)。

(3)容器，是实现操作系统虚拟化的一种途径，可以让用户在资源受到隔离的进程中运行应用程序及其依赖关系。

(4)裸金属服务器，是指可以为租户提供专属化云资源的物理服务器，即主机(host)。

(5)本申请中涉及的第一、第二等各种数字编号仅为描述方便进行的区分，并不用来限制本申请实施例的范围，也表示先后顺序。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。“至少一个”是指一个或者多个。至少两个是指两个或者多个。

图1为本申请提供的一种可能的系统结构示意图。如图1所示，该系统包括云管理平台和多个服务器。

服务器包括硬件层和软件层，硬件层为服务器的常规配置，如包括但不限于CPU、内存、硬盘和网卡等。一个服务器可包括一个或多个CPU，一个CPU可包括一个或多个CPU核(core)。

软件层包括安装并运行在服务器上的操作系统(相对虚拟机的操作系统可称为宿主机操作系统)，宿主机操作系统中设置有虚拟机管理器VMM(又可称为Hypervisor)，虚拟机管理器的作用是通过虚拟化技术，将一台服务器虚拟化为多台虚拟机，并负责管理虚拟机。

虚拟化技术可包括：计算虚拟化。其中，计算虚拟化是指将服务器的计算资源(如CPU)的部分提供给虚拟机。简单来说，CPU虚拟化是指将一个物理CPU核虚拟化出多个vCPU，以提供给虚拟机使用。

请参见图2，运行虚拟机的服务器设置有多个物理CPU，其中，物理CPU为图1所示的硬件层中的处理器，vCPU为图1所示的软件层中的虚拟处理器(为保持简洁，图1内每个虚拟机仅示出一个vCPU，但本申请对一个虚拟机所包括的vCPU的数量不做限定)。具体的，图2所示架构中，服务器1设置有4个物理CPU，分别记为CPU0、CPU1、CPU2、CPU3，每个物理CPU包括4个CPU核，每个CPU核支持的超线程数＝2。

虚拟机管理器可提供给虚拟机使用的vCPU总数＝超线程总数＝物理CPU数量(也称为socket数)×每个物理CPU带的CPU核的数量×每个CPU核支持的超线程的数量＝32。

如图3所示，一个超线程可作为1个vCPU提供给虚拟机使用，此时一个物理CPU核可稳定提供两个vCPU。一个物理服务器可支持多个虚拟机，如此，在云场景中，可以以虚拟机为粒度将一台服务器共享给多个租户使用。

云管理平台，提供访问接口(如界面或API)，租户可操作客户端远程接入访问接口在云管理平台注册云账号和密码，并登录云管理平台，云管理平台对云账号和密码鉴权成功后，租户可进一步在云管理平台付费选择并购买特定规格(如vCPU的数目、内存容量、磁盘容量等)的虚拟机，付费购买成功后，云管理平台提供所购买的虚拟机的远程登录账号密码，客户端可远程登录该虚拟机，在该虚拟机中安装、运行及卸载租户的应用。

应注意，除虚拟机之外，服务器内还可以创建容器、裸金属服务器等，租户可以像租用虚拟机一样租用容器、裸金属服务器等，此处不再赘述。

值得指出的是，图1仅示出两个服务器，通常，一个数据中心包括若干服务器，这些服务器可能来自同一个厂商或者来自多个不同的厂商。不同厂商的服务器中的物理CPU通常具有不同的架构。相应的，一个数据中心内的多个服务器中的物理CPU所采用的架构可能完全相同，或者不完全相同，或者完全不同。当一朵云内存在多种架构的CPU芯片时，可称为“一云多芯”。

如下介绍几种典型的物理CPU的架构。

图4为一种CPU的架构示意图。如图4所示，该CPU包括多个CPU die(芯片裸片)，每个CPU die包括多个处理单元，每个处理单元的结构均相同。为保持简洁，图4左侧示出了一个处理单元的结构，如图4所示，每个处理单元可包括4个CPU核(core)，每个CPU核内均包括L1 cache(L1缓存)和L2 cache(L2缓存)，由该CPU核独占。该4个CPU核共享处理单元内的L3Cache(缓存)。下文类似之处不再重复介绍。

一个CPU die内的组件可通过片内总线通信，CPU die之间可通过片外总线通信。多个CPU die采用环形架构互联，其中的任意两个CPU die互联，以使任意两个CPU die内的处理单元可进行通信。或者说，任意两个CPU die内的任意两个核可进行通信。每个CPU die还可包括其他组件，如内存(如双倍速率同步动态随机存储器(double data rate，DDR))等，此处不做重点介绍。下文类似之处，也不再重复说明。

图5为另一种CPU的架构示意图。如图5所示，该CPU包括4个CPU die或者2个CPUdie(图5未示出)，多个CPU die之间采用全互联架构连接。其中，每个CPU die固定有2个处理单元，每个处理单元的结构均相同。图5左侧示出了一个处理单元的结构，一个处理单元包括4个CPU核及L3 Cache。

图6为第三种CPU的架构示意图。如图6所示，该CPU包括8个CPU die，一个CPU die与两个或者三个CPU die采用二维网状结构(2D Mesh)互联。其中，每个CPU die有2个处理单元，每个处理单元的结构均相同，图6左侧示出了一个处理单元的结构，一个处理单元包括4个CPU核及L3 Cache。

需要说明的是，为保持简洁，图2中每个物理CPU仅示出4个CPU核，实际上，一个物理CPU可能包括大量CPU核，如在图4所示的架构中，一个物理CPU的CPU核数＝CPU die的数量×每个CPU die内处理单元的数量×每个处理单元所包括的CPU核的数量＝2×6×4＝48个。应理解，图4至图6也仅为几种示例，本实施例并不限定一个物理CPU所包括的CPU核数。另外还需说明的是，图3所示的情况也是一种示例，本申请对CPU核可提供的vCPU的数目也不做限定，来自不同厂商的CPU内的CPU核可提供的vCPU数目也可能是不同的。

本申请提供了一种资源管理方法，可应用于“一云多芯”场景中，该方法中，在计算节点内创建实例(如虚拟机)时，根据该计算节点所采用的CPU的架构和资源优化算法确定用于创建实例的处理簇。如此，提供了一种可适用于不同厂商的CPU的统一的资源管理方法，减少管理开销，且能够针对CPU的架构来“摆放”实例对应的vCPU，有利于提升CPU的性能。

接下来结合图7，以本申请提供的资源管理方法应用于图1所示的系统为例，对该方法进行说明。参见图7所示，该方法可包括：

步骤701，云管理平台接收第一实例发放请求。

在一种实施方式中，第一实例发放请求请求创建第一实例，第一实例可以是虚拟机、容器、裸金属服务器等中的一种或多种。

示例性的，第一实例发放请求可包括第一实例的规格信息，如包括但不限于第一实例所包括的vCPU的数量(或CPU核数)，可选的，还可以包括第一实例的内存容量、硬盘容量等一项或多项信息。

假设第一实例为虚拟机，参见表1示例性示出了云管理平台提供的几种虚拟机规格，应理解，表1仅为示例，本申请对虚拟机的规格不做限定。

表1

虚拟机规格	CPU核	虚拟机规格	CPU核	虚拟机规格	CPU核
						large_1	2	large_5	16	large_9	64
large_2	4	large_6	24	large_10	96
						large_3	8	large_7	32	large_11	128
large_4	12	large_8	48	large_12	…

租户可通过客户端在云管理平台付费选择并购买特定规格的虚拟机。付费后，客户端向云管理平台发送请求创建指定规格的第一实例的第一实例发放请求。

相应的，云管理平台接收到第一实例发放请求后，从多个服务器中选择满足条件的服务器，即能够提供该指定规格的实例的任意一个服务器，记为第一计算节点。如第一实例的规格为l arge_6，云管理平台可选择，位于用户选择的区域和/或可用区中，且剩余CPU资源不低于48个vCPU的一个计算节点作为第一计算节点。

在另一种实施方式中，该第一实例发放请求请求在第一计算节点上创建第一实例，第一计算节点可以是租户在云管理平台选择的计算节点。此时，第一实例发放请求可包括第一实例的规格信息和第一计算节点的信息。

步骤702，云管理平台确定第一计算节点的拓扑结构。

示例性的，云管理平台获取第一计算节点的拓扑信息，并基于该拓扑信息确定第一计算节点的拓扑结构。该拓扑信息的获取途径可以是从云管理平台的内存中获取，或者，也可以从云管理平台的本地持久化存储介质(如硬盘)或远端存储系统(如数据库)中获取，具体不做限定。

该拓扑信息用于描述第一计算节点的件组件及组件之间的连接关系。示例性的，计算节点的拓扑信息包括但不限于下列中的一项或多项：计算节点所包括的部分或全部组件、该部分或全部组件之间的连接关系。

如该拓扑信息用于描述计算节点内的计算资源(如CPU)的拓扑结构时，对应的拓扑信息可包括计算节点内的CPU所包括的组件及组件之间的连接关系。

可选的，当第一计算节点内的多个CPU均采用一种相同的架构时，第一计算节点的拓扑信息可仅包括该一种CPU的拓扑结构，不需要重复描述。示例性的，结合图4至图6中任一附图理解，CPU的拓扑结构可包括下列中的一项或多项：该CPU所包括的处理簇的数目、多个处理簇之间的连接关系、每个处理簇所包括的处理单元的数目、多个处理单元之间的连接关系、每个处理单元所包括的CPU核的数目。

处理簇可以是指，(在一个指定物理空间内)多个处理单元的集合，如可以是CPUdie或非统一内存访(numa)节点。示例性地，多个CPU核可封装为一个处理单元，多个处理单元可封装为一个处理簇，多个处理簇可封装为一个CPU芯片，一个服务器主板可包括多个插槽(socker)，一个插槽用于安插一个CPU芯片，也即一个服务器可包括一个或多个CPU。为便于说明，如下以处理簇为CPU die为例进行说明。

关于组件之间的连接关系，如处理簇之间的连接关系可包括但不限于下列中的一项或多项：处理簇的连接方式、处理簇之间的互联情况(每个处理簇与哪些处理簇有直接或间接的连接)、每个处理簇与其余任意一个互联的处理簇之间的距离等。

比如，图5所示的CPU的拓扑结构所对应的拓扑信息可包括：CPU die1至CPU die4采用互联架构互联；CPU die1分别与CPU die2、CPU die3、CPU die4直接连接，即CPU die1与CPU die2直接连接，CPU die1与CPU die3直接连接，CPU die1与CPU die4直接连接。类似的，CPU die2分别与CPU die1、CPU die3、CPU die4直接连接，CPU die3分别与CPU die1、CPU die2、CPU die4直接连接，依此类推。以及CPU die1分别与CPU die2、CPU die3、CPUdie4之间的距离，CPU die2分别与CPU die3、CPU die4之间的距离，等等。

可选的，拓扑信息还可以包括每个CPU核所支持的超线程的数目，或者说，一个CPU核可提供的vCPU的数目。

综上，本文中，CPU的拓扑结构中的层次可包括CPU→处理簇→处理单元→CPU核→超线程。

步骤703，云管理平台获取第一计算节点的资源使用情况。

示例性的，云管理平台获取第一计算节点的资源使用信息，该资源使用信息指示第一计算节点上的资源使用情况，该资源使用情况包括第一计算节点中各个资源对象的可用状态，其中，资源对象可包括但不限于下述中的一种或多种：CPU、处理簇、处理单元、CPU核、超线程。

在使用资源对象的可用状态时有多种方式，比如，指示资源对象中是否运行有实例。又比如，指示哪些资源对象具有空闲资源(或剩余资源)，空闲资源数目是多少等。其中，空闲资源数目可以以超线程或vCPU的数目度量，如一个CPU核支持两个vCPU时，该CPU核的空闲vCPU(即还未分配给虚拟机使用的vCPU)的数目，或者还可以以CPU利用率、CPU空闲率等值来度量，具体不做限定。

可替代的或可选的，资源使用信息可包括第一计算节点中的各个资源对象已使用资源的信息，如包括已使用资源的数目，和/或已使用资源的位置。

需要说明的是，步骤703为可选的步骤，并非必须执行的步骤，另外需要说明的是，步骤702和步骤703之间没有严格的时序限定，两个步骤可以同时执行也可以是步骤703在步骤702之前执行，或者步骤703在步骤702之后执行，具体不做限定。

步骤704，云管理平台基于资源优化算法和第一计算节点的拓扑结构，确定用于创建第一实例的至少一个第一处理簇。

资源优化算法的核心为在计算节点的拓扑结构的约束下，使优化目标参数达到优化指标。

示例性的，资源优化算法的优化目标参数包括但不限于下列中的一种或多种：

计算节点所包括的资源碎片数、计算节点的单实例处理簇距离、计算节点的处理簇距离之和。

(1)资源碎片是指部分处理器资源(未)被占用的资源对象的数量，或者说，运行有实例，且还存在剩余资源的资源对象的数量，可以理解为，资源对象包括已使用资源和未使用资源，则该资源对象为一个资源碎片。

比如，资源对象为CPU核，假设CPU核支持2个vCPU，分别记为vCPU0、vCPU1；该CPU核的部分处理器资源被占用的情况包括：vCPU0被占用，vCPU1未被占用，或者，vCPU1被占用，vCPU0未被占用，此时，该CPU核为一个资源碎片。若vCPU0和vCPU1均未被占用，或者vCPU0和vCPU1均被占用时，该CPU核不是资源碎片。

再比如，资源对象为处理单元，假设该处理单元包括4个CPU核，当4个CPU核中被占用的CPU核数为1个至3个时，该处理单元为一个资源碎片。当该处理单元内的4个CPU核均被占用或均未被占用时，该处理单元不是资源碎片。

相应的，本文中的资源碎片数可以是以CPU核为单位统计的资源碎片的数目，或者，以处理单元为单位统计的资源碎片的数目，或者，以处理簇为单位统计的资源碎片的数目，或者，以CPU为单位统计的资源碎片的数目。

(2)单实例处理簇距离是指用于运行该实例的处理簇的距离之和。

第一实例的单实例处理簇距离是指运行第一实例的处理簇的距离之和。如果运行第一实例的处理簇为一个，则距离为0。如果运行第一实例的处理簇为多个，则距离之和＝多个处理簇中的任意两个处理簇的距离之和。其中，两个处理簇之间的距离可以是两者之间的总线长度。比如，以图5为例，CPU die1和CPU die2之间的距离为CPU die1和CPU die2之间的总线长度。

(3)计算节点的处理簇距离之和，是指运行在该计算节点上的全部实例的单实例处理簇距离的和。

举例来说，假设第一计算节点中的CPU采用图8所示的架构，以及第一计算节点中的每个处理单元可提供8个vCPU，且该CPU内未运行任何实例。假设第一实例的规格包括48个vCPU。

在一种可能的实现方式中，第一实例可占用的48个vCPU可分布于3个处理簇或4个处理簇。其中，第一实例可占用6个完整的处理单元，或者，第一实例占用的处理单元可以超过6个。也即，实例可以占用某个处理单元的部分。例如，包括48个vCPU的第一实例还可以占用7个或8个处理单元，该7个或8个处理单元共计提供48个vCPU以运行第一实例。

示例性的，第一实例所占用的48个vCPU位于3个处理簇，如以CPU die1、CPU die2、CPU die3所包括的6个处理单元(48个vCPU)运行第一实例为例，该第一实例的单实例处理簇距离＝该3个CPU die的距离之和＝CPU die1与CPU die2之间的距离+CPU die1与CPUdie3之间的距离+CPU die2与CPU die3之间的距离，参见图8的(a)中的粗实线所示。应注意，由于该CPU仅运行第一实例，因此，此时第一计算节点的处理簇距离之和即为第一实例的单实例处理簇距离，下文不再赘述。

当以CPU核为单位统计资源碎片的数目时，由于第一实例占用6个完整的处理单元，在该CPU创建第一实例之后，该CPU上的资源碎片数为0。或者，当以处理单元为单位统计资源碎片的数目时，或当以处理簇为单位统计资源碎片的数目时，在该CPU创建第一实例之后，该CPU上的资源碎片数为0。或者，当以CPU为单位统计资源碎片的数目时，在该CPU创建第一实例之后，该CPU上的资源碎片数为1(即CPU die4为一个资源碎片)。

再示例性的，第一实例所占用的48个vCPU位于4个处理簇，如CPU die1、CPU die2、CPU die3、CPU die4内的任意6个完整的处理单元运行第一实例，或者，CPU die1、CPUdie2、CPU die3、CPU die4内的任意7个或8个处理单元运行第一实例。

如以该CPU die1内的一个处理单元，CPU die2内的两个处理单元，CPU die3内的两个处理单元，和CPU die4内的一个处理单元运行第一实例为例，此时，第一实例的单实例处理簇距离＝该4个CPU die的距离之和＝CPU die1与CPU die2之间的距离+CPU die1与CPU die3之间的距离+CPU die2与CPU die3之间的距离+CPU die1与CPU die4之间的距离+CPU die2与CPU die4之间的距离，参见图8的(b)中的粗实线所示。

当以CPU核为单位统计资源碎片的数目时，或以处理单元为单位统计资源碎片的数目时，在该CPU创建第一实例之后，该CPU上的资源碎片数为0。或者，当以处理簇为单位统计资源碎片的数目时，在该CPU创建第一实例之后，该CPU上的资源碎片数为2，即CPU die1内的一个空闲的计算单元为一个资源碎片，CPU die4内的一个空闲的计算单元为另一个资源碎片。或者，当CPU为单位统计资源碎片的数目时，在该CPU创建第一实例之后，该CPU上的资源碎片数为2，即包括一个空闲计算单元的CPU die1为一个资源碎片，及包括一个空闲计算单元的CPU die4为另一个资源碎片。

如果运行第一实例的处理簇数量为1，则第一实例的单实例处理簇距离为0。比如，若第一计算节点中的CPU采用图4所示的架构，为便于说明，仍假设一个CPU核可支持2个vCPU，当使用第一计算节点的其中1个处理簇内的6个完整处理单元运行第一实例时，第一实例的单实例处理簇之间的距离为0。

综上可见，在同一个计算节点上，存在多种可行的资源分配方案。云管理平台可基于资源优化算法从多种可行的资源分配方案中，确定满足优化指标的资源分配方案。并将满足优化指标的资源分配方案作为最终的资源分配方案。

相应的，基于上述优化目标参数，优化指标可包括：创建第一实例之后，第一计算节点上的资源碎片数最少。或者，该第一实例的单实例处理簇距离最小。或者，创建第一实例之后，第一计算节点的处理簇距离之和。或者，为了表示各个优化指标具有不同的重要程度，可以给每个优化指标指定不同的权重，多项优化指标的权重值之和为1。此时，优化指标还可以是多项优化指标的加权值之和最小。比如，优化指标为，创建第一实例后，第一计算节点上的资源碎片数×w1(权重值1)+第一实例的单实例处理簇距离×w2(权重值2)的和值最小，其中，w1+w2＝1。

本申请实施例，可直接基于计算节点的拓扑结构和资源优化算法来确定资源分配方案，比如，该计算节点为首次被使用的节点，再比如，云管理平台在默认CPU空闲的情况下确定资源分配方案，计算节点获取该资源分配方案后，选择一个空闲的CPU内，在该空闲的CPU内实施该资源分配方案，等等。

在一种可选的实施方式中，云管理平台可进一步结合第一计算节点的资源使用情况、资源优化算法和第一计算节点的拓扑结构，确定用于创建第一实例的至少一个第一处理簇。该实现过程可包括：云管理平台获取第一计算节点的资源使用情况，结合第一计算节点的拓扑结构可获知第一计算节点的各个资源对象的空闲资源(或剩余资源)。云管理平台基于资源优化算法和第一计算节点的拓扑结构，在第一计算节点的空闲资源中确定运行第一实例的至少一个第一处理簇。

示例性的，基于该优化指标，资源优化算法为实例分配处理器资源的原则可包括局部最优悲观算法：

若CPU内的一个CPU die的空闲资源可运行第一计算实例，则选择一个CPU die；如果每个CPU die的空闲资源均小于第一计算实例所需的处理器资源，则选择多个CPU die运行第一实例，并计算多个CPU die之间的距离之和。

在一个或多个CPU die中的每个CPU die内，如果第一实例所需的处理器资源包括n个处理单元的资源，则优先以处理单元为单元，先填满n个处理单元，剩余资源用碎片填满。比如，第一实例的规格包括24个vCPU，即所需的处理器资源为24个vCPU，以图8的(a)为例，若一个处理单元可提供16个vCPU，则可在一个CPU die内选择一个完整的处理单元摆放第一实例的16个vCPU，再选择一个空闲资源为8个vCPU的处理单元摆放第一实例的其余8个vCPU。若没有空闲资源恰好等于8个vCPU的处理单元，则可顺序选择空闲资源大于8个vCPU的处理单元摆放第一实例的其余8个vCPU。

如果第一实例所需的处理器资源不可被一个处理单元的资源整除，则优先用碎片填满。比如，第一实例的规格包括4个vCPU，即其所需的处理器资源为4个vCPU，则可以优先选择第一计算节点内的一个空闲资源为4个vCPU的处理单元来创建第一实例。

至此，第一实例的资源分配方案确定完成，粗粒度的，该资源分配方案可指示第一计算节点上用于创建第一实例的至少一个第一处理簇。细粒度的，该资源分配方案还可指示该至少一个第一处理簇内的处理单元、处理器核。

应理解，上述仅为解释说明如何确定资源碎片数、第一实例的单实例处理簇举例、及第一计算节点的处理簇距离之和所列举的几种示例，并不是最终的资源分配方案，也不应构成对本申请适用的优化目标参数的限定。比如，上述资源碎片的定义为一种示例，本实施例中的资源碎片的含义可包括多种，如资源碎片数为以最小碎片单元为粒度，统计的在已运行实例的资源对象中的空闲资源的数量，其中，空闲资源的大小等于一个最小碎片单元，或者，空闲资源可包括一个或多个连续的最小碎片单元。示例性的，最小碎片单元为超线程(或vCPU)，资源对象为CPU核。比如，若CPU核支持2个超线程，若1个超线程被使用，另1个超线程空闲，则该空闲的超线程为一个资源碎片。若2个超线程均被使用或均未被使用，则该CPU核没有资源碎片。再比如，若CPU核支持3个超线程，若1个超线程被使用，另2个超线程空闲，则每个空闲的超线程为一个资源碎片。可选的，当定义一个资源碎片包括连续的多个最小碎片单元时，若该2个空闲的超线程连续，则还可算作一个资源碎片。等等。在统计CPU上的资源碎片数时，可分别统计每个CPU核上的资源碎片数，从而得到该CPU上所有CPU核的资源碎片数。

云管理平台确定第一实例的资源分配方案之后，还可将第一实例的资源分配方案发送给第一计算节点，第一计算节点基于第一实例的资源分配方案创建第一实例。

步骤705，云管理平台接收第二实例发放请求，第二实例发放请求用于请求在第二计算节点创建第二实例。

第一计算节点和第二计算节点均可以通过云管理平台进行管理和配置。

步骤706，云管理平台确定第二计算节点的拓扑结构。

第二计算节点的拓扑结构可以与第一计算节点的拓扑结构相同，也可以与第一计算节点的拓扑结构不同。

步骤707，云管理平台获取第二计算节点的资源使用情况。

步骤708，云管理平台基于同一资源优化算法和第二计算节点的拓扑结构，确定用于创建第二实例的至少一个第二处理簇。

云管理平台执行步骤705至步骤708从而确定第二实例的资源分配方案，步骤705至步骤708的具体实施步骤，请参见前述步骤701至步骤704的介绍，此处不再赘述。

云管理平台确定第二实例的资源分配方案之后，还可将第二实例的资源分配方案发送给第二计算节点，第二计算节点用于基于第二实例的资源分配方案创建第二实例。

基于上述设计，云管理平台接收第一实例发放请求后，基于第一计算节点所采用的处理器架构和资源优化算法确定在第一计算节点内如何“摆放”第一实例的vCPU，即确定用于运行第一实例的处理器资源。当接收到第二请求后，基于第二计算节点所采用的处理器架构和同样的资源优化算法确定在第二计算节点内如何“摆放”第二实例的vCPU，即确定用于运行第二实例的处理器资源。提供一种适用于不同厂商的通用的物理CPU的资源管理方法，可减少管理开销，适用性强，且能够针对CPU的架构来“摆放”实例的vCPU，有利于提升CPU的性能。另外，上述资源优化算法提供满足多种场景/需求的优化指标，可适用于不同CPU架构的物理CPU，能够结合CPU架构摆放实例的vCPU，减少CPU的碎片率，提高处理器的资源利用率，同时尽可能减少跨处理簇通信，多方面提高CPU的性能。可兼容不同厂商的服务器，适用性强，应用场景广。

在本申请中，上述云管理平台所执行的步骤还可以由用于运行实例的计算节点，如第一计算节点和/或第二计算节点执行。应注意，用于运行实例的计算节点(如第一计算节点和第二计算节点)和云管理平台对应的计算节点是不同的节点。

比如，云管理平台接收到第一实例发放请求后，将第一实例发放请求发送至第一计算节点，第一计算节点执行上述步骤701至步骤704中云管理平台所执行的操作，从而由第一计算节点确定用于创建第一实例的处理器资源，第一计算节点在确定的处理器资源上创建第一实例。

又比如，云管理平台将第二请求发送至第二计算节点，第二计算节点执行上述步骤705至步骤708中云管理平台所执行的操作，从而由第二计算节点确定用于创建第二实例的处理器资源，第二计算节点在确定的处理器资源上创建第二实例。

基于与方法实施例同一发明构思，本申请实施例还提供了一种计算装置，该计算装置用于执行上述图7的方法实施例中云管理平台执行的方法。如图9所示，计算装置900包括第一接收模块901、第一确定模块902、第二接收模块903、第二确定模块904；可选的，计算装置900还可包括获取模块905。具体地，在计算装置900中，各模块之间通过通信通路建立连接。

第一接收模块901，接收第一实例发放请求，第一实例发放请求用于请求在第一计算节点上创建第一实例，所述第一计算节点包括多个第一处理簇；具体可参见步骤701的描述，此处不再赘述。

第一确定模块902，基于资源优化算法和所述第一计算节点的拓扑结构，确定用于创建第一实例的至少一个第一处理簇；具体可参见步骤704的描述，此处不再赘述。

第二接收模块903，接收第二实例发放请求，第二实例发放请求用于请求在第二计算节点上创建第二实例，所述第二计算节点包括多个第二处理簇，所述第一计算节点的拓扑结构不同于所述第二计算节点的拓扑结构；具体可参见步骤705的描述，此处不再赘述。

第二确定模块904，基于所述资源优化算法和所述第二计算节点的拓扑结构，确定用于创建所述第二实例的至少一个第二处理簇。具体可参见步骤708的描述，此处不再赘述。

在一种可能的实现方式中，获取模块905还用于：获取第一计算节点的资源使用情况，第一计算节点的资源使用情况包括第一计算节点中各个资源对象的可用状态；具体可参见步骤703的描述，此处不再赘述。

所述第一确定模块902确定用于创建所述第一实例的至少一个第一处理簇时，具体用于：基于资源优化算法、第一计算节点的拓扑结构和第一计算节点的资源使用情况，确定用于创建第一实例的至少一个第一处理簇。具体可参见步骤704中的相关描述，此处不再赘述。

在一种可能的实现方式中，所述资源优化算法的优化目标参数包括下述的一种或多种：

计算节点包括的资源碎片数、所述计算节点的单实例处理簇距离、所述计算节点的处理簇距离之和；其中，所述资源碎片数用于指示部分处理器资源被占用的资源对象的数量，所述资源对象包括至少一个处理器核；单实例处理簇距离为用于运行该实例的处理簇的距离之和，所述处理簇距离之和指示运行在所述计算节点上的全部实例的单实例处理簇距离的和。

在一种可能的实现方式中，资源对象包括下述的一种或多种：处理器核、处理单元、处理簇、处理器。

在一种可能的实现方式中，拓扑结构包括下列中的一项或多项：

计算节点所包括的处理单元的数目、多个处理单元之间的连接关系、每个处理簇所包括的处理单元的数量、多个处理簇之间的连接关系、每个处理单元所包括的处理器核的数量。

在一种可能的实现方式中，第一计算节点所属厂商和第二计算节点所属厂商不相同。

在一种可能的实现方式中，实例包括下述的一种或多种：容器、虚拟机、裸金属服务器。

示例性的，接下来以计算装置900中的第一确定模块902为例，介绍第一确定模块902的实现方式。类似的，第一接收模块901、第二接收模块903、第二确定模块904的实现方式可以参考第一确定模块902的实现方式。

当通过软件实现时，第一确定模块902可以是运行在计算机设备上的应用程序或代码块。其中，计算机设备可以是物理主机、虚拟机、容器等计算设备中的至少一种。进一步地，上述计算机设备可以是一台或者多台。例如，第一确定模块902可以是运行在多个主机/虚拟机/容器上的应用程序。需要说明的是，用于运行该应用程序的多个主机/虚拟机/容器可以分布在相同的可用区(availability zone,AZ)中，也可以分布在不同的AZ中。用于运行该应用程序的多个主机/虚拟机/容器可以分布在相同的区域(region)中，也可以分布在不同的region中。其中，通常一个region可以包括多个AZ。

同样，用于运行该应用程序的多个主机/虚拟机/容器可以分布在同一个虚拟私有云(virtual private cloud,VPC)中，也可以分布在多个VPC中。其中，通常一个region可以包括多个VPC，而一个VPC中可以包括多个AZ。

当通过硬件实现时，第一确定模块902中可以包括至少一个计算设备，如服务器等。或者，第一确定模块902也可以是利用专用集成电路(application-specificintegrated circuit，ASIC)实现、或可编程逻辑器件(programmable logic device，PLD)实现的设备等。其中，上述PLD可以是复杂程序逻辑器件(complex programmable logicaldevice，CPLD)、现场可编程门阵列(field-programmable gate array，FPGA)、通用阵列逻辑(generic array logic，GAL)或其任意组合实现。

第一确定模块902包括的多个计算设备可以分布在相同的AZ中，也可以分布在不同的AZ中。第一确定模块902包括的多个计算设备可以分布在相同的region中，也可以分布在不同的region中。同样，第一确定模块902包括的多个计算设备可以分布在同一个VPC中，也可以分布在多个VPC中。其中，所述多个计算设备可以是服务器、ASIC、PLD、CPLD、FPGA和GAL等计算设备的任意组合。

需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。在本申请的实施例中的各功能模块可以集成在一个模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中，比如，第一接收模块和第二接收模块集成在一个模块中，或者第一接收模块和第二接收模块为同一个模块。类似的，第一确定模块和第二确定模块集成在一个模块中，或者第一确定模块和第二确定模块为同一个模块。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

本申请还提供一种计算设备1000。如图10所示，计算设备1000包括：总线1002、处理器1004、存储器1006和通信接口1008。处理器1004、存储器1006和通信接口1008之间通过总线1002通信。计算设备1000可以是服务器或终端设备。应理解，本申请不限定计算设备1000中的处理器、存储器的个数。

总线1002可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一条线表示，但并不表示仅有一根总线或一种类型的总线。总线1002可包括在计算设备1000各个部件(例如，存储器1006、处理器1004、通信接口1008)之间传送信息的通路。

处理器1004可以包括中央处理器(central processing unit，CPU)、图形处理器(graphics processing unit，GPU)、微处理器(micro processor，MP)或者数字信号处理器(digital signal processor，DSP)等处理器中的任意一种或多种。

存储器1006可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)。处理器1004还可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器，机械硬盘(hard diskdrive，HDD)或固态硬盘(solid state drive，SSD)。

存储器1006中存储有可执行的程序代码，处理器1004执行该可执行的程序代码以分别实现前述第一接收模块901、第一确定模块902、第二接收模块903、第二确定模块904、获取模块905的功能，从而实现资源管理方法。也即，存储器1006上存有计算装置900用于执行本申请提供的资源管理方法的指令。

通信接口1008使用例如但不限于网络接口卡、收发器一类的收发模块，来实现计算设备1000与其他设备或通信网络之间的通信。

本申请实施例还提供了一种计算设备集群。该计算设备集群包括至少一台计算设备。该计算设备可以是服务器。在一些实施例中，计算设备也可以是台式机、笔记本电脑或者智能手机等终端设备。

如图11所示，该计算设备集群包括至少一个计算设备1000。计算设备集群中的一个或多个计算设备1000中的存储器1006中可以存有相同的用于执行资源分配方法的指令。

在一些可能的实现方式中，该计算设备集群中的一个或多个计算设备1000的存储器1006中也可以分别存有用于执行资源分配方法的部分指令。换言之，一个或多个计算设备1000的组合可以共同执行用于执行资源分配方法的指令。

需要说明的是，计算设备集群中的不同的计算设备1000中的存储器1006可以存储不同的指令，分别用于执行计算装置的部分功能。也即，不同的计算设备1000中的存储器1006存储的指令可以实现第一接收模块901、第一确定模块902、第二接收模块903、第二确定模块904和获取模块905中的一个或多个模块的功能。

在一些可能的实现方式中，计算设备集群中的一个或多个计算设备可以通过网络连接。其中，所述网络可以是广域网或局域网等等。图12示出了一种可能的实现方式。如图12所示，两个计算设备100A和100B之间通过网络进行连接。具体地，通过各个计算设备中的通信接口与所述网络进行连接。在这一类可能的实现方式中，计算设备1000A中的存储器1006中存有执行第一接收模块901、第一确定模块902的功能的指令。同时，计算设备1000B中的存储器1006中存有执行第二接收模块903、第二确定模块904的功能的指令。

应理解，图12中示出的计算设备1000A的功能也可以由多个计算设备1000完成。同样，计算设备1000B的功能也可以由多个计算设备1000完成。

本申请实施例还提供了另一种计算设备集群。该计算设备集群中各计算设备之间的连接关系可以类似的参考图11和图12所述计算设备集群的连接方式。不同的是，该计算设备集群中的一个或多个计算设备1000中的存储器1006中可以存有相同的用于执行资源管理方法的指令。

在一些可能的实现方式中，该计算设备集群中的一个或多个计算设备1000的存储器1006中也可以分别存有用于执行资源管理方法的部分指令。换言之，一个或多个计算设备1000的组合可以共同执行用于执行资源管理方法的指令。

本申请实施例还提供了一种包含指令的计算机程序产品。所述计算机程序产品可以是包含指令的，能够运行在计算设备上或被储存在任何可用介质中的软件或程序产品。当所述计算机程序产品在至少一个计算设备上运行时，使得至少一个计算设备执行资源管理方法。

本申请实施例还提供了一种计算机可读存储介质。所述计算机可读存储介质可以是计算设备能够存储的任何可用介质或者是包含一个或多个可用介质的数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘)等。该计算机可读存储介质包括指令，所述指令指示计算设备执行资源管理方法。

可选的，本申请实施例中的计算机执行指令也可以称之为应用程序代码，本申请实施例对此不作具体限定。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包括一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

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

Claims (17)

1.一种资源管理方法，其特征在于，所述方法包括：

接收第一实例发放请求，所述第一实例发放请求用于请求在第一计算节点上创建第一实例，所述第一计算节点包括多个第一处理簇；

基于资源优化算法和所述第一计算节点的拓扑结构，确定用于创建所述第一实例的至少一个第一处理簇；

接收第二实例发放请求，所述第二实例发放请求用于请求在第二计算节点上创建第二实例，所述第二计算节点包括多个第二处理簇，所述第一计算节点的拓扑结构不同于所述第二计算节点的拓扑结构；

基于所述资源优化算法和所述第二计算节点的拓扑结构，确定用于创建所述第二实例的至少一个第二处理簇。

2.如权利要求1所述的方法，其特征在于，所述基于资源优化算法和所述第一计算节点的拓扑结构，确定用于创建所述第一实例的至少一个第一处理簇前，所述方法还包括：

获取所述第一计算节点的资源使用情况，所述第一计算节点的资源使用情况包括所述第一计算节点中各个资源对象的可用状态；所述资源对象包括至少一个处理器核；

所述基于资源优化算法和所述第一计算节点的拓扑结构，确定用于创建所述第一实例的至少一个第一处理簇，包括：

基于所述资源优化算法、所述第一计算节点的拓扑结构和所述第一计算节点的资源使用情况，确定用于创建所述第一实例的至少一个第一处理簇。

3.如权利要求1或2所述的方法，其特征在于，所述资源优化算法的优化目标参数包括下述的一种或多种：

计算节点包括的资源碎片数、所述计算节点的单实例处理簇距离、所述计算节点的处理簇距离之和；

其中，所述资源碎片数用于指示部分处理器资源被占用的资源对象的数量，所述资源对象包括至少一个处理器核；单实例处理簇距离为用于运行该实例的处理簇的距离之和，所述处理簇距离之和指示运行在所述计算节点上的全部实例的单实例处理簇距离的和。

4.如权利要求3所述的方法，其特征在于，所述资源对象包括下述的一种或多种：

处理器核、处理单元、处理簇、处理器。

5.如权利要求1至4中任一项所述的方法，其特征在于，所述拓扑结构包括下列中的一项或多项：

计算节点所包括的处理单元的数目、多个处理单元之间的连接关系、每个处理簇所包括的处理单元的数量、多个处理簇之间的连接关系、每个处理单元所包括的处理器核的数量。

6.如权利要求1至5中任一项所述的方法，其特征在于，所述第一计算节点所属厂商和所述第二计算节点所属厂商不相同。

7.如权利要求1至6中任一项所述的方法，其特征在于，所述实例包括下述的一种或多种：容器、虚拟机、裸金属服务器。

8.一种计算装置，其特征在于，所述装置包括：

第一接收模块，用于接收第一实例发放请求，所述第一实例发放请求用于请求在第一计算节点上创建第一实例，所述第一计算节点包括多个第一处理簇；

第一确定模块，用于基于资源优化算法和所述第一计算节点的拓扑结构，确定用于创建所述第一实例的至少一个第一处理簇；

第二接收模块，用于接收第二实例发放请求，所述第二实例发放请求用于请求在第二计算节点上创建第二实例，所述第二计算节点包括多个第二处理簇，所述第一计算节点的拓扑结构不同于所述第二计算节点的拓扑结构；

第二确定模块，用于基于所述资源优化算法和所述第二计算节点的拓扑结构，确定用于创建所述第二实例的至少一个第二处理簇。

9.如权利要求8所述的装置，其特征在于，所述计算装置还包括获取模块；

所述获取模块还用于：获取所述第一计算节点的资源使用情况，所述第一计算节点的资源使用情况包括所述第一计算节点中各个资源对象的可用状态；所述资源对象包括至少一个处理器核；

所述第一确定模块确定在创建所述第一实例的至少一个第一处理簇时，具体用于：基于所述资源优化算法、所述第一计算节点的拓扑结构和所述第一计算节点的资源使用情况，确定用于创建所述第一实例的至少一个第一处理簇。

10.如权利要求8或9所述的装置，其特征在于，所述资源优化算法的优化目标参数包括下述的一种或多种：

计算节点包括的资源碎片数、所述计算节点的单实例处理簇距离、所述计算节点的处理簇距离之和；

其中，所述资源碎片数用于指示部分处理器资源被占用的资源对象的数量，所述资源对象包括至少一个处理器核；单实例处理簇距离为用于运行该实例的处理簇的距离之和，所述处理簇距离之和指示运行在所述计算节点上的全部实例的单实例处理簇距离的和。

11.如权利要求10所述的装置，其特征在于，所述资源对象包括下述的一种或多种：

处理器核、处理单元、处理簇、处理器。

12.如权利要求8至11中任一项所述的装置，其特征在于，所述拓扑结构包括下列中的一项或多项：

计算节点所包括的处理单元的数目、多个处理单元之间的连接关系、每个处理簇所包括的处理单元的数量、多个处理簇之间的连接关系、每个处理单元所包括的处理器核的数量。

13.如权利要求8至12中任一项所述的装置，其特征在于，所述第一计算节点所属厂商和所述第二计算节点所属厂商不相同。

14.如权利要求8至13中任一项所述的装置，其特征在于，所述实例包括下述的一种或多种：容器、虚拟机、裸金属服务器。

15.一种计算设备集群，其特征在于，包括至少一个计算设备，每个计算设备包括处理器和存储器；

所述至少一个计算设备的处理器用于执行所述至少一个计算设备的存储器中存储的指令，以使得所述计算设备集群执行如权利要求1至7任一项所述的方法。

16.一种包含指令的计算机程序产品，其特征在于，当所述指令被计算设备集群运行时，使得所述计算设备集群执行如权利要求的1至7任一项所述的方法。

17.一种计算机可读存储介质，其特征在于，包括计算机程序指令，当所述计算机程序指令由计算设备集群执行时，所述计算设备集群执行如权利要求1至7任一项所述的方法。