Dedicated cloud region on customer premises

Abstract

Techniques are disclosed for managing aspects of a dedicated regional cloud ("DRCC") at a customer location. The DRCC may include cloud infrastructure components provided by a cloud provider and hosted by computing devices located at the customer's ("cloud owner's") location. Services of a central cloud computing environment may similarly execute in the DRCC. The DRCC may include services configured to collect, store, and / or present data corresponding to the cloud infrastructure components via one or more interfaces (e.g., interfaces provided to the cloud provider and / or cloud owner). Data collected within the DRCC (e.g., capacity and usage data, etc.) may be provided and made accessible to a central cloud at any suitable time. Retrieval of such data enables users to view various operational aspects of the DRCC, while enabling systems and / or users to perform various DRCC-specific operations related to capacity planning, health and performance, change management, etc.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a continuation of U.S. Provisional Patent Application No. 63 / 398,134, filed August 15, 2022, entitled "Multiple Top-of-Rack (TOR) Switches Connected to a Network Virtualization Device," U.S. Provisional Patent Application No. 63 / 402,026, filed August 29, 2002, entitled "Dedicated Cloud Regions at Customer Premises," U.S. Provisional Patent Application No. 63 / 379,427, filed October 13, 2022, entitled "Dedicated Cloud Regions at Customer Premises," U.S. Provisional Patent Application No. 63 / 381,262, filed October 27, 2022, entitled "Network Architecture For Dedicated Region Cloud At Customer (DRCC)," and U.S. Provisional Patent Application No. 63 / 381,262, filed October 27, 2022, entitled "Dedicated Cloud Regions at Customer Premises." This application claims priority to U.S. patent application Ser. No. 18 / 449,615, filed Aug. 14, 2023, entitled "U.S. Patent Application No. 20 ...

[0002] FIELD OF THE INVENTION The present disclosure generally relates to techniques for managing data associated with and derived from a Dedicated Region Cloud at Customer (DRCC). The DRCC hosts infrastructure and services provided by a Cloud Service Provider (CSP) (also referred to as a "cloud provider" for simplicity) that are deployed and run on computing devices physically located in the cloud customer's data center. The disclosed systems, methods, devices, and services enable data that was previously inaccessible to the customer to be processed and presented to the customer, and synchronize this data to a centralized cloud. [Background technology]

[0003] background In cloud computing, processing and storage are generally performed by one or more service providers implemented at a centralized location. Data can be received from customers at the centralized location, processed there, and then the processed (or other) data can be transmitted back to the customers. However, having a centralized location for cloud infrastructure components is not ideal for all users. Some users may prefer to host cloud infrastructure components on hardware located on their own premises. Such users may generally be referred to as "cloud owners." Cloud owners may have unique needs and challenges related to hosting these resources, including, but not limited to, capacity management, growth management, health and performance tracking, change management, etc. The techniques discussed herein are intended to address these aspects of cloud management. Summary of the Invention

[0004] Quick Overview In the following description, for purposes of explanation, specific details are set forth in order to provide a thorough understanding of some embodiments. However, it will be apparent that various embodiments may be practiced without these specific details. The illustrations and description are not intended to be limiting.

[0005] Some embodiments may include a method. The method may include a computing device implementing a dedicated regional cloud including multiple cloud infrastructure components that provide, at least in part, corresponding cloud services associated with a cloud service provider. In some embodiments, the multiple cloud infrastructure components may be hosted by one or more computing devices located at a third-party location. The third-party location may be associated with a third-party entity different from the cloud service provider. The method may include the computing device obtaining capacity and usage data associated with at least one of the multiple cloud infrastructure components. The method may include the computing device executing, in the dedicated regional cloud located at the third-party location, a control center service that processes at least a portion of the capacity and usage data associated with at least one of the multiple cloud infrastructure component components and presents it in a user interface hosted within the dedicated regional cloud. The method may include the computing device storing the capacity and usage data in a data store of the dedicated regional cloud for later use.

[0006] In some embodiments, the capacity and usage data is initially obtained by a data processing service running in a tenancy separate from the tenancy associated with the third-party entity.

[0007] In some embodiments, the capacity and usage data presented in the user interface includes physical space data indicating the number of units of physical space available for placing additional computing devices at the third-party location.

[0008] In some embodiments, the user interface hosted within the dedicated region cloud is implemented at least in part based on a console plug-in installed on an existing dedicated region console of the dedicated region cloud.

[0009] In some embodiments, the capacity and usage data includes first capacity and usage data corresponding to a third-party entity and second capacity and usage data corresponding to a cloud service provider.

[0010] In some embodiments, by storing the capacity and usage data in a data store of a dedicated regional cloud, the capacity and usage data is obtained by one or more corresponding computing devices of a central cloud computing environment hosted by a cloud service provider.

[0011] In some embodiments, at least one of the one or more corresponding computing devices of the central cloud computing environment presents the first capacity and usage data along with additional capacity and usage data obtained from one or more additional dedicated regional clouds individually associated with the respective third-party entities.

[0012] Systems, devices, and computer media are disclosed, each of which may include one or more memories capable of storing instructions corresponding to the methods disclosed herein. The instructions may be executed by one or more processors of the disclosed systems and devices to perform the methods disclosed herein. One or more computer programs may be configured to perform operations corresponding to the described methods by including instructions that, when executed by one or more processors, cause the one or more processors to perform those operations.

[0013] To easily identify the discussion of any particular element or act, one or more of the most significant digits of a reference number will refer to the figure number in which that element is first introduced. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is a block diagram of an environment in which a dedicated region cloud ("DRCC") is hosted at a customer, according to at least one embodiment. [Figure 2] FIG. 1 is a block diagram illustrating an example flow for obtaining operational data corresponding to a DRCC, according to at least one embodiment. [Figure 3] FIG. 1 is a block diagram illustrating an overview of a number of software tools available to various entities serving cloud providers and / or customers, according to at least one embodiment. [Figure 4] FIG. 1 is a block diagram illustrating an exemplary user interface presenting data corresponding to multiple DRCCs, according to at least one embodiment. [Figure 5] FIG. 10 is a block diagram illustrating an exemplary user interface presenting DRCC usage detail data, according to at least one embodiment. [Figure 6] 1 is a block diagram illustrating an example user interface presenting data corresponding to one or more DRCC regions of a realm associated with a single cloud owner. [Figure 7] 1 is a block diagram illustrating an example user interface presenting a region view of a DRCC region, according to at least one embodiment. [Figure 8] FIG. 10 is a block diagram illustrating another exemplary user interface presenting data corresponding to multiple DRCCs, according to at least one embodiment. [Figure 9] FIG. 1 is a block diagram illustrating an exemplary user interface presenting an executive capacity dashboard, according to at least one embodiment. [Figure 10] FIG. 1 is a block diagram illustrating an exemplary user interface presenting a region list in accordance with at least one embodiment. [Figure 11] FIG. 1 is a block diagram illustrating an exemplary user interface presenting capacity information corresponding to multiple regions, according to at least one embodiment. [Figure 12] FIG. 10 is a block diagram illustrating an exemplary user interface presenting region details in accordance with at least one embodiment. [Figure 13] FIG. 1 is a block diagram illustrating an exemplary user interface presenting details of computes corresponding to a single region, according to at least one embodiment. [Figure 14] FIG. 14 is a block diagram illustrating an expanded view of the user interface component of FIG. 13 according to at least one embodiment. [Figure 15] FIG. 1 is a block diagram illustrating an exemplary user interface presenting block storage details corresponding to a single region, according to at least one embodiment. [Figure 16] FIG. 1 is a block diagram illustrating an exemplary user interface presenting object storage details corresponding to a single region, according to at least one embodiment. [Figure 17]FIG. 1 is a block diagram illustrating an exemplary user interface presenting file storage details corresponding to a single region, according to at least one embodiment. [Figure 18] FIG. 1 is a block diagram illustrating an exemplary user interface presenting details of a database corresponding to a single region, according to at least one embodiment. [Figure 19] FIG. 1 is a block diagram illustrating an exemplary user interface presenting details of a physical space corresponding to a single region, according to at least one embodiment. [Figure 20] FIG. 1 is a block diagram illustrating an exemplary user interface presenting details of server hardware corresponding to a single region, according to at least one embodiment. [Figure 21] FIG. 1 is a block diagram illustrating an exemplary user interface presenting network hardware details corresponding to a single region, according to at least one embodiment. [Figure 22] FIG. 10 is a block diagram illustrating an example user interface presenting details of power consumption corresponding to a single region, according to at least one embodiment. [Figure 23] FIG. 1 illustrates a number of example schemas, according to at least one embodiment. [Figure 24] FIG. 1 illustrates a number of example schemas, according to at least one embodiment. [Figure 25] FIG. 1 illustrates a number of example schemas, according to at least one embodiment. [Figure 26] FIG. 1 is a block diagram illustrating an example method for obtaining capacity and usage data in a dedicated region cloud, according to at least one embodiment. [Figure 27] FIG. 1 is a block diagram illustrating a pattern for implementing a cloud infrastructure system as a service that includes a dedicated region operating as part of a DRCC, according to at least one embodiment. [Figure 28]FIG. 1 illustrates a high-level structure of an exemplary 12-rack-based footprint on which an IaaS / DRCC architecture is hosted. [Figure 29] FIG. 1 illustrates an arrangement of multiple TORs contained in a rack, according to at least one embodiment. [Figure 30] FIG. 1 illustrates an exemplary infrastructure of a DRCC according to some embodiments. [Figure 31] FIG. 1 illustrates an exemplary network fabric architecture of a DRCC in accordance with some embodiments. [Figure 32] FIG. 1 illustrates connections within an NFAB block, along with connections between the NFAB block and multiple blocks of switches, in accordance with some embodiments. [Figure 33] FIG. 1 is a block diagram illustrating an example computer system according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0015] Detailed Description In the following description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the embodiments being described.

[0016] introduction Infrastructure as a Service (IaaS) is a type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, an IaaS provider can also offer various services (e.g., billing, monitoring, logging, security, load balancing, clustering, etc.) that accompany those infrastructure components. Accordingly, these services can be policy-driven, allowing IaaS users to implement policies that drive load balancing to maintain application availability and performance.

[0017] In some cases, IaaS customers can access resources and services over a wide area network (WAN) such as the Internet and use the cloud provider's services to install the remaining elements of their application stack. For example, a user can log into an IaaS platform to create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software on the VMs. The customer can then use the provider's services to perform a variety of functions, including distributing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0018] In most cases, the cloud computing model requires the participation of a cloud provider. A cloud provider can be, but is not required to be, a third-party service that specializes in providing (e.g., offering, renting, selling) IaaS. In some embodiments, an entity can deploy a private cloud and become its own provider of infrastructure services.

[0019] In some examples, IaaS deployment is the process of placing a new application, or a new version of an application, onto a prepared application server, etc. IaaS deployment may also include the process of preparing the server (e.g., installing libraries, daemons, etc.), which is often managed by the cloud provider below the hypervisor layer (e.g., server, storage, network hardware, and virtualization). Thus, the customer may be responsible for handling the deployment of the (OS), middleware, and / or application (e.g., in self-service virtual machines (e.g., that can be spun up on demand)). IaaS provisioning may refer to obtaining the computers or virtual hosts to be used and also installing the necessary libraries or services on those computers or virtual hosts. In most cases, deployment does not include provisioning, which must be performed first.

[0020] In some examples, the infrastructure can have many interconnected elements. For example, there can be one or more virtual private clouds (VPCs) (e.g., potential on-demand pools of configurable and / or shared computing resources), also known as a core network. In some examples, there can also be one or more security group rules and one or more virtual machines (VMs) provisioned to define how the network is secured. Other infrastructure elements, such as load balancers, databases, etc., can also be provisioned. The infrastructure can evolve over time as more infrastructure elements are desired and / or added.

[0021] In some cases, continuous deployment techniques can be employed to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques can enable infrastructure management within these environments. In some examples, a service team may write code that is desired to be deployed to one or more, but often many, different production environments (e.g., across various different geographic locations, sometimes across the globe). However, in some examples, the infrastructure onto which the code will be deployed must first be set up. In some cases, provisioning can be done manually, utilizing provisioning tools to provision resources, and / or utilizing deployment tools to deploy the code once the infrastructure has been provisioned.

[0022] Dedicated regional cloud in customer environment This disclosure relates to customer-hosted dedicated regional clouds (DRCCs) that provide infrastructure and services provided by cloud service providers (CSPs) (also referred to as "cloud providers" for brevity) that are deployed and run on computing devices physically located in the customer's (e.g., "cloud owner") own data centers. DRCCs enable enterprises to easily consolidate mission-critical database systems, with applications traditionally deployed on expensive hardware being deployed on the CSP's highly available and secure infrastructure, thereby providing operational efficiencies and modernization opportunities.

[0023] The DRCC framework provides full public cloud functionality on-premises, allowing enterprises to reduce infrastructure and operational costs, upgrade legacy applications with modern cloud services, and meet the most stringent regulatory, data residency, and latency requirements, all on the CSP's infrastructure, which provides improved performance and the highest levels of security. Customers gain the choice and flexibility to run all of the CSP's cloud services in their own data centers. Customers can choose from all public cloud services offered by the CSP, including VMware Cloud, Autonomous Database, Container Engine for Kubernetes, Bare Metal Servers, and Exadata Cloud Service, and pay only for the services they consume. The DRCC framework is designed to keep data and customer operations completely isolated from the internet (control and data plane operations remain on-premises), helping customers meet the most stringent compliance and latency requirements. The DRCC framework provides cloud-scale security, resiliency, and scalability, as well as support for mission-critical workloads, with tools to incrementally modernize legacy workloads with a fully managed experience and access to new capabilities the moment they become available in the public cloud.

[0024] In some examples, a dedicated cloud region (and / or realm) can be hosted using hardware located on a customer's (e.g., "cloud owner's") premises. This cloud environment may be referred to as a "dedicated region cloud at customer" (DRCC) environment (or simply "DRCC"). A DRCC can provide services and features similar to those available in centralized cloud environments that are more traditionally managed by a cloud provider on the cloud provider's premises. One example of a centralized cloud (referred to herein as a "central cloud," "OCI cloud," or "public cloud") may be an IaaS environment that is publicly available to many customers and is hosted, for example, on Oracle Cloud Infrastructure (OCI). Similar techniques discussed herein can also be applied to private label clouds. A "private label cloud" (PLC) refers to a cloud environment that is managed by a cloud provider (e.g., Oracle) but is branded as if it were provided by a third party (e.g., a customer). Examples herein are discussed with reference to a DRCC, but any reference to functionality or features provided in a DRCC may similarly be provided in a PLC.

[0025] Hosting the cloud at a customer's location creates unique needs for the cloud owner (e.g., a DRCC customer). DRCC customers differ from standard public cloud customers because they assume increased responsibility for the facilities in which the DRCC operates. DRCC customers may act more like partners with the cloud provider than typical public cloud consumers. While the cloud provider may manage much of the DRCC's infrastructure, customers have substantial responsibility and a stake in ensuring their DRCC functions effectively. This responsibility requires customers to have a different level of insight into the physical infrastructure running in their data centers than public cloud customers.

[0026] Customers can be provided with the tools to effectively manage their DRCC while maintaining the same public cloud (e.g., OCI) experience. DRCC customers require a rich set of tools to manage various aspects of the DRCC (e.g., operations and capacity). The technology disclosed herein differs from the public cloud experience in terms of increased visibility into the DRCC infrastructure and its operational activities, allowing users to access data (via the user interfaces of Figures 4-22 discussed herein) that was previously unavailable and / or inaccessible to the customer.

[0027] The disclosed technology is directed to managing a DRCC and its corresponding data. In some embodiments, an OCI Control Center (OCC) service can be used to provide various tools for managing aspects of the DRCC related to equipment management, consumption reporting, capacity planning, health and performance, change management, and alerts, to name a few. While the user interfaces discussed herein are directed to presenting capacity and usage data corresponding to capacity planning, it should be understood that any suitable combination of data related to equipment management, consumption reporting, capacity planning, health and performance, change management, and alerts may be presented. The term “OCI Control Center (OCC)” is intended to refer to any suitable service configured to manage aspects of the DRCC, whether or not the service is provided by Oracle. In some embodiments, the DRCC includes public cloud resources (e.g., any suitable combination of cloud services offered by OCI), but can provide these resources via a smaller form factor than traditional cloud computing environments (e.g., 33 racks instead of 45 racks). The OCC service can be configured to provide region and / or realm-level information across tenancies and / or compartments. Information provided by the service (e.g., capacity / usage data for each region) can assist users in forecasting and workload planning. By way of example, users can view usage and availability details for compute resources, block storage, object storage, file storage, database resources, physical space (e.g., floor tiles), server resources / racks, network resources / racks, and power consumption. The console (or a console plug-in implemented for an existing console) can be used to display information related to any suitable aspect of managing the DRCC.

