Cloud resource allocation method and electronic device

Abstract

One or more embodiments of the present specification provide a cloud resource allocation method and electronic device, wherein the method includes: selecting a target supply request with the highest request priority contained in a request queue for processing, wherein the request priority of any supply request contained in the request queue is related to its attribute priority, and the attribute priority of any supply request matches the request attribute of any supply request; if the target supply request is successfully processed, the target cloud resource applied for by the target supply request is allocated to the initiator of the target supply request, and the target supply request is removed from the request queue.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of computer networks, and more particularly, to a cloud resource allocation method and electronic device. Background Art

[0002] In cloud resource allocation scenarios, cloud platforms allocate cloud resources to users by receiving cloud resource supply requests submitted by users. However, cloud resource allocation is currently implemented through spot trading, where cloud platforms sell pre-prepared cloud resources and allocate them to users after they submit supply requests. This results in users having to rush to purchase scarce cloud resources, causing inconvenience. Summary of the Invention

[0003] In view of this, one or more embodiments of this specification provide a cloud resource allocation method and an electronic device.

[0004] One or more embodiments of this specification provide the following technical solutions:

[0005] According to a first aspect of one or more embodiments of this specification, a cloud resource allocation method is proposed, including:

[0006] selecting a target supply request with the highest request priority contained in a request queue for processing, wherein the request priority of any supply request contained in the request queue is related to its attribute priority, and the attribute priority of any supply request matches the request attribute of any supply request;

[0007] In the case that the target provisioning request is successfully processed, the target cloud resources applied for by the target provisioning request are allocated to the initiator of the target provisioning request, and the target provisioning request is removed from the request queue.

[0008] According to a second aspect of one or more embodiments of this specification, an electronic device is provided, including:

[0009] A processor; a memory for storing processor-executable instructions; wherein the processor implements the steps of the above-mentioned cloud resource allocation method by running the executable instructions.

[0010] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the specification and, together with the description, serve to explain the principles of the specification.

[0012] Figure 1 This is a schematic diagram of a network architecture for cloud resource allocation provided in this specification according to an exemplary embodiment.

[0013] Figure 2 This is a flowchart of a cloud resource allocation method provided in this specification according to an exemplary embodiment.

[0014] Figure 3 This is a schematic diagram of a request queue according to an exemplary embodiment of this specification.

[0015] Figure 4 This is a schematic diagram of a scenario for processing a target provisioning request according to an exemplary embodiment provided in this specification.

[0016] Figure 5 It is a structural diagram of a device provided by an exemplary embodiment.

[0017] Figure 6 This is a block diagram of a cloud resource allocation device provided in this specification according to an exemplary embodiment. DETAILED DESCRIPTION

[0018] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of one or more embodiments of this specification, as detailed in the appended claims.

[0019] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0020] Figure 1 This is a schematic diagram of a network architecture for cloud resource allocation provided by an exemplary embodiment. Figure 1As shown, in the embodiment of this specification, the subject that maintains and allocates cloud resources is the cloud platform, and the subject to which cloud resources are allocated may include a client outside the cloud platform or an operation and maintenance system inside the cloud platform. Taking the cloud platform allocating cloud resources to the client as an example, the cloud platform and the client on the user side are connected through a network (such as the public network), so that the cloud platform can respond to the supply request for cloud resources issued by the client and allocate cloud resources to the client. In the embodiment of this specification, the cloud platform allocates cloud resources to the client, specifically refers to allocating the right to use the cloud resources to the corresponding client. For example, the client can log in to the cloud platform through an account registered on the cloud platform. The cloud platform can bind the cloud resources it maintains to the identity identifier corresponding to the client, thereby specifying the right to use the cloud resources to the client, and displaying the cloud resources in the console interface displayed after the client locally logs in to the cloud platform, in response to the client's various use or configuration operations on the cloud resources.

[0021] The cloud resources involved in the embodiments of this specification refer to virtual cloud devices that are instantiated on the cloud platform and are in a usable state, including cloud instances, cloud resource pools, and cloud private pools, etc., wherein cloud instances include cloud servers, cloud disks, cloud applications, or virtual network elements in cloud networks, etc. Since the essence of a cloud platform is to elastically maintain and integrate physical hardware resources, the cloud platform needs to be connected to a large number of hardware entities to maintain a basic cloud resource space. The cloud resource space involved in the embodiments of this specification refers to the general term for computing resources, storage resources, and / or network resources used to implement cloud resources. In essence, it is an abstract representation of the computing resources, storage resources, and / or network resources contained in the hardware entities. The realization (or instantiation) of cloud resources in the cloud resource space refers to the process of cloud resources occupying and instantiating the cloud resource space to obtain available virtual cloud devices. In essence, it is the on-demand fragmented occupation of hardware entities.

[0022] Figure 2 This is a flowchart of a cloud resource allocation method provided in this specification according to an exemplary embodiment, the method comprising the following steps:

[0023] S202: Select the target supply request with the highest request priority contained in the request queue for processing, wherein the request priority of any supply request contained in the request queue is related to its attribute priority, and the attribute priority of any supply request matches the request attribute of any supply request.

[0024] The cloud resource allocation method involved in the embodiments of this specification can be applied to Figure 1The cloud platform shown. For example, the cloud platform will dynamically maintain a request queue for caching multiple supply requests received, and sort these supply requests in order of request priority, and then process the supply requests in the request queue in order of request priority from high to low. Since the inventory of cloud resources is limited, if multiple supply requests are processed in parallel, it may result in the multiple supply requests processed in parallel requiring application for the same cloud resources that are in short supply. Since the processing of multiple supply requests processed in parallel is invisible to each other, this will inevitably lead to the same cloud resource being simultaneously competed for by multiple supply requests, or the same cloud resource space being separately reserved by multiple supply requests, and ultimately leading to the failure of processing of multiple supply requests processed in parallel. The embodiment of this specification can avoid the above situation by processing the supply requests in the request queue in order of request priority from high to low in a serial manner.

