CN110209499B - 一种云平台资源动态配置方法、装置及云平台 - Google Patents

Abstract

本发明提供了一种云平台资源动态配置方法、装置及云平台，该云平台资源动态配置方法，包括：确定当前云平台中用于直接或者间接响应用户请求的业务处理单元所匹配的第一资源；获取业务修改配置请求，并仅在资源池中的剩余资源满足业务修改配置请求所匹配的第二资源时，将所述第一资源与第二资源共同地为云平台中接收所述业务修改配置请求所对应的业务处理单元优先进行资源配置。通过本发明，解决了在云平台所形成的资源既定的前提下因业务修改配置所导致的云主机等业务处理单元所需要的资源发生变动时多个云主机之间发生资源争夺的问题，实现了对资源池中所形成资源的合理配置，调高了云平台运行的稳定性与用户体验。

Description

一种云平台资源动态配置方法、装置及云平台

技术领域

本发明涉及计算机技术领域，尤其涉及一种云平台资源动态配置方法，以及基于运行该种云平台资源动态配置方法的一种云平台资源动态配置装置，以及所形成的一种云平台。

背景技术

对云平台资源作合理调度是保证云平台高效响应用户请求并保证云平台正常运作的关键因素之一。目前通常通过虚拟机监视器(即Hypervisor)对云平台资源进行调度。对云平台资源的合理调度对云平台的用户体验、服务质量保证(QoS)具有重要意义。

资源池是由若干云主机资源组成的资源集合，云主机与资源池是一一对应的，云主机在不同资源池之间具有唯一性，所有云主机资源没有做隔离措施，很多情况下云主机是可以分属不同资源池的，这样就导致同一资源池内部的云主机资源可能属于不同的用户，无法很方便的管理分属于不同用户的云主机资源，而且没有对云主机的性能参数做限制，那么针对是否所有用户都可以使用这些云主机资源就引申出复杂的操作权限问题。显然，如果仅仅依靠对资源池中的各种资源进行赋权设置又会增加云平台的计算开销，并降低云平台通过虚拟化技术所封装形成的云主机的性能。

按需分配是目前业界普遍采用的资源动态配置方法，用户可以按需分配和调度资源，从而提高资源的利用率，提升服务质量，并降低云用户的总体拥有成本。但由于物理服务器的资源边界限制了资源的全局优化能力。同时，Xen、VMware、KVM等虽然提供了气球驱动、页面交换和内存共享等机制来动态调整虚拟机的内存，但缺乏对云计算内存资源的实时监测，缺乏从全局角度进行多虚拟机之间的内存协同管理，容易造成过多的性能损失或者对用户封装的云主机无法满足用户当前的使用需求。

发明内容

本发明的目的在于揭示一种云平台资源动态配置方法、装置及云平台，用以实现对云平台中云主机等业务处理单元所需要的资源执行动态配置，并实现在云平台所形成的资源既定的前提下因业务修改配置所导致的云主机等业务处理单元所需要的资源发生变动时，避免多个云主机之间发生资源争夺，并对资源池中所形成的资源进行合理配置，以调高云平台运行的稳定性与用户体验。

为实现上述第一个发明目的，本发明首先提供了一种云平台资源动态配置方法，包括：

确定当前云平台中用于直接或者间接响应用户请求的业务处理单元所匹配的第一资源；

获取业务修改配置请求，并仅在资源池中的剩余资源满足业务修改配置请求所匹配的第二资源时，将所述第一资源与第二资源共同地为云平台中接收所述业务修改配置请求所对应的业务处理单元优先进行资源配置。

作为本发明的进一步改进，在获取业务修改配置请求后，还包括：

对云平台中的其他业务处理单元所配置的资源与第二资源执行隔离。

作为本发明的进一步改进，对云平台中的其他业务处理单元所配置的资源执行隔离后，还包括：

检测资源池中的剩余资源是否满足业务修改配置请求所匹配的第二资源的需求，

若是，则将所述第一资源与第二资源共同地为云平台中接收该业务修改配置请求所对应的业务处理单元优先进行资源配置；

若否，则仅将所述第一资源为云平台中接收该业务修改配置请求所对应的业务处理单元进行资源配置。

作为本发明的进一步改进，还包括：将业务修改配置请求所匹配的第二资源与第一资源进行比较，并仅在第二资源小于第一资源时，将第二资源与第一资源所形成的差额资源释放至资源池。

