Centralized control for computing resource management

Abstract

A method and system for centralized capacity management that matches resources of a cloud computing environment to requests for the resources of the cloud computing environment using a common provisioning-demand matching (SDM) logic framework. A global cloud inventory availability system (144, 201) may: access the SDM logic framework; matching the resource to the request according to the SDM logic framework (234) based at least in part on a preamble time associated with the resource (112) and the request (122); receiving capacity planning signals from a plurality of capacity management subsystems (142, 202) assigned to perform different capacity management action types; and for each capacity planning signal, transmitting an indication of the matched resources and requests associated with the capacity planning signal to a capacity management subsystem from which the capacity planning signal is transmitted.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a continuation of U.S. patent application No. 17 / 745,166 filed on May 16, 2022, the disclosure of which is hereby incorporated by reference herein. Background Art

[0002] In a cloud computing network, it is necessary to track and manage computing resource availability and forecast inventory to meet both current user demand and future user demand. Tracking and managing available computing resources can be used to avoid stockouts, which refers to the rejection of a demand for VM creation due to a lack of available resources in the target VM location.

[0003] For example, a capacity management system can accommodate user demand, such as projects, and rebalance the supply, such as available computing resources, according to a predefined set of supply-demand matching (SDM) rules. SDM rules can define various actions according to corresponding scenarios, such as rebalancing capacity between clusters in response to increased user demand, directing demand in response to resource surplus, adjusting the configuration of computing resource groups in response to increased or decreased demand, and the like.

[0004] However, as the size of cloud computing networks grows, matching incoming demand with available supply becomes increasingly complex. Typically, a cloud computing network may include multiple network subsystems, each of which includes its own separate capacity management system. This creates multiple records of incoming demand and available capacity, and there is no single source of truth for the entire system. Additionally, supply movement control may not be aware of incoming demand, or vice versa.

[0005] In addition, separate capacity management systems may apply different SDM rule sets in order to achieve different goals. For example, a subsystem tasked with handling an impending demand signal may operate according to one SDM rule set that considers both current demand and current supply, while another subsystem responsible for rebalancing inventory may operate according to a different SDM rule set that considers only current supply. This makes synchronization between subsystems difficult. For example, continuing with the example of two subsystems, each subsystem may utilize different actions to solve the same scenario. For example, a subsystem that handles demand signals may solve the current excess supply by diverting incoming demand toward the location of the excess supply, while a subsystem that balances inventory may solve the same excess supply by diverting the excess supply toward the location of less available supply.

[0006] Furthermore, existing capacity management systems that track the availability of virtual machines define machine interchangeability based on domains, whereby when a machine is available in a domain, there is available inventory. However, this definition does not take into account that some VM types cannot utilize available machines. Therefore, even when there are available machines in the VM's assigned domain, out-of-stock errors may occur if the available machines cannot be utilized by the VM type. Summary of the invention

[0007] The present disclosure resolves conflicts in capacity management by centralizing capacity management in a central system that communicates with other capacity management subsystems. The central system stores one or more common frameworks for matching supply and demand with each other and communicating such rules and matching results with the subsystems. The present disclosure describes a method and system for centralized capacity management for matching resources of a cloud computing environment with requests for resources of the cloud computing environment using a common supply-demand matching (SDM) logical framework. A global cloud inventory availability system can: access the SDM logical framework; match resources with requests based at least in part on lead times associated with resources and requests according to the SDM logical framework; receive capacity planning signals from multiple capacity management subsystems assigned to perform different types of capacity management actions; and for each capacity planning signal, transmit indications of matched resources and requests associated with the capacity planning signal to the capacity management subsystem from which the capacity planning signal was sent.

[0008] In one aspect of the present disclosure, a method includes: receiving, by one or more processors, supply signaling and demand signaling indicating one or more changes in an inventory of available computing resources in a cloud computing environment; updating, by one or more processors, a record of the inventory of available computing resources in response to the supply signaling and the demand signaling; receiving, by one or more processors, a first capacity planning signal from a first capacity management subsystem and a second capacity planning signal from a second capacity management subsystem, the first capacity management subsystem being assigned to perform a first capacity management action type and the second capacity management subsystem being assigned to perform a second capacity management action type different from the first capacity management action type; applying, by one or more processors, a common supply-demand matching (SDM) logic to each of the first capacity planning signal and the second capacity planning signal; transmitting, by one or more processors, a first capacity management signal to the first capacity management subsystem, the first capacity management signal indicating a first action of the first capacity management action type to be performed based on the common SDM logic; and transmitting, by one or more processors, a second capacity management signal to the second capacity management subsystem, the second capacity management signal indicating a second action of the second capacity management action type to be performed based on the common SDM logic.

[0009] In some examples, each of the first capacity management action type and the second capacity management action type can be selected from the group consisting of: reserving computing resource inventory for predicted demand; determining pool size for domains of the cloud computing environment; moving computing resource inventory between domains of the cloud computing environment; moving projects between domains of the cloud computing environment; and moving demand for computing resource inventory between domains of the cloud computing environment.

[0010] In some examples, one or more changes in the inventory of available computing resources indicated by the supply signaling and the demand signaling may include at least one of central processing unit (CPU) capacity, random access memory (RAM) size, or solid-state drive (SSD) size, and the SDM logic may match demand to supply based at least in part on one or more changes in the inventory of available computing resources indicated by the supply signaling and the demand signaling.

[0011] In some examples, the shared SDM logic may include SDM rules that include, but are not limited to, at least one of: packing locations to reduce fragmentation of stored data; requiring supply signaling to be matched with demand on a first-come, first-served basis; avoiding reserved inventory from being counted against currently available capacity; applying multipliers to locations where available resources are over-allocated to reduce the likelihood of allocating further resources; applying cost-efficiency weighting to available capacity based on machine type; and avoiding a single virtual machine (VM) being split across multiple machines.

[0012] In some examples, the provisioning signaling may further indicate a provisioning lead time for new computing resource inventory to become available in the cloud computing environment, the record of available computing resource inventory may include recording the lead time, and the demand signaling may be associated with a demand lead time indicating when new demand will be received.

[0013] In some examples, the common SDM logic can be configured to match the supply signaling with the demand signaling based at least in part on the supply lead time and the demand lead time.

[0014] In some examples, the common SDM logic can be configured to match imminent demand with currently available computing resources and to match predicted demand with future available computing resources.

