Static network structure at prefabrication plant

Abstract

Techniques for prefabricating a networking fabric in a data center of a plant are disclosed. A networking fabric may include a plurality of networking cables routed through a data center, the networking cables being characterized by a static network fabric topology, where groups of networking cables of the plurality of networking cables are configured to terminate at locations in the data center. A plurality of computing devices may be positioned at the location and configured to form a regional network according to the connection plan when communicatively connected to the set of networking cables. The connection plan may be generated by a network service using a physical build request. A network service may determine a configuration of a plurality of computing devices and a static network fabric topology. The network service may generate a connection plan using the configuration and the static network fabric topology.

Description

[0001] Cross-references to related applications

[0002] This application is an international application filed on March 16, 2023, entitled “STATIC NETWORK FABRIC AT A PREFABFACTORY”, U.S. Non-Provisional Application No. 18 / 122,676 (Attorney’s Case No. 088325-1328941 (344010US)), and claims priority and interest thereto. This application also claims priority and interest in the following related applications:

[0003] (1) U.S. Non-Provisional Application No. 18 / 122,674, entitled “TECHNIQUES FOR BUILDING CLOUD REGIONS ATA PREFAB FACTORY”, filed on March 16, 2023, Attorney’s Case No. 088325-1307191 (344000US);

[0004] (2) U.S. Nonprovisional Application No. 18 / 122,677, entitled “MOBILE PREFAB FACTORY FOR BUILDING CLOUDREGIONS”, filed on March 16, 2023, Attorney’s Case No. 088325-1328942 (344020US);

[0005] (3) U.S. Non-Provisional Application No. 18 / 122,678, filed on March 16, 2023, entitled “TECHNIQUES FOR A CABLE TERMINATION PROTECTION APPARATUS IN A PREFAB FACTORY,” Attorney’s File No. 088325-1328943 (344030US); and

[0006] (4) U.S. Nonprovisional Application No. 18 / 122,675, entitled “TECHNIQUES FOR VALIDATING CLOUD REGIONSBUILT AT A PREFAB FACTORY”, filed on March 16, 2023, Attorney’s Case No. 088325-1373430 (344040US).

[0007] The entire contents of the above application are incorporated herein by reference for all purposes. Technical Field

[0008] This disclosure relates to cloud computing data centers. More specifically, this disclosure describes techniques for implementing static network structures within a prefabrication plant for use in building regional data centers. Background Technology

[0009] 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 compute, 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 compute resources, configuring infrastructure, and deploying code to those resources, typically via network connections to the data center. However, building a region using 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

[0010] Embodiments of this disclosure relate to the automated construction of regions using a prefabrication plant. A prefabrication plant can be a facility dedicated to 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., within a geographic area). The operation of constructing a region may include bootstrapping (e.g., provisioning and / or deployment) resources (e.g., infrastructure components, artifacts, etc.) to obtain any suitable number of available services from the region upon delivery to the destination. Once the physical resources have been configured at the prefabrication plant, 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). Constructing regions can be orchestrated by one or more cloud-based services that can manage an inventory of physical computing devices used to construct regions in the prefabrication plant, generate and specify configurations for regions to be constructed in the prefabrication plant, manage the bootstrapping of regions, configure regions for delivery to the destination site, and test and validate physical resources after they have been installed at the destination site. Prefabricated areas can be built to meet specific customer configuration preferences (built to order) or built to a generic specification that can be further customized during installation at a specific customer site (built to stock).

[0011] One embodiment relates to a system comprising a data center serving as a prefabrication plant, the data center having a networking structure that provides network connectivity between devices within the data center. The networking structure may include networking cables and other physical components for establishing network connections between computing devices. For example, within a prefabrication plant data center, multiple networking cables may be installed and configured to terminate at locations within the data center where devices can be located (e.g., server racks with networking devices, server equipment, etc.). Multiple networking cables may also be connected to one or more networking devices (e.g., switches, routers, etc.) within the data center to form a static network topology between the networked devices. A local area network can be formed when computing devices are communicatively connected to the networking cables according to a connectivity plan. The connectivity plan may be generated based on the configuration of the computing devices (e.g., the configuration and connectivity of the computing devices with the networking devices on each server rack) and the static network topology (e.g., the configuration of the networking infrastructure within the data center).

[0012] Another embodiment relates to a method for generating a connectivity plan that can be used to connect a network cable group of a static network structure in a data center to a networking device for multiple computing devices. The multiple computing devices may include computing devices for a region being built in a data center (e.g., a prefabrication plant). For example, during region construction, multiple server racks may be located in the prefabrication plant to connect to the prefabrication plant's static network structure. The selection and location of the server racks may be in response to a physical build request specifying which computing devices to include in the region construction operation. A networking service for prefabrication services performed in a cloud computing environment can use the physical build request to determine the configuration of the computing devices and the static network structure topology of the data center, and then generate a connectivity plan. The connectivity plan may include instructions (e.g., from data center personnel) to connect network cables (e.g., terminating each network cable in a network cable group at a server rack location) to the corresponding network ports of the networking devices (e.g., connecting a prefabrication plant network cable to a rack-top switch on a server rack).

[0013] Another embodiment relates to a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors of a computing system, cause the 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

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

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

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

[0017] Figure 3 The diagram illustrates a block diagram of a CSP system comprising multiple host regions according to at least one embodiment, which can support ViBE for deploying software resources to prefabricated regions being built at a prefabrication plant.

[0018] Figure 4 This is a block diagram illustrating the arrangement of physical computing resources in a prefabrication plant managed by a manager service and an inventory service according to at least one embodiment.

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

[0020] Figure 6 This diagram illustrates the use of a manager service and a test service to test and evaluate a region after delivery to a destination site, according to at least one embodiment.

[0021] Figure 7 This is an example method according to at least one embodiment for deploying software resources to physical resources in an area being built in a prefabrication plant and preparing physical resources for transport to a destination data center.

[0022] Figure 8 This is an example method according to at least one embodiment for initiating and verifying the network configuration of physical resources built at a prefabrication plant after delivery to a destination data center.

[0023] Figure 9 This is a block diagram illustrating an example static network structure in a prefabrication plant according to at least one embodiment.

[0024] Figure 10A and Figure 10B This is a diagram illustrating an example arrangement of physical computing resources connected to a static network structure in a prefabrication plant according to some embodiments.

[0025] Figure 11This is an example method according to at least one embodiment for generating a networked cable group for connecting multiple computing devices to a static network structure in a prefabrication plant.

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

[0027] 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.

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

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

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

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

[0032] The adoption of cloud services has recently seen rapid growth. Currently, various cloud service providers (CSPs) offer a wide range of cloud services. The term cloud service is generally used to refer to services or functions made available 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 make up 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 the 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 easy, scalable, and on-demand access to applications and computing resources without requiring customers to invest in the infrastructure used to provide the services or functions. 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.

[0033] As described above, the CSP is responsible for providing the infrastructure and resources used to deliver cloud services to subscribing customers. 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), storage resources (e.g., databases, data storage), networking resources (e.g., routers, hosts, 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 data centers. A 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 needed to deliver that specific set of cloud services. The CSP can build one or more data centers.

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

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

[0036] As mentioned 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 growing needs of its customers and improve customer service. Preferably, data centers are built with geographical proximity to the locations of the customers they serve. Geographical proximity between a data center and its customers results in lower latency, leading to more efficient use of resources and faster, more reliable service delivery to customers. Therefore, CSPs often build new data centers in new regions geographically close to the customers they serve. For example, for a growing customer base in Germany, a CSP might build one or more data centers in new regions of Germany.

[0037] Building and configuring data centers (or multiple data centers) within a region 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 required or used to provide a set of services that the data centers are configured to offer. The end result of the region building process is the creation of a region in which data centers, along with their contained hardware and software resources, are capable of providing a set of services intended for that region and include a set of resources for providing those services.

[0038] Building a new region is a highly complex activity requiring extensive coordination among various bootstrapping activities. At a high level, this involves the execution and coordination of various tasks, such as: identifying the service groups to be provided by the data center; identifying the various resources required to provide those 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 need to be coordinated, further increasing the complexity. Due to this complexity, currently, region building involves several manually initiated or manually controlled tasks that require careful manual coordination. Therefore, 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, the process is highly error-prone, sometimes requiring several iterations before the desired configuration of the region is achieved, 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 respond to growing customer demands and scale up computing resources in a timely manner.

[0039] Recent innovations allow CSPs to reduce build time, minimize 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 regions separate from the target region (e.g., orchestration regions). 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.

[0040] More recent innovations allow CSPs to centralize region building operations at one or more facilities that act as “factories” to produce partially or fully configured physical infrastructure for subsequent delivery to destination sites. Instead of waiting for the fabrication of the target region’s data center and the installation of physical components (e.g., servers, network switches, power supplies, etc.) at the data center before services are bootstrapped to the target region, CSPs can build regions in a prefabrication plant, ship configured physical components (like racks) to the destination data center, and then finalize and validate the region’s components once the racks arrive at the destination site. A prefabrication plant can build multiple regions simultaneously. Each region built at the prefabrication plant can have separate configurations, network topologies, and services. By building regions at the 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.

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

[0042] Centralized prefabrication plants support additional innovation in the construction of zones in an efficient manner. A prefabrication plant can include a static network structure, consisting of network infrastructure (e.g., network switches, routers, cabling, etc.), designed to support any potential configuration of zone components built within the plant. Therefore, a static network structure allows the physical resources of a zone to be placed within the plant and quickly connected to an existing network structure. Zones with different network topologies can also be quickly connected to the same network structure based on a connectivity plan that matches the static network structure to the physical components of the zone. A static network structure reduces the complexity of network connectivity within zones within the plant, increasing the speed at which zone components are installed in and removed from the plant for transmission. Complementarily, because the static network structure provides a dedicated set of network connections for equipment at different locations within the prefabrication plant, these connections can be protected by cable terminal protection devices (CTPAs), which are designed to accommodate every possible network connection (e.g., Ethernet, fiber optic, etc.) that can be used to connect a zone to the plant network.

[0043] 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 at 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 at 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 transport (including encrypting data volumes to provide security during transit), verify regions upon delivery to and installation at the destination site, and ultimately determine the region configuration, including performing any remaining bootstrap or update operations on services previously deployed to the region infrastructure at the prefabrication plant. Furthermore, this disclosure describes features of the prefabrication plant itself that improve the automated region building activities therein, including a static network structure of the prefabrication plant configured to support any potential region network topology without requiring ad hoc modifications, and support for dedicated CTPA to improve the performance of the static network structure. Finally, this disclosure also describes a mobile prefabrication plant that can perform some, any, or all of the operations related to automated regional construction within the prefabrication plant while regional components are being transported to the destination site.

[0044] Some definitions

[0045] 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 may 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, an execution target may correspond to a destination data center rather than a prefabricated factory data center.

[0046] An "execution target" is the smallest unit of change used to perform a release. A "release" is an indication of an 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).

[0047] A “bootstrapping” service is defined as a set of tasks associated with the provisioning and deployment of any appropriate number of resources (e.g., infrastructure components, artifacts, etc.) corresponding to that single service. A bootstrapping region is defined as a set of tasks associated with each bootstrapping service within that region.

[0048] A "service" refers to a set of resources that provide functionality, typically in the form of an API, which a client can invoke to achieve useful results. The set of resources used 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. The service can be made available to users via the internet.

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

[0050] IaaS provisioning (or "provisioning") refers to acquiring a computer or virtual host for use, and even installing the necessary libraries or services on it. The phrase "provisioning device" refers to evolving a device to a state where it can be used by end users for their specific purposes. A device that has undergone the provisioning process can be referred to as a "provisioned device." Preparing a provisioned device (installing libraries and daemons) may 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 referred to as an "infrastructure component."

[0051] 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 are provisioned (e.g., acquired, allocated, prepared, etc.), additional software can be deployed (e.g., providing additional software to the infrastructure components and installing it on them). 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.