[0028] A Horizon service may be utilized to collect various data corresponding to operations provided by the DRCC. The term “Horizon service” refers to any suitable service configured to collect any suitable usage or capacity data corresponding to resources (e.g., hardware, software, physical devices / racks, etc.) of the DRCC. By way of example, this data may relate to any suitable combination of resource capacity, health and performance, change management, scale management, etc. The Horizon service may collect this data at any suitable frequency, such as according to a schedule, on demand, etc. In some embodiments, the data collection process performed by the Horizon service may be invoked / triggered by one or more other services and / or components of the DRCC. Once collected, the data may be stored in a data store that is local to the DRCC. In some embodiments, the data may be pushed to a data store in a public cloud (e.g., OCI), or a corresponding service in a central cloud may be configured to retrieve the data stored in the DRCC's data store. One or more interfaces (e.g., provided by a console plug-in for the DRCC OCC console 128, the DRCC OCC console 128 without a plug-in, etc.) may be utilized to present at least a portion of this data to users of the DRCC. In some embodiments, this data may be specific to a DRCC (e.g., to the realm or region corresponding to the DRCC, including region 102). In some embodiments, a user associated with a cloud provider (e.g., an OCI operator) can view data specific to any suitable number of DRCCs, including the customer's DRCC in the current example.Data obtained from the DRCC can be utilized within a central cloud hosted by a cloud provider at a cloud provider's location, along with DRCCs hosted at customer locations, to display any suitable aspect of operations at the DRCC, such as determining resource capacity and utilization, determining health and performance, performing change management, scaling management, etc., in any suitable combination.

[0029] Technical effects The ability to monitor DRCC data is paramount for capacity planning, facilities management, consumption reporting, health and performance, change management, and the like. Traditional cloud customers did not need to view this information because the cloud provider (OCI) managed the cloud hardware, but with DRCC, customers host the hardware on their own premises. Traditionally, data related to capacity planning, facilities management, consumption reporting, health and performance, change management, and various alerts was provided solely to the cloud provider. Managing such data within the DRCC and providing tools to view this data has not previously been done. With this hardware moving to the customer's premises, it is also necessary to ensure that data is synchronized within the central cloud (OCI). The technology described herein provides users associated with the cloud owner and users associated with the cloud service provider with the ability to retrieve this data. The user interface described herein allows both types of users to manage and monitor various aspects of the DRCC, which is essential to ensure the operational performance of the DRCC's components.

[0030] Turning to the figures, FIG. 1 is a block diagram of an environment 100 in which a dedicated region cloud ("DRCC") is hosted on customer premises and interacts with a cloud provider's public cloud infrastructure, according to at least one embodiment. The region 102 can be one of many DRCCs or private-label clouds (e.g., DRCC / PLC 104). In a DRCC, the customer can own the hardware that hosts the region 102. The region 102 can be managed by a cloud service provider. In a PLC, the hardware owner (e.g., a cloud customer) can utilize the region 102 to offer cloud services to its customers under its own brand.

[0031] Region 1002 may include DRCC resources 106, including, but not limited to, Exadata 108, file system services 110, object storage services 112, block storage services 114, compute services 116, and services 118, which may include any suitable number of services configured to provide cloud services similar to those accessible in a public cloud. OC1 120 may be an example of a public cloud.

[0032] The region 102 can include a DRCC Horizon service 120, which can be configured to obtain capacity and utilization data associated with the hardware hosting the region 102. The capacity and utilization data can include any suitable data related to compute, block storage, object storage, file storage, database resources, physical space, server resources, network resources, power consumption, etc. Specific examples of such data are presented and discussed in more detail below with respect to FIGS. 4-22. In some embodiments, the DRCC Horizon service 120 can be configured to communicate with any suitable combination of DRCC resources 106 to obtain any suitable information corresponding to capacity management, growth management, health and performance tracking, change management, etc.

[0033] In some embodiments, DRCC Horizon service 120 may be a lightweight version of central Horizon service 121 of OC1 120 and may be configured to provide a subset of the functionality provided by central Horizon service 121. By way of example, in some embodiments, DRCC Horizon service 120 may be configured to retrieve only capacity management data, while central Horizon service 121 may be configured to retrieve any suitable combination of capacity management data, expansion management data, health and performance tracking data, and / or change management data.

[0034] The DRCC Horizon service 120 may store any suitable combination of the retrieved data in object storage 122 in a dedicated bucket (e.g., a Horizon bucket) associated with that service. In some embodiments, as discussed in more detail in connection with FIG. 30 , the DRCC Horizon service 120 may run in a tenancy separate from any suitable components of the DRCC resources 106 and / or region 102, as shown in FIG. 1 .

[0035] The region 102 may host an Oracle Control Center (OCC) service 124. The OCC service 124 may be configured to retrieve any suitable data collected by the DRCC Horizon service 120 from object storage 122 (e.g., from a bucket specific / dedicated to the DRCC Horizon service 120) and store the retrieved data in an autonomous data warehouse (e.g., ADW 126). The ADW 126 may be an example of any suitable data store (e.g., an object storage bucket accessible to and managed by the OCC service 124). In some embodiments, the DRCC Horizon service 120 may be configured to store the data it collects directly in the ADW 126, as shown in FIG. 1 . Data retrieveable by the DRCC Horizon service 120 may pertain only to the region 102. The DRCC Horizon service 120 of a given region may not be communicatively connected to any other DRCCs / PLCs of the DRCCs / PLCs 104.

[0036] The OCC service 124 can retrieve any suitable portion of the data stored in the ADW 126 and provide it to the DRCC OCC console 128. In some embodiments, the DRCC OCC console 128 can be configured to present any suitable portion of that data via any suitable number of user interfaces. Examples of such user interfaces are discussed in further detail below with respect to FIGS. 4-22. Using these interfaces, owners of the hardware hosting the region 102 can view data collected by the DRCC Horizon service 120. The data presented by the DRCC OCC console 128 may be specific to the region 102. Data corresponding to other DRCCs and / or PLCs is collected and presented via the respective components of those environments and may not be accessible to the DRCC OCC console 128 of the region 102.

[0037] At 130 (e.g., according to a predefined schedule or at any suitable time), any suitable portion of the data in object storage 122 can be imported into a corresponding object storage bucket associated with central Horizon service 121. Central Horizon service 121 can be configured to retrieve data from this bucket and store the data in Horizon ADW 132, a data store within OC1 120. In some embodiments, Horizon ADW 132 can be a public cloud object storage bucket dedicated to storing data collected by DRCC Horizon service 120. Central Horizon service 121 can be configured to retrieve any suitable data from any suitable number of DRCC PLCs 104 for storage in Horizon ADW 132 in this manner. At 134, any suitable portion of the data stored in Horizon ADW 132 can be provided via one or more data visualizations. By way of example, the data visualizations can be presented to a user (e.g., a public cloud operator) via any suitable user interface.

[0038] OC1 120 may execute a DRCC cloud card web application 136. At 138, the DRCC cloud card web application may export any suitable data from the Horizon ADW 132 to an object storage bucket associated with the central Horizon service 121. By way of example, this data may be presented using the user interfaces discussed below in connection with FIGS. 4-22.

[0039] At 140, DRCC values ​​and forecast data 142 may be imported into an object storage bucket associated with central Horizon service 121. DRCC values ​​and forecast data 142 may include any suitable data provided from any external source, including, without limitation, forecast values ​​corresponding to capacity, usage, costs, orders, revenue, etc. associated with any suitable combination of DRCC / PLC 104. In some embodiments, this information may be provided via any suitable interface (e.g., by DRCC Cloud Card web application 136 and / or DRCC Lifecycle Management Apex application 144).

[0040] In some embodiments, OC1 120 may include a DRCC lifecycle management Apex application 144 that may be configured to retrieve and present data stored in MXP ADW 146. In some embodiments, the data presented by DRCC lifecycle management Apex application 144 may relate to any suitable component of DRCC / PLC 104.

[0041] At 148, data may be exported from the Horizon ADW 132 (e.g., a bucket in object storage associated with the central Horizon service 121) and stored in the MXP ADW 146. Such data may be viewable in the DRCC lifecycle management Apex application 144. In some embodiments, any suitable data (e.g., user input provided via a user interface hosted by the DRCC lifecycle management Apex application 144) may be stored in the MXP ADW 146. At 150, any suitable data stored in the MXP ADW 146 may be imported into an object storage bucket (e.g., the Horizon ADW 132) associated with the central Horizon service 121.

[0042] 1 may be performed any suitable number of times to make data collected at the DRCC / PLC 104 viewable by users of the public cloud via applications in OCI 120. Data collected by each DRCC Horizon service (e.g., the DRCC Horizon service 120 in region 102) may be viewable at any suitable time using the DRCC OCC console 128. In some embodiments, the DRCC OCC console 128 may be configured to provide user interfaces and / or data visualizations (e.g., the data visualizations shown at 134) that may be similar to those provided by the DRCC Cloud Card web application 136 and / or the DRCC Lifecycle Management Apex application 144 and / or the data visualizations 134. However, those user interfaces, data, and / or data visualizations may be DRCC / PLC-specific and may not pertain to other DRCC / PLCs 104.

[0043] Figure 2 is a block diagram illustrating an example flow 200 for obtaining operational data corresponding to a DRCC, according to at least one embodiment. Figure 2 shows a number of components of a DRCC, such as the DRCC corresponding to region 102 in Figure 1. The following components and flow 200 may be applied to a private label cloud as well.

[0044] The DCC 204 may be a software component configured (e.g., by a timer and / or via a predetermined schedule or frequency) to trigger the collection of metrics obtained by the DRCC Horizon service 206. The DRCC Horizon service 206 may be an example of the DRCC Horizon service 120 of FIG. 1. In some embodiments, the DRCC Horizon service 206 may collect capacity and / or usage data associated with the hosting region 102. The capacity and / or usage data may be associated with any suitable combination of compute resources, object storage, block storage, file storage, database resources, physical space, server devices, networking devices, and / or power consumption. The DRCC Horizon service 206 may be configured to communicate with any suitable combination of the DRCC resources 106 of FIG. 1 to obtain any suitable information corresponding to capacity management (e.g., capacity and usage data), growth management, health and performance tracking, change management, etc. This data may collectively be referred to as “metric data.” The DRCC Horizon service 206 may perform data collection operations according to its own internal schedule or a predefined periodicity. The collected data may be stored (e.g., via a PUT command, etc.) by the DRCC Horizon service 206 in an object storage bucket (e.g., an object storage bucket dedicated to the Horizon service, such as an object storage bucket ("Horizon bucket," not shown)). In some embodiments, data storage and retrieval may be performed by issuing requests to an object storage service 208, which may be configured to manage object storage (including the Horizon bucket).DCC204 can trigger DataFlow service 210 to retrieve (e.g., read using object storage service 208) the metric data stored in the object storage bucket at any suitable time or according to any suitable predetermined frequency and / or schedule.

[0045] In some embodiments, the DRCC Horizon service 206 may include an event adapter 212, which may be configured to similarly invoke the DataFlow service 210 to retrieve metric data from object storage buckets (e.g., utilizing a REST API corresponding to the object storage service 208). In some embodiments, any suitable combination of the DCC 204 and / or the event adapter 212 may be utilized to invoke the functionality of the DataFlow service 210.

[0046] In some embodiments, multiple (e.g., two, three, etc.) instances of DCC 204 can be utilized for multi-node arbitration and redundancy. That is, each DCC 204 instance can attempt to perform a lock (e.g., a daily lock) on ADW 216. If the lock is successful, the corresponding instance can proceed to invoke the dataflow application. Otherwise (because another instance of DCC 204 has already locked ADW 216), the instance can stop execution.

[0047] The DataFlow service 210 may run any suitable number of jobs (e.g., Spark jobs 214) to collect and / or transform data from object storage buckets (utilizing a REST API associated with the object storage service 208). In some embodiments, the Spark jobs 214 may perform any suitable pre-defined transformations on the collected data and may be configured to write the transformed data to the ADW 216 (and example ADW 126 in FIG. 1).

[0048] A console plug-in user interface (UI) 218 ​​can be utilized at any suitable time to request and / or display any suitable portion of the metric data. In some embodiments, the console plug-in UI 218 is an example of the DRCC OCC console 128 of FIG. 1. Input provided via the console plug-in UI 218 can be submitted as a query via a REST API 220 (e.g., directly or via the OCC service 124 of FIG. 1). The REST API 220 can be configured to provide access to region-specific metric data within the ADW 216. In some embodiments, queries can pass through a DB abstraction layer 222. The DB abstraction layer 222 can be a read-only layer that shields the REST API 220 from the details of how data is stored in the underlying database (e.g., the ADW 216).

[0049] Canary service 224 (an example of a health collection service) can be configured to perform health checks 226 of various services and / or components (e.g., DCC 204, DataFlow service 210, DRCC Horizon service 206, object storage service 208, etc.). Health checks 226 (e.g., collection of metrics related to the health of the aforementioned services) can be performed at any suitable time with any suitable frequency and / or according to a predetermined schedule.

[0050] The ADW lifecycle management application 228 may be a software component configured to manage the lifecycle of an ADW database, including, but not limited to, managing changes to the schema, scheduling SQL jobs, etc. In some embodiments, the ADW lifecycle management application 228 may utilize Liquibase to manage these aspects of the ADW 216. The lifecycle management operations of the ADW lifecycle management application 228 may be determined, at least in part, based on reading the Liquibase change log data 230 corresponding to the ADW 216.

[0051] Another computing component of the DRCC may perform operations to install / setup / patch the DataFlow service 210 at 232. For example, instructions to perform the operations may be stored in the DataFlow service 210 as part of the installation performed at 232. In some embodiments, the operations performed at 232 may include installing and / or rotating credentials for the ADW 216 stored in the Vault service 234.

[0052] The flow 200 may begin at step 1, where credentials for the ADW 216 are installed in the Vault service 234. In step 2, instructions for the DataFlow service 210 and credentials for the ADW 216 may be installed.

[0053] In step 3, functionality of the DCC 204 can be invoked (e.g., by a function call initiated by the event adapter 212, or via a timer, according to a predetermined schedule or frequency, etc.). In some embodiments, functionality of the DCC 204 can be invoked using a REST API corresponding to the DCC 204.

[0054] In step 4, the DCC 204 may attempt to perform a lock on the ADW 216. If unsuccessful, the DCC 204 may stop processing and the flow may be stopped. Otherwise, in step 5, the DCC 204 may invoke the DataFlow Application of the DataFlow Service 210.

[0055] The DRCC Horizon service 206 may have previously collected metric data and stored this data in a dedicated bucket (not shown) associated with the service by executing a PUT data command on the object storage service 208. These operations are shown in step 6 and may occur at any suitable time.

[0056] In step 7, DataFlow service 210 may read (or otherwise obtain from object storage service 208) the metrics data collected by DRCC Horizon service 206 and previously stored in a Horizon bucket by object storage service 208 according to the instructions installed in step 2. DataFlow service 210 may run Spark job 214 to collect and / or transform that data. In step 8, Spark job 214 may be configured to read and / or obtain a password (or other credential) for ADW 216 from Vault service 234. In step 9, Spark job 214 may write the collected and / or transformed data to ADW 216 (e.g., using the previous credentials installed in DataFlow service 210 or the credentials obtained in step 8).

[0057] At step 10 (or at any suitable time), input may be received at the console plug-in UI 218 to access metric data stored in the ADW 216. In some embodiments, this input may be obtained from one of the user interfaces of Figures 4-22 presented by the console plug-in UI 218. At step 11, the user input may be passed through the REST API 220 and DB abstraction layer 222 to query the ADW 216 for the requested metric data.

[0058] At any suitable point, ADW lifecycle management application 228 may read Liquibase change log data 230 in step 12 to identify and implement changes to ADW 216. Canary service 224 (an example of a service or application that performs health checks and / or collects health-related data for one or more other components) may perform health check 226 in step 13 to collect health-related data corresponding to other components in Figure 2. In some embodiments, canary service 224 requests metric data (e.g., via REST API 220 and DB abstraction layer 222) to identify the health of other components in Figure 2 (e.g., DRCC Horizon service 206, DataFlow service 210, etc.) and / or components of the DRCC (e.g., DRCC resources 106 of Figure 1).

[0059] 8 illustrates an example user interface (e.g., user interface 800, one of user interfaces 308 in FIG. 3). As shown, user interface 800 presents data regarding live customers, signed customers, and pipeline customers corresponding to multiple DRCCs / PLCs (each an example of DRCC / PLC 104 in FIG. 1). As shown, user interface 800 displays the customer identifier, status, region, country, quantity, and status details of the DRCC / PLC. Although provided in a tabular format, the data presented in user interface 800 may be formatted differently.

[0060] 3 is a block diagram 300 that provides an overview of a number of software tools available to various cloud provider and / or customer-facing entities, according to at least one embodiment. Service provider tools (e.g., tools 302) can include a management dashboard 305. In some embodiments, management dashboard 305 can be used to display lifecycle management data and financial information related to any suitable number of DRCCs (and / or PLCs), such as DRCC / PLC 104 of FIG. 1.

[0061] The tools 302 may include any suitable number of deployment management tools 306 (e.g., portals) to support end-to-end tracking of the deployment or expansion of a DRCC / PLC (e.g., DRCC / PLC 104 of FIG. 1). In some embodiments, the deployment management tools 306 may be available to, among others, region teams, service teams, and account teams of the DRCC / PLC.

[0062] The tools 302 may include a user interface 308. The user interface 308 (e.g., FIGS. 5-24) may be utilized for any suitable combination of order tracking, incident management, equipment management, consumption reporting, capacity planning, change management, and alerts, to name a few. In some embodiments, the user interface 308 may be utilized by, among others, the DRCC / PLC's region teams, service teams, and account teams.

[0063] The tools 302 may include an application programming interface (API) 310. The API 310 may be utilized to access metric data and / or data used by cloud lifecycle management tools (e.g., the ADW lifecycle management application 228 of FIG. 2). In some embodiments, the API 310 may be utilized by, among other things, the DRCC / PLC's regional and service teams.

