System and method for determining and tracking cloud capacity metrics

A cloud capacity system enables calculation and tracking of cloud capacity metrics for data center pods. The system includes a “Cloud Capacity Snapshot” table having a number of different cloud capacity columns; a “Cloud Capacity Query” table that stores a respective, customizable query for each of the cloud capacity columns defining criteria for selecting and combining data to calculate the corresponding cloud capacity metric value; and a “Cloud Capacity URLs” table that stores cloud capacity universal resource locator (URLs). Each cloud capacity URL embodies or encodes a respective cloud capacity query of the “Cloud Capacity Query” table for a given combination of a particular cloud capacity column and a particular pod in the “Cloud Capacity Snapshot” table. As such, by executing the queries encoded in the “Cloud Capacity URLs” table, each cloud capacity field of the “Cloud Capacity Snapshot” table is populated with the corresponding cloud capacity metric value.

BACKGROUND

The present disclosure relates generally to cloud computing environments, and, more specifically, to determining and tracking cloud capacity metrics within a data center hosting a cloud computing environment.

Organizations, regardless of size, rely upon access to information technology (IT) and data and services for their continued operation and success. A respective organization's IT infrastructure may have associated hardware resources (e.g. computing devices, load balancers, firewalls, switches, etc.) and software resources (e.g. productivity software, database applications, custom applications, and so forth). Over time, more and more organizations have turned to cloud computing approaches to supplement or enhance their IT infrastructure solutions.

Cloud computing relates to the sharing of computing resources that are generally accessed via the Internet. In particular, a cloud computing infrastructure allows users, such as individuals and/or enterprises, to access a shared pool of computing resources, such as servers, storage devices, networks, applications, and/or other computing based services. By doing so, users are able to access computing resources on demand that are located at remote locations, which resources may be used to perform a variety of computing functions (e.g., storing and/or processing large quantities of computing data). For enterprise and other organization users, cloud computing provides flexibility in accessing cloud computing resources without accruing large up-front costs, such as purchasing expensive network equipment or investing large amounts of time in establishing a private network infrastructure. Instead, by utilizing cloud computing resources, users are able redirect their resources to focus on their enterprise's core functions.

In modern communication networks, examples of cloud computing services a user may utilize include so-called infrastructure as a service (IaaS), software as a service (SaaS), and platform as a service (PaaS) technologies. IaaS is a model in which providers abstract away the complexity of hardware infrastructure and provide rapid, simplified provisioning of virtual servers and storage, giving enterprises access to computing capacity on demand. In such an approach, however, a user may be left to install and maintain platform components and applications. SaaS is a delivery model that provides software as a service rather than an end product. Instead of utilizing a local network or individual software installations, software is typically licensed on a subscription basis, hosted on a remote machine, and accessed by client customers as needed. For example, users are generally able to access a variety of enterprise and/or information technology (IT)-related software via a web browser. PaaS acts as an extension of SaaS that goes beyond providing software services by offering customizability and expandability features to meet a user's needs. For example, PaaS can provide a cloud-based developmental platform for users to develop, modify, and/or customize applications and/or automating enterprise operations without maintaining network infrastructure and/or allocating computing resources normally associated with these functions.

A data center hosting one or more cloud computing environment may be associated with a number of different cloud capacity metrics. For example, a pod of a data center may host five client instances, two demo instances, and one developer instance, and each of these numerical values represents a distinct cloud capacity metric value of the data center pod. A data center may include numerous pods, each associated with numerous cloud capacity metrics, resulting in a massive number of cloud capacity metrics. It may be desirable for these cloud capacity metrics to be periodically updated, which can involve numerous data requests and calculations. Moreover, it may be desirable to determine and track certain cloud capacity metrics for a pod that have not been previously determined or tracked, or to customize the manner in which certain cloud capacity metrics are tracked. As such, it is recognized that there is a need for improved ways of determining and tracking cloud capacity metrics in a customizable manner.

SUMMARY

Present embodiments are directed to a system and method for efficiently and effectively tracking of various cloud capacity metrics of a data center on a per pod basis in a customizable and scalable manner. Present embodiments include corresponding data structures and computer-implemented instructions to enable calculation and tracking of these cloud capacity metrics. In particular, the data structures include a “Cloud Capacity Snapshot” table that includes a number of different cloud capacity columns, each dedicated to a particular cloud capacity metric of a data center on a per pod basis. The data structures include a “Cloud Capacity Query” table, wherein each row or entry of the table stores a respective, customizable cloud capacity query for each of the cloud capacity columns of the “Cloud Capacity Snapshot” table. Each cloud capacity query defines filter criteria for selecting data, as well as a combination operation (e.g., sum, count, etc.) for calculating the cloud capacity metric value from the selected data. The data structures include a “Cloud Capacity URLs” table that stores a cloud capacity universal resource locator (URL) for each cloud capacity field of the “Cloud Capacity Snapshot” table. More specifically, each cloud capacity URL embodies or encodes a respective cloud capacity query of the “Cloud Capacity Query” table for a given combination of a particular cloud capacity column and a particular pod in the “Cloud Capacity Snapshot” table.