[0025] In the embodiments of this specification, since the processing of supply requests takes time, and the cloud platform can continuously receive new supply requests and add them to the request queue, the request queue usually contains a large number of supply requests that have not yet been processed. Among them, any supply request has a corresponding request priority, and the request priority can be determined by the attribute priority corresponding to the any supply request. Specifically, the request priority of any supply request is positively correlated with its attribute priority. For example, the request priority of any supply request can be directly determined as the attribute priority of the any supply request itself.

[0026] The attribute priority of any supply request involved in the embodiments of this specification is determined by the request attribute of any supply request. The request attribute of any supply request includes the request source and / or request requirement of any supply request, wherein the request source of any supply request refers to the initiator corresponding to any supply request, for example, the initiator of any supply request may include the operation and maintenance system of the cloud platform itself, the client corresponding to the registered user outside the cloud platform, other platforms, etc.; the request requirement of any supply request includes the delivery requirement, batch requirement and the type and quantity of cloud resources required to be applied for of any supply request. Delivery requirements include two different delivery methods: one is full delivery, which specifically refers to allocating all cloud resources required for any supply request to the initiator of any supply request before the delivery time of any supply request. If all cloud resources cannot be allocated to the initiator at the delivery time, the processing of any supply request is considered to have failed, and no cloud resources will be allocated to the initiator; the other is best-effort delivery, which specifically refers to the fact that even if all cloud resources required by the initiator of any supply request cannot be allocated to the initiator of any supply request at the delivery time of any supply request, the processing of any supply request is considered to have succeeded, and the initiator will be allocated as much of the cloud resources required by any supply request as possible. Batch demand refers to whether the cloud resources required for any supply request are delivered all at once at the delivery time, or delivered multiple times in batches over a certain period of time. Cloud resource types include cloud instances, cloud resource pools, and cloud private pools, or specific cloud instances such as cloud servers. The delivery time of any supply request involved in the embodiments of this specification refers to the time when the cloud resources required for any supply request must be allocated, or the time when a request processing failure notification is returned to the initiator due to the inability to allocate cloud resources.

[0027] The above-mentioned request requirements may be specified by the initiator of any supply request when initiating the supply request, or may be determined by the cloud platform itself according to the request source of any supply request.

[0028] In one embodiment, the cloud platform pre-sets a correspondence between request attributes and attribute priorities. This correspondence is called a cloud resource provisioning scenario. Therefore, each time the cloud platform receives a new provisioning request, it first determines the request attributes of the provisioning request and matches them to a cloud resource provisioning scenario containing the request attributes. Finally, the provisioning request is assigned the attribute priorities contained in the matched cloud resource provisioning scenario. For example, the following cloud resource provisioning scenarios can be configured:

[0029] Scenario 1: The attribute priority for a provisioning request originating from the cloud platform's internal operations and maintenance system is 10. Scenario 2: The attribute priority for a provisioning request originating from a client external to the cloud platform is 5. After configuring the above cloud resource provisioning scenarios, if the cloud platform receives a new provisioning request from the cloud platform's internal operations and maintenance system, scenario 1 will be matched, and the attribute priority for the provisioning request will be set to 10. If the cloud platform receives a new provisioning request from an external client, scenario 2 will be matched, and the attribute priority for the provisioning request will be set to 5.

[0030] Optionally, the target supply request with the highest request priority contained in the request queue is selected for processing, including: from the multiple supply requests with the highest request priority contained in the request queue, the target supply request with the earliest corresponding initiation time is selected for processing. In an embodiment of the present specification, for multiple supply requests with the same request priority contained in the request queue, they will be processed in order from early to late according to the corresponding initiation times of the multiple supply requests. In this way, the ones with the same request priority but earlier initiation time can be processed first. The initiation time of any supply request involved in the embodiment of the present specification may refer to: the time when any supply request is initiated by its initiator, the time when any supply request is acquired by the cloud platform, or the time when any supply request is first / most added to the request queue.

[0031] S204: If the target provisioning request is successfully processed, the target cloud resources applied for by the target provisioning request are allocated to the initiator of the target provisioning request, and the target provisioning request is removed from the request queue.

[0032] In one embodiment, when the initiator of the target supply request initiates the target supply request, the target cloud resource has been instantiated and maintained on the cloud platform. At this time, when the cloud platform processes the target supply request, it can determine whether the target supply request is successfully processed by checking whether the target cloud resource is available, and if the target supply request is successfully processed, the use right of the target cloud resource is granted to the initiator; in another embodiment, when the initiator initiates the target supply request, the target cloud resource has not yet been instantiated. At this time, when the cloud platform processes the target supply request, it can check whether the current cloud resource space of the cloud platform supports instantiation of at least part of the target cloud resource, and if the current cloud resource space can instantiate at least part of the target cloud resource, it can determine that the target supply request is successfully processed, and use the target cloud resource space reserved for realizing the target cloud resource to instantiate at least part of the target cloud resource and grant the use right of the target cloud resource to the initiator. In the embodiment of this specification, any supply request will be removed from the request queue if it is successfully processed, so as to ensure that the cloud resources that have been successfully allocated will not be allocated repeatedly.

[0033] In the embodiment of the present specification, if the target provisioning request fails to be processed, the target provisioning request will be re-added to the request queue but will not be removed from the request queue.