[0064] The tools 304 may include a DRCC console 312 (an example of the DRCC OCC console 128 of FIG. 1). The DRCC console 312 may be utilized to access metric data and / or data used for equipment management, consumption reporting, capacity planning, change management, and alerts, among other uses. In some embodiments, the DRCC console 312 may be utilized by, among other things, DRCC / PLC regional and service teams. The DRCC console 312 may present any suitable combination of this data in any suitable combination of the user interfaces of FIGS. 4-22, which are discussed in more detail below.

[0065] 4 is a block diagram illustrating an exemplary user interface (e.g., user interface 400, an example of user interface 308 of FIG. 3) that presents data corresponding to multiple DRCCs, according to at least one embodiment. As shown, user interface 400 presents data (e.g., capacity planning information) corresponding to multiple DRCCs / PLCs (each an example of DRCC / PLC 104 of FIG. 1).

[0066] User interface 400 may include any suitable number of graphical elements representing individual realms, including one or more DRCCs, or any suitable region (e.g., PLC, government region, commercial region, etc.). By way of example, graphical element 402 represents realm "RLM1" that includes regions "R1" and "R2," and graphical element 404 represents another realm "RLM2" that includes region "R1." These realms and corresponding regions may correspond to the same or different customers / cloud owners. As shown, realms RLM1 and RLM2 correspond to different cloud owners.

[0067] As illustrated in graphical elements 402 and 404, any suitable customer and / or DRCC-related data may be presented, including, but not limited to, a customer identifier, a subscription identifier, a DRCC (or PLC) identifier, a realm identifier, a region identifier / version, etc. In some embodiments, a graphical element (e.g., graphical element 402) may include additional elements (e.g., element 407) that present capacity and usage data indicating, for example, any suitable combination of compute core usage / availability, block storage usage / availability, object storage usage / availability, and / or file system storage usage / availability.

[0068] Element 408 indicates the total amount of CPU cores with region R1 of DRCC B, and portion 410 indicates the number of CPUs currently being used. Elements 412, 414, and 416 may similarly present the total amount of block storage, object storage, and file system storage, with each portion (e.g., shaded similar to portion 410) presenting the currently used amount of block storage, object storage, and file system storage, respectively. The data presented in user interface 400 may be formatted differently, may include additional data, or may lack some of the data shown in FIG. 4. A graphical element similar to element 407 may be presented for any DRCC in a realm. In some embodiments, element 407 may show an image (e.g., "order pending") when a region is not yet available / operational.

[0069] FIG. 5 is a block diagram illustrating an exemplary user interface 500 presenting DRCC usage detail data, according to at least one embodiment. User interface 500 is another example of user interface 308 of FIG. 3. As shown, user interface 500 presents a DRCC usage dashboard 502 corresponding to multiple DRCCs / PLCs (each an example of DRCC / PLC 104 of FIG. 1). As shown, DRCC usage dashboard 502 can include a table presenting usage data corresponding to any suitable DRCC region code, DRCC region common name, and any suitable combination of hardware processor (e.g., AMD, Intel, high-density Intel, etc.), block storage usage, file system storage, and physical space. In some examples, blocks in user interface 500 can be colored according to predefined thresholds to indicate utilization. By way of example, resources that are maxed out (e.g., at or above a 90 percent threshold) may be represented in red. Resources that breach another threshold (e.g., 80-90 percent utilization) may be represented in yellow, and all other blocks that do not breach any threshold may be represented in green.

[0070] In some embodiments, the user interface 500 may include DRCC usage details 504. As shown, the DRCC usage details 504 may include a table presenting usage data corresponding to any suitable DRCC region code, DRCC region common name, and any suitable combination of hardware processor (e.g., AMD, Intel, high-density Intel, etc.), block storage usage, file system storage, and physical space. For each region, the table may represent metrics such as total capacity, available resources, unavailable resources, the number of resources used by the cloud provider (e.g., OCI), the number of resources used by the customer (e.g., cloud owner), the number of resources used for overhead, and the number of resources identified as a corrupted pool (e.g., at least temporarily unavailable). Block and file system storage usage may be expressed in tebibytes (TiB) of data capacity, where 1 TiB is 1024 bytes. 4 Blocks with DRCC usage details 504 may similarly be colored according to predefined thresholds to indicate utilization, where resources that are maxed out (e.g., above a 90 percent threshold utilization) may be represented in red, resources that have breached another threshold (e.g., between 80 and 90 percent utilization) may be represented in yellow, and all other blocks that do not breach any threshold may be represented in green.

[0071] DRCC usage dashboard 502 and / or DRCC usage details 504 may include data related to any suitable number of DRCCs and / or may include more or less data than shown in FIG.

[0072] 6 is a block diagram illustrating an exemplary user interface (e.g., user interface 600, one of user interfaces 308 in FIG. 3) that presents data corresponding to one or more DRCC regions of a realm associated with a single cloud owner (e.g., RLM1 in FIG. 4), according to at least one embodiment. Utilizing user interface 600, an operator of the DRCC / PLC and / or an operator associated with a cloud provider can view any suitable information regarding RLM1's DRCC / PLC. As shown, user interface 600 provides an operator (e.g., a DRCC operator or cloud provider (CP) operator) with an aggregated view of all regions deployed within a customer's realm.

[0073] User interface 600 includes an activities section 602, which may be configured to present any suitable data related to events scheduled to occur within realm RLM1. As shown, activities section 602 shows an upgrade event and two capacity expansions, although any suitable number and / or type of events may be shown within activities section 602.

[0074] User interface 600 may include a region list containing any suitable number of graphical elements corresponding to a given region presented in section 604 (e.g., DRCC region "Region 1"). Section 604 may include a graphical element similar to element 408 of FIG. 4 to indicate total available resources and currently used resources. By way of example, element 606 (alone or in combination with text 608) may indicate a number of cores (e.g., 1,852) currently in use and a number (e.g., 4,148 cores) available. In some embodiments, text 610 may be included to textually indicate the percentage of cores used. Similar elements may be provided as illustrated in FIG. 6 to present corresponding information related to the availability and usage of block storage, object storage, and file system storage.

[0075] In some embodiments, user interface 600 may include indicators (e.g., indicators 612) that may be colored (e.g., red, yellow, green, etc.) according to a predefined scheme to indicate the status of various services and / or features within a region. By way of example, indicator 612 may be colored (e.g., green) to indicate that a given feature or service is operational and / or available.

[0076] The data presented in user interface 600 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0077] 7 is a block diagram illustrating an exemplary user interface (e.g., user interface 700, one of user interfaces 308 of FIG. 3) presenting a regional view of a DRCC region, according to at least one embodiment. User interface 700 may be accessible from selecting any suitable region using section 604 of FIG. 6. User interface 700 may be utilized to view any suitable information associated with a region of a DRCC / PLC. As shown, user interface 700 presents information similar to that presented in 702 and 704 of FIG. 6 (corresponding to activity sections 602 and 604 of FIG. 6, respectively).

[0078] In some embodiments, additional details associated with a region may be presented in Figure 7. By way of example, user interface 700 may present at 706 a number of support tickets associated with software patches, maintenance work, errors, or any suitable aspect of supporting and / or maintaining the software, hardware, or physical space of the DRCC.

[0079] The data presented in user interface 700 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0080] FIG. 8 is a block diagram illustrating another exemplary user interface (e.g., user interface 800, one of user interfaces 308 of FIG. 3) presenting data corresponding to multiple DRCCs, according to at least one embodiment. Region 802 of user interface 800 may be a navigation panel including any suitable number of links or shortcuts that can be used to navigate to other interfaces, discussed later. The content of region 802 may be updated, at least in part, based on user input (e.g., a selection made in region 802, a selection made in region 810, etc.). As shown, user interface 800 may correspond to navigation item 806, while selection of navigation item 808 may be used to navigate the user to user interface 900 of FIG. 9. Each navigation may update the content of region 802 to correspond to the user interface being presented.

[0081] User interface 800 may include region 808, which may include any suitable number of user interface elements for filtering the data provided in region 810. By way of example, region 808 may include an element for conducting a search of data associated with the realm presented in region 810 and one or more additional filter options (e.g., filter option 812) that may be used to further filter the items displayed in region 810. By way of non-limiting example, filter option 812 may be deployed and used to filter the items displayed in region 810 based on a region status associated with the region (e.g., a DRCC region), and the items presented in region 810 may be modified to filter based on input provided using filter option 812. The additional filter options displayed in region 808 may allow a user to filter by realm type, geographic region, geographic country, DRCC version, target activation date, and target whitespace date, although other possible filters are also contemplated.

[0082] Region 810 may include a user interface element 814 that represents a single realm (e.g., "RLM8"). Any suitable number of regions (e.g., DRCC regions) may be associated with a realm. Any suitable number of user interface elements similar to user interface element 814 may be presented in region 810 to represent respective realms. As shown, user interface element 814 is associated with realm "RLM8," which is associated with two regions, "RG8A" and "RG8B." Each of these two regions is intended to be an example of a DRCC. User interface element 814 may include any suitable data associated with the realm and / or region. As shown, user interface element 814 provides an overview of realm RLM8, including the common name (e.g., "CST C") associated with a given customer (e.g., "Customer C" referring to a particular DRCC owner), the full name associated with the customer (e.g., "Customer C"), the number of regions corresponding to realm "RLM8," the respective status for each region (e.g., "Live"), and the type (e.g., "DRCC") associated with the realm and / or regions of the realm.

[0083] Any suitable user interface element (e.g., user interface element 814) can include option 816. Option 816 does not necessarily have to be a button as illustrated in FIG. 8, but may be in any suitable form. Option 816 can be selected to navigate the user to an additional user interface (e.g., user interface 1000 of FIG. 10) where additional details related to the realm can be viewed. Selection of option 818 or 820 can be used to navigate the user to an additional user interface (e.g., user interface 1200 of FIG. 12) to view additional details associated with the respective region.

[0084] The data presented in user interface 800 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0085] FIG. 9 is a block diagram illustrating an exemplary user interface (e.g., user interface 900, one of user interfaces 308 of FIG. 3) presenting an executive capacity dashboard, according to at least one embodiment. As shown, user interface 900 presents DRCC utilization dashboard 902 corresponding to multiple DRCCs / PLCs (each an example of DRCC / PLC 104 of FIG. 1). A user can navigate to user interface 900 based at least in part on selecting option 806 of FIG. 8. Upon selection, region 802 can be replaced with the contents of region 903. As shown, DRCC utilization dashboard 902 can include a table presenting capacity and usage information associated with multiple regions, including “RG8A” and “RG8B,” associated with customer C, as illustrated by user interface element 814 of FIG. 8. Any suitable number of regions can be presented within DRCC utilization dashboard 902. As shown, utilization dashboard 902 can include each region shown in FIG. 8 and corresponding individually to customers A, B, and C.

[0086] The DRCC utilization dashboard 902 may include any suitable number of columns corresponding to various usage metrics corresponding to utilized amounts of substrate, standard Intel processor, standard AMD processor, high-density Intel processor, block storage, object storage, file system storage, Exadata resources, and physical space, as well as various attributes of the region data, such as region code, common customer name (corresponding to the presented "Customer" column), etc. Each of the columns corresponding to substrate, standard Intel processor, standard AMD processor, high-density Intel processor, block storage, object storage, file system storage, Exadata resources, and physical space may include a corresponding field indicating the percentage of total available resources that are currently utilized. Field 904 indicates that 63% of the available standard Intel processors are currently utilized (by the text "63%"). Although a percentage is shown, numbers may also be used to indicate current utilization. By way of example, numbers may be provided indicating the current number of block, object, and file system storage units (e.g., in tebibytes (TiB) of capacity currently utilized). A number (e.g., of cores) may be used to represent the number of processing cores (e.g., standard / high density Intel and / or AMD) currently utilized. A number of units of physical space (e.g., floor tiles) may be used to indicate the physical space currently utilized.

[0087] In some examples, blocks in user interface 900 may be colored according to predefined thresholds to indicate utilization. By way of example, a resource that is maxed out (e.g., at or above a 90 percent threshold utilization) may be represented in red (as shown at 906). A resource that has breached another threshold (e.g., between 80 and 90 percent utilization) may be represented in yellow (as shown at 908), and all other blocks that do not breach any threshold may be represented in green (as shown at 910). Any suitable visual indicator, such as color, shading, or outline, may be utilized.

[0088] In some embodiments, each row of the DRCC usage dashboard 902 may initially be presented in a collapsed view, as shown at 912, with region data corresponding to region “RG2B” associated with customer A (as indicated by the common name “CUST_A”). At any suitable point, a toggle or other interface element (e.g., toggle 914) may be selected to transition the row to an expanded view. Area 916 shows an expanded view of region details corresponding to region “RG8B” associated with customer C (as indicated by the common name “CST C”). Area 916 may present the corresponding details for region “RG8B” shown in user interface element 814 of FIG. 8 . While presenting the expanded view, area 916 may include the original row of the DRCC usage dashboard 902 that provided the same region data corresponding to row 918 as presented in the collapsed view, along with additional region data corresponding to the total capacity count of resources, the number of available resources, the number of unavailable resources, the number of resources used by the customer, the number of resources used by the cloud provider on behalf of the customer, and the number of resources used for overhead (e.g., to provide cloud provider services). As an example, region 916 indicates that there are a total of 8,736 standard Intel processors, of which 2,007 are available and 6,729 are unavailable, and of the unavailable processors, 1,394 processors are currently in use by customers, 3,646 processors are in use by the provider on behalf of customers, and 1,689 processors are being used for overhead. Each column in the DRCC utilization dashboard 902 corresponding to column 920 can be similarly utilized to provide corresponding numbers associated with resources corresponding to boards, standard Intel processors, standard AMD processors, high-density Intel processors, block storage, object storage, file system storage, Exadata resources, and physical space.More or fewer types of resources may be provided in the DRCC usage dashboard 902, and the particular resources shown are exemplary and not intended to limit the scope of the present disclosure.

[0089] The data presented in user interface 900 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0090] FIG. 10 is a block diagram illustrating an exemplary user interface (e.g., user interface 1000, one of user interfaces 308 of FIG. 3) presenting a region list (e.g., region list 1002) according to at least one embodiment. As described above, a user can navigate to user interface 1000 by selecting option 816 of FIG. 8. Selecting option 816 can navigate the user to an overview view of realm “RLM8,” as shown at 1002 in navigation panel 1004, the content of which can replace or update the content of region 802 of FIG. 8 based on the selection of option 816. User interface 1000 can include any suitable data corresponding to a realm. Realm data can include, but is not limited to, a realm type, a common name, and the number of regions associated with the realm, as shown at 1006. Any suitable customer data can be presented at 1008, including, but not limited to, a customer name (e.g., “Customer C”) and a common name (e.g., “CST C”). The realm data may be presented in any suitable format, in any suitable location, and in any suitable manner within the user interface 1000.

[0091] User interface 1000 may include a region list 1010. Region list 1010 may list any suitable number of regions and present any suitable region data associated with the listed regions. As shown, region list 1010 includes region data associated with regions “RG8A” and “RG8B” previously presented in user interface element 814 of FIG. 8 . As presented in FIG. 10 , region list 1010 may include a common name (“CST-C-1”), a short name (e.g., “sea-1”), a region code “RG8A,” a geographic area (e.g., “USW”), a status (e.g., “Live”), a date of actual activation (e.g., “March 17, 2021, 12:00 AM”), and a DRCC version (e.g., v1.1). The number of regions and certain attributes (e.g., DRCC regions associated with region code “RG8A” and realm “RLM8”) may differ from those presented in FIG. 10 .

[0092] The user interface 1000 may include a list of upcoming scheduled regions 1012. The list of upcoming scheduled regions 1012 may present any suitable region data corresponding to regions that are planned but not currently operational. As shown, "RLM8" does not include any upcoming scheduled regions.

[0093] Navigation panel 1004 may include any suitable number of options. By way of example, navigation panel 1004 may present navigation options corresponding to an "RG8A" region and an "RG8B" region. For example, selecting option 1018 may navigate a user from user interface 1000 to user interface 1200 of FIG. 12. Navigation panel 1004 may include navigation options corresponding to user interface 1100 of FIG. 11. For example, selecting option 1016 may navigate a user from user interface 1000 to user interface 1100.

[0094] The data presented in user interface 1000 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0095] FIG. 11 is a block diagram illustrating an exemplary user interface (e.g., user interface 1100, one of user interfaces 308 of FIG. 3) presenting capacity information corresponding to multiple regions, according to at least one embodiment. As described above, a user can navigate to user interface 1100 by selecting option 1016 of FIG. 10. Selecting option 1016 can navigate the user to a per-region capacity view, as shown at 1102 in navigation panel 1104, the content of which can replace or update the content of area 1004 of FIG. 10 based on the selection of option 1016. User interface 1100 can include any suitable data corresponding to the live region associated with realm "RLM8." The presentation of realm data of FIG. 10 can remain in area 1105.

[0096] The user interface 1000 may include a region utilization dashboard 1106 (e.g., a table, grid, etc.) corresponding to the regions associated with realm "RLM8." In the current example, the region utilization dashboard 1106 presents regions "RG8A" and "RG8B" according to their association with realm "RLM8." As shown, the region utilization dashboard 1106 may include a table presenting capacity and usage information associated with regions "RG8A" and "RG8B," which are associated with customer C, as shown in user interface element 814 of FIG. 8. The regions and corresponding region data shown in FIG. 11 may be similar to the data presented in DRCC utilization dashboard 902, but may include only data corresponding to regions associated with the selected realm (e.g., "RLM8").