[0052] 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 tunnel (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 System (DNS) services, 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 prevents circular dependencies between boot resources by leveraging the resources of the host zone. Services can be prepared and tested in stages within the ViBE before a pre-provisioned zone (e.g., a target zone) becomes available.

[0053] "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 work in conjunction with one or more additional prefabrication services to orchestrate region builds in the prefabrication plant and to manage how the prefabricated regions are installed and configured at the 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.

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

[0055] A "target area" refers to an area built within the prefabrication plant. During the prefabrication process, the target area is associated with the physical space, power, and cooling provided by the prefabrication plant. Once the prefabricated area has been transported to its destination data center, it becomes associated with the data center to which it is installed.

[0056] Prefabricated area construction

[0057] In some examples, this paper describes techniques for building regions at a prefabrication plant. As briefly described above, such techniques 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 the infrastructure components (e.g., provisioning and deploying software) of 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 infrastructure within the prefabrication plant to independently provide network connectivity for each region, enabling each region to communicate with prefabrication services and / or other cloud services to support region builds. Based on the build request (region specifications, such as the number of server racks, number of computing devices, number and type of services to be hosted in the region, network topology of the region, etc.), the prefabrication service can generate instructions to install the corresponding physical infrastructure in the prefabrication plant (e.g., by plant personnel). This may include networking physical devices together on their racks, positioning racks within the prefabrication plant, and connecting devices to the static network structure of the prefabrication plant. The manager service can then orchestrate the provisioning of the region infrastructure and software resources to the deployment of the prefabricated region infrastructure, configure the prefabricated region for transport, manage (e.g., schedule and monitor) the transport of the prefabricated region, and perform testing and validation on the prefabricated region once it arrives at its destination site.

[0058] Prefabrication plants can centralize the zone construction process to provide more efficient use of the compute and networking resources supporting zone construction. For example, a prefabrication plant might be located "proximity" to a host area that includes prefabrication services and / or ViBE (e.g., with low-latency and high-data-rate networking connections to the host area of ​​prefabrication services and / or ViBE). Multiple zones can be built using the improved performance of network connections to the host area, avoiding the potential performance deficiencies of traditional zone construction when performing zone construction on new data center sites. Prefabrication plants also provide improved physical and compute security for equipment during zone construction because the CSP can control the prefabrication plant and the network connections within it.

[0059] 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, improving efficiency.

[0060] 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 transfer 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, devices in the regions can be installed and prepared in stages in the prefabrication plant 102 prior to the commencement of infrastructure provisioning and software deployment operations.

[0061] 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 may operate an existing data center in 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 constructed within prefabrication plant 102. Additionally or alternatively, the location of prefabrication plant 102 can be determined to improve logistical operations, including delivery from the region to the destination data center.

[0062] The prefabricated areas constructed in prefabrication plant 102 can include any suitable number of physical resources, including computing devices (e.g., servers, racks of multiple servers, etc.), storage (e.g., block storage devices, object storage devices, etc.), networking devices (e.g., switches, routers, gateways, etc.). Depending on the specific requirements of the destination area and data center, each area may have different physical resources. 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 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.

[0063] 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 constructed. For example, prefabrication plant 102 may include any suitable number of leaf switches and backbone 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 cabling installed in the facility that provides network connectivity to the networking infrastructure of prefabrication plant 102. The network cabling may be positioned to terminate at locations where the computing device racks of the prefabricated area can be installed during the area construction operation within prefabrication plant 102. The following is about... Figure 9-11 Provide additional details about the network infrastructure and configuration of the prefabrication plant.

[0064] Prefabrication plant 102 can connect to the 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 onto the supplied infrastructure components. For example, CSP 104 can provision computing devices for 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 be executed on the supplied infrastructure. When the equipment is installed at the destination facility, the prefabrication region can be brought to a state close to the final production state of the equipment.

[0065] 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 taking 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 the snapshot including identifiers of each device in the network and its neighbors, 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 taken from fully configured individual switches, computing devices, and smart NICs in the various racks to be transported to the destination site. Device snapshots enable rapid replacement of any device transported from a rack if that device is not functional upon arrival and must be replaced. Transport to the destination facility can be made by one or more methods, including transport 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.

[0066] Once the computing devices of the prefabricated areas arrive at the destination facility, they can be installed on the facility according to its configuration. The destination facility may be a data center built to host the prefabricated area devices, providing networking, power, cooling, and other infrastructure according to the prefabricated area's configuration. The data center may have a network connection to CSP 104. The installation of the prefabricated areas may include manual operations of connecting racks and their computing devices to the data center's network infrastructure and other related tasks. Once the physical connections have been established, the devices in the prefabricated areas can be powered on, which can initiate one or more test operations based on the configuration performed at the prefabrication plant 102 prior to transmission. The prefabricated areas may also be connected 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 be connected to CSP 104 via connection 118, while prefabricated area 106C may be connected to CSP 104 via connection 116. The prefabrication service can deploy the final configuration for the installed devices, deploy updates to the software resources on the installed devices, and perform additional testing and verification operations for the prefabricated areas at the destination data center.

[0067] Figure 2 This 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 1An example of prefabrication plant 102, while 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 (like the Internet), a private network, or another network. Prefabrication service 210 may include manager service 212, inventory service 214, testing 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 being built in prefabrication plant 202.

[0068] Manager service 212 can perform tasks to coordinate 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 usable by 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 in prefabrication area 206, the number of networking devices that can be used to connect the server devices to form a network in prefabrication area 206, and determining a connection plan for the specified server devices, networking devices, and the existing network infrastructure of prefabrication plant 20. Physical build requests can also include instructions for personnel to retrieve physical equipment from an associated location (e.g., physical inventory 224) and to install the equipment in prefabrication plant 202 at the specified location. In some embodiments, the operation of physical build requests can be performed by an automated system under the control of Manager Service 212. For example, retrieving server equipment racks from physical inventory 224 and installing the racks at prefabrication plant 202 can be performed by a robotic system configured to move physical racks from one site to another.

[0069] 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 during the prefabrication zone construction process. For example, inventory service 214 can determine whether a physical device is located at prefabrication plant 202 or a destination site. Inventory service 214 can query devices via a network (e.g., network 208) to determine their location and / or association with regions, prefabrication zones, or data centers. 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, when physical devices are received at physical inventory 224, inventory service 214 can track them and then retrieve them from physical inventory 224 to use them as part of the 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 to retrieve physical resources from physical inventory 224 and install the physical resources at prefabrication plant 202.

[0070] Physical inventory 224 may be a warehouse or storage facility for storing physical resources (e.g., computing devices) for use 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. Physical resources may be placed into and retrieved from physical inventory 224 by personnel associated with CSP and prefabrication plant 202. In some cases, the retrieval and installation of physical resources from physical inventory 224 during prefabrication area construction operations may be accomplished by robots, automated guided vehicles, or other similar autonomous or semi-autonomous systems using instructions provided by physical construction requests.

[0071] Orchestration service 218 can be configured to perform bootstrapping operations to provision infrastructure components in prefabrication zone 206 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 configuration files 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 configuration files to identify dependencies between resources. Orchestration service 218 can generate specific data structures from 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 boot the service, when booting is blocked, and / or when booting operations associated with previously blocked services can be resumed.

[0072] 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 the need for changes to one or more resources by comparing the desired state data with the current state data. For example, orchestration service 218 may determine that one or more infrastructure components need to be provisioned, one or more artifacts need to be deployed, or any appropriate changes need to be made to the resources of the service to bring the state of those resources into alignment with the desired state. Specific details of a particular implementation 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.

[0073] ViBE 222 can be an example of a boot environment used to deploy resources to prefabrication areas within prefabrication plant 202. ViBE may include a virtual cloud network (e.g., a cloud resource network) implemented within a suitable area of ​​a CSP (e.g., CSP 204). ViBE may 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 may deploy instances of one or more component services of orchestration service 218 to the boot environment (e.g., instances 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 within an existing area, any suitable amount of area infrastructure is provisioned to support services deployed within ViBE (compared to the fixed hardware resources of a seed server). Orchestration service 218 can be configured to supply infrastructure resources (e.g., virtual machines, compute instances, storage, etc.) to ViBE 222 in addition to deploying software resources to ViBE 222. ViBE 222 can simultaneously support boot operations for more than one prefabrication zone in prefabrication plant 202.

[0074] When prefabrication zone 206 is available to support bootstrapping operations, ViBE 222 can connect to prefabrication zone 206, allowing services in ViBE 222 to interact with services and / or infrastructure components in prefabrication zone 206. Instead of a separate seed service as in previous systems, this enables the deployment of production-grade services and will require internet connectivity to the target zone. Traditionally, seed services are deployed as part of a collection of containers and are used to bootstrap dependencies necessary for expanding the zone. Using existing zone infrastructure / tools, resources can be bootstrapped into ViBE 222 and connected to prefabrication zone 206 to provision hardware and deploy services until prefabrication zone 206 becomes self-sufficient (e.g., self-sufficient in terms of services hosted within prefabrication zone 206). Utilizing ViBE 222 allows the establishment of necessary dependencies and services to provision / prepare infrastructure and deploy software, while leveraging resources in the host zone to break circular dependencies in core services.

[0075] Test service 216 can be configured to perform one or more test or verification operations on prefabrication zone 206 after resource provisioning and / or deployment. Test operations may be part of user acceptance testing used to determine whether the behavior of the prefabrication zone conforms to the build specifications. For example, test service 216 may perform tests interacting with service instances deployed to prefabrication zone 206 to verify the expected operation of the queried service. As another example, test service 216 may perform networking tests to obtain the hostname, networking address, and / or other identifiers of components in prefabrication zone 206 for comparison with the expected identifiers of components in prefabrication zone 206 as specified in the build request or other specifications. Test service 216 may perform test operations during the prefabrication zone construction process at prefabrication plant 202 and after delivery of prefabrication zone 206 to the destination site. Test operations performed at prefabrication plant 202 may be the same as or different from test operations performed after prefabrication zone 206 is delivered to the destination site.

[0076] Network service 220 can be configured to determine the network configuration of devices in prefabrication zone 206. Network service 220 can use configuration information from build requests to determine the network topology of devices (e.g., servers, networking devices, racks of servers and networking devices, etc.). As used herein, network topology can refer to a graphical representation of all networking connections between each computing device in the prefabrication zone. Network service 220 can use the configuration information to determine the physical networking connections (e.g., network cabling connections) to be made between devices in the prefabrication zone. Network service 220 can provide networking connection information to manager service 212 for generating instructions for physically installing devices in the prefabrication zone in prefabrication plant 202. Network service 220 can also obtain device information from inventory service 214 as part of determining the network topology of devices in the prefabrication zone. The following is about... Figure 5 and 6 Additional details regarding network service 220 are provided.

[0077] Figure 3 This is a block diagram illustrating a CSP system 300 according to at least one embodiment. The CSP system 300 includes multiple host regions (e.g., host regions 304A-304C) that may support ViBEs (e.g., ViBEs 308A-308C) for deploying software resources to a prefabricated region 306 constructed at a prefabrication plant 302. The prefabrication plant 302 may be as described above. Figure 2 The example described is a prefabrication plant 202. Similarly, ViBE 308A-308C can each be... Figure 2 The example of ViBE 222, while management service 312 can be... Figure 2Example of Manager Service 212. Host zones 304A-304C can correspond to CSP zones and can be associated with one or more data centers that have computing resources for hosting ViBE. Host zones 304A-304C can correspond to different geographical locations.

[0078] like Figure 3 As shown, Manager Service 312 can be an instance within a host region (e.g., host region 304B). In some embodiments, Manager Service 312 can correspond to a CSP tenant, and therefore can have instances in multiple regions (e.g., host regions 304A, 304C) from which prefabricated services can be provided. Similarly, other prefabricated services (e.g., prefabricated service 210) can also be service instances within a host region.

[0079] ViBE can be hosted within a host region to support prefabrication region construction operations at prefabrication plant 302. Because ViBE can be constructed by an orchestration service (e.g., orchestration service 218) as needed to guide prefabrication regions, ViBE can be built in any suitable host region. The suitability of a host region can be based on network connectivity with prefabrication plant 302 (e.g., high-bandwidth, high-data-rate, low-latency network connectivity between the host region's data centers and prefabrication plant 302), sufficient infrastructure resources to support ViBEs used for one or more prefabrication region construction operations (e.g., availability of computing resources in the host region for the duration of provisioning and deployment of one or more prefabrication regions), and / or jurisdictional considerations (e.g., host regions in the same country as the prefabrication plant to comply with regulations regarding data security). For example, host region 304A may include a data center located near prefabrication plant 302, resulting in a low-latency network connectivity between ViBE 308A and prefabrication region 306. During successive prefabrication region construction operations, ViBEs used to support prefabrication region construction may be constructed in different host regions. For example, ViBE 308A may be used as part of a prefabrication region constructed at prefabrication plant 302 for one prefabrication region, but then ViBE 308B in host region 304B or ViBE 308C in host region 304C may be constructed and used for subsequent region construction operations.

[0080] Furthermore, prefabrication plant 302 can be constructed in a location to provide suitable connectivity to one or more host areas. For example, prefabrication plant 302 can be constructed at a site adjacent to the data center of host area 304A to provide suitable network connectivity between host area 304A and prefabrication plant 302.

[0081] Figure 4This is a block diagram illustrating a CSP system 400 according to at least one embodiment, which has an arrangement of physical computing resources for different prefabrication zones 430, 440 in a prefabrication plant 402. The prefabrication plant 402 may be... Figure 2 Example of a prefabrication plant 202. Prefabrication service 410 can be provided by a 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 412 as Figure 2 The inventory service 214 is an example of the inventory service 414. Similarly, prefabricated areas 430 and 440 can be examples of other prefabricated areas described herein, including... Figure 2 The prefabricated area 206.

[0082] As described above, prefabrication plant 402 can simultaneously support the construction of multiple prefabrication zones. Figure 4 As shown, prefabrication plant 402 includes prefabrication area 430 and prefabrication area 440. Prefabrication area 430 may include one or more server racks 432A-432C. Each server rack may include one or more devices, including server devices and networking devices. For example, server rack 432A may include switch 434 and server device 436. Switch 434 may be a top-of-rack switch that provides networking connectivity to other server racks (e.g., via top-of-rack switches at other server racks) or other physical resources in prefabrication area 430. Networking connectivity between physical resources in prefabrication area 430 may include a portion of networking infrastructure 438. Networking infrastructure 438 may include a portion of the networking infrastructure of prefabrication plant 402, including network cabling, network switches, routers, etc., that form the network structure of prefabrication plant 402. Similarly, prefabrication area 440 may include one or more server racks 442A-442B, which may include more or fewer computing devices than the server racks 432A-432C of prefabrication area 430. For example, server rack 442A may include switch 444 and server device 446.

[0083] At any given time, each prefabricated area may be at a different point in the prefabricated area construction process. For example, prefabricated area 430 may be undergoing infrastructure provisioning and resource deployment, while prefabricated area 440 may be undergoing physical resource installation. Furthermore, each prefabricated area at prefabrication plant 402 may include different arrangements of physical resources. For example, prefabricated area 430 may include a greater number of server racks (e.g., racks 432A-432C) than prefabricated area 440, where each server rack supports a greater number of computing devices than the server racks (e.g., server racks 442A, 442B) in prefabricated area 440. Because the number and arrangement of physical resources may differ in each prefabricated area, the network topology corresponding to the connections between physical resources may differ for each prefabricated area.

[0084] Inventory service 414 can track physical resources used to form prefabricated areas in prefabrication plant 402. The physical resources tracked by inventory service 414 may include server equipment and networking equipment, as well as racks for server equipment and networking equipment. Inventory service 414 can also track physical resources in areas at data centers used for deployment, including prefabricated area equipment delivered to and installed at destination sites. In some embodiments, inventory service 414 can connect to the prefabricated area (e.g., via a network) and query device identifiers for devices in the prefabricated area. As part of the prefabricated area construction operation, inventory service 414 can provide information corresponding to physical resources in the prefabricated area to manager service 412. For example, manager service 412 can use inventory information from inventory service 414 to determine whether physical resources in the prefabricated area are to be installed according to a physical construction request. In some embodiments, inventory service 414 can also maintain information corresponding to physical inventory 424 (e.g., repositories, warehouses, or other storage devices for constructing computing devices and other physical resources in the prefabricated area). Maintaining physical inventory 424 may include the quantity and type of physical resources that can be used to track use in the prefabrication area, a database or other data storage for maintaining inventory information, updating inventory information when new physical resources are added to physical inventory 424 (e.g., delivery of new equipment, construction of server racks, etc.), and updating inventory information when equipment leaves physical inventory for use in prefabrication plant 402 (e.g., ...). Figure 4 (As indicated by the arrow in the image) Update inventory information. In some examples, CSP personnel can interact with Inventory Service 414 to provide manual updates to inventory information.

[0085] Manager service 412 can obtain inventory information from inventory service 414 for use when generating physical build requests. For example, inventory information can be used by manager service 412 to determine which physical resources to install in prefabrication plant 402 for the prefabrication area corresponding to the physical build request.

[0086] Figure 5 This is a diagram illustrating a CSP system 500 according to at least one embodiment, which uses a manager service 512 and a network service 520 to manage the network configuration of computing resources in a prefabrication zone 530 constructed in a prefabrication plant 502. The prefabrication plant 502 and prefabrication zone 530 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 510 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 512 as Figure 2 Example of network service 220 is network service 520.

[0087] As mentioned above Figure 2 As described, the manager service 512 can perform tasks to coordinate the operations of the prefabrication service 510, including scheduling prefabrication zone construction operations of other prefabrication services 510, generating physical build requests and corresponding instructions, and configuring prefabrication zone 206 for delivery to the destination site. The physical build request can specify the quantity and type of physical resources to be used in prefabrication zone 206. The network service 520 can use configuration information from the build request to determine the network topology of devices (e.g., servers, networking devices, server and networking device racks, etc.). After the infrastructure components in prefabrication zone 530 are provisioned, the network service 520 can also determine the network configuration of the devices in prefabrication zone 530.

[0088] In some examples, network service 520 may store a snapshot of the network configuration of a prefabricated area (e.g., prefabricated area 530). 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 538 of the prefabricated plant 502, and network settings of the devices (e.g., port configurations, gateway configurations, etc.). For example, server device 536 may be a computing device in server rack 532A of prefabricated area 530. Server device 536 may have a networking connection 540 to a switch 534 of server rack 532. The network configuration of prefabricated area 530 may then include information associating server device 536 with switch 534, including specifying the type of network connection 540, the port of switch 534 to which server device 536 is connected, and the settings of server device 536 and switch 534 corresponding to the networking connection 540 between them. Furthermore, the network configuration may include information associating server device 536 with “neighboring” devices in prefabricated area 530, which have networking connections 542, 544 between them. Network connections 542 and 544 may be connected via switch 534, allowing server device 536 to communicatively connect to other devices in server rack 532A via network connections 542 and 544. In some examples, “neighboring” devices for a given device in prefabricated area 530 may include each computing device on the same server rack. Additionally, switch 534 may have network connections to one or more other switches within prefabricated area 530 (e.g., network connection 546 to a switch in server rack 532B).

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

[0090] Network service 520 can also maintain the network configuration of the network structure of prefabrication plant 502. For example, prefabrication plant 502 may have networking infrastructure to support multiple separate prefabrication areas being built simultaneously. Prefabrication plant 502 may have multiple dedicated locations for placing server racks in the prefabrication areas being built. Each location may have a network cable group for the networking infrastructure, which terminates at a location that can be connected to the server rack. Based on the device placed at that location, specific cables from the network cable group can be connected to the device (e.g., to a top-of-rack switch) to connect the device to other devices in the prefabrication area using a portion of the network structure of prefabrication plant 502. For example, server rack 532A may be placed at a location within prefabrication plant 502 and connected to networking infrastructure 538 using switch 534, while server rack 532B may be placed at a second location and connected to networking infrastructure 538.

[0091] In addition to operations for preserving the network configuration of prefabricated area 530, configuring prefabricated area 530 for transport to the destination site may also include: management service 512 configuring each device to enter a test state during subsequent power-up of the device; encrypting the device's data volume using an encryption key; storing the encryption key on a device that can act as a key server for prefabricated area 530 during initialization at the destination site; and configuring one of the devices to act as a Dynamic Host Configuration Protocol (DHCP) server during initialization of prefabricated area 530 at the destination site. Management service 512 may also generate instructions that can be used by personnel or robotic systems associated with prefabrication plant 502 for packaging devices for transport. Management service 512 may also generate instructions that can be used by personnel associated with the destination facility for installing and connecting devices at the destination facility.

[0092] In some embodiments, the device configuring prefabrication area 530 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 devices of a computing device, which can be used to copy the device's software configuration to a replacement device. Manager service 512 may collaborate with one or more prefabrication services 510 to generate device snapshots. Device snapshots may be stored in a database or data store (e.g., one or more snapshots 524) along with one or more network snapshots. As a specific example, manager service 512 may generate device snapshot 552 of server device 550 of prefabrication area 530 at prefabrication plant 502. Device snapshot 552 can be used to image another physical device with the same or similar physical configuration as server device 550 to create a replicated server device in case server device 550 fails (e.g., is damaged or lost during transport to the destination site).

[0093] Figure 6 This is a diagram illustrating a CSP system 600 according to at least one embodiment, which is used to test and evaluate a prefabricated area 530 after delivery to a destination 602 using a manager service 612 and a test service 616. The destination site 602 may be a data center facility at a location corresponding to a new area to be deployed for the CSP using the computing resources of the prefabricated area 630. The prefabrication service 610 may be provided by the CSP and may be similar to... Figure 2 The pre-built service 210 includes a manager service 612 as an example of a manager service 212, a test service 616 as an example of a test service 216, and a pre-built service 616 as an example of a test service 216. Figure 2 The example of orchestration service 218 is orchestration service 618.

[0094] Transporting the prefabricated area 530 to the destination site 602 may include powering down each device, disconnecting the devices from the prefabrication plant's networking infrastructure, and properly packing the devices for handling. Server racks (e.g., server racks 532A, 532B) can be transported intact without disconnecting individual devices on the server racks. Once delivered to the destination site 602, the server racks can be positioned within the destination site 602 according to the final data center's physical layout and connected to the destination site's networking infrastructure 638. For example, networking connections can be made between the networking infrastructure 638 and the switches of server racks 532A, 532B by connecting one or more networking cables to a switch (e.g., switch 534).

[0095] As described above, the devices in prefabricated area 530 may have been configured to boot into test mode upon first power-on at destination site 602. In some embodiments, the devices may have dedicated boot volumes to support test mode during initialization at destination site 602. In other embodiments, boot volumes may be configured on external devices connected to each device in prefabricated area 530. For example, each server device (e.g., server device 536) may connect to a SmartNIC that provides a low-overhead boot volume that can be used to boot the server device into test mode. Since boot volumes can be used solely to support test mode, data on boot volumes may not need to be encrypted like data volumes on server devices.

[0096] The test mode can be configured to allow each computing device to verify its connectivity with other devices in prefabricated area 530. Verification determines whether the physical network connection between the device and the networking infrastructure 638 at destination site 602 is correctly established. To verify the connectivity, the devices in test mode can use network services (e.g., Figure 5 Network service 520) determines and stores a stored network configuration or a portion of a network configuration at each device. For example, server device 536 can use network snapshot 526 to determine neighboring computing devices communicatively connected to server device 536 via network connection 542. To verify network connection 542, server device 536 can send a verification request to the neighboring computing device. If network connection 542 is intact, server device can receive a verification indication from the neighboring computing device indicating that the verification request was successfully received at the neighboring computing device. Server device 536 can verify all connections specified in network snapshot 526. Similarly, devices on a server rack (e.g., server rack 532A) can verify connections to each other server rack (e.g., server rack 532B) in prefabricated area 530.

[0097] In some embodiments, a device in prefabricated area 530 may be configured to act as a DHCP server (e.g., DHCP server 646). DHCP server 646 may provide network addresses or other identifiers to devices in prefabricated area 530 during initialization. For example, during test mode, each device may verify its connection to DHCP server 646 and then receive addresses, identifiers, or other network configuration information from DHCP server 646. The device may compare the received identifiers with identifiers included in the network configuration generated by the network service during the prefabricated area construction operation at the prefabrication plant. For example, server device 536 may receive identifiers from DHCP server 646 and then compare the received identifiers with identifiers in network snapshot 526. Since prefabricated area 530 should not have undergone any component changes during transport, the network configuration of prefabricated area 530 at destination site 602 should remain unchanged, including the configuration information from DHCP server 646. That is, after the devices are installed at destination site 602, the server devices in the prefabricated area should receive the same network addresses from DHCP server 646. If the network configuration changes, the server devices may indicate that the network configuration of prefabricated area 530 may be incorrect.

[0098] In some embodiments, if any device is damaged and no longer functional during transport, the operator at the destination site can replace the damaged device with a new replacement device and configure the new device using a device snapshot taken before shipping, thus allowing successful on-site verification even if there is hardware failure during transport. For example, server device 550 may be damaged during transport to destination site 602. Discovery of the inoperable state of server device 550 can occur during a test operation to verify the network configuration of prefabrication area 530. To restore functionality, manager service 612 can generate instructions to replace server device 550 with the same physical device at the same location on server rack 532B. Once the replacement device is installed, manager service 612 can deploy device snapshot 552, generated during the prefabrication area build operation in prefabrication plant 502. Deploying device snapshot 552 may include imagerizing one or more disk drives or other storage devices of the replacement server device to bring the replacement server device to the same software configuration as server device 550 in prefabrication area 530 before transport to destination site 602. Other devices, including networking devices like switch 534, can be similarly replaced and restored using captured device snapshots.

[0099] DHCP server 646 can perform test mode verification operations similar to those of other devices within prefabricated area 530. If DHCP server 646 can successfully verify the network connection between itself and a neighboring device, DHCP server 646 can exit test mode and begin operating as a DHCP server for other devices in prefabricated area 530. In some embodiments, DHCP server 646 can complete its test mode verification operation before other devices in prefabricated area 530 complete their test mode verification operations. For example, server device 536 can start in test mode and attempt to verify its network connection with DHCP server 646 before verifying its own network connection 542 or network connection 544 with a neighboring computing device. DHCP server 646 may not send a verification instruction to server device 536 until DHCP server 646 has completed its own test mode verification operation. Then, server device 536 can wait for a predetermined amount of time and retry the verification request to DHCP server 646. Similarly, other computing devices performing test mode verification operations can wait and retry verification requests until DHCP server 646 becomes operational.

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

[0101] Once prefabricated region 530 has been installed and initialized at destination site 602 (e.g., the device boots into normal operating mode, data volumes are decrypted, and services deployed during the prefabricated region build operation at the prefabrication plant are executing), test service 616 can perform one or more acceptance tests. Acceptance tests may include verifying that all services function as expected. For example, test service 616 may interact with the services executing at prefabricated region 530 to verify that the services operate according to the requirements defined in the acceptance tests. Test service 616 may provide the results of the acceptance tests to manager service 612, indicating that the prefabricated region build is complete.

[0102] During transport from prefabricated area 530 to destination site 602, 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 530 at the prefabrication plant. For example, services may be updated to a newer version during transport. Before the prefabrication area construction operation is complete, orchestration service 618 can deploy the updated software resources to prefabricated area 530 at destination site 602. Deploying updated software resources can be similar to the deployment of software resources to prefabricated area 530 at the prefabrication plant.

[0103] Figure 7 This is an example method, according to at least one embodiment, for deploying software resources to physical resources in an area being built in a prefabrication plant and preparing the physical resources for transfer to a target data center. Method 700 can be performed by one or more components of a computer system, including a CSP (e.g., Figure 2 The Execution Manager service of the computer system (e.g., CSP 204) Figure 2 The manager service 212) or one or more components. The operations of method 700 can be performed in any suitable order, and method 700 can include more than Figure 7 The more or fewer operations described in the text.

[0104] Some or all of method 700 (or any other process and / or method described herein, or variations thereof 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 executes jointly on one or more processors, via hardware, or in 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.

[0105] Method 700 may begin at box 702, where the manager service receives the build request. The manager service can be an example of any manager service described herein, including... Figure 2 The Manager Service 212. The Manager Service can be executed on one or more computing devices of a CSP computer system. The Manager Service can be configured to perform operations in a prefabrication plant (e.g., Figure 2 Prefabrication areas are constructed in the prefabrication plant 202 (e.g., Figure 2One of the multiple services of the CSP in the prefabricated area (206) in the prefabricated area. A build request may be a specification or configuration containing information characterizing the prefabricated area. For example, a build request may include information defining the size of the prefabricated area (e.g., the number of computing devices, server racks, etc.), the number and type of services, applications, and other software to be executed on the computing devices in the prefabricated area, the computing power requirements in the prefabricated area (e.g., the number of processors in each computing device, the computing speed of the processors, etc.), the requirements for the type of storage provided in the prefabricated area, and other similar definitions. In some embodiments, the build request may be provided by the operator designing the prefabricated area or a system architect.

[0106] At box 704, the manager service can generate physical build requests for constructing physical resources within the first data center. The first data center can be a prefabrication plant (e.g., Figure 2 (Prefabrication plant 202). The manager service can use information from the build request to generate a physical build request. Physical resources may include server equipment, networking equipment, and other computing equipment that can be used to build prefabricated areas within the first data center. The physical build request may include information identifying the specific physical resources to be built in the first data center. For example, the manager service may work with an inventory service (e.g., Figure 2 Interact with the inventory service 214) to obtain the physical inventory of such devices (e.g., Figure 2 The physical inventory (224) contains the inventory of available server equipment and server racks. The manager service can then determine the specific server rack used to build the prefabricated area corresponding to the build request and include this information in the physical build request. The physical build request may also include, for example, instructions that can be used by operators to retrieve, move, and install physical resources into the first data center. For example, the instructions may identify a specific location within the first data center for placing the server rack, and instructions for completing specific network connections with the server rack to form a prefabricated area network.

[0107] At box 706, the manager service can implement ViBE at the second data center (e.g., Figure 2 (ViBE 222). The second data center can communicatively connect to the first data center. For example, the manager service can be connected via a network (e.g., Figure 2 The network 208) connects to the host area of ​​the CSP in the prefabrication plant to implement ViBE. The manager service can interact with orchestration services (e.g., Figure 2The orchestration service 218 in the system collaborates to implement the ViBE. For example, the manager service can provide the orchestration service with instructions to build the ViBE, specifying the second data center in which the ViBE should be constructed. The manager service can implement the ViBE in response to an indication that the physical resources corresponding to the physical build request have been built (e.g., installed, powered on, and functioning correctly in the first data center). The indication can be provided by an operator after the physical resources are installed. In some embodiments, the indication can be provided by one or more of the physical resources after a self-test or other verification of the completed installation.

[0108] At box 708, the Manager Service can use ViBE to deploy software resources to physical resources. Software resources can be associated with cloud services that execute on the physical resource. For example, a software resource can be a component of a production service (e.g., a database service) that will execute in the provisioned region after being delivered to the destination site. The Manager Service can collaborate with orchestration services to deploy software resources.

[0109] At box 710, the manager service can generate an inventory of physical resources. The manager service can collaborate with the inventory service to generate the inventory. At box 712, the manager service can use the inventory to generate a network configuration corresponding to the network topology of the physical resources in the first data center. The manager service can collaborate with network services (e.g., Figure 2 The network service 220) works in conjunction to generate a network configuration. The network configuration may be a network snapshot of a prefabricated area. The network configuration may include identifiers of physical resources in the inventory (e.g., network addresses of server devices) and information that associates physical resources with adjacent physical resources according to the network topology. For example, the network configuration may identify each computing device and the network connections between the computing device and one or more adjacent computing devices. The operations of boxes 710 and 712 may be operations for configuring physical resources for transmission to a destination site. The destination site may be a third data center. In some embodiments, the manager service may send a portion of the network configuration to the physical resources. A portion of the network configuration may include an identifier corresponding to the physical resource and information that associates the physical resource with adjacent physical resources in the network topology. In some embodiments, configuring physical resources for transmission to the destination site may include encrypting at least a portion of the software resources deployed to each physical resource using an encryption key associated with each physical resource, and storing each encryption key in one of the physical resources assigned to host a key service at a second data center (e.g., Figure 6 The key server is located at 642.

[0110] In some embodiments, the manager service may receive an indication that a physical resource has been delivered to a destination site and built (e.g., installed) at the destination site. In response to the indication, the manager service may verify the topology of the physical resource at the destination site. For example, the manager service, in conjunction with a network service, may obtain the network configuration of the physical resource at the destination site and compare the network configuration with information included in a stored network snapshot obtained prior to the physical resource's delivery to the destination site. If the network topology of the physical resource at the destination site is verified, the manager service may deploy one or more updated software resources to the physical resource. For example, the manager service may operate in conjunction with an orchestration service to deploy updated software components for a service deployed in a prefabrication area at a prefabrication plant, but which has been moved to a newer version during the transport of the physical resource to the destination site.

[0111] In some embodiments, the manager service may perform operations to support the initialization of physical resources at the destination site. The manager service may determine the dependencies of a first cloud service (e.g., a deployed application) on a second cloud service (e.g., a database service). The first cloud service may include software resources hosted on the first physical resource, while the second cloud service may include software resources hosted on a second physical resource. Due to the dependency, the first cloud service may not function correctly until the second cloud service is operational. Because physical resources can independently undergo test mode verification during initialization, a portion of the deployed area may become available before others. In this case, the manager service may determine whether a portion of the network topology associated with the second physical resource has been successfully verified and then send an indication that the first cloud service is available. The indication may be sent to an operations console or other systems configured to report the availability of services and applications in a pre-built area at the destination site when they become available. For example, the indication may be used to initiate one or more user acceptance tests on the newly available first cloud service.

[0112] In some embodiments, the configuration of a prefabricated area can be changed during the prefabrication area construction operation at the prefabrication plant. For example, the prefabrication area may need additional computing resources to support additional or extended applications and / or services once delivered to the destination site. The techniques described herein address modifications to prefabrication areas while they are being built at the prefabrication plant. A manager service can generate updated physical build requests that can be used to modify physical resources. For example, an updated physical build request can specify additional server racks at the prefabrication plant for installation in the prefabrication area. As another example, one or more server devices can be replaced with different types of server devices (e.g., devices with faster processors, additional processors, additional memory, etc.). Similar to the physical build request, the updated physical build request can include instructions that can be used (e.g., by operators at the prefabrication plant) to acquire, install, and / or modify physical resources. Once modifications have been made, the manager service can deploy updated software resources to the modified physical resources. For example, the manager service can use orchestration services and ViBE to deploy software components of new services onto new server racks in the prefabrication area. The manager service can deploy updated software resources in response to receiving an indication that a physical resource has been successfully modified.

[0113] In some embodiments, configuring physical resources for transport to a second data center may include generating device snapshots for one or more of the physical resources. For example, a manager service may generate a software image of each server device in the prefabricated area and store the software image in a data store or similar repository. Upon verification of the prefabricated area after installation at the destination site, the manager service may determine that one of the physical resources has failed. For example, a server device may have been damaged or lost during transport to the destination site. In response, the manager service may generate instructions that can be used to replace the non-functional physical resource with a functional replacement (e.g., swapping the non-functional server device with a functional alternative server device having the same physical configuration). Once the functional replacement device is installed, the manager service can configure the replacement device using the device snapshot of the failed device. For example, the manager service may deploy an image to the replacement device to create a device with the same configuration and function as the replaced device.

[0114] Figure 8 This is an example method 800 according to at least one embodiment for initiating and verifying the network configuration of physical resources built at a prefabrication plant after delivery to a destination data center. Method 800 can be performed by one or more components of a computer system, including a prefabrication area (e.g., Figure 2 One or more components of a computer system in the prefabricated area 206) that are communicatively connected to a managed manager service (e.g., Figure 2The CSP of the manager service 212). For example, method 800 can be executed by a computing device in a prefabricated area, including Figure 5 Server equipment 536 Figure 6 The DHCP server 646 or key server 642. The operation of method 800 can be performed in any suitable order, and method 800 can include... Figure 8 The more or fewer operations described in the text.

[0115] Method 800 may begin at box 802, where the computing device receives network configuration from the manager service (e.g., Figure 5 Network snapshot 526). Network configuration may include specifying a first data center (e.g., Figure 2 The network configuration may include information about the network topology of the physical resources in the prefabrication plant (202). The network configuration may include a first identifier associated with a computing device (e.g., network address, hostname, etc.), a second identifier associated with adjacent computing devices (e.g., network address, hostname, etc.), and information that associates the computing device with adjacent computing devices (e.g., specifying...). Figure 5 (Network connection information 544). The computing device can be configured to communicate with adjacent computing devices via a network connection using network configuration.

[0116] At box 804, the computing device can be configured for transmission to a second data center (e.g., Figure 6 Destination site 602). Configuring computing devices for transmission may include the above-mentioned... Figure 7 The operations described in blocks 710 and 712 are similar. Furthermore, configuring the computing device for transfer to the second data center may include configuring the computing device to boot into test mode during a subsequent power-on sequence. At block 806, the computing device may be booted into test mode at the second data center. For example, once the computing device and other physical resources in the prefabricated area have been delivered to and installed at the second data center, the computing device can be powered on and enter test mode. In some embodiments, booting the computing device into test mode may include booting from a boot volume stored on a SmartNIC connected to the computing device.

[0117] At box 808, the computing device can receive a new identifier. This new identifier can be received from a server device at the second data center. For example, the server device could be a device configured to act as a DHCP server at the second data center. The identifier could be the network address of the computing device. As mentioned above, this identifier can be the same as the first identifier associated with the computing device in the prefabrication area at the prefabrication plant, because changes to the network configuration should not occur during the handling and installation of physical resources at the second data center.

[0118] At box 810, the computing device can verify the new identifier by comparing it with the first identifier. The computing device can obtain the first identifier from the network configuration stored at the computing device prior to transmission.

[0119] At box 812, the computing device may send an authentication request to a neighboring computing device. The authentication request is sent based on a second identifier associated with the neighboring computing device. For example, the computing device may ping a neighboring device at a network address associated with the neighboring computing device. In response, at box 814, the computing device may authenticate its network connectivity with the neighboring computing device. The network connectivity can be characterized by network configuration. In some embodiments, network connectivity authentication may include receiving a response to the authentication request, which may be an authentication indication from the neighboring computing device. In some embodiments, the response to the authentication request may be an indication that the neighboring computing device did not receive the authentication request, such as a request timeout indication. The authentication indication may indicate that the physical networking between the computing device and the neighboring computing devices has been correctly installed at a second data center. In some embodiments, once the computing device has successfully authenticated its connectivity with each neighboring computing device, the computing device may send an indication to the manager service that the network connectivity associated with the computing device has been successfully authenticated at the destination site.

[0120] In some embodiments, the computing device may be configured to operate as a key server in a prefabricated area within a second data center. Configuring the computing device for transmission to the second data center may include encrypting a data volume of the adjacent computing device using an encryption key associated with it. The encryption key may be stored at the data volume of the computing device, which can then be encrypted using a different encryption key (e.g., a master key). The master key may then be stored at a secure storage volume (e.g., a hardware security module, a trusted platform module (TPM), or a SmartNIC) connected to the computing device and usable for decrypting the storage volume on the computing device to retrieve and sell the encryption key to adjacent computing devices and other computing devices in the prefabricated area when they come online in the second data center. In some embodiments, once the computing device has verified its network connectivity with the adjacent computing device, it can retrieve the master key from the secure storage volume, decrypt the data volume storing the encryption key, and sell the encryption key in response to key requests from the adjacent computing device or other computing devices.

[0121] In some embodiments, the computing system may determine that one or more computing devices at the second data center are faulty or otherwise malfunctioning. For example, server equipment in a server rack may have been damaged during transport. To complete the installation of the prefabricated area at the second data center, the faulty or otherwise malfunctioning computing device may be replaced with another device and configured using the software image of the faulty device prior to transport to the second data center. For example, the computing system may configure adjacent computing devices for transport to the second data center by generating device snapshots of the adjacent computing devices. Device snapshots may include the software images of the adjacent computing devices. Device snapshots may be generated by a manager service and / or other prefabrication services that perform prefabrication area construction operations at the prefabrication plant.

[0122] Once the computing device is installed in the second data center, the computing system can determine that the adjacent computing device is not functioning. For example, the computing device may receive a response to a verification request indicating that the adjacent computing device is damaged or malfunctioning. In response to this determination, the management service can generate instructions to replace the adjacent computing device with a replacement computing device. These instructions can be used by personnel in the second data center to make the replacement (e.g., a similar swap of devices on a server rack). The management service can then deploy a device snapshot of the adjacent computing device to the functioning adjacent computing device, resulting in a device identical to the faulty one. The computing device can then resend the verification request to determine the correct operation of the network connection between the computing device and the adjacent computing device.

[0123] Static network structure

[0124] As mentioned above, prefabrication plants (e.g., Figure 1The prefabrication plant 102 may include a static network structure consisting of networking infrastructure (e.g., network switches, routers, cabling, etc.) designed to support various network topologies of the regional components built within the plant. Prefabricated areas with different network topologies can be quickly connected to the static network structure according to a connectivity plan that matches the static network structure to the physical components of the area. The static network structure may include network cabling terminated at designated locations in the prefabrication plant configured for server rack installation. The network cabling may include various types and numbers of cable connectors or other terminations to support connections to different computing devices installed in the prefabricated areas at those locations. For example, server racks in a first prefabricated area may be installed at locations in the prefabrication plant and connected to the static network structure at those locations according to the designated network of the first prefabricated area. Subsequently (e.g., after the prefabrication area construction operation), those server racks may be removed, and server racks in a second prefabricated area with different networking interfaces may be installed at the same locations and connected to the static network structure according to the designated network of the second prefabricated area. In this way, different prefabricated areas can be installed at the prefabrication plant without modifying the static network structure, reducing the complexity of network connections for prefabricated areas within the plant and increasing the speed of installing / removing prefabricated area components from the plant to support prefabricated area construction operations.

[0125] Figure 9 This is a block diagram illustrating an example static network structure 900 in a prefabrication plant 902 according to at least one embodiment. The prefabrication plant 902 can be an example of any of the prefabrication plants described herein, including... Figure 1 The prefabrication plant 102 is included. The static network structure 900 may include network cables 908 routed throughout the prefabrication plant. As an example, network cables 908 may be installed in overhead cable trays aligned with the rows of server racks. In other examples, network cables 908 may be installed in trays or conduits under a raised floor, also aligned with the rows of server racks. Network cables 908 may be configured to terminate at locations within the prefabrication plant 902 where server racks can also be positioned. For example, network cable bundle 910 may terminate at the location of server rack 904A in prefabrication area 904.

[0126] The prefabrication plant can simultaneously support multiple prefabrication zones for prefabrication zone construction operations. For example... Figure 9 As shown, the prefabrication plant 902 may include prefabrication area 904 and prefabrication area 906, each of which may be an example of other prefabrication areas described herein, including... Figure 2Prefabricated area 206 is included. Prefabricated area 904 may include server racks 904A-904D. Similarly, prefabricated area 906 may include server racks 906A-906D. Computing devices in the prefabricated areas can be communicatively connected to each other via an arrangement of network cables, including one or more of network cables 908 and associated networking devices of the static network structure 900. The arrangement of connected computing devices in the prefabricated areas may be referred to as a local area network (LAN). The LAN of prefabricated area 904 may be different from the LAN of prefabricated area 906, but in some cases, some networking devices of the static network structure may handle traffic from both LANs. Network cables 908 may include one or more types of network cabling, and / or various combinations of types, including fiber optic cabling, copper cabling (e.g., Ethernet, copper coaxial cable, etc.). In some embodiments, network connectivity enabled by network cables 908 may be achieved via optical and / or wireless links (such as ultra-wideband technologies). Although described herein with reference to physical network cabling, embodiments of this disclosure including optical or other wireless network connectivity are also contemplated.

[0127] The network cable group 910 terminated at the location may include various types of cables (e.g., fiber optic, twisted-pair for Ethernet or the like, coaxial cable, etc.), each terminated via a suitable cable termination connector. The cable termination connector connects to the terminal end of the network cable in the network cable group 910. Types of cable termination connectors may include, but are not limited to, multi-fiber push-in (MPO), multi-fiber pull-out, small form factor (SFP), SFP+, SFP28, quad small form factor (QSFP), QSFP+, QSFP28, and RJ45. When a server rack is positioned in a prefabrication facility, one or more network cable groups terminated at that location can connect to one or more computing devices in the server rack to connect the computing devices in the server rack to a local area network. For example, server rack 904A may include a network switch positioned at the top of the rack (e.g., a top-of-rack switch).

[0128] The static network structure 900 may also include one or more networking devices configured to simultaneously support network traffic from multiple area networks. These networking devices can be arranged in various architectures to support different levels of network traffic in different prefabricated areas within the prefabrication plant 902. For example, the static network structure 900 may be arranged in a three-tier architecture, where aggregation switches (e.g., switches 912, 914) support the top-of-rack switches in each server rack (e.g., server racks 904A-904D and server racks 906A-906D), and a core switch (e.g., switch 916) supports the aggregation switches. As another example, the static network structure 900 may be arranged in a backbone and leaf architecture, where leaf switches (e.g., the top-of-rack switches in each server rack) support traffic from server devices in each server rack, and backbone switches (e.g., switches 912, 914, 916) support traffic from each of the leaf switches in the next tier.

[0129] A static network structure 900 can form a Clos network. A Clos network topology is a non-blocking architecture where each switch in one layer of the network structure (e.g., each leaf switch) connects to each switch in the next layer (e.g., each backbone switch), providing a network path between each device and every other device and allowing traffic to be routed along the available paths in the most efficient manner. For example, switches 912-916 can be the backbone switches of the static network structure 900. Each of switches 912-916 can be connected to a network cable terminated in network cable 908 at each location, such that a network cable group (e.g., network cable group 910) includes network connections to each of switches 912-916. When the network connections at a location connect to a leaf switch (e.g., the top-of-rack switch of each server rack), the resulting interconnections can form a Clos network. Other topologies can be supported by an appropriate number of switches and networking devices.

[0130] Figure 10A and 10B This is a diagram illustrating an example arrangement of physical computing resources connected to a static network structure in a prefabrication plant according to some embodiments. Figure 10A The diagram illustrates a CSP system 1000 including a prefabrication plant 1002 in which prefabrication areas 1004 can be constructed. Figure 10B This is a diagram illustrating the prefabrication area 1032 in prefabrication plant 1002. CSP systems 1000 and 1030 may include prefabrication service 1020, which may be an example of other prefabrication services described herein, including... Figure 5 Prefabricated service 510. Prefabricated service 1020 may include manager service 1022 and network service 1024, which may be respectively... Figure 5Examples of Manager Service 512 and Network Service 520. Prefabrication plant 1002 can be an example of any other prefabrication plant described herein, including... Figure 9 The prefabrication plant 902. The prefabrication plant 1002 may include a static network structure 1012, which may be Figure 9 An example of a static network structure 900. The static network structure 1012 may include a network cable 1008 and a networking infrastructure 1010 having one or more networking devices (e.g., switches, routers, etc.) for handling traffic between computing devices in one or more local area networks.

[0131] Prefabrication area 1004 may include multiple server racks 1004A, 1004B through 1004N. Each server rack may have multiple computing devices, including server devices and networking devices. Each server rack 1004A-1004N may have the same or different numbers of computing devices and / or different types of computing devices (e.g., server devices with different computing capabilities). For example, server rack 1004N may have fewer server devices than server rack 1004A. As part of the prefabrication area construction operation of prefabrication area 1004, server racks 1004A-1004N may be located at a location within prefabrication plant 1002. Network cable assemblies 1008 (e.g., network cable assemblies 1006A-1006N) configured to terminate at each location may then be connected to each server rack 1004A-1004N.

[0132] As a specific example, server rack 1004A in prefabrication area 1004 can be communicatively connected to static network structure 1012 of prefabrication plant 1002 via network cable bundle 1006A connected from network cable 1008. (See above regarding...) Figure 9 The network cable assembly 1006A may include multiple network cables with cable termination connectors. Server devices on server rack 1004A can communicatively connect to a network switch. For example, server rack 1004A may include 40 server devices, each having a network connection to a rack-top switch on server rack 1004A. The connection between the server devices and the networking devices of the server rack can be made before the server rack is installed in a prefabrication plant. For example, when server rack 1004A is stored in physical inventory (e.g., Figure 2When the server rack 1004A is in the physical inventory 224), the server equipment and networking equipment can be connected. When the server rack 1004A is installed at the corresponding location in the prefabrication plant 1002, one or more of the network cable assemblies 1006A are connected to one or more ports of a network switch to communicatively connect the server equipment to a local area network using the static network structure 1012. The local area network may include a network formed by computing devices in the prefabrication area and a portion of the static network structure 1012 that enables network connections between different server racks.

[0133] Depending on the configuration of server rack 1004A, some cables in network cable group 1006A may not be connected to the network switch in server rack 1004A. For example, the network switch may be configured to connect to another network switch in the static network structure via a QSFP+ fiber optic connection and may not have a networking port that supports twisted-pair or coaxial cabling. Therefore, any cable in network cable group 1006A that is a twisted-pair or coaxial cable and has a corresponding cable termination connector will not be connected to the network switch in server rack 1004A. Similarly, networking devices in server rack 1004B may be connected to one or more cables in network cable group 1006B, and networking devices in server rack 1004N may be connected to one or more cables in network cable group 1006N.

[0134] To establish connections between the static network structure 1012 of prefabrication plant 1002 and the computing devices in prefabrication areas 1004 and / or 1032, manager service 1022 and network service 1024 can perform operations to generate a connection plan. The connection plan may include instructions (e.g., from operators in prefabrication plant 1002) to identify appropriate network cables in network cable bundles at each location for connection to server racks (e.g., server racks 1004A-1004N, server racks 1034A-1034N) and to identify the corresponding ports at which the identified cables can be connected to computing devices (e.g., rack-top switches). Server racks in prefabrication area 1004 may be connected to static network structure 1012 via different connections. For example, server rack 1004A may be connected via one or more QSFP+ connections in network cable bundle 1006A, while server rack 1034A may be connected via one or more SFP connections in network cable bundle 1036A.

[0135] To generate a connectivity plan, network service 1024 can determine the configuration of computing devices in the prefabrication area and the static network topology of static network structure 1012. The configuration of the computing devices may include information specifying the physical networking connections between server devices and networking devices on each server rack. For example, each server device on server rack 1004A may be connected to a specific identified port on the rack-top switch on server rack 1004A. The configuration of server rack 1004A may include information identifying the connection between each server device and a specific port on the rack-top switch to which it is connected. The configuration of the computing devices in prefabrication area 1004 can be predetermined, for example, as part of a physical inventory (e.g., ...). Figure 2 It is part of the initial construction of each server rack in the physical inventory (224). The configuration can be stored as configuration parameters in the data storage accessible by the network service (1024).

[0136] Similarly, the static network topology of static network structure 1012 can specify the physical connection of network cable 1008 to the switch port in networking infrastructure 1010, as well as the identity and type of cables that terminate at locations in prefabrication plant 1002 as part of network cable groups at each location (e.g., network cable groups 1006A-1006N, network cable groups 1036A-1036N). Information describing the static network topology can be stored in data accessible to network service 1024.

[0137] like Figure 10A and 10B As shown, prefabrication plant 1002 can be configured to simultaneously support prefabrication area construction operations on both prefabrication area 1004 and prefabrication area 1032. In some embodiments, server racks 1004A-1004N in prefabrication area 1004 can be installed at a different location than server racks 1034A-1034N in prefabrication area 1032. In some embodiments, after server racks 1004A-1004N have been configured for transmission to the destination site and removed from prefabrication plant 1002, server racks 1034A-1034N in prefabrication area 1032 can be installed at the same location as those used for server racks 1004A-1004N. In this case, network cable bundles 1036A-1036N can be the same as network cable bundles 1006A-1006N used to connect server racks 1004A-1004N to static network structure 1012, but are connected to server racks 1034A-1034N according to the connection plan corresponding to prefabricated area 1032.

[0138] As mentioned above Figure 7The prefabrication plant 1002 can support updates and other modifications to physical resources during prefabrication area construction operations. The static network structure 1012 can support the installation of additional server racks for prefabrication areas 1004 and / or 1032 based on updated construction requests. If additional computing devices are added to the prefabrication areas, the network service 1024 can generate an updated connectivity plan with instructions to connect the additional computing devices to the static network structure 1012.

[0139] Figure 11 This is an example method 1100 for generating a connectivity plan to connect multiple computing devices (e.g., server rack 1004A of FIG. 10) to a network cable group (e.g., static network structure 1012 of FIG. 10) in a prefabrication plant (e.g., prefabrication plant 1002 of FIG. 10). Method 1100 can be performed by one or more computing devices of a CSP hosting prefabrication services (e.g., prefabrication service 1020 of FIG. 10), including network services (e.g., network service 1024).

[0140] Method 1100 may begin at box 1102, where a network service can receive a physical build request. The physical build request may specify a static network structure for connecting multiple computing devices to a data center (e.g., prefabrication plant 1002). The physical build request may be generated by the manager service at the beginning of the prefabrication area build operation and specified above. Figure 7 The example of a physical build request described in Method 700. The network service can receive physical build requests from the manager service.

[0141] At box 1104, the network service can determine the configuration of multiple computing devices. The configuration can specify network connections between the multiple computing devices. For example, the multiple computing devices can be server devices on a server rack, each communicatively connected to a port of a top-of-rack switch. Therefore, the configuration can identify the server devices, the corresponding ports of the top-of-rack switches to which the server devices are connected, and the network settings associated with the connections. In some embodiments, determining the configuration of the computing devices can include determining the arrangement of network connections between the computing devices and the top-of-rack switches or other networking devices. In some embodiments, determining the configuration of the computing devices can include retrieving configuration parameters from a data store. The configuration parameters can include information identifying the connections between each server device and specific ports of the networking devices it is connected to.

[0142] At box 1106, the network service can determine the static network topology of the data center's static network structure. The static network topology can define the network connections between one or more networked devices (e.g., leaf switches, backbone switches, aggregation switches, core switches, etc.) of the prefabricated static network structure's network infrastructure. For example, the static network topology can identify the ports and devices connected to each networked device in the static network structure. The static network topology can also specify one or more cable termination connectors at locations within the prefabricated facility. The network service can determine the configuration and static network topology in response to receiving a physical build request. In some embodiments, determining the static network topology can include retrieving a predetermined topology of the data center's static network structure from data storage. In some embodiments, the static network topology can correspond to a Clos network.

[0143] At box 1108, network services can use configuration and static network topology to generate a connectivity plan for connecting a network cable group of the static network structure to computing devices. The network cable group can be determined from network cables (e.g., network cable 1008) of the static network structure configured to terminate at locations within a data center. Termination at a location may include cable termination connectors at the ends of the network cables that can be connected to computing devices. Locations may correspond to locations in a prefabrication plant where computing devices can be positioned for installation to support prefabrication area construction operations. The connectivity plan may include (e.g., by operators) instructions that can be used to connect each network cable in the network cable group to the corresponding network port of the computing device to form a local area network.

[0144] In some embodiments, the network service may determine an additional configuration for an additional computing device connected to the second networking device. The additional computing device and the second networking device may be a new server rack installed at a prefabrication facility to support modifications to the prefabricated area being built therein. The additional configuration may be similar to this configuration and may specify the network connectivity between the additional computing device and the second networking device. Using the configuration of the computing device, the additional configuration of the additional computing device, and the static network topology, the network service may then generate an updated connectivity plan with instructions to connect the additional computing device to the static network structure to form an updated local area network with the computing devices in the previously installed prefabricated area.

[0145] Example Infrastructure as a Service Architecture

[0146] As mentioned 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), or the like). In some cases, IaaS providers can also provision a wide variety of services to accompany those infrastructure components (example services include billing software, monitoring software, logging software, load balancing software, and clustering software, etc.). Therefore, because these services can be policy-driven, IaaS users can implement policies to drive load balancing to maintain application availability and performance.

[0147] 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 the VM. The customer can then use the provider's services to perform various functions, including balancing network traffic, troubleshooting application problems, monitoring performance, and managing disaster recovery.

[0148] In most cases, cloud computing models will require the involvement of cloud providers. However, cloud providers are not necessarily third-party services that specialize in providing (e.g., provisioning, renting, or selling) IaaS. Entities can also choose to deploy private clouds and become their own infrastructure service providers.

[0149] 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 or similar. It may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is typically managed by the cloud provider under a hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Therefore, the customer can be responsible for the processing (OS), middleware, and / or application deployment (e.g., on self-service virtual machines (e.g., which can be spunup) or the like).

[0150] In some examples, IaaS provisioning can refer to acquiring a computer or virtual host for use, and even installing the necessary libraries or services on it. In most cases, deployment does not include provisioning, and provisioning may need to be performed first.

[0151] In some cases, there are two distinct challenges to IaaS provisioning. First, there's the initial challenge of provisioning the initial infrastructure set before anything can run. Second, there's the challenge of evolving the existing infrastructure after everything has been provisioned (e.g., adding new services, changing services, removing services, etc.). In some cases, both challenges can be addressed by enabling the configuration of the infrastructure to be declaratively defined. In other words, the infrastructure (e.g., what components are needed and how they interact) can be defined by one or more configuration files. Therefore, the overall topology of the infrastructure can be declaratively described (e.g., which resources depend on which resources and how each works together). 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.

[0152] In some examples, the infrastructure can have many interconnected elements. For example, there may be one or more Virtual Private Clouds (VPCs) (e.g., potential on-demand pools of configurable and / or shared computing resources), also known as the core network. In some examples, there may also be one or more inbound / outbound traffic group rules, provisioned to define how inbound and / or outbound traffic to the network will be structured, and one or more Virtual Machines (VMs). Other infrastructure elements, such as load balancers, databases, or the like, may also be provisioned. As more infrastructure elements are expected and / or added, the infrastructure can evolve incrementally.

[0153] In some cases, continuous deployment techniques can be employed to enable the deployment of infrastructure code across various virtual computing environments. Furthermore, the described techniques can 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 multiple) different production environments (e.g., across various geographical locations, sometimes even across the world). However, in some examples, the infrastructure on which the code will be deployed must first be established. In some cases, provisioning can be done manually, provisioning tools can be used to provision resources, and / or, once the infrastructure is provisioned, deployment tools can be used to deploy the code.

[0154] Figure 12 This is a block diagram 1200 illustrating an example pattern of an IaaS architecture according to at least one embodiment. Service provider 1202 may be communicatively coupled to secure host lease 1204, which may include a virtual cloud network (VCN) 1206 and a secure host subnet 1208. In some examples, service provider 1202 may use one or more client computing devices, which may be portable handheld devices (e.g., Cellular phone Computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google) Head-mounted display), running software (such as Microsoft Windows) And / or a variety of mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc.), and with internet, email, and SMS services enabled. Or other communication protocols. Alternatively, the client computing device can be a general-purpose personal computer, including, for example, computers running various versions of Microsoft... Apple Personal computers and / or laptops running Linux operating systems. Client computing devices can be any of a wide variety of commercial operating systems. Workstation computers running UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, such as Google Chrome OS). Alternatively or additionally, client computing devices can be any other electronic device capable of communicating via a network that can access the VCN 1206 and / or the Internet, such as thin client computers, Internet-enabled gaming systems (e.g., with or without...). The Microsoft Xbox game console with gesture input devices, and / or personal messaging devices.

[0155] VCN 1206 may include a local peering gateway (LPG) 1210, which may be communicatively coupled to a secure shell (SSH) VCN 1212 via an LPG 1210 contained in an SSH VCN 1212. SSH VCN 1212 may include an SSH subnet 1214, and SSH VCN 1212 may be communicatively coupled to a control plane VCN 1216 via an LPG 1210 contained in a control plane VCN 1216. Furthermore, SSH VCN 1212 may be communicatively coupled to a data plane VCN 1218 via an LPG 1210. Control plane VCN 1216 and data plane VCN 1218 may be contained within a service lease 1219 that may be owned and / or operated by an IaaS provider.

[0156] The control plane VCN 1216 may include a control plane demilitarized zone (DMZ) layer 1220, which acts as a portion of the perimeter network (e.g., a corporate network between an intranet and an external network). DMZ-based servers can have limited liability and help keep violations contained. Furthermore, the DMZ layer 1220 may include one or more load balancer (LB) subnets 1222, a control plane application layer 1224 that may include one or more application subnets 1226, and a control plane data layer 1228 that may include one or more database (DB) subnets 1230 (e.g., one or more front-end DB subnets and / or one or more back-end DB subnets). 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. The application subnets 1226 can be communicatively coupled to one or more DB subnets 1230 and service gateways 1236 and Network Address Translation (NAT) gateways 1238 contained in the control plane data layer 1228. The control plane VCN 1216 may include service gateway 1236 and NAT gateway 1238.

[0157] The control plane VCN 1216 may include a data plane mirror application layer 1240, which may include one or more application subnets 1226. The one or more application subnets 1226 included in the data plane mirror application layer 1240 may include a Virtual Network Interface Controller (VNIC) 1242, which can execute compute instance 1244. The compute instance 1244 may communicatively couple the one or more application subnets 1226 of the data plane mirror application layer 1240 to the one or more application subnets 1226 that may be included in the data plane application layer 1246.

[0158] Data plane VCN 1218 may include data plane application layer 1246, data plane DMZ layer 1248, and data plane data layer 1250. Data plane DMZ layer 1248 may include one or more application subnets 1226 communicatively coupled to data plane application layer 1246 and one or more LB subnets 1222 of Internet gateway 1234 of data plane VCN 1218. One or more application subnets 1226 may be communicatively coupled to service gateway 1236 and NAT gateway 1238 of data plane VCN 1218. Data plane data layer 1250 may also include one or more DB subnets 1230 communicatively coupled to one or more application subnets 1226 of data plane application layer 1246.

[0159] Internet gateway 1234 of control plane VCN 1216 and data plane VCN 1218 can communicatively couple to metadata management service 1252, which in turn can communicatively couple to public internet 1254. Public internet 1254 can communicatively couple to NAT gateway 1238 of control plane VCN 1216 and data plane VCN 1218. Service gateway 1236 of control plane VCN 1216 and data plane VCN 1218 can communicatively couple to cloud service 1256.

[0160] In some examples, the service gateway 1236 of the control plane VCN 1216 or the data plane VCN 1218 can make application programming interface (API) calls to the cloud service 1256 without traversing the public internet 1254. API calls from the service gateway 1236 to the cloud service 1256 can be unidirectional: the service gateway 1236 can make API calls to the cloud service 1256, and the cloud service 1256 can send requested data to the service gateway 1236. However, the cloud service 1256 may not initiate API calls to the service gateway 1236.

[0161] In some examples, secure host lease 1204 can connect directly to service lease 1219, which would otherwise be isolated. Secure host subnet 1208 can communicate with SSH subnet 1214 via LPG 1210, which can enable bidirectional communication through an otherwise isolated system. Connecting secure host subnet 1208 to SSH subnet 1214 grants secure host subnet 1208 access to other entities within service lease 1219.

[0162] Control plane VCN 1216 may allow users of service lease 1219 to establish or otherwise provision desired resources. Desired resources provisioned in control plane VCN 1216 may be deployed or otherwise used in data plane VCN 1218. In some examples, control plane VCN 1216 may be isolated from data plane VCN 1218, and the data plane mirror application layer 1240 of control plane VCN 1216 may communicate with the data plane application layer 1246 of data plane VCN 1218 via a VNIC 1242 that may be included in both the data plane mirror application layer 1240 and the data plane application layer 1246.

[0163] In some examples, users or clients of the system can make requests (e.g., create, read, update, or delete (CRUD) operations) via the public internet 1254, which can then relay the requests to the metadata management service 1252. The metadata management service 1252 can relay the requests to the control plane VCN 1216 via internet gateway 1234. The requests can be received by one or more LB subnets 1222 contained in the control plane DMZ layer 1220. The LB subnets 1222 can determine that the request is valid, and in response to this determination, can forward the request to one or more application subnets 1226 contained in the control plane application layer 1224. If the request is authenticated and requires a call to the public internet 1254, the call to the public internet 1254 can be relayed to a NAT gateway 1238 that can make calls to the public internet 1254. The request may expect the storage to be stored in one or more DB subnets 1230.

[0164] In some examples, the data plane mirroring application layer 1240 can facilitate direct communication between the control plane VCN 1216 and the data plane VCN 1218. For example, it may be desirable to apply configuration changes, updates, or other suitable modifications to resources contained in the data plane VCN 1218. Through VNIC 1242, the control plane VCN 1216 can communicate directly with the resources contained in the data plane VCN 1218, and thereby can perform configuration changes, updates, or other suitable modifications to the resources contained in the data plane VCN 1218.

[0165] In some embodiments, the control plane VCN 1216 and data plane VCN 1218 may be included in service lease 1219. In this case, the system's users or customers may not own or operate the control plane VCN 1216 or data plane VCN 1218. Conversely, the IaaS provider may own or operate both the control plane VCN 1216 and data plane VCN 1218, both of which may be included in service lease 1219. This embodiment enables network isolation that prevents users or customers from interacting with the resources of other users or customers. Furthermore, this embodiment allows the system's users or customers to privately store databases without relying on the public Internet 1254, which may not have the desired level of threat prevention.

[0166] In other embodiments, one or more LB subnets 1222 included in the control plane VCN 1216 may be configured to receive signals from the service gateway 1236. In this embodiment, the control plane VCN 1216 and the data plane VCN 1218 may be configured to be invoked by the IaaS provider's customers without invoking the public internet 1254. 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 1219 that can be isolated from the public internet 1254.

[0167] 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 12 The service provider 1202) can communicatively couple to the secure host lease 1304 (e.g., Figure 12 Secure hosting rental 1204), which may include a Virtual Cloud Network (VCN) 1306 (e.g., Figure 12 VCN 1206) and Secure Host Subnet 1308 (e.g., Figure 12 The secure host subnet 1208). VCN 1306 may include a local peering gateway (LPG) 1310 (e.g., Figure 12 The LPG 1210, which can be communicatively coupled to the Secure Shell (SSH) VCN 1312 (e.g., LPG 1210 contained in the SSH VCN 1312) via the LPG 1210. Figure 12 (SSH) VCN 1212). SSH VCN 1312 may include SSH subnet 1314 (e.g., Figure 12 SSH subnet 1214), 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 12 Control plane VCN 1216). Control plane VCN 1316 may be included in service lease 1319 (e.g., Figure 12 In the service lease 1219), and the data plane VCN1318 (for example, Figure 12 The data plane VCN 1218 can be included in a customer lease 1321 that can be owned or operated by the system's users or customers.

[0168] The control plane VCN 1316 may include (one or more) LB subnets 1322 (e.g., Figure 12 The control plane DMZ layer 1320 of (one or more) LB subnets 1222) (e.g., Figure 12The control plane DMZ layer 1220 may include (one or more) application subnets 1326 (e.g., Figure 12 The control plane application layer 1324 of (one or more) application subnets 1226 (e.g., Figure 12 The control plane application layer 1224 may include one or more database (DB) subnets 1330 (e.g., similar to...). Figure 12 The control plane data layer 1328 of (one or more) DB subnets 1230) (e.g., Figure 12 The control plane data layer 1228). 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 12 Internet gateway 1234), and application subnet(s) 1326 can communicatively couple to DB subnet(s) 1330 and service gateway 1336 contained in control plane data layer 1328 (e.g., Internet gateway 1234), and application subnet(s) 1326 can be communicatively coupled to DB subnet(s) 1330 and service gateway(s) 1336 contained in control plane data layer 1328 (e.g. Figure 12 Service gateway 1236) and Network Address Translation (NAT) gateway 1338 (e.g., Figure 12 (NAT gateway 1238). The control plane VCN 1316 may include the service gateway 1336 and the NAT gateway 1338.

[0169] The control plane VCN 1316 may include a data plane mirror of the application layer 1340 (e.g., Figure 12 The data plane mirror application layer 1240 may include one or more application subnets 1326. The one or more application subnets 1326 included in the data plane mirror application layer 1340 may include computational instances 1344 (e.g., similar to...). Figure 12 The virtual network interface controller (VNIC) 1342 (e.g., the VNIC of 1242) of the computing instance 1244. The computing instance 1344 may facilitate the mirroring of the application subnet(s) 1326 of the application layer 1340 in the data plane and may be included in the application layer 1346 in the data plane (e.g., Figure 12 Communication between one or more application subnets 1326 in the data plane application layer 1246 via VNIC 1342 contained in the data plane mirror application layer 1340 and VNIC 1342 contained in the data plane application layer 1346.

[0170] The Internet gateway 1334, included in the control plane VCN 1316, can be communicatively coupled to the metadata management service 1352 (e.g., Figure 12Metadata management service 1252), which can communicatively couple to the public Internet 1354 (e.g., Figure 12 The public internet 1354 can communicatively couple to a NAT gateway 1338 contained in a control plane VCN 1316. The service gateway 1336 contained in the control plane VCN 1316 can communicatively couple to a cloud service 1356 (e.g., ...). Figure 12 Cloud services (1256).

[0171] In some examples, data plane VCN 1318 may be included in customer lease 1321. In this case, the IaaS provider may provide control plane VCN 1316 for each customer, and the IaaS provider may establish a unique compute instance 1344 for each customer, included in service lease 1319. Each compute instance 1344 may allow communication between control plane VCN 1316 included in service lease 1319 and data plane VCN 1318 included in customer lease 1321. Compute instance 1344 may allow resources provisioned in control plane VCN 1316 included in service lease 1319 to be deployed or otherwise used in data plane VCN 1318 included in customer lease 1321.

[0172] In other examples, an IaaS provider's customer may have a database residing in customer lease 1321. In this example, control plane VCN 1316 may include data plane mirror application layer 1340, which may include one or more application subnets 1326. Data plane mirror application layer 1340 may reside in data plane VCN 1318, but it may not reside in data plane VCN 1318. That is, data plane mirror application layer 1340 may have access to customer lease 1321, but it may not reside in data plane VCN 1318 or be owned or operated by an IaaS provider's customer. Data plane mirror application layer 1340 may be configured to make calls to data plane VCN 1318, but may not be configured to make calls to any entities contained in control plane VCN 1316. Customers may expect to deploy or otherwise use resources provisioned in the control plane VCN 1316 in the data plane VCN 1318, and the data plane mirroring application layer 1340 can facilitate the customer's expected deployment or other use of resources.

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

[0174] In some embodiments, cloud service 1356 may be invoked by service gateway 1336 to access services that may not exist on public internet 1354, control plane VCN 1316, or data plane VCN 1318. The connection between cloud service 1356 and control plane VCN 1316 or data plane VCN 1318 may be inactive or continuous. Cloud service 1356 may reside on different networks owned or operated by an IaaS provider. Cloud service 1356 may be configured to receive invocations from service gateway 1336 and may be configured not to receive invocations from public internet 1354. Some cloud services 1356 may be isolated from other cloud services 1356, and control plane VCN 1316 may be isolated from cloud services 1356 that may not be in the same region as control plane VCN 1316. For example, control plane VCN 1316 may be located in "Region 1," while cloud service "Deployment 12" may be located in both Region 1 and "Region 2." If a call to deployment 12 is made by a service gateway 1336 contained in a control plane VCN 1316 located in region 1, the call can be forwarded to deployment 12 in region 1. In this example, the control plane VCN 1316 or deployment 12 in region 1 may be non-communicatively coupled to deployment 12 in region 2, or may otherwise communicate with deployment 12 in region 2.

[0175] Figure 14 This is a block diagram 1400 illustrating another example pattern of an IaaS architecture according to at least one embodiment. Service operator 1402 (e.g., Figure 12 The service provider 1202) can communicatively couple to the secure host lease 1404 (e.g., Figure 12 Secure hosting lease 1204), the secure hosting lease 1404 may include a virtual cloud network (VCN) 1406 (e.g., Figure 12 VCN 1206) and Secure Host Subnet 1408 (e.g., Figure 12The secure host subnet 1208). VCN 1406 may include LPG1410 (e.g., Figure 12 The LPG 1410 can be communicatively coupled to the SSH VCN 1412 via the LPG 1410 included in the SSH VCN 1412 (e.g., LPG 1210), and the LPG 1410 can be communicatively coupled to the SSH VCN 1412 via the LPG 1410 included in the SSH VCN 1412 (e.g., LPG 1210). Figure 12 SSH VCN 1212). SSH VCN 1412 may include SSH subnet 1414 (e.g., Figure 12 SSH subnet 1214), and SSH VCN 1412 can be communicatively coupled to control plane VCN 1416 via LPG 1410 included in control plane VCN 1416 (e.g., Figure 12 The control plane VCN 1216) and the LPG 1410 communicatively coupled to the data plane VCN 1418 (e.g., via the control plane VCN 1216) and the data plane VCN 1418 via the LPG 1410 contained in the data plane VCN 1418. Figure 12 Data plane 1218). Control plane VCN 1416 and data plane VCN 1418 may be included in service lease 1419 (e.g., Figure 12 (Service rental 1219).

[0176] The control plane VCN 1416 may include one or more load balancer (LB) subnets 1422 (e.g., Figure 12 The control plane DMZ layer 1420 of (one or more) LB subnets 1222) (e.g., Figure 12 The control plane DMZ layer 1220 may include one or more application subnets 1426 (e.g., similar to...). Figure 12 The control plane application layer 1424 of (one or more) application subnets 1226 (e.g., Figure 12 The control plane application layer 1224 may include (one or more) control plane data layers 1428 of the DB subnet 1430 (e.g., Figure 12 The control plane data layer 1228). One or more LB subnets 1422 contained in the control plane DMZ layer 1420 can be communicatively coupled to one or more application subnets 1426 contained in the control plane application layer 1424 and to an Internet gateway 1434 that can be contained in the control plane VCN 1416 (e.g., Figure 12 Internet gateway 1234), and application subnet(s) 1426 can communicatively couple to DB subnet(s) 1430 contained in control plane data layer 1428 and to service gateway 1436 (e.g., Figure 12 The service gateway) and Network Address Translation (NAT) gateway 1438 (e.g., Figure 12(NAT gateway 1238). The control plane VCN 1416 may include the service gateway 1436 and the NAT gateway 1438.

[0177] Data plane VCN 1418 may include data plane application layer 1446 (e.g., Figure 12 Data plane application layer 1246), data plane DMZ layer 1448 (e.g., Figure 12 Data plane DMZ layer 1248), and data plane data layer 1450 (e.g., Figure 12 The data plane data layer 1250. The data plane DMZ layer 1448 may include one or more LB subnets 1422, which may be communicatively coupled to one or more trusted application subnets 1460 and one or more untrusted application subnets 1462 of the data plane application layer 1446, and an Internet gateway 1434 contained in the data plane VCN 1418. One or more trusted application subnets 1460 may be communicatively coupled to a service gateway 1436 contained in the data plane VCN 1418, a NAT gateway 1438 contained in the data plane VCN 1418, and one or more DB subnets 1430 contained in the data plane data layer 1450. One or more untrusted application subnets 1462 may be communicatively coupled to a service gateway 1436 contained in the data plane VCN 1418 and one or more DB subnets 1430 contained in the data plane data layer 1450. The data plane data layer 1450 may include one or more DB subnets 1430, which may be communicatively coupled to a service gateway 1436 contained in the data plane VCN 1418.

[0178] One or more untrusted application subnets 1462 may include one or more primary VNICs 1464(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 1466(1)-(N). Each tenant VM 1466(1)-(N) may be communicatively coupled to a corresponding application subnet 1467(1)-(N) that may be contained in a corresponding container egress VCN 1468(1)-(N) that may be contained in a corresponding customer lease 1470(1)-(N). A corresponding secondary VNIC 1472(1)-(N) may facilitate communication between one or more untrusted application subnets 1462 contained in a data plane VCN 1418 and application subnets contained in a container egress VCN 1468(1)-(N). Each container exit VCN 1468(1)-(N) may include a NAT gateway 1438, which can communicatively couple to the public Internet 1454 (e.g., Figure 12 The public internet (1254).

[0179] Internet gateway 1434, contained in control plane VCN 1416 and data plane VCN 1418, can be communicatively coupled to metadata management service 1452 (e.g., Figure 12 A metadata management system 1252, which is communicatively coupled to the public internet 1454, is also communicatively coupled to a NAT gateway 1438 contained in a control plane VCN 1416 and a data plane VCN 1418. A service gateway 1436 contained in both the control plane VCN 1416 and the data plane VCN 1418 is communicatively coupled to a cloud service 1456.

[0180] In some embodiments, the data plane VCN 1418 may be integrated with the customer lease 1470. This integration may be useful or desired by the IaaS provider's customer in certain situations, such as when support may be expected when executing code. The customer may provide code to run, which may be destructive, may communicate with other customer resources, or may otherwise cause undesirable effects. In response, the IaaS provider may determine whether to run the code provided by the customer.

[0181] In some examples, an IaaS provider's customer can grant temporary network access to the IaaS provider and request functionality to be attached to data plane layer application 1446. The code running this functionality can execute in VM 1466(1)-(N), and the code does not need to be configured to run anywhere else on data plane VCN 1418. Each VM 1466(1)-(N) can be connected to a customer lease 1470. The corresponding container 1471(1)-(N) contained in VM 1466(1)-(N) can be configured to run the code. In this scenario, dual isolation can exist (e.g., container 1471(1)-(N) runs code, where container 1471(1)-(N) may be contained at least within VM 1466(1)-(N), which is contained within one or more untrusted application subnets 1462), which can help prevent incorrect or otherwise unintended code from corrupting the IaaS provider's network or the networks of different customers. Container 1471(1)-(N) may be communicatively coupled to customer lease 1470 and may be configured to send or receive data from customer lease 1470. Container 1471(1)-(N) may not be configured to send or receive data from any other entity in data plane VCN 1418. After the code execution is complete, the IaaS provider may terminate or otherwise dispose of container 1471(1)-(N).

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

[0183] In other embodiments, the control plane VCN 1416 and the data plane VCN 1418 may be coupled without direct communication. In this embodiment, there may be no direct communication between the control plane VCN 1416 and the data plane VCN 1418. However, communication may occur indirectly through at least one method. The LPG 1410 may be established by an IaaS provider, which can facilitate communication between the control plane VCN 1416 and the data plane VCN 1418. In another example, either the control plane VCN 1416 or the data plane VCN 1418 may make a call to the cloud service 1456 via the service gateway 1436. For example, a call from the control plane VCN 1416 to the cloud service 1456 may include a request for a service that can communicate with the data plane VCN 1418.

[0184] Figure 15 This is a block diagram 1500 illustrating another example pattern of an IaaS architecture according to at least one embodiment. Service operator 1502 (e.g., Figure 12 The service provider 1202) can communicatively couple to the secure host lease 1504 (e.g., Figure 12 The secure hosting lease 1204 may include a virtual cloud network (VCN) 1506 (e.g., Figure 12 VCN 1206) and Secure Host Subnet 1508 (e.g., Figure 12 The secure host subnet 1208). VCN 1506 can include LPG1510 (e.g., Figure 12 The LPG 1210), which can be communicatively coupled to the SSH VCN 1512 via the LPG 1510 included in the SSH VCN 1512 (e.g., LPG 1210), Figure 12 SSH VCN 1212). SSH VCN 1512 can include SSH subnet 1514 (e.g., Figure 12 SSH subnet 1214), and SSH VCN 1512 can be communicatively coupled to control plane VCN 1516 via LPG 1510 included in control plane VCN 1516 (e.g., Figure 12 The control plane VCN 1216) and the LPG 1510 communicatively coupled to the data plane VCN 1518 (e.g., via the control plane VCN 1216) and the data plane VCN 1518 via the LPG 1510 contained in the data plane VCN 1518. Figure 12 Data plane 1218). Control plane VCN 1516 and data plane VCN 1518 may be included in service lease 1519 (e.g., Figure 12 (Service rental 1219).

[0185] The control plane VCN 1516 may include one or more LB subnets 1522 (e.g., Figure 12 The control plane DMZ layer 1520 of (one or more) LB subnets 1222) (e.g., Figure 12 The control plane DMZ layer 1220 may include one or more application subnets 1526 (e.g., Figure 12 The control plane application layer 1524 of (one or more) application subnets 1226 (e.g., Figure 12 The control plane application layer 1224) may include one or more DB subnets 1530 (e.g., Figure 14 The control plane data layer 1528 of (one or more) DB subnets 1430 (e.g., Figure 12 The control plane data layer 1228). One or more LB subnets 1522 contained in the control plane DMZ layer 1520 can be communicatively coupled to one or more application subnets 1526 contained in the control plane application layer 1524 and an Internet gateway 1534 that can be contained in the control plane VCN 1516 (e.g., Figure 12 Internet gateway 1234), and application subnet(s) 1526 can communicatively couple to DB subnet(s) 1530 contained in control plane data layer 1528 and service gateway 1536 (e.g., Figure 12 The service gateway) and Network Address Translation (NAT) gateway 1538 (e.g., Figure 12 (NAT gateway 1238). The control plane VCN 1516 may include the service gateway 1536 and the NAT gateway 1538.

[0186] Data plane VCN 1518 may include data plane application layer 1546 (e.g., Figure 12 Data plane application layer 1246), data plane DMZ layer 1548 (e.g., Figure 12 Data plane DMZ layer 1248), and data plane data layer 1550 (e.g., Figure 12 The data plane data layer 1250). The data plane DMZ layer 1548 may include one or more LB subnets 1522, which may be communicatively coupled to one or more trusted application subnets 1560 of the data plane application layer 1546 (e.g., Figure 14 (one or more) trusted application subnets 1460 and (one or more) untrusted application subnets 1562 (e.g., Figure 14The data plane VCN 1518 may include one or more untrusted application subnets 1462 and an Internet gateway 1534. One or more trusted application subnets 1560 may be communicatively coupled to a service gateway 1536, a NAT gateway 1538, and one or more DB subnets 1530 within the data plane VCN 1518. One or more untrusted application subnets 1562 may be communicatively coupled to a service gateway 1536 and a DB subnet 1530 within the data plane VCN 1518. The data plane VCN 1550 may include one or more DB subnets 1530 that may be communicatively coupled to a service gateway 1536 within the data plane VCN 1518.

[0187] One or more untrusted application subnets 1562 may include a primary VNIC 1564(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 1566(1)-(N) residing within one or more untrusted application subnets 1562. Each tenant VM 1566(1)-(N) may run code in a corresponding container 1567(1)-(N) and be communicatively coupled to an application subnet 1526 that may be contained in a data plane application layer 1546, which may be contained in a container egress VCN 1568. A corresponding secondary VNIC 1572(1)-(N) may facilitate communication between one or more untrusted application subnets 1562 contained in a data plane VCN 1518 and the application subnets contained in a container egress VCN 1568. The container's egress VCN may include a NAT gateway 1538, which can communicatively couple to the public internet 1554 (e.g., Figure 12 The public internet (1254).

[0188] Internet gateway 1534, contained in control plane VCN 1516 and data plane VCN 1518, can be communicatively coupled to metadata management service 1552 (e.g., Figure 12 A metadata management system 1252 is communicatively coupled to the public internet 1554. The public internet 1554 is communicatively coupled to a NAT gateway 1538 contained in a control plane VCN 1516 and a data plane VCN 1518. A service gateway 1536 contained in a control plane VCN 1516 and a data plane VCN 1518 is communicatively coupled to a cloud service 1556.

[0189] In some examples, by Figure 15 The architecture diagram of block diagram 1500 can be considered as a pattern. Figure 14 The architecture shown in block diagram 1400 is an exception to the pattern, and may be what the IaaS provider's customers expect if the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected region). The corresponding container 1567(1)-(N) contained in each customer's VM 1566(1)-(N) is accessible to the customer in real time. Container 1567(1)-(N) can be configured to make calls to the corresponding secondary VNIC 1572(1)-(N) contained in one or more application subnets 1526 of the data plane application layer 1546, which may be contained in the container egress VCN 1568. The secondary VNIC 1572(1)-(N) can forward the calls to a NAT gateway 1538, which can then forward the calls to the public internet 1554. In this example, containers 1567(1)-(N), which can be accessed by clients in real time, can be isolated from the control plane VCN 1516 and from other entities contained in the data plane VCN 1518. Containers 1567(1)-(N) can also be isolated from resources from other clients.

[0190] In other examples, a client may use containers 1567(1)-(N) to invoke cloud service 1556. In this example, the client may run code within containers 1567(1)-(N) requesting services from cloud service 1556. Container 1567(1)-(N) may forward this request to a secondary VNIC 1572(1)-(N), which may forward the request to a NAT gateway, which may forward the request to the public internet 1554. The public internet 1554 may forward the request via internet gateway 1534 to one or more LB subnets 1522 contained in control plane VCN 1516. In response to determining that the request is valid, one or more LB subnets may forward the request to one or more application subnets 1526, which may forward the request to cloud service 1556 via service gateway 1536.

[0191] It should be understood that the IaaS architectures 1200, 1300, 1400, and 1500 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 those shown in the figures, may combine two or more components, or may have different configurations or arrangements of components.

[0192] In some embodiments, the IaaS system described herein may include a suite of application, middleware, and database services 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 the applicant.

[0193] Figure 16 An example computer system 1600, in which various embodiments can be implemented, is illustrated. System 1600 can be used to implement any of the computer systems described above. As shown, computer system 1600 includes a processing unit 1604 that communicates with a plurality of peripheral subsystems via a bus subsystem 1602. These peripheral subsystems may include a processing acceleration unit 1606, an I / O subsystem 1608, a storage subsystem 1618, and a communication subsystem 1624. Storage subsystem 1618 includes a tangible computer-readable storage medium 1622 and system memory 1610.

[0194] Bus subsystem 1602 provides a mechanism for enabling the various components and subsystems of computer system 1600 to communicate with each other as intended. Although bus subsystem 1602 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1602 can be any of several types of bus architectures, including memory buses or memory controllers, peripheral buses, and local buses using any of a wide variety of 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 that may be implemented as mezzanine buses manufactured according to the IEEE P1386.1 standard.

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

[0196] In various embodiments, processing unit 1604 can execute a wide variety of 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 may reside in processor(s) 1604 and / or storage subsystem 1618. With appropriate programming, processor(s) 1604 can provide the various functions described above. Furthermore, computer system 1600 may include processing acceleration unit 1606, which may include a digital signal processor (DSP), a dedicated processor, and / or the like.

[0197] The I / O subsystem 1608 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 the display, scroll wheels, click wheels, dial pads, buttons, switches, keypads, 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 natural user interfaces that enable users to control input devices using gestures and verbal commands (such as Microsoft...). Microsoft 360 Game Controller and its interaction Motion sensors. User interface input devices may also include eye gesture recognition devices, such as those used by Google. A blink detector detects eye movements from the user (e.g., blinking when taking a photo and / or making menu selections) and translates the eye gestures into the input device (e.g., Google). Input from a voice recognition system (e.g., voice commands). Additionally, the user interface input device may include features that enable the user to interact with a voice recognition system via voice commands. Voice recognition sensing devices for interaction with navigators.

[0198] User interface input devices may also include, but are not limited to, 3D mice, joysticks or pointers, game controllers, and graphics 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 and digital musical instruments.

[0199] User interface output devices may include display subsystems, indicator lights, or non-visual displays such as audio output devices. 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 used to encompass all possible types of devices and mechanisms for outputting information from computer system 1600 to the user or other computers. For example, user interface output devices may include, but are not limited to, a wide variety of 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.

[0200] Computer system 1600 may include a storage subsystem 1618 that can provide 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 1604, provide the aforementioned functionality. Storage subsystem 1618 may also provide a repository for storing data used according to this disclosure.

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

[0202] System memory 1610 may also store operating system 1616. Examples of operating system 1616 may include various versions of Microsoft operating system 1616. Apple and / or Linux operating system, a variety of commercial... Or a UNIX-like operating system (including but not limited to various GNU / Linux operating systems, Google...) OS and / or mobile operating systems, such as iOS, Phone OS OS and Operating system (OS). In some implementations of computer system 1600 that execute one or more virtual machines, the virtual machine, along with its guest operating system (GOS), may be loaded into system memory 1610 and executed by one or more processors or cores of processing unit 1604.

[0203] Depending on the type of computer system 1600, system memory 1610 can have different configurations. For example, system memory 1610 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 1610 may include a basic input / output system (BIOS), which contains basic routines that facilitate the transfer of information between elements within computer system 1600 (such as during startup).

[0204] Computer-readable storage medium 1622 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 used by computer system 1600, including instructions executable by processing unit 1604 of computer system 1600.

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

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

[0207] Machine-readable instructions executable by one or more processors or cores of processing unit 1604 may be stored on a non-transitory computer-readable storage medium. A non-transitory computer-readable storage medium may include physically tangible memory or storage devices that include volatile memory storage devices and / or non-volatile memory storage devices. Examples of non-transitory computer-readable storage media include magnetic storage media (e.g., magnetic disks or magnetic 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.

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

[0209] In some embodiments, the communication subsystem 1624 may also receive input communications on behalf of one or more users who may use the computer system 1600 in the form of structured and / or unstructured data feeds 1626, event streams 1628, event updates 1630, etc.

[0210] For example, the communication subsystem 1624 can be configured to receive data feeds 1626 in real time from users of social networks and / or other communication services, such as... feed, Updates, web feeds such as rich site summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0211] Furthermore, the communication subsystem 1624 can also be configured to receive data in the form of a continuous data stream, which may include an event stream 1628 of real-time events and / or event updates 1630, which may be continuous or unbounded in nature without a definite end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial stock analysis, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, vehicle traffic monitoring, etc.

[0212] The communication subsystem 1624 can also be configured to output structured and / or unstructured data feeds 1626, event streams 1628, event updates 1630, etc., to one or more databases that can communicate with one or more streaming data source computers coupled to the computer system 1600.

[0213] The computer system 1600 can be of a variety of types, including handheld portable devices (e.g., Cellular phone Computing tablets, PDAs), and wearable devices (e.g., Google). Head-mounted displays, PCs, workstations, mainframes, kiosks, server racks, or any other data processing systems.

[0214] Due to the constantly evolving nature of computers and networks, the description of the computer system 1600 depicted in the figures is intended only as a particular example. Many other configurations with more or fewer components than the system depicted in the figures are possible. For example, custom hardware may also be used and / or specific elements may be implemented in hardware, firmware, software (including small applications), or a combination thereof. Furthermore, connectivity with other computing devices, such as network input / output devices, may be employed. Based on the disclosure and teachings provided herein, those skilled in the art will understand other ways and / or methods for implementing the various embodiments.

[0215] Although 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 freely operate within multiple data processing environments. Furthermore, although the embodiments have been described using a specific series of transactions and steps, it will be apparent to those skilled in the art 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.

[0216] 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 may be implemented on the same or different processors in any combination. Thus, where a component or module is described as being configured to perform certain operations, such a configuration may be implemented, 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 wide variety of techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0217] Therefore, the specification and drawings are to be considered 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, although specific disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the appended claims.

[0218] In the context of describing the disclosed embodiments (particularly in the context of the appended claims), the terms “a,” “an,” and “the,” and similar pronouns, should be interpreted as encompassing both the singular and plural, unless otherwise stated herein or clearly contradicted by the context. Unless otherwise stated, the terms “comprising,” “having,” “including,” and “containing” should be interpreted as open-ended terms (i.e., meaning “including, but not limited to”). The term “connected to” should be interpreted as partially or wholly included, attached to, or combined with, even if something else is involved. Unless otherwise stated herein, the enumeration of numerical ranges herein is intended only as a concise way of expressing each separate value falling within that range, and each separate value is incorporated into the specification as if it were listed separately herein. Unless otherwise stated herein or clearly contradicted by the context, all methods described herein can be performed in any suitable order. Unless otherwise claimed, 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 limit the scope of this disclosure. No language in the specification should be construed as indicating that any unclaimed element is essential to the practice of this disclosure.

[0219] Unless otherwise expressly stated, disjunctive language such as the phrase “at least one of X, Y, or Z” is intended to be understood in context as generally used to indicate that an item, term, etc., can be X, Y, or Z or any combination thereof (e.g., X, Y, and / or Z). Therefore, such disjunctive language is generally not intended 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.

[0220] This document describes preferred embodiments of the present disclosure, including known best modes 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 appropriately employ such variations, and the present disclosure can be practiced in addition to those specifically described herein. Therefore, the present disclosure includes all modifications and equivalents of the subject matter set forth in the appended claims as permitted by applicable law. Furthermore, unless otherwise stated herein, any combination of the foregoing elements in all possible variations is included in this disclosure.

[0221] All references cited herein, including publications, patent applications and patents, are incorporated herein by reference to the extent that each reference is individually and explicitly indicated as being incorporated herein by reference in its entirety.

[0222] In the foregoing description, aspects of this disclosure have been described with reference to specific embodiments thereof; however, 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 alone or in combination. Various modifications and equivalents are possible without including relevant and appropriate combinations of the features disclosed in the embodiments. Furthermore, the embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of this specification. Therefore, the description and drawings are to be considered illustrative rather than restrictive.

Claims

1. A system comprising: A network structure for a data center, the network structure comprising multiple network cables routed through the data center, the multiple network cables being characterized by a static network topology, and a group of network cables among the multiple network cables being configured to terminate at a location within the data center; as well as Multiple computing devices that can be located at the location in the data center are configured to form a regional network when they are communicatively connected to the network cabling according to a connection plan generated at least in part based on the static network topology and the configuration of the multiple computing devices.

2. The system according to claim 1, wherein the static network structure topology corresponds to a Clos network.

3. The system according to claim 1 or claim 2, wherein the networking cable assembly includes a cable termination connector corresponding to at least one of Multi-Fiber Push-In (MPO), Multi-Fiber Pull-Out, Small Form Factor (SFP), SFP+, SFP28, Quad Small Form Factor (QSFP), QSFP+, QSFP28 or RJ45.

4. The system according to any one of claims 1 to 3, wherein the networking cable group is a first networking cable group, wherein the plurality of networking cables includes a second networking cable group configured to terminate at a second location in the data center, and further includes an additional plurality of computing devices that can be located at the second location in the data center and configured to form an updated local area network when communicatively connected to the second networking cable group.

5. The system of claim 4, wherein the updated regional network is characterized by a second connectivity plan, which is generated at least in part based on a second configuration of the static network topology, the regional network, and the additional plurality of computing devices.

6. A method comprising: The static network structure at the network service receives physical build requests to connect multiple computing devices to the data center. In response to receiving the physical build request: The configuration of the plurality of computing devices is determined by the network service; as well as The static network topology of the data center is determined by the network service. as well as The network service uses the configuration and the static network topology to generate a connection plan for connecting the network cable group of the static network structure to the plurality of computing devices. The connection plan includes instructions for connecting each network cable in the network cable group to the corresponding network port of the network device of the plurality of computing devices to form a local area network.

7. The method of claim 6, wherein the plurality of computing devices are communicatively connected to a networked device, and wherein determining the configuration of the plurality of computing devices includes determining the arrangement of the network connections from the plurality of computing devices to the networked device.

8. The method of claim 6, wherein determining the configuration of the plurality of computing devices includes obtaining configuration parameters from data storage, the configuration parameters corresponding to the arrangement of network connections between the plurality of computing devices and one or more networking devices on a rack.

9. The method according to any one of claims 6 to 8, wherein determining the static network structure topology includes obtaining a predetermined topology of the static network structure of the data center from data storage.

10. The method of claim 9, wherein the predetermined topology of the static network structure corresponds to a Clos network.

11. The method of any one of claims 6 to 10, wherein generating the connection plan includes determining the network cable group from a plurality of network cables of the static network structure configured to terminate at a location in the data center.

12. The method according to any one of claims 6 to 11, further comprising: The network service determines the additional configuration of a plurality of additional computing devices communicatively connected to the second networked device; as well as The network service uses the configuration, the additional configuration, and the static network topology to generate a second connection plan for connecting a second network cable group of the static network structure to the additional multiple computing devices. The second connection plan includes additional instructions that can be used to connect each network cable in the second network cable group to the corresponding network port of the second network device to form an updated local area network.

13. The method of claim 12, wherein generating the second connectivity plan includes determining a second network cable group configured to terminate at a second location in the data center; and Determine the connection arrangement between the second networking cable group and the second networking device to communicatively connect the additional plurality of computing devices to the plurality of computing devices in the updated local area network.

14. A non-transitory computer-readable storage medium storing computer-executable instructions, which, when executed by one or more processors, cause a computer system to at least: Receive physical build requests to connect multiple computing devices to a static network structure in the data center; In response to receiving the physical build request: Determine the configuration of the plurality of computing devices; as well as Determine the static network topology of the static network structure of the data center; as well as The configuration and the static network topology are used to generate a connection plan for connecting the network cable group of the static network structure to the plurality of computing devices. The connection plan includes instructions for connecting each network cable in the network cable group to the corresponding network port of the network device of the plurality of computing devices to form a local area network.

15. The non-transitory computer-readable medium of claim 14, wherein the plurality of computing devices are communicatively connected to a networking device, and wherein determining the configuration of the plurality of computing devices includes determining the arrangement of the network connections from the plurality of computing devices to the networking device.

16. The non-transitory computer-readable medium of claim 14, wherein determining the configuration of the plurality of computing devices includes obtaining configuration parameters from data storage, the configuration parameters corresponding to the arrangement of network connections between the plurality of computing devices and one or more networking devices on a rack.

17. The non-transitory computer-readable medium according to any one of claims 14 to 16, wherein determining the static network structure topology includes obtaining a predetermined topology of the static network structure of the data center from data storage.

18. The non-transitory computer-readable medium of claim 17, wherein the predetermined topology of the static network structure corresponds to a Clos network.

19. The non-transitory computer-readable medium of any one of claims 14 to 18, wherein generating the connection plan includes determining the network cable group from a plurality of network cables of the static network structure configured to terminate at a location in the data center.

20. The non-transitory computer-readable medium according to any one of claims 14 to 19, wherein the computing system is further configured to store further instructions, which, when executed by the one or more processors, cause the computing system to further: Determine the additional configuration of multiple additional computing devices communicatively connected to the second networking device; and Using the configuration, the additional configuration, and the static network topology, a second connection plan is generated to connect the second network cable group of the static network structure to the additional multiple computing devices. The second connection plan includes additional instructions that can be used to connect each network cable in the second network cable group to the corresponding network port of the second network device to form an updated local area network.

Images