System and method for compartment quota in cloud infrastructure environment

Abstract

To provide systems and methods for providing compartment quotas for cloud infrastructure environment.SOLUTION: In a system, instances of cloud infrastructure environment 600 are hosted in different regions, such as cloud infrastructure regions 620, 660, 640, 650 and accessed via a console 603, SDK or APIs, by customer networks 601 via a network 602, such as the Internet. A customer network 601 comprises, for example, a single computer, a network of customer computers, or other such networks.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] Copyright Notice A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of this patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

[0002] Priority claims and cross-references to related applications: This application is a continuation of U.S. Provisional Patent Application No. 62 / 884,936, filed August 9, 2019, entitled "SYSTEM AND METHOD FOR COMPARTMENT QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT"; No. 62 / 884,994, entitled “QUAOTA POLICY LANGUAGE IN A CLOUD INFRASTRUCTURE ENVIRONMENT”; and U.S. Provisional Patent Application No. 62 / 884,994, entitled “SYSTEM AND This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 884,998, entitled "METHOD FOR SUPPORTING A USAGE CALCULATION PROCESS IN A CLOUD INFRASTRUCTURE ENVIRONMENT," each of which is incorporated herein by reference in its entirety.

[0003] This application is also related to U.S. patent application Ser. No. 16 / 986,162, filed on August 5, 2020, entitled "SYSTEM AND METHOD FOR COMPARTMENT QUOTAS IN A CLOUD INFRASTRUCTURE ENVIRONMENT"; No. 16 / 986,163, entitled “A QUOTA POLICY LANGUAGE IN A CLOUD INFRASTRUCTURE ENVIRONMENT”; and U.S. patent application Ser. No. 16 / 986,163, entitled “SYSTEM AND This application also claims the benefit of priority to U.S. patent application Ser. No. 16 / 986,164, entitled "METHOD FOR SUPPORTING A USAGE CALCULATION PROCESS IN A CLOUD INFRASTRUCTURE ENVIRONMENT," each of which is incorporated herein by reference in its entirety.

[0004] Technical Field The embodiments described herein generally relate to a cloud infrastructure environment, such as Infrastructure as a Service (IaaS). The present invention relates to a cloud infrastructure environment, and more particularly to a system and method for providing such a system and method for providing resource constraints within such a cloud infrastructure environment. [Background technology]

[0005] background: A cloud infrastructure environment can comprise a set of complementary cloud services that enable users and clients (throughout this specification the terms "clients" and "customers" can be used interchangeably) to build and run a wide range of applications and services in a highly available hosted environment.

[0006] Every year, more and more businesses and organizations are migrating their mission-critical applications and systems to cloud infrastructure environments. The reasons for this shift are manifold. For example, many businesses are moving to the cloud to reduce the cost and complexity of operating, maintaining, and building out on-premise infrastructure. Similarly, cloud infrastructure also enables a more rapid information technology (IT) delivery mechanism. Some businesses and organizations are also migrating their cloud infrastructure environments to more See it as a way to gain a competitive advantage by adapting to agile systems.

[0007] In the Infrastructure as a Service (IaaS) model, cloud providers In a traditional setting, infrastructure components that would be on-premise at each customer / client location can be provided, hosted and managed. Such traditionally on-premise components can include hardware, e.g., data warehouses and data centres, servers, storage, networking hardware, and software such as virtualisation software.

[0008] In addition to providing hardware and software that would traditionally be on-premise, IaaS providers can also provide services to their clients and customers. As an example, clients and customers can be enabled to tailor their IaaS subscriptions to fit their needs, which in turn allows for detailed and decomposed billing and invoicing. IaaS can also support features such as load balancing, redundancy, replication, recovery, etc. Because such services are provided and supported by the IaaS provider (rather than the customer), this allows clients and customers to focus more on improving their business by pushing further into automation and orchestration for their services.

[0009] Cloud infrastructure allows users and clients to seamlessly run traditional enterprise applications alongside cloud-native apps, all on the same platform, reducing operational overhead and enabling direct connectivity between both types of workloads. Summary of the Invention [Means for solving the problem]

[0010] overview: According to an embodiment, a system and method for providing compartment quotas for a cloud infrastructure environment is described herein. According to an embodiment, a cloud administrator generally does not have the ability to limit resource usage in an existing cloud. Giving a user permission to create resources allows the user to create any number of resources up to a predefined account limit. Compartment quotas allow administrators to limit users' resource usage to appropriate levels, allowing fine-tuned cost control.

[0011] According to an embodiment, customers can be assigned service level limits defined by the cloud infrastructure environment upon account creation. These service level limits limit the total number of resources a customer can create across the tenancy (e.g., across multiple regions with multiple compartments). Tenancy and compartment administrators can utilize compartment quotas to set resource-specific limits. Without such compartment limits, a user authorized to launch an instance may consume all available capacity in the entire tenancy. Compartment resource limits solve this problem and are distinct from service limits and are set and customized by clients and customers, e.g., via the console, SDK, or API. Compartment limits are applied on top of service limits and can be inherited through nested compartment hierarchies. This allows compartment administrators to limit resource consumption and set boundaries around acceptable resource usage.

[0012] According to one embodiment, an allocation policy in a cloud infrastructure environment Systems and methods for supporting languages ​​are described herein. Allocation policies can be configured by setting statement syntax. To set an allocation, an allocation can establish several elements. Each allocation can be unique within a service family (e.g., compute), and thus each allocation can define a target service along with an allocation name. An allocation can then define a value to set the allocation to, and the compartment the allocation targets. There can be a set of conditions that can be included to determine when the allocation applies.

[0013] According to certain embodiments, systems and methods are described herein for supporting a usage computation process or algorithm in a cloud infrastructure environment. The usage computation process can be used to determine whether a requested transaction targeting a compartment in a tree structure of compartments violates any compartment quotas or limits in a parent compartment in the tree structure. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 illustrates a system for providing a cloud infrastructure environment according to an embodiment. [Diagram 2] FIG. 1 illustrates a system for providing a cloud infrastructure region within a cloud infrastructure environment according to an embodiment. [Diagram 3] FIG. 1 illustrates a system for providing compartment policies within compartments across cloud infrastructure regions in a cloud infrastructure environment according to an embodiment. [Figure 4] FIG. 1 illustrates a system for compartment migration within a cloud infrastructure environment according to an embodiment. [Diagram 5] FIG. 1 illustrates a system for policy management and enforcement during compartment movement within a cloud infrastructure environment. [Figure 6] FIG. 1 illustrates a system for supporting compartment allocation in a cloud infrastructure environment, according to one embodiment. [Figure 7] FIG. 1 illustrates a system for supporting compartment allocation in a cloud infrastructure environment, according to one embodiment. [Figure 8] 1 is a flowchart of a method for creating compartment assignments, according to one embodiment. [Figure 9]1 is a flowchart of a method for modifying compartment assignments, according to one embodiment. [Figure 10] FIG. 1 illustrates an architecture for a system for enforcing compartment allocation in a cloud infrastructure environment, according to one embodiment. [Figure 11] 1 is a flowchart of a method for supporting compartment allocation in a cloud infrastructure environment, according to one embodiment. [Figure 12a] FIG. 1 illustrates an example compartment allocation policy statement according to an embodiment. [Figure 12b] FIG. 1 illustrates an example compartment allocation policy statement according to an embodiment. [Figure 12c] FIG. 1 illustrates an example compartment allocation policy statement according to an embodiment. [Figure 13] FIG. 2 illustrates an example of an allocation policy statement according to an embodiment. [Figure 14] FIG. 2 illustrates an example of an allocation policy statement according to an embodiment. [Figure 15] FIG. 2 illustrates an example of an allocation policy statement according to an embodiment. [Figure 16] FIG. 2 illustrates an example of an allocation policy statement according to an embodiment. [Figure 17] FIG. 2 illustrates an example of an allocation policy statement according to an embodiment. [Figure 18] 1 is a flowchart of a method for supporting an allocation policy language in a cloud infrastructure environment according to an embodiment. [Figure 19] FIG. 1 illustrates an architecture for a system for enforcing compartment allocation in a cloud infrastructure environment, according to one embodiment. [Figure 20]1 is a flowchart of a method for supporting a usage computing process in a cloud infrastructure environment, according to one embodiment. [Figure 21] 1 is a flowchart of a method for supporting a usage computing process in a cloud infrastructure environment, according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Detailed Description: According to embodiments herein, the terms "bare metal host," "bare metal instance," or "bare metal compute instance" may refer to a physical host ("bare metal") machine provided for use by a cloud infrastructure environment. A bare metal compute instance runs directly on a bare metal server without a hypervisor. Once a bare metal instance is provisioned, the user / client can maintain sole control of the physical CPU, memory, and network interface card (NIC). The user / client can configure and utilize the full capabilities of each physical machine as if it were hardware running in their own data center. The user / client does not share the physical machine with other tenants.

[0016] According to embodiments herein, a cloud infrastructure environment may be physically hosted in regions and availability domains. The term "region" may refer to a localized geographic area. The term "availability domain" may refer to one or more data centers located within a region. A region is composed of one or more availability domains. Cloud infrastructure may be region-specific, such as a virtual cloud network, or availability domain-specific, such as a compute instance. Availability domains are isolated from each other, fault-tolerant, and unlikely to fail simultaneously or be affected by the failure of another availability domain. When a user / client configures his / her cloud service, the user / client may use multiple availability domains to ensure high availability and protect against resource failures. Some resources must be created in the same availability domain, such as an instance and its associated storage volume.

[0017] According to embodiments herein, the term "realm" may refer to a logical collection of regions. Realms are isolated from each other and do not share any data. A client tenancy may exist within a single realm and have access to each of the regions that belong to that realm. Realms may be provided, for example, for commercial and government cloud regions.

[0018] According to embodiments herein, the term "console" may refer to a (e.g., web-based) user interface that a user / client may use to access and manage a cloud infrastructure environment.

[0019] According to embodiments herein, the term "tenancy" may refer to a secure and isolated partition within a cloud infrastructure environment. When a client / user signs up for a cloud infrastructure environment, the cloud infrastructure environment may create a tenancy for that user / client (or their company). A tenancy may be where a user / client creates, organizes, and manages their cloud resources.

[0020] According to embodiments herein, the term "compartment" may refer to a collection of related resources (instances, virtual cloud networks, block volumes, etc.) that may only be accessed by a specific group that has been granted permission by an administrator. Compartments allow clients / users to organize their cloud resources and control access to them. When a client / user begins working with resources in the console, compartments may provide a filter for what the client / user is looking at.

[0021] According to embodiments herein, the term "tenancy" may refer to a root compartment that contains all of a tenant's cloud resources. Additional compartments may be created within the tenancy (root compartment) and corresponding policies to control access to resources within each compartment. When a user / client creates a cloud resource, such as an instance, block volume, or cloud network, the user / client may specify which compartment the resource should belong to.

[0022] According to embodiments herein, the term "virtual cloud network" may refer to a virtual version of a traditional network, including subnets, route tables, and gateways, in which instances operate. A cloud network exists within a single region but includes all availability domains of that region. Each subnet defined in a cloud network may either be within a single availability domain or span all availability domains within that region. At least one cloud network may be set up before an instance may be launched.

[0023] According to embodiments herein, the term "instance" may refer to a computing host operating within a cloud. A cloud infrastructure environment instance allows users / clients to utilize hosted physical hardware as opposed to traditional software-based virtual machines, which may provide increased security and performance.