[0097] Similar to DRCC usage dashboard 902, region usage dashboard 1106 may include any suitable number of columns corresponding to various attributes of region data, such as region code, common customer name (corresponding to the presented "Customer" column), etc., in addition to various usage metrics corresponding to the amount of utilized board, standard Intel processor, standard AMD processor, high-density Intel processor, block storage, object storage, file system storage, Exadata resources, and physical space. In some embodiments, the specific number and combination of attributes may differ from those presented in DRCC usage dashboard 902.

[0098] In some examples, blocks in region utilization dashboard 1106 may be colored according to predefined thresholds to indicate utilization. By way of example, resources that are maxed out (e.g., at or above a 90 percent threshold utilization) may be represented in red (as shown at 906). Resources that breach another threshold (e.g., between 80 and 90 percent utilization) may be represented in yellow (as shown at 908), and all other blocks that do not breach any threshold may be represented in green (as shown at 910). Any suitable visual indicator, such as color, shading, or outline, may be utilized.

[0099] In some embodiments, each row in the region utilization dashboard 1106 may initially be presented in a collapsed view, as shown at 1108, for region data corresponding to region "RG8A." At any suitable point, a toggle or other interface element (e.g., toggle 1110) may be selected to transition the row to an expanded view. Area 1112 shows an expanded view of region details corresponding to region "RG8B." Area 1112 may be similarly utilized to present data as described above in connection with area 916 of FIG. 9 . The data in the region utilization dashboard 1106 may be formatted similarly or differently than that used in FIG. 9 and may utilize similar or different units, numbers, and / or percentages.

[0100] The data presented in user interface 1100 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0101] FIG. 12 is a block diagram illustrating an exemplary user interface (e.g., user interface 1200, one of user interfaces 308 of FIG. 3) presenting region details (e.g., region data corresponding to region "RG8A") according to at least one embodiment. As described above, a user can navigate to user interface 1200 by selecting option 1018 of FIG. 10 and / or option 1114 of FIG. 11. Selecting option 1018 or 1114 can navigate the user to the region details view presented in FIG. 12, as indicated by 1202 in navigation panel 1204, the contents of which can replace or update the contents of region 1004 of FIG. 10 or region 1104 of FIG. 11 based on the selected navigation option. User interface 1200 can present any suitable data corresponding to a region, in this example, region RG8A, in region 1205. Region data may include, but is not limited to, region name ("sea-1"), region code ("RG8A"), and version (e.g., "v1.1"), region status (e.g., "live"), actual activation date and time (indicating the date and / or time the region was activated, e.g., "March 17, 2021 at 12:00 AM"), geographic country (e.g., "US"), and geographic region (e.g., "USW"), to name a few. Region data may be presented in any suitable format, in any suitable location, and in any suitable manner within user interface 1200.

[0102] Within region 1204, a number of options corresponding to the selected region may be presented. In some embodiments, by default, region 1222 may present data corresponding to the compute resources of the selected region. Selecting any of options 1208-1220 may cause the contents of region 1222 to be updated with data corresponding to the selected option, as discussed in further detail with respect to FIGS. 13-22 . Once an option is selected, the user may scroll down to view additional details in region 1222. In some embodiments, region 1205 may remain docked at the top of user interface 1200 as shown, or region 1205 may scroll off-screen as more of region 1222 is presented. In some embodiments, by scrolling down or otherwise navigating within user interface 1200, the user may be presented with additional details corresponding to compute resources, block storage, object storage, file system storage, Exadata resources, physical space, and power consumption in the order listed in region 1204. In some embodiments, selecting an option (eg, option 1208) may navigate the user to user interface 1300 of FIG.

[0103] The data presented in user interface 1200 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0104] FIG. 13 is a block diagram illustrating an exemplary user interface (e.g., user interface 1300, one of user interfaces 308 of FIG. 3) presenting compute details corresponding to a single region (e.g., region “RG8A”), according to at least one embodiment. In some embodiments, user interface 1300 may represent a portion of user interface 1200, or user interface 1300 may provide an interface separate from user interface 1200. As described above, a user can navigate to user interface 1300 by selecting option 1208 of FIG. 12. Selecting option 1208 can navigate the user to the compute details view presented in FIG. 13, as shown by 1302 in navigation panel 1304, the content of which can replace or update the content of region 1204 of FIG. 12 based on the selected navigation option. User interface 1300 can be configured to initially display data corresponding to tab 1306, which can correspond to a particular type of compute resource (e.g., cores utilizing a standard Intel processor). One or more additional or alternative tabs may be available, such as tabs 1308, 1310, and / or 1312, corresponding to cores utilizing standard AMD processors, high-density Intel processors, and high-density AMD processors, respectively. When selected, each tab may present data in area 1314 that is similar but specific to the type of core represented by each respective tab. Any suitable number of tabs may be provided depending on the number of different compute resources utilized in the region.

[0105] Area 1316 may present current snapshot data 1318 showing the number of cores being used for overhead, cores being used by the cloud provider, cores being used by the customer, and available (not currently utilized) cores for any suitable combination. The number of cores shown in bar graph 1320 indicates that 782 standard Intel cores are currently being used for overhead, 2,755 standard Intel cores are currently being used by the cloud provider, and 5,146 are available (not currently utilized) according to the current selection of tab 1306. Bar graph 1320 may be colorized so that individual metrics shown in bar graph 1320 can match the colors presented in legend 1322. The current snapshot data may be formatted differently than shown in FIG. 13 or presented in different areas of 1316 without departing from this disclosure.

[0106] Region 1316 may include option 1324 corresponding to usage data corresponding to compute resources of RG8A. As shown here, option 1324 may indicate that data is available, but the data may initially be hidden from view. Selecting option 1324 may update region 1316 with the data presented in expanded view 1400. Any suitable data previously presented in region 1316 may be repositioned to correspond to expanded view 1400 of the user interface component corresponding to option 1324.

[0107] FIG. 14 is a block diagram illustrating an expanded view of the user interface component of FIG. 13 (e.g., user interface 1400, one of user interfaces 308 of FIG. 3) according to at least one embodiment. In expanded view 1400, a number of usage tables are presented. By way of example, expanded view 1400 may include table 1402 corresponding to a customer's compute resource usage per tenancy. Row 1404 may be utilized to label the columns "Tenancy Name" and "Customer." Rows of table 1402 positioned below row 1404 and above row 1406 may indicate the particular tenancy and the particular number of cores (e.g., standard Intel cores, in the current example, according to the current selection of tab 1306) used by the customer. Row 1404 may be utilized to indicate the total number of cores used by the customer across all tenancies. In a use case in which user interface 1300 and expanded view 1400 of FIG. 13 are utilized by a user associated with a cloud provider, the expanded view may include table 1408. Row 1410 may be used to label the columns "Tenancy Name" and "Provider." Rows positioned below row 1410 and above row 1412 may indicate a particular tenancy and a particular number of cores (e.g., in the current example, standard Intel cores) used by the cloud provider. Row 1404 may indicate the total number of cores used by the cloud provider across all tenancies.

[0108] In some embodiments, expanded view 1400 may include table 1410. Row 1416 may be utilized to label the columns “Core Shape,” “Available,” “Overhead,” “Customer,” and “Provider.” The rows below row 1416 and above row 1418 may indicate the number of cores available, utilized by overhead, utilized by customer, and utilized by provider for a given core shape (e.g., the core shape shown in the corresponding field in column 1422). As a non-limiting example, data in column 1424 and row 1420 may be used to indicate that there are 4,628 standard Intel cores having a “BM.Standard” shape available, and that there are 488 standard Intel cores of the “BM.Standard” shape currently utilized by overhead, 0 standard Intel cores of the “BM.Standard” shape currently utilized by customers, and 384 standard Intel cores of the “BM.Standard” shape currently utilized by providers. The data in column 1424 and row 1418 can be used to provide total core counts corresponding to available standard Intel cores, standard Intel cores currently used for overhead, standard Intel cores currently used by customers, and standard Intel cores currently used by providers, regardless of core shape. By selecting toggle 1426, user interface 1300 can transition from presenting expanded view 1400 to presenting option 1324.

[0109] 13 , the user interface may present historical data 1326. As shown, in some cases by default, the historical data may represent historical data associated with a default time period (e.g., the past 30 days). However, if utilized, options 1328 may be presented that allow the user to select a different time frame (e.g., the past week, the past 24 hours, the past year, the past six months, etc.). In some embodiments, selections made via options 1328 may update the historical data 1326 to correspond to the selection made.

[0110] In some embodiments, historical data 1326 may include graph 1330, although historical data 1326 may be presented differently and in any suitable format. Graph 1326 may present a number of different sets of usage data. By way of example, graph 1330 may be configured to present usage data corresponding to standard Intel cores currently utilized by the provider, by the customer, and currently unused (e.g., available) cores for overhead according to legend 1332. Each set of data may be colored to distinguish the data sets from one another. The color (or other distinguishing feature) corresponding to each data set may be indicated within legend 1332 or in any suitable manner.

[0111] The data presented in user interface 1300 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0112] FIG. 15 is a block diagram illustrating an exemplary user interface (e.g., user interface 1500, one of user interfaces 308 of FIG. 3) presenting details of block storage corresponding to a single region (e.g., "RG8A"), according to at least one embodiment. In some embodiments, user interface 1500 may represent a portion of user interface 1200, or user interface 1500 may provide an interface separate from user interface 1200. As mentioned above, a user can navigate to user interface 1500 by selecting option 1210 of FIG. 12. Selecting option 1210 can navigate the user to the block storage detail view presented in FIG. 15, as shown at 1502 in navigation panel 1504, the contents of which may replace or update the contents of region 1204 of FIG. 12, or any suitable previously presented navigation panel, based on the selected navigation option.

[0113] Area 1516 may present current snapshot data 1518 showing block storage currently in use by the provider, block storage currently in use by the customer, and block storage not currently in use (e.g., available block storage). Any suitable unit of capacity (e.g., tebibytes (TiB)) may be utilized. The amounts shown in bar graph 1520 indicate that 827.15 TiB of block storage is currently in use by the provider and 4,502.97 TiB of block storage capacity is currently available. Bar graph 1520 may be colorized such that individual metrics shown in bar graph 1520 can match the colors presented in legend 1522. The current snapshot data may be formatted differently than shown in FIG. 15 or presented in different areas of 1516 without departing from this disclosure.

[0114] Region 1516 may include user interface element 1524 corresponding to usage data associated with block storage resources in region RG8A. User interface element 1524 may initially be presented in a collapsed view. When selected, user interface element 1524 may be expanded to present an expanded view including table 1526 and possibly table 1528. By selecting toggle 1530, user interface element 1524 may be transitioned between the expanded and collapsed views any suitable number of times. In the collapsed view, table 1526 and table 1528 may not be visible within user interface element 1524. Any suitable data previously presented in region 1516 before user interface element 1524 is expanded may be repositioned to correspond to the expanded view of user interface element 1524.

[0115] In the expanded view, the user interface element may present table 1526 corresponding to a customer's block storage usage per tenancy. Row 1532 may be utilized to label the columns with "Tenancy Name" and "Customer." Rows of table 1526 positioned below row 1532 and above row 1534 may indicate a particular tenancy and a particular amount of block storage used for a given tenancy. Row 1534 may be utilized to indicate the total amount of block storage (in TiB) used by the customer across all tenancies. In a use case in which user interface 1500 is utilized by a user associated with a cloud provider, user interface element 1524 may include table 1528. In some embodiments, table 1524 may not be presented to a user associated with a customer. Row 1536 may be utilized to label the columns with "Tenancy Name" and "Provider." Rows positioned below row 1536 and above row 1538 may indicate a particular tenancy and a particular amount of block storage (in TiB) used by the cloud provider. Line 1538 may show the total amount of block storage used by the cloud provider across all tenancies.

[0116] User interface 1500 may present historical data 1540. As shown, in some cases by default, the historical data may represent historical data associated with a default time period (e.g., the past 30 days). However, if utilized, option 1542 may be presented that allows the user to select a different time frame (e.g., the past week, the past 24 hours, the past year, the past six months, etc.). In some embodiments, selections made via option 1542 may update historical data 1540 to correspond to the selection made.

[0117] In some embodiments, historical data 1540 may be presented in graph 1544, although historical data 1540 may be presented differently and in any suitable format. Graph 1544 may present a number of different sets of usage data. By way of example, graph 1544 may be configured to present usage data corresponding to the amount of block storage utilized by the provider (in TiB), the amount of block storage utilized by the customer (in TiB), and the amount of block storage capacity (in TiB) currently unused (e.g., available), according to legend 1546. Each set of data may be colored to distinguish the data sets from one another. The color (or other distinguishing feature) corresponding to each data set may be indicated in legend 1546 or in any suitable manner.

[0118] The data presented in user interface 1500 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0119] FIG. 16 is a block diagram illustrating an exemplary user interface (e.g., user interface 1600, one of user interfaces 308 of FIG. 3) presenting object storage corresponding to a single region (e.g., "RG8A"), according to at least one embodiment. In some embodiments, user interface 1600 may represent a portion of user interface 1200, or user interface 1600 may provide an interface separate from user interface 1200. As described above, a user can navigate to user interface 1600 by selecting option 1212 of FIG. 12. Selecting option 1212 can navigate the user to the object storage detail view presented in FIG. 16, as shown at 1602 of navigation panel 1604, the contents of which may replace or update the contents of region 1204 of FIG. 12, or any suitable previously presented navigation panel, based on the selected navigation option.

[0120] Area 1616 may present current snapshot data 1618 showing object storage currently in use by the provider, object storage currently in use by customers, and object storage not currently in use (e.g., available object storage). Any suitable unit of capacity (e.g., tebibytes (TiB)) may be utilized. The amounts shown within bar graph 1620 indicate that 1,834.44 TiB of object storage is currently in use by the provider, 0.84 TiB of object storage is currently in use by customers, and 2,019.73 TiB of object storage capacity is currently available (e.g., not currently in use). Bar graph 1620 may be colorized such that individual metrics shown in bar graph 1620 can match the colors presented in legend 1622. The current snapshot data may be formatted differently than shown in FIG. 16 or presented in different areas of 1616 without departing from this disclosure.

[0121] Region 1616 may include user interface element 1624 corresponding to usage data associated with object storage resources in region RG8A. User interface element 1624 may initially be presented in a collapsed view. When selected, user interface element 1624 may be expanded to present an expanded view including table 1626 and possibly table 1628. By selecting toggle 1630, user interface element 1624 may be transitioned between the expanded and collapsed views any suitable number of times. In the collapsed view, table 1626 and table 1628 may not be visible within user interface element 1624. Any suitable data previously presented in region 1616 before user interface element 1624 is expanded may be repositioned to correspond to the expanded view of user interface element 1624.

[0122] In the expanded view, the user interface element may present table 1626 corresponding to the customer's object storage usage per tenancy. Row 1632 may be utilized to label the columns with "Tenancy Name" and "Customer." Rows of table 1626 positioned below row 1632 and above row 1634 may indicate a particular tenancy and a particular amount of capacity used for a given tenancy. Row 1634 may be utilized to indicate the total amount of object storage (in TiB) used by the customer across all tenancies. In a use case in which user interface 1600 is utilized by a user associated with a cloud provider, user interface element 1624 may include table 1628. In some embodiments, table 1624 may not be presented to a user associated with a customer. Row 1636 may be utilized to label the columns with "Tenancy Name" and "Provider." Rows positioned below row 1636 and above row 1638 may indicate a particular tenancy and a particular amount of object storage (in TiB) used by the cloud provider. Line 1538 may show the total amount of object storage used by the cloud provider across all tenancies.

[0123] User interface 1600 may present historical data 1640. As shown, in some cases by default, the historical data may represent historical data associated with a default time period (e.g., the past 30 days). However, if utilized, option 1642 may be presented that allows the user to select a different time frame (e.g., the past week, the past 24 hours, the past year, the past six months, etc.). In some embodiments, selections made via option 1642 may update historical data 1640 to correspond to the selection made.

[0124] In some embodiments, historical data 1640 may be presented in graph 1644, although historical data 1640 may be differently presented in any suitable format. Graph 1644 may present a number of different sets of usage data. By way of example, graph 1644 may be configured to present usage data corresponding to the amount of object storage utilized by the provider (in TiB), the amount of object storage utilized by the customer (in TiB), and the amount of object storage capacity (in TiB) currently unused (e.g., available), according to legend 1646. Each set of data may be colored to distinguish the data sets from one another. The color (or other distinguishing feature) corresponding to each data set may be indicated in legend 1646 or in any suitable manner.

[0125] The data presented in user interface 1600 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0126] FIG. 17 is a block diagram illustrating an exemplary user interface (e.g., user interface 1700, one of user interfaces 308 of FIG. 3) presenting file storage details corresponding to a single region (e.g., "RG8A"), according to at least one embodiment. In some embodiments, user interface 1700 may represent a portion of user interface 1200, or user interface 1700 may provide an interface separate from user interface 1200. As described above, a user can navigate to user interface 1700 by selecting option 1214 of FIG. 12. Selecting option 1214 can navigate the user to the file system storage view presented in FIG. 17, as shown at 1702 in navigation panel 1704, the contents of which can replace or update the contents of region 1204 of FIG. 12, or any suitable previously presented navigation panel, based on the selected navigation option.

