Patent Description:
These and other problems exist in provisioning resources for cloud computing systems. <CIT> relates to a broker mechanism that allocates a plurality of servers, each having an available resource capacity, to clients for delivering one of several services to the clients. The broker operates by monitoring a subset of the available servers capable of delivering the requested service. The allocation is based on developing a network policy for the plurality of servers by collecting a local policy for each of the servers. The broker receives client requests and, based on a network policy and available resource capacity, suggests one of the servers for making a request. <CIT> describes methods for selectively or automatically migrating resources between storage operation cells. A management component within the storage operation system monitors system operation and migrates components from storage operation cell to another to facilitate failover recovery, promote load balancing within the system and improve overall system performances. Predictive analyses on system operation are performed to reveal trends and tendencies within the system, which are used as the basis for potentially migrating components from one storage operation cell to another.

The object of the present invention is to provide a method, a system, and a computer-readable medium for preventing resource allocation failures.

This object is solved by the subject-matter of the independent claims.

Embodiments of the present invention are defined by the dependent claims.

One example implementation relates to a method. The method may include receiving a resource allocation request for a new resource in a computing system, wherein the resource allocation request identifies a resource subtype of the new resource and a region for the new resource. The method may include predicting an occurrence of a capacity related allocation failure for the resource allocation request using capacity predictions derived from supply chain modeling of a capacity in the region requested. The method may include identifying a ranked list of alternate resources to use for the resource allocation request in response to the predicting of the occurrence of the capacity related allocation failure. The method may include providing at least one recommendation with the ranked list of alternate resources.

Another example implementation relates to a system. The system may include at least one memory to store data and instructions, at least one processor in communication with the at least one memory, and instructions stored in the memory, the instructions being executable by the one or more processors to: receive a resource allocation request for a new resource, wherein the resource allocation request identifies a resource subtype of the new resource and a region for the new resource; predict an occurrence of a capacity related allocation failure for the resource allocation request using capacity predictions derived from supply chain modeling of a capacity in the region requested; identify a ranked list of alternate resources to use for the resource allocation request in response to the predicting of the occurrence of the capacity related allocation failure; and provide at least one recommendation with the ranked list of alternate resources.

Another example implementation relates to a computer-readable medium storing instructions executable by a computer device. The computer-readable medium may include at least one instruction for causing the computer device to receive a resource allocation request for a new resource, wherein the resource allocation request identifies a resource subtype of the new resource and a region for the new resource. The computer-readable medium may include at least one instruction for causing the computer device to predict an occurrence of a capacity related allocation failure for the resource allocation request using capacity predictions derived from supply chain modeling of a capacity in the region requested. The computer-readable medium may include at least one instruction for causing the computer device to identify a ranked list of alternate resources to use for the resource allocation request in response to the predicting of the occurrence of the capacity related allocation failure. The computer-readable medium may include at least one instruction for causing the computer device to provide at least one recommendation with the ranked list of alternate resources.

Additional features and advantages will be set forth in the description, which follows, and in part will be obvious from the description, or may be learned by the practice of the teachings herein. Features and advantages of the disclosure may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. Features of the present disclosure will become more fully apparent from the following description and appended claims, or may be learned by the practice of the disclosure as set forth hereinafter.

The present disclosure generally relates to providing recommendations for alternate resource deployment guidance for resources to use for cloud services. Cloud platforms are experiencing growth in the demand for resources, such as virtual machines (VMs) and storage. Typically, proactive efforts, such as supply chain modeling, enable cloud services to have the necessary capacity to meet the demands of their users. However, there can be capacity related allocation failures that occur due to one or more reasons.

A capacity related allocation failure may occur in response to a resource being unavailable. Specific resources may have varying degrees of availability across all regions. In addition, legacy resources may not be available across all regions. A capacity related allocation failure may also occur in response to customers requesting an unusually large amount of a specific resource that unexpectedly reduces resource availability until new plans can address the gap. In addition, a capacity related allocation failure may occur in response to one or more business restrictions preventing allocation of resources. For example, business restrictions may be in place to prioritize existing customers preventing resource allocation for new customers.

Currently, when a capacity related allocation failure occurs, customers may receive an error message indicating an allocation failure occurred. Customers may retry a resource request and hope the request works, call support, and/or search for a deployment alternative. As such, customers may spend additional money and/or resources in attempting to find an alternate solution.

The present disclosure includes several practical applications that provide benefits and/or solve problems associated with capacity related allocation failures on a cloud computing system. The present disclosure may provide a recommendation service that receives a resource allocation request for a new resource in a computing system and may provide a confidence rating of the resource allocation request succeeding. The confidence rating may provide a prediction of the resource allocation succeeding within a time period following the resource allocation request. Customers may proceed with submitting allocation requests in response to the confidence ratings indicating that the resource allocation request will likely succeed.

The present disclosure may provide recommendations for alternate resources to use in response to the confidence ratings indicating that the resource allocation request will likely fail. The recommendations may provide a ranked list of alternate resources to use for requested resources. The recommendations may be provided in alternate regions where the requested resource subtype may be available. In addition, the recommendations may be provided for alternate resource sub-types similar to the requested resource subtype and available in the same region as the requested resource allocation request. Thus, the present disclosure may allow customers to choose whether location or resource sub-types are more important when selecting an alternate resource to use for the requested resource.

The recommendations may provide guidance for alternate resources to use and/or actions customers may take (e.g., increasing limits) to allow the resource allocation request. For example, a business policy or restriction, such as quota limits, may prevent a customer from receiving a resource allocation. The present disclosure may notify customers when a constraint prevents success of the resource allocation request and may provide one or more actions customers may take to successfully receive the resource allocation.