[0024] According to embodiments herein, the term "image" may refer to a template of a virtual hard drive that defines an operating system and other software for an instance, such as, for example, LINUX. When an instance is launched, its characteristics can be defined by selecting its image. A set of images may be provided, and an image may be used from an existing instance that is already configured (e.g., as a template) to use an instance with the same software and customizations.

[0025] According to an embodiment of the present specification, the term "shape" may refer to the specification of the number of CPUs and the amount of memory to be allocated to an instance. In load balancing, the shape may determine the pre-provisioned total maximum capacity (bandwidth) of the load balancer for ingress + egress traffic. Available shapes are, for example, 100 These can include Mbps, 400Mbps, and 8000Mbps.

[0026] According to an embodiment of the present specification, the term "key pair" may refer to an authentication mechanism used in a cloud infrastructure environment. A key pair consists of a private key file and a public key file. The public key can be uploaded while the private key is kept on the user / client's device. The private key is secret to the user / client, like a password. Key pairs may be generated according to different specifications, such as an instance SSH key pair and an API signing key pair. The instance SSH key pair is used to establish a secure shell (SSH) connection to the instance. When the instance is provisioned, a public key may be provided, which is stored in the instance's authorized key file. To log on to the instance, a private key is provided, which is verified with the public key. The API signing key pair is in PEM (Privacy Enhanced Mail) format and is used to authenticate the user / client when submitting an API request.

[0027] According to embodiments herein, the term "block volume" may refer to a virtual disk that provides persistent block storage for a cloud infrastructure environment instance. A block volume may be used, for example, in a manner similar to a physical hard drive on a computer, for example, to store data and applications. A volume may be detached from one instance and attached to another instance without data loss.

[0028] According to embodiments herein, the term "object storage" may refer to a storage architecture that may be used to store and manage data as objects. Data files may be of any type. Once data is uploaded to object storage, it may be accessed from any location. Object storage may be used when there is a need to store large amounts of data and the data does not change very frequently. Typical uses for object storage include, but are not limited to, data backup, file sharing, and storage of unstructured data (e.g., logs and sensor-generated data).

[0029] According to embodiments herein, the term "bucket" may refer to a logical container for storing data and files. A bucket may contain an unlimited number of objects.

[0030] As described above, a cloud infrastructure environment can comprise a set of complementary cloud services that enable users and clients to build and run a wide range of applications and services in a highly available hosted environment.

[0031] FIG. 1 illustrates a system for providing a cloud infrastructure environment, according to one embodiment.

[0032] According to an embodiment, a cloud infrastructure environment 100, which may run on a number of hardware and software resources 112, may comprise a console interface 102 and an API 104. In addition, the cloud infrastructure environment 100 may support a number of governance services 110, identity and access management (IAM) services 120, and provisioning services 130. The cloud infrastructure environment 100 may also include, for example, a computer resource layer 150, a network resource layer 160, and a storage resource layer 170. A number of resources 140 may be supported at a layer, such as resource layer 170.

[0033] According to an embodiment, a client device, such as a computing device 10 having device hardware (processor, memory, etc.) 12, can communicate with a cloud infrastructure environment over a network, such as, for example, a wide area network (WAN), a local area network (LAN), or the Internet. The client device can include an administrator application 14, which can include a user interface 16.

[0034] According to an embodiment, tenancies may be supported within the cloud infrastructure environment. Upon registration and deployment, a tenancy may be created for each client / customer, which may provide a secure and isolated partition within the cloud infrastructure where the client can create, organize, and manage their cloud resources.

[0035] According to an embodiment, the console interface 102 and API 104 provide clients with access and control over their respective portions of the infrastructure environment. According to an embodiment, the console interface may include an intuitive graphical interface that allows clients to create and manage resources, instances, cloud networks, and storage volumes, as well as manage users associated with the client and set permissions within the client. Similarly, the API 104 may include a REST API that utilizes, for example, HTTPS (Hypertext Transfer Protocol Secure).

[0036] According to one embodiment, an example of a console interface or API may be a configuration management tool (e.g., Ansible). The configuration management tool may be a cloud infrastructure Configuration management tools can be used for infrastructure provisioning, orchestration, and configuration management. Configuration management tools can enable clients to automate the configuration and provisioning of cloud infrastructure, the deployment and updates of software assets, and the orchestration of complex operational processes.

[0037] According to an embodiment, the governance service 110 of the cloud infrastructure environment provides clients with tools that enable simple resource management, help clients manage costs, and control access to the cloud infrastructure. As an example, the governance service can provide tagging, which allows clients to apply tags to their resources for informational or operational reasons. Predefined tags can be controlled to avoid incorrect tags being applied to resources. Tags can also provide a flexible targeting mechanism for management scripts. Similarly, the governance service can enable budget management, tracking actual and forecasted expenses all from one place. This allows clients to stay on top of usage with a cost analysis dashboard, filtering by compartment and tags to analyze spending by department, team, and project. Such data can also be exported for detailed resource utilization reporting and integration with existing cloud management and business intelligence tools. The governance service can also log events that can be later searched, stored, and analyzed for security, compliance, and resource optimization across cloud infrastructure entitlements and compartments.

[0038] According to one embodiment, an identity and access management (IAM) service 12 For each client / customer / user in the IAM service, 0 can create a user profile associated with the user credentials (e.g., username and password). Clients can also be granted administrative privileges in the cloud infrastructure via the IAM service.

[0039] According to an embodiment, the identity and access management service can be integrated with a cloud infrastructure environment: upon client registration, the IAM service can create separate user credentials in the identity service, which can then enable single sign-on to the cloud infrastructure service and access to additional cloud services.

[0040] According to an embodiment, a provisioning service 130 can provision a tenancy within a cloud infrastructure service, such as, for example, within resources 140. The provisioning service can be accessed and controlled, for example, through a console interface or via one or more APIs, such as API 104. The provisioning service can enable clients to provision and manage compute hosts, which can be referred to as instances. Clients can launch instances as needed to meet compute and application requirements. After a client launches an instance, the provisioned instance can be accessed, for example, from a client device. The provisioning service can also provide for rebooting an instance, attaching and detaching volumes from an instance, and terminating an instance.

[0041] According to an embodiment, resources 140 provided by a cloud infrastructure environment may be divided into multiple tiers, such as a computational resource tier 150 , a network resource tier 160 , and a storage resource tier 170 .

[0042] According to an embodiment, the compute resource tier 150 may include several resources, such as, for example, bare metal instances 152, virtual machines 154, edge services 156, and containers 158. The compute resource tier may be used, for example, to provision and manage bare metal compute instances, provisioning instances as needed to deploy and run applications, similar to an on-premise data center.

[0043] According to an embodiment, a cloud infrastructure environment can provide control of one or more physical host ("bare metal") machines in a compute resource tier. Bare metal compute instances run directly on bare metal servers without a hypervisor. Once a bare metal compute instance is provisioned, the client can maintain sole control of the physical CPU, memory, and network interface cards (NICs). Bare metal compute instances can be configured to utilize the full power of each physical machine as if it were hardware running in their own on-premise data center. Thus, bare metal compute instances are generally not shared between tenants.

[0044] According to certain embodiments, bare metal computing instances can provide a high level of security and performance through associated physical hardware, as opposed to software-based virtual environments.

[0045] According to an embodiment, a cloud infrastructure environment can provide control of a number of virtual machines within a computing resource tier. For example, a virtual machine may be booted from an image that may determine the virtual machine operating system and other software. The type and amount of resources available to a virtual machine instance may be determined based on, for example, the image from which the virtual machine was booted.

[0046] According to an embodiment, a virtual machine (VM) computing instance may include an independent computing environment that runs on top of physical bare metal hardware. Virtualization allows multiple VMs to run that are isolated from each other. VMs can be used, for example, to run applications that do not require the performance and resources (CPU, memory, network bandwidth, storage) of an entire physical machine.

[0047] In some embodiments, virtual machine instances can run on the same hardware as bare metal instances, which can have the effect of using the same cloud-optimized hardware, firmware, software stack, and networking infrastructure.

[0048] According to an embodiment, a cloud infrastructure environment can provide several Graphical Processing Unit (GPU) computing instances in the computing resource layer. Accelerated computing requires consistently fast infrastructure across all services. With GPU instances, clients can more efficiently process and analyze large data sets, making them useful for complex machine learning (ML), artificial intelligence (AI) algorithms, and many industrial HPC applications. GPU computing instances can be provisioned as virtualized computing instances (where multiple GPU computing instances share the same bare metal hardware) or as bare metal instances that provide dedicated hardware for each GPU computing instance.

[0049] According to an embodiment, the cloud infrastructure environment can provide several containerized compute instances in a compute resource layer. A standalone container engine service can be used to build and launch containerized applications in the cloud. The container service can be used, for example, to build, deploy, and manage cloud native applications. The container service can specify the compute resources required by the containerized application, and the container engine, via a provisioning service, can then provision the required compute resources for use in the cloud infrastructure environment (e.g., in the context of a tenancy).

[0050] According to one embodiment, one such container service engine that can be used is Kubernetes, an open source system for automating the deployment, scaling, and management of containerized applications across a cluster of hosts. Such container services can group the containers that make up an application into logical units for easy management and discovery.

[0051] According to an embodiment, the network resource layer 160 may include several resources, such as, for example, a virtual cloud network (VCN) 162, a load balancer 164, an edge service 166, and a connectivity service 168.

[0052] According to one embodiment, the cloud infrastructure environment can provide several virtual cloud networks 162 at the networking resource layer. The virtual cloud networks include virtual versions of traditional networks, including subnets, route tables, and gateways, in which client instances can operate. A cloud network exists within a single region but includes all availability domains of that region. Each subnet defined in a cloud network can either be in a single availability domain or span all availability domains in that region (recommended). At least one cloud network can be configured before launching instances. In an embodiment, a VCN can be configured through an Internet gateway to handle public traffic, VPN connections, or high-speed connection services to securely extend on-premises networks.

[0053] According to an embodiment, the cloud infrastructure environment can provide several load balancers 164 at the networking resource layer. The load balancing service can provide automated traffic distribution from one entry point to multiple servers reachable from a virtual cloud network (VCN). The various load balancers can provide public or private IP addresses and provisioned bandwidth.

[0054] According to an embodiment, the load balancer can help improve resource utilization, scaling, and ensure high availability. Multiple load balancing policies can be configured and application-specific health checks can be provided to ensure that the load balancer directs traffic only to healthy instances. The load balancer can reduce maintenance windows by draining traffic from unhealthy application servers before they are removed from service for maintenance.

[0055] According to an embodiment, the load balancing service allows for the creation of public or private load balancers associated with a VCN. A public load balancer has a public IP address accessible from the Internet. A private load balancer has an IP address from a hosting subnet that is only visible within the VCN. Multiple listeners can be configured to load balance different tiers of traffic (e.g., tier 4 and tier 7 (TCP and HTTP) traffic) for an IP address. Both public and private load balancers can route data traffic to any backend server reachable from the VCN.

[0056] According to an embodiment, a public load balancer can be created that can accept traffic from the Internet and is assigned a public address that serves as an entry point for incoming traffic.