[0015] In some examples, each of the supply lead time and the demand lead time can be selected from multiple lead time categories, and the lead time categories can include at least: approaching lead time, which indicates immediately available computing resources and immediate computing resource demand, respectively; reserved lead time, which indicates incoming computing resources that will be available on the order of a few days and predicted computing resource demand that will be received on the order of a few days, respectively; and in-transit lead time, which indicates incoming computing resources that will be available on the order of a few weeks and predicted computing resource demand that will be received on the order of a few weeks, respectively.

[0016] In some examples, for provisioning signaling indicating a transit lead time, the provisioning signaling may further indicate a supplier of the incoming computing resources, and the amount of the incoming computing resources that will be available on the order of weeks may be estimated based at least in part on historical performance data for the supplier.

[0017] In some examples, the provisioning signaling may indicate a VM type, and the common SDM logic may be configured to match the provisioning signaling with the demand signaling based at least in part on a mapping between the VM type and compatible machine types.

[0018] Another aspect of the present disclosure relates to a system comprising: a memory storing a supply-demand matching (SDM) logical framework for matching resources of a cloud computing environment with requests for resources of the cloud computing environment, each of the resources and the requests including an indication of a lead time; and one or more processors of a global cloud inventory availability system, the one or more processors being configured to: access the SDM logical framework; match resources with requests based at least in part on the lead time according to the SDM logical framework; receive a plurality of corresponding capacity planning signals from a plurality of capacity management subsystems, wherein each capacity management subsystem is assigned to perform a different capacity management action type; and for each capacity planning signal, transmit an indication of the matched resources and requests associated with the capacity planning signal to the capacity management subsystem from which the capacity planning signal was sent.

[0019] In some examples, multiple action types can be selected from the group consisting of: reserving computing resource inventory for predicted demand; determining pool size for domains of a cloud computing environment; moving computing resource inventory between domains of a cloud computing environment; moving projects between domains of a cloud computing environment; and moving demand for computing resource inventory between domains of a cloud computing environment.

[0020] In some examples, the one or more processors may be configured to match resources to requests further based on at least one of computing capacity, storage capacity, or virtual machine (VM) type.

[0021] In some examples, the SDM logical framework may include at least one of: packing rules for reducing fragmentation of stored data; VM integrity rules for ensuring that VMs are not scheduled across multiple machines of resources of a cloud computing environment; queuing rules for resolving requests on a first-come, first-served basis; reservation rules for ensuring that reserved resources are not counted toward the available capacity of the cloud computing environment; or cluster rules for moving requests between units of a shared cluster of the cloud computing environment.

[0022] In some examples, the SDM logical framework may include at least three of packing rules, VM integrity rules, queuing rules, reservation rules, and clustering rules.

[0023] In some examples, the lead time for a resource may indicate the time when the resource becomes available in the cloud computing environment, and the lead time for a request may indicate when an item included in the request will be executed.

[0024] In some examples, one or more processors may be configured to: match resources having proximate lead times with requests having proximate lead times; match resources having ready-to-reserve lead times with requests having ready-to-reserve lead times; and transmit indications of the matched resources and requests having proximate lead times and ready-to-reserve lead times to one or more capacity management subsystems configured to perform one of short-term supply shaping or short-term demand steering.

[0025] In some examples, one or more processors may be configured to: match resources having in-transit lead times with requests having in-transit lead times; and transmit indications of the matched resources and requests having in-transit lead times to one or more capacity management subsystems configured to perform one of long-term supply shaping or long-term demand forecasting.

[0026] In some examples, one or more processors may be configured to determine a confidence level for delivery of a resource with an in-transit lead time based on suppliers that deliver resources with in-transit lead times and historical performance data for the suppliers.

[0027] In some examples, the memory may include a mapping between multiple VM types and multiple machine platforms, and the one or more processors may be configured to match resources to requests further based on the mapping according to the SDM logical framework. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 is a block diagram of an example system according to aspects of the present disclosure.

[0029] Figure 2 yes Figure 1A block diagram of an example computing system is included in the examples of FIG.

[0030] Figure 3 is a block diagram of example data flow through subsystems of an example system according to aspects of the present disclosure.

[0031] Figure 4 is a flow diagram of an example centralized capacity management routine according to aspects of the present disclosure. DETAILED DESCRIPTION Overview

[0032] The present disclosure provides a global cloud inventory availability (GCIA) system to serve as an authoritative source of supply and demand information. The GCIA system can communicate with subsystems of a capacity management system to ensure that the subsystems operate on the same supply and demand information. In addition, the GCIA system includes an SDM engine that applies a comprehensive set of rules to manage existing and future inventory so as to avoid conflicting actions between subsystems. A subsystem can communicate an SDM request to the GCIA system, and the GCIA system can return an SDM decision to the requesting subsystem. Since the SDM decision returned to each subsystem in the subsystem is determined according to the same SDM logic, the actions taken by each subsystem in the subsystem can be consistent with each other.

[0033] In order to support supply and demand signaling from each of the subsystems of the capacity management system, the SDM logic of the GCIA system can be configured to support currently available and predicted supply and demand flows. This can be accomplished by the GCIA system by classifying both supply and demand signaling according to lead time. In other words, the GCIA system can distinguish between inventory that will be available soon and inventory that will take longer to become available, and can distinguish between imminent demand and predicted demand. This allows the GCIA system to match supply signaling with demand signaling based on supply and demand with matching lead times. In other words, GCIA can specify inventory that is immediately available to meet immediate needs for computing resources, and can specify inventory that will be available at a future time to meet predicted demand spikes at a future time. Incorporating lead time into SDM rules can improve the efficiency of SDM because currently available supply does not need to be reserved for future demand, but can be allocated to imminent demand.

[0034] The GCIA system also operates by classifying incoming inventory by machine type rather than machine domain. This allows SDM rules to match the VM type of demand signaling with the machine type or platform type of available inventory. By mapping VM types to machine types, it is ensured that the GCIA system will specify machines that can be utilized by the matching VM type. This avoids potential stock-out scenarios due to a mismatch between VM type and machine type.

[0035] Overall, the GCIA system provides a single, authoritative source for capacity planning subsystems to query for inventory availability. This allows inventory availability to be updated in a streamlined manner, meaning that each subsystem is relying on the latest availability information and the same availability information as other capacity planning subsystems. The GCIA system also provides more efficient inventory allocation because allocation is based in part on the lead time of both inventory and demand. The GCIA system also provides a more granular definition of inventory interchangeability so that demand is appropriately matched with compatible inventory. Example System

