Technology for cable termination protection devices in prefabricated factories

Abstract

A cable termination protection device and its use in a prefabricated factory are disclosed. The cable termination protection device may comprise a frame with ports on its surface. Each port can be configured to accept cable termination connectors for networking cables of a static network fabric in a prefabricated factory. A computing device can generate instructions that can be used to disconnect networking cables from the cable termination protection device and to reconnect networking cables at the networking ports of networking devices in a regional data center rack. A computing device can receive a request to build a regional data center rack. In response, the computing device can obtain physical configuration parameters and cabling specification information for the computing device on the data center rack. The computing device can use the physical configuration parameters and cabling specification information to generate the above instructions.

Description

Technical Field

[0001] Cross - reference to Related Applications This application is an international application claiming the priority and benefits of U.S. Non - Provisional Patent Application No. 18 / 122,678, filed on March 16, 2023, entitled "TECHNIQUES FOR A CABLE TERMINATION PROTECTION APPARATUS IN A PREFAB FACTORY" (Attorney Docket No. 088325 - 1328943(344030US)). This application also claims the priority and benefits of the following related applications.

[0002] (1) U.S. Non - Provisional Patent Application No. 18 / 122,674, filed on March 16, 2023, entitled "TECHNIQUES FOR BUILDING CLOUD REGIONS AT A PREFAB FACTORY" (Attorney Docket No. 088325 - 1307191(344000US)) (2) U.S. Non - Provisional Patent Application No. 18 / 122,676, filed on March 16, 2023, entitled "STATIC NETWORK FABRIC AT A PREFAB FACTORY" (Attorney Docket No. 088325 - 1328941(344010US)) (3) U.S. Non - Provisional Patent Application No. 18 / 122,677, filed on March 16, 2023, entitled "MOBILE PREFAB FACTORY FOR BUILDING CLOUD REGIONS" (Attorney Docket No. 088325 - 1328942(344020US)) (4) U.S. Non - Provisional Patent Application No. 18 / 122,675, filed on March 16, 2023, entitled "TECHNIQUES FOR VALIDATING CLOUD REGIONS BUILT AT A PREFAB FACTORY" (Attorney Docket No. 088325 - 1373430(344040US)) All of the content of the above - mentioned applications is incorporated herein by reference for all purposes.

[0003] field This disclosure relates to cloud computing data centers. More specifically, this disclosure describes technology for cable termination protection devices that can be used for cabling between computing devices when constructing regional data centers in prefabricated factories. [Background technology]

[0004] background Cloud infrastructure providers may operate one or more data centers in geographical areas around the world. A "region" is a logical abstraction of a collection of computing, storage, and networking resources in a given geographical area of ​​data centers used to deliver cloud computing infrastructure. Building a new region may involve provisioning computing resources, configuring infrastructure, and deploying code to these resources, but is typically done via network connectivity to data centers. However, building a region with physical resources located at the final target data center site requires extensive preparatory work at the data center, and scheduling logistics and completing the region's construction can be complex. [Overview of the Initiative]

[0005] Brief Overview Embodiments of this disclosure relate to the automated construction of a region using a prefabricated factory. The prefabricated factory may be a facility dedicated to configuring computing devices, networking devices, and other physical resources to be delivered to a target site (e.g., a target region (one or more data centers, customer facilities, etc. in a geographic area)). The work to construct the region may include bootstrapping (e.g., provisioning and / or deployment) resources (e.g., infrastructure components, artifacts, etc.) for any number of services that may be available in the region when delivered to the destination. Once configured in the prefabricated factory, the physical resources may be sent to the target site, deployed in the target data center, and have their final configuration and other software resources deployed. Resources used for bootstrapping (e.g., software artifacts, software images, etc.) may be provided in a bootstrap environment in an existing region (e.g., one or more data centers in a host region). The host region may be selected based on its network proximity to the prefabricated factory, and complementaryly, the prefabricated factory may be located such that it has high-performance network connectivity to one or more host regions to support the bootstrap environment. The construction of a region may be comprised of one or more cloud-based services that manage the inventory of physical computing devices used to construct the region in a prefabricated factory, generate and specify the configuration of the region to be constructed in the prefabricated factory, manage the bootstrapping of the region, configure the region for delivery to the target site, and test and verify the physical resources after they have been deployed at the target site. The prefabricated region may be constructed to meet the configuration preferences of a particular customer (made-to-order) or to meet common specifications that can be further customized at the time of deployment at a particular customer's site (stock built).Because prefabricated factories can support numerous server racks and multiple installations and removals of these racks, networking cables within a prefabricated factory may be connected, disconnected, and reconnected to multiple devices across successive prefabricated region construction operations. This disclosure describes techniques for protecting cables and improving connection / disconnection operations.

[0006] One embodiment relates to a cable termination protection device that may comprise a frame having a plurality of ports arranged on its surface. Each port can be configured to accept a cable termination connector for a networking cable of a static network fabric in a data center (e.g., a prefabricated factory). In some examples, the ports may be positioned on the surface of the frame such that they substantially align with a second plurality of ports of a computing device (e.g., a top-of-rack switch) when the frame is positioned adjacent to the computing device. This alignment may be vertical or horizontal. The device may comprise port covers for the ports that can be inserted into the ports when no networking cable is connected to the device. Each port may correspond to one of several physical standards that define the cable termination connector of a networking cable.

[0007] Another embodiment relates to a system comprising a data center having a device rack that can be positioned in a location within the data center, a cable termination protection device mounted adjacent to the location with the device rack, and a plurality of networking cables routed through the data center, wherein at least one of the plurality of networking cables has a termination at the aforementioned location in the data center, and the termination of at least one networking cable is coupled to a cable termination connector. In some examples, at least one of the plurality of networking ports is configured to accept a cable termination connector, and at least one networking cable is movable between the networking port and the port of the cable termination protection device.

[0008] Another embodiment relates to a method for generating instructions usable for connecting data center rack networking cables in a data center having cable termination protection devices at a location for deploying a data center rack. This method may be performed by a computing device. This method may include receiving a request to build a regional data center rack. In response, the computing device may obtain physical configuration parameters for the computing device on the data center rack. The computing device may include a networking device having multiple networking ports. The physical configuration parameters may specify at least one of the networking ports of the networking device. This method may also include obtaining cabling specification information corresponding to multiple networking cables configured to terminate at the above location in the data center and at the cable termination protection devices. This method may also include generating the above instructions using the physical configuration parameters and the cabling specification information. These instructions may be usable for disconnecting networking cables from the cable termination protection devices and reconnecting networking cables at the networking ports of the networking device.

[0009] To facilitate the identification of discussions of any particular element or behavior, the leading one or more digits of a reference number represent the figure number in which that element was first introduced. [Brief explanation of the drawing]

[0010] [Figure 1] A block diagram showing a prefabricated factory for constructing a region and preparing region computing devices to be transported to a target data center, according to at least one embodiment. [Figure 2] A block diagram showing a prefabricated factory connected to a service provided by a CSP for building a region, according to at least one embodiment. [Figure 3]Block diagram showing a CSP system including multiple host regions that can support ViBE for deploying software resources to a prefabricated region constructed in a prefabricated factory, according to at least one embodiment. [Figure 4] A block diagram showing the arrangement of physical computing resources in a prefabricated factory managed by management services and inventory services, according to at least one embodiment. [Figure 5] This figure shows the management of network configurations for computing resources in a region built in a prefabricated factory by using management services and network services, according to at least one embodiment. [Figure 6] This figure shows the testing and evaluation of a region after delivery to the target site using management services and test services, according to at least one embodiment. [Figure 7] This figure shows an exemplary method for deploying software resources to physical resources in a region constructed in a prefabricated factory, according to at least one embodiment, in order to prepare the physical resources for transport to a target data center. [Figure 8] This figure shows an exemplary method for booting up physical resources constructed in a prefabricated factory after delivery to a target data center, according to at least one embodiment, and verifying the network configuration of the physical resources. [Figure 9A] This figure shows an exemplary configuration of a cable termination protection device that may be installed in a prefabricated factory according to several embodiments. [Figure 9B] This figure shows an exemplary configuration of a cable termination protection device that may be installed in a prefabricated factory according to several embodiments. [Figure 10]This figure shows exemplary steps for disconnecting networking cables from a CTPA and reconnecting networking cables to networking devices according to instructions generated based on the physical configuration parameters of the network fabric and networking devices of a prefabricated factory, according to at least one embodiment. [Figure 11] This figure shows an exemplary method for generating instructions that can be used to disconnect a networking cable from a CTPA in a prefabricated factory and to reconnect the networking cable to a networking device, according to at least one embodiment. [Figure 12] This is a block diagram showing a pattern for implementing a service-type cloud infrastructure system according to at least one embodiment. [Figure 13] This block diagram shows another pattern for implementing a service-type cloud infrastructure system according to at least one embodiment. [Figure 14] This block diagram shows another pattern for implementing a service-type cloud infrastructure system according to at least one embodiment. [Figure 15] This block diagram shows another pattern for implementing a service-type cloud infrastructure system according to at least one embodiment. [Figure 16] A block diagram showing an exemplary computer system according to at least one embodiment. [Modes for carrying out the invention]

[0011] Detailed explanation Example of automated data center construction (region construction) infrastructure In recent years, the adoption of cloud services has been rapidly increasing. Currently, various types of cloud services are offered by different cloud service providers (CSPs). The term "cloud service" is generally used to describe services or functions that are made available on demand (for example, through a subscription model) by a CSP through the use of the CSP's systems and infrastructure (cloud infrastructure). Typically, the servers and systems that make up the CSP's infrastructure and are used to deliver cloud services to customers are separate from the customer's own on-premises servers and systems. Therefore, customers can use cloud services provided by a CSP without having to purchase separate hardware and software resources for the service. Cloud services are designed to provide registered customers with easy, scalable, and on-demand access to applications and computing resources without requiring the customer to invest in procuring the infrastructure used to deliver the service or function. Cloud services can be offered in various different types or models, such as Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). Customers can subscribe to one or more cloud services offered by a CSP. Customers can be any entity, including individuals, organizations, corporations, and government agencies.

[0012] As described above, the CSP is responsible for providing the infrastructure and resources used to provide cloud services to registered customers. The resources provided by the CSP may include both hardware and software resources. These resources may include, for example, compute resources (such as virtual machines, containers, applications, processors, bare metal computers), memory resources (such as databases, data stores), networking resources (such as routers, host machines, load balancers), IDs, and other resources. In one embodiment, the resources provided by the CSP to provide a set of cloud services are organized as a data center. The data center may be configured to provide a specific set of cloud services. The CSP is responsible for installing the infrastructure and resources used to provide the specific set of cloud services into the data center. The CSP may build one or more data centers.

[0013] The data centers provided by the CSP may be hosted in different regions. A region is a local geographic area and can be identified by a region name. Regions are generally independent of each other and can be separated by long distances, for example, across countries or continents. Regions are grouped as realms. Examples of CSP regions include US West, US East, Australia East, South East Australia, etc.

[0014] A region may include one or more data centers, and these data centers are located within a certain geographical area corresponding to the region. As an example, the data centers in a region may be located in cities within the region. For instance, in the case of a specific CSP, the data centers in the western region of the US may be located in San Jose, California, the data centers in the eastern region of the US may be located in Ashburn, Virginia, the data centers in the eastern region of Australia may be located in Sydney, Australia, and the data centers in the southeastern region of Australia may be located in Melbourne, Australia.

[0015] As described above, a CSP provides cloud services to its customers by constructing or deploying data centers. As the customer base of the CSP expands, the CSP typically constructs new data centers in new regions or increases the capacity of existing data centers to better serve the increasing demands of its customers. It is preferable that the data centers be constructed geographically close to the locations of the customers served by the data centers. The geographical proximity between the data centers and the customers served by the data centers helps to more efficiently use resources and provide faster and more reliable services to the customers by reducing latency. Therefore, a CSP typically constructs new data centers in new regions in a geographical area that is geographically close to the customers served by the data centers. For example, if the customer base is expanding in Germany, the CSP may construct one or more data centers in a new region in Germany.

[0016] The process of building (one or more) data centers in a region and configuring them to provide cloud services is sometimes referred to as region build. The term "region build" is used to describe the construction of one or more data centers in a region. Region build involves provisioning or creating a set of new resources required or used to provide a set of services that the data centers are configured to offer. The final result of the region build process is the creation of a region that, along with the hardware and software resources it contains, is capable of providing the set of services that the region is intended for, and contains a set of resources used to provide that set of services.

[0017] Building a new region is an extremely complex operation requiring extensive coordination between various bootstrap operations. At a high level, it involves performing and coordinating various tasks such as identifying a set of services to be provided by the data center, identifying the various resources required to provide that set of services, generating, provisioning, and deploying the identified resources, and properly cabling the underlying hardware to enable the intended use. Each of these tasks has further subtasks that require coordination, further increasing the complexity. Due to this complexity, building a region currently involves multiple manually initiated or manually controlled tasks that require careful manual coordination. As a result, the task of building a new region (i.e., building one or more data centers in the region and configuring the hardware and software of each data center to provide the required cloud services) is very time-consuming. Building a region can take months, for example. Furthermore, the process is highly error-prone and may require multiple iterations before the desired configuration of the region is achieved, further increasing the time required for building a region (e.g., deploying hardware and software resources). These constraints and problems severely limit the CSP's ability to scale computing resources in a timely manner in response to growing customer needs.

[0018] Recent innovations have enabled CSPs to reduce build time, minimize wasted computing resources, and mitigate the risks associated with building regions. CSPs may also bootstrap services to new regions by adopting organization services. Organization services may be cloud-based services hosted in a separate region from the target region (for example, the organization region). To bootstrap services to the target region, an organization service can generate a bootstrap environment hosting instances of one or more cloud services. The organization service can then support the deployment of services to the target region by using the services within the bootstrap environment.

[0019] More recent innovations allow CSPs to concentrate region construction work in one or more facilities that can function as "factories" that generate partially or fully configured physical infrastructure and then deliver it to the target site. Instead of waiting for the target region's data center configuration and the deployment of physical components (e.g., servers, network switches, power supplies, etc.) within the data center before bootstrapping services to the target region, the CSP can construct the region in a prefabricated factory, send the configured physical components (e.g., racks) to the target data center, and then complete and verify the region's components after the racks arrive at the target site. Multiple regions can be constructed simultaneously in a prefabricated factory. Each region constructed in a prefabricated factory may have a distinct configuration, network topology, and services. By constructing regions in a prefabricated factory, the complexity of scheduling and logistics associated with preparing the target facility, delivering physical components to the target facility, and managing bootstrap resources within the cloud service can be significantly reduced because regions can be prefabricated and held until the target site is ready.

[0020] Prefabricated factories can also be used, for example, to build computing components that are integrated into customers' on-premises solutions when customers control and manage their own data center environments.

[0021] Centralized prefabricated factories support additional innovations for the efficient construction of regions. A prefabricated factory may include a static network fabric consisting of networking infrastructure (e.g., network switches, routers, cabling, etc.) designed to support any potential configuration of region components built within the factory. Therefore, the static network fabric enables the rapid placement of region physical resources within the factory and their connection to the existing network fabric. Even regions with different network topologies can be quickly connected to the same network fabric according to a connectivity plan that fits the static network fabric containing the region's physical components. The static network fabric reduces the complexity of network connectivity within regions of the factory, increasing the speed of deployment of region components within the factory and the removal of region components from the factory for delivery preparation. Complementarily, since the static network fabric provides a set of dedicated network connections to devices in various locations within the prefabricated factory, these connections can be protected by cable terminal protection devices (CTPAs) designed to accommodate each conceivable network connection (e.g., Ethernet, fiber optic, etc.) available for connecting to the region's factory network.

[0022] This disclosure pertains to a prefab factory where automated region construction is performed using one or more prefab services. A prefab management service can organize the entire region construction in the prefab factory. The management service, in conjunction with one or more additional prefab services, may function to manage an inventory of physical components used to configure the region in the prefab factory, configure the network (e.g., endpoints, network topology, addresses, and / or other identifiers for components within the region), bootstrap services onto the region infrastructure, prepare components for delivery of the region (including encryption of data volumes for security in transit), verify the region after delivery to the destination site and deployment at the destination site, and complete the region configuration (including performing any remaining bootstrap or update operations for services previously deployed to the region infrastructure in the prefab factory). This disclosure also describes features of the prefab factory itself that improve the automated region construction work, including a static network fabric of the prefab factory configured to support any potential region network topology without requiring special modifications, as well as a dedicated CTPA that improves the performance of the static network fabric. Finally, this disclosure also describes a mobile prefabricated factory that can perform some, some, or all of the automated region construction and related operations in the prefabricated factory during the transport of the region components to the target site.

