Techniques for rotating resource identifiers in a provisioning area

Abstract

A technique for rotating resource identifiers within a local area network is disclosed. An identity service can receive a first request for a first identifier of a software resource within the local area network from a client node. The identity service can generate the first identifier at least partially based on a first attribute and send the first identifier and a first caching instruction to the client node. The identity service can receive an identity rotation instruction, which includes information that the identity service can use to provide a second caching instruction in response to the request for the software resource identifier. The identity service can receive a second request for a second identifier of the software resource. The identity service can generate a second identifier at least partially based on a second attribute and send the second identifier and a second caching instruction to the client node.

Description

[0001] Cross-references to related applications

[0002] This international application claims the interest and priority of U.S. nonprovisional application No. 18 / 520,510, filed November 27, 2023, entitled “TECHNIQUES FOR ROTATINGRESOURCE IDENTIFIERS IN PREFAB REGIONS”, agent file number 088325-1327651 (347900US), the entire contents of which are incorporated herein by reference for all purposes. Technical Field

[0003] This disclosure relates to cloud computing data centers. More specifically, this disclosure describes techniques for rotating resource identifiers of software resources within a data center network from locally unique identifiers within the networked environment of a prefabricated facility to unique identifiers within the networked environment of a destination site. Background Technology

[0004] Cloud infrastructure providers can operate one or more data centers in geographic regions around the world. A "region" is a logical abstraction of a collection of computing, storage, and networking resources surrounding a data center in a given geographic area used to provide cloud computing infrastructure. Building a new region may involve provisioning computing resources, configuring infrastructure, and deploying code to those resources (typically via network connections to the data center). However, building a region with physical resources located at the final destination data center site requires significant preparation work at the data center, which can complicate the logistics and scheduling of completing the region's construction. Summary of the Invention

[0005] Embodiments of this disclosure relate to the automated construction of regions using a prefab factory. A prefab factory can be a facility specifically designed for configuring computing devices, networking devices, and other physical resources for delivery to a destination site (e.g., a destination region—one or more data centers, customer facilities, etc., in a geographic area). Operations for constructing a region may include bootstrapping (e.g., provisioning and / or deployment) resources (e.g., infrastructure components, artifacts, etc.) so that any suitable number of services are available from the region upon delivery to the destination. Once the physical resources have been configured at the prefab factory, they can be transported to the destination site, installed at the destination data center, and the final configuration and other software resources can be deployed to the physical resources. Resources used for bootstrapping (e.g., software artifacts, software images, etc.) can be provided in a boot environment within an existing region (e.g., one or more data centers in a host region). The host region can be selected based on network proximity to the prefab factory, and, complementaryly, the prefab factory can be located to have high-performance network connectivity with one or more host regions to support the boot environment. A prefabricated region can be orchestrated by one or more cloud-based services. These services manage the inventory of physical computing equipment used to build the region in the prefabrication plant, generate and specify the configuration of the region to be built in the prefabrication plant, manage the bootstrapping of the region, configure the region for transfer to the destination site, and test and verify the physical resources after they have been installed at the destination site. Prefabricated regions can be built to meet specific customer configuration preferences (build-to-order) or according to a generic specification that is further customized during installation at a specific customer's site (build-to-stock).

[0006] One embodiment relates to a computer-implemented method for rotating the identity of a resource within a local area network (LAN) after installation at a destination site or during installation at a destination site. The method may be performed by an identity service executing on one or more computing devices of a distributed computing system hosting the LAN. The method may include the identity service receiving a first request for a first identifier of a software resource within the LAN. The identity service may receive the first request from a client node within the LAN. The first request may include a first attribute associated with the software resource. The method also includes the identity service generating the first identifier at least in part based on the first attribute and sending the first identifier and a first cache instruction to the client node. The first cache instruction is available to the client node to prevent the first identifier from being stored in a cache associated with the client node. The method further includes receiving an identity rotation instruction, which may include information available to the identity service to provide a second cache instruction in response to the request for the software resource identifier. The identity service may receive the identity rotation instruction from a manager service of a coordination / orchestration LAN build operation. The method also includes the identity service receiving a second request for a second identifier of the software resource. The second request may be received from a client node, and the second request may include a second attribute associated with the software resource. The method also includes an identity service generating a second identifier based at least in part on a second attribute, and sending the second identifier and a second caching instruction to the client node. The second caching instruction can be used by the client node to store the second identifier in a cache.

[0007] Another embodiment relates to a distributed computing system including one or more processors and instructions that, when executed by the one or more processors, cause the distributed computing system to perform the methods described above.

[0008] Another embodiment relates to a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors of a distributed computing system, cause the distributed computing system to perform the methods described above. Furthermore, embodiments can be implemented using a computer program product comprising a computer program / instructions that, when executed by a processor, cause the processor to perform any of the methods described in this disclosure. Attached Figure Description

[0009] To facilitate identification of any discussion of a particular element or action, the highest one or more bits in the reference number refer to the figure number in which the element was first introduced.

[0010] Figure 1 This is a block diagram illustrating a prefabrication plant for constructing a region and preparing regional computing devices for transmission to a target data center, according to at least one embodiment.

[0011] Figure 2 This is a block diagram illustrating a prefabrication plant connected to services provided by a CSP for building areas, according to at least one embodiment.

[0012] Figure 3 This is a diagram illustrating a network configuration for managing computing resources in an area being built in a prefabrication plant using a manager service and a network service, according to at least one embodiment.

[0013] Figure 4 This is a diagram illustrating the testing and evaluation of an area after delivery to a destination site using a manager service and a test service, according to at least one embodiment.

[0014] Figure 5 This is a block diagram illustrating an identity service for identifier management in a local area network according to at least one embodiment.

[0015] Figure 6 This is a block diagram illustrating the use of identifiers for software resources within multiple regional networks according to at least one embodiment.

[0016] Figure 7 This is a block diagram illustrating the creation of identifiers for software resources based on domains and regions according to at least one embodiment.

[0017] Figure 8 This is a block diagram illustrating the rotation of identifiers used for software resources after they have been delivered to the destination site according to at least one embodiment of the local area network.

[0018] Figure 9 This is a flowchart of an example process for rotating from a first identifier to a second identifier of a software resource, according to at least one embodiment.

[0019] Figure 10 This is a block diagram illustrating a pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0020] Figure 11 This is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0021] Figure 12 This is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0022] Figure 13 This is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system according to at least one embodiment.

[0023] Figure 14 This is a block diagram illustrating an example computer system according to at least one embodiment. Detailed Implementation

[0024] Example of automated data center construction (regional construction) infrastructure

[0025] The adoption of cloud services has increased rapidly recently. Currently, various cloud service providers (CSPs) offer a wide range of cloud services. The term cloud service generally refers to services or functionalities provided by a CSP to users or customers on demand (e.g., via a subscription model) using systems and infrastructure (cloud infrastructure) provided by the CSP. Typically, the servers and systems that constitute the CSP's infrastructure and are used to provide cloud services to customers are separate from the customer's own on-premises servers and systems. Therefore, customers can utilize cloud services provided by the CSP without having to purchase separate hardware and software resources for the service. Cloud services are designed to provide subscribers with simple, scalable, and on-demand access to applications and computing resources without requiring customers to invest in the infrastructure used to provide the services or functionalities. Various types or models of cloud services can be provided, such as Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), etc. Customers can subscribe to one or more cloud services provided by a CSP. Customers can be any entity, such as individuals, organizations, enterprises, government entities, etc.

[0026] As indicated above, the CSP is responsible for providing the infrastructure and resources used to deliver cloud services to subscribers. The resources provided by the CSP can include both hardware and software resources. These resources can include, for example, computing resources (e.g., virtual machines, containers, applications, processors, bare metal computers), storage resources (e.g., databases, data repositories), networking resources (e.g., routers, host machines, load balancers), identity, and other resources. In some implementations, the resources provided by the CSP for delivering a set of cloud services are organized into a data center. The data center can be configured to provide a specific set of cloud services. The CSP is responsible for equipping the data center with the infrastructure and resources for delivering that specific set of cloud services. The CSP can build one or more data centers.

[0027] Data centers provided by a CSP can be hosted in different regions. A region is a local geographic area and can be identified by its name. Regions are typically independent of each other and can be geographically distant, such as spanning countries or even continents. Regions are grouped into domains. Examples of regions for a CSP could include the western United States, the eastern United States, eastern Australia, southeastern Australia, etc.

[0028] A region can include one or more data centers located within a specific geographic area corresponding to that region. As an example, a data center within a region could be located in a city within that region. For instance, for a specific CSP, a data center in the Western United States region could be located in San Jose, California; a data center in the Eastern United States region could be located in Ashburn, Virginia; a data center in the Eastern Australia region could be located in Sydney, Australia; a data center in the Southeastern Australia region could be located in Melbourne, Australia; and so on.

[0029] Data centers within a region can be organized into one or more availability domains, which are used for high availability and disaster recovery purposes. An availability domain can include one or more data centers within a region. Availability domains within a region are isolated from each other, fault-tolerant, and built in a way that makes it extremely unlikely for data centers in multiple availability domains to fail simultaneously. For example, availability domains within a region can be built in a way that makes it unlikely for a failure in one availability domain within the region to affect the availability of data centers in other availability domains within the same region.

[0030] When a customer or subscriber subscribes to or registers for one or more services provided by a CSP, the CSP creates a tenancy for the customer. A tenancy is like an account created for the customer. In some implementations, the tenancy for a customer exists within a single domain and has access to all regions belonging to that domain. The customer's user can then access the services the customer has subscribed to under that tenancy.

[0031] As indicated above, CSPs build or deploy data centers to provide cloud services to their customers. As a CSP's customer base grows, it typically builds new data centers in new regions or increases the capacity of existing data centers to serve the increasing needs of its customers and better serve them. Preferably, the data center is built in a location geographically very close to the location of the customers served by that data center. Geographical proximity between the data center and the customers served by that data center results in lower latency, leading to more efficient use of resources and providing customers with faster and more reliable service. Accordingly, CSPs typically build new data centers in new regions within geographically close to the customers served by the data center. For example, for a growing customer base in Germany, a CSP might build one or more data centers in new regions within Germany.

[0032] Building a data center (or multiple data centers) within a region and configuring it to provide cloud services is sometimes referred to as building a region. The term "region building" is used to refer to constructing one or more data centers within a region. Building a region involves provisioning or creating a new set of resources that are required or used to provide a set of services that the data center is configured to provide. The end result of the region building process is the creation of a region in which the data center, along with its contained hardware and software resources, is capable of providing a set of services designed for that region and includes a set of resources for providing that set of services.

[0033] Building a new region is a highly complex activity, requiring large-scale coordination among various bootstrapping activities. At a high level, this involves performing and coordinating a variety of tasks, such as: identifying the set of services to be provided by the data center; identifying the various resources required to provide the set of services; creating, provisioning, and deploying the identified resources; properly wiring the underlying hardware so that it can be used as intended; and so on. Each of these tasks further has sub-tasks that require coordination, which further increases the complexity. Due to this complexity, currently, region building involves several manually initiated or manually controlled tasks that require careful manual coordination. As a result, the task of building a new region (i.e., building one or more data centers within a region and configuring the hardware and software in each data center to provide the necessary cloud services) is very time-consuming. Region building can take, for example, many months. Furthermore, this process is highly error-prone, sometimes requiring several iterations before achieving the desired configuration of the region, which further increases the time spent building the region (e.g., deploying hardware and software resources). These limitations and problems severely restrict the ability of CSPs to develop computing resources in a timely manner in response to increasing customer demand.

[0034] Recent innovations allow CSPs to shorten build times, reduce wasted computing resources, and mitigate risks associated with build regions. CSPs can use orchestration services to bootstrap services to new regions. Orchestration services can be cloud-based services hosted in a separate region (e.g., an orchestration region) different from the target region. To bootstrap services to the target region, the orchestration service can create a bootstrap environment to host instances of one or more cloud services. The orchestration service can then use the services in the bootstrap environment to support the deployment of services to the target region.

[0035] Even more recent innovations allow CSPs to centralize region building operations into one or more facilities that can act as “factories” to produce partially or fully configured physical infrastructure for subsequent delivery to destination sites. Instead of waiting for the construction of the target region data center and the installation of physical components (e.g., servers, network switches, power supplies, etc.) in the data center before services are bootstrapped to the target region, CSPs can build regions in a prefabrication plant, ship the configured physical components (such as racks) to the destination data center, and then complete the final configuration and verification of the region's components once the racks arrive at the destination site. A prefabrication plant can build multiple regions simultaneously. Each region built in the prefabrication plant can have a separate configuration, network topology, and services. By building regions in a prefabrication plant, the complexity of scheduling and logistics associated with preparing destination facilities, delivering physical components to destination facilities, and managing bootstrapping resources within cloud services can be significantly reduced, as regions can be built and maintained in advance until the destination site is ready.

[0036] Prefabrication plants can also be used to build computing components for integration into customers’ on-premises solutions, for example, when customers control and manage their own data center environments.

[0037] This disclosure relates to a prefabrication plant in which automated region building is performed using one or more prefabrication services. A prefabrication manager service can orchestrate the overall building of regions within the prefabrication plant. The manager service can work in conjunction with one or more additional prefabrication services to manage an inventory of physical components used to build regions in the prefabrication plant, configure networks (e.g., endpoints, network topology, addresses, and / or other identifiers for components within the region), bootstrap services onto the region infrastructure, prepare components for region transfer (including encrypting data volumes to provide security during transfer), verify the region after delivery and installation at the destination site, and finally complete the region configuration, including performing any remaining bootstrap or update operations on services previously deployed to the region infrastructure in the prefabrication plant.

[0038] Specifically, the prefabrication service can perform configuration of regional network components to adapt to operations where the configuration at the destination site may differ from that at the prefabrication plant. For example, a customer network configuration may use a different domain than the one used during prefabrication. As another example, when implementing secure communication channels (e.g., Transport Layer Security (TLS) connections) within the network, customers may use different certificate authorities to establish chains of trust. Once the prefabrication zone has been installed at the destination site, endpoints of services deployed in the prefabrication zone at the prefabrication plant may need to switch to endpoints conforming to the network environment of the destination site. The manager service can orchestrate the adoption of dual-headed certificates that support both the original endpoint and the target endpoint to be rotated. Advantageously, dual-headed certificates allow secure network communication for services using either endpoint to continue during the rotation process. Since downstream services will continue to use the original endpoint against upstream services until the rotation process progresses, the ability to establish an effective and secure communication channel within the regional network allows deployed services to continue operating normally with minimal downtime, thereby improving the efficiency of configuration operations at the destination site.

[0039] Some definitions

[0040] A “region” is a logical abstraction corresponding to a collection of computing, storage, and networking resources associated with a geographical location. A region can include any suitable number of one or more execution targets. A region can be associated with one or more data centers. A “prefabricated region” describes a region built in a prefabricated factory environment before being delivered to a corresponding geographical location. In some embodiments, execution targets may correspond to a destination data center rather than a prefabricated factory data center.

[0041] An "execution target" is the smallest unit of change used to perform a release. A "release" is an expression of intent to orchestrate specific changes to a service (e.g., deploying version 8, "adding internal DNS records," etc.). For most services, an execution target represents an "instance" of the service or an instance of changes to be applied to the service. A single service can be directed to each of one or more execution targets. Execution targets can be associated with a set of devices (e.g., a data center).

[0042] A “guiding” single service is defined as the collective task associated with the provisioning and deployment of any appropriate number of resources (e.g., infrastructure components, artifacts, etc.) corresponding to that single service. A guiding region is defined as the collective task associated with each guiding for each service intended to be in that region.

[0043] A "service" refers to functionality provided by a set of resources, typically in the form of an API that a client can invoke to achieve some useful result. The set of resources for a service includes any suitable combination of infrastructure, platforms, or software (e.g., applications) hosted by a cloud provider and configured to provide the functionality. Services can be made available to users via the Internet.