[0036] Figure 1 An example system 100 is illustrated that includes one or more inventory management devices 110 that provide supply signaling 112 via a network connection 125, and one or more client devices 120 that provide demand signaling via the network connection 125. The system 100 further includes one or more cloud-based devices 130 for computing, storage, or both. The system 100 further includes a capacity management system 140 that is communicatively connected to each of the inventory management devices 110, the client devices 120, and the cloud computing environment 130 via the network 125. The capacity management system 140 can receive the supply signaling 112 and the demand signaling 122 and configure the cloud computing environment 130 based on the supply signaling 112 and the demand signaling 122. Configuring the cloud computing environment 130 can involve virtually clustering certain devices 130 together, assigning or reassigning devices between virtual clusters, and assigning or reassigning tasks and data sets between devices 130.

[0037] Cloud computing environment 130 may include various physical machines, such as servers, processors, storage arrays, etc. The computing capacity, storage capacity, or both of the physical machines may be used to create virtual machine (VM) instances 132. VM instances 132 may be used to store and process data according to instructions in demand signaling 122. Figure 1 134 and can be used to create additional VM instances, or to increase the capacity of existing VM instances 132.

[0038] Physical devices may be added to or removed from the cloud computing environment 130 at any given time. Examples of physical devices being subtracted from the available capacity 134 may include a server being offline for maintenance, a storage array becoming damaged, and the like. Examples of physical devices being added to the available capacity 134 may include any computing device hardware being installed and integrated into the system 100 in order to expand the overall capacity of the system 100. The capacity management system 140 may be notified of added or removed physical devices via provisioning signaling 112 received from one or more inventory management devices 110. For example, the inventory management device 110 may include entries regarding purchase orders for new machines for the cloud computing environment 130, maintenance operations on existing machines of the cloud computing environment 130, and the like.

[0039] The capacity management system 140 may include a plurality of capacity management subsystems 142 for managing the configuration of the cloud computing environment 130. Configuring the cloud computing environment 130 may involve supply steering, such as moving available cloud computing inventory between virtually assigned cells or clusters to meet changes in demand for cloud computing inventory. Additionally or alternatively, configuring the cloud computing environment 130 may involve demand steering, such as moving items or data sets between VM instances 132, such as towards clusters and zones where available capacity 134 exists.

[0040] Each capacity management subsystem 142 may be arranged to handle different aspects of configuring the cloud computing environment 130. Thus, each subsystem may receive a different set of inputs and may provide a different set of outputs depending on its respective role in the capacity management system 140. For example, one subsystem 142 may be tasked with supply guidance and may receive a supply signaling stream to balance the VM capacity within the system 100 based on the supply guidance. By further example, another subsystem 142 may be tasked with demand guidance and may receive a demand signaling stream to evenly distribute demand across the VM capacity of the system 100. Supply guidance and demand guidance may be beneficial to operating the system so that failures such as stock-outs may be avoided. This article combines Figure 3 An example of capacity management subsystem 142 is described in further detail.

[0041] The capacity management system 140 further includes a global cloud inventory availability (GCIA) system 144. The GCIA system 144 is in communication with each of the capacity management subsystems 142. The GCIA system 144 can assist each of the capacity management subsystems 142 in determining how to manage the cloud computing environment 130, including both supply management and demand management. The GCIA system 144 includes a supply / demand matching (SDM) engine 146 that receives input from each of the capacity management subsystems 142 and processes the input according to a common set of SDM rules. The SDM rules can set uniform parameters and criteria that each of the capacity management subsystems 142 must follow so that two capacity management subsystems 142 do not take conflicting actions based on the same or similar set of inputs. Communication between GCIA system 144 and capacity management subsystem 142 whereby after SDM matching engine 146 processes a set of inputs from capacity management subsystem 142, a set of instructions may be output to capacity management subsystem 142 to instruct capacity management subsystem 142 to take actions according to SDM rules.

[0042] Figure 2 Examples include Figure 1 A block diagram of features of an example capacity management system 200 of the capacity management system 140 of FIG. Figure 1 As with the example capacity management system 140, Figure 2 The capacity management system 200 includes both a GCIA system 201 and a plurality of capacity management subsystems. For clarity, Figure 2 Only a single capacity management subsystem 202 is shown in FIG. 2 , but it should be understood that any number of capacity management subsystems may be included in the capacity management system 200 .

[0043] GCIA system 201 may include one or more processors 210 and memory 220. Also, capacity management subsystem 202 may include one or more processors 250 and memory 260. Although the processors and memory are shown as being completely separate from each other, in some examples, the two blocks may share some or all processors, some or all memory, or any combination thereof.

[0044] The processors 210, 250 may be well-known processors or other lesser-known types of processors. Alternatively, the processors 210, 250 may be dedicated controllers, such as application-specific integrated circuits (ASICs).

[0045] The memory 220, 260 may store information accessible by the processor 210, 250, including: data 230, 270 that may be retrieved, manipulated, or stored by the processor; instructions 240, 280 that may be executed by the processor 210, 250; or a combination thereof. The memory 220, 260 may be a type of non-transitory computer-readable medium capable of storing information accessible by the processor 210, 250, such as a hard drive, a solid-state drive, a tape drive, optical storage, a memory card, ROM, RAM, DVD, CD-ROM, a writable memory, and a read-only memory.

[0046] although Figure 2 The processors 210, 250 and corresponding memories 220, 260 of each component 201, 202 are functionally illustrated as being included in a single box, but the processors and memories may actually include multiple processors and memories that may or may not be stored in the same physical housing. For example, some data and instructions may be stored on a removable CD-ROM, a permanent hard disk, a solid-state drive (SSD), and others. Some or all of the instructions and data may be stored in a location physically away from the processor but still accessible to the processor. Similarly, a processor may actually include a collection of processors that may or may not operate in parallel.

[0047] Each of the GCIA system 201 and the capacity management subsystem 202 may further include input / output components 291, 292 for receiving and transmitting data with other components of the system. The received data may include supply signaling flows and demand signaling flows. The transmitted data may include instructions for computing and storage devices of the cloud computing environment. The input / output components 291, 292 of the GCIA system 201 and the capacity management subsystem 202 may also communicate with each other.