[0034] In the embodiments of this specification, the initiator corresponding to the default target provisioning request is the demander of the target cloud resources, so the target cloud resources can be directly allocated to the initiator. However, in other embodiments, the target provisioning request will additionally specify the demander, which can be different from the initiator. Then, when the target cloud resources are allocated, they will not be allocated to the initiator but to the demander.

[0035] The embodiment of this specification sets up a request queue and processes each supply request contained therein in order of request priority from high to low, and if the target supply request is successfully processed, the target cloud resource applied for by the target supply request is allocated to the initiator of the target supply request, so that the process of the initiator applying for cloud resources and the process of allocating cloud resources to the initiator are decoupled in time, but it can ensure that all supply requests can be processed. As a result, the initiator does not need to pay attention to the current inventory status of cloud resources when initiating a supply request for cloud resources, thereby avoiding the phenomenon that the initiator cannot normally apply for cloud resources due to tight or out-of-stock cloud resource inventory, and realizes a new cloud resource allocation method such as booking cloud resources. In addition, since the request priority of any supply request contained in the request queue is related to its attribute priority, the attribute priority of any supply request matches the request attribute of any supply request, so the correspondence between the request attribute and the attribute priority can be fully utilized to distinguish the processing order of different supply requests, and realize supply request processing based on request attributes to adapt to different cloud resource allocation scenarios.

[0036] Optionally, the request priority of any provisioning request is also related to its time priority, where:

[0037] For multiple supply requests with the same time priority, the supply request with a relatively higher attribute priority also has a relatively higher request priority;

[0038] For multiple supply requests with different time priorities, a supply request with a relatively higher time priority has a relatively higher request priority.

[0039] In the embodiments of this specification, the request priority of any supply request will be determined by its corresponding attribute priority and time priority. Moreover, through the above-mentioned request priority determination rules, it can be inferred that: a supply request with a relatively higher time priority must be processed in priority to a supply request with a relatively lower time priority, and for each supply request with the same time priority, it is processed in descending order of attribute priority. In the embodiments of this specification, supply requests that are in a time-critical state are always processed with higher priority, so as to maximize the success rate of the initiator's application for cloud resources and reduce the initiator's waiting time, thereby improving the initiator's experience.

[0040] by Figure 3 For example, Figure 3This is a schematic diagram of a request queue shown in accordance with an exemplary embodiment of this specification. In this figure, the supply requests contained in the request queue are arranged from top to bottom in the order of request priority from high to low. Obviously, the first-level sub-queue containing all supply requests with a time priority of time priority 10 (called the first-level sub-queue with time priority 10) should be arranged above the first-level sub-queue with time priority 9. And for the first-level sub-queue with time priority 10, the second-level sub-queue containing all supply requests with an attribute priority of attribute priority 10 (called the second-level sub-queue with time priority 10 and attribute priority 10) should be arranged above the second-level sub-queue with time priority 10 and attribute priority 9. The cloud platform will process the supply requests one by one in order from top to bottom. For example, in Figure 3 In the example, supply request 1 at the head of the second-level sub-queue with time priority 10 and attribute priority 10 will be processed first as the target supply request with the highest request priority. After supply request 1 is processed, new target supply requests, namely supply request 2, supply request 3 and supply request 4, will be selected and processed in sequence. If the second-level sub-queue with time priority 10 and attribute priority 10 does not contain any supply request, the cloud platform will start to execute the supply request in the second-level sub-queue with time priority 10 and attribute priority 9, and so on.

[0041] Optionally, the time priority of any supply request is positively correlated with the waiting time of any supply request, which is the time between the initiation moment of any supply request and the current moment; and / or, the time priority of any supply request is negatively correlated with the expiration time of any supply request, which is the time between the current moment and the delivery moment of any supply request.

[0042] In the embodiments of this specification, the time priority of any supply request will be positively correlated with the time urgency of any supply request. The time urgency of any supply request involved in the embodiments of this specification is specifically determined by the waiting time and / or expiration time of any supply request, and the time urgency of any supply request is positively correlated with the waiting time of any supply request, and the time urgency of any supply request is negatively correlated with the expiration time of any supply request. For example, in the case where the degree of time urgency is jointly determined by the waiting time and the expiration time, the degree of time urgency can be expressed as the ratio between the waiting time and the expiration time in a unified unit. For example, the units of the waiting time and the expiration time can include seconds, minutes, hours, days, etc. This specification does not impose any restrictions on this. As shown in Table 1, Table 1 shows the correspondence between different time urgency states and different time priorities.

[0043] Waiting time / expiration time (time-sensitive status) Time priority 20 and above 10 15～20 9 12～15 8 10～12 7 8～10 6 6～8 5 4～6 4 2～4 3 1～2 2 0～1 1

[0044] Table 1

[0045] For example, for a supply request that has just been added to the request queue, the ratio of its waiting time to its expiration time is close to 0, so its time priority will be determined as time priority 1. However, for a supply request whose waiting time has just exceeded its expiration time, since its ratio of waiting time to expiration time is between 1 and 2, its time priority needs to be adjusted to time priority 2.

[0046] The timing for updating the time priority of each supply request contained in the request queue can be periodic or under fixed conditions. For example, after processing any of the supply requests, the time priority of the current supply request is updated based on the waiting time and / or expiration time of the current supply request currently contained in the request queue.

[0047] Optionally, also include:

[0048] After processing the target supply request, updating the attribute priority of the supply request currently included in the request queue so that the updated attribute priority of any supply request is positively correlated with the waiting time of any supply request and / or negatively correlated with the expiration time of any supply request;

[0049] The waiting time for any supply request is the time between the initiation time of any supply request and the current time, and the expiration time for any supply request is the time between the current time and the delivery time of any supply request.