[0044] A "resource identifier descriptor" is a tuple of attributes (e.g., categories such as "region," "domain," "type," "resource ID," "name"), attribute values ​​(e.g., "Commercial" domain, "US_East" region, digital resource ID, human-readable label or name), and algorithms corresponding to a resource (e.g., a software resource), and can be used to uniquely and idempotently generate identifiers for the resource. Therefore, a resource identifier descriptor contains sufficient information to create or retrieve a unique identifier for any resource within a region.

[0045] "Artifacts" refer to code deployed to infrastructure components or Kubernetes engine clusters, which can include software (e.g., applications), configuration information (e.g., configuration files), credentials, etc., for infrastructure components.

[0046] IaaS provisioning (or "provisioning") refers to acquiring a computer or virtual host for use, and even installing necessary libraries or services on it. The phrase "provisioning device" refers to the state in which a device is evolved to the point where an end user can use it for their specific purpose. A device that has undergone provisioning can be called a "provisioned device." Preparing a provisioned device (installing libraries and daemons) can be part of provisioning; this preparation is different from deploying a new application or a new version of an application to a prepared device. In most cases, deployment does not include provisioning, and provisioning may need to be performed first. Once ready, the device can be called an "infrastructure component."

[0047] IaaS deployment (or "deployment") refers to the process of providing and / or installing new applications or new versions of applications on provisioned infrastructure components. Once the infrastructure components have been provisioned (e.g., acquired, assigned, prepared, etc.), additional software can be deployed (e.g., provided to and installed on the infrastructure components). After provisioning and deployment are complete, the infrastructure components may be referred to as "resources" or "software resources." Examples of resources may include, but are not limited to, virtual machines, databases, object storage, block storage, load balancers, etc.

[0048] A Virtual Boot Environment (ViBE) is a virtual cloud network provisioned within the coverage of an existing zone (e.g., a "host zone"). Once provisioned, the ViBE connects to the new zone using a communication channel (e.g., an IPSec tunnel VPN). Certain essential core services (or "seed" services), such as deployment orchestrators, public key infrastructure (PKI) services, dynamic host configuration protocol (DHCP) services, and domain name services (DNS), can be provisioned in the ViBE. These services provide the capabilities needed to bring hardware online, establish a chain of trust to the new zone, and deploy the remaining services in the new zone. Utilizing a Virtual Boot Environment can prevent circular dependencies between boot resources by leveraging the resources of the host zone. These services can be staged and tested in the ViBE before a pre-provisioned zone (e.g., a target zone) becomes available.

[0049] "Manager service" can refer to a service configured to manage the provisioning and deployment operations of any appropriate number of services as part of a prefabricated region build. The manager service can be used in conjunction with one or more additional prefabrication services to orchestrate region builds in a prefabrication plant and to manage how prefabricated regions are installed and configured at their destination data center after they have been built and shipped. The manager service and other prefabrication services can be hosted in an existing region of the CSP.

[0050] "Host Zone" refers to the zone that hosts the Virtual Boot Environment (ViBE). The host zone can be used to boot the ViBE.

[0051] A "target area" refers to the area being built in the prefabrication plant. During the construction of the prefabricated area, the target area is associated with the physical space, power, and cooling provided by the prefabrication plant. After guidance, once the prefabricated area has been transported to its destination data center, it becomes associated with the destination data center where it is installed.

[0052] Prefabricated area construction