As such, by executing the queries encoded in the “Cloud Capacity URLs” table, each cloud capacity field of the “Cloud Capacity Snapshot” table may be populated with the corresponding cloud capacity metric value. For example, at a predetermined time of day or in response to changes to a cloud capacity query of the “Cloud Capacity Query” table, the URLs of the “Cloud Capacity URLs” table are updated, and then new cloud capacity metric values are calculated for each cloud capacity field of the “Cloud Capacity Snapshot” table based on the updated URLs. In certain embodiments, each of the cloud capacity metric values of the “Cloud Capacity Snapshot” table may be stored as a respective URL that presents the corresponding cloud capacity metric value and that points to a query having the same filter criteria as the underlying cloud capacity query. In certain embodiments, the previously calculated cloud capacity metric values may be archived for later cloud capacity trend analysis. Additionally, in certain embodiments, auditing information can be captured for changes to the “Cloud Capacity Query” table. The disclosed system includes a graphical user interface (GUI) to enable an administrator to view the data stored and referenced in the “Cloud Capacity Snapshot” table, and to enable the administrator to modify the queries of the “Cloud Capacity Query” table.

DETAILED DESCRIPTION

As used herein, the term “computing system” refers to an electronic computing device such as, but not limited to, a single computer, virtual machine, virtual container, host, server, laptop, and/or mobile device, or to a plurality of electronic computing devices working together to perform the function described as being performed on or by the computing system. As used herein, the term “medium” refers to one or more non-transitory, computer-readable physical media that together store the contents described as being stored thereon. Embodiments may include non-volatile secondary storage, read-only memory (ROM), and/or random-access memory (RAM). As used herein, the term “application” refers to one or more computing modules, programs, processes, workloads, threads and/or a set of computing instructions executed by a computing system. Example embodiments of an application include software modules, software objects, software instances and/or other types of executable code.

Present embodiments are directed to a system and method for efficiently and effectively tracking of various cloud capacity metrics for a data center in a customizable and scalable manner. As used herein, a “cloud capacity” refers to a metric of usage and available resources of a particular pod. A non-limiting list of example cloud capacity metrics include, a number of instances (e.g., production, developer, or demonstration instances) hosted by a pod, a number of shared database points (e.g., points used, max available points), a number of shared application points (e.g., points used, max available points), and so forth. As used herein, a “pod” refers to a distinct set or group of hardware resources (e.g., servers, networking devices, etc.) of a data center.

Present embodiments include corresponding data structures and computer-implemented instructions to enable calculation and tracking of cloud capacity metrics. In particular, the data structures include a “Cloud Capacity Snapshot” table that includes a number of different cloud capacity columns, each dedicated to a particular cloud capacity metric of a data center on a per pod basis. The data structures include a “Cloud Capacity Query” table, wherein each row or entry of the table stores a respective, customizable cloud capacity query for each of the cloud capacity columns of the “Cloud Capacity Snapshot” table. Each cloud capacity query defines filter criteria for selecting data, as well as a combination operation (e.g., sum, count, etc.) for calculating the cloud capacity metric value from the selected data. The data structures include a “Cloud Capacity URLs” table that stores a respective cloud capacity universal resource locator (URL) for each cloud capacity field of the “Cloud Capacity Snapshot” table. Each cloud capacity URL embodies or encodes a respective cloud capacity query of the “Cloud Capacity Query” table for a given combination of a particular cloud capacity column and a particular pod in the “Cloud Capacity Snapshot” table.

As such, by executing the queries encoded in the “Cloud Capacity URLs” table, each cloud capacity field of the “Cloud Capacity Snapshot” table may be populated with the corresponding cloud capacity metric value. For example, at a predetermined time of day or in response to changes to a cloud capacity query of the “Cloud Capacity Query” table, the URLs of the “Cloud Capacity URLs” table are updated, and then new cloud capacity metric values are calculated for each cloud capacity field of the “Cloud Capacity Snapshot” table based on the updated URLs. In certain embodiments, each of the cloud capacity metric values of the “Cloud Capacity Snapshot” table may be stored as a respective URL that presents the corresponding cloud capacity metric value and that points to a query having the same filter criteria as the underlying cloud capacity query. In certain embodiments, the previously calculated cloud capacity metric values may be archived for later cloud capacity trend analysis. Additionally, in certain embodiments, auditing information can be captured for changes to the “Cloud Capacity Query” table. The disclosed system includes a graphical user interface (GUI) to enable an administrator to view the data stored and referenced in the “Cloud Capacity Snapshot” table, and to enable the administrator to modify the queries of the “Cloud Capacity Query” table.

With the preceding in mind, the following figures relate to various types of generalized system architectures or configurations that may be employed to provide services to an organization in a multi-instance framework and on which the present approaches may be employed. Correspondingly, these system and platform examples may also relate to systems and platforms on which the techniques discussed herein may be implemented or otherwise utilized. Turning now toFIG. 1, a schematic diagram of an embodiment of a cloud computing system10where embodiments of the present disclosure may operate, is illustrated. The cloud computing system10may include a client network12, a network14(e.g., the Internet), and a cloud-based platform16. In some implementations, the cloud-based platform16may be a configuration management database (CMDB) platform. In one embodiment, the client network12may be a local private network, such as local area network (LAN) having a variety of network devices that include, but are not limited to, switches, servers, and routers. In another embodiment, the client network12represents an enterprise network that could include one or more LANs, virtual networks, data centers18, and/or other remote networks. As shown inFIG. 1, the client network12is able to connect to one or more client devices20A,20B, and20C so that the client devices are able to communicate with each other and/or with the network hosting the platform16. The client devices20may be computing systems and/or other types of computing devices generally referred to as Internet of Things (IoT) devices that access cloud computing services, for example, via a web browser application or via an edge device22that may act as a gateway between the client devices20and the platform16.FIG. 1also illustrates that the client network12includes an administration or managerial device, agent, or server, such as a management, instrumentation, and discovery (MID) server24that facilitates communication of data between the network hosting the platform16, other external applications, data sources, and services, and the client network12. Although not specifically illustrated inFIG. 1, the client network12may also include a connecting network device (e.g., a gateway or router) or a combination of devices that implement a customer firewall or intrusion protection system.