[0050] In this embodiment, the time priority dimension is not introduced. Instead, the processing order of different supply requests is adjusted solely by dynamically adjusting the attribute priorities of different supply requests. After each supply request is processed, regardless of the processing outcome, the attribute priorities of all supply requests in the request queue are updated. For example, a pre-maintained relationship between waiting time intervals and attribute priority increments can be established, as shown in Table 2.

[0051] Waiting time (unit: hours) The increase in priority relative to the initial attribute 0～10 0 10～20 1 20 and above 3

[0052] Table 2

[0053] Assuming that a supply request has just been added to the request queue and its initial attribute priority is attribute priority 5, then within the first 10 hours after the supply request has been added to the request queue, the attribute priority of the supply request will remain unchanged; if the supply request has not been processed after more than 10 hours, the attribute priority of the supply request will be increased by 1 level, that is, the attribute priority of the supply request will be upgraded to attribute priority 6; and if the supply request has not been processed after 20 hours, the attribute priority of the supply request will be increased by 3 levels based on the initial attribute priority, that is, it will be updated to attribute priority 8.

[0054] Through the above embodiment, provisioning requests that are in a time-critical state can be processed with priority, thereby increasing the application success rate as much as possible, reducing the waiting time of the initiator, and improving the initiator's experience.

[0055] Optionally, the method further includes: lowering the attribute priority of the target supply request if the target supply request fails to be processed. In this embodiment of the present specification, the target supply request fails to be processed, including: the delivery requirement included in the request attribute of the target supply request is full delivery and the target cloud resource space cannot be used to fully realize the target cloud resources; or the delivery requirement included in the request attribute of the target supply request is best delivery and the target cloud resource space cannot be used to realize at least part of the target cloud resources. In the event of any supply request failure, the supply request will not be immediately removed from the request queue, but will continue to remain in the request queue with the attribute priority lowered, waiting to be processed next time. Only if the supply request fails to be processed and the delivery time of the supply request exceeds the current time, the supply request will be removed from the request queue and a notification of request processing failure will be returned to the initiator of the supply request. By lowering the attribute priority of the target supply request when it fails to be processed and re-adding it to the request queue, the same supply request can be processed multiple times, thereby improving the success rate of supply request processing. At the same time, it also prevents the failed supply request from repeatedly occupying processing resources for a long time, which hinders the processing efficiency of other supply requests.

[0056] Optionally, the method further includes: recording the number of times any supply request fails to be processed; if the number of times any supply request fails exceeds a preset threshold, lowering the attribute priority of any supply request to a preset priority, or removing any supply request from the request queue. In the embodiments of this specification, if a supply request fails to be processed too many times, it means that the probability of successful processing of the supply request is very low. In this case, its attribute priority can be lowered to the lowest priority, or it can be directly removed from the request queue, thereby preventing supply requests that have failed to be processed multiple times from repeatedly occupying processing resources for a long time, thereby hindering the processing efficiency of other supply requests.

[0057] Optionally, the method further includes: obtaining a new supply request for applying for cloud resources, and determining an attribute priority of the new supply request according to a request attribute of the new supply request; and adding the new supply request to the request queue.

[0058] As previously mentioned, the cloud platform can receive new supply requests from various initiators at any time, match them to corresponding attribute priorities based on their request attributes, and then add them to the request queue, thereby implementing the functionality of adding new supply requests to the request queue and queuing them. Because adding supply requests and processing supply requests are two independent processes, initiators do not need to be aware of the supply request processing process and can easily initiate new supply requests at any time.

[0059] Optionally, selecting the target supply request with the highest request priority contained in the request queue for processing includes:

[0060] Selecting the target provisioning request with the highest request priority from the request queue, determining a target cloud resource space for realizing at least part of the target cloud resources from the idle cloud resource space, and removing the target cloud resource space from the idle cloud resource space; or

[0061] The target provisioning request with the highest request priority is selected from the request queue, and the target cloud resource space currently used to realize other cloud resources is reserved from the cloud resource space in use, so that the target cloud resource space is used to realize at least part of the target cloud resources after releasing the other cloud resources.

[0062] In the embodiments of this specification, the default cloud platform currently does not maintain ready-made instantiated and available target cloud resources, but needs to gradually generate a target cloud resource space for realizing the target cloud resources in the process of processing the target provisioning request, and then, when the target cloud resources need to be allocated to the initiator, first instantiate at least part of the corresponding target cloud resources in the target cloud resource space, and then allocate the use rights of the target cloud resources to the initiator.

[0063] Figure 4 This is a schematic diagram of a scenario for processing a target provisioning request according to an exemplary embodiment of the present specification. Figure 4 As shown, the cloud platform maintains cloud resource space for realizing cloud resources. The cloud resource space can be divided into three categories: idle cloud resource space, in-use cloud resource space, and reserved cloud resource space. Among them, idle cloud resource space refers to the available cloud resource space that can be collected in the current cloud platform and is neither reserved nor in use. In-use cloud resource space refers to the cloud resource space that has been used to instantiate running cloud resources. Reserved cloud resource space refers to the cloud resource space used to prepare the cloud resources required for each unsuccessful supply request in the request queue. Once any supply request is successfully processed, the cloud resource space corresponding to the said supply request in the reserved cloud resource space will be used to realize at least part of the cloud resources required for the said supply request, and at the same time, the cloud resource space used to realize at least part of the cloud resources will be moved to the in-use cloud resource space.