[0057] According to an embodiment, the public load balancer is regional in scope. If the region includes multiple availability domains, the public load balancer can have, for example, a regional subnet or two availability domain-specific (AD-specific) subnets, each in a separate availability domain. In a regional subnet, the load balancer can create a primary load balancer and a standby load balancer, each in a different availability domain, to ensure accessibility even during an availability domain outage. When the load balancer is formed in multiple AD-specific subnets, one subnet can host the primary load balancer and the other subnet can host the standby load balancer. If the primary load balancer fails, the public IP address can switch to the secondary load balancer. The service treats the two load balancers as equivalent.

[0058] According to an embodiment, if a region contains only one availability domain, the service requires only one subnet, whether regional or AD-specific, to host both the primary and standby load balancers. The primary and standby load balancers can each have a private IP address from the host subnet in addition to the floating public IP address assigned to them. If there is an availability domain outage, the load balancers do not have failover.

[0059] According to an embodiment, private load balancing may also be provided to isolate the load balancer from the Internet and simplify the security posture. The load balancer service may assign the load balancer a private address that serves as an entry point for incoming traffic.

[0060] According to an embodiment, a private load balancer can be created by a service to serve only one subnet and host both a primary and a standby load balancer. The load balancer can be regional or AD-specific, depending on the scope of the host subnet. The load balancer is accessible only from within the VCN that contains the host subnet, or as further restricted by security rules.

[0061] According to one embodiment, the assigned floating private IP addresses are local to the host subnet. The primary and standby load balancers each require an additional private IP address from the host subnet.

[0062] According to one embodiment, a private load balancer created in a regional subnet in a multi-AD region provides failover capability when there is an availability domain outage. A private load balancer created in an AD-specific subnet or in a regional subnet in a single availability domain region does not have failover capability in response to an availability domain outage.

[0063] According to an embodiment, the cloud infrastructure environment can provide several edge services 166 at the networking resource layer. Generally, the edge services comprise several services that enable clients to manage, secure, and maintain domains and endpoints. These include, for example, DNS (Domain Name System), DDoS (Distributed Denial of Service) protection, email delivery, etc. These services enable clients to optimize performance, thwart cyber attacks, and scale communications.

[0064] According to an embodiment, the cloud infrastructure environment can provide several connectivity services 168 at the networking resource layer. Such connectivity services can provide an easy way to create dedicated, private connections between client data centers or existing networks and the cloud infrastructure environment. The connectivity services can provide high bandwidth and reliable, consistent networks.

[0065] According to an embodiment, storage resource layer 170 may include several resources, such as, for example, block volume 172 , file storage 174 , object storage 176 , and local storage 178 .

[0066] According to one embodiment, block volumes 172 provide high-performance network storage capacity that supports a wide range of I / O intensive workloads. Clients can use block volumes to extend the storage capacity of their compute instances, provide durable, persistent data storage that can be migrated across compute instances, and host large databases.

[0067] According to one embodiment, file storage 174 enables clients to create scalable, distributed, enterprise-grade network file systems. File storage supports semantics, snapshot capabilities, and encryption at rest.

[0068] According to one embodiment, object storage provides high-throughput storage for unstructured data. Object storage services allow for nearly unlimited storage capacity for large amounts of analytical data or rich content such as images and videos. Block volumes can be backed up to object storage for additional durability.

[0069] According to an embodiment, local storage 178 can provide fast and reliable storage, for example in the form of solid state drives for I / O intensive applications. These can be provided, for example, within bare metal instances. The local storage provides high storage performance for VMs and bare metal compute instances. Some examples include relational databases, data warehouses, big data, analytics, AI, and HPC applications.

[0070] FIG. 2 illustrates a system for providing a cloud infrastructure region within a cloud infrastructure environment according to an embodiment.

[0071] According to an embodiment, instances of the cloud infrastructure environment described above in Figure 1 may be hosted in different regions, referred to as cloud infrastructure regions 220. They may be accessed by customer networks 200 over a network, such as the Internet 210, via a console, SDK, or API, as described above. Each cloud infrastructure region may include management services 222, compute services 224, storage services 226, edge services 228, network services 230, and physical infrastructure 232.

[0072] According to an embodiment, cloud infrastructure can be hosted in regions and availability domains. A region can be a localized geographic area, and an availability domain can be one or more data centers located within a region. A region is composed of one or more availability domains. Most cloud infrastructure resources can be either region-specific, such as a virtual cloud network, or availability domain-specific, such as a compute instance. Traffic between availability domains and between regions is encrypted.

[0073] According to one embodiment, availability domains are isolated from each other, fault tolerant, and highly unlikely to fail simultaneously: Because availability domains do not share infrastructure such as power or cooling, or internal availability domain networks, a failure in one availability domain within a region is unlikely to affect the availability of others in the same region.

[0074] According to one embodiment, availability domains within the same region can be connected to each other by low-latency, high-bandwidth networks, providing highly available connectivity to the Internet and on-premises, and enabling the creation of replicated systems in multiple availability domains for both high availability and disaster recovery.

[0075] According to one embodiment, regions are independent of other regions and can be geographically separated (e.g., across countries or continents), which then leads to the deployment of an application in the region where it is most likely to be used most frequently.

[0076] However, according to an embodiment, applications may also be deployed in different regions for a variety of reasons, including, for example, risk mitigation when an event such as a weather system takes a region offline. In addition, applications may be deployed to other regions for strategic reasons, such as tax domains or other business or social criteria.

[0077] According to one embodiment, there are several services available across the region, including, for example, management services 222, computational services 224, storage services 226, edge services 228, and network services 230.

[0078] According to an embodiment, compartments allow clients to organize and control access to cloud resources. A compartment is a collection of related resources (instances, virtual cloud networks, block volumes, etc.) that can only be accessed by specific groups that have been given permission by an administrator. Compartments can be thought of as logical groupings, rather than physical containers. When working within the console, compartments can act as a filter for what you are allowed to see.

[0079] According to an embodiment, a compartment can have several tiers. For example, a tenancy can be considered the root compartment that holds all of a client's cloud resources. Additional compartments can be created within the root compartment (tenancy) and corresponding policies can be created to control access to resources within each compartment. When a client creates a cloud resource, such as an instance, block volume, or cloud network, such resource can be targeted to a specific compartment or compartments. Compartments can span regions.

[0080] Fault Domain According to an embodiment, a fault domain can include a grouping of hardware and infrastructure within an availability domain. Each availability domain can include three fault domains. Fault domains allow instances to be distributed such that they are not on the same physical hardware within a single availability domain. A hardware failure or compute hardware maintenance that affects one fault domain does not affect instances in other fault domains.

[0081] According to an embodiment, placement of a resource, such as a compute, bare metal DB system, or virtual machine DB system instance, can optionally specify a failure domain or a new instance at launch time. After placement, the resource can be reclaimed by terminating the resource in its current failure domain and launching a new instance of the resource in a different failure domain. By doing so, the failure domain can be incrementally changed.

[0082] According to an embodiment, fault domains can be utilized for a number of reasons, such as protection from unexpected hardware failures and protection from planned outages due to maintenance.

[0083] availability According to an embodiment, service availability can be provided. Regions within a cloud infrastructure environment can provide core infrastructure services and resources, including: Compute: Compute (bare metal and VM, DenseIO and Standard), for Kubernetes Container engines, registries... Storage: Block volumes, file storage, object storage, archive storage Networking: Virtual cloud network, load balancing, high speed connection Database: Database, Exadata cloud services, autonomous data warehouse, Autonomous Transactions ·process Edge: DNS Platform: Identity and access management, tagging, auditing According to an embodiment, the above services and resources may be generally available, but other services and resources may be additionally available (e.g., based on regional demand or customer request). By way of example, new cloud services may be made available as quickly as possible in a region based on various considerations, including regional customer demand, the ability to achieve regulatory compliance where applicable, resource availability, and other factors. Because of the low-latency interconnection backbone, customers can use cloud services with efficient results in other geographic regions when they are not available in their home region, provided that data residency requirements do not prevent them from doing so.

[0084] According to an embodiment, resource availability can be considered in the context of global availability, regional availability, single region availability, and domain availability. Generally, IAM resources are globally available, while DB systems, instances, and volumes are specific to a viability domain. Most other resources are regional.

[0085] According to an embodiment, examples of globally available resources may include API signing keys, compartments, dynamic groups, federated resources, groups, policies, tag namespaces, tag keys, and users.

[0086] According to one embodiment, examples of regionally available resources include alarms, applications, buckets (buckets are regional resources, but buckets can be accessed from any location with the correct region-specific object storage URL for the API call), clusters, cloud event rules, customer premises equipment (CPE), DHCP option sets, dynamic routing gateways (DRGs), encryption keys, functions, images, internet gateways, jobs, key vaults, load balancers, local peering gateways (LPGs), metrics, NAT gateways, network security groups, node pools, ons-subscriptions, ons-topics. , Repositories, Reserved Public IPs, Route Tables, Security Lists, Service Gateways, Stacks, Subnets (when a subnet is created, it can be declared specific to a regional or availability domain), Virtual Cloud Networks ( VCN), and volume backups (volume backups can be restored as new volumes to any availability domain within the same region in which they are stored).

[0087] According to an embodiment, examples of availability domain-specific resources may include DB systems, ephemeral public IPs, instances (an instance can be attached to a volume in the same availability domain), subnets (when a subnet is created, it can be declared as regional or availability domain specific), and volumes (a volume can be attached to an instance in the same availability domain).

[0088] compartment According to one embodiment, an administrator can manage compartments within a cloud infrastructure environment.

[0089] According to an embodiment, tags can be applied to resources within a compartment. Tags can be used to organize resources according to a schema, such as a business needs schema. Tags can be applied to resources when they are created, or tags can be updated on existing resources.

[0090] According to an embodiment, compartments are important for building and organizing a cloud infrastructure. Resources can be moved between compartments, viewed (e.g., via a user interface), and organized by compartment within the current region. When working with and managing resources, a compartment can be selected first.

[0091] According to one embodiment, compartments are tenancy-wide and can span regions: when a compartment is created, it can be made available in any region to which the tenancy is subscribed.

[0092] According to an embodiment, a compartment can be deleted: To delete a compartment, the compartment can have all resources therein removed prior to deletion.

[0093] According to one embodiment, the action of deleting a compartment can be asynchronous and initiates a work request. The compartment's state changes to "deleting" while the work request is running. If the work request fails, the compartment is not deleted and returns to the active state.

[0094] According to an embodiment, each compartment created in the cloud infrastructure environment can have certain properties. For example, each compartment can be assigned a unique identifier (ID) and, optionally, can be provided with a configurable description and name. According to an embodiment, subcompartments can be hierarchically defined under a base compartment.

[0095] According to an embodiment, access to and control over compartments and subcompartments can be limited to administrators or other users with sufficient credentials. Credentials can be associated with different levels of compartment access. For example, an administrator may have permission to view and access all compartments and to work with resources in any compartment of the tenancy, while a user with more limited access may not have such a level of access. It has no power or control.

[0096] FIG. 3 illustrates a system for providing compartment policies within compartments across cloud infrastructure regions in a cloud infrastructure environment according to an embodiment.

[0097] According to an embodiment, as discussed above, instances of cloud infrastructure environment 300 as discussed above in Figure 1 may be hosted in different regions, such as cloud infrastructure regions 320, 330, 340, 350. They may be accessed by customer network 301 over network 302, such as the Internet, via consoles, SDKs, or APIs, as discussed above.

[0098] According to an embodiment, customer network 301 may include, for example, a single computer, a network of customer computers, or other such networks.