[0048] In the GCIA system 201, data 230 stored in the memory 220 may include capacity management subsystem signaling 232 received from the capacity management subsystem 202. This signaling 232 may be stored at the GCIA system for processing according to SDM rules 234, which may also be stored in the memory 220 of the GCIA system 201. The instructions 240 of the GCIA system 201 may include one or more routines for processing the capacity management subsystem signaling 232, including, but not limited to, an inventory classification routine 242 for classifying inventory identified in the supply signaling, and a supply / demand matching routine 242 for applying the SDM rules 234 to the capacity management subsystem signaling 232 and deriving a set of instructions for managing existing VMs and available VM capacity of computing and storage devices according to the SDM rules.

[0049] In the capacity management subsystem 202, the data 270 stored in the memory 260 may include one or both of supply signaling and demand signaling 272 received from a supply source and a demand source, such as the inventory management device 110 or the client device 120. The supply signaling and demand signaling 272 may be stored at the capacity management subsystem 202 for processing according to the SDM rules 234 according to the instructions received from the GCIA 201, and the SDM rules may also be stored in the memory 270 of the capacity management subsystem 202. The instructions 280 of the capacity management subsystem 202 may include one or more routines for processing the supply signaling and demand signaling 272, including but not limited to a cloud computing management routine 282 for controlling the supply guidance and demand guidance within the cloud computing environment, and a GCIA query routine 284 for querying the GCIA system 201 for instructions for directing the execution of the cloud computing management routine 282.

[0050] Figure 3 Examples of the present disclosure include Figure 1 100 is a block diagram of an example of information flow within system 300 .

[0051] Figure 3 The example system 300 receives both supply signaling 310 and demand signaling 320 from various signal sources. The system 300 may include several different subsystems 330-380 that are responsible for receiving different elements of the supply signaling 310 or demand signaling 320 and processing the received elements according to each subsystem's respective role within the overall system. Some subsystems may receive and process the supply signaling 310 and make decisions about the inventory of the cloud computing environment based on the supply signaling 310. Some subsystems may receive and process the demand signaling 320 and make decisions about the distribution of operations performed in the cloud computing environment based on the demand signaling 320. Although Figure 3 Not shown, one or more subsystems may receive and process the combination of supply signaling 310 and demand signaling 320. Figure 3 As shown, each of the subsystems 330-380 is directly or indirectly communicatively connected to the GCIA system 390. The GCIA system 390 is responsible for implementing a common set of SDM rules for each of the subsystems so that the supply signaling 310 and demand signaling 320 are managed consistently and coherently throughout the system 300.

[0052] The supply signaling 310 may include communications indicating the immediate or final availability or unavailability of the cloud computing environment inventory. For example, the supply signaling may indicate a new order for a machine for the cloud computing environment. The signaling indicating the new order may further indicate any one or combination of delivery details such as the inventory stock keeping unit (SKU) of the ordered machine, a unique identifier for each of the machines, the supplier providing the machine, the estimated delivery time of the machine, and the estimated time for the machine to be integrated or installed into the cloud computing environment. The signaling indicating the new order may further indicate specifications or details about the machine's capabilities, such as the number of central processing units (CPUs) or other indications of the amount of computing capacity included in the machine, the amount of random access memory (RAM), hard disk space, solid state drive (SSD) space, or other indications of the amount of storage capacity included in the machine, and any one or combination of machine platform types that may indicate which types of VMs are compatible with the machine. Example types of VMs may include N1, E2, N2, and the like.

[0053] In some examples, signaling indicating new orders may use soft SKUs to improve capacity management efficiency. Soft SKUs may represent a shared pool of resources, whereby each soft SKU may group together a limited number of standard SKU pools. Soft SKUs may be used to set interchangeability rules for machines, whereby if a machine of the requested type is not available, another type of machine having the same soft SKU as the requested type of machine may be provided instead.

[0054] Another example of provisioning signaling 310 may be a signal indicating maintenance work on one or more machines of the cloud computing environment, whereby the one or more machines may be taken offline for maintenance. Another example of provisioning signaling 310 may be a signal indicating an error at one or more machines of the cloud computing environment, whereby the one or more machines may be completely or partially unavailable to meet customer needs due to the error. Maintenance work signaling and machine error signaling may also indicate the identity and attributes of the offline machine, and the estimated time when the machine will be back up and running. In the case of maintenance, the signaling may also include the estimated start time of the maintenance.

[0055] Demand signaling 320 may include a request from a user of a cloud computing environment for access to storage resources, computing resources, or both. The request may be for immediate access to available resources, or a reservation for future access to resources. The request may indicate an estimated time for the requested access, which may include a start time for the access and optionally an end time or information from which the end time may be predicted, such as the size of a project being requested to be performed using computing resources of the cloud computing environment. The request may further indicate information about the requester, such as the identity of the requester, the time of the request, the type of machine to which the requester is requesting access, the amount of computing resources, storage resources, or both being requested, the urgency of the request, and the like.

[0056] First, focus on the provisioning signaling 310. Figure 3 In the example of , the supply signaling 310 is initially received by the supply classification subsystem 330. The supply classification subsystem 330 is responsible for interpreting the supply signaling 310 to determine one or more attributes of the supply signaling. The determined attributes may include any attributes of the supply signaling described herein, such as SKU, VM types compatible with the inventory, processing capacity of the inventory, storage capacity of the inventory, and the like.

[0057] In some examples, the supply classification subsystem 330 may include a mapping of VM types to platform types. For a request for computing resources that requires a particular type of VM, the mapping between VM types and platform types may be used to identify which machines may be used to satisfy the received request, and which machines may be used to substitute for each other in the event of a change in the supply / demand match.

[0058] In addition, for new inventory added to the cloud computing environment, the supply classification subsystem 330 can assign one or more new attributes to the new inventory. One example new attribute is a supply installation lead time classification for the new inventory. The supply installation lead time can classify when the new inventory will become available in the cloud computing environment. For example, inventory can be classified using a first category indicating an approaching lead time and a second category indicating a reserved lead time. The approaching lead time can indicate that the associated inventory has been deployed in a data center or other station in the cloud computing environment and is ready to serve customer VMs to meet the imminent demand at the cloud computing environment. In contrast, a delayed lead time can indicate that the associated inventory is predicted to be available at a future time and can be used to meet inventory reservations at the cloud computing environment or can be designated for a predicted demand surge.