The present disclosure may provide customers flexibility in moving forward with a resource allocation request if another option can be substituted for the original request. For example, a customer may request a large VM in Japan when there is insufficient capacity; the recommendations may provide large VMs in Korea or medium VMs in Japan as alternatives.

The present disclosure may also show a prediction of allocation success within a specified time period to customers via various customer interfaces so that customers may proactively plan out deployments in a desired region.

The present disclosure may also use the alternate resource guidance to only show available alternate resources in any deployment tool, preventing customers from selecting unavailable resources. As such, the present disclosure may be used to proactively prevent resource allocation failures. In addition, the present disclosure may be used to show alternate resource deployment choices that closely match the original allocation request, preventing uses from wasting time and frustration in identifying alternate solutions for resource deployments in a cloud computing system.

Referring now to <FIG>, illustrated is an example environment <NUM> including a cloud computing system <NUM> for use with providing recommendations for alternate resource to use for cloud services. The cloud computing system <NUM> may include any number of devices. For example, the cloud computing system <NUM> includes one or more server device(s) <NUM> having a resource allocation system <NUM> implemented thereon.

In addition to the server device(s) <NUM>, the cloud computing system <NUM> may include any number of node clusters 108a-n. One or more of the node clusters 108a-n may be grouped by geographic location (e.g., a region of node clusters). The node clusters 108a-n may also be implemented across multiple geographic locations (e.g., at different datacenters including one or multiple node clusters).

Each of the node clusters 108a-n may include a variety of server nodes having a number and variety of compute cores thereon. In addition, one or more virtual machines may be implemented on the compute cores of the server nodes. For example, a first node cluster 108a may include a first set of server nodes 110a. Each node from the set of server nodes 110a may include one or more compute cores 112a. As further shown, some or all of the compute cores 112a may include virtual machine(s) 114a implemented thereon. The node cluster 108a may include any number and variety of server nodes 110a. In addition, the server nodes 110a may include any number and variety of compute cores 112a. Moreover, the compute cores 112a may include any number and variety of virtual machines 114a. The cloud computing system <NUM> may include multiple node clusters 108a-n including respective server nodes 110a-n, compute cores 112a-n, and virtual machines 114a-n.

The environment <NUM> may also include a plurality of client devices 116a-n in communication with the cloud computing system <NUM>. For example, the client devices 116a-n may communicate with server devices <NUM> via a network <NUM> to send one or more resource allocation requests for a new resource on cloud computing system <NUM>. The new resource may include any type of resource in a computing system. For example, the new resource may include cloud resources, such as, but not limited to, networks, virtual machines 114a-n, and/or storage. In addition, the client devices 116a-n may communicate with different server nodes 110a-n via network <NUM>. The client devices 116a-n may refer to various types of computing devices including, by way of example, mobile devices, desktop computers, server devices, or other types of computing devices. The network <NUM> may include one or multiple networks that use one or more communication platforms or technologies for transmitting data. For example, the network <NUM> may include the Internet or other data link that enables transport of electronic data between respective client devices 116a-n and devices of the cloud computing system <NUM>.

In one or more implementations, the virtual machines 114a-n correspond to one or more customers and provide access to storage space, applications, or various cloud-based services hosted by the server nodes 110a-n. For example, a virtual machine may provide access to a large-scale computation application to a first client device 116a (or multiple client devices). As another example, a different virtual machine on the same server node or a different server node (on the same or different node cluster) may provide access to a gaming application to a second client device 112b (or multiple client devices).

As will be described in further detail below, the resource allocation system <NUM> may evaluate information associated with the compute cores 112a-n to accurately determine and/or predict capacity related allocation failures of resources on the cloud computing system <NUM>. In particular, resource allocation system <NUM> may evaluate information about a specific region <NUM> to determine whether a capacity related allocation has already occurred and/or predict whether capacity related allocation failures will likely occur over a predetermined period of time (e.g., <NUM> days, <NUM> days, <NUM> days) for the region <NUM>.

In addition to determining a prediction of capacity related allocation failures that may occur on region <NUM>, resource allocation system <NUM> may also facilitate one or more recommendations for alternate resources to use for the allocation request in response to the prediction of capacity allocation failures. For example, as will be discussed in further detail below, upon identifying predicted capacity related allocation failures, resource allocation system <NUM> may provide recommendations for alternate resources to use for the resource allocation request.

As such, resource allocation system <NUM> may be used to show customers a chance of allocation success within a specified period via various user interfaces so that customers may plan out deployments in the desired region proactively.

Referring now to <FIG>, illustrated is an example resource allocation system <NUM> for use within cloud computing system <NUM>. Resource allocation system <NUM> may receive one or more resource allocation requests <NUM> for a new resource. The new virtual resource may include cloud resources, such as, but not limited to, networks, virtual machines <NUM> and/or storage for use with cloud computing system <NUM>. For example, the resource allocation requests <NUM> may be received from one or more users of client devices 116a-n (also referred throughout as customers). The resource allocation requests <NUM> may include one or more deployment parameters <NUM> for the new resource. Deployment parameters <NUM> may include, but are not limited to, a subscription identification for a customer, a selected region (e.g., a geographical region), resource subtype (e.g., an amount of random access memory (RAM), central processing units (CPUs), and/or storage requested), a number of instances (e.g., how many VMs requested), and/or region/size ranking types. In addition, deployment parameters <NUM> may include required parameters and/or optional parameters. For example, a customer may input, or otherwise select, deployment parameters <NUM>.