[0099] According to one embodiment, although not shown in the figure, each cloud infrastructure region may include several services, each of which includes several resources such as management services, computational services, storage services, edge services, network services, and physical infrastructure.

[0100] According to an embodiment, cloud infrastructure can be hosted in regions and availability domains. A region can be a localized geographic area, and an availability domain can be one or more data centers located within a region. A region is composed of one or more availability domains. Most cloud infrastructure resources can be either region-specific, such as a virtual cloud network, or availability domain-specific, such as a compute instance. Traffic between availability domains and between regions is encrypted.

[0101] According to one embodiment, availability domains are isolated from each other, fault tolerant, and highly unlikely to fail simultaneously: Because availability domains do not share infrastructure such as power or cooling, or internal availability domain networks, a failure in one availability domain within a region is unlikely to affect the availability of others in the same region.

[0102] According to one embodiment, availability domains within the same region can be connected to each other by low-latency, high-bandwidth networks, providing highly available connectivity to the Internet and on-premises, and enabling the creation of replicated systems in multiple availability domains for both high availability and disaster recovery.

[0103] According to one embodiment, regions are independent of other regions and can be geographically separated (e.g., across countries or continents), which then leads to the deployment of an application in the region where it is most likely to be used most frequently.

[0104] However, according to an embodiment, applications may also be deployed in different regions for a variety of reasons, including, for example, risk mitigation when an event such as a weather system takes a region offline. In addition, applications may be deployed to other regions for strategic reasons, such as tax domains or other business or social criteria.

[0105] According to one embodiment, there are several services available across a region, including, for example, management services, compute services, storage services, edge services, and network services.

[0106] According to an embodiment, compartments allow clients to organize and control access to cloud resources. A compartment is a collection of related resources (instances, virtual cloud networks, block volumes, etc.) that can only be accessed by specific groups that have been given permission by an administrator. Compartments can be thought of as logical groupings, rather than physical containers. When working within the console, compartments can act as a filter for what you are allowed to see.

[0107] According to an embodiment, compartments can have several tiers. For example, tenancy 305 can be considered the root compartment that holds all of a client's cloud resources. Compartments can be organized in a hierarchical manner, such that compartment 360 is a level below the tenancy compartment, and subcompartment 370 is an additional tier below compartment 360. According to an embodiment, each compartment can be associated with one or more compartment policies, such as compartment policy 365 and subcompartment policy 375. Tenant compartment policies are not shown in the figure.

[0108] According to an embodiment, during, during, or after the creation of a compartment or subcompartment, e.g., compartment 360 and subcompartment 370, policies, such as compartment policy 365 and subcompartment policy 375, can be written / created for each compartment and subcompartment. Compartment policies can, for example, restrict which users are permitted to access / utilize resources and services within the compartment. Without policies in place, access to the compartment and / or subcompartment can be restricted to users with authorization at the tenancy 305 level.

[0109] According to one embodiment, upon creation of a compartment within a compartment (ie, a subcompartment), the subcompartment inherits access permissions from the compartment above it in the hierarchy.

[0110] According to an embodiment, when a compartment or subcompartment policy is created, the policy may include a specification that indicates which compartment it is attached to. Such a specification may include controls that limit access for subsequence control, modification, or deletion of the policy. In some embodiments, a policy may be attached to the tenancy, a parent compartment, or the specific compartment to which the policy is directed.

[0111] According to an embodiment, resources can be placed into a compartment. This can be accomplished by specifying the targeted compartment when creating a resource (the compartment is one of the pieces of information required to create a resource). This can be accomplished via the console interface.

[0112] According to an embodiment, existing resources can also be moved to a different compartment. Most resources can be moved after they are created.

[0113] According to one embodiment, some resources have resource dependencies attached. , some have no attached resource dependencies. Not all attached dependencies behave the same when a parent resource moves.

[0114] According to one embodiment, for some resources, attached dependencies are moved to the new compartment along with the parent resource: the parent resource moves immediately, but in some cases, the attached dependencies move asynchronously and are not visible in the new compartment until the move is complete.

[0115] According to one embodiment, for other resources, attached resource dependencies are not moved to the new compartment: such attached resources may be moved independently.

[0116] According to one embodiment, after a resource is moved to a new compartment, the policies governing the new compartment are immediately applied and affect access to the resource. Depending on the compartment organization structure, metering, billing, and alerting may also be affected.

[0117] According to an embodiment, after creation, a compartment can be moved, for example to a different parent compartment within the same tenancy. When a compartment is moved, all of the compartment's contents (including subcompartments and resources) move with it.

[0118] FIG. 4 illustrates a system for compartment migration within a cloud infrastructure environment according to an embodiment.

[0119] According to an embodiment, as described above, instances of cloud infrastructure environment 400 as described above in FIG. 1 may be hosted in different regions. Compartments, such as tenancy 405, compartment A 460, and compartment B 470, may be defined within the cloud infrastructure environment, and these compartments may span regions. Such compartments may be accessed by customer network 401 over network 402, such as the Internet, via a console, SDK, or API, as described above.

[0120] According to an embodiment, customer network 401 may include, for example, a single computer, a network of customer computers, or other such networks.

[0121] According to an embodiment, compartments allow clients to organize and control access to cloud resources. A compartment is a collection of related resources (instances, virtual cloud networks, block volumes, etc.) that can only be accessed by specific groups that have been given permission by an administrator. Compartments can be thought of as logical groupings, rather than physical containers. When working within the console, compartments can act as a filter for what you are allowed to see.

[0122] According to an embodiment, compartments can have several tiers. For example, tenancy 405 can be considered the root compartment that holds all of a client's cloud resources. Compartments can be organized in a hierarchical fashion such that compartment A 460 and compartment B 470 are levels below the tenancy compartment, subcompartment A 465 is defined below compartment A, and subcompartment B 475 is defined below compartment B. According to one embodiment, each compartment can be associated with one or more compartment policies (not shown).

[0123] According to an embodiment, for example, a compartment defined within a tenancy may be moved, for example, by redefining the compartment or a subcompartment.

[0124] According to one embodiment, a request with sufficient permissions to move a compartment can be received, i.e., from a user belonging to a group that has "all resource management" permissions for the current compartment and the lowest tier shared parent compartment for the destination compartment of the moved compartment.

[0125] That is, for example, a request to move subcompartment A 465 from compartment A 460 to compartment B 470 (moving 465 to 476) must be received with sufficient permissions from a user. Because tenancy 405 is the lowest-level shared parent compartment of both the source compartment, compartment A 460, and the destination compartment, compartment B 470, as shown in the figure, the request to move subcompartment A must be received from a user with "manage all resources" permission in the compartments of tenancy 405.

[0126] In another example, according to an embodiment, if a request to move subcompartment A465 from compartment A to compartment B is received from a user who only has permission to “manage all resources” in compartment A, the request may fail because the request from the user cannot manage resources in the destination compartment, i.e., compartment B.

[0127] According to an embodiment, when a compartment is moved to a new parent compartment, the access policies of the new parent compartment take effect and the policies of the previous parent compartment no longer apply. In some cases, when moving nested compartments with policies that specify a hierarchy, those policies may be automatically updated to ensure consistency.

[0128] Thus, according to one embodiment, the compartment policy of compartment A 460 that was previously applied to subcompartment A will no longer apply to the movement of subcompartment A to compartment B. The compartment policy of compartment B will then be applied to subcompartment A instead. This is further explained in the following figure.

[0129] FIG. 5 illustrates a system for policy management and enforcement during compartment movement within a cloud infrastructure environment.

[0130] More specifically, FIG. 5 illustrates a compartment hierarchy through which compartments may be moved and the consequences for different policies, according to one embodiment.

[0131] According to an embodiment, as noted above, instances of cloud infrastructure environment 500 as described above in Figure 1 may be hosted in different regions. Compartments such as tenancy 505, compartment A 560 and compartment B 565, and compartment D 566 may be defined within the cloud infrastructure environment, and these compartments may span regions. Such compartments can be accessed by a customer network 501 over a network 502, such as the Internet, via a console, SDK, or API, as described above.

[0132] According to an embodiment, customer network 501 may include, for example, a single computer, a network of customer computers, or other such networks.

[0133] According to an embodiment, compartments can have several tiers. For example, tenancy 505 can be considered the root compartment that holds all of a client's cloud resources. Compartments can be organized hierarchically such that compartment A 560 is a level below the tenancy. Compartment B 565 and compartment D 566 are then organized as yet another level below compartment A 560, while compartment C 570 is initially shown as a level below compartment B. According to an embodiment, each compartment can be associated with one or more compartment policies, such as compartment B policy 582, compartment A policy 580, and compartment D policy 583. Such policies can, for example, govern user / client permissions for access to the compartment, as well as permissions for access to and control of resources within any given compartment. As described above, compartment policies can be added to one another (i.e., “stacked”) such that a user accessing compartment B 565 has their interaction with compartment B 565 governed / restricted by compartment B policy 582 in addition to compartment A policy 580.

[0134] According to one embodiment, assume, for example, that compartment B policy 582 allows a group, group 1, to manage an instance family in compartment AB (the compartment hierarchy includes compartment B, which is a subcompartment of compartment A).

[0135] According to one embodiment, assume that compartment D policy 583 also allows another group, group 2, to manage instance families within compartment AD (the compartment hierarchy includes compartment D, which is a subcompartment of compartment A).

[0136] According to one embodiment, when compartment C is moved from compartment B to compartment D, members of group 1 can no longer manage the instance families in compartment C, and members of group 2 can now manage the instance families in compartment C.

[0137] According to certain embodiments, in certain circumstances, moving a compartment can automatically update certain policies. For example, policies that specify the compartment hierarchy up to the compartment being moved can be automatically updated when policies are attached to a shared ancestor of the current target parent.

[0138] Referring again to Figure 5, for example, according to one embodiment, assume that compartment A policy allows members of a group, group X, to manage buckets in compartment B:C. If compartment C is moved to compartment D, because of the shared ancestor between compartment B and compartment D (compartment A), compartment A policy may be automatically updated to allow members of group X to manage buckets in compartment D:C.

[0139] According to an embodiment, policies attached to a tenancy can also be automatically updated when a compartment is moved within the tenancy.

[0140] However, according to an embodiment, moving a compartment does not automatically update all policies. For example, referring to FIG. 5, in a situation where compartment C is moved from compartment B to compartment D, assume that compartment B policy allows management of buckets in compartment C (prior to the move). When compartment C is moved, compartment B policy is not automatically updated. Instead, the policy is no longer valid and may be removed (e.g., manually or automatically).

[0141] According to an embodiment, cloud administrators generally do not have the ability to limit resource usage in existing clouds. Giving a user permission to create resources allows the user to create any number of resources up to a predefined account limit. Compartment quotas allow for imposing restrictions on the ability to create or use resources within a compartment to an appropriate level that allows fine-tuned cost control.

[0142] According to an embodiment, customers can be assigned service level limits defined by the cloud infrastructure environment upon account creation. These service level limits limit the total number of resources a customer can create across the tenancy (e.g., across multiple regions with multiple compartments). Tenancy and compartment administrators can utilize compartment quotas to set resource-specific hard limits. Without such compartment limits, users authorized to launch instances may consume all available capacity in the entire tenancy. Compartment resource limits solve this problem and are distinct from service limits and are set and customized by clients and customers, e.g., via the console, SDK, or API. Compartment limits are applied on top of service limits and can be inherited through nested compartment hierarchies. This allows compartment administrators to limit resource consumption and set boundaries around acceptable resource usage.