[0064] For the target provisioning request, it will also maintain a corresponding target cloud resource space in the reserved cloud resource space, so as to instantiate the target cloud resource when the target cloud resource space is successfully processed. When processing the target provisioning request, the corresponding target cloud resource space can be reserved in two different ways. For example, a portion of the idle cloud resource space can be selected from the idle cloud resource space as the existing cloud resource space in the target cloud resource space and added to the target cloud resource space, while removing this portion from the idle cloud resource space. Alternatively, a portion of the cloud resource space currently being used to implement other cloud resources can be selected from the currently being used cloud resource space and reserved as the reserved cloud resource space in the target cloud resource space and added to the target cloud resource space, so that after the portion of the cloud resource space releases the other cloud resources, it is converted into the existing cloud resource space in the target cloud resource space. In the embodiment of this specification, the above-mentioned other cloud resources have a release moment. When the current moment reaches the release moment, the other cloud resources will be released, and the portion of the cloud resource space originally used to implement the other cloud resources will be assigned to the existing cloud resource space. In particular, when the cloud resource type of the other cloud resources is the same as the cloud resource type of the target cloud resources, there is no need to release the other cloud resources. Instead, the usage rights of the other cloud resources are directly adjusted to the initiator of the target supply request, thereby realizing a seamless inheritance allocation method and greatly improving the allocation efficiency of cloud resources.

[0065] It should be noted that for the cloud resource space currently in use, the same portion of the cloud resource space can only be reserved by one provision request. For example, after the aforementioned portion of the cloud resource space is reserved by the target provision request and becomes the reserved cloud resource space in the target cloud resource space, it can no longer be reserved by other provision requests. If the target provision request is successfully processed, the target cloud resource space will be triggered to realize the target cloud resources. However, since only the existing cloud resource space is available, even if the above-mentioned realization of the target cloud resources is triggered, it is necessary to wait until the reserved cloud resource space is completely converted into the existing cloud resource space before realizing the corresponding target cloud resources based on the existing cloud resource space.

[0066] In the embodiments of this specification, target cloud resource space can be reserved from idle cloud resource space or cloud resource space in use, so as to ultimately achieve target cloud resources. Not only is the idle cloud resource space fully utilized, but the cloud resource space in use is also reserved, so as to tap into as much currently available or subsequently available cloud resource space as possible and increase the utilization rate of the cloud resource space.

[0067] Optionally, determining a target cloud resource space for realizing at least part of the target cloud resources from the idle cloud resource space includes:

[0068] Determining, from the idle cloud resource space, a newly added cloud resource space for realizing at least a portion of the target cloud resources to be realized, wherein the target cloud resources to be realized are at least a portion of the target cloud resources that cannot be realized by the target cloud resource space at present;

[0069] The newly added cloud resource space is merged into the target cloud resource space, so that the merged target cloud resource space is also used to realize at least part of the target cloud resources to be realized.

[0070] The step of reserving the target cloud resource space currently used to implement other cloud resources from the currently used cloud resource space includes:

[0071] Reserving new cloud resource space currently used to realize other cloud resources from the currently used cloud resource space, so that the new cloud resource space is used to realize at least part of the target cloud resources to be realized after releasing the other cloud resources, wherein the target cloud resources to be realized are at least part of the target cloud resources that cannot be realized by the target cloud resource space currently;

[0072] The newly added cloud resource space is merged into the target cloud resource space, so that the merged target cloud resource space is also used to realize the at least part of the target cloud resources to be realized after releasing the other cloud resources.

[0073] like Figure 4As shown, each time a target supply request is processed, new cloud resource spaces can be mined from idle cloud resource spaces and / or in-use cloud resource spaces based on the last target supply request, and merged into the target cloud resource space, so that the cloud resource space obtained after the merger can realize the newly added parts of the target cloud resources that the target cloud resource space before the merger could not realize. For example, the target cloud resource space before the merger can only realize 10 cloud servers, but by merging the newly added cloud resource spaces, the target cloud resource space after the merger can realize 15 cloud servers. Through the embodiments of this specification, more target cloud resource spaces can be reserved each time a target supply request is processed, so that it is possible to finally reserve a target cloud resource space that can fully realize the target cloud resources by processing the target supply requests multiple times.

[0074] Optionally, the temporary release duration of the other cloud resources does not exceed the expiration duration of the target supply request. The temporary release duration of the other cloud resources is the duration between the current moment and the release moment of the other cloud resources, and the expiration duration of the target supply request is the duration between the current moment and the delivery moment of the target supply request. To ensure that the reserved cloud resource space can be converted into existing cloud resource space before the delivery moment of the target supply request and further realize the target cloud resources, in this embodiment of the specification, the temporary release duration of the other cloud resources cannot exceed the expiration duration of the target supply request.

[0075] Optionally, the target provisioning request is successfully processed, including:

[0076] The delivery requirement included in the request attribute of the target provisioning request is full delivery and the target cloud resource space is used to fully realize the target cloud resources; or

[0077] The delivery requirement included in the request attributes of the target provisioning request is best-effort delivery, and the target cloud resource space is used to realize at least part of the target cloud resources.

[0078] In the present embodiment, the method for determining whether the request is successfully processed is different for different delivery requirements of the target provisioning request. If the delivery requirement of the target provisioning request is full delivery, it is necessary to ensure that the target cloud resource space is used to fully realize the target cloud resources in order to consider the target provisioning request processed successfully. Otherwise, the target provisioning request is considered to have failed. For example, if the target cloud resources required for the target provisioning request are 20 cloud servers, and the target cloud resource space reserved during the processing of the target provisioning request can only realize 10 cloud servers, then the target provisioning request will be considered to have failed. If the delivery requirement of the target provisioning request is maximum delivery, it is only necessary to ensure that the target cloud resource space can be used to realize part of the target cloud resources in order to consider the target provisioning request processed successfully. For example, if the target cloud resources required for the target provisioning request are 20 cloud servers, and the target cloud resource space reserved during the processing of the target provisioning request can only realize 10 cloud servers, then the target provisioning request will also be considered to have failed, and these 10 cloud servers will be further allocated to the initiator of the target provisioning request.