Resource allocation system <NUM> may use the deployment parameters <NUM> in determining whether a capacity related allocation failure will likely occur. A capacity related allocation failure may occur in response to a resource being unavailable. A capacity related allocation failure may also occur in response to customers requesting an unusually large amount of a specific resource that unexpectedly reduces resource availability until new plans can address the gap. For example, resource allocation system <NUM> may use the deployment parameters <NUM> to identify whether a requested resource is available in a requested region. In addition, a capacity related allocation failure may occur in response to one or more business restrictions preventing allocation of resources. For example, resource allocation system <NUM> may use the deployment parameters <NUM> to identify any business restrictions that may be in place to prioritize existing customers, thereby preventing resource allocation for new customers.

Resource allocation system <NUM> may include a data collection engine <NUM> that may collect or otherwise receive predicted available capacity <NUM> in a region (e.g., region <NUM>) including information about nodes, available cores for deployment, and virtual machines on the node clusters 108a-n. The predicted available capacity <NUM> in region <NUM> may include supply chain modeling of the capacity in region <NUM>. The supply chain modeling of the capacity in region <NUM> may include a combination of demand data and supply state data currently in use for the node clusters 108a-n. The demand data may include a variety of demand-related data including, but not limited to, existing customer workloads, reserved and blocked demand, virtual machine resources already deployed, reserved compute resources, blocked quota increase requests (e.g., a backlog), and/or promised quote increase in the near future (e.g., forelog). The supply state data may include the number of nodes and/or available cores for allocation. The supply state data may also include one or more expected or scheduled changes to the number of available cores. In an implementation, the predicted available capacity <NUM> in region <NUM> may include raw data associated with the demand and/or supply state of the node clusters 108an.

The predicted available capacity <NUM> in region <NUM> may include demand data and/or supply state data from node clusters 108a-n in a region corresponding to the selected region of the deployment parameters <NUM>. In addition, the predicted available capacity <NUM> in region <NUM> may include demand data and/or supply state data from node clusters 108a-n in an area surrounding and/or adjacent to the selected region of the deployment parameters <NUM>.

The predicted available capacity <NUM> in region <NUM> may enable resource allocation system <NUM> to identify a projected demand and/or supply state for region <NUM> over a predetermined duration of time (e.g., <NUM> days, <NUM> days, <NUM> days, <NUM> months, <NUM> year). The projected demand and/or supply state may include a prediction of available and/or occupied compute cores for region <NUM>.

Resource allocation system <NUM> may use the predicted available capacity <NUM> in region <NUM> to determine whether a capacity related allocation failure will likely occur that prevents the resource allocation requests <NUM> from succeeding. Resource allocation system <NUM> may generate a confidence rating <NUM> indicating a likelihood of success for the resource allocation requests <NUM> within a predetermined duration of time (e.g., the next n days, where n is an integer) using the predicted available capacity <NUM> in region <NUM> (e.g., the demand data and/or the supply state data currently in use and/or a projected demand and/or supply state).

For example, the confidence rating <NUM> may include none or low in response to predicting that a capacity related allocation failure is likely to occur for the selected resource within the selected region (e.g., the selected resource is currently unavailable in the selected region or is predicted to be unavailable in the selected region). In another example, the confidence rating <NUM> may include none in response to a restriction or other business policy preventing the resource allocation. In yet another example, the confidence rating <NUM> may include medium or high in response to predicting that a capacity related allocation failure is unlikely to occur for the selected resource within the selected region (e.g., the selected resource is available in the selected region or is predicted to be available in the selected region).

Resource allocation system <NUM> may also include a ranking engine <NUM> that identifies alternate resources <NUM> to use for the resource allocation request <NUM> in response to a determination that a capacity related allocation failure is likely to occur for the selected resource of the resource allocation request <NUM>. Alternate resources <NUM> may include, but are not limited to, alternate region resources <NUM> or alternate size resources <NUM>. Alternate region resources <NUM> may include the requested resource in a different region. For example, the requested resource may be available in a nearby geographical region or a region pair of the original requested geographical region. Alternate size resources <NUM> may include subtypes similar to the requested resource that are available in the original requested geographical region.

In an implementation, ranking engine <NUM> may generate a ranked list <NUM> of alternate resources <NUM>. The ranked list <NUM> of alternate resources <NUM> may include a plurality of alternate region resources 32a-n associated with a rank 26a-n and/or a plurality of alternate size resources 34a-n associated with a rank 26a-n. The plurality of alternate region resources 32a-n and/or the plurality of alternate size resources 34a-n may be ranked hierarchically in an order relative to one another using the associated rank 26a-n.

The ranks 26a-n may be generated by ranking engine <NUM> in response to one or more rankings of the alternate resources <NUM>. Ranking engine <NUM> may have a size ranker <NUM> to order the alternate resources <NUM> in response to comparing a requested size in the deployment parameters <NUM> of the resource allocation request <NUM> to the size of the alternate resources <NUM>. Size ranker <NUM> may identify alternate resources <NUM> with the same or similar size (e.g., same or similar amount of RAM, CPU, and/or storage) as the requested size. For example, alternate resources <NUM> with sizes similar to, or the same as, the requested size may have a higher rank relative to alternate resources <NUM> with sizes with greater differences from the requested size.