作为本发明的进一步改进，所述业务处理单元为计算节点、网络节点、控制节点、存储节点、虚拟机、容器中的一种或者任意几种的组合。

为实现上述第二个发明目的，本发明还提供了一种云平台资源动态配置装置，包括：

资源调度模块，判断模块及检测模块；其中，

资源调度模块，用于确定当前云平台中用于直接或者间接响应用户请求的业务处理单元所匹配的第一资源并获取业务修改配置请求；

检测模块，用以对资源池中的剩余资源进行检测并通知判断模块；

判断模块，用以判断资源池中的剩余资源是否满足业务修改配置请求所匹配的第二资源，并仅在资源池中的剩余资源满足业务修改配置请求所匹配的第二资源时，通过所述资源调度模块将所述第一资源与第二资源共同地为云平台中接收所述业务修改配置请求所对应的业务处理单元优先进行资源配置。

作为本发明的进一步改进，还包括隔离模块，所述隔离模块用以在获取业务修改配置请求后对云平台中的其他业务处理单元所配置的资源与第二资源执行隔离。

作为本发明的进一步改进，还包括释放模块，所述判断模块将业务修改配置请求所匹配的第二资源与第一资源进行比较，并仅在第二资源小于第一资源时，将第二资源与第一资源所形成的差额资源通过所述释放模块释放至资源池。

作为本发明的进一步改进，所述业务处理单元为计算节点、网络节点、控制节点、存储节点、虚拟机、容器中的一种或者任意几种的组合。

为实现上述第三个发明目的，本发明还提供了一种云平台，包括：

至少一个计算节点，所述计算节点中被配置出至少一个业务处理单元，控制节点，

所述控制节点中配置如第6至第8个发明创造所述的云平台资源动态配置装置，以通过所述云平台资源动态配置装置对业务处理单元进行资源配置。

与现有技术相比，本发明的有益效果是：本发明通过获取业务修改配置请求，并仅在资源池中的剩余资源满足业务修改配置请求所匹配的第二资源时，将所述第一资源与第二资源共同地为云平台中接收所述业务修改配置请求所对应的业务处理单元优先进行资源配置，解决了在云平台所形成的资源既定的前提下因业务修改配置所导致的云主机等业务处理单元所需要的资源发生变动时多个云主机之间发生资源争夺的问题，实现了对资源池中所形成资源的合理配置，并由此显著地调高了云平台运行的稳定性与用户体验。

附图说明

图1为本发明一种云平台资源动态配置方法的流程图；

图2为本发明一种云平台资源动态配置装置在一种实施例中的框图；

图3为本发明一种云平台资源动态配置装置在一种变形实施例中的框图；

图4为业务修改配置请求所匹配的第二资源与第一资源进行比较，并当第二资源大于第一资源且不超过资源池中对应种类的资源时，将所述第一资源与第二资源共同地为云平台中接收所述业务修改配置请求所对应的业务处理单元优先进行资源配置的示意图；

图5为业务修改配置请求所匹配的第二资源小于第一资源时，将第二资源与第一资源所形成的差额资源释放至资源池的示意图；

图6为本发明一种云平台的框图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

在详细阐述本发明各个实施例之前，对实施例中出现的重要术语的含义予以界定与解释。

术语“资源”包括但不限于基于云平台各种功能所形成的虚拟计算资源、虚拟存储资源、虚拟网络资源、接口资源、IP地址资源、MAC地址资源或者硬件资源。

术语“资源池”是指由前述资源所形成的一个集合。

术语“云主机”是指由前述资源所配置形成并向用户进行响应的业务处理单元，并可以与“虚拟机”作相同或者等同理解。

术语“大于”如无特殊说明，通常不包含本数；

术语“不超过”如无特殊说明，通常包含本数。

实施例一：

结合图1、图4及图5所示，本实施例揭示了一种云平台资源动态配置方法(以下简称“方法”)。

本发明不依赖现有技术中对业务处理单元(例如“云主机”)所需要配置的资源进行调整时，直接释放掉业务处理单元在当前状态下所配置的资源，再重新先自资源池60申请需要调整的资源，并共同为业务处理单元进行配置。

本实施例所揭示的一种云平台资源动态配置方法，包括以下步骤：

首先，执行步骤S1、确定当前云平台中用于直接或者间接响应用户请求的业务处理单元所匹配的第一资源。