[0143] According to an embodiment, compartment quotas give tenant and compartment administrators better control over how resources are consumed in a cloud infrastructure environment and allow administrators to easily allocate resources to compartments, for example, using the console, SDK, or API. Compartment quotas are a powerful toolset for managing client spending within a tenant.

[0144] FIG. 6 illustrates a system for supporting compartment allocation in a cloud infrastructure environment, according to one embodiment.

[0145] According to an embodiment, as discussed above, instances of cloud infrastructure environment 600 as discussed above in Figure 1 may be hosted in different regions, such as cloud infrastructure regions 620, 660, 640, 650, which may be accessed by a customer network 601 over a network 602, such as the Internet, via a console 603, SDK, or API, as discussed above.

[0146] According to an embodiment, customer network 601 may include, for example, a single computer, a network of customer computers, or other such networks.

[0147] According to one embodiment, although not shown in the figure, each cloud infrastructure region may include several services, each of which includes several resources such as management services, computational services, storage services, edge services, network services, and physical infrastructure.

[0148] According to an embodiment, cloud infrastructure can be hosted in regions and availability domains. A region can be a localized geographic area, and an availability domain can be one or more data centers located within a region. A region is composed of one or more availability domains. Most cloud infrastructure resources can be either region-specific, such as a virtual cloud network, or availability domain-specific, such as a compute instance. Traffic between availability domains and between regions is encrypted.

[0149] According to one embodiment, availability domains are isolated from each other, fault tolerant, and highly unlikely to fail simultaneously: Because availability domains do not share infrastructure such as power or cooling, or internal availability domain networks, a failure in one availability domain within a region is unlikely to affect the availability of others in the same region.

[0150] According to one embodiment, availability domains within the same region can be connected to each other by low-latency, high-bandwidth networks, providing highly available connectivity to the Internet and on-premises, and enabling the creation of replicated systems in multiple availability domains for both high availability and disaster recovery.

[0151] According to one embodiment, regions are independent of other regions and can be geographically separated (e.g., across countries or continents), which then leads to the deployment of an application in the region where it is most likely to be used most frequently.

[0152] However, according to an embodiment, applications may also be deployed in different regions for a variety of reasons, including, for example, risk mitigation when an event such as a weather system takes a region offline. In addition, applications may be deployed to other regions for strategic reasons, such as tax domains or other business or social criteria.

[0153] According to an embodiment, compartments allow clients to organize and control access to cloud resources. A compartment is a collection of related resources (instances, virtual cloud networks, block volumes, etc.) that can only be accessed by specific groups that have been given permission by an administrator. Compartments can be thought of as logical groupings, rather than physical containers. When working within the console, compartments can act as a filter for what you are allowed to see.

[0154] According to an embodiment, compartments may have several tiers or levels arranged hierarchically. For example, tenancy 605 may be considered the root compartment that holds all of a client's cloud resources. Compartments may be sub-compartments, with compartment 660 being a level below the tenancy compartment. The compartments 670 may be organized in a hierarchical manner, such that compartments 670 are an additional tier below compartments 660. According to an embodiment, each compartment may be associated with one or more compartment resource quotas, such as tenancy resource quotas 680 (i.e., the service limits discussed above), compartment resource quotas 682, and subcompartment resource quotas 684.

[0155] According to one embodiment, during, during, or after creation of a compartment or subcompartment, such as compartment 660 and subcompartment 670, each corresponding compartment resource allocation can be generated, for example, via console 603.

[0156] According to one embodiment, the hierarchical nature of compartments allows compartment resource quotas set on the root / base level compartment. An administrator (with sufficient access level to manage and create resource quotas in the root compartment) can set quotas on the root compartment and any nested or "child" compartments. Compartment resource quotas set on a parent / root compartment override compartment resource quotas set on a child compartment. In this way, an administrator of a parent compartment can create quotas on a child compartment that cannot be overridden by the child.

[0157] According to an embodiment, quotas have different scopes and can work on availability domains, regions, or globally. There are some important things to understand about scope when working with compartment quotas. When setting a quota at the availability domain (AD) level, the quota is assigned to each AD. So, for example, setting a quota of 2 x 7 VMs on a compartment actually sets a limit of 2 VMs per AD. Quotas can be written in such a way that they target a specific AD. Similarly, regional quotas can be applied to each region. For example, if a quota of 10 features is set on a compartment, then 10 features will be assigned per region. To target a specific region, the quota can use the region parameter.

[0158] According to an embodiment, due to the hierarchical nature of compartment allocation, usage (e.g., of resources), subcompartment resource usage counts towards the main compartment, i.e., in a three-level compartment nest (parent compartment, child compartment, grandchild compartment), if each compartment and subcompartment has a compartment allocation policy attached, resource usage by the grandchild compartment counts towards the compartment allocation of both the child compartment and the parent compartment.

[0159] For example, assume compartment resource allocation 682 specifies, compartment-wide, that compartment 660 can only utilize 10 virtual machines of type X. Upon creation of subcompartment 670, subcompartment resource allocation 684 specifies, subcompartment-wide, that subcompartment 670 can only utilize 8 virtual machines of type X. Then, if subcompartment 670 utilizes its maximum capacity of virtual machines of type X (i.e., 8), compartment 660 and any other subcompartments thereof (e.g., subcompartments not shown in the figure) can only utilize an additional 2 virtual machines of type X. The above example additionally applies to tenancy resource allocation 680 (i.e., service limits) as well.

[0160] According to an embodiment, compartment quotas may be evaluated according to these guidelines. Within a policy, quota statements may be evaluated in order, with later statements superseding earlier statements targeting the same resource. When multiple policies are configured for the same resource, the most restrictive policy may apply. Service limits always take precedence over quotas. It is possible to specify a quota for a resource that exceeds the service limit for that resource, but the service limit will still be enforced.

[0161] FIG. 7 illustrates a system for supporting compartment allocation in a cloud infrastructure environment, according to one embodiment.

[0162] More specifically, FIG. 7 illustrates replication of compartment assignments to different regions after creation / modification / deletion of compartment assignments within a region.

[0163] According to an embodiment, as discussed above, instances of cloud infrastructure environment 700 as discussed above in Figure 1 may be hosted in different regions, such as cloud infrastructure regions 720, 730, 740, 750. They may be accessed by a customer network 701 over a network 702, such as the Internet, via a console 703, SDK, or API, as discussed above.

[0164] According to an embodiment, customer network 701 may include, for example, a single computer, a network of customer computers, or other such networks.

[0165] According to one embodiment, although not shown in the figure, each cloud infrastructure region may include several services, each of which includes several resources such as management services, computational services, storage services, edge services, network services, and physical infrastructure.

[0166] According to an embodiment, cloud infrastructure can be hosted in regions and availability domains. A region can be a localized geographic area, and an availability domain can be one or more data centers located within a region. A region is composed of one or more availability domains. Most cloud infrastructure resources can be either region-specific, such as a virtual cloud network, or availability domain-specific, such as a compute instance. Traffic between availability domains and between regions is encrypted.

[0167] According to one embodiment, availability domains are isolated from each other, fault tolerant, and highly unlikely to fail simultaneously: Because availability domains do not share infrastructure such as power or cooling, or internal availability domain networks, a failure in one availability domain within a region is unlikely to affect the availability of others in the same region.

[0168] According to one embodiment, availability domains within the same region can be connected to each other by low-latency, high-bandwidth networks, providing highly available connectivity to the Internet and on-premises, and enabling the creation of replicated systems in multiple availability domains for both high availability and disaster recovery.