[0059] Within the classification of delayed lead time, a more fine-grained classification may be applied to distinguish between inventory that will be available on the order of days and inventory that will only be available on the order of weeks. For example, a new order for a machine that has been delivered but not yet installed may be predicted to be available on the order of days and may be used to satisfy a computing resource reservation scheduled in a few days' time, while a new order for a machine that has not yet been shipped may be projected not to arrive and be installed for a few weeks or so, meaning that it is not suitable to satisfy the same computing resource reservation. Inventory that has been received and is ready to be reserved is referred to herein as having a "reserved lead time" classification, and inventory that is still in transit is referred to herein as having an "in transit" classification.

[0060] Another example of a new attribute that can be assigned to inventory is a confidence level of availability, which indicates the confidence level that the inventory is available or will be available within the predicted time. In the case of inventory with a near lead time, the confidence level can be high, such as 100% or close to 100% when a numerical value is assigned to the confidence level. In the case of inventory with a delayed lead time, the confidence level may vary depending on multiple factors, such as whether the inventory has been received from the supplier, and the supplier's past performance history, and telemetry about the current shipment. For example, if the inventory is classified under the reserved lead time, the confidence level can be high, such as 100% or close to 100%. However, if the inventory is classified as in transit, the confidence level can be less than 100%. The confidence level can be further based on the supplier's past tracking record in previously supplying inventory, whereby the better the supplier's tracking record, the higher the confidence level can be. The tracking record history can include not only the time it took the supplier to deliver the inventory, but also whether the delivered inventory has historically worked as expected. For example, if a supplier has a history of delivering 80% of working product, while the remaining 20% ​​requires immediate maintenance or must be returned, the confidence level can be adjusted to reflect this. Ultimately, the confidence level can be used as a weighting factor to increase or decrease the system's reliance on inventory that has not yet been received so as not to over-promise resources and under-deliver to customers.

[0061] The provisioning classification subsystem 330 may further determine to which other subsystem or subsystems the provisioning signaling 310 is forwarded. Figure 3In an example of, the system 300 includes two supply shaping subsystems: a short-term supply shaping subsystem 340 and a long-term supply shaping subsystem. Supply signaling for inventory with approaching lead times can be provided to at least the short-term supply shaping subsystem 340, while supply signaling for inventory with in-transit lead times can be provided to at least the long-term supply shaping subsystem 350. Supply signaling for inventory with reserved lead times can be provided to either or both of the two supply shaping subsystems. For example, in an example system, the short-term supply shaping subsystem 340 may have the task of scheduling any inventory with a confidence level of 100% or close to 100%, which means providing signaling for inventory with reserved lead times. Alternatively, if the short-term supply shaping subsystem 340 is only responsible for balancing currently available supply, signaling for inventory with reserved lead times may not be provided. By further example, the long-term supply shaping subsystem 350 may employ all supply signaling 310 in order to establish a forecast of future supply needs based on current supply availability.

[0062] In one example implementation, the short-term supply shaping subsystem 340 can be a service that automates the configuration of a fleet of computing resources of a cloud computing environment on which VMs are running. The service can ingest signaling for approaching and reserved lead time inventory, and can assign inventory to meet the expected state of the cloud computing environment, thereby providing necessary resources to all customers of the cloud computing environment while avoiding stock-outs. The service can be cluster-wide, meaning that supply resources can be aggregated in a manner that achieves the expected state. When machines enter the cloud computing environment, the service can assign machines to domains and storage roles. Machines can then be reassigned between domains based on the capacity targets of each domain. Thus, the service can track each of the VM cluster, the assigned domains, the assigned storage roles of previously entered machines, and the capacity targets of each domain.

[0063] The short-term supply shaping subsystem 340 may also be responsible for setting a machine reservation threshold that indicates the maximum capacity that a machine cluster can hold before no further requests are assigned to the machine. This threshold may act as a buffer to provide some excess capacity for managing items already present at the machine while reducing the likelihood of a stock-out scenario. This threshold may be adjusted as the likelihood of a stock-out scenario increases or decreases, whereby the greater the likelihood of a stock-out becomes, the larger the buffer reserved at the machine.

[0064] The long-term supply shaping subsystem 350 can be a service that predicts capacity over a long-term scale in order to manage in-transit inventory. The service can predict increased capacity for different clusters or domains of a cloud computing environment based on factors such as currently available supply, future available supply, information about one or more suppliers that transport inventory (including supplier performance data), and interchangeability data indicating the interchangeability of one machine type for another machine type in the future when one part of the machine is operating and a different part of the machine is not operating. This can be automatically adjusted or updated based on a feedback loop so that any delays that occur during transportation can be integrated into previous predictions and used to update delivery schedules, confidence levels, and other availability expectations. The long-term supply shaping subsystem 350 service can also be able to predict domains for incoming machines, as well as reassign machines between domains based on changes in shipping schedules and supplier performance. Long-term predictions are helpful in avoiding situations where inventory increases are expected but inventory does not meet expectations due to failures in machine transportation and delivery.

[0065] Next, focus on the demand signaling 320. Figure 3 In the example of , demand signaling 320 is initially received by cloud access control subsystem 360. Cloud access control subsystem 360 is responsible for interfacing client devices with other capacity management subsystems in order to direct resource requests to their appropriate destinations. Information received at cloud access control subsystem 360 may be interpreted to determine the customer that sent the request, and the request may be stored along with the customer's current and historical workload data. Cloud access control subsystem 360 may also be responsible for scheduling user reservations of computing resources, thereby effectively assuring the user that the cloud computing environment has capacity to meet the user's future computing needs. Conversely, if cloud access control subsystem 360 determines that the user's request cannot be met, the subsystem is able to communicate to the user that the requested capacity is not available.

[0066] In some cases, the cloud access control subsystem 360 may also have the ability to differentiate between imminent demand and future demand, whereby imminent demand requires immediately available resources to satisfy the demand, and future demand may rely on resources that will be available in the future, such as inventory with a reserved lead time. Demand signaling 320 may be directed to one or more additional subsystems based on the type of demand contained in the signaling.