云平台可为IaaS、PaaS或者SaaS。云平台中运行一个或者多个直接或者间接响应用户请求的业务处理单元。所谓业务处理单元可为计算节点、网络节点、控制节点、存储节点、虚拟机(或者称之为云主机)、容器中的一种或者任意几种的组合，并可基于云平台的应用需求进行任意组合，以满足用户的实际需求为原则。

在本实施例中，申请人以云主机为作为业务处理单元的一种典型形式，并作示范性说明。同时，在申请各个实施例中，直接响应用户80发起的访问请求是指，能够直接向用户80进行响应的装置、系统或者逻辑组件，并能够基于网络向业务处理单元执行写操作、读操作、修改操作、备份操作或者迁移操作等各种类型的操作。间接响应用户80发起的访问请求是指，必须依赖其他装置(例如，数据库)才能完成的写操作、读操作、修改操作、备份操作或者迁移操作等各种类型的操作。但无论任何是直接响应用户请求的业务处理单元，还是间接响应用户请求的业务处理单元，在云平台中均依赖云平台中的资源60运行，通过如图2或者图3中的资源调度模块20调度若干资源，并将该资源60封装成具有一定功能的装置或者组件，才能直接或者间接地向用户80进行响应。因此，对云平台中资源60的合理调度与配置极大决定了云平台运行的稳定性与用户体验。

在步骤S1中，可通过资源调度模块20确定云主机在动态配合前所确定的资源(例如，虚拟CPU、虚拟内存或者虚拟存储所形成的资源)设定为临时占用的状态。这种临时占用状态所占用的资源与资源池60中的其他相同种类和/或不同种类的资源相互隔离。

结合图4与图5所示，云平台中的资源池60中形成了4颗CPU(在本申请中，CPU均硬件形式的CPU并基于虚拟化技术所形成的虚拟CPU，并视为资源的一种形式)，即CPU_1、CPU_2、CPU_3、CPU_4。配合参照图6所示，云主机91在资源调度模块20确定云主机91在动态配合前所确定的资源(即虚拟CPU资源)是CPU_1、CPU_2及CPU_3。此时，将CPU_1、CPU_2及CPU_3设定为临时占用的状态，此时CPU_1、CPU_2及CPU_3共同构成上述步骤S1中的第一资源。同时，该第一资源与CPU_4进行隔离。CPU_4就被定义为资源池60中的对应虚拟CPU的可用资源。需要说明的是，可用资源还可为与虚拟CPU不同类型的资源类型，例如虚拟内存、GPU等设备/模块。

然后，执行步骤S2、获取业务修改配置请求，并仅在资源池60中的剩余资源满足业务修改配置请求所匹配的第二资源时，将所述第一资源与第二资源共同地为云平台中接收所述业务修改配置请求所对应的业务处理单元(例如，云主机91)优先进行资源配置。具体而言，在获取业务修改配置请求后，对云平台中的其他业务处理单元所配置的资源与第二资源执行隔离。其中，所谓“云平台中的其他业务处理单元所配置的资源”可以是支撑其他云主机所需要各种虚拟资源和/或硬件资源，且不局限于类似于图4及图5所示出的虚拟CPU。

在云平台环境中，可通过如图2中所示出的资源调度模块20获取用户80发起的业务修改配置请求。此种业务修改配置请求可以是对步骤S1中确定的第一资源进行增量配置，也可为对步骤S1中确定的第一资源进行缩量配置。但是无论是增量配置还是缩量配置均会形成一定的差额资源。申请人结合图4与图5对用户80发起的业务修改配置请求所可能形成的上述两种情形予以说明。

同时，对云平台中的其他业务处理单元所配置的资源执行隔离后，还包括：检测资源池60中的剩余资源是否满足业务修改配置请求所匹配的第二资源的需求。参图2或者图3所示，在本实施例中，第二资源可被理解为满足业务修改配置请求所匹配的资源。需要说明的是，资源池60可被划分为虚拟计算资源601、虚拟存储资源602及虚拟网络资源603，同时，资源池60并不局限于上述三种类型的资源，还可包括其他专用设备，例如GPU设备、独占型CPU、独占型内存等。

云主机91可在步骤S1中预先配置作为第一资源611、第一资源612及第一资源613。同时，图2中包含第一资源的611的资源611a、资源612a及资源613a的面积分别比对应的第一资源611、第一资源612及第一资源613稍大，以代表云主机91所收到的业务修改配置请求是增量配置。本领域的技术人员应当预测到，如果第一资源的611的资源611a、资源612a及资源613a的面积分别比对应的第一资源611、第一资源612及第一资源613稍小或者直接消失，则代表该业务修改配置请求是缩量配置，并可参考下文关于缩量配置的实现过程予以合理解释与理解。此时，可参考图4所揭示的技术方案，判断资源池60中对应的资源是否满足用户80发起的业务修改配置请求，并具体如下文所述。