[0169] According to one embodiment, a region is independent of other regions and may be geographically (e.g. For example, across countries or continents, the applications can be separated into regions. This then leads to the deployment of an application in the region where it is most likely to be used most heavily.

[0170] However, according to an embodiment, applications may also be deployed in different regions for a variety of reasons, including, for example, risk mitigation when an event such as a weather system takes a region offline. In addition, applications may be deployed to other regions for strategic reasons, such as tax domains or other business or social criteria.

[0171] According to an embodiment, compartments allow clients to organize and control access to cloud resources. A compartment is a collection of related resources (instances, virtual cloud networks, block volumes, etc.) that can only be accessed by specific groups that have been given permission by an administrator. Compartments can be thought of as logical groupings, rather than physical containers. When working within the console, compartments can act as a filter for what you are allowed to see.

[0172] According to an embodiment, compartments can have several tiers or levels arranged hierarchically. For example, tenancy 705 can be considered the root compartment that holds all of a client's cloud resources. Compartments can be organized in a hierarchical manner such that compartments 760 are a level below the tenancy compartment and subcompartments 770 are additional tiers below compartments 760. According to an embodiment, each compartment can be associated with one or more compartment resource quotas, such as tenancy resource quota 780 (i.e., service limits as discussed above), compartment resource quota 782, and subcompartment resource quota 784.

[0173] According to one embodiment, during, during, or after creation of a compartment or subcompartment, such as compartment 760 and subcompartment 770, each corresponding compartment resource allocation can be generated, for example, via console 703.

[0174] According to one embodiment, the hierarchical nature of compartments allows compartment resource quotas set on the root / base level compartment. An administrator (with sufficient access level to manage and create resource quotas in the root compartment) can set quotas on the root compartment and any nested or "child" compartments. Compartment resource quotas set on a parent / root compartment override compartment resource quotas set on a child compartment. In this way, an administrator of a parent compartment can create quotas on a child compartment that cannot be overridden by the child.

[0175] According to certain embodiments, quotas have different scopes and can work at an availability domain, region, or globally. There are some important things to understand about scope when working with compartment quotas: When setting a quota at the availability domain (AD) level, the quota is assigned to each AD. So, for example, setting a quota of 2 x 7 VMs on a compartment actually sets a limit of 2 VMs per AD. Quotas can be written in such a way that they target a specific AD. Similarly, regional quotas can be applied to each region. For example, if a compartment has a quota of 10 features, then there will be an allocation of 10 features per region. To target specific regions, the quota can use the region parameter.

[0176] According to an embodiment, due to the hierarchical nature of compartment allocation, usage (e.g., of resources), subcompartment resource usage counts towards the main compartment, i.e., in a three-level compartment nest (parent compartment, child compartment, grandchild compartment), if each compartment and subcompartment has a compartment allocation policy attached, resource usage by the grandchild compartment counts towards the compartment allocation of both the child compartment and the parent compartment.

[0177] According to an embodiment, allocations can be managed centrally in a single region and replicated globally. This reduces the effort required to manage allocations. For example, looking at FIG. 7, subcompartment resource allocation policies 784 and compartment resource allocations 782 can first be defined in region 720. Once created, each of resource allocations 782 and 784 can be replicated to regions 730, 740, and 750. Such replication can be an asynchronous process that replicates the allocation policies globally to the allocation data plane in each data center.

[0178] According to an embodiment, compartment quota provides the ability to turn off individual services completely. Similarly, algorithms are provided for calculating resource usage across a hierarchy of resource compartments. Quota can consist of several main components: Quota User Interface, Quota Control Plane, Quota Data Plane, and Quota Client SDK.

[0179] According to one embodiment, administrators can manage compartment allocation policies through a user interface that invokes the allocation control plane where, behind the scenes, the policies are stored. An asynchronous process replicates the data globally to the allocation data plane in each data center. Other cloud services integrate with client SDKs that can fetch usage data from the service's persistent storage layer and quota values ​​from the quota data plane. A decision is then made to allow or deny the creation of a resource.

[0180] According to an embodiment, there are several conditions that can be set to initiate compartment allocation. These include, but are not limited to: create / update / delete / list compartment level resource allocations; view compartment resource usage; compartment allocations can be set globally to apply to all regions / ADs; region / AD specific compartment allocations can be set and override globally defined allocations; compartment allocations can correspond to existing service allocations, where applicable; setting and viewing compartment allocations can be possible through the console; allocations can be strictly enforced by each respective control plane; setting quotas should not fail based on current resource counts or parent compartment values; integrate with core services compute, DBaaS (database as a service) and block storage; achieve strong read-after-write consistency for get / list operations; ability to enforce zero quotas for teams that cannot be onboarded at no cost; declarative quota statements via policies; and act as either a whitelist or blacklist (i.e., no quotas set by the quotas). Define compartment assignments (deny or allow all that are not allowed).

[0181] According to an embodiment, the control plane can be extended to support compartment resource restrictions.

[0182] FIG. 8 is a flowchart of a method for creating compartment assignments according to one embodiment.

[0183] According to one embodiment, when the console 800 receives an instruction indicating a user of a tenant interaction to create a compartment assignment, the console can call the restriction control plane 805 (e.g., in the tenant's home region) via an API to create the compartment assignment.

[0184] According to an embodiment, the call may include a compartment ID to which the compartment assignment is directed.

[0185] According to an embodiment, the restriction control plane 805 can communicate with the identity data plane 810 (e.g., in the tenant's home region). The communication can include a compartment ID for the target compartment, and the restriction control plane can request the tenant associated with the targeted compartment. The identity control plane can return the tenant.

[0186] According to one embodiment, upon receiving a tenant, the restriction control plane can check whether the request to create a compartment assignment is sufficiently authorized (e.g., the tenant's user has sufficient permissions to instantiate such a compartment assignment on the targeted compartment). The restriction control plane can do this by again communicating with the identity control plane.

[0187] According to an embodiment, upon determining that the request is approved, the constraints control plane can create an assignment entity in database 815 (e.g., Kiev) (e.g., in the tenant's home region) and can then return successful creation of the compartment assignment to the console.

[0188] According to an embodiment, database 815 can be configured to store, and can store, all quotas associated with a tenant (or multiple tenants), i.e., for example, both service level limits (which apply to the entire tenancy) and each of multiple compartment level quotas can be stored in one database (e.g., Kiev), with the complete limits owned by one tenant.

[0189] FIG. 9 is a flowchart of a method for modifying compartment assignments, according to one embodiment.

[0190] According to one embodiment, when the console 900 receives an instruction indicating a tenant-interactive user to retrieve, update, or delete a compartment assignment, the console 900 can call the database 915 to retrieve the requested targeted compartment assignment via the assignment ID included in the request.

[0191] According to one embodiment, the call is made to the allocation object to which the get / update / delete allocation operation is directed. It may include an assignment ID.

[0192] According to an embodiment, the restriction control plane 905 can communicate with the identity data plane 910 (e.g., in the tenant's home region). The communication can include a compartment ID for the target compartment, and the restriction control plane can request the tenant associated with the targeted compartment. The identity control plane can return the tenant.

[0193] According to one embodiment, upon receiving a tenant, the restriction control plane can check whether the request to create a compartment assignment is sufficiently authorized (e.g., the tenant's user has sufficient permissions to instantiate such a compartment assignment on the targeted compartment). The restriction control plane can do this by again communicating with the identity control plane.

[0194] According to an embodiment, upon determining that the request is approved, the constraints control plane can retrieve / update / delete the compartment assignment in database 915 (e.g., Kiev) (e.g., in the tenant's home region). Successful creation of the compartment assignment can then be returned to the console.

[0195] According to an embodiment, database 815 can be configured to store, and can store, all quotas associated with a tenant (or multiple tenants), i.e., for example, both service level limits (which apply to the entire tenancy) and each of multiple compartment level quotas can be stored in one database (e.g., Kiev), with the complete limits owned by one tenant.

[0196] FIG. 10 illustrates an architecture for a system for enforcing compartment allocation in a cloud infrastructure environment, according to one embodiment.

[0197] According to one embodiment, FIG. 10 illustrates an architecture flow for a user launching an instance that requires checking against one or more compartment resource quotas.

[0198] According to one embodiment, in step 1, an instruction may be received, for example, from a user 1001. The instruction may indicate a request to launch an instance within a region 1000, where the request specifies a compartment within the region.

[0199] According to one embodiment, in step 2, a load balancer 1020 (eg, Flamingo) can forward the request to an API, such as a public API proxy.

[0200] According to an embodiment, in step 3, the API can perform authentication in the identity data plane 1035. Such an authentication step can check both that the user has the correct credentials (e.g., user credentials such as username and password, one-time password, or other authentication method) and that user 1001 has sufficient authorization in the region to perform the requested launch of an instance in the targeted compartment. For example, if user 1001 does not have sufficient authorization to launch an instance in the targeted compartment (e.g., user 1001 only has authorization to launch a similar instance in a child compartment of the targeted compartment), then the API can check whether the user has the correct credentials (e.g., user credentials such as username and password, one-time password, or other authentication method) and whether user 1001 has sufficient authorization in the region to perform the requested launch of an instance in the targeted compartment. , the API 1025 can reject the request. If the user has sufficient authorization, the API can allow the request to proceed.

[0201] According to one embodiment, in step 4, the request to launch the instance may be forwarded to a Computation Control Plane (CCP) 1030. The CCP may then, in step 5, further authenticate the request in the Identity Data Plane.

[0202] According to an embodiment, in step 6, the compute control plane can call the identity data plane 1035 to fetch the compartment tree associated with the compartment to which the request is directed, or the compartment tree for the entire tenancy to which the request is directed.

[0203] According to one embodiment, in step 7, the compute control plane can fetch all compartment assignments for a tenancy or compartment tree from the restricted services data plane 1040, which contains a compartment assignment map 1041. This can include a certain number of compartment assignments for the particular compartment to which the request is directed, as well as compartment assignments for the entire tree above that particular compartment.

[0204] According to an embodiment, in step 8, the compute control plane can retrieve the resource usage for the compartment from database 1045 and can check whether the requested usage violates any of the compartment assignments for any compartments along the tree including the particular compartment to which the request is directed. If the requested usage does not violate any compartment assignments, the request can be processed. If the requested usage violates any of the compartment assignments along the compartment tree, the request can be dropped and a message can be sent to inform the user.

[0205] According to an embodiment, the compartment quota applies to a specific compartment within a tenancy. Once the compartment tree is fetched with all associated compartment quotas, the CCP can get the usage and update the usage based on the request. From the database, as part of step 8, the CCP can get the actual usage in each compartment. For the entire compartment tenancy, the CCP can map each compartment ID to a certain number of counts (usage). The CCP can then map the entire compartment tree layout and the quotas that exist. The CCP can then ensure that a new request does not violate any of the quotas. If the request exceeds the quota, the CCP can drop the request.

[0206] FIG. 11 is a flowchart of a method for supporting compartment allocation in a cloud infrastructure environment, according to one embodiment.

[0207] According to one embodiment, in step 1110, the method may provide a computer including one or more microprocessors.

[0208] According to an embodiment, in step 1120, the method can provide a cloud infrastructure environment in a computer, the cloud infrastructure environment including a plurality of regions, and within the plurality of regions a tenancy is defined.

[0209] According to an embodiment, in step 1130, the method may provide multiple compartments for the tenancy.

[0210] According to an embodiment, in step 1140, the method can provide, within the cloud infrastructure environment, a restricted service data plane having access to a database that stores multiple compartment resource allocations.

[0211] In one embodiment, in step 1150, the method can include associating a compartment resource allocation among a plurality of compartment resource allocations with a compartment among a plurality of compartments, the compartment resource allocation limiting at least one type of resource within the compartment.

[0212] According to an embodiment, in step 1160, the method can receive a request for a resource to be provisioned in a compartment, the requested resource being of a type restricted by the resource allocation.

[0213] According to an embodiment, in step 1170, the method may determine whether provisioning of the requested resource would violate a compartment resource allocation.

[0214] According to an embodiment, in step 1180, the method may provision the requested resources based on a determination that no compartment resource allocations are violated.

[0215] According to one embodiment, in step 1190, the method can challenge the request based on a determination that a compartment resource allocation is violated.

[0216] Quota Policy Language According to an embodiment, as described above, the cloud infrastructure environment can provide the ability for customers to set resource quotas on compartments. The quotas work like existing service limits, except they are set by the customer, not by the cloud infrastructure environment, to limit the customer's own usage. Service teams can check these quotas in their control plane and hard block requests that exceed the quota. Quotas can be stored and accessed from the limits service, and set by clients via the console or REST API. Additionally, the cloud infrastructure environment can support a declarative, human-readable quota policy language that is used to create such compartment quotas.

[0217] According to an embodiment, compartment resource quotas can be configured similarly to writing identity policies, for example: both live within a compartment and can be written to target different compartments. Resource quotas can also be associated with a set of conditions that can be applied, such as regions, availability domains, and overlaps.

[0218] According to an embodiment, resource allocations can be configured by setting statement syntax. To set an allocation, the allocation can establish several elements. Each allocation can be unique within a service family (e.g., compute), and therefore each allocation can define a target service along with an allocation name. The allocation then defines the value to which the allocation is set, and the target service for which the allocation is to be used. Finally, there is a set of conditions that can be included that determine when this allocation applies.

[0219] According to an embodiment, compartment allocation policies can be written using an expressive, human-readable policy language. The policy language allows for rich expressivity, including the ability to both whitelist or blacklist resource usage through statement overrides. A whitelist allows all resources to be created except for those that are explicitly denied. A blacklist does not allow resources to be created except for those that are explicitly allowed.

[0220] According to one embodiment, compartment quotas can be set using policy statements written in a simple declarative language. In general, there are three types of quota policy statements: 1) set - sets the maximum number of cloud resources that can be used for a compartment; 2) not set - resets the quota back to the default service limits; 3) zero - removes access to cloud resources for a compartment.

[0221] 12a, 12b, and 12c are example compartment allocation policy statements according to one embodiment.

[0222] FIG. 12a illustrates a configured allocation policy according to one embodiment. FIG. 12b illustrates an unconfigured allocation policy according to one embodiment.

[0223] FIG. 12c illustrates a zero allocation policy according to one embodiment. According to an embodiment, the language component of each quota policy statement includes the following components: 1) an action keyword - the action keyword can correspond to the type of quota being defined. This can be, for example, set, unset, or zero; 2) the name of the service family. This can be, for example, compute; 3) the quota or the quota keyword; 4) the name of the quota, which varies depending on the service family. For example, a valid quota in the compute family could be "vm-standard2-16-count". In addition, a range of names can be specified using wildcards. For example, " / vm-* / " matches all compute shapes that start with the letters "vm"; 5) a "for" configuration statement that sets the value of an assignment; 6) and the compartment the allocation covers;7) optional conditions may also be provided, for example, request.region = 'us-phoenix-1'. Such conditions may include request.region and request.ad.

[0224] FIG. 13 is a diagram illustrating an example of an allocation policy statement according to an embodiment.

[0225] According to one embodiment, the statement in FIG. 13 is set 1301 state. This statement applies to family 1302. An assignment 1303 is applied to a name 1304 (e.g., a resource) and an assignment sets it to a value 1305. An assignment may be applied in 1307 to a location 1308, and then conditions 1309 may also be applied. can be set similarly.