[0079] In an embodiment of the present specification, if the target provision request is removed from the request queue without being successfully processed, it is declared that the processing of the target provision request has completely failed. At this time, the previously reserved target cloud resource space needs to be released, so that the existing cloud resource space and the reserved cloud resource space in the target cloud resource space are returned to the idle cloud resource space or the cloud resource space in use respectively.

[0080] The cloud resource allocation method of the present application will be described in detail below in conjunction with a cloud server sales scenario. In the embodiment of this specification, the supply request is specifically a pre-order order for applying for a cloud server, which is initiated by a client corresponding to the user and submitted to the cloud platform.

[0081] In the embodiments of the present specification, users can use various payment strategies to settle the pre-order. For example, a user can make a prepayment for the pre-order when initiating the pre-order. In this case, if the pre-order is successfully processed, the cloud platform will immediately allocate the cloud server requested for the pre-order to the user. If the pre-order fails to be processed, a refund will be made based on the user's prepayment. Alternatively, the user can authorize the cloud platform to pay the amount required for the pre-order before initiating the pre-order. If the pre-order is successfully processed, the cloud platform will automatically collect payment based on the user's granted payment authority to settle the pre-order and allocate the cloud server requested for the pre-order to the user after the payment is successfully collected. Alternatively, the user can simply initiate the pre-order. Once the pre-order is successfully processed, the cloud platform will send a notification to the user's client indicating that the pre-order has been successfully processed, along with a payment notification for the pre-order. After receiving the notification and notification, the user will need to manually make payment on the corresponding payment page on the client to settle the pre-order. Finally, the cloud platform will allocate the corresponding cloud server to the user after confirming that the pre-order has been successfully settled.

[0082] Taking the example of a user completing the corresponding prepayment when initiating a pre-order order, after receiving the pre-order order submitted by the client, the cloud platform first determines the request attributes of the pre-order order, including the request source and the request requirements configured by the user. For example, the user can configure the following request requirements for the pre-order order: "Delivery requirement: full delivery; allocation requirement: one-time delivery; cloud resource type and quantity: 10 cloud servers". Then the cloud platform will match the pre-set cloud resource supply scenario based on the request attributes of the pre-order order. For example, the above pre-order order can be matched to the pre-set cloud resource supply scenario of "the request source is an external client of the cloud platform, the delivery requirement is full delivery, the allocation requirement is one-time delivery, the cloud resource type is cloud server and the quantity is within 10 (including 10) and the attribute priority of the pre-order order is attribute priority 7", so that the attribute priority of the pre-order order is determined to be attribute priority 7.

[0083] Each pre-order order has a unique request ID. The cloud platform maintains a binding relationship between each request ID and the corresponding pre-order order initiator. Assuming that the request ID of the above pre-order order is "001", then after assigning attribute priority to the pre-order order, the cloud platform will further assign the pre-order order a time priority of 1, which is the lowest time priority level, and add the pre-order order to the end of the queue in the first-level sub-queue of time priority 1 and the second-level sub-queue of attribute priority 7 in the request queue, and queue it for processing. The pre-order orders in the entire request queue are processed serially in descending order of request priority. Since the request priority is set so that pre-orders with higher time priority are always higher than pre-orders with lower time priority, and pre-orders with higher attribute priority are always higher than pre-orders with lower attribute priority under the same time priority, if the time priority of the pre-order is not updated, the pre-orders in the secondary sub-queue with time priority 1 and attribute priority 7 need to wait until there are no pre-orders with higher time priority than 1 in the current request queue, and there are no pre-orders with higher attribute priority than 7 in the primary sub-queue with time priority 1 before they will start to be processed from the head of the secondary sub-queue.

[0084] After processing each pre-order, the cloud platform updates the time priority of each pre-order in the request queue. Specifically, the updated time priority of each pre-order is determined based on the waiting time and / or expiration time of each pre-order. For example, after a period of time in the request queue, the pre-order with request ID "001" may have its time priority updated to time priority 2. Therefore, it will be removed from the secondary sub-queue with time priority 1 and attribute priority 7 and re-added to the end of the secondary sub-queue with time priority 2 and attribute priority 7 in the request queue.

[0085] If a pre-order with the request identifier "001" is not successfully processed, it will be re-added to the request queue and await the next processing. Each time a pre-order with the request identifier "001" is processed, cloud resource space for implementing cloud servers will be reserved from the cloud platform's cloud resource space. For example, during a certain processing process, cloud resource space for implementing one cloud server can be sorted out from the idle cloud resource space. This portion of cloud resource space will be reserved for the pre-order with the request identifier "001" and added to the cloud resource space corresponding to it in the reserved cloud resource space. This cloud resource space is bound to the request identifier "001". Assuming that the cloud resource space corresponding to "001" can originally instantiate five cloud servers, then through this processing of the pre-order with the request identifier "001", the cloud resource space corresponding to "001" can now instantiate six cloud servers. For another example, during a certain processing, the cloud resource space currently in use contains cloud resource space for implementing other cloud resources that are about to be released. This portion of cloud resource space may also be reserved for the cloud resource space "001" by the pre-order "001", so that this portion of cloud resource space can be used to implement two cloud servers after the release of the other cloud resource space. Therefore, as long as the existing cloud resource space and the reserved cloud resource space in the cloud resource space corresponding to "001" are combined to implement 10 cloud servers, it can be considered that the pre-order "001" meets the delivery requirements for full delivery. Then, after the other cloud resources in the reserved cloud resource space are released and fully converted into existing cloud resource space before the delivery time, the processing can be declared successful in the next processing. The existing cloud resource space is then used to instantiate 10 cloud servers. After the initiator of the pre-order "001" is determined and the prepayment is completed, the use rights of the 10 cloud servers are allocated to the user, and a message notification of the successful pre-order is sent to the user. The user can then control the 10 cloud servers through the console on the client.