For the illustrated embodiment,FIG. 1illustrates that client network12is coupled to a network14. The network14may include one or more computing networks, such as other LANs, wide area networks (WAN), the Internet, and/or other remote networks, to transfer data between the client devices20and the network hosting the platform16. Each of the computing networks within network14may contain wired and/or wireless programmable devices that operate in the electrical and/or optical domain. For example, network14may include wireless networks, such as cellular networks (e.g., Global System for Mobile Communications (GSM) based cellular network), IEEE 802.11 networks, and/or other suitable radio-based networks. The network14may also employ any number of network communication protocols, such as Transmission Control Protocol (TCP) and Internet Protocol (IP). Although not explicitly shown inFIG. 1, network14may include a variety of network devices, such as servers, routers, network switches, and/or other network hardware devices configured to transport data over the network14.

InFIG. 1, the network hosting the platform16may be a remote network (e.g., a cloud network) that is able to communicate with the client devices20via the client network12and network14. The network hosting the platform16provides additional computing resources to the client devices20and/or the client network12. For example, by utilizing the network hosting the platform16, users of the client devices20are able to build and execute applications for various enterprise, IT, and/or other organization-related functions. In one embodiment, the network hosting the platform16is implemented on the one or more data centers18, where each data center could correspond to a different geographic location. Each of the data centers18includes a plurality of virtual servers26(also referred to herein as application nodes, application servers, virtual server instances, application instances, or application server instances), where each virtual server26can be implemented on a physical computing system, such as a single electronic computing device (e.g., a single physical hardware server) or across multiple-computing devices (e.g., multiple physical hardware servers). Examples of virtual servers26include, but are not limited to a web server (e.g., a unitary Apache installation), an application server (e.g., unitary JAVA Virtual Machine), and/or a database server (e.g., a unitary relational database management system (RDBMS) catalog).

To utilize computing resources within the platform16, network operators may choose to configure the data centers18using a variety of computing infrastructures. In one embodiment, one or more of the data centers18are configured using a multi-tenant cloud architecture, such that one of the server instances26handles requests from and serves multiple customers. Data centers18with multi-tenant cloud architecture commingle and store data from multiple customers, where multiple customer instances are assigned to one of the virtual servers26. In a multi-tenant cloud architecture, the particular virtual server26distinguishes between and segregates data and other information of the various customers. For example, a multi-tenant cloud architecture could assign a particular identifier for each customer in order to identify and segregate the data from each customer. Generally, implementing a multi-tenant cloud architecture may suffer from various drawbacks, such as a failure of a particular one of the server instances26causing outages for all customers allocated to the particular server instance.

In another embodiment, one or more of the data centers18are configured using a multi-instance cloud architecture to provide every customer its own unique customer instance or instances. For example, a multi-instance cloud architecture could provide each customer instance with its own dedicated application server(s) and dedicated database server(s). In other examples, the multi-instance cloud architecture could deploy a single physical or virtual server26and/or other combinations of physical and/or virtual servers26, such as one or more dedicated web servers, one or more dedicated application servers, and one or more database servers, for each customer instance. In a multi-instance cloud architecture, multiple customer instances could be installed on one or more respective hardware servers, where each customer instance is allocated certain portions of the physical server resources, such as computing memory, storage, and processing power. By doing so, each customer instance has its own unique software stack that provides the benefit of data isolation, relatively less downtime for customers to access the platform16, and customer-driven upgrade schedules. An example of implementing a customer instance within a multi-instance cloud architecture will be discussed in more detail below with reference toFIG. 2.

FIG. 2is a schematic diagram of an embodiment of a multi-instance cloud architecture100where embodiments of the present disclosure may operate.FIG. 2illustrates that the multi-instance cloud architecture100includes the client network12and the network14that connect to two (e.g., paired) data centers18A and18B that may be geographically separated from one another and provide data replication and/or failover capabilities. UsingFIG. 2as an example, network environment and service provider cloud infrastructure client instance102(also referred to herein as a client instance102) is associated with (e.g., supported and enabled by) dedicated virtual servers (e.g., virtual servers26A,26B,26C, and26D) and dedicated database servers (e.g., virtual database servers104A and104B). Stated another way, the virtual servers26A-26D and virtual database servers104A and104B are not shared with other client instances and are specific to the respective client instance102. In the depicted example, to facilitate availability of the client instance102, the virtual servers26A-26D and virtual database servers104A and104B are allocated to two different data centers18A and18B so that one of the data centers18acts as a backup data center. Other embodiments of the multi-instance cloud architecture100could include other types of dedicated virtual servers, such as a web server. For example, the client instance102could be associated with (e.g., supported and enabled by) the dedicated virtual servers26A-26D, dedicated virtual database servers104A and104B, and additional dedicated virtual web servers (not shown inFIG. 2).