[0127] Area 1716 may present current snapshot data 1718 showing file system storage currently in use by the provider, file system storage currently in use by the customer, and file system storage not currently in use (e.g., available file system storage). Any suitable unit of capacity (e.g., tebibytes (TiB)) may be utilized. The amount shown in bar graph 1720 indicates that 13.56 TiB of file system storage is currently in use by the provider and 87.39 TiB of file system storage is currently available (e.g., not currently in use). Bar graph 1720 may be colorized such that individual metrics shown in bar graph 1720 can match the colors presented in legend 1722. The current snapshot data may be formatted differently than shown in FIG. 17 or presented in different areas of 1716 without departing from this disclosure.

[0128] Region 1716 may include user interface element 1724 corresponding to usage data associated with file system storage resources for region "RG8A." User interface element 1724 may initially be presented in a collapsed view. When selected, user interface element 1724 may be expanded to present an expanded view including table 1726 and possibly table 1728. By selecting toggle 1730, user interface element 1724 may be transitioned between the expanded and collapsed views any suitable number of times. In the collapsed view, tables 1726 and 1728 may not be visible within user interface element 1724. Any suitable data previously presented in region 1716 may be repositioned to correspond to the expanded view of user interface element 1724 before user interface element 1724 is expanded.

[0129] In the expanded view, the user interface element may present table 1726 corresponding to a customer's file system storage usage per tenancy. Row 1732 may be utilized to label the columns with "Tenancy Name" and "Customer." Rows of table 1726 positioned below row 1732 and above row 1734 may indicate a particular tenancy and a particular amount of file system storage used for a given tenancy. Row 1734 may be utilized to indicate the total amount of file system storage (in TiB) used by the customer across all tenancies. In a use case in which user interface 1700 is utilized by a user associated with a cloud provider, user interface element 1724 may include table 1728. In some embodiments, table 1724 may not be presented to a user associated with a customer. Row 1736 may be utilized to label the columns with "Tenancy Name" and "Provider." Rows positioned below row 1736 and above row 1738 may indicate a particular tenancy and a particular amount of file system storage (in TiB) used by the cloud provider. Line 1738 may show the total amount of file system storage used by the cloud provider across all tenancies.

[0130] User interface 1700 may present historical data 1740. As shown, in some cases by default, the historical data may represent historical data associated with a default time period (e.g., the past 30 days). However, if utilized, option 1742 may be presented that allows the user to select a different time frame (e.g., the past week, the past 24 hours, the past year, the past six months, etc.). In some embodiments, selections made via option 1742 may update historical data 1740 to correspond to the selection made.

[0131] In some embodiments, historical data 1740 may be presented in graph 1744, although historical data 1740 may be differently presented in any suitable format. Graph 1744 may present a number of different sets of usage data. By way of example, graph 1744 may be configured to present usage data corresponding to the amount of file system storage utilized by the provider (in TiB), the amount of file system storage utilized by the customer (in TiB), and the amount of file system storage capacity (in TiB) that is currently unused (e.g., available), according to legend 1746. Each set of data may be colored to distinguish the data sets from one another. The color (or other distinguishing feature) corresponding to each data set may be indicated within legend 1746 or in any suitable manner.

[0132] The data presented in user interface 1700 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0133] FIG. 18 is a block diagram illustrating an exemplary user interface (e.g., user interface 1800, one of user interfaces 308 of FIG. 3) presenting database details corresponding to a single region (e.g., "RG8A"), according to at least one embodiment. In some embodiments, user interface 1800 may represent a portion of user interface 1200, or user interface 1800 may provide an interface separate from user interface 1200. As described above, a user can navigate to user interface 1800 by selecting option 1216 of FIG. 12. Selecting option 1216 can navigate the user to the Exadata view presented in FIG. 18, as shown at 1802 in navigation panel 1804, the contents of which may replace or update the contents of region 1204 of FIG. 12, or any suitable previously presented navigation panel, based on the selected navigation option. User interface 1800 may be configured to initially display data corresponding to tab 1860, which may correspond to a particular type of Exadata resource (e.g., a core operating as part of an X7 Oracle Exadata Database (DB) Machine, a hardware component configured to perform according to a predefined Oracle Exadata Data Machine model). One or more additional or alternative tabs may be utilized, such as tabs 1862, 1864, and / or 1866, corresponding to X8, X8M, and X9M DB Machines, each pre-configured to correspond to a pre-defined DB Machine model. When selected, each tab may appear within an area specific to the type of rack represented by each respective tab. Any suitable number of tabs may be provided, depending on the number of DB Machine models utilized in the region.

[0134] Area 1816 may present current snapshot data 1818 showing Exadata resources currently being used by the provider, Exadata resources currently being used by customers, and Exadata resources not currently being used (e.g., available). Any suitable units (e.g., cores, nodes, etc.) may be utilized. Snapshot data 1818 may include one or more bar graphs (e.g., bar graph 1820 corresponding to cores being used by DB nodes and bar graph 1821 for cores being used by high-capacity (HC) nodes). The quantities shown in bar graph 1820 indicate that, with respect to cores being used for DB nodes, 10 cores are being used by the provider, 14 cores are being used by customers, and 6 cores are available. The quantities shown in bar graph 1821 indicate that, with respect to cores being used for HC nodes, 15 cores are being used by the provider, 21 cores are being used by customers, and 9 cores are available. Bar graphs 1820 and 1821 may be colored such that the individual metrics shown in bar graphs 1820 and 1821 can match the colors presented in legend 1822. Current snapshot data may be formatted differently or presented in different areas of 1816 than shown in FIG. 18 without departing from this disclosure.

[0135] Region 1816 may include user interface element 1824 corresponding to usage data associated with Exadata resources in region RG8A. User interface element 1824 may initially be presented in a collapsed view. When selected, user interface element 1824 may be expanded to present an expanded view including table 1826 and possibly table 1828. By selecting toggle 1830, user interface element 1824 may be transitioned between the expanded and collapsed views any suitable number of times. In the collapsed view, tables 1826 and 1828 may not be visible within user interface element 1824. Any suitable data previously presented in region 1816 before user interface element 1824 is expanded may be repositioned to correspond to the expanded view of user interface element 1824.

[0136] In the expanded view, the user interface element may present table 1826 corresponding to the customer's node usage per tenancy. Row 1832 may be utilized to label the columns “Tenancy Name,” “Cust. DB,” and “Cust. HC.” Rows of table 1826 positioned below row 1832 and above row 1834 may indicate a specific tenancy and the number of DB nodes and HC nodes used for that tenancy. Row 1834 may be utilized to indicate the total amount of DB nodes and the total amount of HC nodes used by the customer across all tenancies. In a use case in which user interface 1800 is utilized by a user associated with a cloud provider, user interface element 1824 may include table 1828. In some embodiments, table 1824 may not be presented to users associated with a customer. Row 1836 may be utilized to label the columns “Tenancy Name,” “Provider DB,” and “Provider HC.” The lines positioned below line 1836 and above line 1838 may indicate a particular tenancy and a particular number of DB nodes and HC nodes being used by the cloud provider. Line 1838 may indicate the total amount of DB nodes and HC nodes being used by the cloud provider across all tenancies.

[0137] User interface 1800 may present historical data 1840. As shown, in some cases by default, the historical data may represent historical data associated with a default time period (e.g., the past 30 days). However, if utilized, option 1842 may be presented that allows the user to select a different time frame (e.g., the past week, the past 24 hours, the past year, the past six months, etc.). In some embodiments, selections made via option 1842 may update historical data 1840 to correspond to the selection made.

[0138] In some embodiments, historical data 1840 may be presented in graph 1844 and / or graph 1845, although historical data 1840 may be presented differently and in any suitable format. Graph 1844 may present a number of different sets of usage data corresponding to DB nodes / cores. By way of example, graph 1844 may be configured to present usage data indicating the number of DB nodes / cores utilized by the provider, the number of DB nodes / cores utilized by the customer, and the number of DB nodes / cores currently unused (e.g., available) according to legend 1846. Similarly, graph 1845 may be configured to present usage data indicating the number of HC nodes / cores utilized by the provider, the number of HC nodes / cores utilized by the customer, and the number of HC nodes / cores currently unused (e.g., available) according to legend 1846. Each set of data in graph 1844 and / or graph 1845 may be colored to distinguish the data sets from one another. The color (or other distinguishing feature) corresponding to each data set may be indicated in legend 1846 or in any suitable manner.

[0139] The data presented in user interface 1800 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0140] FIG. 19 is a block diagram illustrating an exemplary user interface (e.g., user interface 1900, one of user interfaces 308 of FIG. 3) presenting physical space details corresponding to a single region (e.g., “RG8A”), according to at least one embodiment. In some embodiments, user interface 1900 may represent a portion of user interface 1200, or user interface 1900 may provide an interface separate from user interface 1200. As described above, a user can navigate to user interface 1900 by selecting option 1218 of FIG. 12. Selecting option 1218 can navigate the user to the physical space view presented in FIG. 19, as shown at 1902 in navigation panel 1904, the contents of which can replace or update the contents of region 1204 of FIG. 12, or any suitable previously presented navigation panel, based on the selected navigation option. User interface 1900 can be configured to initially display data corresponding to tab 1906, which can correspond to physical floor tiles having DRCCs corresponding to region “RG8A.” One or more additional or alternative tabs may be utilized, such as a tab 1908 corresponding to server hardware and / or a tab 1910 corresponding to network hardware. Tabs 1908 and 1910 are discussed in further detail with respect to Figures 20 and 21, respectively.

[0141] Area 1916 may present current snapshot data 1918 indicating the number of units of physical space (e.g., floor tiles) currently in use and the number of units of physical space currently unused (e.g., available). Any suitable units (e.g., floor tiles of a raised floor system having a predefined area) may be utilized. Snapshot data 1918 may include one or more bar graphs (e.g., bar graph 1920). The quantities shown in bar graph 1920 indicate that 51 floor tiles are utilized and 27 floor tiles are available. Bar graph 1920 may be colorized such that individual metrics shown in bar graph 1920 can match the colors presented in legend 1922. Current snapshot data may be formatted differently than shown in FIG. 19 or presented in different areas of 1916 without departing from this disclosure.

[0142] User interface 1900 may present historical data 1940. As shown, in some cases by default, the historical data may represent historical data associated with a default time period (e.g., the past 30 days). However, if utilized, option 1942 may be presented that allows the user to select a different time frame (e.g., the past week, the past 24 hours, the past year, the past six months, etc.). In some embodiments, selections made via option 1942 may update historical data 1940 to correspond to the selection made.

[0143] In some embodiments, historical data 1940 may be presented in a graph 1944, although historical data 1940 may be differently presented in any suitable format. Graph 1944 may present a number of different sets of usage data. By way of example, graph 1944 may be configured to present the number of physical tiles that have been utilized in the past and the number of physical tiles that were available in the past. Each set of data may be colored to distinguish the data sets from one another. The color (or other distinguishing feature) corresponding to each data set may be indicated in legend 1946 or in any suitable manner.

[0144] The data presented in user interface 1900 may be formatted differently, may include additional data, or may not include all of the data shown in Figure 19. Selecting tab 1908 may navigate the user to user interface 2000 of Figure 20.

[0145] FIG. 20 is a block diagram illustrating an exemplary user interface (e.g., user interface 2000, one of user interfaces 308 of FIG. 3) presenting server hardware details corresponding to a single region (e.g., region “RG8A”), according to at least one embodiment. User interface 2000 may be presented in response to selection of tab 1908 of FIG. 19. User interface 2000 may include any suitable number of user interface elements (e.g., UI elements 2002-2014). Each UI element may present data corresponding to a category of server hardware resources. As an example, UI element 2002 presents any suitable data corresponding to available server hardware (e.g., floor tiles) that is currently not powered and networked ready. In some embodiments, UI element 2002 may present a number indicating a quantity corresponding to the available server hardware category (e.g., 25 floor tiles).

[0146] As a further example, UI element 2004 may present any suitable data corresponding to Exadata hardware (e.g., the number of racks corresponding to a configuration for running an X8M Exadata Database Machine). As shown, UI element 2004 may present a number (e.g., 6) indicating the amount of racks currently utilized. In some embodiments, multiple additional user interface elements (e.g., UI elements 2016, 2018, and 2020) may present data corresponding to the number of subcategories corresponding to the racks utilized. By way of example, UI element 2016 presents data (e.g., part number, rack number corresponding to the number of individual units / rack) organized according to a first configuration (e.g., Exadata_X8M_Storage_Rack.01). UI element 2018 presents data (e.g., part number, rack number corresponding to the number of individual units / rack) organized according to a second configuration (e.g., Exadata_X8M_Provider_Rack.01). UI element 2018 presents data (eg, part number, rack number corresponding to number of individual units / rack) organized according to a third configuration (eg, Exadata_X8M_DB_Rack.01).

[0147] As shown, UI element 2006 presents any suitable data corresponding to the server hardware currently utilized for object storage. In some embodiments, UI element 2006 may present a number (e.g., 3) indicating the number of racks currently utilized to provide object storage. One or more additional user interface elements (e.g., UI element 2022) may present data corresponding to the number of corresponding respective subcategories corresponding to the racks utilized. UI element 2022 presents data (e.g., part number, rack number corresponding to the number of individual units / rack) configured according to a fourth configuration (e.g., Object_Storage_Rack.01).

[0148] As shown, UI element 2008 presents any suitable data corresponding to the server hardware currently utilized for compute resources. In some embodiments, UI element 2008 may present a number (e.g., 3) indicating the number of racks currently utilized to provide compute resources. One or more additional user interface elements (e.g., UI element 2024) may be presented that provide data corresponding to the number of respective subcategories corresponding to the racks utilized. UI element 2024 presents data (e.g., part number, rack number corresponding to the number of individual units / rack) configured according to a fifth configuration (e.g., Compute_Rack.04).

[0149] As shown, UI element 2010 presents any suitable data corresponding to the server hardware currently utilized to provide the service gateway. In some embodiments, UI element 2010 may present a number (e.g., 2) indicating the number of racks currently utilized to provide the service gateway. One or more additional user interface elements (e.g., UI element 2026) may be presented that provide data corresponding to the number of respective subcategories corresponding to the racks utilized. UI element 2026 presents data (e.g., part number, rack number corresponding to the number of individual units / rack) configured according to a sixth configuration (e.g., Svc_Gateway_Rack.04).

[0150] As shown, UI element 2012 presents any suitable data corresponding to the server hardware currently utilized for block storage. In some embodiments, UI element 2012 may present a number (e.g., 4) indicating the number of racks currently utilized to provide block storage. One or more additional user interface elements (e.g., UI element 2028) may be presented that provide data corresponding to the number of respective subcategories corresponding to the racks utilized. UI element 2028 presents data (e.g., part number, rack number corresponding to the number of individual units / rack) configured according to a seventh configuration (e.g., Block_Storage_Rack.04).

[0151] As shown, UI element 2014 presents any suitable data corresponding to the server hardware currently utilized to provide key management services. In some embodiments, UI element 2014 may present a number (e.g., 3) indicating the number of racks currently utilized to provide key management services. One or more additional user interface elements (e.g., UI element 2030) may be presented that provide data corresponding to the number of respective subcategories corresponding to the racks utilized. UI element 2030 presents data (e.g., part number, rack number corresponding to the number of individual units / rack) configured according to an eighth configuration (e.g., KMS_Rack.04).

[0152] User interface 2000 may include any suitable number of user interface elements corresponding to any suitable number of server hardware categories, the number presented depending on the number of different categories utilized in the region (e.g., RG8A). Each of the UI elements may individually include any suitable number of additional UI elements corresponding to any suitable number of server hardware subcategories, the number presented depending on the number of different subcategories utilized in the region.

[0153] The data presented in user interface 2000 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0154] FIG. 21 is a block diagram illustrating an exemplary user interface (e.g., user interface 2100, one of user interfaces 308 of FIG. 3) presenting network hardware details corresponding to a single region (e.g., region “RG8A”), according to at least one embodiment. User interface 2100 may be presented in response to selection of tab 1910 of FIG. 19. User interface 2100 may include any suitable number of user interface elements (e.g., UI elements 2102 and 2104). Each UI element may present data corresponding to a category of network hardware resources. As an example, UI element 2102 presents any suitable data corresponding to available network hardware resources (e.g., floor tiles) that are currently not powered and networking ready. In some embodiments, UI element 2102 may present a number (e.g., 2 floor tiles) indicating a quantity corresponding to a network hardware category (e.g., “Available”).

[0155] As shown, UI element 2104 presents any suitable data corresponding to the network hardware currently utilized. In some embodiments, UI element 2104 may present a number (e.g., 12) indicating the number of racks currently utilized for networking. One or more additional user interface elements (e.g., UI elements 2106-2116) may be presented that provide data corresponding to the number of respective subcategories corresponding to the racks utilized. As an example, UI element 2106 presents data (e.g., part number, rack number corresponding to the number of individual units / rack) organized according to a particular configuration (e.g., Network_1_1.1). Each of UI elements 2106-2116 may correspond to a different rack configuration.

[0156] The data presented in user interface 2100 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0157] FIG. 22 is a block diagram illustrating an example user interface (e.g., user interface 2200, one of user interfaces 308 of FIG. 3) presenting power consumption details corresponding to a single region (e.g., “RG8A”), according to at least one embodiment.