[0086] Finally, because the pre-order "001" was successfully processed, it needs to be removed from the request queue to avoid duplicate processing, thus completing the entire process of pre-ordering the cloud server. Through the embodiments of this specification, users who need to purchase cloud servers do not have to wait for stocks to be available before rushing to buy them. Instead, they can participate in the queue in the form of pre-orders, and after the cloud platform can sort out enough cloud resource space, the corresponding pre-order orders will be processed in the order of request priority to provide users with the required cloud servers, avoiding the situation where users cannot rush to buy cloud servers. At the same time, by setting attribute priority and time priority, it ensures that users can obtain cloud servers in a timely manner while adapting to different cloud resource allocation scenarios, which is more humane and improves user experience.

[0087] Corresponding to the embodiments of the aforementioned method, this specification also provides embodiments of an apparatus, an electronic device, and a storage medium.

[0088] Figure 5 This is a schematic structural diagram of a device provided by an exemplary embodiment. Figure 5 At the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, a memory 508, and a non-volatile memory 510. Of course, it may also include hardware required for other functions. One or more embodiments of this specification can be implemented based on software, such as the processor 502 reading the corresponding computer program from the non-volatile memory 510 into the memory 508 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0089] like Figure 6 As shown, Figure 6 This is a block diagram of a cloud resource allocation device provided by this specification according to an exemplary embodiment. The device can be applied to Figure 5 In the device shown, to implement the cloud resource allocation solution involved in this specification, the device may include:

[0090] a request processing unit 601 configured to select a target provisioning request with the highest request priority from a request queue for processing, wherein the request priority of any provisioning request in the request queue is related to its attribute priority, and the attribute priority of any provisioning request matches the request attribute of any provisioning request;

[0091] The cloud resource allocation unit 602 is configured to allocate the target cloud resources applied for by the target provision request to the initiator of the target provision request and remove the target provision request from the request queue if the target provision request is successfully processed.

[0092] Optionally, the request processing unit 601 is specifically configured to:

[0093] From the multiple supply requests with the highest request priority contained in the request queue, the target supply request with the earliest corresponding initiation time is selected for processing.

[0094] Optionally, the request priority of any supply request is positively correlated with its attribute priority.

[0095] Optionally, the request priority of any provisioning request is also related to its time priority, where:

[0096] For multiple supply requests with the same time priority, the supply request with a relatively higher attribute priority also has a relatively higher request priority;

[0097] For multiple supply requests with different time priorities, a supply request with a relatively higher time priority has a relatively higher request priority.

[0098] Optional,

[0099] The time priority of any supply request is positively correlated with the waiting time of any supply request, and the waiting time of any supply request is the time between the initiation time of any supply request and the current time; and / or,

[0100] The time priority of any supply request is negatively correlated to the expiration time of any supply request, and the expiration time of any supply request is the time between the current moment and the delivery moment of any supply request.

[0101] Optionally, the request processing unit 601 is specifically configured to:

[0102] The target supply request with the highest request priority is selected from the request queue, a target cloud resource space for realizing at least part of the target cloud resources is determined from the idle cloud resource space, and the target cloud resource space is removed from the idle cloud resource space.

[0103] Optionally, the request processing unit 601 is specifically configured to:

[0104] Determining, from the idle cloud resource space, a newly added cloud resource space for realizing at least a portion of the target cloud resources to be realized, wherein the target cloud resources to be realized are at least a portion of the target cloud resources that cannot be realized by the target cloud resource space at present;

[0105] The newly added cloud resource space is merged into the target cloud resource space, so that the merged target cloud resource space is also used to realize at least part of the target cloud resources to be realized.

[0106] Optionally, the request processing unit 601 is specifically configured to:

[0107] The target provisioning request with the highest request priority is selected from the request queue, and the target cloud resource space currently used to realize other cloud resources is reserved from the cloud resource space in use, so that the target cloud resource space is used to realize at least part of the target cloud resources after releasing the other cloud resources.

[0108] Optionally, the request processing unit 601 is specifically configured to:

[0109] Reserving new cloud resource space currently used to realize other cloud resources from the currently used cloud resource space, so that the new cloud resource space is used to realize at least part of the target cloud resources to be realized after releasing the other cloud resources, wherein the target cloud resources to be realized are at least part of the target cloud resources that cannot be realized by the target cloud resource space currently;

[0110] The newly added cloud resource space is merged into the target cloud resource space, so that the merged target cloud resource space is also used to realize the at least part of the target cloud resources to be realized after releasing the other cloud resources.

[0111] Optionally, the temporary release duration of the other cloud resources does not exceed the expiration duration of the target supply request. The temporary release duration of the other cloud resources is the duration between the current moment and the release moment of the other cloud resources, and the expiration duration of the target supply request is the duration between the current moment and the delivery moment of the target supply request.

[0112] Optionally, the target provisioning request is successfully processed, including:

[0113] The delivery requirement included in the request attribute of the target provisioning request is full delivery and the target cloud resource space is used to fully realize the target cloud resources; or

[0114] The delivery requirement included in the request attributes of the target provisioning request is best-effort delivery, and the target cloud resource space is used to realize at least part of the target cloud resources.

[0115] Optionally, also include:

[0116] a priority updating unit 603 configured to update the attribute priority of the supply requests currently included in the request queue after processing the target supply request, so that the updated attribute priority of any supply request is positively correlated with the waiting time of any supply request and / or negatively correlated with the expiration time of any supply request;