AlthoughFIGS. 1 and 2illustrate specific embodiments of a cloud computing system10and a multi-instance cloud architecture100, respectively, the disclosure is not limited to the specific embodiments illustrated inFIGS. 1 and 2. For instance, althoughFIG. 1illustrates that the platform16is implemented using data centers, other embodiments of the platform16are not limited to data centers and can utilize other types of remote network infrastructures. Moreover, other embodiments of the present disclosure may combine one or more different virtual servers into a single virtual server or, conversely, perform operations attributed to a single virtual server using multiple virtual servers. For instance, usingFIG. 2as an example, the virtual servers26A,26B,26C,26D and virtual database servers104A,104B may be combined into a single virtual server. Moreover, the present approaches may be implemented in other architectures or configurations, including, but not limited to, multi-tenant architectures, generalized client/server implementations, and/or even on a single physical processor-based device configured to perform some or all of the operations discussed herein. Similarly, though virtual servers or machines may be referenced to facilitate discussion of an implementation, physical servers may instead be employed as appropriate. The use and discussion ofFIGS. 1 and 2are only examples to facilitate ease of description and explanation and are not intended to limit the disclosure to the specific examples illustrated therein.

As may be appreciated, the respective architectures and frameworks discussed with respect toFIGS. 1 and 2incorporate computing systems of various types (e.g., servers, workstations, client devices, laptops, tablet computers, cellular telephones, and so forth) throughout. For the sake of completeness, a brief, high level overview of components typically found in such systems is provided. As may be appreciated, the present overview is intended to merely provide a high-level, generalized view of components typical in such computing systems and should not be viewed as limiting in terms of components discussed or omitted from discussion.

By way of background, it may be appreciated that the present approach may be implemented using one or more processor-based systems such as shown inFIG. 3. Likewise, applications and/or databases utilized in the present approach may be stored, employed, and/or maintained on such processor-based systems. As may be appreciated, such systems as shown inFIG. 3may be present in a distributed computing environment, a networked environment, or other multi-computer platform or architecture. Likewise, systems such as that shown inFIG. 3, may be used in supporting or communicating with one or more virtual environments or computational instances on which the present approach may be implemented.

With this in mind, an example computer system may include some or all of the computer components depicted inFIG. 3.FIG. 3generally illustrates a block diagram of example components of a computing system200and their potential interconnections or communication paths, such as along one or more busses. As illustrated, the computing system200may include various hardware components such as, but not limited to, one or more processors202, one or more busses204, memory206, input devices208, a power source210, a network interface212, a user interface214, and/or other computer components useful in performing the functions described herein.

The one or more processors202may include one or more microprocessors capable of performing instructions stored in the memory206. In some embodiments, the instructions may be pipelined from execution stacks of each process in the memory206and stored in an instruction cache of the one or more processors202to be processed more quickly and efficiently. Additionally or alternatively, the one or more processors202may include application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or other devices designed to perform some or all of the functions discussed herein without calling instructions from the memory206.

With respect to other components, the one or more busses204include suitable electrical channels to provide data and/or power between the various components of the computing system200. The memory206may include any tangible, non-transitory, and computer-readable storage media. Although shown as a single block inFIG. 1, the memory206can be implemented using multiple physical units of the same or different types in one or more physical locations. The input devices208correspond to structures to input data and/or commands to the one or more processors202. For example, the input devices208may include a mouse, touchpad, touchscreen, keyboard and the like. The power source210can be any suitable source for power of the various components of the computing device200, such as line power and/or a battery source. The network interface212includes one or more transceivers capable of communicating with other devices over one or more networks (e.g., a communication channel). The network interface212may provide a wired network interface or a wireless network interface. A user interface214may include a display that is configured to display text or images transferred to it from the one or more processors202. In addition and/or alternative to the display, the user interface214may include other devices for interfacing with a user, such as lights (e.g., LEDs), speakers, and the like.

With the preceding in mind,FIG. 4is a block diagram illustrating an embodiment in which a virtual server26and a database server104of a data center18supports and enables a data center instance220, according to one or more disclosed embodiments. More specifically,FIG. 4illustrates an example of a portion of a service provider cloud infrastructure, including the cloud-based platform16discussed above. The cloud-based platform16is connected to a client device20via the network14to provide a user interface to network applications executing within the data center instance220(e.g., via a web browser running on the device20). Data center instance220is supported by virtual servers26similar to those explained with respect toFIG. 2, and is illustrated here to show support for the disclosed functionality described herein within the data center instance220. Cloud provider infrastructures are generally configured to support a plurality of end-user devices, such as device(s)20, concurrently, wherein each end-user device is in communication with the single data center instance220. Also, cloud provider infrastructures may be configured to support any number of instances, such as the data center instance220and/or client instances, concurrently, with each of the instances in communication with one or more end-user devices. As mentioned above, an end-user (e.g., an administrator) may also interface with data center instance220using an application that is executed within a web browser.