[0067] exist Figure 3In the example of , a short-term demand guidance subsystem 370 is provided, which is used to guide the user's resource request towards the available computing resources of the cloud computing environment. The short-term demand guidance subsystem 370 can be capable of guiding the request towards the available resources based on the current demand at the system, so that the request flow from one or more users is appropriately distributed among the available resources. Directing the request may involve assigning new requests, rebalancing the distribution of existing requests, or a combination thereof. The short-term demand guidance subsystem 370 may also be able to determine whether there are insufficient resources in the system to meet the current demand request, and in this case notify the user of this through the cloud access control subsystem 360.

[0068] And, in Figure 3 In the example of , a long-term demand forecasting subsystem 380 is provided to predict future demand for computing resources in a cloud computing environment. The long-term demand forecasting subsystem 380 may receive information about demand signaling from a past period of time (such as two weeks, one month, two months, four months, six months, etc.) to predict future demand for the system. In general, receiving more historical demand information can improve predictions of future demand. The long-term demand forecasting subsystem 380 may be able to determine whether a reservation for computing resources can be fulfilled at a future time, and provide capacity guarantees to customers when it is predicted that the request is consistent with future available capacity. In addition, the long-term demand forecasting subsystem 380 may be able to recommend aggregate pool sizes for machines in the cloud computing environment based on predicted demand, move projects between clusters within a region of the cloud computing environment to balance remaining idle capacity, or both.

[0069] The GCIA system 390 is connected to each of the subsystems 330-380 to unify supply shaping decisions with demand steering decisions. In operation, the subsystems 330-380 can call the SDM engine of the GCIA system through remote procedure calls (RPCs) or libraries. The GCIA system can return a selection of appropriate supplies that match a given demand based on factors such as the lead time of the supply and demand.

[0070] The GCIA system 390 relies on a predetermined set of SDM rules to ensure that computing resources are handled consistently across the various subsystems. Some of the SDM rules stored at the GCIA system may include the following:

[0071] (1) Packing: Packing the units of the cloud computing environment to reduce unit fragmentation.

[0072] (2) VM integrity: ensuring that a single VM is not scheduled across multiple machines in a cloud computing environment.

[0073] (3) Queuing: Client requests for computing resources are resolved on a first-come, first-served basis.

[0074] (4) Reservation: Identify reserved resources and ensure that reserved resources are not counted as saleable capacity for the purpose of forecasting available capacity.

[0075] (5) Clustering: Allows the scheduling of VM requests to be moved from one unit to another within the same VM cluster without causing performance degradation. In some examples, VM requests can be moved between zones in a cloud computing environment.

[0076] (6) Cost efficiency: Track the cost efficiency of different machine types. This can be used to select machine types for computing resource requests based on cost efficiency, such as when two machine types are available, the more cost-efficient machine type is preferred over the other machine type.

[0077] (7) Overallocation multiplier: A weighted cost is applied to overallocated units or clusters to ensure that further demand is directed away from overallocated areas and toward underutilized resources and to improve forecasts of future resource availability.

[0078] These rules and others can ensure that subsystems 330-380 of system 300 handle supply signaling 310 and demand signaling 320 consistently and do not take conflicting actions, such as one subsystem responding to a lack of available resources by moving more resources toward that location while another subsystem directs demand away from the same location.

[0079] The example system 300 above describes the GCIA system 390 as having a single unified set of SDM rules for all subsystems. However, in some cases, it may not be necessary to unify each subsystem. For example, a first subset of subsystems may have a first set of SDM rules in common, and a second subset of subsystems may have a second, similar set of SDM rules in common, but the first set of SDM rules may be independent of the second subset of subsystems, and the second set of SDM rules may be independent of the first subset of subsystems. In this case, the GCIA system may host two independent sets of shared SDM rules: one for the first subset of subsystems, and one for the second set of subsystems. In other cases, the SDM rules may be divided into subsystem-specific rules that may apply to one or more subsystems, and global SDM rules that apply to all subsystems.

[0080] exist Figure 3In the example of , the GCIA system 390 is shown as merely interfacing with the subsystems and providing guidelines or instructions to the subsystems to perform actions consistent with the SDM rules. However, in other cases, the GCIA system 390 may be responsible for additional tasks within the system 300. For example, the GCIA system 390 may be further responsible for ingesting signaling for new inventory and classifying the inventory, as described in conjunction with the supply classification subsystem 330. In such an example, the GCIA system 390 may further use its determined supply classification to match new inventory that is available or will soon be available with incoming demand, such as by matching supply signaling 310 with demand signaling 320 based at least in part on supply lead time and demand lead time. This may involve the GCIA system 390 matching adjacent demands with currently available computing resources and matching reserved demands with reserved inventory. By further example, the GCIA system 390 may assign adjacent supplies to incoming demands when possible, and may select reserved supplies to meet incoming demands when no adjacent supplies are available. Example Method

[0081] Combination Figure 4 The routines performed by the capacity management subsystem and the GCIA system are described in more detail.It should be understood that the routines described herein are merely examples, and in other examples, certain steps may be added, subtracted, replaced, or reordered.

[0082] Figure 4 4 is a flow chart illustrating an example routine 400 for capacity management. Certain steps of the routine are described as being performed by one or more processors of the GCIA system. However, in other example routines, the processor responsible for at least some of these steps may be switched from the GCIA system to the capacity management subsystem.

[0083] At block 410, the GCIA system receives supply signaling and demand signaling. The supply signaling may indicate that new inventory is received at the cloud computing environment. The new inventory may include new machines that may be configured as virtual machines for processing customer projects or other requests, or for storing data, such as data sets on which projects and other requests are executed. The demand signaling may include customer projects and requests. Both the supply signaling and the demand signaling may be associated with corresponding lead times, which indicate an amount of time until supply becomes available or an amount of time until a customer request needs to be executed, respectively.

[0084] At block 420, the GCIA system updates a record of the inventory of available computing resources based on the supply signaling and the demand signaling. The record may be maintained at the GCIA system and may indicate information about the incoming supply and demand, such as the corresponding lead times. The GCIA system may further classify the incoming supply and demand according to pre-stored classifications, such as depending on the amount of lead time, the confidence level of the incoming supply to be received, etc.