Ranking engine <NUM> may also have a region ranker <NUM> to order the alternate resources <NUM> using region. The order of the rankings may be in response to comparing a requested region in the deployment parameters <NUM> to the region of the alternate resource <NUM>. Region ranker <NUM> may identify other regions in the same geography and/or same data center as the requested region in order to identify alternate resources <NUM> nearby or close to the requested region. For example, alternate resources <NUM> in the same geographical region or a nearby geographical region may have a higher rank relative to alternate resources <NUM> in a geographical region further away from the requested geographical region.

Ranking engine <NUM> may also have one or more capacity rankers <NUM> to order the alternate resources <NUM> using available capacity of the regions of the alternate resources <NUM>. The capacity rankers <NUM> may order the alternate resources <NUM> using the available capacity and/or predicted capacity (e.g., when a region may lose capacity) of the regions of the alternate resources <NUM>. For example, alternate resources <NUM> in a geographical region predicted to have a capacity for the requested resource may have a higher ranking relative to alternate resources <NUM> in a geographical region where the requested resource is predicted to be unavailable within a number of days (e.g., one week).

Ranking engine <NUM> may add and/or remove rankers (e.g., size ranker <NUM>, region ranker <NUM>, and/or capacity ranker <NUM>) in response to business needs. In addition, ranking engine <NUM> may use any combination of size ranker <NUM>, region ranker <NUM>, and/or capacity ranker <NUM> in determining the ranked list <NUM> of alternate resources <NUM>. Each of the size ranker <NUM>, region ranker <NUM>, and/or capacity ranker <NUM> may generate an independent rank <NUM> for the alternate resources <NUM>.

In addition, ranking engine <NUM> may apply one or more weights <NUM> to the ranks <NUM> and generate a combined recommendation score for the ranks 26a-n to include in the ranked list <NUM> of alternate resources <NUM>. For example, a higher weight <NUM> may be applied for a capacity ranker and a lower weight <NUM> applied for a region ranker. Another example may include a higher weight <NUM> applied for a capacity ranker and a lower weight applied for a size ranker. As such, ranking engine <NUM> may generate a ranked list <NUM> of alternate resources <NUM> with associated ranks 26a-n ranked in an order of the highest available capacity, size most similar to the requested size, and region closest to the requested region.

Resource allocation system <NUM> may also include a restriction manager <NUM> that may apply one or more restrictions <NUM> to the ranked list <NUM> of alternate resources <NUM>. Restrictions <NUM> may prevent the resource allocation. For example, a restriction <NUM> may include a subscription plan without the quota to support the resource allocation. Another example restriction <NUM> may include a business policy that gives existing customers priority over new customers. Restriction manager <NUM> may update the ranked list <NUM> of alternate resources <NUM> in response to the restrictions <NUM>. For example, the ranked list <NUM> of alternate resources <NUM> may be updated by annotating the alternate resources <NUM> as blocked from the ranked list <NUM> of alternate resources <NUM> and/or provided with a lower rank <NUM> in response to the restrictions <NUM>.

Resource allocation system <NUM> may include a recommendation engine <NUM> that generates one or more recommendations <NUM>. For example, recommendations <NUM> may be generated in response to receiving a resource allocation request <NUM>. Recommendations <NUM> may include, for example, a confidence rating <NUM> indicating a likelihood of success for the resource allocation request <NUM>. The confidence ratings <NUM> may help customers in proceeding with resource allocation requests <NUM>. In addition, recommendations <NUM> may include, for example, alternate resources <NUM> or a ranked list <NUM> of alternate resources <NUM> that may be used for the resource allocation request <NUM>. Alternate resources <NUM> may be recommended in response to the confidence ratings <NUM> indicating that a resource allocation request <NUM> may be unsuccessful.

As such, resource allocation system <NUM> may provide users with flexibility in proceeding with resource allocation requests <NUM> when an original requested resource is unavailable and/or predicted to become unavailable within a predetermined time. In addition, resource allocation system <NUM> may provide customers with available alternate resources <NUM> to use for the resource allocation request <NUM> and may allow customers to choose whether location or resource subtype may be more important (or more desirable) for moving forward with the resource allocation requests <NUM>.

Each of the components <NUM>, <NUM>, <NUM>, <NUM> of the resource allocation system <NUM> may be in communication with each other using any suitable communication technologies. In addition, while the components <NUM>, <NUM>, <NUM>, <NUM> of the resource allocation system <NUM> are shown to be separate in <FIG>, any of the components or subcomponents may be combined into fewer components, such as into a single component, or divided into more components as may serve a particular implementation. As an illustrative example, components <NUM>, <NUM>, <NUM>, <NUM> may be implemented on different server devices of the cloud computing system <NUM>. As another illustrative example, one or more of the components <NUM>, <NUM>, <NUM>, <NUM> may be implemented on an edge computing device that is not implemented on the hierarchy of devices of the cloud computing system <NUM>.

Moreover, the components <NUM>, <NUM>, <NUM>, <NUM> of the resource allocation system <NUM> may include hardware, software, or both. For example, the components of the resource allocation system <NUM> shown in <FIG> may include one or more instructions stored on a computer-readable storage medium and executable by processors of one or more computing devices. When executed by the one or more processors, the computer-executable instructions of one or more computing devices (e.g., server device(s) <NUM>) can perform one or more methods described herein. Alternatively, the components of the resource allocation system <NUM> may include hardware, such as a special purpose processing device to perform a certain function or group of functions. Additionally, or alternatively, the components <NUM>, <NUM>, <NUM>, <NUM> of the resource allocation system <NUM> may include a combination of computer-executable instructions and hardware.