More specifically,FIG. 4illustrates an embodiment of a cloud capacity system222as part of the data center instance220. For the illustrated embodiment, the cloud capacity system222includes a cloud capacity tool224(also referred to herein as a cloud capacity application224) that is hosted by the virtual server26. In certain embodiments, the virtual server26hosting the cloud capacity system222may be referred to herein as the cloud capacity server26. The cloud capacity tool224includes instructions that are stored in a suitable memory (e.g., memory206) and executed by a suitable processor (e.g., processor(s)202) associated with the virtual server26to enable the cloud capacity tracking behavior set forth herein. The cloud capacity system222includes a graphical user interface (GUI)226that enables an administrator to view and modify aspects of the cloud capacity system222, as set forth below.

The cloud capacity system222illustrated inFIG. 4includes the database server104of the data center instance220, which stores multiple tables of a data schema228that enable operation of the cloud capacity system222. For the illustrated embodiment, these tables include a “Cloud Capacity Snapshot” table230, a “Cloud Capacity Queries” table232, a “Cloud Capacity URLs” table234, a “Cloud Capacity Archive” table236, and a “Data Center” table238. It may be appreciated that the illustrated tables are merely provided as an example, and in other embodiments, the database server104may store the cloud capacity data in a different manner, in accordance with the present disclosure. In describing these tables, those skilled in the art will appreciate that the terms “column” and “field” are used herein in a largely interchangeable manner.

For the embodiment illustrated inFIG. 4, the “Cloud Capacity Snapshot” table230stores a collection of current cloud capacity metric values for the data center18hosting the data center instance220on a per pod basis. As such, each row or entry in the “Cloud Capacity Snapshot” table230includes a “Pod ID” field240that is designed to store a suitable value (e.g., a string value, an integer value) that uniquely identifies a particular pod of the data center18. In certain embodiments, the “Pod ID” field240may serve as the primary key for the “Cloud Capacity Snapshot” table230. Each entry in the illustrated “Cloud Capacity Snapshot” table230also includes a “Report Order” field242that stores an integer value indicating the relative desired position of each pod when the table is presented by the GUI226, as discussed below. Additionally, each entry in the illustrated “Cloud Capacity Snapshot” table230includes a number of cloud capacity fields244, each designed to store a different cloud capacity metric value. As discussed below, in certain embodiments, each of the cloud capacity fields244is designed to at least store an integer value for the corresponding cloud capacity metric. In other embodiments, each of the cloud capacity fields244stores a respective URL that is designed to present the integer value for a particular cloud capacity metric value, and designed to point or refer to a query that returns the underlying data from which the cloud capacity metric value was calculated.

For the embodiment illustrated inFIG. 4, each row or entry of the “Cloud Capacity Queries” table232stores a customizable query that defines how a particular cloud capacity metric value will be calculated for each of the cloud capacity columns244of the “Cloud Capacity Snapshot” table. As illustrated, each entry in the “Cloud Capacity Queries” table232includes a “CC Field Name” field246that stores a unique string of the name of the particular cloud capacity field of the “Cloud Capacity Snapshot” that corresponds to the query. As such, in certain embodiments, the “CC Field Name” field246may serve as the primary key for the “Cloud Capacity Queries” table232. Each entry in the illustrated “Cloud Capacity Queries” table232includes a “Query” field248(also referred to herein as the filter criteria248) that stores a string that defines the filter criteria for selecting data from a “Data Center” table238hosted by the database server104. Entries in the illustrated “Data Center” table238include a “Pod ID” field250, a “Pod data” field252and a “Configuration items (CI)” data field254, among others, that store information regarding the current configuration and resource usage of each pod of the data center18. Each entry in the illustrated “Cloud Capacity Queries” table232includes a “Combination Operation” field256indicating the type of combination operation (e.g., sum, count, minimum, maximum, average, etc.) that will be used to calculate of the value of the particular cloud capacity metric from the data selected by the filter criteria248. Each entry in the illustrated “Cloud Capacity Queries” table232includes a “Combination Operation Column” field260indicating to which column of the data selected by the query the combination operation will be applied. Additionally, in certain embodiments, each entry in the illustrated “Cloud Capacity Queries” table232includes one or more auditing fields262(e.g., a “Created” timestamp field, a “Created by” field, an “Updated” timestamp field, an “Updated by” field, an “Updates” count field, etc.) to enable detailed tracking of changes to the “Cloud Capacity Queries” table232.

For the embodiment illustrated inFIG. 4, each row or entry of the “Cloud Capacity URLs” table234stores a particular cloud capacity URL that encodes a particular cloud capacity query from the “Cloud Capacity Queries” table232for a particular cloud capacity field of the “Cloud Capacity Snapshot” table230. That is, while each cloud capacity query stored in the “Cloud Capacity Queries” table232generally defines the filter criteria248, the combination operation256, and so forth, to calculate all of the cloud capacity metric values of a particular cloud capacity column of the “Cloud Capacity Snapshot” table230, each URL stored in the “Cloud Capacity URLs” table234embodies the cloud capacity query for each cloud capacity field of the “Cloud Capacity Snapshot” table230(e.g., for each unique combination of a particular data center pod and a particular cloud capacity metric).