[0158] FIG. 19 is a block diagram illustrating an exemplary user interface 1900 presenting physical space details corresponding to a single region (e.g., "RG8A"), according to at least one embodiment. In some embodiments, user interface 2200 may represent a portion of user interface 1200, or user interface 2200 may provide a separate interface from user interface 1200. As described above, a user may navigate to user interface 2200 by, for example, selecting option 1220 of FIG. 12. Selecting option 1220 may navigate the user to the power consumption view presented in diagram 2200, as shown at 2202 in navigation panel 2204, the contents of which may replace or update the contents of region 1204 of FIG. 12, or any suitable previously presented navigation panel, based on the selected navigation option.

[0159] Area 2216 may present current snapshot data 2218 indicating the number of units of power consumption (e.g., kilowatts) currently being used and the number of units of power consumption (e.g., available power consumption) not currently being used. Snapshot data 2218 may include one or more bar graphs (e.g., bar graph 2220). The amount shown in bar graph 2220 of FIG. 22 indicates that 528.03 kilowatts of power are currently being consumed and that no additional kilowatts are available. Bar graph 2220 may be colorized such that individual metrics shown in bar graph 2220 can match the colors presented in legend 2222. Current snapshot data may be formatted differently than shown in FIG. 22 or presented in different areas of 2216 without departing from this disclosure.

[0160] User interface 2200 may present historical data 2240. As shown, in some cases by default, the historical data may represent historical data associated with a default time period (e.g., the past 30 days). However, if utilized, option 2242 may be presented that allows the user to select a different time frame (e.g., the past week, the past 24 hours, the past year, the past six months, etc.). In some embodiments, selections made via option 2242 may update historical data 2240 to correspond to the selection made.

[0161] In some embodiments, historical data 2240 may be presented in graph 2244, although historical data 2240 may be differently presented in any suitable format. Graph 2244 may present a number of different sets of usage data. By way of example, graph 2244 may be configured to present the number of kilowatts that have been consumed in the past and the number of kilowatts that have not been consumed (e.g., available) in the past. Each set of data may be colored to distinguish the data sets from one another. The color (or other distinguishing feature) corresponding to each data set may be indicated in legend 2246 or in any suitable manner.

[0162] The data presented in user interface 2200 may be formatted differently, may include additional data, or may lack some of the data shown in FIG.

[0163] 23-25 ​​show a number of example schemas according to at least one embodiment. FIG. 23 illustrates an entity-relationship diagram 2300 of data represented by multiple schemas corresponding to compute-related services. A star schema pattern may be utilized. The star pattern refers to a schema including one or more fact tables that reference any suitable number of dimension tables. The entity-relationship diagram 2300 may include a fact table 2302 that includes multiple values ​​and keys that reference dimensional data stored in dimension tables 2304-2308. The dimension tables 2304-2308 may include data corresponding to storage shape data, customer data, and capacity type data, respectively. At least a portion of the data collected by the DRCC Horizon service 120 of FIG. 1 (e.g., data corresponding to the compute service 116) may be retrieved and / or transformed into data corresponding to data structures and / or records conforming to the entity-relationship diagram 2300. Using these structures / records, the data corresponding to FIGS. 9 and 11-14 may be viewed for the compute resources described in connection with those figures and presented in a corresponding user interface.

[0164] FIG. 24 illustrates an entity-relationship diagram 2400 of data represented by multiple schemas from various storage-related services (block storage, object storage, and file system storage). The entity-relationship diagram 2400 may include a fact table 2402 that includes multiple values ​​and keys that reference dimensional data stored in dimension tables 2404-2408. The dimension tables 2304-2308 may include data corresponding to storage shape data, customer data, and capacity type data, respectively. At least a portion of the data collected by the DRCC Horizon service 120 of FIG. 1 (e.g., data corresponding to the block storage service 114, the object storage service 112, and the file system service 110) may be retrieved and / or transformed into data corresponding to data structures and / or records conforming to the entity-relationship diagram 2300. Using these structures / records, data corresponding to FIGS. 9, 11, and 15-17 may be viewed for the storage resources described in connection with those figures and presented in corresponding user interfaces.

[0165] FIG. 25 shows an entity-relationship diagram 2500 of service and dimension data represented by a number of schemas. The SERVICE_DIM can be utilized to hold data for all services that can be reported on, and the DIMENSION_DIM can be utilized to hold dimensions associated with each service. A star schema pattern can be utilized to maintain these records and corresponding relationships. Using the data stored in these records and their corresponding relationships, the collected data can be processed to identify usage data, such as the percentage and / or number of resources utilized by services associated with a cloud provider. The results can be presented as described in the diagram above.

[0166] 26 is a block diagram illustrating an example method 2600 for obtaining capacity and usage data in a dedicated region cloud, according to at least one embodiment. Method 2600 may be performed by one or more components of DRCC / PLC region 102. As an example, method 2600 may be performed by a computing device providing OCC service 124 of FIG. 1. The operations discussed in connection with method 2600 may be performed in any suitable order. Method 2600 may include more or fewer operations than those discussed in connection with FIG. 26.

[0167] Method 2600 may begin at 2602, where a dedicated region cloud (e.g., DRCC / PLC region 102 of FIG. 1) may be implemented, at least in part, by a computing device (e.g., the computing device of FIG. 27). In some embodiments, the dedicated region cloud may include multiple cloud infrastructure components that provide corresponding cloud services associated with a cloud service provider (e.g., Oracle). The multiple cloud infrastructure components are hosted by one or more computing devices located at a third-party location (e.g., on the premises of a cloud owner). In some embodiments, the third-party location may be associated with a third-party entity (e.g., a cloud owner) different from the cloud service provider (e.g., Oracle).

[0168] At 2604, capacity and usage data associated with at least one of the plurality of cloud infrastructure components may be obtained. By way of example, the capacity and usage data may include any suitable combination of data associated with compute resources, block storage, object storage, file storage, database resources, physical space (e.g., floor tiles), server resources / racks, network resources / racks, and / or power consumption. In some embodiments, the capacity and usage data presented in the user interface includes physical space data (e.g., any suitable data presented via user interfaces 1900-2100 of FIGS. 19-21 ) indicating the number of units of physical space available for placing additional computing devices at a third-party location. In some embodiments, the capacity and usage data includes first capacity and usage data corresponding to the third-party entity and second capacity and usage data corresponding to the cloud service provider. The user interface may be implemented, at least in part, based on a console plug-in installed with an existing dedicated region console (e.g., DRCC OCC console 128 of FIG. 1 ) of the dedicated region cloud. In some embodiments, the capacity and usage data may be initially obtained by a data processing service (e.g., DRCC Horizon service 120 of FIG. 1). In some embodiments, the data processing service operates in a tenancy separate from the tenancy associated with the third-party entity (e.g., service provider tenancy 2762 of FIG. 27).

[0169] At 2606, a control center service (e.g., OCC service 124) may be executed within the dedicated regional cloud located at the third-party location. The control center service may process at least a portion of the capacity and usage data associated with at least one of the plurality of cloud infrastructure component clouds and present it in a user interface (e.g., any suitable combination of user interfaces 400-2200 of FIGS. 4-22) hosted within the dedicated regional cloud.

[0170] At 2606, the capacity and usage data can be stored in a data store of the dedicated regional cloud (e.g., ADW 126 of FIG. 1 ) for later use. In some embodiments, by storing the capacity and usage data in a data store of the dedicated regional cloud, the capacity and usage data is obtained by one or more corresponding computing devices of a central cloud computing environment hosted by the cloud service provider (e.g., by a computing device hosting central Horizon service 121, a computing device hosting object storage utilized for object storage import 130 of FIG. 1 , etc.). In some embodiments, at least one of the one or more corresponding computing devices of the central cloud computing environment presents the first capacity and usage data along with additional capacity and usage data obtained from one or more additional dedicated regional clouds individually associated with respective third-party entities.

[0171] 27 is a block diagram 2700 illustrating an example pattern of an IaaS architecture (e.g., a DRCC architecture) according to at least one embodiment. A service operator 2702 can be communicatively coupled to a secure host tenancy 2704, which can include a virtual cloud network (VCN) 2706 and a secure host subnet 2708. In some examples, the service operator 2702 can employ one or more client computing devices, which can be portable handheld devices (e.g., iPhone®, mobile phone, iPad®, computing tablet, personal digital assistant (PDA)), or wearable devices (e.g., Google Glass® head-mounted display) running software such as Microsoft Windows Mobile® and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, and supporting the Internet, email, short message service (SMS), Blackberry®, or other communication protocols. Alternatively, the client computing devices may be general-purpose personal computers, including, by way of example, personal and / or laptop computers running various versions of the Microsoft Windows operating system, the Apple Macintosh operating system, and / or the Linux operating system. The client computing devices may be workstation computers running any of a variety of commercially available UNIX or UNIX-like operating systems, including, without limitation, various GNU / Linux operating systems such as Google Chrome OS.Alternatively or additionally, the client computing device may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and / or a personal messaging device, that can communicate over a network that has access to the VCN 2706 and / or the Internet.

[0172] VCN 2706 may include a local peering gateway (LPG) 2710, which may be communicatively coupled to a secure shell (SSH) VCN 2712 via the LPG 2710 included in the SSH VCN 2712. The SSH VCN 2712 may include an SSH subnet 2714, which may be communicatively coupled to a control plane VCN 2716 via the LPG 2710 included in the control plane VCN 2716. The SSH VCN 2712 may also be communicatively coupled to a data plane VCN 2718 via the LPG 2710. The control plane VCN 2716 and the data plane VCN 2718 may be included in a service tenancy 2719, which may be owned and / or operated by the IaaS provider.

[0173] Data plane VCN 2718 may include a data plane app layer 2746, a data plane DMZ layer 2748, and a data plane data layer 2750. Data plane DMZ layer 2748 may include LB subnet 2722, which may be communicatively coupled to app subnet 2726 of data plane app layer 2746 and gateway 2734 of data plane VCN 2718. Gateway 2734 may be an example of an internet gateway, a service gateway, a NAT gateway, etc. Data plane data layer 2750 may also include DB subnet 2730, which may be communicatively coupled to app subnet 2726 of data plane app layer 2746.

[0174] Gateway 2734 of data plane VCN 2718 can be communicatively coupled to a proxy computer 2752 (e.g., a Splat proxy), which can be communicatively coupled to the public Internet 2754. The public Internet 2754 can be communicatively coupled to gateway 2734 of data plane VCN 2718. Gateway 2736 of data plane VCN 2718 (e.g., a service gateway of gateway 2736) can be communicatively coupled to cloud services 2756. In some embodiments, cloud services 2756 can operate within a DRCC on hardware provided by the customer. Cloud services 2756 can include any suitable services, such as ADW 2774 (an example of ADW 126 in FIG. 1 ), service 2757 (an example of one of services 118 in FIG. 1 ), object storage 2772 (an example of object storage managed by object storage service 112 in FIG. 1 ), telemetry and logging service 2760 (an example of service 118 in FIG. 1 ), etc., although any suitable services, including those discussed in connection with FIG. 1 , can be included in cloud services 2756. A dataflow job (e.g., an example of Spark job 214 in FIG. 2 ) can be configured to pull collected data from object storage (e.g., from object storage bucket (Horizon bucket) 122 in FIG. 2 ) and transform and / or write the data to an ADW (e.g., ADW 126 in FIGS. 1 and 2 ).

[0175] Service provider tenancy 2762 may include Horizon service 2764 (an example of the Horizon service of FIGS. 1 and 2 ) that may be communicatively connected to cloud services 2756 via gateway 2766. As described above, Horizon service 2764 may be configured to perform data collection operations to obtain any suitable operational data for the DRCC, such as any suitable data related to capacity management, growth management, health and performance tracking, change management, etc. By way of non-limiting example, Horizon service 2764 may be configured to obtain capacity and usage data such as the number of CPUs, the total amount and usage of block storage, the total amount and usage of object storage, the total amount and usage of file storage, or any suitable data shown in FIGS. 4-22 . In some embodiments, this may include interacting with one or more of cloud services 2756. Horizon service 2764 may be configured to store any suitable data described above in a dedicated bucket (e.g., a Horizon bucket) in object storage 2772 (e.g., object storage bucket (Horizon bucket) 122 of FIG. 1 ).

[0176] In some examples, a gateway 2734 (e.g., a service gateway) of the data plane VCN 2718 can make application programming interface (API) calls to cloud services 2756 (e.g., using data plane APIs 2755) without traversing the public internet 2754. API calls from the gateway 2734 to cloud services 2756 can be unidirectional. That is, the gateway 2734 can make API calls to cloud services 2756 (e.g., using data plane APIs 2755), and the cloud services 2756 can send the requested data to the gateway 2734. However, the cloud services 2756 cannot initiate API calls to the service gateway 2736.

[0177] In some examples, secure host tenancy 2704 can be directly connected to service tenancy 2719, which may otherwise be isolated. Secure host subnet 2708 can communicate with SSH subnet 2714 through LPG 2710, which may enable bidirectional communication in an otherwise isolated system. By connecting secure host subnet 2708 to SSH subnet 2714, secure host subnet 2708 can access other entities in service tenancy 2719.

[0178] In some examples, a user or customer of the system may make a request, such as a request for a create, read, update, or delete (CRUD) operation (e.g., using a user interface provided by Oracle cloud console 2757), via the public internet 2754, which may communicate such request to proxy computer 2752. Proxy computer 2752 may communicate the request to data plane VCN 2718 via gateway 2734. The request may be received by LB subnet 2722 included in data plane DMZ tier 2748. LB subnet 2722 may determine that the request is valid, and in response to this determination, LB subnet 2722 may send the request to app subnet 2726 included in data plane app tier 2724. If the request is validated and requires a call to the internet 2754, the call to the internet 2754 may be sent to gateway 2734 (e.g., a NAT gateway of gateway 2734), which can make the call to the internet 2754. Memory that may be desired to be stored upon request may be stored in DB subnet 2730 .

[0179] In some embodiments, the control plane VCN 2716 and the data plane VCN 2718 can be included in the service tenancy 2719. In this case, a user or customer of the system may not own or operate either the control plane VCN 2716 or the data plane VCN 2718. Instead, an IaaS provider can own or operate the control plane VCN 2716 and the data plane VCN 2718, both of which can be included in the service tenancy 2719. In some embodiments, the hardware implementing the service tenancy 2719 can be owned by the customer but managed by the IaaS provider. In some embodiments, the isolation of these networks (VCNs) can enable a user or customer of the system to store databases privately without having to rely on the internet 2754, which may not have the desired level of threat protection for storage.

[0180] In another embodiment, LB subnet 2722 included in control plane VCN 2716 can be configured to receive signals from gateway 1034. In this embodiment, data plane VCN 1018 can be configured to be called by customers of the IaaS provider without calling the internet 2754. Customers of the IaaS provider may desire this embodiment because databases used by the customers can be stored in service tenancy 2719, which can be controlled by the IaaS provider and isolated from the internet 2754.

[0181] In some embodiments, the following operations may be performed: In step 1, Oracle cloud console 2757 sends an HTTPS request to proxy computer 2752. Proxy computer 2752 may be configured to perform authentication and / or authorization operations. In step 2, proxy computer 2752 may forward the request to LB subnet 2722 via HTTPS. In step 3, a load balancer in LB subnet 2722 forwards the request to one OCC data plane via HTTPS / mTLS. In step 4, proxy computer 2752 may perform authentication, which is handled via mTLS, using a certificate loaded from service 2757. In step 5, data from ADW 2774 is read and returned to the caller.

[0182] In some embodiments, a timer (e.g., a daily timer) may elapse, starting a dataflow job 2770 (an example of Spark job 214 in FIG. 2 ). In step 7, the dataflow job 2770 may pull data from object storage 2772 from a bucket owned and operated by a service provider associated with service provider tenancy 2762. In step 8, the dataflow job may process and store the retrieved data in ADW 2774 (an example of ADW 216 in FIG. 1 ). In step 9, a zipfile containing the Spark job may be loaded into object storage 2772. Data collector controller 2776 may load a file (e.g., a zipfile) containing the Spark job into object storage 2772. The dataflow job 2770 may be configured to consume code from object storage 2772.

[0183] Although not shown, the IaaS / DRCC architecture can be hosted by multiple racks. As an example, the architecture can utilize a 12-rack-based footprint, or at least fewer racks than those utilized in a typical public cloud. In some embodiments, cloud services 2756 can be hosted by fewer racks than those utilized for cloud services within a public cloud. In some embodiments, a public cloud may utilize 21 racks for service enclaves, while the IaaS / DRCC of FIG. 27 may utilize four racks. A public cloud may utilize 12 racks for customer enclaves, while the IaaS / DRCC of FIG. 27 may utilize five racks. As another example, a public cloud may utilize 12 racks for networking, while the IaaS / DRCC of FIG. 27 may utilize three racks. The IaaS / DRCC architecture, like a public cloud, can maintain separation between service enclaves, customer enclaves, and network racks. This allows for the highest core density in both the substrate network and the overlay network. In some embodiments, the hardware utilized to host the IaaS / DRCC may be configured by the service provider and deployed on-premise at the customer's location.