[0023] A certain definition A "region" is a logical abstraction corresponding to a set of computing, storage, and networking resources associated with a geographical location. A region may contain any number of one or more execution targets. A region may be associated with one or more data centers. A "prefab region" represents a region built in a prefabricated factory environment prior to delivery to the corresponding geographical location. In some embodiments, the execution target may also correspond to a target data center rather than a prefabricated factory data center.

[0024] An "execution target" represents the smallest unit of change required to execute a release. A "release" represents a declaration of intent to organize specific changes to a service (e.g., a version 8 deployment, "adding an internal DNS record," etc.). For most services, an execution target represents an "instance" of the service or an instance of changes applied to the service. A single service may be bootstrapped for each of one or more execution targets. An execution target may be associated with a set of devices (e.g., a data center).

[0025] A "bootstrap" for a single service is intended to represent the collective task associated with the provisioning and deployment of any suitable number of resources (e.g., infrastructure components, artifacts, etc.) corresponding to that single service. A regional bootstrap is intended to represent the collective task associated with each individual bootstrap for each service intended within that region.

[0026] A "service" typically refers to a set of resources that provide functionality, usually in the form of an API, which a customer can invoke to achieve some useful result. This set of resources includes any suitable combination of infrastructure, platforms, or software (e.g., applications) hosted by a cloud provider that can be configured to provide the functionality of the service. The service may be available to users over the internet.

[0027] An "artifact" refers to code deployed to an infrastructure component or Kubernetes engine cluster, which can include software (e.g., applications), configuration information (e.g., configuration files), credentials, etc.

[0028] IaaS provisioning (or "provisioning") refers to acquiring computers or virtual hosts for use, and further, installing the necessary libraries or services for them. The expression "provisioning a device" refers to deploying a device to a state where it can be used by an end user for a specific purpose. A device that has gone through the provisioning process is sometimes called a "provisioned device." Creating a provisioned device (installing libraries and daemons) is considered part of provisioning, but this is different from deploying a new application or a new version of an application to the created device. In most cases, deployment does not include provisioning, and provisioning may need to be performed first. The created device is sometimes called an "infrastructure component."

[0029] An IaaS deployment (or "deployment") refers to the process of providing and / or installing a new application or a new version of an application to provisioned infrastructure components. Once infrastructure components are provisioned (e.g., acquired, allocated, created, etc.), additional software deployment (e.g., provided to and installed on the infrastructure components) may occur. After provisioning and deployment are complete, infrastructure components may be referred to as "resources" or "software resources." Examples of resources include, but are not limited to, virtual machines, databases, object storage, block storage, and load balancers.

[0030] A "virtual bootstrap environment" (ViBE) represents a virtual cloud network provisioned over an existing region (e.g., a "host region"). The provisioned ViBE connects to the new region using a communication channel (e.g., IPSec Tunnel VPN). Within the ViBE, essential core services (or "seed" services) such as a deployment orchestrator, public key infrastructure (PKI) services, dynamic host configuration protocol services (DHCP), and domain name services (DNS) can be provisioned. These services can provide the functionality necessary for bringing hardware online, establishing a trust chain to the new region, and deploying other services in the new region. By utilizing a virtual bootstrap environment, circular dependencies between bootstrap resources can be prevented by leveraging the resources of the host region. These services can be staged and tested within the ViBE before the prefabricated region (e.g., the target region) becomes available.

[0031] A "Manager Service" may represent a service configured to manage the provisioning and deployment of any number of services as part of the construction of a prefabricated region. The Manager Service, in conjunction with one or more additional prefabricated services, can manage the organization of region construction at the prefabricated factory, as well as the deployment and configuration of the prefabricated region at the target data center after construction and transport. The Manager Service and other prefabricated services may be hosted in an existing region of the CSP.

[0032] The "host region" refers to the region hosting the virtual bootstrap environment (ViBE). The host region can be used to bootstrap the ViBE.

[0033] The "target region" represents the region being constructed in the prefabricated factory. During the construction of the prefabricated region, the target region is associated with the physical space, power, and cooling provided by the prefabricated factory. After bootstrapping, the prefabricated region is sent to the target data center where it will be deployed and is then associated with that target data center.

[0034] Prefab Region Construction In some examples, this specification describes techniques for building regions in a prefabricated factory. Such techniques may include one or more prefabricated services (e.g., management services, network services, inventory services, test services, deployment organization systems) hosted by a CSP capable of managing the bootstrapping (e.g., provisioning and software deployment) of infrastructure components for one or more regions within the prefabricated factory, as outlined above. The prefabricated factory may be configured to support the simultaneous construction of multiple regions. For example, the physical resources for a first prefabricated region (e.g., server racks, network switches, etc.) may be deployed at one location in the prefabricated factory, while the physical resources for a second prefabricated region may be deployed at a second location in the prefabricated factory. Each prefabricated region may be connected to a dedicated network fabric of the prefabricated factory that independently provides networking connectivity to each prefabricated region, and thus be able to communicate with prefabricated services and / or other cloud services that support the region construction. Based on the build request (region specifications (e.g., the number of server racks in the region, the number of computing devices, the number and types of services hosted by the region, the network topology of the region, etc.)), the prefab service can generate instructions for the corresponding physical infrastructure to be deployed in the prefab factory (e.g., by factory personnel), which may include the integrated networking of physical devices on racks, the placement of racks at the location of the prefab factory, and the connection of devices to the static network fabric of the prefab factory. The management service can then organize the provisioning of the regional infrastructure and the deployment of software resources to the prefab regional infrastructure, configure the prefab region for delivery, manage the delivery of the prefab region (e.g., scheduling and monitoring), and perform testing and verification of the prefab region upon arrival at the target site.

[0035] Prefabricated factories can centralize the region construction process and streamline the use of computing and networking resources that support region construction. For example, a prefabricated factory may be located "near" the host region containing prefabricated services and / or ViBE (e.g., with low-latency and high-data-rate networking connectivity). Furthermore, building multiple regions with improved network connectivity to the host region can avoid the potential performance degradation that occurs when performing region construction on newly configured data center sites in a normal region construction. Prefabricated factories also improve the physical computing security for devices during region construction, because the CSP can control the prefabricated factory and its network connectivity.

[0036] Furthermore, prefabricated factories improve the management of physical component inventory. Management services can determine the computing devices required for a specific region's construction, which can be stored in or near the prefabricated factory. Along with the construction and transportation of the region, the infrastructure for the new region can be quickly brought into and deployed at the prefabricated factory, improving efficiency.

[0037] Referring here to the drawings, Figure 1 is a block diagram of a prefabricated system 100, which includes a prefabricated factory 102 for constructing regions (e.g., prefabricated region 106A, prefabricated region 106B, prefabricated region 106C) and preparing regional computing devices to be delivered to target data centers (e.g., data center 108, data center 110), according to at least one embodiment. Each region constructed in the prefabricated factory 102 may include one or more devices that constitute the computing environment of the data center. The use of the prefabricated factory 102 allows for the construction of multiple regions simultaneously. For example, the prefabricated factory 102 can simultaneously construct all of prefabricated regions 106A, 106B, and 106C. In some examples, the devices of the regions may be deployed and staged in the prefabricated factory 102 prior to the commencement of infrastructure provisioning and software deployment operations.

[0038] The prefabricated factory 102 can be a data center-like facility that includes sufficient power, cooling, and networking infrastructure to support the construction of one or more regions. The prefabricated factory 102 may be located in close proximity to the existing computing infrastructure of the CSP (e.g., CSP 104). For example, CSP 104 can operate its existing data center for one or more regions. By being located near or next to the existing data center of the host region, the prefabricated factory 102 can provide high data-rate network connectivity between the CSP's cloud services and the computing devices of the region being built in the prefabricated factory 102. As an addition or alternative, the prefabricated factory 102 may be positioned to improve logistical operations, including transportation to the target data center of the region.

[0039] A prefabricated region constructed in prefabricated factory 102 may 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.), and networking devices (e.g., switches, routers, gateways, etc.). Each region may have different physical resources depending on the specific requirements of the target region and data center. For example, prefabricated region 106A may comprise 100 racks, each having 40 computing devices. On the other hand, prefabricated region 106B may comprise 20 racks, each having 30 computing devices. Each rack of computing devices may include one or more networking devices configured to communicate with the server devices on that rack and connect to the networking infrastructure of prefabricated factory 102 to form a network with other computing devices in the prefabricated region. Each rack may also include power supplies and cooling systems to support the operation of the computing devices on the rack.

[0040] The prefabricated factory 102 may comprise any suitable number of networking devices to support the deployment and connection of one or more computing devices in the prefabricated region to be constructed. For example, the prefabricated factory 102 may comprise any suitable number of leaf and spine switches to support the connection of computing devices on multiple racks and constitute the network of the prefabricated region. Similarly, the prefabricated factory 102 may comprise network cabling that is deployed in the facility and can provide network connectivity to the networking infrastructure of the prefabricated factory 102. The network cabling may be arranged to terminate at locations within the prefabricated factory 102 where racks of computing devices for the prefabricated region can be deployed during the region construction work. Further details regarding the configuration of the networking infrastructure and the prefabricated factory are given below with respect to Figures 9 to 11.

[0041] The prefabricated factory 102 may be connected to services provided by CSP104 via one or more networks. During region construction, CSP104 can provision infrastructure components on the physical resources of the prefabricated region and deploy software resources, configurations, and / or other artifacts to the provisioned infrastructure components. For example, CSP104 can provision computing devices in prefabricated region 106A to host one or more virtual machines, provide hostnames, network addresses, and other network settings for the provisioned physical and virtual devices, and then deploy one or more services to run on the provisioned infrastructure. The prefabricated region may be in a state close to the final production state of the devices when they are deployed in the target facility.

[0042] Once a prefabricated region is constructed, physical resources may be configured for delivery / transportation to the target facility. In the context of use herein, the term “transmission” may be used synonymously with the term “transportation” when referring to the movement of physical resources associated with a prefabricated region from the prefabricated factory to the target site. Configuring a prefabricated region for delivery may include taking a “snapshot” of the current network configuration of computing devices in the prefabricated region, storing the snapshot, providing each computing device with a portion of the snapshot containing identifiers for each device in the network and its neighbors, encrypting the data volumes of the computing devices, and configuring the devices to boot in a test state upon power-on after delivery. In addition to network snapshots, the CSP104 prefab service may also capture device snapshots, which are disk images obtained for individual switches, compute devices, and smart NICs that are fully configured in the various racks being sent to the target site. Device snapshots allow for the rapid replacement of any device in a transported rack if it becomes non-functional after arrival and requires replacement. Transportation to the target facility can be carried out by one or more methods, including transportation by truck 112 or by aircraft 114. For example, prefabricated region 106B may be configured to be delivered to data center 108 by truck 112. On the other hand, prefabricated region 106C may be configured to be delivered to data center 110 by aircraft 114.

[0043] The computing devices in the prefabricated region may be deployed at the destination facility upon arrival, according to the facility's configuration. The destination facility could be a data center built to host the prefabricated region devices, with infrastructure such as networking, power, and cooling provided according to the prefabricated region's configuration. The data center may have network connectivity to CSP104. Deployment of the prefabricated region may include manual operations and other related tasks to connect the racks and their respective computing devices to the data center's network infrastructure. Once the physical connectivity is configured, powering on the devices in the prefabricated region allows the devices to initiate one or more test operations based on the configuration performed in the prefabricated factory 102 prior to delivery. The prefabricated region can communicate with prefabricated services by also connecting to CSP104 via one or more network connections to the data center. For example, prefabricated region 106B may connect to CSP104 via connection 118, while prefabricated region 106C may connect to CSP104 via connection 116. The prefab service can deploy the final configuration of the deployed devices in the target data center, deploy software resource updates on the deployed devices, and perform additional testing and verification operations on the prefab region.

[0044] Figure 2 is a block diagram of a prefabrication system 200, which includes a prefabrication factory 202 connected to a prefabrication service 210 provided by CSP204 for the construction of a region, according to at least one embodiment. The prefabrication factory 202 may be an example of the prefabrication factory 102 in Figure 1, and CSP204 may be an example of CSP104 in Figure 1. The prefabrication factory 202 may interact with CSP204 via a network 208, which may be a public network such as the Internet, a private network, or another network. The prefabrication service 210 may include a management service 212, an inventory service 214, a test service 216, an organization service 218, and a network service 220. The prefab service 210 is capable of performing actions corresponding to the construction of prefab region 206 in prefab factory 202, including managing the bootstrap environment (e.g., ViBE 222), provisioning infrastructure components in prefab region 206, deploying software resources to prefab region 206, configuring the network of prefab region 206, testing the prefab region at various stages of the construction process, and managing the physical inventory (e.g., physical inventory 224) of computing devices used to construct prefab region 206 and other prefab regions being built in prefab factory 202.

[0045] Management service 212 can perform tasks to coordinate the operation of prefab services 210, including scheduling prefab region construction work by other prefab services 210, generating physical construction requests and corresponding instructions, initiating the transport of prefab region 206 to the target site, and managing the provisioning and deployment of resources in prefab region 206 at both the prefab factory 202 and the target site. A physical construction request may specify the number and type of physical resources to be used in prefab region 206. A physical construction request may also include a set of instructions that personnel can use to deploy the corresponding physical resources in prefab factory 202. For example, management service 212 may generate a physical construction request that specifies the number of racks and server devices in prefab region 206, the number of networking devices available to connect the server devices and constitute the network of prefab region 206, and a connectivity plan that determines the networking connections between the specified server devices, networking devices, and the existing networking infrastructure of prefab factory 20. Furthermore, a physical build request may include instructions for an agent to retrieve physical devices from a relevant location (e.g., physical inventory 224) and instructions to deploy the devices to a designated location in the prefabricated factory 202. In some embodiments, the operation of a physical build request may be performed by an automated system under the control of the management service 212. For example, the retrieval of server device racks from the physical inventory 224 and the deployment of racks in the prefabricated factory 202 may be performed by a robotic system configured to move physical racks between sites.

[0046] The inventory service 214 may be configured to track and monitor physical devices corresponding to one or more regions (e.g., one or more data centers in a region). The inventory service 214 can also track physical devices for one or more prefabricated regions in the prefabricated factory 202 (e.g., prefabricated region 206). Tracking and monitoring physical devices may include maintaining an inventory of devices according to their identifiers (e.g., serial numbers, device names, etc.) and their association with data centers. The inventory service 214 can provide inventory information to other prefabricated services 210, including the management service 212, for use in the prefabricated region construction process. For example, the inventory service 214 can determine whether a physical device is located in the prefabricated factory 202 or the target site. The inventory service 214 can determine the location and / or association with a region, prefabricated region, or data center by querying devices over a network (e.g., network 208). Furthermore, the inventory service 214 can maintain a physical inventory (e.g., physical inventory 224) of devices stored for use in the prefabricated region construction work. For example, the inventory service 214 can track physical devices that, after being accepted in the physical inventory 224, are taken out of the physical inventory 224 and used as part of a prefabricated region in the prefabricated factory 202. In some examples, the inventory service 214 can provide the management service 212 with inventory information that can be used to generate physical construction requests for a prefabricated region 206, including instructions to retrieve physical resources from the physical inventory 224 and deploy them in the prefabricated factory 202.

[0047] The physical inventory 224 may be a warehouse or storage facility for storing physical resources (e.g., computing devices) used in the prefabricated region construction work. The physical inventory 224 may be located near the prefabricated factory 202 to facilitate the retrieval of physical resources in response to physical construction requests. For example, the physical inventory 224 may be in a building adjacent to the building used for the prefabricated factory 202. In some examples, the physical inventory 224 may be located within the prefabricated factory 202. The physical resources may be placed into and retrieved from the physical inventory 224 by personnel associated with the CSP and the prefabricated factory 202. In some cases, during the prefabricated region construction work, robots, automated guided vehicles, or other similar autonomous or semi-autonomous systems may be used to retrieve and deploy physical resources from the physical inventory 224 using instructions provided by the physical construction request.