With the foregoing in mind, each entry in the illustrated “Cloud Capacity URLs” table234includes a “Pod ID” field264value that uniquely identifies a pod of the data center18, as well as a “CC Field Name” field266value that uniquely identifies a query of the “Cloud Capacity Queries” table. As such, in certain embodiments, a combination of the “Pod ID” field264value and the “CC Field Name” field266value may serve as the primary key for the “Cloud Capacity URLs” table234. Additionally, each entry in the illustrated “Cloud Capacity URLs” table234includes a “CC URL” field268storing a string that encodes the filter criteria248, the combination operation256, and so forth, of the related query in the “Cloud Capacity Queries” table232specifically for the pod indicated by the value of the “Pod ID” field264. In certain embodiments, each entry in the “Cloud Capacity URLs” table234also includes one or more auditing fields270(e.g., a “Created” timestamp field, a “Created by” field, an “Updated” timestamp field, and “Updated by” field, an “Updates” count field, etc.) to enable detailed tracking of changes to the table.

For the embodiment illustrated inFIG. 4, the data schema228includes a “Cloud Capacity Archive” table236that is designed to store archival copies of the “Cloud Capacity Snapshot” table230. That is, as discussed herein, since the “Cloud Capacity Snapshot” table230may be updated at different times (e.g., daily, nightly, hourly), prior to updating, the cloud capacity system222may store and preserve the cloud capacity metric values of each of the cloud capacity fields244in the “Cloud Capacity Archive” table236. As such, the “Cloud Capacity Archive” table236can be used by the cloud capacity system222to generate trend data (e.g., capacity increases, capacity decreases, steady-state capacity) for various cloud capacity metrics. For example, in certain embodiments, the “Cloud Capacity Snapshot” table230may be updated daily, and, prior to updating, the contents of the table may be copied over to the “Cloud Capacity Archive” table236. In certain embodiments, the “Cloud Capacity Snapshot” table230may have the same fields as the “Cloud Capacity Snapshot” data, along with a “Time Stamp” field272that stores a suitable value indicating when the archival occurred.

It may be appreciated that the tables of the data schema228may be related to one another, and these relationships may be enforced via suitable features of the database server104. For example, in certain embodiments, the data schema228may represent a relational database structure. For such embodiments, the “Pod ID” field264of the “Cloud Capacity URLs” table234may have a foreign key relationship to the primary key “Pod ID” field240of the “Cloud Capacity Snapshot” table230, while the “CC Field Name” field266may have a foreign key relationship to the primary “CC Field Name” field246of the “Cloud Capacity Queries” table232. Similarly, the values of “CC Field Name” field246of the “Cloud Capacity Queries” table232are restricted to the names of the cloud capacity fields244of the “Cloud Capacity Snapshot” table230, wherein the names of these columns may be stored within the “Data Center” table238in certain embodiments. In certain embodiments, this relationship, as well as other relationships within the data schema228, may be enforced using suitable business rules, class relationships, and/or other suitable features of the database server104. For example, upon adding a new cloud capacity column244to the “Cloud Capacity Snapshot” table230, the database server104may execute a business rule that creates a default entry in the “Cloud Capacity Queries” table232that is associated with this new column. Similarly, upon removing a cloud capacity column244from the “Cloud Capacity Snapshot” table230, the database server104may execute a business rule that removes the corresponding entry in the “Cloud Capacity Queries” table232.

During operation of the cloud capacity system222, the “Cloud Capacity Snapshot” table230may be updated on a recurring interval (e.g., once per day, once per hour) or in response to changes made to the “Cloud Capacity Queries” table232. For example,FIG. 5is a flow diagram illustrating an embodiment of a process280by which the cloud capacity tool224may update the “Cloud Capacity Snapshot” table230. The process280may be stored in a suitable memory (e.g., memory206) and executed by a suitable processor (e.g., processor(s)202) associated with the cloud capacity server26of the data center instance220. It may be appreciated that, in other embodiments, the process280may include additional steps, fewer steps, repeated steps, and so forth, in accordance with the present disclosure. The discussion of the process280includes references toFIG. 4, discussed above.

For the embodiment illustrated inFIG. 5, the process280may begin with the cloud capacity system222receiving (block282) instructions from a routine or scheduled job to update the “Cloud Capacity Snapshot” table230at a particular time of day, such as during a low-usage time period. In other situations, the cloud capacity system222may be triggered by instructions (e.g., by a database or business rule) to update the “Cloud Capacity Snapshot” table230in response to detecting a change in the “Cloud Capacity Queries” table232(block284). In either case, the cloud capacity system222may respond by first determining (block286) the names of the cloud capacity columns244that have been defined in the “Cloud Capacity Snapshot” table230. For example, the cloud capacity system222may query the “Cloud Capacity Snapshot” table230or another suitable table (e.g., the “Data center” table238) to identify the names of the cloud capacity columns244defined in the “Cloud Capacity Snapshot” table230.

For the embodiment illustrated inFIG. 5, the process280continues with the cloud capacity system222selecting (block288) or retrieving cloud capacity queries from the “Cloud Capacity Queries” table232that correspond to the names of the cloud capacity columns244of the “Cloud Capacity Snapshot” table230determined in block286. For example, the cloud capacity system222may query the “Cloud Capacity Queries” table232to retrieve the query information (e.g., the values stored in the “Query” field248, the “Combination Operation” field256, the “Combination Operation Column” field260, and so forth) for each entry that is related to the cloud capacity columns244of the “Cloud Capacity Snapshot” table230.