[0117] The waiting time for any supply request is the time between the initiation time of any supply request and the current time, and the expiration time for any supply request is the time between the current time and the delivery time of any supply request.

[0118] Optionally, also include:

[0119] The priority reducing unit 604 is configured to reduce the attribute priority of the target provisioning request if the processing of the target provisioning request fails.

[0120] Optionally, also include:

[0121] a failure count recording unit 605, configured to record the number of times any provisioning request fails to be processed;

[0122] The failed request processing unit 606 is configured to, when the number of failures of any supply request exceeds a preset threshold, reduce the attribute priority of any supply request to a preset priority, or remove any supply request from the request queue.

[0123] Optionally, also include:

[0124] A new request acquisition unit 607 is configured to acquire a new provision request for applying for cloud resources and determine an attribute priority of the new provision request according to a request attribute of the new provision request;

[0125] The adding queue unit 608 is configured to add the newly added supply request to the request queue.

[0126] Accordingly, this specification also provides a device, which includes a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement the steps of the cloud resource allocation method provided in all the above method embodiments.

[0127] Accordingly, this specification also provides a computer-readable storage medium having executable instructions stored thereon; wherein, when the instructions are executed by a processor, the steps of the cloud resource allocation method provided in all the above method embodiments are implemented.

[0128] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0129] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0130] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0131] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0132] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0133] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0134] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0135] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "an," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0136] It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when..." or "when..." or "in response to determining."

[0137] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included in the scope of protection of one or more embodiments of this specification.

Claims

1. A cloud resource allocation method, characterized in that: include: selecting a target supply request with the highest request priority contained in a request queue for processing, wherein the request priority of any supply request contained in the request queue is related to its attribute priority, and the attribute priority of any supply request matches the request attribute of any supply request; If the target provisioning request is successfully processed, allocating the target cloud resources applied for by the target provisioning request to the initiator of the target provisioning request, and removing the target provisioning request from the request queue; The selecting the target supply request with the highest request priority contained in the request queue for processing includes: Selecting the target provisioning request with the highest request priority from the request queue, determining a target cloud resource space for realizing at least part of the target cloud resources from the idle cloud resource space, and removing the target cloud resource space from the idle cloud resource space; or The target provisioning request with the highest request priority is selected from the request queue, and the target cloud resource space currently used to realize other cloud resources is reserved from the cloud resource space in use, so that the target cloud resource space is used to realize at least part of the target cloud resources after releasing the other cloud resources.

2. The method according to claim 1, characterized in that The request priority of any supply request is positively correlated with its attribute priority.

3. The method according to claim 1, characterized in that The request priority of any provisioning request is also related to its time priority, where: For multiple supply requests with the same time priority, the supply request with a relatively higher attribute priority also has a relatively higher request priority; For multiple supply requests with different time priorities, a supply request with a relatively higher time priority has a relatively higher request priority.

4. The method according to claim 3, characterized in that The time priority of any supply request is positively correlated with the waiting time of any supply request, and the waiting time of any supply request is the time between the initiation time of any supply request and the current time; and / or, The time priority of any supply request is negatively correlated to the expiration time of any supply request, and the expiration time of any supply request is the time between the current moment and the delivery moment of any supply request.

5. The method according to claim 1, wherein The determining of a target cloud resource space for realizing at least part of the target cloud resources from the idle cloud resource space includes: Determining, from the idle cloud resource space, a newly added cloud resource space for realizing at least a portion of the target cloud resources to be realized, wherein the target cloud resources to be realized are at least a portion of the target cloud resources that cannot be realized by the target cloud resource space at present; The newly added cloud resource space is merged into the target cloud resource space, so that the merged target cloud resource space is also used to realize at least part of the target cloud resources to be realized.

6. The method according to claim 1, characterized in that The step of reserving the target cloud resource space currently used to implement other cloud resources from the currently used cloud resource space includes: Reserving new cloud resource space currently used to realize other cloud resources from the currently used cloud resource space, so that the new cloud resource space is used to realize at least part of the target cloud resources to be realized after releasing the other cloud resources, wherein the target cloud resources to be realized are at least part of the target cloud resources that cannot be realized by the target cloud resource space currently; The newly added cloud resource space is merged into the target cloud resource space, so that the merged target cloud resource space is also used to realize the at least part of the target cloud resources to be realized after releasing the other cloud resources.

7. The method according to claim 1, characterized in that The temporary release duration of the other cloud resources does not exceed the expiration duration of the target supply request. The temporary release duration of the other cloud resources is the duration between the current moment and the release moment of the other cloud resources, and the expiration duration of the target supply request is the duration between the current moment and the delivery moment of the target supply request.

8. The method according to any one of claims 1, 5-7, characterized in that The target provisioning request is successfully processed, including: The delivery requirement included in the request attribute of the target provisioning request is full delivery and the target cloud resource space is used to fully realize the target cloud resources; or The delivery requirement included in the request attributes of the target provisioning request is best-effort delivery, and the target cloud resource space is used to realize at least part of the target cloud resources.

9. The method according to claim 1, characterized in that Also includes: In the event that the target provisioning request fails to be processed, the attribute priority of the target provisioning request is lowered.

10. The method according to claim 1, characterized in that Also includes: Recording the number of times any provisioning request fails to be processed; In the case that the number of failures of any provisioning request exceeds a preset threshold, the attribute priority of any provisioning request is reduced to a preset priority, or any provisioning request is removed from the request queue.

11. The method according to claim 1, wherein Also includes: Obtaining a new provisioning request for applying for cloud resources, and determining an attribute priority of the new provisioning request according to a request attribute of the new provisioning request; The newly added supply request is added to the request queue.

12. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 1 to 11 by running the executable instructions.

Images