[0048] The organization service 218 may be configured to perform bootstrap operations to provision infrastructure components in the prefabricated region 206 and deploy software resources to the prefabricated region 206. The organization service 218 may also configure a bootstrap environment (e.g., ViBE222) used when bootwrapping resources to the prefabricated region 206. The organization service 218 may be an example of the deployment orchestrator described above. In some examples, the organization service 218 may be configured to bootstrap (e.g., provision and deploy) services to a prefabricated region (e.g., prefabricated region 206) based on a predetermined configuration file that identifies resources (e.g., infrastructure components and software to be deployed) for implementing a given change in the prefabricated region. The organization service 218 can identify dependencies between resources by parsing and analyzing the configuration file. The analysis may generate specific data structures, which may be used to drive operations and manage the order in which services are bootstrapped to the region. The organization service 218 may use these data structures to identify when a service can be bootstrapped, when a bootstrap is blocked, and / or when a bootstrap operation associated with a previously blocked service can be resumed.

[0049] In some embodiments, the organization service 218 may include components configured to perform bootstrap tasks associated with a single service in a prefabricated region. The organization service 218 may maintain current state data indicating an optional preferred mode of the current state of the resources associated with the service. In some embodiments, the desired state data may include settings that declare a desired state for the resources associated with the service (e.g., by declarative statements). In some embodiments, the organization service 218 may identify one or more resources that require modification by comparing the desired state data with the current state data. For example, the organization service 218 may determine that it is necessary to provision one or more infrastructure components, deploy one or more artifacts, or make an optional preferred modification to the resources of the service to bring the state of those resources to a desired state. Specific details relating to a particular embodiment of the organization service 218 are given in U.S. Patent Application No. 17 / 016,754, entitled "Techniques for Deploying Infrastructure Resources with a Declarative Provisioning Tool," which is incorporated herein by reference for all purposes.

[0050] ViBE222 may be an example of a bootstrap environment that can be used to deploy resources to a prefabricated region in a prefabricated factory 202. ViBE may include a virtual cloud network (e.g., a network of cloud resources) implemented within a preferred region of a CSP (e.g., CSP204). ViBE may have one or more nodes (e.g., compute nodes, storage nodes, load balancers, etc.) that support hosting services deployed by the organization service 218. On the other hand, the use of ViBE services can support the deployment of services to the prefabricated region 206. For example, the organization service 218 may deploy an instance of one or more of its constituent services (e.g., an instance of the organization service 218) to the bootstrap environment, and the use of this instance may be used to deploy resources from ViBE222 to the prefabricated region 206. Since ViBE is implemented as a virtual cloud network in an existing region, support for services deployed in ViBE may involve provisioning an arbitrary and preferred amount of regional infrastructure (compared to the fixed hardware resources of the seed server). The organization service 218 may be configured to deploy software resources to ViBE222, as well as provision infrastructure resources for ViBE222 (e.g., virtual machines, compute instances, storage, etc.). ViBE222 can simultaneously support the bootstrap operation of two or more prefabricated regions in the prefabricated factory 202.

[0051] If a prefab region 206 is available to support bootstrap operations, connecting ViBE222 to prefab region 206 allows services within ViBE222 to interact with services and / or infrastructure components in prefab region 206. This enables the deployment of generation-level services instead of self-contained seed services as in traditional systems, and requires connectivity to the target region over the internet. Traditionally, seed services were deployed as part of a container collection and used to bootstrap the dependencies necessary for building the region. By using existing region infrastructure / tools, hardware provisioning and service deployment may be performed by bootstrapping resources to ViBE222 and connecting to prefab region 206 until prefab region 206 becomes self-sufficient (e.g., self-sufficient with respect to services hosted within prefab region 206). Using ViBE222 enables the establishment of dependencies and services necessary for infrastructure provisioning / creation and software deployment, while resolving circular dependencies of core services by utilizing resources in the host region.

[0052] Test service 216 may be configured to perform one or more test or verification operations on the prefab region 206 following the provisioning and / or deployment of resources. The test operations may be part of user approval tests that can be used to determine whether the behavior of the constructed region conforms to the construction specifications. For example, test service 216 may be configured to interact with instances of services deployed in the prefab region 206 to perform tests that verify the expected behavior of the queried services. As another example, test service 216 may be configured to perform networking tests that retrieve the hostnames, networking addresses, and / or other identifiers of the components of the prefab region 206 and compare them with the expected identifiers of the components, such as those specified in the specifications, such as the construction request for the prefab region 206. Test service 216 may be configured to perform test operations both during the prefab region construction process in the prefab factory 202 and after the prefab region 206 has been delivered to the target site. Test operations performed in the prefab factory 202 may be the same as or different from test operations performed after the prefab region 206 has been delivered to the target site.

[0053] Network service 220 may be configured to determine the network configuration of devices in prefabricated region 206. Using configuration information from build requests, network service 220 can determine the network topology of devices (e.g., servers, networking devices, racks of servers and networking devices). In the use herein, the network topology may represent a graphical representation of all networking connections between each computing device in the prefabricated region. Using configuration information, network service 220 can determine the physical networking connections (e.g., network cabling connections) between devices in the prefabricated region. Network service 220 may also provide networking connection information to management service 212, which is used to generate instructions for physically deploying devices in the prefabricated region at prefabricated factory 202. Additionally, network service 220 may obtain device information from inventory service 214 as part of determining the network topology of devices in the prefabricated region. Further details regarding network service 220 are given below with respect to Figures 5 and 6.

[0054] Figure 3 is a block diagram of a CSP system 300 that includes multiple host regions (e.g., host regions 304A to 304C) capable of supporting ViBEs (e.g., ViBE308A to 308C) for deploying software resources to a prefabricated region 306 constructed in a prefabricated factory 302, according to at least one embodiment. The prefabricated factory 302 may be an example of the prefabricated factory 202 described above with respect to Figure 2. Similarly, each of the ViBE308A to 308C may be an example of the ViBE222 in Figure 2, and the management service 312 may be an example of the management service 212 in Figure 2. The host regions 304A to 304C may correspond to regions of the CSP and may be associated with one or more data centers having computing resources for hosting the ViBEs. The host regions 304A to 304C may correspond to different geographical locations.

[0055] As shown in Figure 3, the management service 312 may be an instance within a host region (for example, host region 304B). In some embodiments, the management service 312 may correspond to CSP tenancy and therefore may have instances in multiple regions capable of providing prefab services (for example, host regions 304A, 304C). Similarly, other prefab services (for example, prefab service 210) may also be instances of services within a host region.

[0056] To support the construction of the prefabricated region at prefabricated factory 302, ViBE may be hosted in a host region. Since ViBE may be configured with organization services (e.g., organization service 218) as needed for bootstrapping the prefabricated region, it can be built in any suitable host region. Suitability as a host region may depend on network connectivity to prefabricated factory 302 (e.g., high bandwidth, high data rate, low latency network connectivity between the host region's data center and prefabricated factory 302), sufficient infrastructure resources to support ViBE for one or more prefabricated region construction operations (e.g., availability of the host region's computing resources over the time of provisioning and deployment of the prefabricated region), and / or jurisdictional considerations (e.g., the host region being in the same country as the prefabricated factory in accordance with data security regulations). For example, host region 304A may have a data center very close to prefabricated factory 302, which would result in low latency network connectivity between ViBE 308A and prefabricated region 306. In a series of prefabricated region construction operations, the ViBE used to support the construction of the prefabricated region may be configured in different host regions. For example, for one prefabricated region, ViBE308A may be used as part of the construction of the prefabricated region in prefabricated factory 302, but for subsequent region construction operations, ViBE308B in host region 304B or ViBE308C in host region 304C may be configured and used.

[0057] Furthermore, the prefabricated factory 302 may be constructed in a location that provides suitable connectivity to one or more host regions. For example, the prefabricated factory 302 may be configured at a site adjacent to a data center in host region 304A in order to provide suitable network connectivity between host region 304A and the prefabricated factory 302.

[0058] Figure 4 is a block diagram of a CSP system 400 having the arrangement of physical computing resources of a prefabricated factory 402 to different prefabricated regions 430, 440 according to at least one embodiment. The prefabricated factory 402 may be an example of the prefabricated factory 202 in Figure 2. The prefabricated services 410 may be provided by the CSP and may also be an example of the prefabricated services 210 described above with respect to Figure 2, and include management services 412 as an example of management services 212 in Figure 2, and inventory services 414 as an example of inventory services 214 in Figure 2. Similarly, prefabricated regions 430 and 440 may be examples of other prefabricated regions described herein (including prefabricated region 206 in Figure 2).

[0059] As described above, the prefabricated factory 402 may be configured to support the construction of multiple prefabricated regions simultaneously. As shown in Figure 4, the prefabricated factory 402 comprises prefabricated region 430 and prefabricated region 440. Prefabricated region 430 may include one or more server racks 432A to 432C. Each server rack may contain one or more devices (including server devices and networking devices). For example, server rack 432A may contain a switch 434 and a server device 436. Switch 434 may be a top-of-rack switch that provides networking connections to other server racks in prefabricated region 430 (for example, via the top-of-rack switch of those other server racks) or to other physical resources. Networking connections between physical resources in prefabricated region 430 may include part of the networking infrastructure 438. The networking infrastructure 438 may include a portion of the networking infrastructure of the prefabricated factory 402 (including network cabling, network switches, routers, etc., that constitute the network fabric of the prefabricated factory 402). Similarly, the prefabricated region 440 may include one or more server racks 442A and 442B. The computing devices they comprise may be more or less than those in the server racks 432A-432C of the prefabricated region 430. For example, server rack 442A may comprise a switch 444 and a server device 446.

[0060] Each prefab region may be at a different stage of the prefab region construction process at any given time. For example, infrastructure provisioning and resource deployment may be taking place in prefab region 430, while physical resources are being deployed in prefab region 440. Also, each prefab region in prefab factory 402 may have a different arrangement of physical resources. For example, prefab region 430 may contain more server racks (e.g., racks 432A-432C) than prefab region 440, and each server rack may support more computing devices than the server racks in prefab region 440 (e.g., server racks 442A, 442B). Because the number and arrangement of physical resources in each prefab region may differ, the network topology corresponding to the connections between physical resources may also differ from prefab region to prefab region.

[0061] The inventory service 414 can track the physical resources used to configure the prefabricated region in the prefabricated factory 402. The physical resources tracked by the inventory service 414 may include server devices and networking devices, as well as racks containing server devices and networking devices. The inventory service 414 can also track physical resources in the data center of the deployed region (including prefabricated region devices after delivery to the target site and deployment). In some embodiments, the inventory service 414 can connect to the prefabricated region (e.g., via a network) and query the device identifiers of devices in the prefabricated region. The inventory service 414 may also provide the management service 412 with information corresponding to the physical resources in the prefabricated region as part of the prefabricated region construction work. For example, the management service 412 may use inventory information from the inventory service 414 to determine whether the physical resources of the prefabricated region have been deployed in accordance with the physical construction request. In some embodiments, the inventory service 414 can also maintain information corresponding to the physical inventory 424 (e.g., repositories, warehouses, or other storage for physical resources such as computing devices used to configure the prefabricated region). Maintaining the physical inventory 424 may include tracking the number and types of physical resources available for use in the prefabricated region, maintaining a database or other data store of inventory information, updating the inventory information when new physical resources are added to the physical inventory 424 (e.g., delivery of new devices, configuration of server racks, etc.), and updating the inventory information when devices leave the physical inventory for use in the prefabricated factory 402 (as indicated by the arrows in Figure 4). In some examples, CSP personnel may interact with the inventory service 414 to manually update the inventory information.

[0062] The management service 412 can obtain inventory information from the inventory service 414 and use it when generating physical construction requests. For example, the management service 412 may use the inventory information to determine the physical resources to be deployed in the prefabricated factory 402 for the prefabricated region corresponding to the physical construction request.

[0063] Figure 5 shows a CSP system 500 for managing the network configuration of computing resources in a prefabricated region 530 constructed in a prefabricated factory 502, using a management service 512 and a network service 520, according to at least one embodiment. The prefabricated factory 502 and prefabricated region 530 may be examples of other prefabricated factories and prefabricated regions described herein (including the prefabricated factory 202 and prefabricated region 206 in Figure 2). The prefabricated service 510 may be provided by the CSP and may also be an example of the prefabricated service 210 described above with respect to Figure 2, and includes a management service 512 as an example of the management service 212 in Figure 2, and a network service 520 as an example of the network service 220 in Figure 2.

[0064] As described above with respect to Figure 2, the management service 512 can perform tasks to coordinate the operation of the prefab service 510, including scheduling prefab region construction work by other prefab services 510, generating physical construction requests and corresponding instructions, and configuring the prefab region 206 for transport to the target site. The physical construction request may specify the number and type of physical resources to be used in the prefab region 206. The network service 520 can use the configuration information from the construction request to determine the network topology of the devices (e.g., servers, networking devices, racks of servers and networking devices). The network service 520 can also determine the network configuration of the devices in the prefab region 530 after provisioning the infrastructure components in the prefab region 530.

[0065] In some examples, the network service 520 may store a snapshot of the network configuration of a prefabricated region (for example, prefabricated region 530). The snapshot may contain information about the network topology of the prefabricated region at a specific point in time, including network identifiers of devices in the prefabricated region (e.g., network address, hostname, etc.), current network connections between devices, physical networking interfaces between devices in the prefabricated factory 502 and the networking infrastructure 538, and network configurations of devices (e.g., port settings, gateway settings, etc.). For example, server device 536 may be a computing device in server rack 532A of prefabricated region 530. Server device 536 may have a networking connection 540 to switch 534 in server rack 532. The network configuration of prefabricated region 530 may include information relating server device 536 to switch 534, including the type of networking connection 540, the port on switch 534 to which server device 536 is connected, and information specifying the settings of both server device 536 and switch 534 corresponding to the networking connection 540 between them. The network configuration may also include information relating server device 536 to “adjacent” devices in prefabricated region 530 via networking connections 542 and 544. Networking connections 542 and 544 may be via switch 534, and server device 536 may be connected to other devices in server rack 532A via networking connections 542 and 544. In some examples, “adjacent” devices of a given device in prefabricated region 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 the prefabricated region 530 (for example, networking connection 546 to a switch in server rack 532B).

[0066] Network snapshots may be used to verify the physical deployment (e.g., physical networking connectivity) of the prefabricated region 530 after the devices have been deployed at the target site. For example, network service 520 may provide a network snapshot (or part of a snapshot) to each device in the prefabricated region 530 as part of the configuration of the prefabricated region 530 for transport to the target site. For example, network service 520 may provide a network snapshot 526 to server device 536 for storage in server device 536. Network snapshot 526 may be part of a network snapshot corresponding to the network configuration of the entire prefabricated region 530. Network snapshot 526 may include an identifier for server device 536 (e.g., network address, hostname, etc.) and information that associates server device 536 with one or more other devices in the prefabricated region 530. Information that associates server device 536 with neighboring devices may include an identifier for the neighboring device and information about the network connection between them. For example, server device 536 can use network snapshot 526 to identify neighboring devices and communicate with them over the network connection.

[0067] Furthermore, the network service 520 may maintain the network configuration of the network fabric of the prefabricated factory 502. For example, the prefabricated factory 502 may have a networking infrastructure that supports multiple separate prefabricated regions being built simultaneously. The prefabricated factory 502 may have multiple dedicated locations for locating server racks for the prefabricated regions being built. Each location may have a set of networking cables of the networking infrastructure that terminates at a location connectable to a server rack. Based on the devices located at that location, certain cables from the set of networking cables are connected to a device (e.g., a top-of-rack switch), so that these devices can be connected to other devices in the prefabricated region using part of the network fabric of the prefabricated factory 502. For example, server rack 532A may be located at a location within the prefabricated factory 502 and connected to the networking infrastructure 538 using switch 534. Server rack 532B, on the other hand, may be located at a second location and connected to the networking infrastructure 538.

[0068] In addition to maintaining the network configuration of the prefabricated region 530, configuring the prefabricated region 530 for transport to the destination site may include the management service 512 configuring each device to enter a test state upon subsequent power-on of the device, encrypting the device's data volume with an encryption key, storing the encryption key in a device that can function as a key server for the prefabricated region 530 during initialization at the destination site, and configuring one of the devices to function as a Dynamic Host Configuration Protocol (DHCP) server during initialization of the prefabricated region 530 at the destination site. The management service 512 may also generate instructions that can be used by personnel or robotic systems associated with the prefabricated factory 502 for packaging the devices for delivery. The management service 512 may also generate instructions that can be used by personnel associated with the destination facility for deploying and connecting the devices at the destination facility.