云主机91在步骤S1中所确定的第一资源是CPU_1、CPU_2及CPU_3，而此时CPU_4则被视为第二资源。例如，当用户80发起申请四颗CPU的业务修改配置请求，在云主机91接收到用户80发起的业务修改配置请求后需要判断是增量配置还是缩量配置。如果是增量配置，则需要判断资源池60中的剩余的虚拟CPU是否满足业务修改配置请求。若是，则将所述第一资源与第二资源共同地为云平台中接收该业务修改配置请求所对应的业务处理单元优先进行资源配置。即，此时资源池60中还剩余CPU_4，那么资源调度模块20则会将CPU_4作为第二资源，并与作为第一资源的CPU_1、CPU_2及CPU_3共同响应用户80。若否，则仅将所述第一资源为云平台中接收该业务修改配置请求所对应的业务处理单元进行资源配置。如果在此期间，云平台接收到了其他用户(即非用户80)所发起的申请两颗CPU的业务请求时，资源调度模块20就会拒绝其他用户(即非用户80)向云平台发起的业务请求，并优先保证在先用户(即用户80)，即用户80发起的业务修改配置请求，从而解决了用户80与其他用户对虚拟CPU，并具体为CPU_4这一资源的争夺。同时，如果是缩量配置，例如，云主机91接收到用户80发起的业务修改配置请求后要求将作为第一资源的CPU_1、CPU_2及CPU_3缩减为CPU_1与CPU_2。如果在此期间，云平台接收到了其他用户(即非用户80)所发起的申请两颗CPU的业务请求时，则可通过如图2中的资源调度模块20直接将CPU_3与CPU_4分配给新用户。

更为重要的是的，在本实施例中，用户80在发起业务修改配置请求时，不需要将其在步骤S1已经配置的虚拟CPU执行释放操作，因此保证了在云平台中某个新用户申请新的云主机与老用户在云平台中已经部署的云主机在资源紧张时不会发生资源争夺的现象，确保了老用户(即图2中的用户80)已经创建的云主机91运行的稳定性，实现了对资源池60中所形成资源的合理配置。

同时，需要说明的是，本实施例中所披露的资源，除了上文所述的资源所涉及的种类之外，还可为GPU设备、虚拟网卡、虚拟网关、物理网卡、SAN存储、金属裸机交换机、二层交换机、三层交换机、FPGA芯片，SoC芯片、防火墙、虚拟服务器等用于构建云主机的组件或者装置，且不限定于上述穷尽的资源种类。

实施例二：

配合参照图5所示，基于实施例一中相同或者类似的发明思想，本实施例揭示了一种云平台资源动态配置方法的一种变形实施例。

在本实施例中，该方法还包括：将业务修改配置请求所匹配的第二资源与第一资源进行比较，并仅在第二资源小于第一资源时，将第二资源与第一资源所形成的差额资源释放至资源池60。

具体而言，如果用户80发起业务修改配置请求是增量配置，参实施例一所揭示的技术方案予以处理，如果80发起业务修改配置请求是缩量配置来，则需要判断修改配置请求所匹配的第二资源与第一资源进行比较，且比较是的两者资源的规模。

举例而言，在本实施例中在步骤S1中用户80在接收到缩量配置的业务修改配置请求前，云主机91在步骤S1中所确定的第一资源是CPU_1、CPU_2及CPU_3，而此时CPU_4则被视为第二资源。然后，在步骤S2中当用户80发起修改三颗CPU为两颗CPU的业务修改配置请求时(即缩量配置)，可通过图2中的资源调度模块20将作为第一资源的CPU_1、CPU_2及CPU_3中的任一CPU执行释放操作，并仅要求第二资源中包含两颗CPU(例如仅保留CPU_1与CPU_3)，则此时可将图5中的CPU_2通过图3中的释放模块30在资源调度模块20的控制下，将CPU_2释放至资源池60中。

在本实施例中，如果此时云平台接收到了其他用户(即非用户80)所发起的申请两颗CPU的业务请求时，则将CPU_2与CPU_4直接分配给新用户。由此，通过本实施例所揭示的技术方案，进一步提高了解决了在云平台所形成的资源既定的前提下因业务修改配置所导致的云主机等业务处理单元所需要的资源发生变动时多个云主机之间发生资源争夺的问题的能力，且不需要依赖现有技术中采用为云主机预设QoS等级的技术方案，实现了更为细腻的服务粒度。