Referring now to <FIG>, an example implementation of the resource allocation system <NUM> for providing recommendations for alternate resources for use with a resource allocation request is described in connection with an example framework <NUM>. The framework <NUM> is discussed below in connection with reference to the architectures of <FIG> and <FIG>.

Client device(s) <NUM> may generate one or more resource allocation requests <NUM> with deployment parameters <NUM> for a new resource. Deployment parameters <NUM> may include required parameters, such as, but not limited to, size and region of the requested resource. Deployment parameters <NUM> may also include optional parameters, such as, but not limited to, latency requirements, region pair requests, and/or same geographical region for the requested resource. If optional parameters are provided in the deployment parameters <NUM>, ranking engine <NUM> may rank the regions of the alternate resources <NUM> as specified. If optional parameters are not specified in the deployment parameters <NUM>, ranking engine <NUM> may apply a default region ranking (e.g., low latency, region pair, same geographical region) in ranking the regions of the alternate resources <NUM>.

Ranking engine <NUM> may receive the deployment parameters <NUM> and may perform a level one ranking <NUM> of available alternate resources <NUM> using the deployment parameters <NUM>. A level one ranking <NUM> of available alternate resources <NUM> may include applying a size ranker <NUM>, a region ranker <NUM>, a first capacity ranker <NUM> and/or a second capacity ranker <NUM> to the available alternate resources <NUM>. Each of the size ranker <NUM>, region ranker <NUM>, first capacity ranker <NUM> and/or second capacity ranker <NUM> may provide independent rankings of the alternate resources <NUM>. Level one rankers (e.g., size ranker <NUM>, region ranker <NUM>, first capacity ranker <NUM>, and/or second capacity ranker <NUM>) may be added or removed from ranking engine <NUM> in response to business needs.

Size ranker <NUM> may calculate a similarity distance score between the requested size in the deployment parameters <NUM> to all other sizes of the alternate resources <NUM>. A weighted Euclidean distance measure may be used to calculate the size score for the alternate resources <NUM>. Size configuration features such as, but not limited to, cores, memory, disks may be used as features to the Euclidean distance calculator.

In an implementation, the size similarity scores may be adjusted in response to one or more domain specific rules. Examples of domain specific rules may include, the requested size, latest version of size, legacy size, premium storage, isolated node size, hyperthreaded size, VM series, or VM type. Weights may be assigned to each of the size configuration features using for example, business rules or domain knowledge, to determine an importance of the size configuration features. For example, older sizes may not be available in many regions so a lower weight may be applied to older sizes relative to newer versions of the requested size. The weights may be used to alter the final similarity ranking score of the size of the alternate resources <NUM>. Size ranker <NUM> may use the weights to artificially modify the similarity ranking score of the size of the alternate resources <NUM>. As such, size ranker <NUM> may identify sizes of alternate resources <NUM> that are closest to, or the same as, the requested size in terms of the configuration.

Region ranker <NUM> may calculate the similarity between the requested region in the deployment parameters <NUM> to regions of the alternate resources <NUM> based on, for example, data center proximity, geography, and/or region pairs. If a region ranking option is not specified, region ranker <NUM> may optimize the region rankings by ranking higher region pairs, low latency regions, and/or the same geographic locations as the requested region. If the region ranking option is specified, region ranker <NUM> may calculate the score for the region rankings by adjusting the weight based on the specified input option. For example, certain customers may prefer to stay in the same geographical region whereas other customers might prefer to be in the same region pair for redundancy. Another example may include customers that always prefer low latency, and thus, high region rankings for these customers will be in the order of the closest regions.

First capacity ranker <NUM> and/or second capacity ranker <NUM> may use the predicted available capacity <NUM> for the region as a source to rank the alternate resources <NUM> choices based on available capacity. First capacity ranker <NUM> and/or second capacity ranker <NUM> may leverage predicted days to failure, days to exhaustion, allocation failures, and/or available capacity from the predicted available capacity <NUM> from the region of the alternate resources <NUM>. Calculations performed by first capacity ranker <NUM> and/or second capacity ranker <NUM> may be based on the latest available snapshot of the predicted available capacity <NUM> for the region of the alternate resources <NUM>. In an implementation, first capacity ranker <NUM> may use the projected demand and/or supply state from the predicted available capacity <NUM> for the region for the calculations and second capacity ranker <NUM> may use the actual demand and/or supply state from the predicted available capacity <NUM> for the calculations. In an implementation, the predicted available capacity <NUM> for the region may be received from regional level capacity predication data feed.

First capacity ranker <NUM> and/or second capacity ranker <NUM> may determine the requested cores based on the size and instances requested by the customer. In an implementation, first capacity ranker <NUM> and/or second capacity ranker <NUM> may calculate the percentage of remaining cores as a function of the cores available and generate a capacity score in response to the calculation. If the percentage of remaining cores is less than <NUM>%, or if the number of allocation failures is greater than <NUM>, first capacity ranker <NUM> and/or second capacity ranker <NUM> may automatically mark the capacity score as low and the probability of a successful allocation request as low as well.

First capacity ranker <NUM> and/or second capacity ranker <NUM> may use the capacity score for ranking the alternate resources <NUM> in an order where a higher capacity score indicates a higher chance of a successful allocation request and a lower capacity score indicates a lower chance of a successful allocation request. For example, any region/size combination that has a score of <NUM> or less may be marked as a low chance of success, a score between <NUM> to <NUM> may be marked as a medium success, and a score greater than <NUM> may be marked as a high success.