For the embodiment illustrated inFIG. 5, the process280continues with the cloud capacity system222updating (block290), for each pod of the data center18, the cloud capacity URLs stored in the “Cloud Capacity URLs” table234, based on the selected cloud capacity queries. That is, the cloud capacity system222may modify the “CC URL” field268of each entry in the “Cloud Capacity URLs” table234to encode the details of the corresponding cloud capacity query selected in block288. For example, the cloud capacity system222may modify the “CC URL” field268of an entry in the “Cloud Capacity URLs” table234to encode the value stored in the “Pod ID” field264of the entry in the “Cloud Capacity URLs” table234, as well as the values stored in the “Query” field248, the “Combination Operation” field256, and the “Combination Operation Column” field260of the corresponding cloud capacity query. It may be appreciated that, for situations in which new cloud capacity fields244were added to the “Cloud Capacity Snapshot” table230and new corresponding entries were added to the “Cloud Capacity Queries” table232, new entries are added to the “Cloud Capacity URLs” table234during the updating of block290.

For the embodiment illustrated inFIG. 5, the process280continues with the cloud capacity system222executing (block292) each of the queries encoded by the cloud capacity URLs stored in the “Cloud Capacity URLs” table234to calculate each corresponding cloud capacity metric value for each pod of the data center18. As discussed above, since the calculation of each cloud capacity metric of each pod of the data center18is embodied as a distinct value of a “CC URL” field268in the “Cloud Capacity URLs” table234, accessing (e.g., selecting, requesting, resolving, following) the location identified each “CC URL” field268results in the database server104executing the encoded query to calculate the value of the corresponding cloud capacity metric for the particular pod of the data center18.

As mentioned, when executed by the database server104in response to the cloud capacity URL being accessed, each query encoded by a cloud capacity URL calculates a numerical value (e.g., an integer) as a result for the corresponding cloud capacity metric. For example, in certain embodiments, a first portion of a cloud capacity URL, which encodes the value of the filter criteria240of the associated cloud capacity query for a particular pod, may select a number of records from a database table based on the specified filter criteria. A second portion of the cloud capacity URL, which encodes the “Combination Operation” field256and the “Combination Operation Column” field260of the associated cloud capacity query, may combine the values of the identified column in the specified manner, for example, by counting the number of values, calculating a sum of the values, calculating an average of the values, selecting a minimum of the values, selecting a maximum of the values, or another suitable combination of the values in the identified column. As such, the output of the second portion of the cloud capacity URL is the calculated value of the corresponding cloud capacity metric.

For the embodiment illustrated inFIG. 5, the process280concludes with the cloud capacity system222updating (block294) the cloud capacity fields244of the “Cloud Capacity Snapshot” table230using the cloud capacity metric values calculated in block292. For example, in certain embodiments, each of the cloud capacity fields244of the “Cloud Capacity Snapshot” table230are updated to store the numerical value of the cloud capacity metric that is returned in response to following the corresponding cloud capacity URL for a particular pod and cloud capacity column combination. As mentioned, in other embodiments, the cloud capacity fields244of the “Cloud Capacity Snapshot” table230may instead be updated to store a respective URL, distinct from the cloud capacity URL, which may be referred to herein as a snapshot URL for clarity. For example, each of the cloud capacity fields244of the “Cloud Capacity Snapshot” table230may be updated to include a respective snapshot URL that presents (e.g., as the URL name) the calculated value of the associated cloud capacity metric, wherein the snapshot URL points or refers to the query results of the first portion of the query encoded by the cloud capacity URL, which represents the underlying data from which the cloud capacity metric value was calculated. For such embodiments, as discussed below, when the “Cloud Capacity Snapshot” table230is presented by the GUI226, the contents of each of the cloud capacity fields244may be presented as a snapshot URL that presents the calculated value of the cloud capacity metric, and that, upon selection, presents a table that includes the underlying data that was combined to calculate the cloud capacity metric value. As mentioned, in certain embodiments, prior to updating the “Cloud Capacity Snapshot” table230, the contents may be added to the “Cloud Capacity Archive” table236to preserve the previous information for cloud capacity trend analysis.

FIGS. 6-9are simulated screenshots of portions of the GUI226for an embodiment of the cloud capacity system222. More specifically, the portion of the GUI226illustrated inFIG. 6is designed to present the contents of the “Cloud Capacity Snapshot” table230to a suitable user (e.g., a data center administrator). As such, the GUI226includes a table300having columns302that correspond to columns, and rows304that correspond to entries or records, of the “Cloud Capacity Snapshot” table230. As such, the table300of the GUI226presents a “Pod ID” column302A, and each of the rows304includes a value in this field indicating which pod is described by the row. The illustrated table300of the GUI226includes a number of cloud capacity columns244of the “Cloud Capacity Snapshot” table230, including a “Instances Prods” column302B that presents a number of production instances hosted by each pod, an “Instances Subs” column302C that presents a number of substitution or backup instances hosted by each pod, an “Instance Demos” column302D that presents a number of demo instances hosted by each pod, an “Instance Devs” column302D that presents a number of developer instances hosted by each pod, a “Shared Points DB Avail” column302E that presents a number of shared database points or servers that are available to each pod, a “Shared Points DB Used” column302F that presents a number of shared database points that are used by each pod, and so forth. It may be appreciated that the table300of the GUI226, as well as the underlying “Cloud Capacity Snapshot” table230, may include any suitable number of cloud capacity columns244that present and store values for various cloud capacity metrics. In certain embodiments, the GUI226includes an “Add Cloud Capacity Column” button303that, in response to receiving user input, causes the cloud capacity system222to create a new cloud capacity column244in the “Cloud Capacity Snapshot” table230.