[0184] FIG. 28 illustrates a high-level structure of an exemplary 12-rack-based footprint on which an IaaS / DRCC architecture (e.g., the IaaS / DRCC architecture of FIG. 27) is hosted. Each of the 12 racks can be configured to hold 18 servers. Six servers can be utilized to provide key management services and can be configured according to a predefined X9 configuration. These six servers can be distributed across three racks (e.g., racks 1-3) for fault tolerance. Eighteen servers can be utilized to provide object storage resources according to an X9 bitstore configuration. These 18 servers can be distributed across three racks (e.g., racks 1-3) for fault tolerance and can be utilized to provide 1818 TiB of capacity, as shown in FIG. 28. Four servers across four racks (e.g., racks 1-4) can be utilized to provide board storage according to an X9 bitstore configuration and can be utilized to provide 288 virtual CPUs and 864 TiB of capacity. Forty-five servers distributed across four racks (e.g., racks 1-4) can be used to provide board compute resources according to the E4 platform using 1U servers. These 45 servers can be used to provide 11,520 virtual CPUs and 1,080 TiB of Non-Volatile Memory Express (NVMe) capacity. Four servers in a single rack (e.g., rack 4) can be used to provide board compute resources according to the E3 platform using 1U servers. Eight servers in a single rack (e.g., rack 4) can be used to provide additional board compute resources according to the El Paso, E4 platform. Sixteen servers distributed across four racks (e.g., racks 1-4) can be used to provide block storage resources according to the E4 platform. These servers can be used to provide 1,280 TiB of capacity.Thirty-six servers distributed across three racks (e.g., racks 5-7) can be used to provide customer enclaves according to an E4 regular platform (e.g., using standard AMD processors) and provide 4608 OCPUs of computing power. Eighteen servers distributed across three racks (e.g., racks 5-7) can be used to provide customer enclaves according to an E4 high-density platform (e.g., using E4 AMD high-density processors) and provide 2304 OCPUs of computing power. Eighteen servers in a single rack (e.g., rack 8) can be used to host Exadata X9M database (DB) nodes (e.g., 18 nodes). Another 18 servers in another rack (e.g., rack 9) can be used to host Exadata X9M high-capacity (HC) nodes (e.g., 15 HC nodes). Racks 10 and 11, with their corresponding 36 servers, can be used for network core resources (e.g., to provide 32 to 128 standard racks). Rack 12 and its 36 servers can be utilized to provide a network CFAB / QFAB, as discussed in connection with FIG.

[0185] As shown, service enclave 2802 may be implemented using servers in racks 1-4, customer service enclave 2804 may be implemented using servers in racks 5-7, Exadata resources may be implemented using servers in racks 8 and 9, and network resources may be implemented using servers in racks 10-12.

[0186] FIG. 29 illustrates a configuration of multiple TORs included in a rack, according to at least one embodiment. The multiple TOR configuration 2900 illustrated in FIG. 29 corresponds to a 3-TOR configuration. The rack includes three TORs (2901, 2902, and 2903) and multiple host machines / servers. In one implementation, fault domains are created within an availability domain (i.e., the rack) by selecting a subset of host machines from the multiple host machines. Each host machine in the selected group of host machines (i.e., the subset of host machines) is communicatively coupled to one of the TORs included in the multiple TORs. For example, as illustrated in FIG. 29, a first subset of host machines from the multiple host machines is illustrated as 2905A. Each host machine / server included in 2905A is communicatively coupled to a first TOR, i.e., TOR1, 2901. Thus, the combination of the first subset of host machines (2905A) and the first TOR (2901) forms a first fault domain.

[0187] A second fault domain is created within the availability domain by selecting a second subset of host machines from the plurality of host machines. Each host machine in the second subset of host machines is communicatively coupled to another TOR included in the plurality of TORs (i.e., a different TOR than the TOR associated with the first fault domain). It is noted that the first subset of host machines is decoupled from the second subset of host machines. For example, as shown in FIG. 29, the second subset of host machines from the plurality of host machines is shown as 2905B. Each host machine / server included in 2905B is communicatively coupled to a second TOR, i.e., TOR2, 2902.

[0188] In a similar manner, a third fault domain can be created within the availability domain by selecting a third subset of host machines from the plurality of host machines. Each host machine in the third subset of host machines is communicatively coupled to another TOR (i.e., a TOR different from the TORs associated with the first and second fault domains). It is noted that the third subset of host machines, along with the first subset of host machines, is separate from the second subset of host machines. For example, as shown in FIG. 29, a third subset of host machines from the plurality of host machines is shown as 2905C. Each host machine / server included in 2905C is communicatively coupled to a third TOR, i.e., TOR3, 2903, forming a third fault domain.

[0189] In FIG. 29, each of the first, second, and third subsets of servers (2905A, 2905B, and 2905C) is shown to include K servers. It is understood that this is in no way limiting to the scope of the present disclosure. A particular subset of servers may include a different number of servers compared to another subset of servers. Additionally, the rack includes multiple network virtualization devices (NVDs). A first subset of NVDs from the multiple NVDs is employed to connect a first subset of server / host machines to a first TOR. Similarly, a second subset of NVDs from the multiple NVDs is employed to connect a second subset of server / host machines to a second TOR, and a third subset of NVDs is employed to connect a third subset of server / host machines to a third TOR.

[0190] Further, for each fault domain (i.e., a combination of a subset of servers and a TOR switch associated with the subset of servers), a set of addresses corresponding to the host machines / servers in the first subset of servers is associated with the TOR switch associated with the first subset of servers. In this manner, the control plane is configured to forward packets destined for a particular server in the first subset of servers to the first TOR associated with the first subset of servers.

[0191] Therefore, the rack configuration shown in FIG. 29 provides three different fault domains, which provide a smaller blast radius (i.e., the percentage of capacity loss when a TOR switch fails) than if all servers in the rack were communicatively coupled to a single TOR switch. Specifically, the rack configuration shown in FIG. 29 provides a blast radius of 33%, i.e., a 33% capacity loss when a single TOR fails. However, it is noted that the probability of multiple TORs failing simultaneously within a rack is very low, i.e., negligible. In one embodiment, the rack configuration of FIG. 29 provides one or more fault domains that can be presented to a customer. Upon receiving a request from a customer requesting allocation of one or more host machines within a rack, the control plane can allocate one or more host machines contained in one or more fault domains based on certain criteria. For example, if high availability is required by a customer, the control plane can allocate host machines in different fault domains.

[0192] 30, an exemplary architecture 3000 of a DRCC framework is shown that provides customers with the full capabilities of a public cloud. In this way, customers can reduce infrastructure and operational costs, upgrade legacy applications with modern cloud services, and meet the most stringent regulatory, data residency, and latency requirements.

[0193] According to some embodiments, FIG. 30 illustrates a data center 3005 (of which the DRCC / PLC 104 of FIG. 1 is an example) including a pair of TORs, i.e., TOR#1 3022 and TOR#2 3024, a network virtualization platform, e.g., NVD 3026, and a compute host 3028 (also referred to herein as a local compute host). It is understood that the compute host 3028 includes multiple virtual machines or bare metal instances. The NVD 3026 is referred to herein as a local NVD. The compute host 3028 includes a host network interface card (i.e., a host NIC). For illustrative purposes, FIG. 30 illustrates the compute host 3028 as including two virtual machines, VM1 and VM2, respectively. It is noted that each of the VMs is communicatively coupled to the host NIC via one of the logical interfaces (e.g., the logical interfaces shown as PF1 and PF2, respectively). It is further noted that the local NVD 3026 may be located in the same chassis as the host NIC included in the compute host 3028.

[0194] A compute host 3028 included in a data center can be coupled to another host machine 3011, referred to herein as a remote host machine. It is understood that a remote host machine can be “any” host machine, for example, (i) another host within a DRCC and located behind another NVD, or (ii) another host in another DRCC (e.g., within a DRCC group for the same customer / organization) and located behind another NVD (e.g., within a DRCC group for the same customer / organization), or (iii) a host machine included in a customer’s premises network. If the host machine is included in a customer’s premises network, the host machine can connect to the DRCC via a Fast-Connect or IPSec VPN tunnel and connect to the host machine in the DRCC using a dynamic routing gateway (DRG). For illustrative purposes, the following description assumes that the remote host machine (e.g., host machine 3011) is a remote host machine included in a DRCC and located behind another NVD (e.g., NVD 3013, provided by a remote TOR 3015). However, it is noted that the features described below are equally applicable to the other cases of remote host machines outlined above. Furthermore, in this case (and as shown in Figure 30), it is understood that two host machines (i.e., local host machine 3028 and remote host machine 3011) may be linked via network fabric 3020. Furthermore, for convenience, NVD 3013 will be referred to herein as the remote NVD.

[0195] According to some embodiments, the local NVD 3026 has multiple physical ports. For example, in one implementation as shown in Figure 30, the local NVD 3026 has two physical ports: a first physical port 3027A (referred to herein as the TOR-facing port) connected to the TORs 3022 and 3024, respectively, and a second physical port 3027B (referred to herein as the host-facing port) connected to the compute host 3028. Each physical port of the local NVD 3026 can be divided into multiple logical ports. For example, as shown in Figure 30, physical port 3027B is divided into two logical ports on the host-facing side, and physical port 3027A is divided into two logical ports on the TOR-facing side.

[0196] Splitting each of the physical ports of the local NVD 3026 provides the flexibility of representing two logical ports, two MAC addresses, and two IP addresses for each physical port of the NVD 3026. For example, in FIG. 30, the overlay IP address and overlay MAC address are indicated by underlined symbols (e.g., B1 , M1 ), while the board IP address and MAC address are shown with ununderlined symbols (e.g., A0, M0). As shown in FIG. 30, a first physical port 3027A of the local NVD 3026 is associated with a first IP address (A1), a second IP address (A3), a first MAC address (M1), and a second MAC address (M3). A second physical port 3027B of the local NVD 3026 is associated with a first overlay IP address ( B1 ), the second overlay IP address ( C1 ), the first overlay MAC address ( M4 ), and a second overlay MAC address ( M6 )

[0197] It is understood that the limit on the number of logical ports that can be obtained by dividing a physical port (e.g., port 3027A) of the NVD3026 is determined by the width of the serializer / deserializer component (i.e., SerDes component) included in the NVD chipset. In one example, each physical port of the NVD3026 can be bifurcated into four logical ports. It is understood that more logical ports can be obtained for each physical port of the NVD3026 through the use of a gearbox component in the NVD. Data center 3005 (i.e., DRCC) provides customers with the full capabilities of a public cloud. Specifically, the DRCC hosts applications and data that require strict data residency, control, and security, and provides low-latency connectivity and a means to leave data in a specific location for data-intensive processing. Thus, customers can utilize all cloud services running directly in their data center, as opposed to a cloud region hundreds or thousands of miles away. Therefore, a DRCC with a smaller footprint (e.g., DRCC / PLC 104 in Figure 1) provides organizations with the opportunity to run workloads outside of the public cloud.

[0198] FIG. 31 illustrates an exemplary network fabric architecture of a DRCC according to some embodiments. The DRCC network fabric architecture 3100 includes a combination of compute fabric blocks (referred to herein as CFABs, 3120A-3120B) and a network fabric block (referred to herein as NFABs, 3115). The NFAB 3115 is communicatively coupled to each of the CFAB blocks (3120A-3120B) via multiple switch blocks (3105, 3110). The multiple switch blocks are also referred to herein as layer 3 (T3) level switches. Each of the multiple switch blocks includes a predetermined number of switches, e.g., four switches. For example, the switch block 3105 includes four switches labeled 3105A-3105D, and the switch block 3110 includes four switches labeled 3110A-3110D.

[0199] According to some embodiments, a compute fabric block (e.g., CFAB block 3120A) is communicatively coupled to multiple switch blocks 3105, 3110. The compute fabric block 3120A includes a set of one or more racks, such as an Exadata rack 3124 or a compute rack 3123. Each rack in the set of one or more racks includes one or more servers configured to execute one or more customer workloads. It is understood that each Exadata rack 3124 can be associated with a cluster network of virtual machines 3125. The CFAB block 3120A further includes a first plurality of switches 3122 organized into a first plurality of levels (e.g., levels labeled CFAB T1 and CFAB T2). The first plurality of switches 3122 communicatively couple the set of one or more racks (e.g., racks 3123, 3124) to the multiple switch blocks (3105, 3110). Specifically, the first plurality of levels associated with the first plurality of switches 3122 of the compute fabric block 3120A include (i) a first tier 1 level of switches, i.e., CFAB T1, and (ii) a first tier 2 level of switches, i.e., CFAB T2.

[0200] The switches in the first tier 1 level are communicatively coupled at a first end to a set of one or more racks and at a second end to switches in the first tier 2 level. Furthermore, the first tier 2 level of switches, i.e., CFAB T2, connects the first tier 1 level of switches, i.e., CFAB T1, to the plurality of switch blocks 3105, 3110. In one embodiment, the first tier 1 level of switches (CFAB T1) in the compute fabric block includes eight switches, and the first tier 2 level of switches (CFAB T2) in the compute fabric block includes four switches. Each switch in the first tier 1 level of switches in the compute fabric block is connected to each switch in the first tier 2 level of switches in the compute fabric block. Furthermore, each switch in the first tier 2 level of switches (CFAB T2) in the compute fabric block is connected to at least one switch in each of the plurality of switch blocks 3105, 3110.

[0201] According to some embodiments, the NFAB block 3115 is communicatively coupled to multiple blocks of switches 3105, 3110. The network fabric block 3115 includes (i) one or more edge devices 3120 and (ii) a second multiple of switches 3118 organized into a second multiple of levels. The one or more edge devices 3120 include a first edge device that provides connectivity to a first external resource. For example, the first external resource may be a public communication network, e.g., the Internet, and the first edge device may be a gateway that provides connectivity to the public communication network. The one or more edge devices 3120 may include a gateway, a backbone edge device, a metro edge device, and a route reflector. Thus, the first edge device, e.g., a gateway, enables access to the first external resource (e.g., the Internet) for workloads executed by servers included in a rack in a set of one or more racks included in the CFAB block 3120A.

[0202] A second plurality of switches 3118 organized into a second plurality of levels (labeled NFAB T1 and NFAB T2) communicatively couples one or more edge devices 3120 to the plurality of switch blocks 3105, 3110. In FIG. 31 , the connections between the plurality of switch blocks and the second plurality of switches 3118 are shown as a logical construct 3116 (NFAB T1 stripe). Detailed connections of the logical construct 3116 are described below with reference to FIG. 32 . According to some embodiments, the second plurality of levels associated with the second plurality of switches 3118 in the network fabric block 3115 include (i) a second tier 1 level of switches, i.e., NFAB T1, and (ii) a second tier 2 level of switches, i.e., NFAB T2. Each switch in the second tier 2 level of switches is communicatively coupled to each switch included in the second tier 1 level of switches, i.e., NFAB T1. In one embodiment, the second tier 1 level switches in the network fabric block include eight switches and the second tier 2 level switches in the network fabric block include four switches.

[0203] According to some embodiments, the initial deployment of the DRCC network architecture includes deploying an NFAB block (3115), one CFAB block (3120A), and a T3 switch layer (i.e., multiple switch blocks 3105, 3110) that interconnects the NFABs to the CFABs. It is understood that additional CFAB blocks (and additional T3 layer switch blocks) can be deployed on the fly (i.e., in real time) based on customer requirements. It is understood that the number of switches (e.g., eight switches) described above with respect to the first layer 1 level of switches or the second layer 1 level of switches in the network fabric is for illustrative purposes only. The number of switches included in the first layer 1 level or the second layer 1 level may be any other number of switches, such as four or sixteen, or a variable number of switches. Similarly, the second layer 2 level of switches in the network fabric block as described above includes four switches. However, it is understood that this is for illustrative purposes only, and the actual number of switches at this level may be a variable number of switches, for example, half the number of switches in layer 1.

[0204] Figure 32 shows connections between the NFAB block and multiple switch blocks, and connections within the NFAB block, i.e., connections between a second plurality of switches organized into a second plurality of levels in the NFAB. The second plurality of levels associated with the second plurality of switches in the NFAB include (i) a second layer 1 level of switches (i.e., NFAB layer 1, 3205) and (ii) a second layer 2 level of switches (i.e., NFAB layer 2, 3210). In one example, the second layer 1 level of switches in the NFAB includes eight switches (labeled t1-r1 through t1-r8 in Figure 32), and the second layer 2 level of switches in the network fabric block includes four switches (labeled t2-r1 through t2-r4 in Figure 32).

[0205] As shown in Figure 32, a first subset of switches included in the second Layer 1 level of switches (i.e., NFAB Layer 1) are communicatively coupled at a first end to one or more edge devices. For example, as shown in Figure 32, switches t1-r1, t1-r2, t1-r3, and t1-r4 are each coupled to route reflector 3220A and VPN gateway 3220. Furthermore, a second subset of switches included in the second Layer 1 level of switches (e.g., switches t1-r5, t1-r6, t1-r7, and t1-r8) are communicatively coupled at a first end to a plurality of switch blocks (i.e., the block of switches labeled as CFAB Layer 3 in Figure 32). It is noted that the second subset of switches may also be coupled to WDM metro switches, i.e., switches used to interconnect racks located in different buildings. The first and second subsets of switches included in the second tier 1 level of switches are coupled at a second end to a second tier 2 level of switches included in the network fabric block.