[0069] Furthermore, in some embodiments, configuring devices in the prefabricated region 530 may include taking a device snapshot of each device. The device snapshot may include a software image of memory such as one or more disk drives of the computing device, which can be used to replicate the device's software configuration onto a replacement device. The management service 512 may generate device snapshots in conjunction with one or more of the prefabricated services 510. The device snapshots may be stored in a database or datastore in conjunction with network snapshots (e.g., snapshot 524). In a particular example, the management service 512 may generate a device snapshot 552 of the server device 550 in the prefabricated region 530 at the prefabricated factory 502. The device snapshot 552 may be used for an image of another physical device having the same or similar physical configuration as the server device 550 in order to generate a replica of the server device in the event of a failure of the server device 550 (e.g., damage or loss during transport to the target site).

[0070] Figure 6 shows a CSP system 600 for testing and evaluating a prefabricated region 530 after delivery to a target site 602 using management services 612 and test services 616, according to at least one embodiment. The target site 602 may be a data center facility in a location corresponding to a new region deployed to the CSP by using the computing resources of the prefabricated region 630. The prefabricated services 610 may be provided by the CSP and may be similar to the prefabricated services 210 in Figure 2, and include management services 612 as an example of management services 212 in Figure 2, test services 616 as an example of test services 216, and organization services 618 as an example of organization services 218.

[0071] Sending the prefabricated region 530 to the destination site 602 may include powering off each device, disconnecting the devices from the networking infrastructure of the prefabricated plant, and packaging the devices as necessary for transport. Server racks (e.g., server racks 532A, 532B) may be sent as is without disconnecting the individual devices within the server racks. The server racks delivered to the destination site 602 may be placed at the destination site 602 in the resulting data center physical layout and connected to the destination site's networking infrastructure 638. For example, a networking connection may be established between the networking infrastructure 638 and the switches of the server racks 532A, 532B by connecting one or more networking cables to a switch (e.g., switch 534).

[0072] As described above, devices in prefabricated region 530 may be configured to boot in test mode upon initial power-on at target site 602. In some embodiments, these devices may have a dedicated boot volume to support test mode during initialization at target site 602. In other embodiments, the boot volume may be configured on an external device connected to each device in prefabricated region 530. For example, each server device (e.g., server device 536) may be connected to a smart network interface card (smart NIC) that provides a low-overhead boot volume available for booting the server device in test mode. Since the boot volume is only used to support test mode, encryption of data on the boot volume is not considered necessary, unlike that of data volumes on server devices.

[0073] The test mode may be configured to have each computing device verify its connectivity to other devices in the prefabricated region 530. This verification can determine whether the device's physical network connectivity to the networking infrastructure 638 at the target site 602 is correct. To verify the connectivity, the devices in test mode may be determined by a network service (e.g., network service 520 in Figure 5) and may use the network settings or a portion of the network settings stored on each device. For example, server device 536 may use a network snapshot 526 to determine neighboring computing devices that are communicating with server device 536 via networking connection 542. To verify networking connection 542, server device 536 may send a verification request to the neighboring computing device. If networking connection 542 is complete, server device 536 may receive a verification indicator from the neighboring computing device indicating that the verification request was successfully received by the neighboring computing device. Server device 536 may verify all connections specified in network snapshot 526. Similarly, in prefabricated region 530, devices on one server rack (e.g., server rack 532A) may be configured to verify connections to each of the other server racks (e.g., server rack 532B).

[0074] In some embodiments, a device in the prefabricated region 530 may be configured to function as a DHCP server (e.g., DHCP server 646). The DHCP server 646 may, during initialization, provide the devices in the prefabricated region 530 with identifiers such as network addresses. For example, in test mode, each device may, after verifying its connection to the DHCP server 646, receive an address, identifier, or other network configuration information from the DHCP server 646. The device may compare the received identifier to an identifier included in the network configuration generated by the network service during the prefabricated region construction process at the prefabricated factory. For example, after receiving an identifier from the DHCP server 646, the server device 536 can compare the received identifier to an identifier in the network snapshot 526. Since the components of the prefabricated region 530 should remain unchanged during transport, the network configuration of the prefabricated region 530 at the target site 602 (including the configuration information from the DHCP server 646) should also remain unchanged. That is, after the devices are deployed at the target site 602, the server devices in the prefabricated region should receive the same network address from the DHCP server 646. If the network settings change, the server device may indicate that the network settings for prefab region 530 are incorrect.

[0075] In some embodiments, if any device is damaged and becomes non-functional during transport, the operator at the destination site can successfully complete on-site post-deployment verification even if there is a hardware failure during transport by replacing the broken device with a new replacement device and configuring the new device with a device snapshot taken prior to transport. For example, server device 550 may be damaged during transport to destination site 602. The discovery of the non-functional state of server device 550 may occur during a test run verifying the network configuration of prefabricated region 530. For recovery, management service 612 can generate instructions to replace server device 550 with an identical physical device at the same location on server rack 532B. Once the replacement device is deployed, management service 612 can deploy a device snapshot 552 generated during the prefabricated region construction work at prefabricated factory 502. Deploying the device snapshot 552 may include imaging one or more disk drives or other memory of the replacement server device so that the replacement server device has the same software configuration as the server device 550 in prefabricated region 530 prior to transport to destination site 602. Other devices, including networking devices such as switch 534, may be similarly replaced and restored using captured device snapshots.

[0076] The DHCP server 646 can perform a test mode verification operation similar to that of other devices in the prefabricated region 530. If the DHCP server 646 is able to successfully verify the network connectivity with neighboring devices, it can exit test mode and begin operating as a DHCP server for other devices in the prefabricated region 530. In some embodiments, the DHCP server 646 may complete its test mode verification operation before other devices in the prefabricated region 530 have completed their respective test mode verification operations. For example, server device 536 may boot in test mode and attempt to verify its network connectivity to the DHCP server 646 prior to verifying the networking connectivity 542 or networking connectivity 544 with neighboring computing devices. The DHCP server 646 does not need to send verification indicators to server device 536 until it has completed its own test mode verification operation. Server device 536 can then wait for a predetermined time and retry the verification request to the DHCP server 646. Similarly, other computing devices performing a test mode verification operation may wait until the DHCP server 646 is operational before retrying their verification request.

[0077] As described above, the data volumes of devices in prefabricated region 530 may be encrypted prior to their transport to the target site 602. The encryption key used to encrypt the data volume of each device may be associated with that particular device. The encryption key 644 may be stored in one of the computing devices in prefabricated region 530 that is configured to function as the key server for prefabricated region 530 during initialization (for example, it may be stored in key server 642). The encryption key 644 itself may also be encrypted by a parent key. In some embodiments, the encryption key 644 may be protected by a hardware security module (for example, a trusted platform module (TPM)). The hardware security module may be part of key server 642 or part of another device connected to key server 642 (for example, a smart NIC, an external security device, etc.). In some embodiments, the parent key or external security device may be delivered to the target site 602 separately from prefabricated region 530 (for example, by a worker) and provided to or deployed to key server 642 as part of the deployment work for prefabricated region 530. The key server 642 may perform a test mode verification operation similar to that of other computing devices in the prefab region 530. If the test mode verification operation is successful, the key server 642 may provide the cryptographic key 644 to other computing devices in the prefab region to begin decrypting the data volume. For example, the key server 642 may receive a key request from server device 536. In response, the key server 642 can decrypt the data volume containing the cryptographic key 644 (for example, by a parent key, hardware security module), read the cryptographic key corresponding to server device 536, and send the cryptographic key to server device 536.

[0078] Once the prefabricated region 530 is deployed and initialized at the target site 602 (for example, when the device boots in normal operating mode, the data volumes are decrypted, and the services deployed during the prefabricated region construction work at the prefabricated factory are running), the test service 616 may perform one or more approval tests. The approval tests may include verifying that all services are functioning as expected. For example, the test service 616 may interact with the services running in the prefabricated region 530 to verify that the services are operating according to the requirements defining the approval tests. The test service 616 may provide the management service 612 with the results of the approval tests indicating that the construction of the prefabricated region is complete.

[0079] During the transport of prefabricated region 530 to the destination site 602, changes such as updates may be specified for one or more infrastructure components and / or software resources that were provisioned and / or deployed to prefabricated region 530 at the prefabricated factory. For example, services may be updated to a newer version during transport. Before the prefabricated region construction work is completed, the organization service 618 can deploy the updated software resources to prefabricated region 530 at the destination site 602. The deployment of updated software resources can occur in the same way as the deployment of software resources to prefabricated region 530 at the prefabricated factory.

[0080] Figure 7 shows an exemplary method, according to at least one embodiment, for deploying software resources to physical resources in a region constructed in a prefabricated factory, to prepare the physical resources for delivery to a target data center. Method 700 may be performed by one or more components of a computer system (including one or more components of a computer system of a CSP (e.g., CSP204 in Figure 2) that runs a management service (e.g., management service 212 in Figure 2)). The operations of Method 700 may be performed in any preferred order, and the operations included in Method 700 may be more or less than those shown in Figure 7.

[0081] Method 700 (or any other process and / or method described herein, or any variation thereof, and / or combination thereof) may be executed under the control of one or more computer systems comprising executable instructions, or may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is collectively executed on one or more processors by hardware or a combination thereof. The code may be stored in a computer-readable storage medium in the form of a computer program containing, for example, multiple instructions executable by one or more processors. The computer-readable storage medium may be non-temporary.

[0082] Method 700 may begin in block 702, causing a management service to receive a build request. The management service may be an example of any management service described herein (including management service 212 in Figure 2). The management service may be configured to run on one or more computing devices of the CSP computer system. The management service may be one of several services of the CSP configured to perform the operation of building a prefabricated region (e.g., prefabricated region 206 in Figure 2) in a prefabricated factory (e.g., prefabricated factory 202 in Figure 2). A build request may be a specification or configuration containing information characterizing the prefabricated region. For example, a build request may include information specifying the size of the prefabricated region (e.g., the number of computing devices, server racks, etc.), the number and types of services, applications, and other software to run on the computing devices in the prefabricated region, requirements regarding the computing power in the prefabricated region (e.g., the number of processors in each computing device, the processing speed of the processors, etc.), requirements regarding the type of storage to be provided in the prefabricated region, and other similar definitions. In some embodiments, the build request may be provided by the worker or the system designer who designs the prefabricated region.

[0083] In block 704, the management service may generate a physical build request for constructing physical resources within a first data center. The first data center may be a prefabricated factory (for example, prefabricated factory 202 in Figure 2). The management service can use the information in the build request to generate a physical build request. The physical resources may include server devices, networking devices, and other computing devices that can be used to construct a prefabricated region in the first data center. The physical build request may include information that identifies a specific physical resource to be constructed in the first data center. For example, the management service can interact with an inventory service (for example, inventory service 214 in Figure 2) to obtain an inventory of server devices and server racks available in the physical inventory of devices (for example, physical inventory 224 in Figure 2). The management service can then determine a specific server rack to be used to construct the prefabricated region corresponding to the build request and include that information in the physical build request. The physical build request may also include instructions that can be used, for example, when a worker retrieves, moves, and deploys the physical resources in the first data center. For example, these instructions may identify a specific location within the first data center where the server racks will be placed, and instructions for completing specific network connections to the server racks to configure the network of the prefabricated region.

[0084] In block 706, the management service may implement ViBE (for example, ViBE222 in Figure 2) in a second data center. The second data center may be communicated to the first data center. For example, the management service may implement ViBE in a host region of a CSP connected to a prefabricated factory via a network (for example, network 208 in Figure 2). The management service may implement ViBE in conjunction with an organization service (for example, organization service 218 in Figure 2). For example, the management service may build ViBE by providing the organization service with an indicator specifying the second data center in which ViBE will be configured. The management service may implement ViBE in response to an indicator that the physical resources corresponding to a physical build request have been built (for example, deployment, power-on, and normal operation in the first data center). This indicator may be provided by an operator after the deployment of the physical resources. In some embodiments, this indicator may be provided by one or more of the physical resources after the completion of verification such as a self-check of the deployment.

[0085] In block 708, the management service can use ViBE to deploy software resources to physical resources. The software resources may be associated with cloud services running on the physical resources. For example, the software resources may be components of a generation service (e.g., a database service) that runs in a prefabricated region after it has been delivered to the target site. The management service, in conjunction with the organization service, can deploy the software resources.

[0086] In block 710, the management service can generate an inventory of physical resources. The management service may generate the inventory in conjunction with an inventory service. In block 712, the management 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 management service may generate the network configuration in conjunction with a network service (for example, network service 220 in Figure 2). The network configuration may be a network snapshot of a prefabricated region. The network configuration may include identifiers of the physical resources in the inventory (for example, the network addresses of server devices) and information relating the physical resources to neighboring physical resources according to the network topology. For example, the network configuration may identify each computing device and the network connections between that computing device and one or more neighboring computing devices. The operations in blocks 710 and 712 may be operations for configuring physical resources for delivery to a target site. The target site may be a third data center. In some embodiments, the management service may send a portion of the network configuration to the physical resources. This portion of the network configuration may include identifiers corresponding to the physical resources and information relating the physical resources to neighboring physical resources in the network topology. In some embodiments, configuring physical resources for delivery to a target site may include encrypting at least a portion of the software resources deployed on each physical resource using an encryption key associated with each physical resource, and storing each encryption key in one of the physical resources designated to host the key service in a second data center (for example, the key server 642 in Figure 6).

[0087] In some embodiments, the management service may receive an indicator that the physical resource has been delivered to the target site and constructed (e.g., deployed). Based on this indicator, the management service may verify the topology of the physical resource at the target site. For example, the management service, in conjunction with a network service, may obtain the network configuration of the physical resource at the target site and compare it with information contained in a stored network snapshot taken before the physical resource was sent to the target site. Once the network topology of the physical resource at the target site has been verified, the management service may deploy one or more update software resources to the physical resource. For example, the management service, working with an organization service, may deploy update software components to services that were deployed in a prefabricated region at a prefabricated factory and then migrated to a newer version upon delivery of the physical resource to the target site.

[0088] In some embodiments, the management service can perform actions to support the initialization of physical resources at the target site. The management service can 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 the second physical resource. Due to the dependencies, the first cloud service may not function correctly until the second cloud service is operational. Because the physical resources can independently perform test mode verification during initialization, some parts of the deployed region may become available before others. In this case, the management service can determine whether the verification of the portion of the network topology associated with the second physical resource was successful, and then send an indicator that the first cloud service is available. This indicator may be sent to a system, such as an operations console, configured to report the availability of services and applications in a prefabricated region at the target site when they become available. For example, the use of this metric may be used to initiate one or more user approval tests for a newly available first cloud service.

[0089] In some embodiments, during the construction of a prefabricated region in a prefabricated factory, changes may be made to the configuration of the prefabricated region. For example, after being delivered to the target site, the prefabricated region may need to have additional computing resources to support the addition or expansion of applications and / or services. The techniques described herein can address modifications to a prefabricated region under construction in a prefabricated factory. The management service can generate an update physical build request that can be used to modify physical resources. For example, an update physical build request may specify the deployment of additional server racks to the prefabricated region in the prefabricated factory. As another example, one or more server devices may be replaced with different types of server devices (e.g., devices with high-speed processors, additional processors, additional memory, etc.). Similar to a physical build request, an update physical build request may include instructions that can be used, for example, by workers in the prefabricated factory to acquire, deploy, and / or modify physical resources. After the modifications are made, the management service can deploy the updated software resources to the modified physical resources. For example, the management service can use the organization service and ViBE to deploy the software components of the new service to the new server racks in the prefabricated region. The management service may deploy updated software resources upon receiving an indicator that the physical resource repair was successful.

[0090] In some embodiments, configuring physical resources for transport to a second data center may include generating device snapshots of one or more of the physical resources. For example, a management service may generate a software image of each server device in a prefabricated region and store this software image in a datastore or similar repository. When verifying the prefabricated region after deployment at the target site, the management 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 target site. In response, the management service may generate instructions that can be used to replace the non-functional physical resource with a functional replacement (e.g., replacing a non-functional server device with a functional replacement server device with the same physical configuration). Once a functional replacement device is deployed, the management service may configure the replacement device using a device snapshot of the failed device. For example, the management service may deploy an image of the replacement device to generate a device that is configured and functions the same as the replaced device.

[0091] Figure 8 shows an exemplary method 800 for booting up physical resources constructed in a prefabricated factory after delivery to a target data center and verifying the network configuration of the physical resources, according to at least one embodiment. Method 800 may be performed by one or more components of a computer system (including one or more components of a computer system in a prefabricated region (e.g., prefabricated region 206 in Figure 2) that is connected to a CSP hosting a management service (e.g., management service 212 in Figure 2)). For example, Method 800 may be performed by a computing device in a prefabricated region (including server device 536 in Figure 5, DHCP server 646 or key server 642 in Figure 6). The operations of Method 800 may be performed in any preferred order, and the operations included in Method 800 may be more or less than those shown in Figure 8.