As mentioned, for the embodiment illustrated inFIG. 6, each of the cloud capacity fields244of the table300includes a respective snapshot URL306. Each snapshot URLs306presents the value of the corresponding cloud capacity metric, which may be calculated as set forth above. Additionally, each of the snapshot URLs306points to or encodes a query for the underlying data from which the corresponding cloud capacity metric was calculated. For example, in response to receiving a user selection of URL306A, which indicates that pod “DVB401” has 671 production instances, the GUI226may present the user with new table that displays information for the671production instances hosted by pod “DVB401.” In certain embodiments, the query encoded by the snapshot URL306A may include the filter criteria248of the particular cloud capacity query that is associated with the cloud capacity column302B, along with an additional filter criteria to limit the data to resources associated with pod “DVB401.”

The portion of the GUI226illustrated inFIG. 7presents the contents of the “Cloud Capacity Queries” table232. As such, the GUI226includes a table310, wherein the columns312of the table310correspond to columns, and the rows314correspond to entries or records, of an embodiment of the “Cloud Capacity Queries” table232. The illustrated portion of the GUI226also includes an editing section316having suitable user input mechanisms (e.g., text boxes, select boxes, check boxes) to enable the user to update one or more fields of a record selected in the table310.

The columns312of the table310include column312A that corresponds to the “CC field name” field246, column213B that corresponds to the “Combination Operation” field256, column312C that corresponds to the “Combination Operation Column” field256, and column312D that corresponds to the “Query” field248of the “Cloud Capacity Queries” table232discussed above. For the illustrated embodiment, the table310of the GUI226and the underlying “Cloud Capacity Queries” table232include a “Table Name” column312E that presents and stores the name of the database table on which the query is applied, while in other embodiments, this table name may be includes as part of the “Query” field248. For the illustrated embodiment, the columns312include a “Unit” column312F that presents and stores a unit for the corresponding cloud capacity metric. Additionally, the illustrated table310includes a “Created” column312G and an “Updated” column312H, which correspond to the audit fields270of the “Cloud Capacity URLs” table234.

In certain embodiments, when the user selects a “Query” text box318of the editing section316of the GUI226illustrated inFIG. 7, the cloud capacity system222may present the user a query editor330of the GUI226, as illustrated inFIG. 8. That is, in addition to enabling the user to provide text to define the value of the “Query” field248of the “Cloud Capacity Queries” table232, the query editor330of the cloud capacity system222may enable the user to visually construct the query by providing selections that define the filter criteria248for the query. It may be appreciated that these features of the cloud capacity system222enable different data center pods to have different customized queries to calculate different cloud capacity metrics. For example, using these features, an administrator may design a first query for a particular instance count metric which includes developer instances when it is calculated for a pod of a first data center, and design a second query for the instance count metric which excludes developer instances when it is calculated for a pod of a second data center.

For the embodiment illustrated inFIG. 8, the query editor330includes a first set of select boxes332that may be populated with properties or fields of the table indicated in the “Table Name” field312E for the embodiment illustrated inFIG. 7. The query editor330includes a second set of select boxes334that are populated with comparison operations, such as “contains”, “does not contain”, “is”, “is not”, “belongs to”, “does not belong to”, and so forth. The query editor330also includes a third set of user input mechanisms336, which include text boxes, as well as select boxes populated with known values (e.g., true or false), depending on the data type of the property indicated by the select boxes332.

To construct the illustrated filter criteria248, the user selects the “Server attributes” parameter or field using the first set of select boxes332. The user selects the appropriate comparison operations for each filter criterion using the second set of select boxes334. The user then provides suitable values for each filter criterion using the third set of user input mechanisms336. For the illustrated example, each of the illustrated filter criterion are combined with an “AND” Boolean operator, and additional filter criteria may be added by selecting the “AND” button338or the “OR” button340. Additionally, a particular filter criterion may be removed in response to the user selecting the corresponding “Remove filter” button342. Once the query editor330receives input from the user selecting the “Save” button344, then the query editor330may convert the filter criteria illustrated inFIG. 8to a text string that is used to populate the “Query” field248of the corresponding entry in the “Cloud Capacity Queries” table232.

The portion of the GUI226illustrated inFIG. 9is designed to present information stored within the “Cloud Capacity URLs” table234. As such, the GUI226includes a table350having columns352that correspond to the columns, and rows354that correspond to the entries or records, of an embodiment of the “Cloud Capacity URLs” table. The columns352include column352A that corresponds to the “CC Field Name” field266, column352B that corresponds to the “Pod ID” field264, column352C that corresponds to the “CC URL” field268, in addition to other fields. As mentioned above, the “Cloud Capacity URLs” table234is automatically generated in response to changes to the “Cloud Capacity Queries” table232or in response to a call from a scheduled (e.g., hourly, daily, nightly) job.