[0206] Specifically, a T2 layer of switches (e.g., four switches) 3210 is employed in the NFAB to provide connectivity between switches in the T1 layer 3205. As shown, each of the four switches included in the T2 layer switches of the NFAB connects to a respective T1 layer switch. In this manner, service enclaves included in different NFAB blocks are communicatively coupled to edge devices via the NFAB fabric. Thus, a workload executed by a server included in a rack of compute fabric blocks accesses a first external resource (e.g., the Internet) by establishing a connection to a first switch in the multiple switch blocks. 32, this connection is further routed as follows: (i) from the first switch to a second switch included in a second subset of switches in a second tier 1 level of switches (e.g., switches t1-r5, t1-r6, t1-r7, and t1-r8), (ii) from the second switch to a third switch included in a second tier 2 level of switches (e.g., one of the switches from the group of switches t1-r1, t1-r2, t1-r3, t1-r4), (iii) from the third switch to a fourth switch included in a first subset of switches in the second tier 1 level of switches (e.g., switches t1-r1, t1-r2, t1-r3, and t1-r4), and (iv) from the fourth switch to a gateway. It will be understood that the CFAB and JFAB blocks described above with respect to FIGS. 31 and 32 support 400G connections and operate with a power budget of 100KW. The architecture includes a total of three network racks, plus an optional fourth rack to support backbone and metro connections.

[0207] 33 illustrates an example computer system 3300 upon which various embodiments may be implemented. System 3300 may be used to implement any of the computer systems described above. As shown, computer system 3300 includes a processing unit 3304 that communicates with multiple peripheral subsystems via a bus subsystem 3302. These peripheral subsystems may include a processing acceleration unit 3306, an I / O subsystem 3308, a storage subsystem 3318, and a communication subsystem 3324. Storage subsystem 3318 includes a tangible computer-readable storage medium 3322 and a system memory 3310.

[0208] The bus subsystem 3302 provides a mechanism for allowing the various components and subsystems of the computer system 3300 to communicate with each other as intended. While the bus subsystem 3302 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 3302 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus, which may be implemented as a Mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0209] Processing unit 3304, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of computer system 3300. Processing unit 3304 may include one or more processors. These processors may include single-core or multi-core processors. In some embodiments, processing unit 3304 may be implemented as one or more independent processing units 3332 and / or 3334, with a single-core or multi-core processor included in each processing unit. In other embodiments, processing unit 3304 may be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0210] In various embodiments, the processing unit 3304 may execute various programs according to program code and may maintain multiple simultaneously executing programs or processes. At any given time, some or all of the program code to be executed may reside in the processor 3304 and / or in the storage subsystem 3318. Through suitable programming, the processor 3304 may provide the various functions described above. The computer system 3300 may further include a processing acceleration unit 3306, which may include a digital signal processor (DSP), a special purpose processor, etc.

[0211] The I / O subsystem 3308 can include user interface input devices and user interface output devices. User interface input devices can include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touchscreen integrated into a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, a voice input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices can include, for example, motion sensing and / or gesture recognition devices such as a Microsoft Kinect® motion sensor that enables a user to control and interact with an input device such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and spoken commands. User interface input devices can also include eye gesture recognition devices such as a Google Glass® blink detector that detects eye activity from a user (e.g., “blinking” during picture taking and / or menu selection) and translates the eye gesture as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (e.g., Siri® Navigator) via voice commands.

[0212] User interface input devices may also include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads, and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser ranging devices, and eye-tracking devices. Furthermore, user interface input devices may include medical imaging input devices such as, for example, computed tomography (CT) scanners, magnetic resonance imaging (MRI) scanners, positron emission tomography (PET) scanners, and medical ultrasound scanners. User interface input devices may also include audio input devices such as, for example, MIDI keyboards, digital musical instruments, and the like.

[0213] User interface output devices may include a display subsystem, indicator lights, or non-visual displays such as audio output devices, etc. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), a liquid crystal display (LCD), or a plasma display, a projection device, a touch screen, etc. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 3300 to a user or to another computer. For example, user interface output devices may include various display devices that visually convey text, graphics, and audio / video information, such as, but not limited to, monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

[0214] Computer system 3300 may include a storage subsystem 3318, which includes software elements that are currently shown as residing in system memory 3310. System memory 3310 may store program instructions that are loadable into and executable by processing unit 3304, as well as data that is generated during the execution of these programs.

[0215] Depending on the configuration and type of computer system 3300, system memory 3310 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated on and executed by the processing unit 3304. In some implementations, system memory 3310 may include several different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, ROM may typically store a basic input / output system (BIOS), which contains the basic routines that help to transfer information between elements within the computer system 3300, such as during start-up. By way of example and not limitation, system memory 3310 also illustrates application programs 3312, which may include client applications, a web browser, a middle-tier application, a relational database management system (RDBMS), etc.; program data 3314; and an operating system 3316. By way of example, operating system 3316 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS operating systems.

[0216] The storage subsystem 3318 may also provide a tangible, computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. The storage subsystem 3318 may store software (programs, code modules, instructions) that, when executed by the processor, provide the functionality described above. These software modules or instructions may be executed by the processing unit 3304. The storage subsystem 3318 may also provide a repository for storing data used in accordance with the present disclosure.

[0217] Storage subsystem 3300 may also include computer readable storage medium reader 3320, which may further be connected to computer readable storage medium 3322. Optionally combined with system memory 3310, computer readable storage medium 3322 may collectively represent remote, local, fixed, and / or removable storage devices, plus storage media, for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer readable information.

[0218] The computer-readable storage medium 3322 containing the code, or portions of code, can include any suitable medium known or used in the art, including, but not limited to, storage and communication media such as volatile and nonvolatile, removable and non-removable media, implemented in any method or technology for storing and / or transmitting information. This can include tangible computer-readable storage media such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, or other tangible computer-readable medium. This can also include non-tangible computer-readable media, such as data signals, data transmission, or any other medium that can be used to transmit the desired information and that can be accessed by the computing system 3300.

[0219] By way of example, the computer-readable storage medium 3322 may include a hard disk drive that reads from or writes to non-removable, non-volatile magnetic media, a magnetic disk drive that reads from or writes to removable, non-volatile magnetic disks, and an optical disk drive that reads from or writes to removable, non-volatile optical disks such as CD-ROMs, DVDs, and Blu-Ray® disks or other optical media. The computer-readable storage medium 3322 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, etc. The computer-readable storage media 3322 can also include flash memory-based SSDs, enterprise flash drives, solid-state drives (SSDs) based on non-volatile memory such as solid-state ROM, solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, volatile memory-based SSDs such as magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. Disk drives and their associated computer-readable media can provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 3300.

[0220] The communications subsystem 3324 provides an interface to other computer systems and networks. The communications subsystem 3324 serves as an interface for receiving data from the computer system 3300 and transmitting data from the computer system 3300 to other systems. For example, the communications subsystem 3324 may enable the computer system 3300 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 3324 may include a radio frequency (RF) transceiver component for accessing wireless voice and / or data networks (e.g., using cellular technology, advanced data network technologies such as 3G, 4G, or EDGE (enhanced data rates for global evolution), Wi-Fi (IEEE 802.11 family of standards, or other mobile communications technologies, or any combination thereof), a global positioning system (GPS) receiver component, and / or other components. In some embodiments, the communications subsystem 3324 may provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

[0221] In some embodiments, the communications subsystem 3324 may also receive incoming communications in the form of structured and / or unstructured data feeds 3326, event streams 3328, event updates 3330, etc., on behalf of one or more users who may use the computer system 3300.

[0222] By way of example, the communications subsystem 3324 may be configured to receive data feeds 3326 in real time from users of social networks and / or other communications services, such as web feeds such as Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party sources.

[0223] Additionally, the communications subsystem 3324 may be configured to receive data in the form of a continuous data stream, which may include an event stream 3328 of real-time events and / or event updates 3330, which may be continuous or infinite in nature with no apparent end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0224] The communications subsystem 3324 may also be configured to output structured and / or unstructured data feeds 3326, event streams 3328, event updates 3330, etc. to one or more databases that can communicate with one or more streaming data source computers coupled to the computer system 3300.

[0225] The computer system 3300 can be one of a variety of types, including a handheld portable device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.

[0226] Because the nature of computers and networks is constantly changing, the description of computer system 3300 shown in the figure is intended merely as a specific example. Many other configurations are possible, having more or fewer components than the system shown in the figure. For example, customized hardware may be used, and / or particular elements may be implemented in hardware, firmware, software (including applets), or a combination. Furthermore, connection to other computing devices, such as network input / output devices, may be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other manners and / or methods for implementing the various embodiments.

[0227] The embodiments may be implemented by using a computer program product comprising a computer program / instructions which, when executed by a processor, cause the processor to perform any of the methods described in this disclosure.

[0228] While specific embodiments have been described, various modifications, variations, alternative constructions, and equivalents are encompassed within the scope of the present disclosure. The embodiments are not limited to operation in one specific data processing environment, but can freely operate in multiple data processing environments. Furthermore, while the embodiments have been described using a particular sequence of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described sequence of transactions and steps. Various features and aspects of the above-described embodiments may be used individually or jointly.

[0229] Furthermore, while embodiments have been described using particular combinations of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments may be implemented exclusively in hardware, exclusively in software, or using a combination thereof. Various processes described herein may be implemented on the same processor or on any combination of different processors. Thus, when a component or module is described as being configured to perform certain operations, such configuration may be achieved, for example, by designing electronic circuitry to perform the operations, by programming a programmable electronic circuit (such as a microprocessor) to perform the operations, or any combination thereof. Processes may communicate using various techniques, including, but not limited to, conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0230] Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense. However, it will be apparent that additions, subtractions, deletions, and other modifications and changes may be made to the specification and drawings without departing from the broader spirit and scope as set forth in the appended claims. Accordingly, although specific disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the appended claims.

[0231] In the context of describing the disclosed embodiments (particularly in the context of the appended claims), use of the terms "a," "an," and "the" and similar referents should be construed to encompass both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" should be construed as open-ended terms (i.e., meaning "including, but not limited to"), unless otherwise noted. The term "connected" should be construed as contained within, attached to, or joined to one another, either partially or as a whole, even if there is intervening material. The recitation of ranges of values ​​herein, unless otherwise indicated herein, is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, and each separate value is incorporated herein as if it were individually recited herein. Unless otherwise indicated herein or clearly contradicted by context, all methods described herein can be performed in any suitable order. Any and all examples provided herein, or the use of exemplary language (e.g., "etc.") are intended merely to clarify the embodiments and do not limit the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0232] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood in context as generally used to indicate that an item, term, etc. may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise. Thus, such disjunctive language is not intended to, and should not, generally imply that some embodiments require that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0233] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of these preferred embodiments will become apparent to those skilled in the art upon reading the foregoing description. Such variations will be readily apparent to those skilled in the art, and the present disclosure may be practiced in ways other than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, unless otherwise indicated herein, any combination of the above-described elements in all possible variations thereof is encompassed by the present disclosure.

[0234] Example embodiments of the present disclosure can be described in light of the following provisions. Clause 1. A method is disclosed. The method can include a computing device implementing, at least in part, a dedicated regional cloud including multiple cloud infrastructure components that provide corresponding cloud services associated with a cloud service provider. In some embodiments, the multiple cloud infrastructure components are hosted by one or more computing devices located at a third-party location. In some embodiments, the third-party location is associated with a third-party entity different from the cloud service provider. The method can include the computing device obtaining capacity and usage data associated with at least one of the multiple cloud infrastructure components. The method can include the computing device executing, in the dedicated regional cloud located at the third-party location, a control center service that processes at least a portion of the capacity and usage data associated with at least one of the multiple cloud infrastructure components and presents it in a user interface hosted in the dedicated regional cloud. The method can include the computing device storing the capacity and usage data in a data store of the dedicated regional cloud for later use.

[0235] Clause 2. The computer-implemented method of clause 1, wherein the capacity and usage data is initially obtained by a data processing service operating in a tenancy separate from the tenancy associated with the third-party entity.

[0236] Clause 3. The computer-implemented method of clause 1 or clause 2, wherein the capacity and usage data presented in the user interface includes physical space data indicating the number of units of physical space available for placing additional computing devices at the third-party location.

[0237] Clause 4. A computer-implemented method according to any one of clauses 1 to 3, wherein the user interface hosted within the dedicated region cloud is implemented at least in part based on a console plug-in installed on an existing dedicated region console of the dedicated region cloud.

[0238] Clause 5. The computer-implemented method of any of Clauses 1 to 4, wherein the capacity and usage data includes first capacity and usage data corresponding to a third-party entity and second capacity and usage data corresponding to a cloud service provider.

[0239] Clause 6. The computer-implemented method of clause 5, wherein the capacity and usage data is stored in a data store of a dedicated regional cloud, whereby the capacity and usage data is retrieved by one or more corresponding computing devices of a central cloud computing environment hosted by a cloud service provider.

[0240] Clause 7. The computer-implemented method of clause 6, wherein at least one of the one or more corresponding computing devices of the central cloud computing environment presents the first capacity and usage data along with additional capacity and usage data obtained from one or more additional dedicated regional clouds individually associated with respective third-party entities.

[0241] Clause 8. A computing device is disclosed. The computing device may include one or more memories and one or more processors configured to execute computer-executable instructions to perform the method described in any of clauses 1-7.

[0242] Clause 9. A system is disclosed. The system may include a memory configured to store computer-executable instructions and one or more processors configured to execute the instructions to perform the method described in any of clauses 1 to 7.

[0243] Clause 10. A non-transitory computer-readable medium is disclosed. The non-transitory computer-readable medium can store computer-executable instructions that, when executed by a processor, cause the processor to perform the method described in any of clauses 1 to 7.

[0244] All references cited herein, including publications, patent applications, and patents, are incorporated by reference to the same extent as if each individual reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0245] While the foregoing specification has described aspects of the disclosure with reference to specific embodiments thereof, those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above-described disclosure can be used individually or jointly. Moreover, the embodiments can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive.

Claims

1. A method by which a computer performs an action, The computing device includes, at least in part, running a dedicated regional cloud that includes multiple cloud infrastructure components providing corresponding cloud services associated with a cloud service provider, The aforementioned plurality of cloud infrastructure components are hosted by one or more computing devices located in third-party locations, and the third-party locations are associated with third-party entities different from the cloud service provider. The aforementioned method, The computing device acquires capacity and usage data associated with at least one of the plurality of cloud infrastructure components, The computing device processes at least a portion of the capacity and usage data associated with at least one of the multiple cloud infrastructure component clouds within the dedicated regional cloud located at the third-party location, and performs control center services presented in a user interface hosted within the dedicated regional cloud. A method performed by a computer, further comprising the computing device storing the capacity and usage data in a data store in the dedicated regional cloud for later use.

2. The method performed by a computer according to claim 1, wherein the capacity and usage data are initially obtained by a data processing service operating in a tenancy separate from the tenancy associated with the third-party entity.

3. The computer method according to claim 1, wherein the capacity and usage data presented in the user interface includes physical space data indicating the number of units of physical space available for deploying additional computing devices at the third-party location.

4. The computer execution method according to claim 1, wherein the user interface hosted within the dedicated region cloud is implemented at least in part based on a console plugin installed on an existing dedicated region console of the dedicated region cloud.

5. The method performed by a computer according to claim 1, wherein the capacity and usage data includes first capacity and usage data corresponding to the third-party entity and second capacity and usage data corresponding to the cloud service provider.

6. The method performed by a computer according to claim 5, wherein the capacity and usage data is stored in the data store of the dedicated regional cloud, and the capacity and usage data is acquired by one or more corresponding computing devices in a central cloud computing environment hosted by the cloud service provider.

7. At least one of the one or more corresponding computing devices of the central cloud computing environment shall, The method performed by the computer according to claim 6, presenting additional capacity and usage data obtained from one or more additional dedicated regional clouds individually associated with each third-party entity.

8. A computing device, One or more processors, It comprises one or more memories for storing computer executable instructions, When the aforementioned computer executable instruction is executed by one or more processors of the computing device, the computing device will: A dedicated regional cloud is run, at least in part, including multiple cloud infrastructure components that provide corresponding cloud services associated with a cloud service provider, the multiple cloud infrastructure components being hosted by one or more computing devices located in third-party locations, the third-party locations being associated with a third-party entity different from the cloud service provider, and the computer executable instructions are further to the computing devices, To obtain capacity and usage data associated with at least one of the aforementioned multiple cloud infrastructure components, Within the dedicated regional cloud located at the third-party location, the system processes at least a portion of the capacity and usage data associated with at least one of the multiple cloud infrastructure component clouds and executes a control center service presented in a user interface hosted within the dedicated regional cloud. A computing device that stores the aforementioned capacity and usage data in a data store in the dedicated regional cloud for later use.

9. The computing device according to claim 8, wherein the capacity and usage data are initially obtained by a data processing service operating in a tenancy separate from the tenancy associated with the third-party entity.

10. The computing device according to claim 8 or 9, wherein the capacity and usage data presented in the user interface includes physical space data indicating the number of units of physical space available for deploying additional computing devices at the third-party location.

11. The computing device according to claim 8 or 9, wherein the user interface hosted within the dedicated region cloud is implemented at least in part based on a console plugin installed on an existing dedicated region console of the dedicated region cloud.

12. The computing device according to claim 8 or 9, wherein the capacity and usage data includes first capacity and usage data corresponding to the third-party entity and second capacity and usage data corresponding to the cloud service provider.

13. The computing device according to claim 12, wherein the capacity and usage data are stored in the data store of the dedicated regional cloud, and the capacity and usage data are acquired by one or more corresponding computing devices in a central cloud computing environment hosted by the cloud service provider.

14. The computing device according to claim 13, wherein at least one of the one or more corresponding computing devices of the central cloud computing environment presents the first capacity and usage data together with additional capacity and usage data obtained from one or more additional dedicated regional clouds individually associated with each third-party entity.

15. A program for causing a computer to perform the method described in any one of Claims 1 to 7.

Images