[0092] Method 800 begins in block 802, in which the computing device receives network configuration (e.g., network snapshot 526 in Figure 5) from a management service. The network configuration may include information specifying the network topology of physical resources in the first data center (e.g., prefabricated factory 202 in Figure 2). The network configuration may include a first identifier associated with the computing device (e.g., network address, hostname, etc.), a second identifier associated with the neighboring computing device (e.g., network address, hostname, etc.), and information relating the computing device to the neighboring computing device (e.g., information specifying the networking connection 544 in Figure 5). The computing device can be configured to communicate with the neighboring computing device over the network connection by using the network configuration.

[0093] In block 804, the computing device may be configured for delivery to a second data center (for example, the target site 602 in Figure 6). Configuring the computing device for delivery may involve operations similar to those described above with respect to blocks 710 and 712 in Figure 7. Configuring the computing device for delivery to a second data center may also involve configuring the computing device to boot in test mode during the subsequent power-on sequence. In block 806, the computing device may be configured to boot in test mode at the second data center. For example, once the computing device and other physical resources of the prefabricated region are delivered to and deployed at the second data center, the computing device may be powered on and enter test mode. In some embodiments, booting the computing device in test mode may involve booting from a boot volume stored on a smart NIC connected to the computing device.

[0094] In block 808, the computing device may receive a new identifier. This new identifier may be received from a server device in the second data center. For example, the server device could be a device configured to function as a DHCP server in the second data center. The identifier may also be the network address of the computing device. As mentioned above, this identifier may be the same as the first identifier associated with the computing device in the prefabricated region of the prefabricated factory, because no changes should have occurred in the network configuration during the transport and deployment of the physical resources to the second data center.

[0095] In block 810, the computing device can verify a new identifier by comparing it with a first identifier. Prior to delivery, the computing device can obtain the first identifier from the network configuration stored in the computing device.

[0096] In block 812, a computing device can send a verification request to an adjacent computing device. The verification request is sent according to a second identifier associated with the adjacent computing device. For example, a computing device can verify the network connectivity of an adjacent computing device at the network address associated with the adjacent computing device. Accordingly, in block 814, a computing device can verify its network connectivity to an adjacent computing device. Network connectivity may be characterized by network configuration. In some embodiments, verification of network connectivity may include receiving a response to a verification request, which may be a verification indicator from the adjacent computing device. In some embodiments, the response to a verification request may be an indicator (e.g., a request timeout indicator) that the verification request was not received by the adjacent computing device. The verification indicator may indicate that the physical networking between the computing device and the adjacent computing device was properly deployed in the second data center. In some embodiments, once the computing device has successfully verified its connectivity to each adjacent computing device, it may send an indicator to a management service at the target site indicating that the verification of the network connectivity associated with the computing device was successful.

[0097] In some embodiments, the computing device may be configured to act as a key server for a prefabricated region in a second data center. Configuring the computing device for delivery to the second data center may include encrypting the data volume of the neighboring computing device using an encryption key associated with the neighboring computing device. The encryption key may be stored in the data volume of the computing device, which may be encrypted with a different encryption key (e.g., a parent key). The parent key may be stored in a secure storage volume (e.g., a hardware security module, a trusted platform module (TPM), a smart NIC) that is connected to the computing device and can be used to decrypt storage volumes on the computing device, thereby reading the encryption key and providing it to neighboring computing devices and other computing devices in the prefabricated region that have come online in the second data center. In some embodiments, once the computing device has verified network connectivity to the neighboring computing device, it may retrieve the parent key from the secure storage volume, decrypt the data volume storing the encryption key, and provide the encryption key in response to key requests from the neighboring computing device and other computing devices.

[0098] In some embodiments, a computing system may determine that one or more computing devices in a second data center have failed or are not functioning correctly. For example, a server device in a server rack may have been damaged during transport. To complete the deployment of a prefabricated region in the second data center, the failed or non-functioning computing device may be replaced with another device, and the failed device may be configured with a software image prior to its transport to the second data center. As an example, a computing system may configure an adjacent computing device for delivery to the second data center by generating a device snapshot of the adjacent computing device. The device snapshot may include a software image of the adjacent computing device. The device snapshot may be generated by a management service and / or other prefab services that perform prefabricated region construction work in the prefab factory.

[0099] Once a computing device is deployed to the second data center, the computing system can determine if an 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 not functioning correctly. In response to this determination, the management service can generate instructions to replace the adjacent computing device with a replacement computing device. These instructions may be available for personnel in the second data center to perform the replacement (e.g., a likeness replacement of a device on a server rack). The management service can then deploy a device snapshot of the adjacent computing device to a functional adjacent computing device, and the resulting device may be identical to the failed device. The computing device can then resend a verification request to determine if the network connection between the computing device and the adjacent computing device is functioning correctly.

[0100] Cable termination protection device As described in the brief above and in the related U.S. Patent Application No. [number], “STATIC NETWORK FABRIC AT A PREFAB FACTORY,” a static network fabric in a prefabricated factory may enable the deployment of prefabricated regions without modification of the network infrastructure. Server racks containing computing devices in the prefabricated region may be located in positions within the prefabricated factory that have cable terminations (e.g., overhead cable drops) for the network cables of the static network fabric. Network cables and corresponding cable termination connectors at each position may include multiple different types of cables / connectors, as well as multiple cables / connectors of the same type (e.g., for redundancy). Network cables can connect to different ports on networking devices or computing devices in the server racks that correspond to the cable termination connectors, thereby connecting the server racks and forming a regional network.

[0101] Depending on the type of network connectivity used by the server rack, not all network cables available at a given location may be used for connecting to the server rack. To protect the cable termination connectors, a Cable Termination Protection (CTPA) may be installed at the aforementioned location in the prefabricated factory. Network cables terminating at the aforementioned location may be connected to a port on the CTPA if they are not connected to computing devices in the prefabricated region. The CTPA port may be a socket that matches the cable termination connector of the network cable. Cables connected to the CTPA are kept in a configuration that avoids cable tangling and reduces connection errors by protecting the termination connectors from dust and debris and damage, not interfering with server rack installation / removal operations, and aligning the connectors for the most efficient connection to the server rack.

[0102] Figures 9A and 9B show exemplary configurations 900 and 920 of the CTPA 902 that may be placed in a prefabricated factory (e.g., prefabricated factory 202 in Figure 2) according to several embodiments. Configurations 900 and 920 show that the CTPA 902 can be placed adjacent to a location in the prefabricated factory where network cable routing (e.g., network cable 908 in Figure 9) is introduced into an overhead cable tray 910. At this location, it is possible to configure a pair of network cables 908 to terminate, so that one or more cables have cable termination connectors (e.g., connectors such as plugs) at the ends of the network cables. In the case of configurations 900 and 920, the network cables are introduced above the location of the server racks in the prefabricated factory, but the CTPA 902 may be placed for network cables that terminate at the above location by passing under the floor (e.g., cable trays under the raised floor) in a prefabricated factory with a raised floor configuration.

[0103] The CTPA902 may comprise a frame 903 that can be positioned at a location in a prefabricated factory. For the purposes of this specification, the frame 903 may be “positionable” if, as described below, the frame 903 is adjacent to that location (e.g., above, horizontally adjacent, etc.) and a set of network cables (e.g., a set of network cables 908) terminating at that location can be connected to the CTPA902. In some embodiments, the frame 903 may have dimensions corresponding to standard rack frames used in data center environments. For example, the frame 903 may have a height of 1U (i.e., 1.75 inches) and a width of 19 inches, according to the width of a standard 19-inch rack frame. Other standard dimensions may include 2U, 3U, or other heights. Other standard widths for rack frames may include a width of 23 inches. In some embodiments, the frame 903 may comprise a body that occupies a volume similar to that of a computing device mounted in a standard-dimension server rack. For example, frame 903 may be 1U high, 19 inches wide, and 24 inches deep. In some embodiments, frame 903 may be a surface plate having standard dimensions without a housing body extending to a certain depth from the mounting location. For example, frame 903 may be a metal plate 1U high and 19 inches wide with its sides attached to rail 906. Rail 906 may be a standard rack rail mounted in a location on the ceiling of a prefabricated factory supporting CTPA 902 above the location where server rack 912 will be installed.

[0104] Frame 903 may have a surface on which multiple ports 904 are located. This surface may be the front surface of frame 903 when frame 903 is positioned as described above. For example, this surface may be the surface of frame 903 that is accessible from the same side as the network connectivity of server rack 912 when server rack 912 is installed as described above. The multiple ports 904 may be networking ports characterized by one or more physical standards. For example, physical standards can define ports and include, but are not limited to, multi-fiber push-on (MPO), multi-fiber pull-off, SFP (Small Form-factor Pluggable), SFP+, SFP28, QSFP (Quad Small Form-factor Pluggable), QSFP+, QSFP28, or RJ45. The multiple ports 904 may be defined by physical standards but do not have to be valid network ports and do not have to be equipped with associated electronics that support network connectivity. In other words, the CTPA902 has several "blank" network ports that allow for a physical connection to a set of network cables 908 in a prefabricated factory, but do not provide communication connectivity.

[0105] A set of network cables 908 may also be equipped with cable termination connectors that conform to physical standards. For example, a set of network cables 908 may include a cable terminated with a QSFP28 connector. The QSFP28 connector of this cable may be connected to a QSFP28 port on frame 903 of CTPA902. Since a set of network cables 908 may include any suitable number and type of network cables and corresponding cable termination connectors, the multiple ports on frame 903 may also include any suitable number of physical standard combinations. For example, the multiple ports may have four MPO ports, four QSFP28 ports, two QSFP+ ports, and two RJ45 ports.

[0106] In some embodiments, the multiple ports 904 may include more ports than the cables in a pair of network cables 908. As shown in Figure 9A, the CTPA 902 has eight ports, while the pair of network cables 908 includes five network cables. The pair of network cables 908 can protect the cable termination connectors of each cable by connecting to corresponding ports among the multiple ports 904, thereby accommodating them at corresponding ports as if they were connected to a valid computing device.

[0107] Multiple ports 904 may be positioned on the surface of the CTPA 902 to match the arrangement of networking ports on a computing device (e.g., networking device 914 on server rack 912 or networking device 924 on server rack 922). Matching the arrangement of several ports on a networking device may involve substantial alignment between the multiple ports 904 and the multiple ports on the computing device. For example, networking device 914 may have networking ports (e.g., two QSFP28 ports) for connecting to a static network fabric in a prefabricated factory positioned on one side of its surface. The most efficient way to run two QSFP28 cables from the CTPA 902 to the ports on networking device 914 is to run the two QSFP28 cables straight down from the matching ports among the multiple ports 904. Also, by matching the arrangement of several ports on a networking device, the number of homogeneous connections can be increased, thereby reducing the possibility of cable miswiring when deploying server racks in a prefabricated factory.

[0108] Figure 9A shows configuration 900 in which the CTPA 902 is positioned above a server rack 912, which is considered a typical configuration for a prefabricated factory where network cables are contained in an overhead cable tray 910 above the location of the computing devices in the prefabricated region of the factory. In configuration 900, the CTPA 902 may have vertical alignment 916 between one or more of the multiple ports 904 and the ports on the networking device 914. Similarly, Figure 9B shows configuration 920 in which the CTPA 902 is positioned adjacent to the location where a server rack 922 is installed. In configuration 920, the CTPA 902 may have horizontal alignment 926 between one or more of the multiple ports 904 and the ports on the networking device 924. Possible examples of both the vertical alignment 916 and the horizontal alignment 926 are substantial alignments between the multiple ports 904 and the multiple ports on the computing devices located at a certain location in the prefabricated factory, according to one embodiment.

[0109] In some embodiments, the CTPA902 may have a port cover 917 for at least one of the multiple ports 904. Since the cables included in a set of network cables 908 may be fewer than the ports of the CTPA902, some of the multiple ports 904 may not be connected to network cables. To prevent dust and debris from entering the open ports, the port cover 917 may be connected to the open ports to substantially cover the openings of the open ports. For example, the port cover 917 may include a molded rubber stopper that fits into the open port. In another example, the port cover 917 may include a plastic cap that fits over the port opening. In some embodiments, the CTPA902 may have multiple port covers. The port covers 917 may be connected to the frame 903 by flexible cables 918.

[0110] Figure 10 shows exemplary steps for disconnecting a networking cable from CTPA 1002 and reconnecting the networking cable to networking device 1014 according to instructions generated based on the physical configuration parameters of the network fabric (e.g., network fabric 900 in Figure 9) and networking device 1014 of a prefabricated factory (e.g., prefabricated factory 902 in Figure 9) according to at least one embodiment. Networking device 1014 may be a computing device in a server rack 1012. The physical configuration parameters may include information specifying the number and type of networking ports on networking device 1014, identifiers such as the port name of each networking port, networking connections between networking device 1014 and other computing devices on the server rack 1012, and / or the location of the networking ports on networking device 1014 relative to the physical dimensions of networking device 1014.

[0111] As described above with respect to Figures 2 and 5, the use of management services (e.g., management service 212 in Figure 2) and / or network services (e.g., network service 220 in Figure 2) can generate instructions that can be used for deploying computing devices in a prefabricated factory as part of the prefabricated region construction work. These instructions may be used by personnel 1006 to move the server rack 1012 to a location in the prefabricated factory and connect one or more network cables from a set of network cables 1008 to the networking device 1014. In some embodiments, these instructions may be sent to a user device and presented to personnel 1006 on the user device's display. These instructions enable the identification of the network cables to be connected to the networking device 1014 and the order in which the identified cables are disconnected from the CTPA 1002 and connected to the ports on the networking device 1014. By determining the order in which network cables are disconnected and reconnected, these instructions reduce the possibility of misconnections, and by utilizing the effective alignment of ports on CTPA 1002 with ports on networking device 1014, the time required to connect server rack 1012 to the prefabricated regional network can be shortened.

[0112] In step 1, the person in charge 1006 can disconnect the first network cable from the first port of the multiple ports 1004. The first network cable can be identified by the above instructions. The first port may be vertically aligned with the corresponding network port of the networking device 1014. The person in charge 1006 may then reconnect the first network cable to the corresponding network port. Due to the vertical alignment, the person in charge 1006 may only need to move the first network cable directly down to the corresponding port.

[0113] Similarly, in step 2, the person in charge 1006 may disconnect the second network cable from the second port of the multiple ports 1004. The second network cable may be identified by the above instructions. Similar to the first port, the second port may be aligned perpendicularly with the corresponding network port of the networking device 1014. The person in charge 1006 may then reconnect the second network cable to the corresponding network port.

[0114] In step 3, the person in charge 1006 can disconnect the third network cable from the third port of the multiple ports 1004. As shown in Figure 10, the third network cable does not need to be vertically aligned with the corresponding network port. Due to the lack of vertical alignment and / or positioning of the corresponding network port on the networking device 1014, the instructions may be made to avoid misconnection by having the third network cable disconnected and reconnected to the networking device after the first and second network cables have been connected.

[0115] While the steps described above refer to the manual operation performed by the person in charge 1006 to connect the network cable to the networking device 1014, in some embodiments, the above instructions may be used by an automated system (e.g., a robot) to perform the task of disconnecting / reconnecting the network cable from the CTPA 1002.

[0116] Figure 11 shows an exemplary method 1100 for generating instructions that can be used to disconnect a networking cable from a CTPA (e.g., CTPA 1002 in Figure 10) in a prefabricated factory and to reconnect the networking cable to a networking device (e.g., networking device 1014 in Figure 10), according to at least one embodiment. Method 1100 may be performed by a computing device of the CSP (including a computing device configured to run one or more prefabricated services (e.g., management service 212 and / or network service 220 in Figure 2)).

[0117] Method 1100 may begin in block 1102, causing a computing device to receive a build request for a prefabricated regional data center rack. The build request may be similar to the build requests described above with respect to Figures 2, 7, and 8. The data center rack may be any example of a server rack described herein, including a computing device (e.g., a server device, a networking device, etc.), and includes server rack 1012 in Figure 10.

[0118] In block 1104, a computing device can obtain physical configuration parameters for computing devices on a data center rack. These physical configuration parameters may include information identifying the connection between each computing device and a specific port on the networking device to which it is connected. They may also include information specifying at least one networking port on the networking device configured to connect to the static network fabric of the prefabricated factory. The physical configuration parameters may be stored in a datastore accessible to the computing device.