[0085] At block 430, the GCIA system receives capacity planning signals from a plurality of capacity management subsystems assigned to perform different action types. The different action types may generally involve short-term supply shaping, long-term supply shaping, short-term demand guidance, long-term demand forecasting, etc. For example, in conjunction with Figure 3 Any service described by the subsystems of the system 300 may be considered an action type. For example, the action types may include any one or more of the following: reserving computing resource inventory for predicted demand; determining a pool size for a domain of a cloud computing environment; moving computing resource inventory between domains of a cloud computing environment; moving items between domains of a cloud computing environment; and moving demand for computing resource inventory between domains of a cloud computing environment.

[0086] At block 440, the GCIA system applies common SDM logic to each of the received capacity planning signals. The common SDM logic may include rules that directly match supply, such as available cloud computing environment resources, to demand, such as incoming computing requests from customers. The common SDM logic may be uniformly applied to all subsystems to ensure consistent handling of available supply and incoming demand and to avoid conflicting actions by subsystems.

[0087] At block 450, the GCIA system transmits capacity management signals back to the multiple capacity management subsystems based on the common SDM logic. The capacity management signals may instruct the subsystems on how to perform the corresponding action types of the corresponding subsystems. As described in conjunction with block 440, the capacity management signals may be obtained from the unified application of the SDM logic across the various subsystems, so that the subsystems take consistent and coherent actions.

[0088] In one example implementation of routine 400, the GCIA system may operate as a trading system. In practice, the supply signaling and demand signaling received at box 410 may be received directly or indirectly from a supply source and a demand source external to the system, and may include an indication of the type of resource being added or requested, the amount of the resource being added or requested, and the lead time until the resource is added or requested. Based on the information received at box 410, the GCIA system may attempt to match the incoming supply with the incoming demand at box 420 so that each resource is allocated for the corresponding request. Allocation of resources may involve specifying the resources in a GCIA record so that the entire system is aware that the resources have been allocated.

[0089] Resources and requests can be matched to each other based on type, available amount and lead time, and any one or combination of other factors and attributes described herein. In this example implementation, the capacity planning signal received at box 430 can actually be a request from various subsystems of the capacity management system, and the request is used to access the updated record of the GCIA system from box 420, so that the subsystem can be informed which resources are available and which resources have been specified. In this regard, applying the common SDM rules to each subsystem in the subsystem at box 440 can be achieved by providing a common record of computing resource allocation to each subsystem in the subsystem, so that the information used by each subsystem to shape supply, guide demand, predict future capacity or requests, etc. is based on a single source of truth, rather than conflicting views of the cloud computing system from various capacity management subsystems. Thus, the capacity management signal transmitted to the subsystem at box 450 can at least partially include information about computing resource allocation contained in the GCIA system record.

[0090] In order to keep the GCIA system records up to date and relevant, the records can be updated or refreshed periodically (such as cyclically). For example, a new machine entering the GCIA system record may initially be marked as being available soon, but later the machine may be disassembled for maintenance. The update cycle may process new supply signaling indicating a maintenance event and update the record based on the new supply signaling to indicate that the resource is unavailable. By further example, a new machine entering the GCIA system may initially be marked as reserved and designated to satisfy a user request for computing resources with a two-day lead time. However, another user request may be received later, and it may be determined that the designated machine is more suitable for handling a more recent user request. For example, if an earlier request is more flexible about which machine type can be used to satisfy the request, but a more recent request requires a specific machine type that can only be satisfied by a designated machine, or if a large influx of new resource requests is received at the GCIA system, it may be determined that the new request is bundled at a shared machine cluster while other requests at the cluster are directed to different locations to rebalance the demand within the cloud computing system. In this case, the update loop may process new provisioning signaling indicating one or more new user requests and redirect the original request to the new machine, thereby negating the original designation and possibly replacing the original designation with the new designation. The update may also involve recalculating the confidence level that the newly designated machine will be available to the user. Such information may be proactively communicated to the user so that the user's expectations may be set appropriately.

[0091] As described in the capacity management system and management method of the present disclosure, the use of a centralized inventory availability system has several advantages over a capacity management system that lacks centralized control. A centralized system is able to unify and apply consistent supply demand matching rules that improve the accuracy of truly available inventory. This has the positive impact of minimizing stranding and out-of-stock scenarios caused by asynchronous systems shaping both supply and demand. A centralized system is also able to maintain up-to-date availability information for incoming supply and quickly and regularly update customers with guarantees or commitments to available inventory as supply chain difficulties occur and are resolved. A centralized system also enables a unified set of interchangeability rules to be applied to different machine types, so that the various subsystems connected thereto can efficiently replace inoperative and unavailable machines with working and available inventory. In addition, the use of a centralized system provides a more robust and clearer understanding of both current inventory availability and historical inventory availability, thereby improving the system's ability to predict future availability and set accurate forecasts and customer expectations.

[0092] Although the technology has been described herein with reference to specific embodiments, it should be understood that these embodiments are only illustrative of the principles and applications of the present technology. Therefore, it should be understood that various modifications may be made to the illustrative embodiments, and other arrangements may be designed without departing from the spirit and scope of the present technology as defined by the appended claims.

[0093] Most of the aforementioned alternative examples are not mutually exclusive, but can be implemented in various combinations to achieve unique advantages. Since these and other variations and combinations of the features discussed above can be utilized without departing from the subject matter defined by the claims, the previous description of the embodiments should be carried out by way of illustration rather than by way of limiting the subject matter defined by the claims. As an example, the preceding operations do not have to be performed in the exact order described above. On the contrary, the various steps can be disposed in different orders, such as disposed in reverse order, or disposed simultaneously. Unless otherwise specified, steps can also be omitted. In addition, the examples described herein and the supply of clauses expressed as "such as", "including", etc. should not be interpreted as limiting the subject matter of the claims to specific examples; on the contrary, these examples are intended to illustrate only one of many possible embodiments. Further, the same reference numerals in different figures can identify the same or similar elements.

Claims

1. A method comprising: receiving, by one or more processors, supply signaling and demand signaling indicating one or more changes to an inventory of available computing resources in a cloud computing environment; updating, by the one or more processors, a record of an inventory of available computing resources in response to the supply signaling and the demand signaling; receiving, by the one or more processors, a first capacity planning signal from a first capacity management subsystem and a second capacity planning signal from a second capacity management subsystem, the first capacity management subsystem being assigned to perform a first capacity management action type, and the second capacity management subsystem being assigned to perform a second capacity management action type different from the first capacity management action type; applying, by the one or more processors, a common supply-demand matching (SDM) logic to each of the first capacity planning signal and the second capacity planning signal; transmitting, by the one or more processors, a first capacity management signal to the first capacity management subsystem, the first capacity management signal indicating execution of a first action of the first capacity management action type based on the common SDM logic; as well as A second capacity management signal is transmitted by the one or more processors to the second capacity management subsystem, the second capacity management signal instructing to perform a second action of the second capacity management action type based on the common SDM logic.