[0226] According to an embodiment, several exemplary allocation policy statements are provided below, with several examples provided below along with a description of each allocation policy.

[0227] According to one embodiment, the allocation policy is as follows: Set compute quotas to 0 in compartment My Compartment (Set the compute quota to 0 in compartment My Compartment) According to the embodiment, the above allocation policy is Set the compute quota to 0, thereby preventing any further resources from being created.

[0228] According to one embodiment, the allocation policy is as follows: Set block-storage quota 'volume-count' to 10 in compartment My Compartment (Set Block-Storage Allocation "Volume Count" to 10 in compartment My Compartment) According to one embodiment, the above allocation policy would set the block storage allocation for the volume count in "My Compartment" to 10.

[0229] According to one embodiment, the allocation policy is as follows: Set compute quota 'VM.Dense101.16' to 10 in compartment MyCompartment where request.region = 'phx' (Set compute quota 'VM.Dense101.16' to 10 in compartment My Compartment, where request.region = 'phx') According to one embodiment, the above allocation policy is applied to the VM.DenseIO1.16 compute shape. The allocation for "My Compartment" in PHX would be set to 10.

[0230] According to one embodiment, the allocation policy is as follows: Set compute quota / VM.* / to 10 in compartment MyCompartment (Set the compute quota / VM.* / to 10 in compartment My Compartment) According to an embodiment, wildcard expressions can be used to match many names at once. The above allocation policy sets the allocation for each VM shape to 10, but not the combined allocation to 10.

[0231] According to one embodiment, the allocation policy format may require the specification of an allocation family, along with an optional name or list of names.

[0232] According to an embodiment, the allocation location 1008 may include the target compartment to which the allocation applies, which is often different from the compartment in which the allocation resides and may be a descendant of it. The allocation location may also be the "tenancy," which is equivalent to identifying the root compartment.

[0233] According to an embodiment, another example of an allocation policy statement is a zero statement.

[0234] FIG. 14 illustrates an example allocation policy statement, according to one embodiment. According to one embodiment, the statement in Figure 14 is a zero 1401 statement that applies to a family 1402. A quota 1403 applies to a name 1404 (e.g., a resource). A zero quota applies to a location 1405. ) 1406 may be applied in 1405 and then conditions 1407 may be set as well.

[0235] According to an embodiment, several exemplary allocation policy statements are provided below, with several examples provided below along with a description of each allocation policy.

[0236] According to one embodiment, the allocation policy is as follows: Zero compute quota 'VMStandard2.32' in compartment MyCompartmen (Set compute quota 'VMStandard2.32' to zero in compartment MyCompartment ) According to one embodiment, the above allocation policy statement assigns This applies to VM Standard 2.32 instance types in the compartment. Once this quota is set, users will not be able to launch any of these instances (e.g. VM Standard 2.32) in that compartment.

[0237] According to an embodiment, the allocation policy language can further support whitelists, in other words, setting all allocations in a family to 0 and explicitly allocating resources on top of this. This can be achieved by establishing a simple statement precedence rule: if two or more statements evaluate to true in the same policy, the last statement in the set will take control.

[0238] To see how priorities work to support whitelists, according to one embodiment, consider the following two allocation policies: Zero compute quotas in tenancy (Tenancy has zero compute quota) Set compute quota 'VM.DenseIO1.16' to 10 in tenancy (Set the compute quota 'VM.DenseIO1.16' to 10 in your tenancy) According to one embodiment, a base statement can be written that reduces all compute allocations to 0. In addition to this, a second statement can be written for VM.DenseIO1.16 that we want to allow up to 10. Importantly, this override only applies to statements written in the same policy. There is no precedence between statements from different policies, they must all be satisfied. This makes it impossible for a child compartment administrator to override allocations in a parent compartment. Administrators can safely give child compartment administrators "full resource control" of the child and maintain appropriate allocations. Child compartment administrators can only further reduce allocations that already exist in the parent compartment.

[0239] Another example of an allocation policy statement is an unset statement, according to one embodiment.Figure 15 illustrates an example of an allocation policy statement, according to one embodiment.

[0240] According to one embodiment, the statement in FIG. 15 is an unset statement 1 501, which applies to family 1502. 1503 is unset in 1505 a location 1506 , with optional conditions 1507 , to a name 1504 (eg, a resource).

[0241] According to one embodiment, going back to the example above regarding priorities, the second allocation policy can be unset so that there is no allocation on VM DenseIO1.16. Zero compute quotas in tenancy (Tenancy has zero compute quota) Unset compute quota 'VM.DenseIO1.16' to 10 in tenancy (Assume that your tenancy has a compute allocation of 'VM.DenseIO1.16' set to 10) According to one embodiment, as in the previous example, unconfigured works across different allocation policies. It doesn't work.

[0242] According to one embodiment, within the control plane of each service there is a critical section (e.g., time) during which a database transaction remains open. The longer this period, the more contention and failures begin to creep in. To minimize this potential problem, an allocation policy in the range of approximately 5 milliseconds can be considered and applied.

[0243] According to one embodiment, as described above, quotas can be enforced at the compartment level. Thus, quotas can be further specified to place quotas on additional entities within a compartment, such as users, groups, and tags. For example, consider the following quota statement: Set compute quota 'VM.DenseIO1.16' to 20 in tenancy where request.user = ocid1.user.dev..aaaaaaaan4xh2xpvzcmabc5m7pd7ioaovc2ktt56fvbhfy77y4v (You have set the compute quota 'VM.DenseIO1.16' to 20 in your tenancy and request.user = ocid1.user.dev..aaaaaaaan4xh2xpvzcmabc5m7pd7ioaovc2ktt56fvbhfy77y4v) The above allows quotas to be placed partially on the user, but does not guarantee that the user will get 20 instances, since quotas are on compartments and not users. Instead, a quota can be specified that sets the quota for a user regardless of current compartment usage.

[0244] FIG. 16 illustrates an example of an allocation policy statement, according to one embodiment. More specifically, FIG. 16 illustrates an allocation policy statement that further includes a scope.

[0245] According to one embodiment, the statement in FIG. 16 is set 1601 state. This statement applies to family 1602. A name 1603 is applied to a name (e.g., a resource) and an assignment sets it to a value 1605. In 1610, a condition 1612 may be set in the same manner, for 1607, a scope 1608, where 1611. Taking the compartment assignment above and rewriting it using the statement language of Figure 16, the assignment policy becomes: Set compute quota 'VM.DenseIO1.16' to 10 for user MyUser in tenancy (Set the compute quota 'VM.DenseIO1.16' to 10 for user MyUser in your tenancy) According to one embodiment, the quota policy language clearly expresses that this quota applies to MyUser and not to a compartment. This is an entirely separate quota from the compartment quota, and all quota scopes (both the quota policies above and any compartment quota policies) must be satisfied when creating a resource.

[0246] FIG. 17 illustrates an example of an allocation policy statement, according to one embodiment. More specifically, FIG. 17 illustrates an override assignment policy.

[0247] According to one embodiment, the precedence rules associated with compartment assignments do not allow a statement in one policy to override a statement from a different policy. This means that to implement whitelists, the system and method are limited by the maximum number of statements in a single policy. To address this, explicit override statements can be utilized. This statement establishes that one policy takes precedence over another. This is equivalent to writing the statements together as part of one longer policy. Policies must live in the same compartment for the override statement to apply.

[0248] According to one embodiment, an override statement may include an override statement 1700 , override 1701 , one or more other quatas 1703 , in 1704 , policy 1704 , and name 1705 .

[0249] According to one embodiment, consider the following override statement: Override quotas in policy BasePolicy (Overrides assignments in policy "base policy") According to one embodiment, the override statement specifies that any statement in this policy overrides a statement in the base policy. Note that overrides are transitive: if a overrides b, and b overrides c, then a overrides c.

[0250] FIG. 18 is a flowchart of a method for supporting an allocation policy language in a cloud infrastructure environment according to an embodiment.

[0251] According to one embodiment, in step 1810, the method may provide a computer including one or more microprocessors.

[0252] According to an embodiment, in step 1820, the method may provide a cloud infrastructure environment including multiple regions, where a tenancy is defined within the multiple regions.

[0253] According to an embodiment, in step 1830, the method may provide multiple compartments for the tenancy.

[0254] According to an embodiment, in step 1840, the method can include providing a console interface adapted to receive input indicative of an instruction.

[0255] According to an embodiment, at step 1850, the method can provide, within the cloud infrastructure environment, a restricted service data plane having access to a database that stores multiple compartment resource allocations.

[0256] According to an embodiment, in step 1860, the method may associate a compartment of the tenancy with a compartment assignment of a plurality of compartment assignments.

[0257] According to an embodiment, in step 1870, the method may configure the allocation policy to be one of a set policy, a not set policy, or a zero allocation policy.

[0258] Calculation process (algorithm) used According to an embodiment, the system and method may support a usage computation process or algorithm to determine whether a requested transaction violates any restrictions or quotas for a compartment.

[0259] According to an embodiment, a usage accounting method can provide an SDK for both evaluating quotas or limits and counting resources per compartment.

[0260] According to one embodiment, this process can be distributed across several systems and subsystems within a cloud infrastructure environment.

[0261] According to one embodiment, FIG. 10 illustrates an architecture flow for a user launching an instance that requires checking against one or more compartment resource quotas.

[0262] FIG. 19 illustrates an architecture for a system for enforcing compartment allocation in a cloud infrastructure environment, according to one embodiment.

[0263] According to one embodiment, in step 1, an instruction may be received, for example, from a user 1901. The instruction may indicate a request to launch an instance within a region 1900, where the request specifies a compartment within the region.

[0264] According to one embodiment, in step 2, a load balancer 1920 (eg, Flamingo) can forward the request to an API, such as a public API proxy.

[0265] According to an embodiment, in step 3, the API can perform authentication in the identity data plane 1935. Such an authentication step can check both that the user has the correct credentials (e.g., user credentials such as username and password, one-time password, or other authentication method) and that the user 1901 has sufficient authorization in the region to perform the requested launch of an instance in the targeted compartment. For example, if the user 1901 does not have sufficient authorization to launch an instance in the targeted compartment (e.g., the user 1901 only has authorization to launch a similar instance in a child compartment of the targeted compartment), the API 1925 can reject the request. If the user has sufficient authorization, the API can allow the request to proceed.

[0266] According to an embodiment, in step 4, the request to launch the instance may be forwarded to a computation control plane (CCP) 1930. The CCP may then further authenticate the request in the identity data plane in step 5.

[0267] According to an embodiment, in step 6, the compute control plane can call the identity data plane 1935 to fetch the compartment tree associated with the compartment to which the request is directed, or the compartment tree for the entire tenancy to which the request is directed.

[0268] According to one embodiment, in step 7, the compute control plane can fetch all compartment assignments for a tenancy or compartment tree from the restricted services data plane 1940, which contains the compartment assignment map 1941. This can include a certain number of compartment assignments for the particular compartment to which the request is directed, as well as the compartment assignments for the entire tree above that particular compartment.

[0269] According to one embodiment, in step 8, the computational control plane can calculate a total usage for each compartment in the lineage, which is equal to the sum of the compartment's usage and the total usage of each child compartment recursively down the hierarchy.