本实施例所揭示的一种云平台资源动态配置方法与实施例一中相同部分的技术方案，请参实施例一所示，在此不再赘述。

实施例三：

参图2并结合图6所示，基于实施例一中相同或者类似的发明思想，本实施例揭示了一种云平台资源动态配置装置100(以下简称“装置100”)，并包括：资源调度模块20，判断模块40及检测模块10。资源调度模块20，用于确定当前云平台200中用于直接或者间接响应用户请求的业务处理单元所匹配的第一资源并获取业务修改配置请求。装置100最优选地被配置并运行于控制节点110中，当然也可将该装置100配置于云平台200中虚拟操作系统、负载均衡系统(未示出)等逻辑组件中。

检测模块10，用以对资源池60中的剩余资源进行检测并通知判断模块40。判断模块40，用以判断资源池60中的剩余资源是否满足业务修改配置请求所匹配的第二资源，并仅在资源池60中的剩余资源满足业务修改配置请求所匹配的第二资源时，通过资源调度模块20将第一资源与第二资源共同地为云平台200中接收所述业务修改配置请求所对应的业务处理单元优先进行资源配置。该业务处理单元为计算节点、网络节点、控制节点、存储节点、虚拟机、容器中的一种或者任意几种的组合。其中，第一资源与第二资源的含义及具体处理过程可配合参照实施例一及实施例二所示。检测模块10对资源池60中的各种类型的资源进行检测后，将资源池60的可用资源的种类及数量向资源调度模块20汇报，以对资源调度模块20提供对资源动态配置的决策依据。判断模块40在执行对资源池60中的剩余资源是否满足业务修改配置请求所匹配的第二资源的判断后，将判断结果发送至资源调度模块20，以对资源调度模块20提供对资源动态配置的决策依据。

本实施例中关于第一资源与第二资源的定义以及业务修改配置请求对资源的动态配置过程可结合实施例一和/或实施例二所揭示的技术方案予以理解。

实施例四：

基于实施例三中相同或者类似的发明思想，本实施例揭示了一种云平台资源动态配置装置100的一种变形实施例。

参图3所示，本实施例与实施例三和/或实施例四相比，尤其是与实施例三相比，其主要区别在于，本实施例所揭示的一种云平台资源动态配置装置100中还包括：隔离模块50，该隔离模块50用以在获取业务修改配置请求后对云平台中的其他业务处理单元所配置的资源与第二资源执行隔离。以及，释放模块30。

检测模块10对资源池60中的各种类型的资源进行检测后，将资源池60的可用资源的种类及数量向资源调度模块20汇报，以对资源调度模块20提供对资源动态配置的决策依据。判断模块40将业务修改配置请求所匹配的第二资源与第一资源进行比较，并仅在第二资源小于第一资源时，将第二资源与第一资源所形成的差额资源通过所述释放模块30释放至资源池60。隔离模块50受控于资源配置模块20并对资源池60中对应的种类的第一资源、第二资源与其他云主机所配置的资源或者其他类型的资源执行隔离操作。判断模块40在执行对资源池60中的剩余资源是否满足业务修改配置请求所匹配的第二资源的判断后，将判断结果发送至资源调度模块20，以对资源调度模块20提供对资源动态配置的决策依据，并在需要释放资源时，通知释放模块30执行释放操作。

本实施例中关于第一资源与第二资源的定义以及业务修改配置请求对资源的配置过程可结合实施例一和/或实施例二所披露的内容予以理解。在本实施例中，所谓差额资源既可以是对云主机91所在步骤S1中所确定的第一资源做增量配置所对应的资源(例如图4中的CPU_4)，也可以是对云主机91所在步骤S1中所确定的第一资源做缩量配置所对应的资源(例如图4中的CPU_2)。本实施例所揭示的一种云平台资源动态配置装置100运行实施例一或者实施例二所揭示的一种云平台资源动态配置方法，具体参上文所述。本实施例所揭示的云平台资源动态配置装置100与实施例三中相同部分的技术方案，请参实施例三所示，在此不再赘述。

实施例五：

结合图6所示，基于上述任一实施例所蕴含相同或者类似发明思想，本实施例揭示了一种云平台200。

该云平台200，包括：