Ranking engine <NUM> may generate a ranked list of alternate resources <NUM>. In an implementation, the ranked list of alternate resources <NUM> may be the same as the ranked list of alternate resources <NUM> in <FIG>. The ranked list of alternate resources <NUM> may use the independent scores or rankings from size ranker <NUM>, region ranker <NUM>, first capacity ranker <NUM>, and/or second capacity ranker <NUM> to generate the order of the alternate resources.

In addition, ranking engine <NUM> may perform a second level of ranking <NUM> on the ranked list of alternate resources <NUM>. The second level of ranking <NUM> may apply weights <NUM> to the ranked list of alternate resources <NUM> to create a combined recommendation score for each of the alternate resources <NUM> included in the ranked list of alternate resources. The weights <NUM> may be determined using a combination of machine learning and/or domain experts. For example, the highest weight <NUM> may be for capacity ranker, followed by size and then region. The output of the second level of ranking <NUM> may include a weighted ranked list of alternate resources <NUM> ranked in an order of the highest available capacity, size most similar to the requested size, and region closest to the requested region.

Restriction manager <NUM> may receive the weighted ranked list of alternate resources <NUM> and may apply one or more restrictions <NUM> and/or other business policies to further improve the list of alternatives and generate a revised ranked list of alternate resources <NUM>. An order of the alternate resources <NUM> may change in response to the restrictions <NUM> or other business policies. For example, older alternate resources <NUM> may be ranked lower than newer alternate resources <NUM> in response to a business policy to promote newer resources.

In addition, alternate resources <NUM> may be annotated, or otherwise identified, as blocked from the revised ranked list of alternate resources <NUM> if a quota limit of a customer does not allow the use of the alternate resources <NUM>. In addition, alternate resources <NUM> may be annotated as blocked from the revised ranked list of alternate resources <NUM> in response to business policies preventing the use of the alternate resources <NUM>. For example, if a business policy prevents new virtual machines in a specific region, the alternate resources <NUM> from the specific region may be blocked from the revised ranked list of alternate resources <NUM>. As such, the revised ranked list of alternate resources <NUM> may only show available options to customers to proactively prevent resource allocation failures.

A recommendation engine <NUM> may receive the revised ranked list of alternate resources <NUM> and may generate one or more recommendations <NUM>. Recommendations <NUM> may include the revised ranked list of alternate resources <NUM> for use for the resource allocation request <NUM>. In addition, recommendations <NUM> may include a confidence rating <NUM> indicating a chance of allocation success for the resource allocation request <NUM>.

Client device <NUM> may receive the one or more recommendations <NUM> and may present the recommendations <NUM> to a customer. Customers may plan out virtual resource deployments in desired regions proactively using the one or more recommendations <NUM>.

Referring now to <FIG>, an example method <NUM> may be used by resource allocation system <NUM> (<FIG> and <FIG>) for providing recommendations for alternate resources <NUM> (<FIG>) to use with a resource allocation request <NUM> (<FIG>). The actions of method <NUM> may be discussed below with reference to the architectures of <FIG>.

At <NUM>, method <NUM> may include receiving a resource allocation request for a new resource. Resource allocation system <NUM> may receive one or more resource allocation requests <NUM> for a new resource. The new resource may be any type of resource in a computing system. For example, the new resource may include cloud resources, such as, but not limited to networks, virtual machines <NUM> and/or storage for use with cloud computing system <NUM>. In one configuration, the resource allocation requests <NUM> may be received from one or more users of client devices 116a-n (e.g., customers of cloud computing system <NUM>). The resource allocation requests <NUM> may include one or more deployment parameters <NUM> for the new resource. Deployment parameters <NUM> may include, but are not limited to, a subscription identification for a customer, a selected geographical region, resource subtype (e.g., an amount of RAM, CPU, storage requested), a number of instances (e.g., how many VMs requested), and/or region/size ranking types. In addition, deployment parameters <NUM> may include required parameters (e.g., size and region) and/or optional parameters (latency preferences and/or region rankings). For example, a customer may input, or otherwise select, deployment parameters <NUM>.

At <NUM>, method <NUM> may include determining whether the resource allocation request is likely to succeed. Resource allocation system <NUM> may use the deployment parameters <NUM> in determining whether a capacity related allocation failure is likely to occur to prevent the resource allocations requests <NUM> from succeeding. A capacity related allocation failure may occur in response to a resource being unavailable. A capacity related allocation failure may also occur in response to customers requesting an unusually large amount of a specific resource that unexpectedly reduces resource availability until new plans can address the gap. In addition, a capacity related allocation failure may occur in response to one or more business restrictions.

Resource allocation system <NUM> may use the latest predicted available capacity <NUM> for the requested region in determining whether a capacity related allocation, failure may occur in the requested region for the requested resource. The predicted available capacity <NUM> for the region may include demand data and/or supply state data from node clusters 108a-n in region <NUM> corresponding to the selected region of the deployment parameters <NUM>. In addition, the predicted available capacity <NUM> for region <NUM> may include supply chain modeling of the capacity in region <NUM>. The supply chain modeling of the capacity in region <NUM> may include, for example, demand data and/or supply state data from node clusters 108a-n in region <NUM> and/or an area surrounding, or adjacent to, the selected region of the deployment parameters <NUM>.

The predicted available capacity <NUM> for region <NUM> may enable resource allocation system <NUM> to identify a projected demand and/or supply state for region <NUM> over a predetermined duration of time (e.g., <NUM> days, <NUM> days, <NUM> days, <NUM> months, <NUM> year). The projected demand and/or supply state may include a prediction of available and/or occupied compute cores for the region <NUM>.