2. The method of claim 1, wherein: Each of the first capacity management action type and the second capacity management action type is selected from the group consisting of: reserving computing resource inventory for forecasted demand; determining a pool size for a domain of the cloud computing environment; moving computing resource inventory between domains of the cloud computing environment; moving items between domains of the cloud computing environment; and the need to move computing resource inventory between domains in the cloud computing environment.

3. The method of claim 1, wherein: One or more changes in the inventory of available computing resources indicated by the supply signaling and the demand signaling include at least one of central processing unit (CPU) capacity, random access memory (RAM) size, or solid state drive (SSD) size, and wherein the SDM logic matches demand to supply based at least in part on the one or more changes in the inventory of available computing resources indicated by the supply signaling and the demand signaling.

4. The method of claim 1, wherein: The common SDM logic includes SDM rules, wherein the SDM rules include at least one of the following: Packing locations to reduce fragmentation of stored data; Require supply signaling to be matched with demand on a first-come, first-served basis; Avoid having reserved inventory counted towards currently available capacity; Applying multipliers to locations where available resources are overallocated to reduce the likelihood that further resources will be reallocated; Apply cost-efficiency weighting to available capacity based on machine type; or Prevent a single virtual machine (VM) from being split across multiple machines.

5. The method of claim 4, wherein: The provisioning signaling further indicates a provisioning lead time for new inventory of computing resources to become available in the cloud computing environment, wherein the recording of available inventory of computing resources includes recording the lead time, and wherein the demand signaling is associated with a demand lead time indicating when new demand will be received.

6. The method of claim 1, wherein: The common SDM logic is configured to match provision signaling with demand signaling based at least in part on the provision lead time and the demand lead time.

7. The method of claim 6, wherein: The common SDM logic is configured to match imminent demand with currently available computing resources and to match predicted demand with future available computing resources.

8. The method of claim 5, wherein: Each of the supply lead time and the demand lead time is selected from a plurality of lead time categories, wherein the lead time categories include at least: an approaching lead time, the approaching lead time indicating immediately available computing resources and an immediate computing resource demand, respectively; a reserved lead time indicating incoming computing resources to be available on the order of days and a predicted computing resource demand to be received on the order of days, respectively; and The en-route lead times indicate incoming computing resources that will be available on the order of weeks and predicted computing resource demand that will be received on the order of weeks, respectively.

9. The method of claim 8, wherein: For the provisioning signaling indicating the in-transit lead time, the provisioning signaling further indicates a supplier of the incoming computing resources, and wherein an amount of the incoming computing resources that will be available on the order of weeks is estimated based at least in part on historical performance data of the supplier.

10. The method of claim 1, wherein: The provisioning signaling indicates a VM type, and wherein the common SDM logic is configured to match the provisioning signaling with the demand signaling based at least in part on a mapping between the VM type and compatible machine types.

11. A system comprising: a memory storing a supply-demand matching (SDM) logic framework for matching resources of a cloud computing environment with requests for the resources of the cloud computing environment, wherein each of the resources and the requests includes an indication of a lead time; and One or more processors of a global cloud inventory availability system, the one or more processors being configured to: Accessing the SDM logical framework; matching the resource with the request based at least in part on the lead time according to the SDM logical framework; receiving a plurality of corresponding capacity planning signals from a plurality of capacity management subsystems, wherein each capacity management subsystem is assigned to perform a different capacity management action type; and For each capacity planning signal, an indication of the matched resources and requests associated with the capacity planning signal is transmitted to the capacity management subsystem from which the capacity planning signal was sent.

12. The system of claim 11, wherein: The plurality of action types are selected from the group consisting of: reserving an inventory of computing resources for predicted demand; determining a pool size for a domain of the cloud computing environment; moving computing resource inventory between domains of the cloud computing environment; moving items between domains of the cloud computing environment; and the need to move computing resource inventory between domains in the cloud computing environment.

13. The system of claim 11, wherein: The one or more processors are configured to match the resource with the request further based on at least one of computing capacity, storage capacity, or virtual machine (VM) type.

14. The system of claim 11, wherein: The SDM logical framework includes at least one of the following: A packing rule, wherein the packing rule is used to reduce fragmentation of stored data; a VM integrity rule, the VM integrity rule being used to ensure that a VM is not scheduled across multiple machines of the resources of the cloud computing environment; a queuing discipline for resolving requests on a first-come, first-served basis; a reservation rule, the reservation rule being used to ensure that the reserved resources are not counted towards the available capacity of the cloud computing environment; or Cluster rules are used to move requests between units of a common cluster of the cloud computing environment.

15. The system of claim 14, wherein: The SDM logical framework includes at least three of the packing rules, the VM integrity rules, the queuing rules, the reservation rules, and the clustering rules.

16. The system of claim 11, wherein: The lead time for the resource indicates a time when the resource becomes available in the cloud computing environment, and wherein the lead time for the request indicates when an item included in the request will be executed.

17. The system of claim 16, wherein: The one or more processors are configured to: matching resources having close lead times with requests having the close lead times; matching a resource having a ready-to-reservation lead time with a request having the ready-to-reservation lead time; and Indications of the matched resources and requests having the approaching lead time and the ready-to-reservation lead time are transmitted to one or more capacity management subsystems configured to perform one of short-term supply shaping or short-term demand steering.

18. The system of claim 16, wherein: The one or more processors are configured to: matching a resource having an in-transit lead time with a request having the in-transit lead time; An indication of the matched resource and request having the in-transit lead time is transmitted to one or more capacity management subsystems configured to perform one of long-term supply shaping or long-term demand forecasting.

19. The system of claim 18, wherein: The one or more processors are configured to determine a confidence level for delivery of the resource with the in-transit lead time based on a supplier that delivers the resource with the in-transit lead time and historical performance data for the supplier.

20. The system of claim 11, wherein: The memory includes a mapping between a plurality of VM types and a plurality of machine platforms, and wherein the one or more processors are configured to match the resource to the request further based on the mapping according to the SDM logical framework.

Images