[0119] In block 1106, the computing device can obtain cabling specification information corresponding to a location in the data center and a set of network cables (for example, a set of network cables 1008 in Figure 10) configured to terminate at the CTPA at that location. The cabling specification information may be an example of the information for the static network fabric of the prefabricated factory described above with respect to Figure 10. For example, the cabling specification information may identify the number of network cables that terminate at the location of the prefabricated factory with the CTPA and include a physical standard that characterizes the cable termination connector for each network cable. Similar to the physical configuration parameters, the cabling specification information may also be stored in a data store accessible to the computing device.

[0120] In block 1108, the computing device can use physical configuration parameters and cabling specification information to generate instructions that can be used (for example, by person 1006 in Figure 3) to disconnect networking cables from the CTPA and reconnect networking cables at the network ports of the networking device. For example, these instructions may include the steps of identifying network cables connected to the data center rack from among the network cables connected to the CTPA, and identifying the order in which the identified cables should be disconnected / reconnected. In some embodiments, generating the above instructions may include determining the correspondence between the identified network cables connected to the CTPA and the networking ports of the networking device on the data center rack, and determining the order in which the identified network cables should be disconnected / reconnected using physical configuration parameters (for example, the physical location of the corresponding network ports), which improve the speed of the disconnection / reconnection work and minimize network cable entanglement by utilizing alignment with the CTPA.

[0121] In some embodiments, the computing device can send the instructions to a user device, causing the user device to present the instructions to the user (e.g., person 1006). For example, the user device could be a tablet device capable of displaying the instructions as part of a connectivity plan that can visually identify the cables and provide steps for connecting the data center rack to the network cables. In some embodiments, the computing device can perform a connectivity test to confirm that the network cables have been successfully connected to the networking devices. For example, the computing device may notify or send network traffic, such as requests, to the networking devices and / or other computing devices on the data center rack. If the networking devices successfully receive the requests, the computing device may receive a response indicating that the network connection of the data center rack to the computing device has been established. The computing device may display an indicator on the user device corresponding to the results of the connectivity test. If the connection test fails, the computing device may disconnect one or more network cables from the networking device, reconnect them to the CTPA, and then generate additional instructions (for example, instructions to avoid misconnecting network cables and ensure correct connections) that identify any additional network cables to be disconnected from the CTPA and reconnected to the networking device. In some embodiments, the network device or compute device may determine that a network link has been established between adjacent devices by observing Link Layer Discovery Protocol (LLDP) packets being passed between them. By sequentially listing information on all valid links observed by various devices in the network and comparing this list to a list of all expected valid links, the management service may instruct personnel 1006 to check the cabling associated with any observed invalid links.

[0122] Exemplary service-based infrastructure architecture 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, a cloud computing provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, the IaaS provider may also supply a variety of services associated with these infrastructure components (exemplary services include billing software, monitoring software, logging software, load balancing software, and clustering software, etc.). Therefore, since these services can be policy-driven, IaaS users can maintain application availability and performance by implementing policies that promote load balancing.

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

[0124] In most cases, cloud computing models may require the participation of a cloud provider. This cloud provider may, but does not have to be, a third-party service specializing in providing IaaS (e.g., granting, leasing, or selling). Alternatively, an entity could deploy a private cloud and become its own infrastructure service provider.

[0125] In some cases, IaaS deployment is the process of placing a new application or a new version of an application on a prepared application server, etc. It may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider under the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Therefore, the customer may be responsible for handling (OS), middleware, and / or application deployment (e.g., on self-service virtual machines that can be spun up on demand).

[0126] In some cases, IaaS provisioning represents acquiring the computers or virtual hosts to be used, and may even represent installing the necessary libraries or services for them. In most cases, a deployment does not include provisioning, and provisioning may need to be performed first.

[0127] In some cases, IaaS provisioning presents two distinct challenges. Firstly, there is the initial challenge of provisioning the initial set of infrastructure before anything is operational. Secondly, there is the challenge of evolving the existing infrastructure after all provisioning is complete (e.g., adding new services, modifying services, removing services, etc.). In some cases, these two challenges can be addressed by enabling the declarative definition of infrastructure configuration. In other words, the infrastructure (e.g., the required components and the way those components interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., resource dependencies and how each resource works together) can be described declaratively. In some cases, once the topology is defined, a workflow can be generated to form and / or manage the various components described in the configuration files.

[0128] In some examples, infrastructure can consist of many interconnected elements. For instance, there may be one or more virtual private clouds (VPCs), also known as core networks (e.g., potential on-demand pools of configurable and / or shared computing resources). In some examples, there may also be one or more inbound / outbound traffic group rules provisioning that define how inbound and / or outbound network traffic is configured and one or more virtual machines (VMs). Other infrastructure elements such as load balancers and databases may also be provisioned. As there is a demand for and / or addition of more infrastructure elements, the infrastructure can gradually evolve.

[0129] In some cases, the adoption of sequential deployment techniques can enable the deployment of infrastructure code across various virtual computing environments. Furthermore, the techniques described can enable infrastructure management within these environments. In some examples, a service team may write code that is desirable to be deployed to one or more (but often many) different generation environments (e.g., geographically diverse locations, sometimes even worldwide). However, in some examples, the infrastructure to which the code is deployed may need to be configured first. In some cases, manual provisioning, the use of provisioning tools for provisioning resources, and / or the use of deployment tools for deploying code after infrastructure provisioning are also possible.

[0130] Figure 12 is a block diagram 1200 showing an exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 1202 may be communicated with a secure host tenancy 1204 which may include a virtual cloud network (VCN) 1206 and a secure host subnet 1208. In some examples, the service operator 1202 may use one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, mobile phones, iPad®, computing tablets, personal digital assistive devices (PDAs)) or wearable devices (e.g., Google Glass® head-mounted displays) that run software such as Microsoft Windows Mobile® and / or a variety of mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, and are capable of using the Internet, email, short message service (SMS), BlackBerry®, or other communication protocols. Alternatively, a general-purpose personal computer (PC) can serve as a client computing device, including, for example, PCs and / or laptop computers running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. A workstation computer running any of the various commercially available UNIX® or UNIX-like operating systems can also serve as a client computing device, including, but is not limited to, various GNU / Linux® operating systems such as Google Chrome® OS.Alternatively or additionally, the client computing device may be any other electronic device, such as a thin client computer that can communicate via a network that can access the VCN1206 and / or the Internet, an Internet-enabled gaming system (e.g., a Microsoft Xbox game console with or without a Kinect® gesture input device), and / or a personal messaging device.

[0131] VCN1206 may comprise an LPG1210 that can communicate with SSH VCN1212 via a local peering gateway (LPG) 1210 included in Secure Shell (SSH) VCN1212. SSH VCN1212 may comprise an SSH subnet 1214, and SSH VCN1212 may communicate with control plane VCN1216 via an LPG1210 included in control plane VCN1216. Furthermore, SSH VCN1212 may communicate with data plane VCN1218 via LPG1210. Control plane VCN1216 and data plane VCN1218 may be included in a service tenancy 1219 owned and / or operated by an IaaS provider.

[0132] The control plane VCN 1216 may comprise a control plane buffer zone (DMZ) layer 1220 that functions as a perimeter network (for example, part of the corporate network between the corporate intranet and the external network). DMZ-based servers can be limited in responsibility and help to mitigate breaches. The DMZ layer 1220 may also comprise a control plane application layer 1224 that may include one or more load balancer (LB) subnets 1222, an application subnet 1226, and a control plane data layer 1228 that may include database (DB) subnets 1230 (for example, a front-end DB subnet and / or a back-end DB subnet). The LB subnet 1222 included in the control plane DMZ layer 1220 is connected to the application subnet 1226 included in the control plane application layer 1224 and the Internet gateway 1234 which may be included in the control plane VCN 1216. The application subnet 1226 may be connected to the DB subnet 1230, the service gateway 1236, and the network address translation (NAT) gateway 1238 included in the control plane data layer 1228. The control plane VCN 1216 may include the service gateway 1236 and the NAT gateway 1238.

[0133] The control plane VCN 1216 may comprise a data plane mirror application layer 1240 that may include an application subnet 1226. The application subnet 1226 included in the data plane mirror application layer 1240 may comprise a virtual network interface controller (VNIC) 1242 that can run a compute instance 1244. The compute instance 1244 may communicate with the application subnet 1226 of the data plane mirror application layer 1240 to an application subnet 1226 that may be included in the data plane application layer 1246.

[0134] The data plane VCN1218 may comprise a data plane application layer 1246, a data plane DMZ layer 1248, and a data plane data layer 1250. The data plane DMZ layer 1248 may comprise an LB subnet 1222 that can be connected to the application subnet 1226 of the data plane application layer 1246 and the internet gateway 1234 of the data plane VCN1218. The application subnet 1226 may be connected to the service gateway 1236 and the NAT gateway 1238 of the data plane VCN1218. The data plane data layer 1250 may comprise a DB subnet 1230 that can be connected to the application subnet 1226 of the data plane application layer 1246.

[0135] The Internet gateway 1234 of the control plane VCN1216 and data plane VCN1218 can be connected to a metadata management service 1252, which can be connected to the public internet 1254. The public internet 1254 can be connected to the NAT gateway 1238 of the control plane VCN1216 and data plane VCN1218. The service gateway 1236 of the control plane VCN1216 and data plane VCN1218 can be connected to a cloud service 1256.

[0136] In some examples, a service gateway 1236 of the control plane VCN1216 or data plane VCN1218 can make application programming interface (API) calls to a cloud service 1256 without going through 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 the requested data to the service gateway 1236. However, the cloud service 1256 does not have to initiate an API call to the service gateway 1236.

[0137] In some examples, the secure host tenancy 1204 may be directly connected to the service tenancy 1219, or otherwise isolated. The secure host subnet 1208 may communicate with the SSH subnet 1214 via the LPG 1210, which may enable two-way communication through a system that is otherwise isolated. By connecting the secure host subnet 1208 to the SSH subnet 1214, the secure host subnet 1208 becomes able to access other entities within the service tenancy 1219.

[0138] The control plane VCN1216 may allow users of service tenancy 1219 to configure or provision desired resources. Desired resources provisioned in the control plane VCN1216 may be deployed or used in the data plane VCN1218. In some examples, the control plane VCN1216 can be isolated from the data plane VCN1218, and the data plane mirror application layer 1240 of the control plane VCN1216 can communicate with the data plane application layer 1246 of the data plane VCN1218 via a VNIC 1242 which may be included in the data plane mirror application layer 1240 and the data plane application layer 1246.

[0139] In some examples, a system user, or customer, can make a request (for example, create, read, update, or erase an operation (CRUD)) through the public internet 1254, and the public internet 1254 can send the request to the metadata management service 1252. The metadata management service 1252 can send the request to the control plane VCN 1216 through the internet gateway 1234. The request may be received by the LB subnet 1222, which is included in the control plane DMZ layer 1220. The LB subnet 1222 may determine that the request is valid, and in response to this determination, the LB subnet 1222 may send the request to the application subnet 1226, which is included in the control plane application layer 1224. If the request is validated and a call to the public internet 1254 is required, the call to the public internet 1254 may be sent to a NAT gateway 1238, which can make a call to the public internet 1254. Metadata that is deemed desirable to be stored by the request may be stored in the DB subnet 1230.

[0140] In some examples, the data plane mirror application layer 1240 may facilitate direct communication between the control plane VCN 1216 and the data plane VCN 1218. For example, it may be desirable that configuration changes, updates, or other preferred modifications be applied to resources contained in the data plane VCN 1218. The control plane VCN 1216 can perform configuration changes, updates, or other preferred modifications to resources by communicating directly with the resources contained in the data plane VCN 1218 via VNIC 1242.

[0141] In some embodiments, the control plane VCN1216 and the data plane VCN1218 may be included in the service tenancy 1219. In this case, the system user, i.e., the customer, does not have to own either the control plane VCN1216 or the data plane VCN1218, or does not have either of them running. Alternatively, the IaaS provider may own both the control plane VCN1216 and the data plane VCN1218, or have both running, and both may be included in the service tenancy 1219. This embodiment may enable network isolation that can prevent interaction between the user, i.e., the customer, and other users, i.e., other customers' resources. Furthermore, this embodiment may enable private storage of databases by the system user, i.e., the customer, without having to rely on the public internet 1254, which may not have the desired level of threat prevention for storage.

[0142] In another embodiment, the LB subnet 1222 included in the control plane VCN 1216 can 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 customer without calling the public internet 1254. The IaaS provider's customer is likely to prefer this embodiment because the database used by the customer can be stored in a service tenancy 1219 that is controlled by the IaaS provider and can be isolated from the public internet 1254.

[0143] Figure 13 is a block diagram 1300 showing another exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 1302 (for example, service operator 1202 in Figure 12) may be connected to a secure host tenancy 1304 (for example, secure host tenancy 1204 in Figure 12), which may include a virtual cloud network (VCN) 1306 (for example, VCN1206 in Figure 12) and a secure host subnet 1308 (for example, secure host subnet 1208 in Figure 12). VCN 1306 may comprise an LPG 1310 (for example, LPG1210 in Figure 12), which may be connected to an SSH VCN 1312 via a local peering gateway (LPG) 1210 included in the Secure Shell (SSH) VCN 1312 (for example, SSH VCN1212 in Figure 12). SSH VCN1312 may comprise SSH subnet 1314 (for example, SSH subnet 1214 in Figure 12), and SSH VCN1312 may be communicated with control plane VCN1316 via LPG1310 included in control plane VCN1316 (for example, control plane VCN1216 in Figure 12). Control plane VCN1316 may be included in service tenancy 1319 (for example, service tenancy 1219 in Figure 12), and data plane VCN1318 (for example, data plane VCN1218 in Figure 12) may be included in customer tenancy 1321, which may be owned or operated by the system's users, i.e., customers.

[0144] The control plane VCN1316 may comprise a control plane DMZ layer 1320 (for example, the control plane DMZ layer 1220 in Figure 12) which may include an LB subnet 1322 (for example, the LB subnet 1222 in Figure 12), a control plane application layer 1324 (for example, the control plane application layer 1224 in Figure 12) which may include an application subnet 1326 (for example, the application subnet 1226 in Figure 12), and a control plane data layer 1328 (for example, the control plane data layer 1228 in Figure 12) which may include a DB subnet 1330 (similar to the database (DB) subnet 1230 in Figure 12). The LB subnet 1322 included in the control plane DMZ layer 1320 is connected to the application subnet 1326 included in the control plane application layer 1324 and the Internet gateway 1334 (for example, Internet gateway 1234 in Figure 12) which may be included in the control plane VCN 1316. The application subnet 1326 may be connected to the DB subnet 1330 included in the control plane data layer 1328, the service gateway 1336 (for example, the service gateway in Figure 12), and the Network Address Translation (NAT) gateway 1338 (for example, NAT gateway 1238 in Figure 12). The control plane VCN 1316 may comprise the service gateway 1336 and the NAT gateway 1338.

[0145] The control plane VCN 1316 may comprise a data plane mirror application layer 1340 (for example, the data plane mirror application layer 1240 in Figure 12) which may include an application subnet 1326. The application subnet 1326 included in the data plane mirror application layer 1340 may comprise a virtual network interface controller (VNIC) 1342 (for example, the VNIC in Figure 12) which can run a compute instance 1344 (for example, similar to the compute instance 1244 in Figure 12). The compute instance 1344 may facilitate communication between the application subnet 1326 of the data plane mirror application layer 1340 and the application subnet 1326 included in the data plane mirror application layer 1346 (for example, the data plane application layer 1246 in Figure 12) via the VNIC 1342 included in the data plane mirror application layer 1340 and the VNIC 1342 included in the data plane application layer 1346 (for example, the data plane application layer 1246 in Figure 12).

[0146] The Internet gateway 1334 included in the control plane VCN 1316 can be connected to a metadata management service 1352 (for example, the metadata management service 1252 in Figure 12), which can be connected to the public internet 1354 (for example, the public internet 1254 in Figure 12). The public internet 1354 can be connected to a NAT gateway 1338 included in the control plane VCN 1316. The service gateway 1336 included in the control plane VCN 1316 can be connected to a cloud service 1356 (for example, the cloud service 1256 in Figure 12).

[0147] In some examples, the data plane VCN1318 may be included in customer tenancy 1321. In this case, the IaaS provider may provide a control plane VCN1316 for each customer, or the IaaS provider may configure a unique compute instance 1344 included in service tenancy 1319 for each customer. Each compute instance 1344 may enable communication between the control plane VCN1316 included in service tenancy 1319 and the data plane VCN1318 included in customer tenancy 1321. Compute instance 1344 may enable the deployment or use of resources provisioned in the control plane VCN1316 included in service tenancy 1319 in the data plane VCN1318 included in customer tenancy 1321.