Resource allocation system <NUM> may use the predicted available capacity <NUM> for region <NUM> to determine whether a capacity related allocation failure may occur to prevent the resource allocation requests <NUM> from succeeding. Resource allocation system <NUM> may generate a confidence rating <NUM> indicating a likelihood of success for the resource allocation requests <NUM> within a predetermined duration of time (e.g., the next n days, where n is an integer) using the predicted available capacity <NUM> for region <NUM> (e.g., the demand data and/or the supply state data currently in use and/or a projected demand and/or supply state).

For example, the confidence rating <NUM> may include none or low in response to predicting that a capacity related allocation failure is likely to occur for the selected resource within the selected region (e.g., the selected resource is currently unavailable in the selected region or is predicted to be unavailable in the selected region). In another example, the confidence rating <NUM> may include none in response to a restriction or other business policy preventing the resource allocation. In another example, the confidence rating <NUM> may include medium or high in response to predicting that a capacity related allocation failure is unlikely to occur for the selected resource within the selected region (e.g., the selected resource is available in the selected region or is predicted to be available in the selected region).

At <NUM>, method <NUM> may include providing a recommendation with a confidence rating in response to determining that the resource allocation is likely to succeed. For example, recommendation engine <NUM> may generate one or more recommendations <NUM> with a confidence rating <NUM> indicating that a capacity allocation failure is unlikely to occur for the selected resource in the selected region (e.g., a confidence rating of medium or high). Recommendations <NUM> may refer to any communication provided to customers of cloud computing system <NUM>. For example, recommendations <NUM> may be provided to customers via an email, text message, or other communication displayable via a graphical user interface of client devices <NUM>.

At <NUM>, method <NUM> may include identifying a ranked list of alternate resources to use for the resource allocation request. Resource allocation system <NUM> may identify one or more alternate resources <NUM> for use with the allocation request <NUM> in response to determining that a capacity related allocation failure is likely to occur in the selected region. Alternate resources <NUM> may include, but are not limited to, alternate region resources <NUM> or alternate size resources <NUM>. Alternate region resources <NUM> may include the requested resource in a different region. For example, the requested resource may be available in a nearby geographical region or a region pair of the original requested geographical region. Alternate size resources <NUM> may include resource subtypes like the requested resource that are available in the original requested geographical region.

In an implementation, ranking engine <NUM> may generate a ranked list <NUM> of alternate resources <NUM>. The ranked list <NUM> of alternate resources <NUM> may include a plurality of alternate region resources 32a-n associated with a rank 26a-n and/or a plurality of alternate size resources 34a-n associated with a rank 26a-n. The plurality of alternate region resources 32a-n and/or the plurality of alternate size resources 34a-n may be ranked hierarchically in an order relative to one another using the associated rank 26a-n. The ranks 26a-n may be generated by ranking engine <NUM> in response to one or more rankings of the alternate resources <NUM>.

In an implementation, ranking engine <NUM> may use deployment parameters <NUM> to perform a level one ranking of available alternate resources <NUM> using by applying one or more of a size ranker <NUM>, a region ranker <NUM>, a capacity ranker <NUM> to the available alternate resources <NUM>. A level one ranking <NUM> of available alternate resources <NUM> may include applying a size ranker <NUM>, a region ranker <NUM>, a first capacity ranker <NUM> and/or a second capacity ranker <NUM> to the available alternate resources <NUM>. Each of the size ranker <NUM>, region ranker <NUM>, first capacity ranker <NUM> and/or second capacity ranker <NUM> may provide independent rankings of the alternate resources <NUM>. Level one rankers (e.g., size ranker <NUM>, region ranker <NUM>, first capacity ranker <NUM>, second capacity ranker <NUM>) may be added or removed from ranking engine <NUM> in response to business needs.

For example, size ranker <NUM> may order the alternate resources <NUM> using size. Size ranker <NUM> may identify alternate resources <NUM> with the same or similar size (e.g., same or similar number of RAM, CPU, and/or storage) as the requested size. For example, alternate resources <NUM> with sizes similar to, or the same as, the requested size may have a higher rank relative to alternate resources <NUM> with sizes different from the requested size.

In addition, region ranker <NUM> may order the alternate resources <NUM> using region. Region ranker <NUM> may identify other geographical regions in the same geography and/or same data center as the requested region in order to identify alternate resources <NUM> nearby or close to the requested region. For example, alternate resources <NUM> in the same geographical region or a nearby geographical region may have a higher rank relative to alternate resources <NUM> in a geographical region further away from the requested geographical region.

Capacity rankers <NUM>, <NUM> may order the alternate resources <NUM> using an available capacity of the regions of the alternate resources <NUM>. The capacity rankers <NUM>, <NUM> may order the alternate resources <NUM> using the available capacity and/or predicted capacity (e.g., when a region may lose capacity) of the regions of the alternate resources <NUM>. For example, alternate resources <NUM> in a geographical region predicted to have capacity for the requested resource may have a higher ranking relative to alternate resources <NUM> in a geographical region where the requested resource is predicted to be unavailable within a number of days (e.g., one week).

In an implementation, ranking engine <NUM> may perform a second level of ranking on the ranked list <NUM> of alternate resources <NUM>. The second level of ranking may apply weights <NUM> to the ranked list of alternate resources <NUM> to create a combined score for the ranks associated with the alternate resources <NUM>. The weights <NUM> may be determined using a combination of machine learning and/or domain experts. For example, the highest weight <NUM> may be for capacity ranker, followed by size and then region. The output of the second level of ranking may include a weighted ranked list of alternate resources <NUM>. The alternate resources <NUM> may be ranked in an order relative to one another using the associated ranks, where the order is based on the highest available capacity, size most similar to the requested size, and region closest to the requested region.