[0270] According to an embodiment, the CCP 1930 can compare each limit / quota to the total usage of that compartment. If any limit / quota is violated, the CCP can return a complaint indicating which quota and / or limit the expected resources will exceed. In addition to the complaint, the CCP can also return the amount by which the expected resources will exceed the quota.

[0271] According to one embodiment, if the CCP determines that the expected resources are permitted, then in step 9 the transaction may be committed in database 1945 .

[0272] FIG. 20 is a flowchart of a method for supporting a usage computing process in a cloud infrastructure environment, according to one embodiment.

[0273] According to an embodiment, in step 2001, the process can fetch the compartment tree hierarchy, for example from the identity data plane. This can involve a single request (e.g., HTTP) with the amount of data returned growing linearly with the number of compartments.

[0274] According to one embodiment, the process can determine the lineage of the target compartment (i.e., the compartment to which the transaction is directed) in step 2002. Lineage can grow linearly with the height of the compartment tree.

[0275] According to an embodiment, in step 2003, the method can fetch the quota policy / service restrictions enforced on the target compartment by invoking the restriction service data plane. In doing so, the process can fetch both the quota and service restriction requests in a single restriction service data plane request.

[0276] According to one embodiment, in step 2004, a database transaction may be initiated.

[0277] According to an embodiment, in step 2005, the resource counts for each affected allocation from the database buckets can be fetched. For each allocation, the process can match the objects from the database with the entire tenant usage data for that allocation. The data returned can grow linearly with the number of compartments within that tenant that have usage of that resource / allocation.

[0278] According to an embodiment, in step 2006, the process can calculate the total usage of each compartment in the lineage. The total usage can be the sum of the compartment's usage and the total usage of all its children recursively down the tree. This operation is linear in the number of compartments in the tree. The process can perform a recursive depth first tree traversal with counts going up the tree.

[0279] According to one embodiment, in step 2007, the process can compare each limit / quota to the total usage for that compartment. ,The process can return a result object indicating which quota or limit was violated and by how much.

[0280] According to one embodiment, in step 2008, the process may commit the transaction to the database.

[0281] FIG. 21 is a flowchart of a method for supporting a usage computing process in a cloud infrastructure environment, according to one embodiment.

[0282] According to one embodiment, in step 2110, the method may provide a computer including one or more microprocessors.

[0283] According to an embodiment, in step 2120, the method may provide a cloud infrastructure environment including multiple regions, where a tenancy is defined within the multiple regions.

[0284] According to an embodiment, in step 2130, the method can provide a compartment of the tenancy, where the compartment belongs to a tree structure of multiple compartments, and the compartment is associated with a compartment allocation policy.

[0285] According to an embodiment, in step 2140, the method can receive a requested transaction, the requested transaction targeted to a compartment.

[0286] According to an embodiment, in step 2150, the method may determine whether the requested transaction violates a compartment allocation policy.

[0287] According to one embodiment, the requested transaction may require a certain type of resource.

[0288] According to an embodiment, the determination described in step 2150 may include additional steps, including fetching a compartment tree hierarchy including the targeted compartment, determining a lineage of the targeted compartment, and fetching a plurality of compartment assignments to be implemented on the targeted compartment by invoking a restriction service data plane, the plurality of compartment assignments including a compartment assignment policy, each of the plurality of compartment assignments belonging to a compartment in the compartment tree hierarchy, the above steps further including initiating the requested transaction in a database, and fetching a resource count for each of the plurality of compartment assignments from the database, each resource count including a count of the requested resource type, the above steps further including calculating a total usage of the requested resource type for each compartment in the determined lineage, the total usage for each compartment including an aggregate of the usage of the compartment and the total usage of each child compartment, and the above steps further including comparing each of the plurality of compartment assignments to the total usage of each compartment.

[0289] According to various embodiments, the teachings herein can be implemented in one or more conventional general-purpose or special-purpose digital computers, computing devices, including one or more processors, memory, and / or computer-readable storage media programmed according to the teachings of the present disclosure. The implementation may conveniently be achieved using a microprocessor, machine, or microprocessor. Appropriate software coding can be readily prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.

[0290] In some embodiments, the teachings of the present disclosure may include a computer program product that may use a computer-readable medium to communicate (e.g., store or carry) instructions for one or more programmable processors or computers to perform any of the processes of the present teachings. One example of a computer-readable medium is a non-transitory computer-readable storage medium having stored thereon instructions that may be used to program a computer to perform any of the processes of the present teachings. Examples of such storage media may include, but are not limited to, hard disk drives, hard disks, hard drives, fixed disks, or other electromechanical data storage devices, floppy disks, optical disks, DVDs, CD-ROMs, microdrives, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems, or other types of storage media or devices suitable for non-transitory storage of instructions and / or data. Another example of a computer-readable medium is a transient medium that communicates such instructions between computer systems or between components of a given computer system. Examples of transient media may include, but are not limited to, carrier waves and transmission signals.

[0291] Thus, in one respect, a system and method for supporting compartment quotas in a cloud infrastructure environment has been described. Cloud administrators generally do not have the ability to limit resource usage in existing clouds. Giving users permission to create resources allows them to create any number of resources up to a predefined account limit. Compartment quotas allow administrators to limit users' resource usage to appropriate levels, allowing for fine-tuned cost control.

[0292] The foregoing description has been provided for purposes of illustration and explanation. It is not intended to be exhaustive or to limit the scope of protection to the precise form disclosed. Many modifications and variations will be apparent to those skilled in the art. For example, although some of the examples provided in this disclosure illustrate use with enterprise software application components such as Oracle Fusion Applications, cloud environments such as Oracle Cloud Infrastructure, and cloud services such as Oracle Fusion Analytics, according to various embodiments, the systems and methods described in this disclosure can be used with other types of enterprise software applications, cloud environments, cloud services, cloud computing, or other computing environments.

[0293] The embodiments have been chosen and described in order to best explain the principles of the present teachings and their practical application, so that those skilled in the art will recognize various embodiments and various modifications suited to the particular use contemplated, the scope of which is intended to be defined by the claims and their equivalents.

Claims

1. 1. A system for supporting compartment allocation in a cloud infrastructure environment, comprising: a computer including one or more microprocessors; a cloud infrastructure environment including a plurality of regions, wherein a tenancy is defined within the plurality of regions, the system further comprising: a plurality of compartments in said tenancy; a restricted service data plane in the cloud infrastructure environment, the restricted service data plane having access to a database storing a plurality of compartment resource allocations; a compartment resource allocation of the plurality of compartment resource allocations associated with a compartment of the plurality of compartments, the compartment resource allocation limiting at least one type of resource within the compartment; a request is received for a resource to be provisioned in the compartment, the requested resource being of the type limited by the resource allocation; a determination is made whether the provisioning of the requested resource violates the compartment resource allocation; provisioning the requested resources based on a determination that the compartment resource allocation will not be violated; The system challenges the request based on a determination that the request would violate the compartment resource allocation.

2. the plurality of compartments are arranged in a hierarchical manner; The system of claim 1 , wherein a mapping of the arrangement of the plurality of compartments arranged in a hierarchical manner is stored in a location accessible by the restricted services data plane.

3. The system of claim 2 , wherein the compartment resource allocations are arranged in a hierarchical manner corresponding to the hierarchical arrangement of the compartments.

4. The system of claim 1 , wherein the cloud infrastructure environment includes multiple regions and the tenancy is defined across the multiple regions.

5. The system of claim 4 , wherein each of the plurality of compartments is defined across the plurality of regions.

6. The system of claim 5 , wherein the compartment resource allocation is defined within a first region of the plurality of regions.

7. The system of claim 6 , wherein once the compartment resource allocation is defined in the first region of the plurality of regions, the compartment resource allocation is replicated in each other region of the plurality of regions.

8. 1. A method for supporting compartment assignment in a cloud infrastructure environment, comprising: Providing a computer including one or more microprocessors; providing a cloud infrastructure environment on the computer, the cloud infrastructure environment including a plurality of regions, a tenancy defined within the plurality of regions, the method further comprising: providing a plurality of compartments in said tenancy; and providing a restricted service data plane within the cloud infrastructure environment, the restricted service data plane having access to a database storing a plurality of compartment resource allocations, the method further comprising: and associating a compartment resource allocation of the plurality of compartment resource allocations with a compartment of the plurality of compartments, the compartment resource allocation limiting at least one type of resource within the compartment, the method further comprising: receiving a request for a resource to be provisioned in the compartment, the requested resource being of the type limited by the resource allocation, the method further comprising: determining whether the provisioning of the requested resource would violate the compartment resource allocation; provisioning the requested resources based on a determination that the compartment resource allocation will not be violated; and and challenging the request based on a determination that the request would violate the compartment resource allocation.

9. further comprising arranging the plurality of compartments in a hierarchical manner; The method of claim 8 , wherein the arranging mapping of the arrangement of the plurality of compartments in a hierarchical manner is stored in a location accessible to the restricted service data plane.

10. The method of claim 9 , further comprising arranging the compartment resource allocations in a hierarchical manner corresponding to the hierarchical arrangement of the compartments.

11. 11. The method of claim 8, wherein the cloud infrastructure environment includes multiple regions and the tenancy is defined across the multiple regions.

12. The method of claim 11 , further comprising defining each of the plurality of compartments across the plurality of regions.

13. The method of claim 12 , further comprising defining the compartment resource allocation within a first region of the plurality of regions.

14. The method of claim 13 , wherein once the compartment resource allocation is defined in the first region of the plurality of regions, the compartment resource allocation is replicated in each other region of the plurality of regions.

15. 1. A computer-readable medium having instructions for supporting compartment allocation in a cloud infrastructure environment, the instructions, when read and executed by a computer, causing the computer to perform steps including: Providing a computer including one or more microprocessors; providing a cloud infrastructure environment on the computer, the cloud infrastructure environment including a plurality of regions, tenancies defined within the plurality of regions, the steps further comprising: providing a plurality of compartments in said tenancy; and providing a restricted service data plane within the cloud infrastructure environment, the restricted service data plane having access to a database storing a plurality of compartment resource allocations, the steps further comprising: and associating a compartment resource allocation of the plurality of compartment resource allocations with a compartment of the plurality of compartments, the compartment resource allocation limiting at least one type of resource within the compartment, the step further comprising: receiving a request for a resource to be provisioned in the compartment, the requested resource being of the type limited by the resource allocation, the step further comprising: determining whether the provisioning of the requested resource would violate the compartment resource allocation; provisioning the requested resources based on a determination that the compartment resource allocation will not be violated; and and challenging the request based on a determination that the request would violate the compartment resource allocation.

16. The steps further include arranging the plurality of compartments in a hierarchical manner; 16. The computer-readable medium of claim 15, wherein the arranging mapping of the arrangement of the plurality of compartments in a hierarchical manner is stored in a location accessible to the restricted service data plane.

17. 20. The computer-readable medium of claim 16, said steps further comprising arranging the compartment resource allocations in a hierarchical manner corresponding to the hierarchical arrangement of the compartments.

18. 18. The computer-readable medium of claim 15, wherein the cloud infrastructure environment includes multiple regions and the tenancy is defined across the multiple regions.

19. 20. The computer-readable medium of claim 18, wherein the steps further comprise defining each of the plurality of compartments across the plurality of regions.

20. The steps further include: defining the compartment resource allocation within a first region of the plurality of regions; 20. The computer-readable medium of claim 19, further comprising: once the compartment resource allocation is defined in the first region of the plurality of regions, replicating the compartment resource allocation in each other region of the plurality of regions.

Images