[0148] In another example, the IaaS provider's customer may have a database located in customer tenancy 1321. In this example, the control plane VCN 1316 may comprise a data plane mirror application layer 1340, which may include application subnet 1326. The data plane mirror application layer 1340 may reside in data plane VCN 1318, but may not reside in data plane VCN 1318. That is, the data plane mirror application layer 1340 may be accessible to customer tenancy 1321, but may not reside in data plane VCN 1318, nor may it be owned or operated by the IaaS provider's customer. The 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 included in control plane VCN 1316. The customer is expected to want to deploy or use resources in the data plane VCN1318 that are provisioned in the control plane VCN1316, and the data plane mirror application layer 1340 can facilitate the deployment or other use of the resources desired by the customer.

[0149] In some embodiments, a customer of the IaaS provider can apply filters to the data plane VCN1318. In this embodiment, the customer can determine what the data plane VCN1318 can access, and the customer may also restrict access from the data plane VCN1318 to the public internet 1354. The IaaS provider may not be able to apply filters or control the data plane VCN1318's access to any external network or database. The application of filters and controls by the customer to the data plane VCN1318 included in the customer tenancy 1321 may help isolate the data plane VCN1318 from other customers and the public internet 1354.

[0150] In some embodiments, a cloud service 1356 can access services that could not exist on the public internet 1354, the control plane VCN 1316, or the data plane VCN 1318 via a call from the service gateway 1336. The connection between the cloud service 1356 and the control plane VCN 1316 or the data plane VCN 1318 does not have to be live or continuous. The cloud service 1356 may reside on different networks owned or operated by the IaaS provider. The cloud service 1356 may be configured to receive calls from the service gateway 1336 and may be configured not to receive calls from the public internet 1354. Some cloud services 1356 may be isolated from other cloud services 1356, and the control plane VCN 1316 may be isolated from cloud services 1356 that could not be in the same region as the control plane VCN 1316. For example, the control plane VCN1316 may be located in "Region 1," and the 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 included in the control plane VCN1316 located in Region 1, the call may be sent to Deployment 12 in Region 1. In this example, the control plane VCN1316 or Deployment 12 in Region 1 does not need to be communication-coupled to or in communication with Deployment 12 in Region 2.

[0151] Figure 14 is a block diagram 1400 showing another exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 1402 (for example, service operator 1202 in Figure 12) may be connected to a secure host tenancy 1404 (for example, secure host tenancy 1204 in Figure 12), which may include a virtual cloud network (VCN) 1406 (for example, VCN1206 in Figure 12) and a secure host subnet 1408 (for example, secure host subnet 1208 in Figure 12). VCN 1406 may comprise an LPG 1410 (for example, LPG1210 in Figure 12), which may be connected to SSH VCN 1412 via an LPG 1410 included in SSH VCN 1412 (for example, SSH VCN1212 in Figure 12). SSH VCN1412 may comprise SSH subnet 1414 (for example, SSH subnet 1214 in Figure 12), and SSH VCN1412 may be connected to control plane VCN1416 via LPG1410 included in control plane VCN1416 (for example, control plane VCN1216 in Figure 12), and may be connected to data plane VCN1418 via LPG1410 included in data plane VCN1418 (for example, data plane VCN1218 in Figure 12). Control plane VCN1416 and data plane VCN1418 may be included in service tenancy 1419 (for example, service tenancy 1219 in Figure 12).

[0152] The control plane VCN1416 may comprise a control plane DMZ layer 1420 (for example, the control plane DMZ layer 1220 in Figure 12) which may include a load balancer (LB) subnet 1422 (for example, the LB subnet 1222 in Figure 12), a control plane application layer 1424 (for example, the control plane application layer 1224 in Figure 12) which may include an application subnet 1426 (for example, similar to the application subnet 1226 in Figure 12), and a control plane data layer 1428 (for example, the control plane data layer 1228 in Figure 12) which may include a DB subnet 1430. The LB subnet 1422 included in the control plane DMZ layer 1420 is connected to the application subnet 1426 included in the control plane application layer 1424 and the Internet gateway 1434 (for example, Internet gateway 1234 in Figure 12) which may be included in the control plane VCN 1416. The application subnet 1426 may be connected to the DB subnet 1430 included in the control plane data layer 1428, the service gateway 1436 (for example, the service gateway in Figure 12), and the Network Address Translation (NAT) gateway 1438 (for example, NAT gateway 1238 in Figure 12). The control plane VCN 1416 may comprise the service gateway 1436 and the NAT gateway 1438.

[0153] The data plane VCN1418 may comprise a data plane application layer 1446 (for example, the data plane application layer 1246 in Figure 12), a data plane DMZ layer 1448 (for example, the data plane DMZ layer 1248 in Figure 12), and a data plane data layer 1450 (for example, the data plane data layer 1250 in Figure 12). The data plane DMZ layer 1448 may comprise an LB subnet 1422 that can be connected to the trusted application subnet 1460 and the untrusted application subnet 1462 of the data plane application layer 1446, as well as the internet gateway 1434 included in the data plane VCN1418. The trusted application subnet 1460 may be connected to the service gateway 1436 included in the data plane VCN1418, the NAT gateway 1438 included in the data plane VCN1418, and the DB subnet 1430 included in the data plane data layer 1450. The non-trusted application subnet 1462 can be communicated to the service gateway 1436 included in the data plane VCN 1418 and the DB subnet 1430 included in the data plane data layer 1450. The data plane data layer 1450 may comprise the DB subnet 1430, which can be communicated to the service gateway 1436 included in the data plane VCN 1418.

[0154] The untrusted application subnet 1462 may comprise one or more primary VNICs 1464(1) to 1464(N) that can be connected to tenant virtual machines (VMs) 1466(1) to 1466(N). Each tenant VM 1466(1) to 1466(N) may be connected to each application subnet 1467(1) to 1467(N) that may be included in each container output VCN 1468(1) to 1468(N) that may be included in each customer tenancy 1470(1) to 1470(N). Each secondary VNIC 1472(1) to 1472(N) may facilitate communication between the untrusted application subnet 1462 included in the data plane VCN 1418 and the application subnets included in the container output VCNs 1468(1) to 1468(N). Each container output VCN 1468(1) to 1468(N) may be equipped with a NAT gateway 1438 that can communicate with the public internet 1454 (for example, the public internet 1254 in Figure 12).

[0155] The Internet gateway 1434 included in the control plane VCN1416 and data plane VCN1418 can be connected to a metadata management service 1452 (for example, the metadata management system 1252 in Figure 12), which can be connected to the public internet 1454. The public internet 1454 can be connected to a NAT gateway 1438 included in the control plane VCN1416 and data plane VCN1418. The service gateway 1436 included in the control plane VCN1416 and data plane VCN1418 can be connected to a cloud service 1456.

[0156] In some embodiments, the data plane VCN 1418 may be integrated with a customer tenancy 1470. This integration may be useful or desirable to the IaaS provider's customers, for example, if they may want support for executing code. The customer may provide code to be executed, which may be destructive, communicate with other customer resources, or have undesirable effects. In response, the IaaS provider may determine whether to execute the code provided to the IaaS provider by the customer.

[0157] In some examples, an IaaS provider's customer may grant temporary network access to the IaaS provider and request functionality to be granted to the data plane application layer 1446. The code that performs this functionality may run in VMs 1466(1) to 1466(N), and may not be configured to run elsewhere on the data plane VCN 1418. Each VM 1466(1) to 1466(N) may be connected to a single customer tenancy 1470. Each container 1471(1) to 1471(N) contained within VMs 1466(1) to 1466(N) may be configured to run code. In this case, a double isolation may exist (for example, containers 1471(1)-1471(N) executing the code may be contained within VMs 1466(1)-1466(N) that are at least in the non-trusted app subnet 1462), which may help prevent damage to the IaaS provider's network or a different customer's network by erroneous or undesirable code. Containers 1471(1)-1471(N) may be communication-coupled to customer tenancy 1470 and may be configured to send or receive data to or from customer tenancy 1470. Containers 1471(1)-1471(N) may also be configured not to send or receive data to or from any other entity in the data plane VCN 1418. Upon completion of code execution, the IaaS provider may disable or discard containers 1471(1)-1471(N).

[0158] In some embodiments, the trusted application subnet 1460 may be configured to execute code owned or operated by the IaaS provider. In this embodiment, the trusted application subnet 1460 may be connected to the DB subnet 1430 and may be configured to perform CRUD operations in the DB subnet 1430. The non-trusted application subnet 1462 may be connected to the DB subnet 1430, but in this embodiment, may be configured to perform read operations in the DB subnet 1430. Containers 1471(1) to 1471(N) contained in each customer's VMs 1466(1) to 1466(N) and capable of executing code from the customer may not be connected to the DB subnet 1430.

[0159] In other embodiments, the control plane VCN1416 and the data plane VCN1418 do not have to be directly connected. In this embodiment, direct communication between the control plane VCN1416 and the data plane VCN1418 is not required. However, communication can be performed indirectly by at least one method. An LPG1410 that can facilitate communication between the control plane VCN1416 and the data plane VCN1418 may be established by the IaaS provider. In another example, the control plane VCN1416 or the data plane VCN1418 can make a call to the cloud service 1456 via the service gateway 1436. For example, a call from the control plane VCN1416 to the cloud service 1456 may include a request for a service that can communicate with the data plane VCN1418.

[0160] Figure 15 is a block diagram 1500 showing another exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 1502 (for example, service operator 1202 in Figure 12) may be connected to a secure host tenancy 1504 (for example, secure host tenancy 1204 in Figure 12), which may include a virtual cloud network (VCN) 1506 (for example, VCN1206 in Figure 12) and a secure host subnet 1508 (for example, secure host subnet 1208 in Figure 12). VCN 1506 may comprise an LPG 1510 (for example, LPG1210 in Figure 12), which may be connected to SSH VCN 1512 (for example, SSH VCN1212 in Figure 12) via an LPG 1510 included in SSH VCN 1512. SSH VCN1512 may comprise an SSH subnet 1514 (for example, SSH subnet 1214 in Figure 12), and SSH VCN1512 may be connected to control plane VCN1516 via an LPG 1510 included in control plane VCN1516 (for example, control plane VCN1216 in Figure 12), and may be connected to data plane VCN1518 via an LPG 1510 included in data plane VCN1518 (for example, data plane VCN1218 in Figure 12). Control plane VCN1516 and data plane VCN1518 may be included in service tenancy 1519 (for example, service tenancy 1219 in Figure 12).

[0161] The control plane VCN1516 may comprise a control plane DMZ layer 1520 (for example, the control plane DMZ layer 1220 in Figure 12) which may include an LB subnet 1522 (for example, the LB subnet 1222 in Figure 12), a control plane application layer 1524 (for example, the control plane application layer 1224 in Figure 12) which may include an application subnet 1526 (for example, the application subnet 1226 in Figure 12), and a control plane data layer 1528 (for example, the control plane data layer 1228 in Figure 12) which may include a DB subnet 1530 (for example, the DB subnet 1430 in Figure 14). The LB subnet 1522 included in the control plane DMZ layer 1520 is connected to the application subnet 1526 included in the control plane application layer 1524 and the Internet gateway 1534 (for example, Internet gateway 1234 in Figure 12) which may be included in the control plane VCN 1516. The application subnet 1526 may be connected to the DB subnet 1530 included in the control plane data layer 1528, the service gateway 1536 (for example, the service gateway in Figure 12), and the Network Address Translation (NAT) gateway 1538 (for example, NAT gateway 1238 in Figure 12). The control plane VCN 1516 may comprise the service gateway 1536 and the NAT gateway 1538.

[0162] The data plane VCN 1518 may comprise a data plane application layer 1546 (for example, the data plane application layer 1246 in Figure 12), a data plane DMZ layer 1548 (for example, the data plane DMZ layer 1248 in Figure 12), and a data plane data layer 1550 (for example, the data plane data layer 1250 in Figure 12). The data plane DMZ layer 1548 may comprise a trusted application subnet 1560 (for example, the trusted application subnet 1460 in Figure 14) and an untrusted application subnet 1562 (for example, the untrusted application subnet 1462 in Figure 14) of the data plane application layer 1546, as well as an LB subnet 1522 that can be connected to an internet gateway 1534 included in the data plane VCN 1518. Trusted application subnet 1560 can be connected to service gateway 1536 included in data plane VCN 1518, NAT gateway 1538 included in data plane VCN 1518, and DB subnet 1530 included in data plane data layer 1550. Non-trusted application subnet 1562 can be connected to service gateway 1536 included in data plane VCN 1518 and DB subnet 1530 included in data plane data layer 1550. Data plane data layer 1550 may include DB subnet 1530 that can be connected to service gateway 1536 included in data plane VCN 1518.

[0163] The untrusted application subnet 1562 may comprise primary VNICs 1564(1) to 1564(N) that can be connected to tenant virtual machines (VMs) 1566(1) to 1566(N) residing within the untrusted application subnet 1562. Each tenant VM 1566(1) to 1566(N) can execute code in each of the containers 1567(1) to 1567(N) and can be connected to an application subnet 1526 that may be included in the data plane application layer 1546 that may be included in the container output VCN 1568. The secondary VNICs 1572(1) to 1572(N) can facilitate communication between the untrusted application subnet 1562 included in the data plane VCN 1518 and the application subnet included in the container output VCN 1568. The container output VCN may include a NAT gateway 1538 that can be connected to the public internet 1554 (for example, the public internet 1254 in Figure 12).

[0164] The Internet gateway 1534 included in the control plane VCN1516 and data plane VCN1518 can be connected to a metadata management service 1552 (for example, the metadata management system 1252 in Figure 12), which can be connected to the public internet 1554. The public internet 1554 can be connected to a NAT gateway 1538 included in the control plane VCN1516 and data plane VCN1518. The service gateway 1536 included in the control plane VCN1516 and data plane VCN1518 can be connected to a cloud service 1556.

[0165] In some examples, the architecture pattern shown in block diagram 1500 of Figure 15 is considered an exception to the architecture pattern shown in block diagram 1400 of Figure 14, and is considered desirable for the IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (for example, in an unconnected region). Each customer has containers 1567(1) to 1567(N) contained within VMs 1566(1) to 1566(N), each of which is accessible to the customer in real time. Containers 1567(1) to 1567(N) may be configured to make calls to each of the secondary VNICs 1572(1) to 1572(N) contained within the application subnet 1526 of the data plane application layer 1546, which may be contained within the container output VCN 1568. Secondary VNICs 1572(1) to 1572(N) can send calls to the NAT gateway 1538, which may then send calls to the public internet 1554. In this example, the customer-accessible containers 1567(1) to 1567(N) can be isolated from the control plane VCN 1516, as well as from other entities included in the data plane VCN 1518. Furthermore, the containers 1567(1) to 1567(N) can also be isolated from other customer resources.

[0166] In another example, a customer can use containers 1567(1) to 1567(N) to invoke cloud service 1556. In this example, a customer can execute code in containers 1567(1) to 1567(N) to request services from cloud service 1556. Containers 1567(1) to 1567(N) can send this request to secondary VNICs 1572(1) to 1572(N), which can send the request to the NAT gateway, which can send the request to the public internet 1554. The public internet 1554 can send the request to LB subnet 1522, which is included in control plane VCN 1516, via internet gateway 1534. In response to the determination that the request is valid, the LB subnet can send the request to the application subnet 1526, and the application subnet 1526 can send the request to the cloud service 1556 via the service gateway 1536.

[0167] Naturally, the IaaS architectures 1200, 1300, 1400, and 1500 shown in the drawings may have components other than those shown. Furthermore, the embodiments shown in the drawings are merely examples of cloud infrastructure systems that may encompass one embodiment of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown, may combine two or more components, or may have different configurations or arrangements of components.

[0168] In one embodiment, the IaaS system described herein may include a set of applications, middleware, and database service offerings delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. Oracle Cloud Infrastructure (OCI), offered by the assignee, is an example of such an IaaS system.

[0169] Figure 16 shows an exemplary computer system 1600 in which various embodiments can be realized. System 1600 may be used to realize any of the computer systems described above. As shown in the drawing, computer system 1600 comprises a processing unit 1604 that communicates with many peripheral subsystems via a bus subsystem 1602. Peripheral subsystems may include a processing acceleration unit 1606, an I / O subsystem 1608, a storage subsystem 1618, and a communication subsystem 1624. The storage subsystem 1618 comprises a tangible computer-readable storage medium 1622 and a system memory 1610.