至少一个计算节点90，所述计算节点90中被配置出至少一个业务处理单元，控制节点91。

控制节点91中配置如实施例二和/或实施例三所揭示的云平台资源动态配置装置100，以通过所述云平台资源动态配置装置100对业务处理单元进行资源配置。其中，业务处理单元可为计算节点、网络节点、控制节点、存储节点、云主机、容器中的一种或者任意几种的组合。如图6所示，计算节点90中形成云主机91～云主机9i(参数i取大于或者等于2的正整数)，并均可被云平台资源动态配置装置100执行资源动态配置的操作。同时，该云平台资源动态配置装置100部署于控制节点中，并可被用户80或者管理员81进行访问，并接收用户80或者管理员81发起的业务修改配置请求。同时，该云平台200可是IaaS类型的云平台，也可以是的PaaS类型的云平台或者SaaS类型的云平台。

本实施例所揭示的云平台200中所依赖的云平台资源动态配置装置100参实施例三和/或实施例四所示，且云平台资源动态配置装置100所依赖的云平台资源动态配置方法，可综合参照实施例一至实施例四所揭示的技术方案所示，在此不再赘述。

在本申请所披露的几个实施例中，本领域技术人员应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (8)

1.一种云平台资源动态配置方法，其特征在于，包括：

确定当前云平台中用于直接或者间接响应用户请求的业务处理单元所匹配的第一资源；

获取业务修改配置请求，并仅在资源池中的剩余资源满足业务修改配置请求所匹配的第二资源时，将所述第一资源与第二资源共同地为云平台中接收所述业务修改配置请求所对应的业务处理单元优先进行资源配置；

在获取业务修改配置请求后，还包括：

对云平台中的其他业务处理单元所配置的资源与第二资源执行隔离。

2.根据权利要求1所述的方法，其特征在于，对云平台中的其他业务处理单元所配置的资源执行隔离后，还包括：

检测资源池中的剩余资源是否满足业务修改配置请求所匹配的第二资源的需求，

若是，则将所述第一资源与第二资源共同地为云平台中接收该业务修改配置请求所对应的业务处理单元优先进行资源配置；

若否，则仅将所述第一资源为云平台中接收该业务修改配置请求所对应的业务处理单元进行资源配置。

3.根据权利要求1或者2所述的方法，其特征在于，还包括：将业务修改配置请求所匹配的第二资源与第一资源进行比较，并仅在第二资源小于第一资源时，将第二资源与第一资源所形成的差额资源释放至资源池。

4.根据权利要求3所述的方法，其特征在于，所述业务处理单元为计算节点、网络节点、控制节点、存储节点、虚拟机、容器中的一种或者任意几种的组合。

5.一种云平台资源动态配置装置(100)，其特征在于，包括：

资源调度模块(20)，判断模块(40)及检测模块(10)；其中，

资源调度模块(20)，用于确定当前云平台中用于直接或者间接响应用户请求的业务处理单元所匹配的第一资源并获取业务修改配置请求；

检测模块(10)，用以对资源池中的剩余资源进行检测并通知判断模块(40)；

判断模块(40)，用以判断资源池中的剩余资源是否满足业务修改配置请求所匹配的第二资源，并仅在资源池中的剩余资源满足业务修改配置请求所匹配的第二资源时，通过所述资源调度模块(20)将所述第一资源与第二资源共同地为云平台中接收所述业务修改配置请求所对应的业务处理单元优先进行资源配置；

以及隔离模块(50)，所述隔离模块(50)用以在获取业务修改配置请求后对云平台中的其他业务处理单元所配置的资源与第二资源执行隔离。

6.根据权利要求5所述的装置，其特征在于，还包括释放模块(30)，所述判断模块(40)将业务修改配置请求所匹配的第二资源与第一资源进行比较，并仅在第二资源小于第一资源时，将第二资源与第一资源所形成的差额资源通过所述释放模块(30)释放至资源池。

7.根据权利要求5所述的装置，其特征在于，所述业务处理单元为计算节点、网络节点、控制节点、存储节点、虚拟机、容器中的一种或者任意几种的组合。

8.一种云平台(200)，其特征在于，包括：

至少一个计算节点(90)，所述计算节点(90)中被配置出至少一个业务处理单元，控制节点(91)，

所述控制节点(91)中配置如权利要求5至7中任一项所述的云平台资源动态配置装置(100)，以通过所述云平台资源动态配置装置(100)对业务处理单元进行资源配置。

Images