[0053] In some examples, this paper describes technologies for building regions at a prefabrication plant. As briefly described above, such technologies may include one or more prefabrication services (e.g., manager services, network services, inventory services, testing services, deployment orchestration systems) hosted by a CSP that manages and bootstraps infrastructure components (e.g., provisioning and deploying software) for one or more regions within the prefabrication plant. The prefabrication plant can be configured to support multiple region builds simultaneously. For example, the physical resources (e.g., server racks, network switches, etc.) of a first prefabrication region may be installed at one location within the prefabrication plant, while the physical resources of a second prefabrication region may be installed at a second location within the prefabrication plant. Each prefabrication region may connect to a dedicated network fabric within the prefabrication plant to provide independent networking connectivity to each region, enabling each region to communicate with prefabrication services and / or other cloud services to support region builds. Based on the build request (regional specifications, such as the number of server racks for the region, the number of computing devices, the number and types of services to be hosted in the region, the region's network topology, etc.), the prefabrication service can generate instructions to install the corresponding physical infrastructure in the prefabrication plant (e.g., by plant personnel). This can include networking physical devices together on their racks, positioning the racks at locations within the prefabrication plant, and establishing a static network structure for connecting devices to the prefabrication plant. The manager service can then orchestrate the provisioning of the regional infrastructure and the deployment of software resources to the prefabricated regional infrastructure, configure the prefabricated regional infrastructure for transport, manage (e.g., schedule and monitor) the transports within the prefabricated region, and perform testing and verification of the prefabricated region once it reaches its destination site.

[0054] Prefabrication plants can centralize region building processes for more efficient use of compute and networking resources that support region building. For example, a prefabrication plant can be located “proximity” (e.g., with low-latency and high-data-rate networking connectivity) to a host region that includes prefabrication services and / or ViBE. Multiple regions can be built using the improved performance of network connectivity to the host region, thus avoiding potentially poor performance when performing region building on newly constructed data center sites for typical region building. Because the CSP can control the prefabrication plant and its network connectivity, the prefabrication plant also provides improved physical and compute security for equipment during region building.

[0055] Furthermore, the prefabrication plant improves the management of physical component inventory. The manager service can determine which computing devices are needed for building a specific region, and these devices can be stored at or near the prefabrication plant. As regions are built and shipped, the infrastructure for new regions can be quickly moved to the prefabrication plant and installed, thus improving efficiency.

[0056] Now turn to the attached diagram. Figure 1 This is a block diagram illustrating a prefabrication system 100 according to at least one embodiment. The prefabrication system 100 includes a prefabrication plant 102 for constructing regions (e.g., prefabricated region 106A, prefabricated region 106B, prefabricated region 106C) and preparing region computing devices for delivery to a target data center (e.g., data center 108, data center 110). Each region constructed in the prefabrication plant 102 may include one or more devices forming the computing environment of the data center. The prefabrication plant 102 can be used to construct multiple regions simultaneously. For example, the prefabrication plant 102 can construct all of prefabricated regions 106A, 106B, and 106C simultaneously. In some examples, the devices of the regions can be installed and temporarily stored in the prefabrication plant 102 prior to the commencement of infrastructure provisioning and software deployment operations.

[0057] Prefabrication plant 102 can be a data center-like facility, including sufficient power, cooling, and networking infrastructure to support the construction of one or more regions. Prefabrication plant 102 can be located near the existing computing infrastructure of a CSP (e.g., CSP 104). For example, CSP 104 can operate an existing data center for one or more regions. Prefabrication plant 102 can be located near, or even adjacent to, the existing data center in the host region to provide high-data-rate network connectivity between the CSP's cloud services and the computing equipment in the regions being built in prefabrication plant 102. Additionally or alternatively, prefabrication plant 102 can be positioned to improve logistics operations, including shipping regions to destination data centers.

[0058] The prefabricated areas constructed in prefabrication plant 102 can include any suitable number of physical resources, including computing devices (e.g., servers, multi-server racks, etc.), storage devices (e.g., block storage devices, object storage devices, etc.), networking devices (e.g., switches, routers, gateways, etc.). Each area may have different physical resources depending on the specific requirements of the destination area and data center. For example, prefabrication area 106A may include 100 racks, each with 40 computing devices, while prefabrication area 106B may include 20 racks, each with 30 computing devices. Each rack of computing devices may include one or more networking devices that are communicatively connected to the server devices on the rack and configured to connect to the networking infrastructure of prefabrication plant 102 to form a network with other computing devices in the prefabrication area. Each rack may also include power and cooling equipment to support the operation of the computing devices on the rack.

[0059] Prefabrication plant 102 may include any suitable number of networking devices to support the installation and connection of one or more computing devices in the prefabricated area being built. For example, prefabrication plant 102 may include any suitable number of leaf-ridge switches to support the connection of computing devices on multiple racks to form a network for the prefabricated area. Similarly, prefabrication plant 102 may include network cables installed in the facility that provide network connectivity to the networking infrastructure of prefabrication plant 102. Network cables may be positioned to terminate at locations within prefabrication plant 102 where racks for installing computing devices for the prefabricated area can be installed during the area building operation. Additional details regarding the networking infrastructure and configuration of the prefabrication plant are provided below. Figures 9-11 supply.

[0060] Prefabrication plant 102 can connect to services provided by CSP 104 via one or more networks. During the region build operation, CSP 104 can provision infrastructure components on the physical resources of the prefabrication region and deploy software resources, configurations, and / or other artifacts to the supplied infrastructure components. For example, CSP 104 can provision computing devices in prefabrication region 106A to host one or more virtual machines, provide hostnames, network addresses, and other network configurations for the supplied physical and virtual devices, and then deploy one or more services to execute on the supplied infrastructure. This allows the prefabrication region to approach a state close to the final production state of the equipment when it is installed at the destination facility.

[0061] Once the prefabrication area has been constructed, physical resources can be configured for transfer / transport to the destination facility. As used herein, the term "transfer" may be used synonymously with the term "transport" in the context of moving physical resources associated with a prefabrication area from the prefabrication plant to the destination site. Configuring a prefabrication area for transfer may include obtaining a "snapshot" of the current network configuration of the computing devices in the prefabrication area, storing the snapshot, providing each computing device with a portion of its identifier, including each device and its neighboring devices within the network, encrypting the data volumes of the computing devices, and configuring the devices to boot into a test state upon power-up after the transfer. In addition to network snapshots, CSP 104's prefabrication service can also capture device snapshots, which are disk images of the individual switches, computing devices, and smart NICs fully configured in the various racks to be transported to the destination site. Device snapshots enable rapid replacement of any device in the racks that have been transported but are not functional upon arrival. Transport to the destination facility may be achieved through one or more methods, including by truck 112 or by airplane 114. For example, prefabricated area 106B can be configured to be delivered to data center 108 by truck 112, while prefabricated area 106C can be configured to be delivered to data center 110 by aircraft 114.

[0062] Once the computing equipment in the prefabricated area arrives at the destination facility, it can be installed there according to the facility's configuration. The destination facility may be a data center already built to host the prefabricated area equipment, with networking, power, cooling, and other infrastructure provided according to the prefabricated area's configuration. The data center may have a network connection to CSP 104. The installation of the prefabricated area may include manual operations for connecting racks and their computing equipment to the data center's network infrastructure, as well as other related tasks. Once the physical connection is complete, the equipment in the prefabricated area can be powered on, which may initiate one or more test operations based on the configuration performed at the prefabrication plant 102 prior to transmission. The prefabricated area may also connect to CSP 104 via one or more network connections to the data center to communicate with the prefabrication service. For example, prefabricated area 106B may connect to CSP 104 via connection 118, while prefabricated area 106C may connect to CSP 104 via connection 116. The prefabrication service may deploy the final configuration for the installed equipment, deploy updates to software resources on the installed equipment, and perform additional testing and verification operations on the prefabricated area at the destination data center.

[0063] Figure 2This is a block diagram illustrating a prefabrication system 200 according to at least one embodiment, the prefabrication system 200 including a prefabrication plant 202 connected to a prefabrication service 210 for building areas provided by a CSP 204. The prefabrication plant 202 may be... Figure 1 An example of prefabrication plant 102, and CSP 204 can be Figure 1 An example of CSP 104. Prefabrication plant 202 may interface with CSP 204 via network 208, which may be a public network (such as the Internet), a private network, or another network. Prefabrication service 210 may include manager service 212, inventory service 214, test service 216, orchestration service 218, and network service 220. Prefabrication service 210 may perform operations corresponding to building prefabricated region 206 in prefabrication plant 202, including managing boot environments (e.g., ViBE 222), supplying infrastructure components in prefabricated region 206, deploying software resources to prefabricated region 206, configuring the network of prefabricated region 206, testing the prefabricated region at various points during the build process, and managing the physical inventory (e.g., physical inventory 224) of computing devices used to build prefabricated region 206 and other prefabricated regions built in prefabrication plant 202.

[0064] Manager service 212 can perform tasks for coordinating the operations of prefabrication service 210, including scheduling prefabrication area construction operations of other prefabrication services 210, generating physical build requests and corresponding instructions, initiating the delivery of prefabrication area 206 to the destination site, and managing the provisioning and deployment of resources in prefabrication area 206 at both the prefabrication plant 202 and the destination site. Physical build requests can specify the quantity and type of physical resources to be used in prefabrication area 206. Physical build requests can also include a set of instructions for personnel to install the corresponding physical resources in prefabrication plant 202. For example, manager service 212 can generate a physical build request specifying the number of racks and server devices for prefabrication area 206, the number of networking devices that can be used to connect the server devices to form a network for prefabrication area 206, and determining a connection plan for the specified server devices, networking devices, and the existing networking infrastructure of prefabrication plant 202. The physical build request may also include instructions to enable personnel to obtain physical equipment from an associated location (e.g., physical inventory 224), and instructions to install the equipment at a specified location in the prefabrication plant 202. In some embodiments, the operation of the physical build request may be performed by an automated system under the control of the manager service 212. For example, obtaining racks of server equipment from physical inventory 224 and installing the racks at the prefabrication plant 202 may be performed by a robotic system configured to move physical racks from the site to the site.

[0065] Inventory service 214 can be configured to track and monitor physical devices corresponding to one or more regions (e.g., one or more data centers within a region). Inventory service 214 can also track physical devices in one or more prefabrication zones (e.g., prefabrication zone 206) within prefabrication plant 202. Tracking and monitoring physical devices may include maintaining an inventory of devices based on device identifiers (e.g., serial numbers, device names, etc.) and the association of devices with data centers. Inventory service 214 can provide inventory information to other prefabrication services 210 (including manager service 212) for use in the prefabrication zone construction process. For example, inventory service 214 can determine whether a physical device is located at prefabrication plant 202 or at a destination site. Inventory service 214 can query devices via a network (e.g., network 208) to determine their location and / or association with a region, prefabrication zone, or data center. Inventory service 214 can also maintain a physical inventory (e.g., physical inventory 224) of devices stored for use in prefabrication zone construction operations. For example, inventory service 214 can track physical devices as they are received at physical inventory 224 and then retrieved from physical inventory 224 for use as part of a prefabrication area at prefabrication plant 202. In some examples, inventory service 214 can provide inventory information to manager service 212, which can be used to generate a physical build request for prefabrication area 206, including instructions for obtaining physical resources from physical inventory 224 and installing the physical resources at prefabrication plant 202.

[0066] Physical inventory 224 may be a warehouse or storage facility for storing physical resources (e.g., computing devices) used in prefabrication area construction operations. Physical inventory 224 may be located near prefabrication plant 202 to facilitate the retrieval of physical resources based on physical construction requests. For example, physical inventory 224 may be a building adjacent to the building used for prefabrication plant 202. In some examples, physical inventory 224 may be located within prefabrication plant 202. Personnel associated with the CSP and prefabrication plant 202 may place physical resources into and retrieve them from physical inventory 224. In some cases, during prefabrication area construction operations, physical resources may be retrieved and installed from physical inventory 224 using instructions provided by the physical construction request via robots, automated guided vehicles, or other similar autonomous or semi-autonomous systems.

[0067] Orchestration service 218 can be configured to perform bootstrapping operations to provision infrastructure components and deploy software resources to prefabrication zone 206. Orchestration service 218 can also construct boot environments (e.g., ViBE 222) for use when bootstrapping resources to prefabrication zone 206. Orchestration service 218 can be an example of the deployment orchestrator described above. In some examples, orchestration service 218 can be configured to boot (e.g., provision and deploy) services to prefabrication zones (e.g., prefabrication zone 206) based on predefined profiles that identify resources (e.g., infrastructure components and software to be deployed) used to implement a given change to the prefabrication zone. Orchestration service 218 can parse and analyze the profiles to identify dependencies between resources. Orchestration service 218 can generate specific data structures based on the analysis and can use these data structures to drive operations and manage the order in which services are bootstrapped to zones. The orchestration service 218 can use these data structures to identify when it can bootstrap services, when bootstrap is blocked, and / or when bootstrap operations associated with previously blocked services can be resumed.

[0068] In some embodiments, orchestration service 218 may include components configured to perform bootstrapping tasks associated with a single service in a prefabricated region. Orchestration service 218 may maintain current state data indicating any suitable aspects of the current state of resources associated with the service. In some embodiments, desired state data may include a configuration of the desired state of resources associated with the service, declared (e.g., via declarative statements). In some embodiments, orchestration service 218 may identify changes required for one or more resources by comparing desired state data with current state data. For example, orchestration service 218 may determine any suitable changes required to resources of the service to procure one or more infrastructure components, one or more deployed artifacts, or to bring the state of resources of the service into alignment with the desired state. Specific details regarding particular implementations of orchestration service 218 are provided in U.S. Patent Application No. 17 / 016,754, entitled “Techniques for Deploying Infrastructure Resources with a Declarative Provisioning Tool,” the entire contents of which are incorporated herein by reference for all purposes.

[0069] ViBE 222 can be an example of a bootstrap environment that can be used to deploy resources to a prefabrication area in prefabrication plant 202. ViBE can include a virtual cloud network (e.g., a network of cloud resources) implemented in a suitable area of ​​a CSP (e.g., CSP 204). ViBE can have one or more nodes (e.g., compute nodes, storage nodes, load balancers, etc.) to support the operation of services hosted by orchestration service 218. ViBE services can then be used to support the deployment of services to prefabrication area 206. For example, orchestration service 218 can deploy instances of one or more component services of orchestration service 218 to a bootstrap environment (e.g., an instance of orchestration service 218), which can then be used to deploy resources from ViBE 222 to prefabrication area 206. Because ViBE is implemented as a virtual cloud network in an existing area, any suitable amount of regional infrastructure can be provisioned to support services deployed within ViBE (compared to the fixed hardware resources of a seed server). In addition to deploying software resources to ViBE 222, orchestration service 218 can also be configured to supply infrastructure resources (e.g., virtual machines, compute instances, storage devices, etc.) to ViBE 222. ViBE 222 can simultaneously support boot operations for more than one prefabrication zone in prefabrication plant 202.

[0070] When prefabricated region 206 is available to support bootstrapping operations, ViBE 222 can connect to prefabricated region 206 so that services in ViBE 222 can interact with services and / or infrastructure components in prefabricated region 206. This enables the deployment of production-grade services, rather than deploying self-contained seed services as in previous systems, and will require internet connectivity to the target region. Typically, seed services are deployed as part of a collection of containers and used to bootstrap the dependencies required to build the region. Using existing region infrastructure / tools operations, resources can be bootstrapped into ViBE 222 and connected to prefabricated region 206 to provision hardware and deploy services until prefabricated region 206 becomes self-sufficient (e.g., self-sufficient with respect to services hosted within prefabricated region 206). Utilizing ViBE 222 allows the establishment of dependencies and services necessary to provision / prepare infrastructure and deploy software, while using resources from the host region to break circular dependencies in core services.

[0071] Test service 216 can be configured to perform one or more test or verification operations on prefabricated region 206 after resource provisioning and / or deployment. Test operations can be part of user-accepted testing used to determine whether the behavior of the prefabricated region conforms to the build specifications. For example, test service 216 can perform tests that interact with instances of services deployed to prefabricated region 206 to verify the expected operation of the queried service. As another example, test service 216 can perform networking tests to obtain the hostname, networking address, and / or other identifiers of components in prefabricated region 206, and compare them with the expected identifiers of components as specified in the build request or other specifications for prefabricated region 206. Test service 216 can perform test operations during the prefabricated region build process at prefabricated plant 202 and after prefabricated region 206 is delivered to the destination site. Test operations performed at prefabricated plant 202 can be the same as or different from test operations performed after prefabricated region 206 is delivered to the destination site.

[0072] Manager service 212 can obtain inventory information from inventory service 214 for use when generating physical build requests. For example, manager service 212 can use the inventory information to determine which physical resources to install in the prefabrication plant 202 for the prefabrication area corresponding to the physical build request.

[0073] Figure 3 This is a diagram illustrating a CSP system 300, according to at least one embodiment, for managing the network configuration of computing resources for a prefabrication zone 330 under construction in a prefabrication plant 302 using a manager service 312 and a network service 320. The prefabrication plant 302 and prefabrication zone 330 may be examples of other prefabrication plants and prefabrication zones described herein, including... Figure 2 The prefabrication plant 202 and prefabrication area 206. Prefabrication services 310 can be provided by CSP and can be as described above. Figure 2 Examples of prefabricated services 210 described include, as Figure 2 The example of Manager Service 212 and Manager Service 312 as Figure 2 Example of network service 220 is network service 320.

[0074] As mentioned above Figure 2As described, the manager service 312 can perform tasks for coordinating the operations of the prefabrication service 310, including scheduling prefabrication zone construction operations performed by other prefabrication services 310, generating physical construction requests and corresponding instructions, and configuring the prefabrication zone 206 for delivery to the destination site. The physical construction request can specify the quantity and type of physical resources to be used in the prefabrication zone 206. The network service 320 can use configuration information from the construction request to determine the network topology of devices (e.g., servers, networking devices, racks of servers and networking devices, etc.). After the provisioning of infrastructure components in the prefabrication zone 330, the network service 320 can also determine the network configuration of the devices in the prefabrication zone 330.

[0075] In some examples, network service 320 may store a snapshot of the network configuration of a prefabricated area (e.g., prefabricated area 330). The snapshot may include information about the network topology of the prefabricated area at a specific point in time, including network identifiers of devices in the prefabricated area (e.g., network addresses, hostnames, etc.), current network connections between devices, physical networking interfaces between devices and the networking infrastructure 338 of the prefabricated plant 302, and network settings for the devices (e.g., port configurations, gateway configurations, etc.). As an example, server device 336 may be a computing device in server rack 332A of prefabricated area 330. Server device 336 may have a networking connection 340 to a switch 334 of server rack 332. Thus, the network configuration of prefabricated area 330 may include information associating server device 336 with switch 334, including specifying the type of network connection 340, the port of switch 334 to which server device 336 is connected, and the settings of server device 336 and switch 334 corresponding to the networking connection 340 between server device 336 and switch 334. Furthermore, the network configuration may include information associating server device 336 with “neighboring” devices in prefabricated area 330 that have networking connections 342, 344 between them. Network connections 342 and 344 may be via switch 334 so that server device 336 can communicatively connect to other devices in server rack 332A via network connections 342, 344. In some examples, “neighboring” devices for a given device in prefabricated area 330 may include each computing device on the same server rack. Additionally, switch 334 may have network connections to one or more other switches within prefabricated area 330 (e.g., network connection 346 to a switch in server rack 332B).

[0076] Network snapshots can be used to verify the physical installation (e.g., physical networking connectivity) of prefabricated area 330 after devices are installed at the destination site. For example, network service 320 can provide a network snapshot (or a portion of a snapshot) to each device in prefabricated area 330 as part of configuring prefabricated area 330 for transport to the destination site. For example, network service 320 can provide network snapshot 326 to server device 336 for storage at server device 336. Network snapshot 326 can be a portion of a network snapshot corresponding to the network configuration of the entire prefabricated area 330. Network snapshot 326 may include an identifier for server device 336 (e.g., network address, hostname, etc.) and information associating server device 336 with one or more other devices in prefabricated area 330. Information associating server device 336 with neighboring devices may include identifiers of the neighboring devices and information about network connections between them. For example, server device 336 can use network snapshot 326 to identify neighboring devices and communicate with them via network connections.

[0077] Network service 320 can also maintain the network configuration of the network structure of prefabrication plant 302. For example, prefabrication plant 302 may have networking infrastructure to support the simultaneous construction of multiple separate prefabrication areas. Prefabrication plant 302 may have multiple dedicated locations for placing server racks for the prefabrication areas being constructed. Each location may have a set of networking cables for the networking infrastructure, which terminates at a location that can be connected to a server rack. Based on the device placed at that location, specific cables from that set of networking cables can be connected to the device (e.g., to a switch at the top of the rack) to connect the device to other devices in the prefabrication area using a portion of the network structure of prefabrication plant 302. For example, server rack 332A may be placed at a location within prefabrication plant 302 and connected to networking infrastructure 338 using switch 334, while server rack 332B may be placed at a second location and connected to networking infrastructure 338.

[0078] In addition to operations for storing the network configuration of prefabricated area 330, configuring prefabricated area 330 for transport to the destination site may also include manager service 312 configuring each device to enter a test state during subsequent power-on of the device, encrypting the device's data volume with an encryption key, storing the encryption key at a device that can act as a key server for prefabricated area 330 during initialization at the destination site, and configuring one of these devices to act as a Dynamic Host Configuration Protocol (DHCP) server during the initialization of prefabricated area 330 at the destination site. Manager service 312 may also generate instructions for use by personnel or robotic systems associated with prefabrication plant 302 for packaging devices for transport. Manager service 312 may also generate instructions for use by personnel associated with the destination facility for installing and connecting devices at the destination facility.

[0079] In some embodiments, the device configuring prefabrication area 330 may also include operations for capturing device snapshots of each device. Device snapshots may include software images of one or more disk drives or other storage of a computing device, which can be used to copy the device's software configuration to a replacement device. Manager service 312 may generate device snapshots in conjunction with one or more of the prefabrication services 310. Device snapshots may be stored in a database or data repository (e.g., one or more snapshots 324) along with network snapshots(s). As a specific example, manager service 312 may generate device snapshot 352 of server device 350 of prefabrication area 330 at prefabrication plant 302. Device snapshot 352 may be used to image another physical device with the same or similar physical configuration as server device 350 to create a copy of the server device in the event of failure of server device 350 (e.g., damage or loss during transport to the destination site).

[0080] Figure 4 This is a diagram illustrating a CSP system 400, according to at least one embodiment, for testing and evaluating a prefabricated area 330 after delivery to a destination site 402 using a manager service 412 and a test service 416. The destination site 402 may be a data center facility located corresponding to a new area deployed for the CSP using the computing resources of the prefabricated area 430. The prefabrication service 410 may be provided by the CSP and may be similar to... Figure 2 The pre-built service 210 includes a manager service 412 as an example of a manager service 212, a test service 416 as an example of a test service 216, and a pre-built service 416 as an example of a test service 216. Figure 2 The example of orchestration service 218 is orchestration service 418.

[0081] Transporting the prefabricated area 330 to the destination site 402 may include powering off each device, disconnecting the devices from the prefabrication plant's networking infrastructure, and appropriately packing the devices as needed for transport. Server racks (e.g., server racks 332A, 332B) can be transported intact without disconnecting the individual devices within the racks. Once delivered to the destination site 402, the server racks can be placed in the destination site 402 according to the resulting data center's physical layout and connected to the destination site's networking infrastructure 438. For example, a networking connection can be established between the networking infrastructure 438 and the switches of server racks 332A, 332B by connecting one or more networking cables to a switch (e.g., switch 334).

[0082] As described above, the devices in prefabrication zone 330 may have been configured to boot into test mode upon first power-on at destination site 402. In some embodiments, the devices may have a dedicated boot volume to support test mode during initialization at destination site 402. In other embodiments, the boot volume may be configured on an external device connected to each device in prefabrication zone 330. For example, each server device (e.g., server device 336) may be connected to a SmartNIC that provides a low-overhead boot volume that can be used to boot the server device into test mode. Because the boot volume can be used solely to support test mode, the data on the boot volume may not need to be encrypted like the data volume on the server device.

[0083] The test mode can be configured to allow each computing device to verify its connectivity with other devices in prefabricated area 330. This verification determines whether the physical network connection between the device and the networking infrastructure 438 at destination site 402 is correctly established. To verify the connection, devices in test mode can use stored network configurations or network services (e.g., Figure 3 Network service 320 identifies and stores a portion of the network configuration at each device. For example, server device 336 can use network snapshot 326 to identify nearby computing devices that are communicatively connected to server device 336 via network connection 342. To verify network connection 342, server device 336 can send a verification request to the nearby computing device. If network connection 342 is intact, the server device can receive a verification indication from the nearby computing device indicating that the verification request was successfully received at the nearby computing device. Server device 336 can verify all connections specified in network snapshot 326. Similarly, devices on a server rack (e.g., server rack 332A) can verify connections to each other server rack (e.g., server rack 332B) in prefabricated area 330.

[0084] In some embodiments, a device in prefabricated area 330 may be configured to act as a DHCP server (e.g., DHCP server 446). DHCP server 446 may provide network addresses or other identifiers to devices in prefabricated area 330 during initialization. For example, during test mode, each device may verify its connection to DHCP server 446 and then receive addresses, identifiers, or other network configuration information from DHCP server 446. The device may compare the received identifiers with identifiers included in the network configuration generated by a network service during the prefabricated area construction operation at the prefabrication plant. For example, server device 336 may receive identifiers from DHCP server 446 and then compare the received identifiers with identifiers in network snapshot 326. Because prefabricated area 330 should not undergo any component changes during transport, the network configuration of prefabricated area 330 at destination site 402 should remain unchanged, including the configuration information from DHCP server 446. That is, the server device in the prefabricated area should receive the same network address from DHCP server 446 after the installation of the device at destination site 402. If the network configuration changes, the server device may indicate that the network configuration of prefabricated area 330 may be incorrect.

[0085] In some embodiments, if any device is damaged and no longer functions properly during transport, an operator at the destination site can replace the damaged device with a new replacement device and configure the new device using a snapshot of the device taken before transport, thus allowing successful verification after on-site installation even in the event of hardware failure during transport. For example, server device 350 may be damaged during transport to destination site 402. A non-functional state of server device 350 may be discovered during test operations used to verify the network configuration of prefabrication area 330. To recover, manager service 412 can generate instructions to replace server device 350 with the same physical device located at the same location on server rack 332B. Once the replacement device is installed, manager service 412 can deploy device snapshot 352, generated during the prefabrication area construction operation in prefabrication plant 302. Deploying device snapshot 352 may include imagerizing one or more disk drives or other storage devices of the replacement server device to make the replacement server device have the same software configuration as server device 350 in prefabrication area 330 before transport to destination site 402. Other devices (including networked devices such as switch 334) can similarly use captured device snapshots to be replaced and restored.

[0086] DHCP server 446 can perform test mode verification operations similar to those of other devices within the prefabricated area 330. If DHCP server 446 can successfully verify the network connection between itself and a neighboring device, then DHCP server 446 can exit test mode and begin operating as a DHCP server for other devices within the prefabricated area 330. In some embodiments, DHCP server 446 can complete its test mode verification operation before other devices in the prefabricated area 330 complete their test mode verification operations. For example, server device 336 can boot into test mode and attempt to verify its network connection with DHCP server 446 before verifying its own network connection 342 or network connection 344 with a neighboring computing device. DHCP server 446 may not send a verification instruction to server device 336 until DHCP server 446 has completed its own test mode verification operation. Server device 336 can then wait for a predetermined amount of time and retry the verification request to DHCP server 446. Similarly, other computing devices performing test mode verification operations can wait and retry verification requests until DHCP server 446 is operational.

[0087] As described above, the data volumes of devices in prefabrication zone 330 can be encrypted before being transported to destination site 402. An encryption key used to encrypt the data volume of each device can be associated with that specific device. Encryption key 444 can be stored in one of the computing devices in prefabrication zone 330 configured to act as a key server for prefabrication zone 330 during initialization (e.g., stored at key server 442). Encryption key 444 itself can be encrypted by a master key. In some embodiments, encryption key 444 can be protected by a hardware security module (e.g., a trusted platform module (TPM)). This hardware security module can be part of key server 442 or can be part of another device connected to key server 442 (e.g., a SmartNIC, an external security device, etc.). In some embodiments, the master key or external security device can be delivered separately from prefabrication zone 330 to destination site 402 (e.g., by an operator) and provided to key server 442 or installed at key server 442 as part of the installation operation for prefabrication zone 330. Key server 442 can perform test mode verification operations similar to those of other computing devices in prefabricated area 330. If the test mode verification operation completes successfully, key server 442 can begin providing encryption key 444 to other computing devices in the prefabricated area to decrypt data volumes. For example, key server 442 can receive a key request from server device 336. In response, key server 442 can decrypt the data volume storing encryption key 444 (e.g., via a master key, via a hardware security module), retrieve the encryption key corresponding to server device 336, and send that encryption key to server device 336.

[0088] Once prefabricated region 330 has been installed and initialized at destination site 402 (e.g., the device boots into normal operating mode, the data volume is decrypted, and services deployed during the prefabricated region construction operation at the prefabrication plant are executing), test service 416 can perform one or more acceptance tests. Acceptance tests may include verifying that all services are functioning as expected. For example, test service 416 may interact with the services executing at prefabricated region 330 to verify that the service is operating according to the requirements defined for the acceptance test. Test service 416 may provide the results of the acceptance tests to manager service 412, indicating that the prefabricated region construction is complete.

[0089] During the transport of prefabricated area 330 to destination site 402, updates or other changes can be specified for one or more infrastructure components and / or software resources already supplied and / or deployed to prefabricated area 330 at the prefabrication plant. For example, services may be updated to a newer version during transport. Before the prefabrication area construction operation is completed, orchestration service 418 can deploy the updated software resources to prefabricated area 330 at destination site 402. Deploying updated software resources can occur similarly to deploying software resources to prefabricated area 330 at the prefabrication plant.

[0090] Role rotation

[0091] Software resources within a regional network (e.g., services, virtual machines, databases, object storage, compute instances, load balancers, etc.) can have a unique identifier assigned during a regional build operation. For example, the identifier can be a numeric identifier, a universally unique identifier (“UUID”), or another similar label that uniquely corresponds to the resource in the compute environment in which it is executed. In some examples, the identifier can be a key in a database of records describing the software resources in the compute environment. In addition to unique identifiers, software resources can also be associated with other identifiers, including human-readable labels (e.g., resource names). A human-readable label may not be globally unique, but it may uniquely identify the associated software resource within a particular local compute environment. For example, in the context of a regional build operation, a human-readable label may uniquely identify a software resource within a regional network in a domain, but the same human-readable label may be used in different domains containing different regional networks.

[0092] Identifiers can be provided to software resources by a service that can be configured to create, look up, retrieve, and return identifiers. This identity service can be configured to support application programming interface (“API”) calls to generate guaranteed unique identifiers using attributes and attribute values ​​associated with the corresponding software resource. The identity service can be configured to use one or more algorithms to generate identifiers. Algorithms may include methods for constructing a namespace string that identifies the software resource and methods for hashing the namespace string to produce a hashed identifier. This set of attributes, values, and algorithms can be a resource identifier descriptor. For example, an identifier can be constructed to include... <type> . <realm> . <region> . <uuid>The string, where the fields within angle brackets can be labels of associated data (e.g., the type of software resource, such as "VM" for a virtual machine, domain name, region name, etc.) or unique numeric or alphanumeric values ​​(e.g., UUIDs), which can be constructed by hashing other components of the string and appending them, or by hashing other attributes and values ​​associated with the resource. Hash processing can be performed by any suitable algorithm used to generate the hash value (e.g., cryptographic hash algorithms such as SHA, message digest algorithms such as MD5, digital signature algorithms, etc.). The configuration of the identity service ensures that calls to the request identifier are idempotent, such that a request identifier using a set of input parameters (e.g., attributes, namespaces, human-readable labels, etc.) returns the same identifier as a second request using the same set of input parameters. As defined above, a "service" can refer to functionality provided by a set of resources, typically in the form of an API that a client can invoke to achieve some useful result. Therefore, an identity service can include a set of resources, which is any suitable combination of infrastructure, platform, or software (e.g., applications) hosted within a computing system. For example, identity services may include one or more processes executed by one or more processors of a computing system to provide the aforementioned API(s).

[0093] In prefabrication plants (e.g., Figure 3 When a regional network is built at a prefabrication zone 330 in prefabrication plant 302, software resources deployed within the regional network can be assigned identifiers based on the "zone" and "domain" configuration of the prefabrication plant. For example, an identity service within the regional network can provide an identifier for each software resource deployed during the zone build operation. Furthermore, these software resources can each have associated human-readable tags or other non-globally unique tags that can be resolved into unique identifiers by the identity service. The identifiers generated by the identity service can be cached by the requesting service and / or the associated software resource. When a service needs an identifier for a software resource, it can look up the cached identifier instead of invoking the identity service. After the regional network has been built, physical resources (e.g., servers, server racks, switches, etc.) can be delivered to the destination site and configured to form a regional network within the data center at the destination site, as part of a new zone within a new domain. As a result, the identifiers created for software resources within the prefabrication plant (e.g., in the first region / domain) will not be compatible with the identifiers when the same resource is executed at the destination site (e.g., in the second region / domain), and the cached identifiers may not function correctly to uniquely identify software resources in the new region / domain.

[0094] To avoid the aforementioned issues during prefabricated region building, the identity service can be configured to rotate identifiers used during region building operations at the prefabricated factory to identifiers that correctly and uniquely identify the deployed software resources in the regional network at the destination site (e.g., at the destination region and / or destination domain). To perform identity rotation, the identity service can prevent nodes within the regional network from caching identifiers returned by the identifier service based on calls during bootstrapping operations at the prefabricated factory. The identity service can also enforce additional policies to ensure correct identifier rotation at the destination site. For example, the identity service can enforce a no-duplicates policy for human-readable labels within the prefabricated regional network, ensuring that these labels are not duplicated within the prefabricated regional network (e.g., locally unique). By doing so, the identity service can limit namespace conflicts between individual software resources until those resources are assigned appropriate unique identifiers compatible with the regional network after installation at the destination site. Once identity rotation is complete, the identity service can relax this policy and allow duplicate human-readable labels to be used for the software resources.

[0095] The identity rotation technique described in this paper offers numerous advantages over conventional methods of establishing resource identifiers in newly built data center environments. For example, prefabricated regional networks can be built without prior knowledge of the network configuration attributes at the destination site, allowing resources to be deployed and tested in an operational computing environment ahead of time at the prefabrication plant. Identity rotation can be achieved through configuration changes to a single service (e.g., an identity service) that detects when the regional build bootstrapping process completes and generates identifiers compatible with the network environment of the destination site, reducing the number of manual configuration changes required to update software resource identifiers. Furthermore, identity rotation is not limited to prefabricated regional build processes and can be used to modify software resources deployed in one region / domain to simulate those resources operating in another region / domain, facilitating resource evaluation without requiring reconfiguration of entire domains, regional networks, or data center facilities.

[0096] Figure 5 This is a block diagram illustrating an identity service 514 for identifier management provided in a local area network 504 according to at least one embodiment. The local area network 504 may be... Figure 3 The example is a prefabricated area 330, while data center 502 can be a facility suitable for hosting area network 504. For example, data center 502 could be... Figure 3 An example of a prefabrication plant 302. In some embodiments, data center 502 may be a data center in a production area, wherein identity service 514 can provide identifier generation / lookup operations for resources within regional network 504, such as when performing identity rotation techniques for a regional network outside the prefabrication area's construction context. Prefabrication service 510 may be an example of other prefabrication services described herein, including Figure 4 Prefabricated service 410. Prefabricated service 510 may include manager service 512. Manager service 512 may be an example of other manager services described herein, including... Figure 2 The manager service 212 can be configured to orchestrate the aforementioned prefabrication operations and instruct the identity service 514 to initiate identity rotation operations as described below. The prefabrication service 510 can be connected to the regional network 504 in the data center 502 via network 508, which can be... Figure 2 Example of network 208.

[0097] like Figure 5 As shown, regional network 504 can be built during a prefabrication regional construction operation at data center 502 (e.g., a prefabrication plant). During the regional construction operation, infrastructure resources, including software resources, can be deployed to regional network 504. Software resource 522 can be deployed to client node 520. As an example, software resource 522 can include an application or part of an application running on a virtual machine that is client node 520. As another example, software resource 522 can be a load balancer that provides traffic routing within the regional network, wherein the load balancer is implemented on the infrastructure of client node 520. These examples are non-limiting, and software resource 522 can be an example of several other resources deployed within regional network 504 as described above. During the prefabrication regional construction operation, software resource 522 can be assigned an identifier 526. This identifier can be a UUID or another label that uniquely identifies software resource 522 within regional network 504.

[0098] Identity service 514 can be configured to generate identifier 526 using attribute 524 corresponding to software resource 522. For example, attribute 524 may include region, domain, resource type, internal identifier (e.g., a numeric identifier for software resource 522 within client node 520, such as a process ID created by the virtual machine's operating system). Identity service 514 can expose an API to allow services and clients within area network 504 to invoke identity service 514 to retrieve a unique identifier for a resource within area network 504. API calls can be made using a resource identifier descriptor, which may include a specification of a specific algorithm used to generate the identifier or to format the resulting identifier. For example, a client within area network 504 can invoke identity service 514 and provide an internal numeric ID, resource type, name, and specify an obfuscation algorithm to generate an identifier that uniquely identifies the resource and associates its name with that identifier. As another example, a client within area network 504 can invoke identity service 514 and provide an internal numeric ID, resource type, and specify a UUID algorithm to generate a globally unique identifier. If another client within the local area network 504 invokes the identity service 514 and provides the same resource identifier descriptor, then the identity service 514 will return the same identifier as provided to any other client that makes the invocation with the same input parameters.

[0099] Cache 528 can be a storage device associated with client node 520. Client node 520 can use cache 528 to store identifiers returned by identity service 514. For example, client node 520 can obtain identifier 526 of software resource 522 using attribute 524. In production, client node 520 can store identifier 526 in cache 528. Whether an identifier can be cached is specified by identity service 514, which can also specify the period for which the identifier is retained in the cache and whether the identifier is maintained permanently. If identity service 514 instructs client node 520 to cache identifier 526, then the client node will check cache 528 before invoking identity service 514 when retrieving identifier 526 of software resource 522. During prefab area build operations (e.g., bootstrapping), as part of the identity rotation technique described herein, identity service 514 can instruct client node 520 not to cache identifier 526 in cache 528, as indicated by the dashed line. Therefore, whenever client node 520 needs to obtain identifier 526, client node 520 can invoke identity service 514. By not caching identifier 526, client node 520 can avoid storing identifiers that are unsuitable for use at the destination site or at other data centers installed after the regional build operation 504 is completed.

[0100] Figure 6 This is a block diagram illustrating the use of identifiers 618 and 638 of software resources 614 and 634 within multiple regional networks according to at least one embodiment. As briefly described above, a region may be included in a domain. A domain may be a logical collection of regions, such that user leases can be assigned to a domain and that user can access lease data and resources in various regions and associated data centers within that domain. A domain may be an attribute used to identify resources within the regional network of the domain.

[0101] like Figure 6 As shown, area 602 may include area network 1 610 and area network 2 630. Area network 1 610 and area network 2 630 may be examples of other area networks described herein, including... Figure 5 Local area network 504. Local area network 1 610 may include client node 612, which in turn may host software resource 614. Similarly, local area network 2 630 may include client node 632, which in turn may host software resource 634. Client node 612 and client node 632 may be Figure 5 Example of client node 520. Software resources 614 and 634 can be... Figure 5 Example of software resource 522. Software resource 614 can be associated with attribute 616, while software resource 634 can be associated with attribute 636. Because software resource 614 is hosted in a separate area network, attribute 616 can include values ​​different from attribute 636. For example, attribute 616 can identify area 1 of hosted area network 1 610, while attribute 636 can identify area 2 of hosted area network 2 630.

[0102] Although executed within the same area 602, software resources 614 and 634 can be associated with the same resource name 620 (e.g., a human-readable label). Resource name 620 is not required to be unique, while identifiers 618 and 638 may be required to be unique. Identity services (e.g., Figure 5 The identity service (514) can generate identifier 618 using attribute 616 and identifier 638 using attribute 636. Because attribute 616 identifies region 1 and attribute 636 identifies region 2, the identifiers generated by the identity service can be unique. The identity service can also retrieve identifiers using attributes or resource name 620.

[0103] Figure 7 This is a block diagram illustrating the creation of identifiers for software resources based on domain and region according to at least one embodiment. Identity service 700 can be configured to generate identifiers (e.g., identifier 1 716, identifier 2 718) from a set of attributes 704 and one or more algorithms (e.g., algorithm 1 712, algorithm 2 714). These attributes can be associated with software resource 710, which may be... Figure 5 Example of software resource 522. Attribute 704 may include both attribute labels and values. For example, attribute 704 may include domain 706 and region 708, each identifying the corresponding domain and region of the associated software resource.

[0104] Identity service 700 can be configured to expose an API to allow clients within a local area network to invoke identity service 700 to obtain identifiers. As a specific example, identity service 700 may allow calls to create identifiers (e.g., "CreateID()"), retrieve identifiers by resource name (e.g., "GetIDByName()"), and retrieve identifiers by resource identifier descriptor (e.g., "GetIDByDescriptor()"). For the "CreateID()" call, identity service 700 can take a resource identifier descriptor as input and generate a unique identifier for that resource. As described above, the resource identifier descriptor can be a tuple of attributes, attribute values, and an algorithm corresponding to a resource (e.g., a software resource) that can be used to uniquely and idempotently generate identifiers for that resource. For example, a client node can invoke identity service 700 with "CreateID()" providing attribute 704 and specifying algorithm 1 712. Identity service 700 can then return identifier 1 716. Algorithm 1 712 can be an obfuscation algorithm configured to obfuscate the software resource's local numeric identifier and human-readable label. Identifier 1 716 can be guaranteed to be unique by identity service 700. As another example, a client node can call Identity Service 700 with "CreateID()" and provide attribute 704, specifying Algorithm 2 714. Identity Service 700 can then return Identifier 2 718. Algorithm 2 714 can be a UUID algorithm configured to generate a UUID using a local numeric identifier of the software resource and the software type. For the "GetIDByName()" call, Identity Service 700 can receive the resource name (e.g., Figure 6 The identity service 700 can receive the resource name (620) and return the associated identifier corresponding to that resource name. For the "GetIDByDescriptor()" call, the identity service 700 can receive the resource identifier descriptor describing the software resource and return the corresponding identifier.

[0105] In some embodiments, identity service 700 can be configured to enforce a request on attribute 704 based on information corresponding to the associated domain. For example, identity service 700 can verify that the values ​​of domain 706 and region 708 match the expected values ​​of those attributes. If domain 706 and / or region 708 are incorrect, then identity service 700 can reject the call and not provide the requested identifier.

[0106] Figure 8 This is a block diagram illustrating a distributed computing system 800 according to at least one embodiment, which implements a technique for rotating identifiers for software resources after a regional network 504 has been delivered to a destination site. The destination site may be a data center 802, which may differ from the data center 502 (e.g., a prefabrication plant) where the boot process is performed. A manager service 512 may be configured to provide an indication to an identity service 514 that the boot process has been completed. For example, the regional network 504 may perform one or more test operations after physical resources have been delivered and installed in the data center 802 to verify the correct configuration of the infrastructure and deployed software. After this verification is complete, the identity service 514 may receive an identity rotation instruction indicating that the regional network 504 is no longer in a boot or regional build configuration.

[0107] In response to receiving an identity rotation instruction from manager service 512, identity service 514 may modify its response to invocations for identifiers from client nodes within regional network 504. Specifically, identity service 514 may include instructions to locally cache identifiers at client node 520. For example, client node 520 may invoke identity service 514 and provide attribute 824 to obtain identifier 828. Because regional network 504 is a new data center 802 (e.g., a new area, a new domain), attribute 824 of software resource 522 may differ from attribute 828. Identity service 514 may include a caching instruction to client node 520 to cache identifier 828. Client node 520 can then store identifier 828 in cache 528. Subsequently, client node 520 can retrieve identifier 828 from cache 528 instead of invoking identity service 514. In some embodiments, identity service 514 may not send a caching instruction after receiving an identity rotation instruction from manager service 512. In these cases, client nodes in regional network 504 can always invoke identity service 514 to obtain identifier 828 that is compatible with the area and domain in which regional network 504 operates.

[0108] Figure 9 This is a flowchart of an example method 900 for rotating from a first identifier to a second identifier of a software resource according to at least one embodiment. Method 900 can be executed by one or more components of a distributed computing system, including an execution manager service (e.g., Figure 2 Manager service 212, Figure 5 The CSP (e.g., the manager service 512) Figure 2 One or more components of a distributed computing system (CSP204). The operations of method 900 can be performed in any suitable order, and method 900 can include more than... Figure 9 The operations described in the text are more or fewer operations.

[0109] Some or all of method 900 (or any other processing and / or method described herein, or variations and / or combinations thereof) may be executed under the control of one or more computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed jointly on one or more processors via hardware or a combination thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising multiple instructions executable by one or more processors. The computer-readable storage medium may be non-transitory.

[0110] Method 900 can begin at box 902, where the identity service (e.g., Figure 5 Identity service 514 receives a first request for a first identifier (e.g., identifier 526) of a software resource within a local area network (e.g., local area network 504). The first request may include a first attribute (e.g., attribute 524) associated with the software resource. The first attribute may include an attribute label and a value, as well as an algorithm that the identity service can use to generate the first identifier. In some embodiments, the first attribute may include the local area name of the local area network, the attribute value of the software resource, and information specifying the algorithm.

[0111] At box 904, the identity service may generate a first identifier based at least in part on a first attribute. For example, the first attribute may specify a region corresponding to a prefabricated factory data center and specify the use of a UUID algorithm. The identity service may use the specified UUID algorithm to extract region information, the type of software resource, and an internal numeric identifier to generate a UUID for the software resource as the first identifier. As another example, the first attribute may specify the resource name of the software resource (e.g., a human-readable label), the internal numeric identifier of the software resource, and an obfuscation algorithm that obfuscates the internal numeric identifier and the resource name to generate the first identifier. In some embodiments, generating the first identifier may include using the algorithm and taking the region name and attribute value as input to generate a globally unique identifier.

[0112] At box 906, the identity service may send a first identifier and a first cache instruction to the client node. The first cache instruction may include information that the client node can use to prevent the identifier from being stored in the cache associated with the client node (e.g., ...). Figure 5 The information is stored in the cache (528). By not storing the first identifier in the cache, the client node may need to invoke the identity service to retrieve the first identifier. Not storing the first identifier according to the first cache instruction may include the client node removing (e.g., deleting) the first identifier from active storage when the operation including receiving the first identifier ends. In some examples, the client node may operate according to the default behavior, where the client node stores information (e.g., identifier) ​​received from the identity service in the cache. The first cache instruction can then override the default behavior, causing the client node not to store the first identifier in the cache, which the client node might otherwise store such information received from the identity service.

[0113] At box 908, the identity service can be obtained from the manager service (e.g., Figure 5 The manager service 512 receives an identity rotation instruction. The identity rotation instruction may include information that the identity service can use to provide a second cache instruction in response to a request for a software resource identifier. The identity rotation instruction may correspond to the end of a regional network boot operation and the start of a production operation. For example, after a regional network is built at a prefabrication plant and subsequently delivered and installed at a destination site in a new region, the manager service may determine that the regional network is no longer in boot mode and may provide an identity rotation instruction to the identity service. In some embodiments, the identity rotation instruction may correspond to a change in region and / or domain parameters imposed by an operator. For example, the manager service may send an identity rotation instruction based on a region name change imposed by a user. Subsequently, the identity service may begin providing a new identifier corresponding to the changed region and / or domain, as if the client node were configured to operate in that region / domain.

[0114] At box 910, the identity service may receive a second request for a second identifier of a software resource from the client node. The second request may include a second attribute associated with the software resource (e.g., ...). Figure 8 Attribute 824). The second attribute can specify a new region, domain, resource name, or characterize the software resource in its current operating location (e.g., ...). Figure 8 The values ​​of other parameters in the data center (802). In some embodiments, the second attribute may include the new area name of the regional network, the attribute value of the software resource, and information specifying the algorithm.

[0115] At box 912, the identity service may generate a second identifier at least in part based on a second attribute. For example, the second attribute may specify a region corresponding to the destination site data center and specify an algorithm for generating the second identifier. The identity service may use the specified algorithm to extract the region information and generate the second identifier. In some embodiments, generating the second identifier may include using an algorithm and taking a new region name and attribute value as input to generate a globally unique identifier.

[0116] At box 914, the identity service can send a second identifier and a second cache instruction to the client node. The second cache instruction can include information that the client node can use to store the second identifier in its cache. For example, the second cache instruction can instruct the client node to store the second identifier in its local cache for a specific period of time or to store it permanently. The second cache instruction can also instruct the client node to always check the second identifier in its local cache instead of calling the identity service to retrieve the identifier.

[0117] In some embodiments, before generating the first identifier, the identity service may determine whether the zone name matches the expected zone name of the area network. For example, if the identity service is configured to anticipate a call from a client node for a resource executed in zone 1, then a call from the client node providing a resource identifier descriptor specifying zone 2 will not match. The expected zone name may be stored by the identity service. Based on the determination that the zone name matches the expected zone name, the identity service may proceed to generate the first identifier. If the zone name does not match the expected zone name, the identity service may return an error message or other error to the client node.

[0118] In some embodiments, the rotation instruction may include second information specifying a new expected area name for the area network. For example, the manager service may provide an area name (e.g., "Area 1") or a new area (e.g., "Area 1") to be used in response to a call for an identifier from a client. A second attribute of the software resource may include a new area name for the area network in which the software resource is executing. Before generating the second identifier, the identity service may determine whether the new area name matches the new expected area name of the area network. If the new area name matches the new expected area name, the identity service may proceed to generate the second identifier. If the new area name does not match the new expected area name, the identity service may send an error message or other message to the client node.

[0119] Example Infrastructure as a Service architecture

[0120] As noted above, Infrastructure as a Service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, cloud providers can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, IaaS providers can also provision various services to accompany these infrastructure components (example services include billing software, monitoring software, logging software, load balancing software, and clustering software, etc.). Therefore, because these services may be policy-driven, IaaS users can implement policies to drive load balancing to maintain application availability and performance.

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

[0122] In most cases, cloud computing models may require the involvement of cloud providers. Cloud providers can, but are not necessarily, third-party providers specializing in (e.g., provisioning, renting, selling) IaaS services. Entities may also choose to deploy private clouds, thus becoming their own infrastructure service providers.

[0123] In some examples, IaaS deployment is the process of placing a new application or a new version of an application onto a prepared application server, etc. It may also include the processing of server preparation (e.g., installing libraries, daemons, etc.). This is typically managed by the cloud provider, below the hypervisor layer (e.g., servers, storage devices, network hardware, and virtualization). Therefore, the customer can be responsible for processing (OS), middleware, and / or application deployment (e.g., on self-service virtual machines that can be started on demand), etc.

[0124] In some examples, IaaS provisioning can refer to acquiring computers or virtual hosts for use, or even installing necessary libraries or services on them. In most cases, deployment does not include provisioning, and provisioning may need to be performed first.

[0125] In some cases, IaaS provisioning presents two distinct challenges. First, there's the initial challenge of provisioning the initial infrastructure set before anything is operational. Second, once everything is provisioned, there's the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.). In some cases, both challenges can be addressed by enabling configuration that declaratively defines the infrastructure. In other words, the infrastructure (e.g., which components are needed and how they interact) can be defined by one or more configuration files. Therefore, the overall topology of the infrastructure (e.g., which resources depend on which resources and how they work together) can be described declaratively. In some cases, once the topology is defined, workflows for creating and / or managing the different components described in the configuration files can be generated.

[0126] In some examples, the infrastructure can have many interconnected components. For example, there may be one or more Virtual Private Clouds (VPCs) (e.g., a potential on-demand pool of configurable and / or shared computing resources), also known as the core network. In some examples, one or more inbound / outbound traffic group rules may also be provided to define how inbound / outbound traffic to the network and one or more virtual machines (VMs). Other infrastructure elements, such as load balancers, databases, etc., may also be provided. The infrastructure can evolve incrementally as more and / or more infrastructure elements are expected and added.

[0127] In some cases, continuous deployment techniques can be used to enable the deployment of infrastructure code across various virtual computing environments. Furthermore, the described techniques enable infrastructure management within these environments. In some examples, service teams may write code that they expect to deploy to one or more, but often many, different production environments (e.g., across various geographical locations, sometimes spanning the entire world). However, in some examples, the infrastructure on which code may need to be deployed is first set up. In some cases, provisioning can be done manually, resources can be provisioned using provisioning tools, and / or once the infrastructure is provisioned, the code can be deployed using deployment tools.

[0128] Figure 10 This is a block diagram 1000 illustrating an example pattern of an IaaS architecture according to at least one embodiment. Service operator 1002 may be communicatively coupled to a secure host lease 1004, which may include a virtual cloud network (VCN) 1006 and a secure host subnet 1008. In some examples, service operator 1002 may use one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, cellular phone, iPad®, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass® head-mounted display), running software (such as Microsoft Windows Mobile®) and / or various mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc.), and supporting the Internet, email, short message service (SMS), Blackberry®, or other communication protocols. Alternatively, client computing devices may be general-purpose personal computers, including, for example, personal computers and / or laptops running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. Client computing devices can be workstation computers running a variety of commercially available UNIX® or UNIX-like operating systems, including but not limited to any of the various GNU / Linux operating systems (such as, for example, Google Chrome OS). Alternatively or additionally, client computing devices can be any other electronic device, such as thin client computers, internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect® gesture input devices), and / or personal messaging devices capable of communicating over a network that can access VCN 1006 and / or the internet.

[0129] VCN 1006 may include a local peering gateway (LPG) 1010, which may be communicatively coupled to a secure shell (SSH) VCN 1012 via an LPG 1010 contained in an SSH VCN 1012. SSH VCN 1012 may include an SSH subnet 1014, and SSH VCN 1012 may be communicatively coupled to a control plane VCN 1016 via an LPG 1010 contained in a control plane VCN 1016. Furthermore, SSH VCN 1012 may be communicatively coupled to a data plane VCN 1018 via an LPG 1010. Control plane VCN 1016 and data plane VCN 1018 may be contained within a service lease 1019 that may be owned and / or operated by an IaaS provider.

[0130] The control plane VCN 1016 may include a control plane demilitarized zone (DMZ) layer 1020 that acts as a peripheral network (e.g., a portion of a corporate network between a corporate intranet and an external network). DMZ-based servers can assume limited liability and help control vulnerabilities. Furthermore, the DMZ layer 1020 may include one or more load balancer (LB) subnets 1022, a control plane application layer 1024 that may include one or more application subnets 1026, and a control plane data layer 1028 that may include one or more database (DB) subnets 1030 (e.g., one or more front-end DB subnets and / or one or more back-end DB subnets). One or more LB subnets 1022 contained in the control plane DMZ layer 1020 may be communicatively coupled to one or more application subnets 1026 contained in the control plane application layer 1024 and an Internet gateway 1034 that may be contained in the control plane VCN 1016. The application subnets 1026 may be communicatively coupled to one or more DB subnets 1030 contained in the control plane data layer 1028, as well as a service gateway 1036 and a Network Address Translation (NAT) gateway 1038. The control plane VCN 1016 may include the service gateway 1036 and the NAT gateway 1038.

[0131] The control plane VCN 1016 may include a data plane mirror application layer 1040, which may include one or more application subnets 1026. The one or more application subnets 1026 included in the data plane mirror application layer 1040 may include a virtual network interface controller (VNIC) 1042 capable of executing a compute instance 1044. The compute instance 1044 may communicatively couple the one or more application subnets 1026 of the data plane mirror application layer 1040 to the one or more application subnets 1026 that may be included in the data plane application layer 1046.

[0132] Data plane VCN 1018 may include data plane application layer 1046, data plane DMZ layer 1048, and data plane data layer 1050. Data plane DMZ layer 1048 may include one or more LB subnets 1022 communicatively coupled to one or more application subnets 1026 of data plane application layer 1046 and Internet gateway 1034 of data plane VCN 1018. One or more application subnets 1026 communicatively coupled to service gateway 1036 and NAT gateway 1038 of data plane VCN 1018. Data plane data layer 1050 may also include one or more DB subnets 1030 communicatively coupled to one or more application subnets 1026 of data plane application layer 1046.

[0133] The Internet gateway 1034 of the control plane VCN 1016 and data plane VCN 1018 can be communicatively coupled to the metadata management service 1052, which can be communicatively coupled to the public Internet 1054. The public Internet 1054 can be communicatively coupled to the NAT gateway 1038 of the control plane VCN 1016 and data plane VCN 1018. The service gateway 1036 of the control plane VCN 1016 and data plane VCN 1018 can be communicatively coupled to the cloud service 1056.

[0134] In some examples, the service gateway 1036 of the control plane VCN 1016 or data plane VCN 1018 can make application programming interface (API) calls to the cloud service 1056 without traversing the public internet 1054. API calls from the service gateway 1036 to the cloud service 1056 can be unidirectional: the service gateway 1036 can make API calls to the cloud service 1056, and the cloud service 1056 can send requested data to the service gateway 1036. However, the cloud service 1056 may not initiate API calls to the service gateway 1036.

[0135] In some examples, secure host lease 1004 can be directly connected to service lease 1019, which would otherwise be isolated. Secure host subnet 1008 can communicate with SSH subnet 1014 via LPG 1010, which enables bidirectional communication between otherwise isolated systems. Connecting secure host subnet 1008 to SSH subnet 1014 allows secure host subnet 1008 to access other entities within service lease 1019.

[0136] Control plane VCN 1016 may allow users of service lease 1019 to configure or otherwise provision desired resources. Desired resources provisioned in control plane VCN 1016 may be deployed or otherwise used in data plane VCN 1018. In some examples, control plane VCN 1016 may be isolated from data plane VCN 1018, and the data plane mirror application layer 1040 of control plane VCN 1016 may communicate with the data plane application layer 1046 of data plane VCN 1018 via VNIC 1042, which may be included in both the data plane mirror application layer 1040 and the data plane application layer 1046.

[0137] In some examples, users or clients of the system can make requests, such as create, read, update, or delete (CRUD) operations, via the public internet 1054, which can transmit requests to the metadata management service 1052. The metadata management service 1052 can transmit requests to the control plane VCN 1016 via internet gateway 1034. Requests can be received by one or more LB subnets 1022 contained in the control plane DMZ layer 1020. The LB subnets 1022 can determine that the request is valid, and in response to this determination, they can transmit the request to one or more application subnets 1026 contained in the control plane application layer 1024. If the request is validated and requires a call to the public internet 1054, the call to the public internet 1054 can be transmitted to a NAT gateway 1038 that can make calls to the public internet 1054. The request may expect the storage to be located in one or more DB subnets 1030.

[0138] In some examples, the data plane mirroring application layer 1040 can facilitate direct communication between the control plane VCN 1016 and the data plane VCN 1018. For example, it may be desirable to apply configuration changes, updates, or other appropriate modifications to resources contained in the data plane VCN 1018. Through VNIC 1042, the control plane VCN 1016 can communicate directly with the resources contained in the data plane VCN 1018, and thus can perform configuration changes, updates, or other appropriate modifications.

[0139] In some embodiments, the control plane VCN 1016 and data plane VCN 1018 may be included in service lease 1019. In this case, the system's users or customers may not own or operate the control plane VCN 1016 or data plane VCN 1018. Alternatively, the IaaS provider may own or operate both the control plane VCN 1016 and data plane VCN 1018, and both planes may be included in service lease 1019. This embodiment enables the isolation of networks that might prevent users or customers from interacting with resources from other users or customers. Furthermore, this embodiment allows users or customers of the system to privately store databases without relying on the public internet 1054, which may not have the desired level of threat protection.

[0140] In other embodiments, one or more LB subnets 1022 included in the control plane VCN 1016 may be configured to receive signals from the service gateway 1036. In this embodiment, the control plane VCN 1016 and the data plane VCN 1018 may be configured to be invoked by the IaaS provider's customers without invoking the public internet 1054. The IaaS provider's customers may expect this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and can be stored on a service lease 1019, which may be isolated from the public internet 1054.

[0141] Figure 11 This is a block diagram 1100 illustrating another example pattern of an IaaS architecture according to at least one embodiment. Service operator 1102 (e.g., Figure 10 The service provider 1002 can communicatively couple to the secure host lease 1104 (e.g., Figure 10 Secure hosting lease 1004), the secure hosting lease 1104 may include a virtual cloud network (VCN) 1106 (e.g., Figure 10 VCN 1006) and Secure Host Subnet 1108 (e.g., Figure 10 The secure host subnet 1008). VCN 1106 may include a local peering gateway (LPG) 1110 (e.g., Figure 10 The LPG 1010, which can be communicatively coupled to the Secure Shell (SSH) VCN 1112 (e.g., LPG 1010 included in the SSH VCN 1112) via the LPG 1010. Figure 10 SSH VCN 1012). SSH VCN 1112 can include SSH subnet 1114 (e.g., Figure 10 SSH subnet 1014), and SSH VCN 1112 can be communicatively coupled to control plane VCN 1116 via LPG 1110 contained in control plane VCN 1116 (e.g., Figure 10 Control plane VCN 1016). Control plane VCN 1116 may be included in service lease 1119 (e.g., Figure 10 In the service lease 1019), and the data plane VCN 1118 (e.g., Figure 10 The data plane VCN 1018 may be included in a customer lease 1121 that may be owned or operated by a user or customer of the system.

[0142] The control plane VCN 1116 may include one or more LB subnets 1122 (e.g., Figure 10 The control plane DMZ layer 1120 of (one or more) LB subnets 1022) (e.g., Figure 10 The control plane DMZ layer 1020 may contain one or more application subnets 1126 (e.g., Figure 10 The control plane application layer 1124 of (one or more) application subnets 1026 (e.g., Figure 10 The control plane application layer 1024 may contain one or more database (DB) subnets 1130 (e.g., similar to...). Figure 10 The control plane data layer 1128 of (one or more) DB subnets 1030 (e.g., Figure 10 The control plane data layer 1028). One or more LB subnets 1122 contained in the control plane DMZ layer 1120 can be communicatively coupled to one or more application subnets 1126 contained in the control plane application layer 1124 and an Internet gateway 1134 that can be contained in the control plane VCN 1116 (e.g., Figure 10 Internet gateway 1034), and application subnet(s) 1126 can communicatively couple to DB subnet(s) 1130 contained in control plane data layer 1128 and service gateway 1136 (e.g., Figure 10 The service gateway) and Network Address Translation (NAT) gateway 1138 (e.g., Figure 10 (NAT gateway 1038). The control plane VCN 1116 may include the service gateway 1136 and the NAT gateway 1138.

[0143] The control plane VCN 1116 may include a data plane mirror application layer 1140 that may contain one or more application subnets 1126 (e.g., Figure 10 The data plane mirror application layer 1040). One or more application subnets 1126 contained in the data plane mirror application layer 1140 may include computational instances 1144 (e.g., similar to...). Figure 10 The virtual network interface controller (VNIC) 1142 (e.g., the VNIC of 1042) of the computing instance 1044. The computing instance 1144 may facilitate the mirroring of the application subnet(s) 1126 of the application layer 1140 in the data plane and may be included in the application layer 1146 of the data plane (e.g., Figure 10 Communication between one or more application subnets 1126 in the data plane application layer 1046 via VNIC 1142 contained in the data plane mirror application layer 1140 and VNIC 1142 contained in the data plane application layer 1146.

[0144] Internet gateway 1134, included in control plane VCN 1116, can be communicatively coupled to metadata management service 1152 (e.g., Figure 10 Metadata management service 1052), which can communicatively couple to the public Internet 1154 (e.g., Figure 10 The public internet 1154 can communicatively couple to a NAT gateway 1138 contained in a control plane VCN 1116. The service gateway 1136 contained in the control plane VCN 1116 can communicatively couple to a cloud service 1156 (e.g., ...). Figure 10 Cloud services (1056).

[0145] In some examples, data plane VCN 1118 may be included in customer lease 1121. In this case, the IaaS provider may provide control plane VCN 1116 for each customer, and the IaaS provider may set up a unique compute instance 1144 for each customer, included in service lease 1119. Each compute instance 1144 may allow communication between control plane VCN 1116 included in service lease 1119 and data plane VCN 1118 included in customer lease 1121. Compute instance 1144 may allow resources provisioned in control plane VCN 1116 included in service lease 1119 to be deployed or otherwise used in data plane VCN 1118 included in customer lease 1121.

[0146] In other examples, an IaaS provider's customer may have a database residing in customer lease 1121. In this example, control plane VCN 1116 may include data plane mirror application layer 1140, which may include one or more application subnets 1126. Data plane mirror application layer 1140 may reside in data plane VCN 1118, but may not reside in data plane VCN 1118. That is, data plane mirror application layer 1140 may have access to customer lease 1121, but may not reside in data plane VCN 1118 or be owned or operated by an IaaS provider's customer. Data plane mirror application layer 1140 may be configured to invoke data plane VCN 1118, but may not be configured to invoke any entity contained in control plane VCN 1116. Customers may expect to deploy or otherwise use resources provisioned in the control plane VCN 1116 in the data plane VCN 1118, and the data plane mirroring application layer 1140 can facilitate the customer's expected deployment or other use of resources.

[0147] In some embodiments, an IaaS provider's customer may apply filters to data plane VCN 1118. In this embodiment, the customer may determine what data plane VCN 1118 can access, and the customer may restrict access from data plane VCN 1118 to the public internet 1154. The IaaS provider may not be able to apply filters or otherwise control data plane VCN 1118's access to any external networks or databases. Applying filters and controls to data plane VCN 1118 contained in customer lease 1121 can help isolate data plane VCN 1118 from other customers and the public internet 1154.

[0148] In some embodiments, cloud service 1156 may be invoked by service gateway 1136 to access services that may not exist on public internet 1154, control plane VCN 1116, or data plane VCN 1118. The connection between cloud service 1156 and control plane VCN 1116 or data plane VCN 1118 may not be real-time or continuous. Cloud service 1156 may reside on different networks owned or operated by an IaaS provider. Cloud service 1156 may be configured to receive calls from service gateway 1136 and may be configured not to receive calls from public internet 1154. Some cloud services 1156 may be isolated from other cloud services 1156, and control plane VCN 1116 may be isolated from cloud services 1156 that may not be in the same region as control plane VCN 1116. For example, control plane VCN 1116 may be located in "Region 1," and cloud service "Deployment 10" may be located in both "Region 1" and "Region 2." If the service gateway 1136, contained in the control plane VCN 1116 located in region 1, makes a call to deployment 10, then that call can be transmitted to deployment 10 in region 1. In this example, the control plane VCN 1116 or deployment 10 in region 1 may not be communicatively coupled to or otherwise communicate with deployment 10 in region 2.

[0149] Figure 12 This is a block diagram 1200 illustrating another example pattern of an IaaS architecture according to at least one embodiment. Service operator 1202 (e.g., Figure 10 The service provider 1002 can communicatively couple to the secure host lease 1204 (e.g., Figure 10 Secure hosting lease 1004), the secure hosting lease 1204 may include a virtual cloud network (VCN) 1206 (e.g., Figure 10 VCN 1006) and Secure Host Subnet 1208 (e.g., Figure 10 The secure host subnet 1008). VCN 1206 may include LPG 1210 (e.g., Figure 10 The LPG 1010), which can be communicatively coupled to the SSH VCN 1212 via the LPG 1210 included in the SSH VCN 1212 (e.g., Figure 10 SSH VCN 1012). SSH VCN 1212 can include SSH subnet 1214 (e.g., Figure 10 SSH subnet 1014), and SSH VCN 1212 can be communicatively coupled to control plane VCN 1216 via LPG 1210 included in control plane VCN 1216 (e.g., Figure 10 The control plane VCN 1016) and coupled to the data plane VCN 1218 via the LPG 1210 contained in the data plane VCN 1218 (e.g., Figure 10 Data plane 1018). Control plane VCN 1216 and data plane VCN 1218 can be included in service lease 1219 (e.g., Figure 10 In the service rental (1019).

[0150] The control plane VCN 1216 may include a load balancer (LB) subnet 1222 (e.g., Figure 10 The control plane DMZ layer 1220 of (one or more) LB subnets 1022) (e.g., Figure 10 The control plane DMZ layer 1020 may include one or more application subnets 1226 (e.g., similar to...). Figure 10 The control plane application layer 1224 of (one or more) application subnets 1026 (e.g., Figure 10 The control plane application layer 1024), and may include (one or more) DB subnets 1230, and the control plane data layer 1228 (e.g., Figure 10 The control plane data layer 1028). One or more LB subnets 1222 contained in the control plane DMZ layer 1220 can be communicatively coupled to one or more application subnets 1226 contained in the control plane application layer 1224 and an Internet gateway 1234 that can be contained in the control plane VCN 1216 (e.g., Figure 10 Internet gateway 1034), and application subnet(s) 1226 can communicatively couple to DB subnet(s) 1230 contained in control plane data layer 1228 and service gateway 1236 (e.g., Figure 10 The service gateway) and Network Address Translation (NAT) gateway 1238 (e.g., Figure 10 (NAT gateway 1038). The control plane VCN 1216 may include the service gateway 1236 and the NAT gateway 1238.

[0151] Data plane VCN 1218 may include data plane application layer 1246 (e.g., Figure 10 Data plane application layer 1046), data plane DMZ layer 1248 (e.g., Figure 10 Data plane DMZ layer 1048), and data plane data layer 1250 (e.g., Figure 10 The data plane data layer 1050. The data plane DMZ layer 1248 may include one or more trusted application subnets 1260 and one or more untrusted application subnets 1262 that can be communicatively coupled to the data plane application layer 1246, and one or more LB subnets 1222 of the Internet gateway 1234 contained in the data plane VCN 1218. The one or more trusted application subnets 1260 may be communicatively coupled to the service gateway 1236 contained in the data plane VCN 1218, the NAT gateway 1238 contained in the data plane VCN 1218, and one or more DB subnets 1230 contained in the data plane data layer 1250. The one or more untrusted application subnets 1262 may be communicatively coupled to the service gateway 1236 contained in the data plane VCN 1218 and the one or more DB subnets 1230 contained in the data plane data layer 1250. The data plane data layer 1250 may include one or more DB subnets 1230 that can be communicatively coupled to the service gateway 1236 contained in the data plane VCN 1218.

[0152] One or more untrusted application subnets 1262 may include one or more primary VNICs 1264(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 1266(1)-(N). Each tenant VM 1266(1)-(N) may be communicatively coupled to a corresponding application subnet 1267(1)-(N) that may be contained in a corresponding container egress VCN 1268(1)-(N), which may be contained in a corresponding customer lease 1270(1)-(N). A corresponding secondary VNIC 1272(1)-(N) may facilitate communication between one or more untrusted application subnets 1262 contained in data plane VCN 1218 and application subnets contained in container egress VCN 1268(1)-(N). Each container exit VCN 1268(1)-(N) may include a NAT gateway 1238, which can communicatively couple to the public Internet 1254 (e.g., Figure 10 (Public Internet 1054).

[0153] Internet gateway 1234, contained in control plane VCN 1216 and data plane VCN 1218, can be communicatively coupled to metadata management service 1252 (e.g., Figure 10 A metadata management system 1052 is provided, which can communicatively couple to the public internet 1254. The public internet 1254 can communicatively couple to a NAT gateway 1238 contained in a control plane VCN 1216 and a data plane VCN 1218. A service gateway 1236 contained in a control plane VCN 1216 and a data plane VCN 1218 can communicatively couple to a cloud service 1256.

[0154] In some embodiments, the data plane VCN 1218 may be integrated with the customer lease 1270. Such integration may be useful or desired by the IaaS provider's customer in certain situations, such as when support may be expected during code execution. A customer may provide code that could be destructive, might communicate with other customer resources, or might otherwise cause undesirable effects. In response, the IaaS provider may determine whether to run the code provided by the customer to the IaaS provider.

[0155] In some examples, an IaaS provider's customer may grant the IaaS provider temporary network access and request functionality attached to the data plane application layer 1246. The code running this functionality may execute in VMs 1266(1)-(N) and may not be configured to run anywhere else on the data plane VCN 1218. Each VM 1266(1)-(N) may be connected to a customer lease 1270. The corresponding container 1271(1)-(N) contained in VMs 1266(1)-(N) may be configured to run the code. In this case, dual isolation may exist (e.g., container 1271(1)-(N) runs the code, where container 1271(1)-(N) may be contained in at least one or more untrusted application subnets 1262 containing VMs 1266(1)-(N)), which can help prevent incorrect or otherwise unintended code from corrupting the IaaS provider's network or the networks of different customers. Containers 1271(1)-(N) may be communicatively coupled to customer lease 1270 and may be configured to transmit or receive data from customer lease 1270. Containers 1271(1)-(N) may not be configured to transmit or receive data from any other entity in data plane VCN 1218. After the code execution is complete, the IaaS provider may terminate or otherwise dispose of containers 1271(1)-(N).

[0156] In some embodiments, one or more trusted application subnets 1260 may run code that may be owned or operated by an IaaS provider. In this embodiment, one or more trusted application subnets 1260 may be communicatively coupled to one or more database subnets 1230 and configured to perform CRUD operations in one or more database subnets 1230. One or more untrusted application subnets 1262 may be communicatively coupled to one or more database subnets 1230, but in this embodiment, one or more untrusted application subnets may be configured to perform read operations in one or more database subnets 1230. Containers 1271(1)-(N) that may be contained in each customer's VM 1266(1)-(N) and may run code from the customer may not be communicatively coupled to one or more database subnets 1230.

[0157] In other embodiments, the control plane VCN 1216 and the data plane VCN 1218 may be coupled without direct communication. In this embodiment, there may be no direct communication between the control plane VCN 1216 and the data plane VCN 1218. However, communication can occur indirectly through at least one method. The LPG 1210 may be established by an IaaS provider, which can facilitate communication between the control plane VCN 1216 and the data plane VCN 1218. In another example, the control plane VCN 1216 or the data plane VCN 1218 may invoke the cloud service 1256 via the service gateway 1236. For example, an invocation of the cloud service 1256 from the control plane VCN 1216 may include a request for a service that can communicate with the data plane VCN 1218.

[0158] Figure 13 This is a block diagram 1300 illustrating another example pattern of an IaaS architecture according to at least one embodiment. Service operator 1302 (e.g., Figure 10 The service provider 1002 can communicatively couple to the secure host lease 1304 (e.g., Figure 10 Secure hosting lease 1004), the secure hosting lease 1304 may include a virtual cloud network (VCN) 1306 (e.g., Figure 10 VCN 1006) and Secure Host Subnet 1308 (e.g., Figure 10 The secure host subnet 1008). VCN 1306 can include LPG 1310 (e.g., Figure 10 The LPG 1010), the LPG 1310 can be contained in SSH VCN 1312 (e.g., Figure 10 The LPG 1310 in SSH VCN 1012 is communicatively coupled to SSH VCN 1312. SSH VCN 1312 may include SSH subnet 1314 (e.g., Figure 10 SSH subnet 1014), and SSH VCN 1312 can be communicatively coupled to control plane VCN 1316 via LPG 1310 included in control plane VCN 1316 (e.g., Figure 10 The control plane VCN 1016) and coupled to the data plane VCN 1318 via the LPG 1310 contained in the data plane VCN 1318 (e.g., Figure 10 Data plane 1018). Control plane VCN 1316 and data plane VCN 1318 may be included in service lease 1319 (e.g., Figure 10 In the service rental (1019).

[0159] The control plane VCN 1316 may include one or more LB subnets 1322 (e.g., Figure 10 The control plane DMZ layer 1320 of (one or more) LB subnets 1022) (e.g., Figure 10 The control plane DMZ layer 1020 may include one or more application subnets 1326 (e.g., Figure 10 The control plane application layer 1324 of (one or more) application subnets 1026 (e.g., Figure 10 The control plane application layer 1024 may include (one or more) DB subnets 1330 (e.g., Figure 12 The control plane data layer 1328 of (one or more) DB subnets 1230 (e.g., Figure 10 The control plane data layer 1028). One or more LB subnets 1322 contained in the control plane DMZ layer 1320 can be communicatively coupled to one or more application subnets 1326 contained in the control plane application layer 1324 and an Internet gateway 1334 that can be contained in the control plane VCN 1316 (e.g., Figure 10 Internet gateway 1034), and application subnet(s) 1326 can communicatively couple to DB subnet(s) 1330 contained in control plane data layer 1328 and service gateway 1336 (e.g., Figure 10 The service gateway) and Network Address Translation (NAT) gateway 1338 (e.g., Figure 10 (NAT gateway 1038). The control plane VCN 1316 may include the service gateway 1336 and the NAT gateway 1338.

[0160] Data plane VCN 1318 may include data plane application layer 1346 (e.g., Figure 10 Data plane application layer 1046), data plane DMZ layer 1348 (e.g., Figure 10 Data plane DMZ layer 1048), and data plane data layer 1350 (e.g., Figure 10 The data plane data layer 1050). The data plane DMZ layer 1348 may include one or more trusted application subnets 1360 that can be communicatively coupled to the data plane application layer 1346 (e.g., Figure 12 (one or more) trusted application subnets 1260) and (one or more) untrusted application subnets 1362 (e.g., Figure 12 The data plane VCN 1318 may include one or more untrusted application subnets 1262 and one or more LB subnets 1322. One or more trusted application subnets 1360 may be communicatively coupled to a service gateway 1336, a NAT gateway 1338, and a DB subnet 1330, all contained in the data plane VCN 1318. One or more untrusted application subnets 1362 may be communicatively coupled to a service gateway 1336 and a DB subnet 1330, both contained in the data plane VCN 1318 and the data plane data layer 1350. The data plane data layer 1350 may include one or more DB subnets 1330 that may be communicatively coupled to a service gateway 1336, contained in the data plane VCN 1318.

[0161] One or more untrusted application subnets 1362 may include a primary VNIC 1364(1)-(N) communicatively coupled to tenant virtual machines (VMs) 1366(1)-(N) residing within one or more untrusted application subnets 1362. Each tenant VM 1366(1)-(N) may run code in a corresponding container 1367(1)-(N) and is communicatively coupled to an application subnet 1326 that may be contained in a data plane application layer 1346 contained in a container egress VCN 1368. A corresponding secondary VNIC 1372(1)-(N) may facilitate communication between one or more untrusted application subnets 1362 contained in a data plane VCN 1318 and the application subnet contained in a container egress VCN 1368. The container egress VCN may include a public internet 1354 (e.g., Figure 10 The public internet (1054) uses NAT gateway 1338.

[0162] Internet gateway 1334, contained in control plane VCN 1316 and data plane VCN 1318, can be communicatively coupled to metadata management service 1352 (e.g., Figure 10 A metadata management system 1052 is provided, which can communicatively couple to the public internet 1354. The public internet 1354 can communicatively couple to a NAT gateway 1338 contained in a control plane VCN 1316 and a data plane VCN 1318. A service gateway 1336 contained in a control plane VCN 1316 and a data plane VCN 1318 can communicatively couple to a cloud service 1356.

[0163] In some examples, Figure 13 The architecture shown in block diagram 1300 can be considered as... Figure 12 This is an exception to the pattern shown in the architecture of block diagram 1200, and this pattern may be what the IaaS provider's customers would expect if the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected region). The customer can access in real time the corresponding container 1367(1)-(N) contained in each customer's VM 1366(1)-(N). Container 1367(1)-(N) can be configured to invoke a corresponding auxiliary VNIC 1372(1)-(N) contained in one or more application subnets 1326 of the data plane application layer 1346, which may be contained in a container egress VCN 1368. The auxiliary VNIC 1372(1)-(N) can transmit the call to a NAT gateway 1338, which can then transmit the call to the public internet 1354. In this example, containers 1367(1)-(N), which can be accessed by clients in real time, can be isolated from the control plane VCN 1316 and from other entities contained in the data plane VCN 1318. Containers 1367(1)-(N) can also be isolated from resources from other clients.

[0164] In other examples, a client may use container 1367(1)-(N) to invoke cloud service 1356. In this example, the client may run code within container 1367(1)-(N) requesting a service from cloud service 1356. Container 1367(1)-(N) may transmit the request to auxiliary VNIC 1372(1)-(N), which may transmit the request to a NAT gateway, which may then transmit the request to the public internet 1354. The public internet 1354 may then transmit the request via internet gateway 1334 to one or more LB subnets 1322 contained in control plane VCN 1316. In response to determining that the request is valid, one or more LB subnets may transmit the request to one or more application subnets 1326, which may then transmit the request to cloud service 1356 via service gateway 1336.

[0165] It should be recognized that the IaaS architectures 1000, 1100, 1200, and 1300 depicted in the figures may have other components besides those depicted. Furthermore, the embodiments shown in the figures are merely some examples of cloud infrastructure systems that can be incorporated into embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown in the figures, may combine two or more components, or may have different configurations or component arrangements.

[0166] In some embodiments, the IaaS system described herein may include application suites, middleware, and database service offerings delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such an IaaS system is the Oracle Cloud Infrastructure (OCI) provided by this assignee.

[0167] Figure 14 An example computer system 1400 in which various embodiments can be implemented is illustrated. System 1400 can be used to implement any of the computer systems described above. As shown, computer system 1400 includes a processing unit 1404 that communicates with a plurality of peripheral subsystems via a bus subsystem 1402. These peripheral subsystems may include a processing acceleration unit 1406, an I / O subsystem 1408, a storage subsystem 1418, and a communication subsystem 1424. Storage subsystem 1418 includes a tangible computer-readable storage medium 1422 and system memory 1410.

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

[0169] A processing unit 1404, which may be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of the computer system 1400. One or more processors may be included in the processing unit 1404. These processors may include single-core or multi-core processors. In some embodiments, the processing unit 1404 may be implemented as one or more independent processing units 1432 and / or 1434, wherein each processing unit includes a single-core or multi-core processor. In other embodiments, the processing unit 1404 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0170] In various embodiments, processing unit 1404 can execute various programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can reside in processor(s) 1404 and / or storage subsystem 1418. With appropriate programming, processor(s) 1404 can provide the various functions described above. Computer system 1400 may additionally include processing acceleration unit 1406, which may include digital signal processor (DSP), dedicated processor, etc.

[0171] I / O subsystem 1408 may include user interface input devices and user interface output devices. User interface input devices may include keyboards, pointing devices such as mice or trackballs, touchpads or touchscreens integrated into a display, scroll wheels, click wheels, dials, buttons, switches, keyboards, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices, such as the motion sensor of Microsoft Kinect®, which enables users to control and interact with input devices such as game controllers for the Microsoft Xbox® 360 via a natural user interface using gestures and voice commands. User interface input devices may also include eye gesture recognition devices, such as the Google Glass® blink detector, which detects eye activity from the user (e.g., "blinking" when taking a photo and / or making menu selections) and translates the eye gesture into input in an input device (e.g., Google Glass®). Furthermore, user interface input devices may include voice recognition sensing devices that enable users to interact with a voice recognition system (e.g., the Siri® navigator) via voice commands.

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

[0173] User interface output devices may include display subsystems, indicator lights, or non-visual displays such as audio output devices, etc. Display subsystems may be cathode ray tubes (CRTs), flat panel devices such as those using liquid crystal displays (LCDs) or plasma displays, projection devices, touchscreens, etc. Generally, the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1400 to a user or other computer. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0174] Computer system 1400 may include storage subsystem 1418, which provides a tangible, non-transitory, computer-readable storage medium for storing software and data constructs that provide the functionality of the embodiments described in this disclosure. The software may include programs, code, instructions, scripts, etc., which, when executed by one or more cores or processors of processing unit 1404, provide the aforementioned functionality. Storage subsystem 1418 may also provide a repository for storing data used according to this disclosure.

[0175] like Figure 14 As illustrated in the example, storage subsystem 1418 may include various components, including system memory 1410, computer-readable storage medium 1422, and computer-readable storage medium reader 1420. System memory 1410 may store program instructions that can be loaded and executed by processing unit 1404. System memory 1410 may also store data used during the execution of instructions and / or data generated during the execution of program instructions. Various types of programs may be loaded into system memory 1410, including but not limited to client applications, web browsers, middleware applications, relational database management systems (RDBMS), virtual machines, containers, etc.

[0176] System memory 1410 may also store operating system 1416. Examples of operating system 1416 may include various versions of Microsoft Windows®, Apple Macintosh® and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.) and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS. In some implementations of computer system 1400 that execute one or more virtual machines, the virtual machine, along with the guest operating system (GOS), may be loaded into system memory 1410 and executed by one or more processors or cores of processing unit 1404.

[0177] System memory 1410 can be configured differently depending on the type of computer system 1400. For example, system memory 1410 can be volatile memory (such as random access memory (RAM)) and / or non-volatile memory (such as read-only memory (ROM), flash memory, etc.). Different types of RAM configurations can be provided, including static random access memory (SRAM), dynamic random access memory (DRAM), etc. In some implementations, system memory 1410 may include a basic input / output system (BIOS), which contains basic routines such as those that facilitate the transfer of information between components within computer system 1400 during startup.

[0178] Computer-readable storage medium 1422 may represent remote, local, fixed and / or removable storage devices and storage media for temporarily and / or more permanently containing and storing computer-readable information for use by computer system 1400, including instructions executable by processing unit 1404 of computer system 1400.

[0179] Computer-readable storage medium 1422 may include any suitable medium known or used in the art, including storage and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented by any method or technology for storing and / or transmitting information. This may include tangible computer-readable storage media such as RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic tape cassette, magnetic tape, disk storage or other magnetic storage devices, or other tangible computer-readable media.

[0180] As an example, computer-readable storage medium 1422 may include a hard disk drive that reads or writes to a non-removable non-volatile magnetic medium, a disk drive that reads or writes to a removable non-volatile magnetic disk, and an optical disc drive that reads or writes to a removable non-volatile optical disc (such as a CD-ROM, DVD, and Blu-ray® disc or other optical media). Computer-readable storage medium 1422 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD discs, digital audio tapes, and so on. Computer-readable storage medium 1422 may also include solid-state drives (SSDs) based on non-volatile memory (such as flash memory-based SSDs, enterprise flash drives, solid-state ROMs, etc.), volatile memory-based SSDs (such as solid-state RAM, dynamic RAM, static RAM), DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs using a combination of DRAM-based and flash memory-based SSDs. Disk drives and their associated computer-readable media can provide non-volatile storage for computer-readable instructions, data structures, program services and other data for computer system 1400.

[0181] Machine-readable instructions executable by one or more processors or cores of processing unit 1404 may be stored on a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium may include physically tangible memory or storage devices, including volatile memory storage devices and / or non-volatile memory devices. Examples of non-transitory computer-readable storage media include magnetic storage media (e.g., disks or tapes), optical storage media (e.g., DVDs, CDs), various types of RAM, ROM, or flash memory, hard disk drives, floppy disk drives, removable memory drives (e.g., USB drives), or other types of storage devices.

[0182] The communication subsystem 1424 provides an interface to other computer systems and networks. The communication subsystem 1424 serves as an interface for receiving data from other systems and sending data from computer system 1400 to other systems. For example, the communication subsystem 1424 enables computer system 1400 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 1424 may include radio frequency (RF) transceiver components (e.g., advanced data network technologies using cellular telephone technologies, such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 series standards), or other mobile communication technologies, or any combination thereof), GPS receiver components, and / or other components for accessing wireless voice and / or data networks. In some embodiments, as an addition to or alternative to the wireless interface, the communication subsystem 1424 may provide a wired network connection (e.g., Ethernet).

[0183] In some embodiments, the communication subsystem 1424 may also represent one or more users who can use the computer system 1400 to receive input communications in the form of structured and / or unstructured data feeds 1426, event streams 1428, event updates 1430, etc.

[0184] As an example, the communication subsystem 1424 may be configured to receive data feeds 1426 in real time from users of social networks and / or other communication services, such as Twitter® feeds, Facebook® updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0185] Furthermore, the communication subsystem 1424 can also be configured to receive data in the form of a continuous data stream, which may include event streams 1428 and / or event updates 1430 that are essentially continuous or unbounded real-time events without a clearly defined termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, vehicle traffic monitoring, and so on.

[0186] The communication subsystem 1424 can also be configured to output structured and / or unstructured data feeds 1426, event streams 1428, event updates 1430, etc. to one or more databases, which can communicate with one or more streaming data source computers coupled to the computer system 1400.

[0187] The computer system 1400 can be one of a variety of types, including handheld portable devices (e.g., iPhone® cellular phones, iPad® computing tablets, PDAs), wearable devices (e.g., Google® Glass head-mounted displays), PCs, workstations, mainframes, information stations, server racks, or any other data processing system.

[0188] Due to the constantly evolving nature of computers and networks, the depiction of the computer system 1400 in the figures is merely a specific example. Many other configurations with more or fewer components than the system depicted in the figures are possible. For example, custom hardware may be used and / or specific elements may be implemented using hardware, firmware, software (including applets), or a combination thereof. Additionally, connections to other computing devices, such as network input / output devices, may also be employed. Based on the disclosure and teachings provided herein, those skilled in the art will recognize other ways and / or methods for implementing the various embodiments.

[0189] While specific embodiments have been described, various modifications, alterations, alternative constructions, and equivalents are also included within the scope of this disclosure. The embodiments are not limited to operation within certain specific data processing environments, but can be freely operated within multiple data processing environments. Furthermore, although the embodiments have been described using a specific series of transactions and steps, those skilled in the art will understand that the scope of this disclosure is not limited to the described series of transactions and steps. Various features and aspects of the above embodiments can be used individually or in combination.

[0190] Furthermore, while embodiments have been described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of this disclosure. Embodiments may be implemented using only hardware, or only software, or a combination thereof. The various processes described herein can be implemented in any combination on the same processor or on different processors. Accordingly, where a component or service is described as being configured to perform certain operations, such configuration can be accomplished, for example, by designing electronic circuits to perform operations, by programming programmable electronic circuits (such as microprocessors), or any combination thereof. Processes may communicate using a variety of technologies, including but not limited to conventional technologies for inter-process communication, and different pairs of processes may use different technologies, or the same pair of processes may use different technologies at different times.

[0191] Accordingly, the specification and drawings are intended to be illustrative rather than restrictive. However, it will be apparent that additions, omissions, deletions, and other modifications and alterations may be made thereto without departing from the broader spirit and scope set forth in the claims. Thus, while specific disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

[0192] In the context of describing the disclosed embodiments (particularly in the context of the following claims), the terms "a," "an," and "the," and similar designations, are to be interpreted as covering both singular and plural, unless otherwise indicated herein or obviously contradicted by the context. Unless otherwise stated, the terms "comprising," "having," "including," and "containing" are to be interpreted as open-ended terms (i.e., meaning "including but not limited to"). The term "connected" should be interpreted as partially or wholly contained in, attached to, or joined together, even if something exists in between. Unless otherwise indicated herein, the enumeration of value ranges herein is intended only as a shorthand method for individually referencing each individual value falling within that range, and each individual value is incorporated into the specification as if it were individually enumerated herein. Unless otherwise indicated herein or obviously contradicted by the context, all methods described herein can be performed in any suitable order. The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate the embodiments and does not constitute a limitation on the scope of this disclosure, unless otherwise stated. Nothing in the specification should be construed as indicating that any unclaimed element is essential to the practice of this disclosure.

[0193] Extractive language, such as the phrase "at least one of X, Y, or Z", is intended to be understood in the context in which items, terms, etc., can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless otherwise expressly stated. Therefore, such extractive language is generally not intended to, and should not, imply that certain embodiments require the presence of at least one of X, at least one of Y, or at least one of Z, each individually.

[0194] This document describes preferred embodiments of the present disclosure, including the best modes known for carrying out the present disclosure. Variations of those preferred embodiments will become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art should be able to suitably employ such variations and may practice the present disclosure in ways other than those specifically described herein. Accordingly, the present disclosure includes all modifications and equivalents to the subject matter recited in the appended claims, where permitted by applicable law. Furthermore, unless otherwise indicated herein, the present disclosure includes any combination of the foregoing elements in all its possible variations.

[0195] All references cited in this article, including publications, patent applications and patents, are incorporated into this article by reference to the same extent as if each reference individually and specifically indicated to be incorporated by reference and elaborated in full in this article.

[0196] In the foregoing specification, various aspects of this disclosure have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that this disclosure is not limited thereto. The various features and aspects of the foregoing disclosure may be used individually or in combination. Furthermore, embodiments may be used in any number of settings and applications other than those described herein without departing from the broader spirit and scope of this specification. Accordingly, this specification and the accompanying drawings should be considered illustrative rather than restrictive.

[0197] Various embodiments and aspects of the present invention may be provided by the following numbered clauses: Clause 1: A computer-implemented method comprising: receiving, by an identity service, a first request for a first identifier of a software resource within a regional network of a distributed computing system from a client node, the first request including a first attribute associated with the software resource; generating the first identifier by the identity service at least partially based on the first attribute; sending the first identifier and a first cache instruction to the client node, the first cache instruction being available for use by the client node to prevent the first identifier from being stored in a cache associated with the client node; receiving, by the identity service, an identity rotation instruction from a manager service, the identity rotation instruction including information available for the identity service to provide a second cache instruction in response to the request for the software resource identifier; receiving, by the identity service, a second request for a second identifier of the software resource from the client node, the second request including a second attribute associated with the software resource; generating the second identifier by the identity service at least partially based on the second attribute; and sending, by the identity service, the second identifier and a second cache instruction to the client node, the second cache instruction being available for use by the client node to store the second identifier in a cache.

[0198] Clause 2: A computer-implemented method as described in Clause 1, wherein the first attribute includes a region name of a regional network, attribute values ​​of software resources, and information of a specified algorithm; and wherein generating the first identifier includes using the algorithm and taking the region name and attribute values ​​as input to generate a globally unique identifier.

[0199] Clause 3: A computer-implemented method as described in Clause 1 or 2, wherein the second attribute includes a new area name of the area network, attribute values ​​of the software resources, and information about a specified algorithm; and wherein generating the second identifier includes using the algorithm and taking the new area name and attribute values ​​as input to generate a globally unique identifier.

[0200] Clause 4: A computer-implemented method as described in any one of Clauses 1-3, wherein the first attribute includes a region name of a regional network, and the method further includes: determining, by an identity service, whether a region name matches an expected region name of the regional network, the expected region name being stored by the identity service, before generating a first identifier; and generating the first identifier based at least in part on the determination that the region name matches the expected region name.

[0201] Clause 5: The method described in Clause 4 further includes sending an error message to the client node based at least in part on an additional determination that the region name does not match the expected region name.

[0202] Clause 6: The method described in any of Clauses 1-5, wherein the rotation instruction includes second information on the new expected area name of the specified area network.

[0203] Clause 7: The method as described in Clause 6, wherein the second attribute includes a new area name of the area network, and the method further includes: determining, by an identity service, whether the new area name matches a new expected area name of the area network before generating the second identifier; and generating the second identifier based at least in part on the determination that the new area name matches the new expected area name.

[0204] Clause 8: The method described in Clause 7 further includes sending an error message to the client node based at least in part on an additional determination that the new zone name does not match the new expected zone name.

[0205] Clause 9: A distributed computing system includes one or more processors; and one or more memories storing computer-executable instructions, which, when executed by the one or more processors, cause the distributed computing system to: receive, by an identity service, a first request for a first identifier of a software resource within a regional network of the distributed computing system, the first request including a first attribute associated with the software resource; generate the first identifier by the identity service based at least in part on the first attribute; send the first identifier and a first cache instruction to the client node, the first cache instruction being available for use by the client node to prevent the first identifier from being stored in a cache associated with the client node; receive an identity rotation instruction from a manager service, the identity rotation instruction including information available for the identity service to provide a second cache instruction in response to the request for the software resource identifier; receive, by the identity service, a second request for a second identifier of a software resource from the client node, the second request including a second attribute associated with the software resource; generate the second identifier by the identity service based at least in part on the second attribute; and send the second identifier and a second cache instruction to the client node, the second cache instruction being available for use by the client node to store the second identifier in a cache.

[0206] Clause 10: A distributed computing system as described in Clause 9, wherein the first attribute includes the region name of the regional network, the attribute value of the software resource, and information of the specified algorithm; and wherein generating the first identifier includes using the algorithm and taking the region name and attribute value as input to generate a globally unique identifier.

[0207] Clause 11: A distributed computing system as described in Clause 9 or 10, wherein the second attribute includes a new region name of the regional network, attribute values ​​of the software resources, and information about a specified algorithm; and wherein generating the second identifier includes using the algorithm and taking the new region name and attribute values ​​as input to generate a globally unique identifier.

[0208] Clause 12: A distributed computing system as described in any of Clauses 9-11, wherein the first attribute includes a region name of a regional network, and wherein the one or more memories store additional instructions that, when executed by the one or more processors, cause the distributed computing system to further: determine, before generating a first identifier, whether a region name matches an expected region name of the regional network, the expected region name being stored by the identity service; and generate the first identifier based at least in part on the determination that the region name matches the expected region name.

[0209] Clause 13: A distributed computing system as described in Clause 12, wherein the one or more memories store additional instructions that, when executed by the one or more processors, cause the distributed computing system to send an error message to a client node, at least in part, based on an additional determination that the region name does not match the expected region name.

[0210] Clause 14: A distributed computing system as described in any of Clauses 9-13, wherein the rotation instruction includes second information specifying a new expected area name for the area network.

[0211] Clause 15: A distributed computing system as described in Clause 14, wherein the second attribute includes a new region name of the regional network, and wherein the one or more memories store additional instructions that, when executed by the one or more processors, cause the distributed computing system to further: determine by an identity service whether the new region name matches a new expected region name of the regional network before generating the second identifier; and generate the second identifier based at least in part on the determination that the new region name matches the new expected region name.

[0212] Clause 16: A distributed computing system as described in Clause 15, wherein the one or more memories store additional instructions that, when executed by the one or more processors, cause the distributed computing system to send an error message to a client node, at least in part, based on an additional determination that the new region name does not match the new expected region name.

[0213] Clause 17: A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by one or more processors, cause a distributed computing system to receive, by an identity service, a first request for a first identifier of a software resource within a local area network of the distributed computing system from client nodes within the local area network, the first request including a first attribute associated with the software resource; generate the first identifier by the identity service at least in part based on the first attribute; send the first identifier and a first cache instruction to the client nodes by the identity service, the first cache instruction being available for use by the client nodes to prevent the first identifier from being stored in a cache associated with the client nodes; receive an identity rotation instruction from a manager service by the identity service, the identity rotation instruction including information available for the identity service to provide a second cache instruction in response to the request for the software resource identifier; receive a second request for a second identifier of a software resource from the client nodes by the identity service, the second request including a second attribute associated with the software resource; generate the second identifier by the identity service at least in part based on the second attribute; and send the second identifier and a second cache instruction to the client nodes by the identity service, the second cache instruction being available for use by the client nodes to store the second identifier in a cache.

[0214] Clause 18: A non-transitory computer-readable medium as described in Clause 17, wherein the first attribute includes the area name of the area network, the attribute value of the software resource, and information of the specified algorithm; and wherein generating the first identifier includes using the algorithm and taking the area name and attribute value as input to generate a globally unique identifier.

[0215] Clause 19: A non-transitory computer-readable medium as described in Clause 17 or 18, wherein the second attribute includes a new area name of the area network, attribute values ​​of the software resources, and information about a specified algorithm; and wherein generating the second identifier includes using the algorithm and taking the new area name and attribute values ​​as input to generate a globally unique identifier.

[0216] Clause 20: A nontransitory computer-readable medium as described in any of Clauses 17-19, wherein a first attribute includes a region name of a regional network and stores additional instructions that, when executed by the one or more processors, cause the distributed computing system to further: determine, before generating a first identifier, whether a region name matches an expected region name of the regional network, the expected region name being stored by the identity service; and generate a first identifier based at least in part on the determination that the region name matches the expected region name.< / uuid> < / region> < / realm> < / type>

Claims

1. A computer-implemented method, comprising: The identity service receives a first request for a first identifier of a software resource within the regional network from a client node within the regional network of the distributed computing system. The first request includes a first attribute associated with the software resource. The first identifier is generated by the identity service based at least in part on the first attribute; The identity service sends a first identifier and a first cache instruction to the client node. The first cache instruction can be used by the client node to prevent the first identifier from being stored in the cache associated with the client node. The identity service receives an identity rotation instruction from the manager service. The identity rotation instruction includes information that the identity service can use to provide a second cache instruction in response to a request for a software resource identifier. The identity service receives a second request for a second identifier of a software resource from the client node, the second request including a second attribute associated with the software resource; The identity service generates a second identifier based at least in part on the second attribute; as well as The identity service sends a second identifier and a second cache instruction to the client node. The second cache instruction can be used by the client node to store the second identifier in the cache.

2. The computer-implemented method of claim 1, wherein the first attribute includes the region name of the regional network, the attribute value of the software resource, and information of the specified algorithm; and wherein generating the first identifier includes using the algorithm and taking the region name and attribute value as input to generate a globally unique identifier, and / or wherein the second attribute includes the new region name of the regional network, the attribute value of the software resource, and information of the specified algorithm; and wherein generating the second identifier includes using the algorithm and taking the new region name and attribute value as input to generate a globally unique identifier.

3. The computer-implemented method as described in claim 1 or 2, wherein the first attribute includes the area name of the regional network, and further includes: Before generating the first identifier, the identity service determines whether the area name matches the expected area name of the area network, which is stored by the identity service. as well as The first identifier is generated based at least in part on the determination that the region name matches the expected region name.

4. The method of claim 3, further comprising sending an error message to the client node based at least in part on an additional determination that the region name does not match the expected region name.

5. The method of any one of claims 1-4, wherein the rotation instruction includes second information specifying a new expected area name for the area network.

6. The method of claim 5, wherein the second attribute includes a new area name for the regional network, and further includes: Before generating the second identifier, the identity service determines whether the new zone name matches the new expected zone name of the zone network; A second identifier is generated, at least in part, based on the determination that the new region name matches the new expected region name; and An error message is sent to the client node, at least in part based on the additional determination that the new region name does not match the new expected region name.

7. A distributed computing system, comprising: One or more processors; as well as One or more memories storing computer-executable instructions, which, when executed by the one or more processors, cause the distributed computing system to: The identity service receives a first request for a first identifier of a software resource within the regional network from a client node within the regional network of the distributed computing system. The first request includes a first attribute associated with the software resource. The first identifier is generated by the identity service based at least in part on the first attribute; The identity service sends a first identifier and a first cache instruction to the client node. The first cache instruction can be used by the client node to prevent the first identifier from being stored in the cache associated with the client node. The identity service receives an identity rotation instruction from the manager service. The identity rotation instruction includes information that the identity service can use to provide a second cache instruction in response to a request for a software resource identifier. The identity service receives a second request for a second identifier of a software resource from the client node, the second request including a second attribute associated with the software resource; The identity service generates a second identifier based at least in part on the second attribute; as well as The identity service sends a second identifier and a second cache instruction to the client node. The second cache instruction can be used by the client node to store the second identifier in the cache.

8. The distributed computing system of claim 7, wherein the first attribute includes the region name of the regional network, the attribute value of the software resource, and information of the specified algorithm; and wherein generating the first identifier includes using the algorithm and taking the region name and attribute value as input to generate a globally unique identifier, and / or wherein the second attribute includes the new region name of the regional network, the attribute value of the software resource, and information of the specified algorithm; and wherein generating the second identifier includes using the algorithm and taking the new region name and attribute value as input to generate a globally unique identifier.

9. The distributed computing system of claim 7 or 8, wherein the first attribute includes a region name of a regional network, and wherein the one or more memories store additional instructions that, when executed by the one or more processors, cause the distributed computing system to also: Before generating the first identifier, the identity service determines whether the region name matches the expected region name of the regional network; the expected region name is stored by the identity service. The first identifier is generated based at least in part on the determination that the region name matches the expected region name.

10. The distributed computing system of claim 9, wherein the one or more memories store additional instructions that, when executed by the one or more processors, cause the distributed computing system to send an error message to a client node, at least in part, based on an additional determination that the region name does not match the expected region name.

11. The distributed computing system of any one of claims 7-10, wherein the rotation instruction includes second information specifying a new expected region name for the specified regional network.

12. The distributed computing system of claim 11, wherein the second attribute includes a new region name for the regional network, and wherein the one or more memories store additional instructions that, when executed by the one or more processors, cause the distributed computing system to further: Before generating the second identifier, the identity service determines whether the new zone name matches the new expected zone name of the zone network; A second identifier is generated, at least in part, based on the determination that the new region name matches the new expected region name; and An error message is sent to the client node, at least in part based on the additional determination that the new region name does not match the new expected region name.

13. A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by one or more processors, cause a distributed computing system to: The identity service receives a first request for a first identifier of a software resource within the regional network from a client node within the regional network of the distributed computing system. The first request includes a first attribute associated with the software resource. The first identifier is generated by the identity service based at least in part on the first attribute; The identity service sends a first identifier and a first cache instruction to the client node. The first cache instruction can be used by the client node to prevent the first identifier from being stored in the cache associated with the client node. The identity service receives an identity rotation instruction from the manager service. The identity rotation instruction includes information that the identity service can use to provide a second cache instruction in response to a request for a software resource identifier. The identity service receives a second request for a second identifier of a software resource from the client node, the second request including a second attribute associated with the software resource; The identity service generates a second identifier based at least in part on the second attribute; as well as The identity service sends a second identifier and a second cache instruction to the client node. The second cache instruction can be used by the client node to store the second identifier in the cache.

14. The non-transitory computer-readable medium of claim 13, wherein the first attribute includes a region name of a regional network, attribute values ​​of software resources, and information about a specified algorithm; and wherein generating the first identifier includes using an algorithm and taking the region name and attribute values ​​as input to generate a globally unique identifier, and / or wherein the second attribute includes a new region name of a regional network, attribute values ​​of software resources, and information about a specified algorithm; and wherein generating the second identifier includes using an algorithm and taking the new region name and attribute values ​​as input to generate a globally unique identifier.

15. The non-transitory computer-readable medium of claim 13 or 14, wherein the first attribute includes a region name of a regional network, and stores additional instructions that, when executed by the one or more processors, cause the distributed computing system to further: Before generating the first identifier, the identity service determines whether the region name matches the expected region name of the regional network; the expected region name is stored by the identity service. The first identifier is generated based at least in part on the determination that the region name matches the expected region name.

Images