At <NUM>, method <NUM> may optionally include updating the ranked list of alternate resources by applying one or more restrictions. Restriction manager <NUM> may receive the weighted ranked list of alternate resources <NUM> and may apply one or more restrictions <NUM> or other business policies to further improve the list of alternatives and generate a revised ranked list of alternate resources <NUM>. An order of the alternate resources <NUM> may change in response to the restrictions <NUM> or other business policies. For example, older alternate resources <NUM> may be ranked lower than newer alternate resources <NUM> in response to a business policy to promote newer resources.

In addition, alternate resources <NUM> may be annotated as blocked from the revised ranked list of alternate resources <NUM>, or otherwise prevented from inclusion on the revised ranked list of alternate resources <NUM>, if a quota limit of a customer does not allow the use of the alternate resources <NUM>. In addition, alternate resources <NUM> may be blocked from the revised ranked list of alternate resources <NUM> in response to business policies preventing the use of the alternate resources <NUM>. For example, if a business policy prevents new virtual machines in a specific region, the alternate resources <NUM> from the specific region may be annotated as blocked from the revised ranked list of alternate resources <NUM>. As such, the revised ranked list of alternate resources <NUM> may only include available options to customers to proactively prevent resource allocation failures.

At <NUM>, method <NUM> may include providing a recommendation with the ranked list of alternate resources. A recommendation engine <NUM> may receive the revised ranked list of alternate resources <NUM> and may generate one or more recommendations <NUM>. Recommendations <NUM> may include the revised ranked list of alternate resources <NUM> for use for the resource allocation request <NUM>. In addition, recommendations <NUM> may include a confidence rating <NUM> indicating a chance of allocation success for the resource allocation request <NUM>.

Method <NUM> may be used to show a prediction of allocation success within a specified time period to customers via various customer interfaces so that customers may proactively plan out deployments in a desired region. Method <NUM> may also provide customers flexibility in moving forward with a resource allocation request if another option may be substituted for the original request.

The computer system <NUM> includes a processor <NUM>. The processor <NUM> may be a general-purpose single or multi-chip microprocessor (e.g., an Advanced RISC (Reduced Instruction Set Computer) Machine (ARM)), a special purpose microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, etc. The processor <NUM> may be referred to as a central processing unit (CPU). Although just a single processor <NUM> is shown in the computer system <NUM> of <FIG>, in an alternative configuration, a combination of processors (e.g., an ARM and DSP) could be used.

The computer system <NUM> also includes memory <NUM> in electronic communication with the processor <NUM>. The memory <NUM> may be any electronic component capable of storing electronic information. For example, the memory <NUM> may be embodied as random access memory (RAM), read-only memory (ROM), magnetic disk storage mediums, optical storage mediums, flash memory devices in RAM, on-board memory included with the processor, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) memory, registers, and so forth, including combinations thereof.

A computer system <NUM> may also include one or more input devices <NUM> and one or more output devices <NUM>. Some examples of input devices <NUM> include a keyboard, mouse, microphone, remote control device, button, joystick, trackball, touchpad, and lightpen. Some examples of output devices <NUM> include a speaker and a printer. One specific type of output device that is typically included in a computer system <NUM> is a display device <NUM>. Display devices <NUM> used with implementations disclosed herein may utilize any suitable image projection technology, such as liquid crystal display (LCD), light-emitting diode (LED), gas plasma, electroluminescence, or the like. A display controller <NUM> may also be provided, for converting data <NUM> stored in the memory <NUM> into text, graphics, and/or moving images (as appropriate) shown on the display device <NUM>.

The techniques described herein may be implemented in hardware, software, firmware, or any combination thereof, unless specifically described as being implemented in a specific manner. Any features described as modules, components, or the like may also be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be realized at least in part by a non-transitory processor-readable storage medium comprising instructions that, when executed by at least one processor, perform one or more of the methods described herein. The instructions may be organized into routines, programs, objects, components, data structures, etc., which may perform particular tasks and/or implement particular data types, and which may be combined or distributed as desired in various implementations.

The steps and/or actions of the methods described herein may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is required for proper operation of the method that is being described, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.

Additionally, it should be understood that references to "one implementation" or "an implementation" of the present disclosure are not intended to be interpreted as excluding the existence of additional implementation s that also incorporate the recited features. For example, any element or feature described in relation to an implementation herein may be combinable with any element or feature of any other implementation described herein, where compatible.

Claim 1:
A method, comprising:
receiving (<NUM>) a resource allocation request for a new resource in a computing system, wherein the resource allocation request identifies a resource subtype of the new resource and a region for the new resource;
predicting (<NUM>) an occurrence of a capacity related allocation failure for the resource allocation request using capacity predictions derived from supply chain modeling of a capacity in the region requested;
identifying (<NUM>) a ranked list of alternate resources (<NUM>) to use for the resource allocation request in response to the predicting of the occurrence of the capacity related allocation failure; and
providing (<NUM>) at least one recommendation (<NUM>) with the ranked list of alternate resources, wherein the at least one recommendation (<NUM>) comprises a confidence rating of the occurrence of the capacity related allocation failure, wherein the confidence rating is based on one or more restrictions preventing the resource allocation request.