[0170] The bus subsystem 1602 provides a mechanism for various components and subsystems of the computer system 1600 to communicate with each other as intended. While the bus subsystem 1602 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 1602 may be one of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus, using any of a variety of bus architectures. For example, such architectures may include industry standard architecture (ISA) buses, microchannel architecture (MCA) buses, extended ISA (EISA) buses, video electronics standards (VESA) local buses, and peripheral interconnect (PCI) buses, which can be implemented as mezzanine buses manufactured according to the IEEE P1386.1 standard.

[0171] A processing unit 1604, which can be implemented as one or more integrated circuits (for example, conventional microprocessors or microcontrollers), controls the operation of the computer system 1600. The processing unit 1604 may include one or more processors. These processors may include single-core or multi-core processors. In one embodiment, the processing unit 1604 may be implemented as one or more independent processing units 1632 and / or 1634, each containing a single-core or multi-core processor. In another embodiment, the processing unit 1604 may be implemented as a quad-core processing unit formed by integrating two dual-core processors onto a single chip.

[0172] In various embodiments, the processing unit 1604 can execute a variety of programs in response to program code and maintain multiple concurrently running programs or processes. At any given time, some or all of the program code to be executed may reside in the processor 1604 and / or the storage subsystem 1618. With suitable programming, the processor 1604 can provide the various functions described above. The computer system 1600 may also include a processing acceleration unit 1606 which may include a digital signal processor (DSP), a dedicated processor, and / or similar.

[0173] The I / O subsystem 1608 may include user interface input devices and user interface output devices. User interface input devices may include pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include motion detection and / or gesture recognition devices such as Microsoft Kinect® motion sensors that enable user control and interaction with input devices such as Microsoft Xbox® 360 game controllers through a natural user interface using gestures and voice commands. User interface input devices may also include eye gesture recognition devices such as Google Glass® blink detectors that detect the user's eye activity (e.g., blinking during shooting and / or menu selection) and convert eye gestures into input to an input device (e.g., Google Glass®). Furthermore, the user interface input device may include a voice recognition detection device that enables user interaction with a voice recognition system (e.g., Siri® Navigator) via voice commands.

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

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

[0176] The computer system 1600 may include a storage subsystem 1618 that provides a tangible temporary 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., that provide the above-described functionality when executed by one or more cores or processors of the processing unit 1604. The storage subsystem 1618 may also provide a repository for storing data used in accordance with this disclosure.

[0177] As shown in the example in Figure 16, the storage subsystem 1618 may comprise various components, including system memory 1610, a computer-readable storage medium 1622, and a computer-readable storage medium reader 1620. The system memory 1610 may store program instructions that can be loaded and executed by the processing unit 1604. The system memory 1610 may also store data used when instructions are executed and / or data generated when program instructions are executed. Various different types of programs may be loaded into the system memory 1610, including, but not limited to, client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), virtual machines, containers, and the like.

[0178] Furthermore, system memory 1610 may be configured to store the operating system 1616. Examples of operating systems 1616 include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems, a variety of commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux® operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS. In one embodiment in which computer system 1600 runs one or more virtual machines, the virtual machines, along with their respective guest operating systems (GOS), may be loaded into system memory 1610 and executed by one or more processors or cores of processing unit 1604.

[0179] The system memory 1610 can have various configurations depending on the type of computer system 1600. For example, the system memory 1610 may be volatile memory (such as random access memory (RAM)) and / or non-volatile memory (such as read-only memory (ROM) or flash memory). It may also be provided with different types of RAM configurations, including static random access memory (SRAM), dynamic random access memory (DRAM), and others. In some embodiments, the system memory 1610 may include a basic input / output system (BIOS) that includes basic routines useful for communicating information between elements within the computer system 1600, such as during startup.

[0180] The computer-readable storage medium 1622 may represent a remote, local, fixed, and / or removable storage device, as well as a storage medium for temporarily and / or permanently containing and storing computer-readable information used by the computer system 1600 (including instructions executable by the processing unit 1604 of the computer system 1600).

[0181] The computer-readable storage medium 1622 may include, but is not limited to, any suitable medium known or used in the art (including storage and communication media), volatile and non-volatile, removable and non-removable media implemented in any method or technique for storing and / or transmitting information. This may include memory technologies such as RAM, ROM, electronically erasable programmable ROM (EEPROM), and flash memory; optical storage such as CD-ROM and digital multipurpose discs (DVDs); magnetic storage devices such as magnetic cassettes, magnetic tapes, and magnetic disk storage; or other tangible computer-readable storage media.

[0182] As an example, the computer-readable storage medium 1622 may include a hard disk drive that reads and writes to a non-removable non-volatile magnetic medium, a magnetic disk drive that reads and writes to a removable non-volatile magnetic disk, and an optical disk drive that reads and writes to a removable non-volatile optical disk such as a CD-ROM, DVD, Blu-ray® disc, or other optical medium. The computer-readable storage medium 1622 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD discs, digital videotapes, etc. Furthermore, the computer-readable storage medium 1622 may include SSDs based on volatile memory such as flash memory-based SSDs, enterprise flash drives, semiconductor drives (SSDs) based on non-volatile memory such as semiconductor ROM, semiconductor RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their respective associated computer-readable media may provide non-volatile storage for computer-readable instructions, data structures, program services, and other data to the computer system 1600.

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

[0184] The communication subsystem 1624 provides an interface to other computer systems and networks. The communication subsystem 1624 functions as an interface for sending and receiving data between the computer system 1600 and other systems. For example, the communication subsystem 1624 may enable the computer system 1600 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 1624 may comprise radio voice and / or data networks (using, for example, cellular technology, 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution), advanced data network technologies such as WiFi (IEEE 802.11 family standards), or other mobile communication technologies, or any combination thereof), a Global Positioning System (GPS) receiver component, and / or radio frequency (RF) transceiver components for accessing other components. In some embodiments, the communication subsystem 1624 may provide wired network connectivity (e.g., Ethernet) as an addition to or alternative to the radio interface.

[0185] In addition, in some embodiments, the communication subsystem 1624 is capable of receiving input communications in the form of structured and / or unstructured data feeds 1626, event streams 1628, event updates 1630, etc., on behalf of one or more users who may be using the computer system 1600.

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

[0187] Furthermore, the communication subsystem 1624 may 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 virtually infinite with no explicit end. Examples of applications that generate continuous data include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, and automotive traffic monitoring.

[0188] Furthermore, the communication subsystem 1624 may 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 connected to the computer system 1600.

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

[0190] Due to the constantly changing nature of computers and networks, the description of the illustrated computer system 1600 is intended only as a specific example. Many other configurations are possible, whether with more or fewer components than the illustrated system. For example, the use of customized hardware and / or the implementation of specific elements in hardware, firmware, software (including applets), or combinations thereof are also possible. Furthermore, connections to other computing devices such as network input / output devices may be employed. Based on the disclosures and teachings contained herein, those skilled in the art will recognize other methods and / or ways of realizing various embodiments.

[0191] While specific embodiments have been described above, various improvements, modifications, alternative configurations, and equivalents are also included in the scope of this disclosure. The embodiments are not limited to operation within a particular data processing environment, but can freely operate within multiple data processing environments. Furthermore, while the embodiments have been described using a specific set of transactions and steps, it will be clear to those skilled in the art that the scope of this disclosure is not limited to the set of transactions and steps described. The various features and aspects of the embodiments described above may be used individually or in combination.

[0192] Furthermore, while embodiments have been described using specific combinations of hardware and software, it will be recognized that other combinations of hardware and software are also included in the scope of this disclosure. Embodiments may be implemented in hardware only, in software only, or by using a combination of these. The various processes described herein may be implemented on the same processor or on any combination of different processors. Thus, where a component or service is described as being configured to perform a certain operation, such configuration may be achieved, for example, by designing electronic circuitry to perform this operation, by programming programmable electronic circuitry (such as a microprocessor) to perform this operation, or by any combination thereof. Processes may be communicative using a variety of techniques, including but not limited to conventional techniques for inter-process communication. Also, different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0193] Therefore, this specification and the drawings are intended to be illustrative and not limiting in any way. However, it is clear that additions, differences, deletions, and other improvements and modifications can be made without departing from the broader idea and scope set forth in the claims. For this reason, specific embodiments of this disclosure have been described, but these are not intended to be limiting in any way. Various improvements and equivalents are included in the following claims.

[0194] In the context describing embodiments of the disclosure (in particular, in the context of the following claims), the terms “a,” “an,” and “the,” and similar reference subjects, shall be interpreted to encompass both singular and plural forms unless otherwise indicated herein or there is a clear contextual inconsistency. The terms “comprising,” “having,” “including,” and “containing” shall be interpreted as open-ended terms (i.e., “including, but not limited to,”) unless otherwise indicated herein. The term “connected” shall be interpreted as including, attaching, or integrally combining, in whole or in part, even if something is intervening. Unless otherwise indicated herein, descriptions of ranges of values ​​are intended merely as a concise way of referring individually to each distinct value contained within that range, and each distinct value is incorporated herein as if it were individually described herein. Unless otherwise indicated herein or there is a clear contextual inconsistency, all methods described herein may be performed in any preferred order. The use of any examples or illustrative expressions (e.g., "such as") described herein is intended solely to facilitate the understanding of the embodiments and, unless otherwise claimed, does not limit the scope of this disclosure. Nothing described herein shall be construed as indicating that any non-claimed element is essential to the implementation of this disclosure.

[0195] Unless otherwise specified, disjunctive expressions such as the phrase "at least one of X, Y, or Z" are intended to be understood in contexts in which they are commonly used to indicate that an item, term, etc., can be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such disjunctive expressions are not intended, nor should they, to imply, that any embodiment requires the presence of at least one of X, at least one of Y, or at least one of Z.

[0196] This specification describes preferred embodiments of the Disclosure, including the best known modes for the execution of the Disclosure. Those skilled in the art will be able to see, by reading the above description, variations of these preferred embodiments. Those skilled in the art may adopt such variations as appropriate, and the Disclosure may be executed in a manner different from the specific description herein. Therefore, to the extent permitted by applicable law, the Disclosure includes all improvements and equivalents to the subject matter described in the claims appended herein. Furthermore, unless otherwise indicated herein, any combination of all conceivable variations of the elements described herein is included in the Disclosure.

[0197] All references cited herein, including publications, patent applications, and patents, are incorporated herein by reference to the same extent as they are incorporated herein by reference, with each reference being individually and specifically indicated.

[0198] While the above specification describes aspects of the disclosure with reference to specific embodiments, those skilled in the art will recognize that the disclosure is not limited thereto. The various features and aspects of the disclosure described above may be used individually or in combination. Furthermore, various modifications and equivalents include appropriate combinations of the features of the disclosure relevant to the embodiments. Moreover, the embodiments may be used in any number of environments and applications beyond those described herein, without departing from the broader idea and scope of this specification. Accordingly, this specification and the drawings should be considered illustrative and not limiting.

Claims

1. A frame that can be placed adjacent to a computing device, The frame comprises a plurality of ports arranged on its surface, each configured to accept a cable termination connector corresponding to a networking cable of a static network fabric, A cable terminal protection device equipped with the following features.

2. The cable terminal protection device according to claim 1, wherein the plurality of ports are arranged on the surface of the frame such that they substantially align with a second plurality of ports of the computing device when the frame is positioned adjacent to the computing device.

3. The cable terminal protection device according to claim 2, wherein the substantial alignment of the plurality of ports with respect to the second plurality of ports includes vertical alignment of each of the plurality of ports with respect to a corresponding port among the second plurality of ports when the frame is positioned adjacent to the computing device.

4. The cable terminal protection device according to claim 2, wherein the substantial alignment of the plurality of ports with respect to the second plurality of ports includes the horizontal alignment of each of the plurality of ports with respect to a corresponding port among the second plurality of ports when the frame is positioned adjacent to the computing device.

5. The cable terminal protection device according to any one of claims 1 to 4, further comprising a port cover for at least one of the plurality of ports, wherein the port cover is connected to the at least one port and configured to substantially cover the opening of the at least one port.

6. The cable terminal protection device according to claim 5, wherein the port cover is connected to the frame by a flexible cable at a position adjacent to at least one port.

7. The cable terminal protection device according to any one of claims 1 to 6, wherein the plurality of ports comprises at least one networking port corresponding to a physical standard, and the cable termination connector corresponding to the at least one networking port corresponds to the physical standard.

8. The aforementioned physical standard is, Multi-fiber push-on (MPO), Multi-fiber pull-off, SFP (Small Form-factor Pluggable), SFP+, SFP28, QSFP (Quad Small Form-factor Pluggable), QSFP+, QSFP28, or RJ45, The cable terminal protection device according to claim 7, including the above.

9. The cable terminal protection device according to claim 7 or 8, wherein at least one networking port among the plurality of ports includes a disabled terminal.

10. It is a system, A data center equipped with racks for housing multiple devices, The rack can be located at a certain location in the data center, and the plurality of devices comprises networking devices and server devices, the networking devices are connected to the server devices for communication, and the networking devices have a plurality of networking ports. The aforementioned system, The data center further comprises a cable terminal protection device mounted adjacent to the aforementioned location, The cable terminal protection device comprises a plurality of ports, and at least one of the plurality of ports is configured to accept a cable termination connector. The aforementioned system, The system further comprises multiple network cables routed through the aforementioned data center, A system in which at least one of the plurality of networking cables has a termination portion at the location in the data center, and the termination portion of the at least one networking cable is coupled to the cable termination connector.

11. The system according to claim 10, wherein at least one of the plurality of networking ports is configured to accept the cable termination connector, and the at least one networking cable is movable between the at least one of the plurality of networking ports of the networking device and the at least one of the plurality of ports of the cable terminal protection device.

12. The system according to claim 10 or 11, wherein at least one of the plurality of ports of the cable terminal protection device is aligned vertically with at least one of the plurality of networking ports when the rack is positioned in the data center.

13. The system according to any one of claims 10 to 12, wherein the number of ports of the cable terminal protection device is greater than the number of networking ports of the networking device.

14. The system according to claim 10, wherein the number of ports of the cable terminal protection device is the same as the number of networking ports of the networking device, the number of ports of the cable terminal protection device and the number of networking ports of the networking device are characterized by physical standards, and each of the number of networking ports of the networking device corresponds to one of the number of ports.

15. The system according to claim 10, wherein the cable terminal protection device is located above the rack when the rack is positioned in the data center.

16. It is a method, In computing devices, receiving requests to build regional data center racks, In response to the build request, the computing device obtains the physical configuration parameters of the computing device on the data center rack, Includes, The computing device comprises a networking device having a plurality of networking ports, and the physical configuration parameter specifies at least one of the networking ports of the networking device. The aforementioned method, The computing device acquires cable wiring specification information corresponding to a number of networking cables configured to terminate at a location in the data center and at a cable terminal protection device at that location. The computing device uses the physical configuration parameters and the cable wiring specification information to generate instructions that can be used to disconnect the networking cable from the cable terminal protection device and to reconnect the networking cable at the networking port of the networking device. Methods that further include the above.

17. Generating instructions is To determine a first correspondence between the port of the cable terminal protection device to which the networking cable is detachably connected and the networking port of the networking device on the data center rack, To determine a second correspondence between the second port of the cable terminal protection device to which the second networking cable among the plurality of networking cables is detachably connected and the second networking port of the networking device, Using the first correspondence and the second correspondence, determine the sequence of operations for (i) disconnecting the networking cable from the port, (ii) reconnecting the networking cable to the networking port, (iii) disconnecting the second networking cable from the second port, and (iv) reconnecting the second networking cable to the second networking port. The method according to claim 16, including the method described in claim 16.

18. Sending the aforementioned instructions to the user device, To disconnect the networking cable from the cable terminal protection device and reconnect the networking cable to the networking port, the user device is instructed to present the user with the instructions. The method according to claim 16 or claim 17, further comprising:

19. Perform a connection test to confirm that the network cable is connected to the network port, The user device is made to display an indicator corresponding to the results of the aforementioned connection test, The method according to any one of claims 16 to 18, further comprising:

20. The result of the connection test is determined to correspond to an incorrect connection of the network cable to the network port, To determine the current connection of the networking cable to the wrong port of the networking device, Using the existing connection, determine the additional sequence of actions for (a) disconnecting the networking cable from the erroneous port, (b) disconnecting the erroneous cable from the networking port, (c) reconnecting the networking cable to the networking port, and (d) reconnecting the erroneous cable to the cable terminal protection device. This generates additional instructions, The method according to claim 19, further comprising:

Images