Techniques for generating configurations for electrically isolating failure domains in a data center

Abstract

The computer system may receive a datacenter layout, the datacenter layout identifying the physical locations of multiple server racks, power distribution units, and uninterruptible power supplies. The computer system may receive a failure domain configuration for the datacenter, the failure domain configuration identifying the virtual locations of multiple logical failure domains for distributing one or more instances such that the one or more instances are stored on independent physical hardware devices within a single availability failure domain. The computer system may determine the datacenter configuration by assigning the multiple failure domains to multiple electrical zones, each electrical zone providing redundant power supply across the multiple logical failure domains in the event of one or more power distribution units failing. The computer system may display the configuration for the datacenter on a display.

Description

[Technical Field]

[0001] REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 17 / 211,670, entitled "TECHNIQUES FOR GENERATING A CONFIGURATION FOR ELECTRICALLY ISOLATING FAULT DOMAINS IN A DATA CENTER," filed March 24, 2021, which claims the benefit of U.S. Provisional Patent Application No. 63 / 083,754, entitled "Techniques For Improving Ranging Between Electronic Devices," filed September 25, 2020, the entire contents of which are incorporated herein by reference for all purposes. [Background technology]

[0002] background Data centers can be organized by fault domains. A fault domain is a grouping of hardware and infrastructure within an availability domain. Fault domains provide anti-affinity by distributing customer compute and storage instances so that instances are not on the same physical hardware within a single availability domain. A hardware failure or hardware maintenance event that affects one fault domain does not affect instances in other fault domains. However, these fault domains are not necessarily electrically isolated from each other. Therefore, an electrical failure in one or more power sources can result in a loss of fault domain redundancy or performance of instances on the fault domain. Summary of the Invention [Means for solving the problem]

[0003] overview In some implementations, a technique includes receiving a layout of a data center. The data center layout may identify physical locations of multiple server racks, multiple power distribution units, and multiple power sources. The technique may include receiving a logical fault domain configuration for the data center. The logical fault domain configuration may identify virtual locations of multiple logical fault domains for distributing one or more compute instances. The compute instances may run on independent physical hardware devices within a single logical fault domain based at least in part on the logical fault domain configuration. The technique may include determining a data center configuration by assigning at least some of the multiple logical fault domains to at least some of a plurality of electrical zones. Each electrical zone of the multiple electrical zones may provide a redundant power supply across the multiple logical fault domains based at least in part on the occurrence of a power outage. The technique may include transmitting the data center configuration to a device for display.

[0004] In some implementations, a non-transitory computer-readable medium storing a set of instructions includes one or more instructions that, when executed by one or more processors of a computer system, cause the computer system to perform operations. The operations may include receiving a layout of a data center. The data center layout may identify physical locations of a plurality of server racks, a plurality of power distribution sections, and a plurality of power sources. The operations may include receiving a logical fault domain configuration for the data center. The logical fault domain configuration may identify virtual locations of a plurality of logical fault domains for distributing one or more compute instances. The compute instances may run on independent physical hardware devices within a single logical fault domain based at least in part on the logical fault domain configuration. The operations may include determining a data center configuration by assigning at least some of the plurality of logical fault domains to at least some of a plurality of electrical zones. Each electrical zone of the plurality of electrical zones may provide a redundant power supply across the plurality of logical fault domains based at least in part on the occurrence of a power outage. The operations may include transmitting the data center configuration to a device for display.

[0005] In some implementations, a computer system includes one or more memories and one or more processors communicatively coupled to the one or more memories and configured to perform operations. The operations may include receiving a layout of a data center. The data center layout may identify physical locations of a plurality of server racks, a plurality of power distribution sections, and a plurality of power sources. The operations may include receiving a logical fault domain configuration for the data center. The logical fault domain configuration may include identifying virtual locations of a plurality of logical fault domains for distributing one or more compute instances. The compute instances may run on independent physical hardware devices within a single logical fault domain based at least in part on the logical fault domain configuration. The operations may include determining a data center configuration by assigning at least some of the plurality of logical fault domains to at least some of a plurality of electrical zones. Each electrical zone of the plurality of electrical zones provides a redundant power supply across the plurality of logical fault domains based at least in part on the occurrence of a power outage. The operations may include transmitting the data center configuration to a device for display.

[0006] These and other embodiments are described in more detail below. For example, other embodiments are directed to systems, devices, and computer-readable media associated with the methods described herein.

[0007] A better understanding of the nature and advantages of the embodiments of the present disclosure may be obtained by reference to the following detailed description and accompanying drawings. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates a first exemplary data center according to some embodiments. [Figure 2] FIG. 2 illustrates a second exemplary data center according to an embodiment of the present disclosure. [Figure 3] 1 illustrates an exemplary data center that does not employ the electrical isolation techniques described above, according to embodiments of the present disclosure. [Figure 4] 4 is a table showing the effects of the data center configuration shown in FIG. 3. [Figure 5] A first table showing a failover matrix for a data center using the electrical isolation techniques described above is shown. [Figure 6] 1 is a second table showing a failover matrix for a data center using the electrical isolation techniques described above. [Figure 7] 1 is a flowchart of an exemplary process associated with a technique for generating a configuration for electrically isolating failure domains in a data center. [Figure 8] FIG. 1 is a block diagram of a data center according to at least one embodiment. [Figure 9] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 10] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 11] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 12] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 13] FIG. 1 is a block diagram illustrating an exemplary computer system according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] Detailed Description of the Drawings In the following description, for purposes of explanation, specific details are set forth in order to provide a thorough understanding of particular embodiments. However, it will be apparent that various embodiments may be practiced without these specific details. The drawings and description are not intended to be limiting.

[0010] Certain embodiments disclose techniques for determining configurations for electrically isolating various failure domains within a data center. A data center may provide redundancy and resilience by distributing compute and / or storage instances across several servers as part of logical failure domains. Thus, the failure of a particular server or server rack does not render the compute and / or storage instances inoperable or unavailable. For example, if a web service is hosted on several servers across failure domains, the failure of any one server does not render the web service unavailable.

[0011] The present disclosure improves on the failure domain concept by considering the power sources and power distribution to devices within various failure domains. For example, if multiple servers within a failure domain are powered by the same power supply, a failure of that power supply or power distribution can destroy the redundancy that the failure domain concept provides.

[0012] Disclosed is a technique that includes receiving a data center layout. The data center layout may identify physical locations of multiple server racks, multiple power distribution sections, and multiple power sources. The technique may include receiving a logical fault domain configuration for the data center. The logical fault domain configuration may identify virtual locations of multiple logical fault domains for distributing one or more compute instances. The compute instances may run on independent physical hardware devices within a single logical fault domain based at least in part on the logical fault domain configuration. The technique may include determining a data center configuration by assigning at least some of the multiple logical fault domains to at least some of a plurality of electrical zones. Each electrical zone of the multiple electrical zones may provide a redundant power supply across the multiple logical fault domains based at least in part on the occurrence of a power outage. The technique may include transmitting the data center configuration to a device for display.

[0013] In this manner, a data center configuration employing the techniques described herein preserves the redundancy and resilience provided by logical fault domains in the event of failure of one or more power sources or feeds.

[0014] For purposes of this application, a "fault domain" is a set of hardware components (computers, switches, and so on) that share a single point of failure. A compute pool may be logically divided into fault domains. In some examples, each availability domain contains two or more fault domains. Fault domains provide anti-affinity, allowing developers to distribute instances so that they are not on the same physical hardware within a single availability domain. A hardware failure or hardware maintenance event that affects one fault domain does not affect instances in other fault domains.

[0015] For purposes of this application, an "instance" is a hosted server running in either a customer enclave (publicly available) or a service enclave. If an instance has direct access to the hardware it runs on, it may be considered a bare metal instance. If there is a hypervisor between the compute or storage instance, it may be considered a virtual instance.

[0016] For the purposes of this application, an "electrical zone" (EZ) in a data center is defined as a unique combination of uninterruptible power supplies (UPS) that are fed to individual racks through the electrical infrastructure. EZs can be established during data center design and are inflexible after construction. A data center may have as few as one EZ. Depending on the UPS configuration and power distribution, a single location may have many failure domains. Table 1 shows how the number of uninterruptible power supplies results in the number of electrical zones.

[0017] [Table 1]

[0018] Mapping fault domains between electrical zones increases service reliability during electrical events. Electrical zones will have their resiliency reduced to different degrees during planned maintenance and equipment failures. Some events will remove UPS resiliency and provide only utility power to the racks. Other events will interrupt power at different levels of the electrical infrastructure. Some interruptions will occur during required maintenance cycles. It is important to note that power resiliency is designed so that it takes two failures to bring down the racks.

[0019] Examples of "blast radii" are in the table below, which will vary from location to location depending on infrastructure design.

[0020] Table 2 shows the impact of various equipment outages.

[0021] [Table 2]

[0022] 1 illustrates a first exemplary data center 100 according to some embodiments of the present disclosure. The data center can receive power from one or more substations 102, 104. The substations 102, 104 can receive power from power generation sources (e.g., nuclear power plants, conventional power plants (e.g., coal, oil, and natural gas), hydroelectric power plants, wind turbine power systems, solar power systems, geothermal power systems), which transmit power to substations (e.g., substations 102, 104) via high-frequency power lines. The substations 102, 104 are part of an electrical power generation, transmission, and distribution system. The substations 102, 104 can convert voltage from high to low or vice versa, or perform any of several other important functions. Between the power generation plants and consumers, electrical power may flow through several substations at different voltage levels. The substations 102, 104 may include transformers for changing voltage levels between a higher transmission voltage and a lower distribution voltage, or in the interconnection of two different transmission voltages.

[0023] The data center may have one or more backup power sources 106 (eg, generators) that provide power to the substation in the event of a loss of power from the utility grid.

[0024] Power from substations 102, 104 or backup power sources 106 may be routed to switch 108. Switch 108 may include a hitless transfer system (STS). An STS is an intelligent switch that provides increased supply availability by automatically transferring loads to an alternate power source if the primary power source fails or is unavailable. Switch 108 may also include an automatic transfer switch (ATS). An ATS is a device that, upon sensing a fault or accident in the primary power source, automatically switches power supply from the primary power source to a backup generator until utility power is restored.

[0025] From the switches, power is routed to various power supply devices (e.g., uninterruptible power supply (UPS) devices) 110, 112, 114, 116. UPS devices 110, 112, 114, 116 are electrical devices that provide emergency power to loads when the input or main power source fails. UPS devices 110, 112, 114, 116 differ from standby or standby generators in that they provide near-instantaneous protection from input power interruptions by providing energy stored in batteries, supercapacitors, or flywheels. The on-battery runtime of most uninterruptible power supplies is relatively short (may be only a few minutes), but may be sufficient to start the standby power supply or properly shut down the protected equipment.

[0026] UPSs are typically used to protect hardware such as computers, data centers, telecommunications equipment, or other electrical equipment when unexpected power interruptions could cause injury, death, serious business interruptions, or data loss. UPS units range in size from units designed to protect a single computer without a video monitor (rated at approximately 200 volt-amperes) to larger units that power an entire data center or building.

[0027] The UPSs 110, 112, 114, and 116 supply power to one or more power distribution units (PDUs) 118, 120, 122, 124, 126, and 128. A PDU is a device with multiple outputs designed specifically to distribute power to racks of computer and network-connected equipment located within a data center. Data centers face challenges in power protection and management solutions, which is why many data centers rely on PDU monitoring to improve efficiency, uptime, and growth. For data center applications, power requirements are typically much greater than home or office-style power strips, with power inputs typically as high as 22 kilovolt-amperes (kVA) or greater. Most large data centers utilize PDUs with three-phase power inputs and one-phase power outputs. There are two main categories of PDUs: basic PDUs and intelligent (networked) PDUs, or iPDUs. A basic PDU simply provides a means of distributing power from an input to multiple outlets. Intelligent PDUs typically have an intelligence module that enables the PDU for remote management of power metering information, on / off control of power outlets, and / or alarms. Some advanced PDUs also allow users to manage external sensors for temperature, humidity, airflow, etc.

[0028] PDUs 118, 120, 122, 124, 126, and 128 may transfer power to rack PDUs, which in turn transfer power to individual electronic modules, such as data servers. The role of servers is to share data, as well as share resources and distribute work. Server computers may also host their own computer programs.

[0029] Each of the electrical racks receives redundant power sources. For example, UPSs 110, 112, 114, and 116 may each receive power from substations 102, 104 or from backup power source 106. Each of the PDUs may receive power from multiple UPSs. For example, PDU1 118 may receive power from UPS A 110 and UPS B. Each of the racks may receive power from multiple PDUs. For example, rack 1 139 receives power from PDU1 118 and PDU6 128. This redundancy allows power to the server devices without any single point of failure vulnerability.

[0030] Each electrical rack can be divided into multiple failure domains. For example, Rack 1 130 and Rack 4 136 are on failure domain 1. Rack 2 132 and Rack 5 138 are on failure domain 2, and Rack 3 134 and Rack 6 140 are on failure domain 3. In this way, a customer instance (e.g., a web service) can be propagated across three failure domains. Therefore, a problem with one or more racks in one failure domain will not affect services on other failure domains.

[0031] 2 illustrates an improved data center 200 according to an embodiment of the present disclosure. While having many of the same components of data center 100, improved data center 200 introduces electrical zones 240, 242, and 244.

[0032] As shown in FIG. 2 , the data center 200 has two power legs 252, 254. The power legs 252, 254 may include a substation 202, a backup power supply 204, and UPSs 210, 212, as described above with reference to the data center 100. The substation 202 and the backup power supply may feed a switch 208. The switch 208 may be a hitless transfer switch (STS) or an automatic transfer switch (ATS). A hitless transfer switch uses power semiconductors, such as silicon-controlled rectifiers (SCRs), to transfer the load between two sources. Because there are no mechanical moving parts, the transfer can be completed quickly, perhaps within a quarter cycle of the power frequency. A hitless transfer switch may be used when a reliable, independent power source is available and the load needs to be protected from interruptions, even for a few power frequency cycles, or from any surges or sags in the main power supply. Automatic transfer switches (ATS) are often installed where backup generators are deployed so that the generators can provide temporary power in the event of a utility power failure.

[0033] 2 shows two power legs 250. Power leg 250 supplies power to three PDUs 218, 220, and 222. Each of PDUs 218, 220, and 222 supplies power to multiple racks by electrical zone. For example, electrical zone 1 240 includes rack 1 230 and rack 2 232, both of which are in fault domain 1. Electrical zone 1 240 receives power from both PDU 1 218 and PDU 2 220.

[0034] Electrical zone 2 242 includes rack 2 234 and rack 4 236, both of which are in fault domain 2. Electrical zone 2 242 receives power from both PDU1 218 and PDU3 222.

[0035] Electrical zone 3 244 includes rack 5 237 and rack 6 238, both of which are in fault domain 3. Electrical zone 3 244 receives power from both PDU1 218 and PDU3 238.

[0036] The configuration shown in FIG. 2 enables both fault isolation and electrical isolation. For example, a customer may store instances across three failure domains (e.g., failure domain 1, failure domain 2, and failure domain 3). The loss of any one of PDUs 218, 220, and 222 would still provide failure domain redundancy due to electrical isolation. For example, if instances are stored in rack 1 230 (failure domain 1), rack 3 (failure domain 2), and rack 5 (failure domain 3). If PDU 218 fails, rack 1 230 receives power from PDU 2 220, rack 3 receives power from PDU 3 222, and rack 5 receives power from PDU 2 220 and PDU 3 222. Thus, in the event of a single PDU failure, failure domain redundancy is preserved.

[0037]

[0033] Figure 3 illustrates an exemplary data center 300 that does not employ the electrical isolation techniques described above. For example, UPS A 310, UPS B 312, UPS C 314, and UPS D 316 each supply redundant power to PDU1 318, PDU2 320, PDU3 322, PDU4 324, PDU5 326, and PDU6 328, as shown in Figure 3. In turn, PDU1 318, PDU2 320, PDU3 322, PDU4 324, PDU5 326, and PDU6 328 supply power to Rack1 330, Rack2 332, Rack3 334, Rack4 336, Rack5 338, and Rack6 340. The configuration of data center 300 illustrated in Figure 3 does not employ the concept of electrical isolation. PDU1 318 supplies primary power to rack 1 330 via line 342 and secondary power to rack 2 332 via line 346. PDU2 320 supplies primary power to rack 2 332 via line 348 and secondary power to rack 1 330 via line 344. PDU3 322 supplies primary power to rack 3 334 via line 350 and secondary power to rack 4 336 via line 354. PDU4 324 supplies primary power to rack 4 336 via line 356 and secondary power to rack 3 334 via line 352. PDU5 326 supplies primary power to rack 5 338 via line 358 and secondary power to rack 6 340 via line 362. PDU 6 provides primary power to rack 6 340 via line 364 and secondary power to rack 5 338 via line 366. In that way, all racks have duplicate power sources.

[0038] Figure 4 is a table illustrating the effect of the data center configuration 300 shown in Figure 3. If there is a double electrical failure, such as the failure of UPS A 310 and UPS B 312, the result is that Rack 1 330 and Rack 2 332 are offline. Because these racks provide redundancy for Failure Domain 1, if both UPS A 310 and UPS B 312 fail, the instances stored in Failure Domain 1 will be lost along with the failure of UPS A and UPS B. Rack 3 334 will also lose redundancy in power sources.

[0039] Figure 5 shows a first table illustrating a failover matrix for a data center employing the electrical isolation technology described above. The data center includes UPS A, UPS B, UPS C, and UPS D. Electrical Zone 1 receives power from UPS A and UPS B. Electrical Zone 2 receives power from UPS A and UPS C. Electrical Zone 3 receives power from UPS A and UPS D. Electrical Zone 4 receives power from UPS B and UPS C. Electrical Zone 5 receives power from UPS B and UPS D. Electrical Zone 1 receives power from UPS C and UPS D. Fault Domain 1, Fault Domain 2, and Fault Domain 3 are spread among Electrical Zone 1, Electrical Zone 2, and Electrical Zone 3. Scenario 1 illustrates a normal situation in which all UPSs are online. As a result, there is no impact from the failure, and all systems operate normally.

[0040] Figure 5 also shows allocated block volumes. Block volumes are a more scalable type of data storage than file storage. They use the Internet Small Computer System Interface (iSCSI) Ethernet protocol to provide features and performance similar to on-premises storage area networks (SANs) and are designed for security and durability throughout the data lifecycle. Block volumes provide customers with reliable, high-performance block storage designed to work with a range of virtual machines and bare metal instances. With built-in redundancy, block volumes are persistent and durable beyond the life of a virtual machine and can scale to 1 picobyte per compute instance. Block volumes use advanced, low-latency Non-Volatile Memory Express (NVMe) solid-state drives (SSDs) and non-blocking network connectivity on every host, which provides high input / output operations per second (IOPS) to Oracle compute services.

[0041] In Scenario 2, there is a single UPS electrical failure, with UPS AN offline. Note that the offline can be a system failure or when the UPS is intentionally taken offline for maintenance. The impact of the failure in Scenario 2 is a loss of power redundancy in three zones (e.g., specifically, electrical zone 1, electrical zone 2, and electrical zone 3). However, each of electrical zones 1, 2, and 3 may receive power from an alternate source. For example, electrical zone 1 receives power from UPS B. Electrical zone 2 receives power from UPS C, and electrical zone 3 receives power from UPS D. Electrical zones 4 through 6 are unaffected. Therefore, none of the instances would be affected.

[0042] Figure 6 is a second table illustrating a failover matrix for a data center using the electrical isolation techniques described above. In Scenario 3, there is a double electrical failure because UPS A and UPS B are offline. As shown in Figure 6, electrical zone 1 is offline because both UPS A and UPS B are offline. However, instances stored in servers supported by electrical zone 1 within failure domain 1 are replicated across electrical zone 4. Because UPS B is offline but UPS C is online, electrical zone 4 loses power redundancy. In Scenario 3, the impact of the failure is that electrical zone 1 is offline; there is a partial loss of failure domain 1 and block volume 1. In Scenario 3, only one failure domain and block volume will lose service.

[0043] In Scenario 4, there is a double electrical failure because UPS B and UPS D are offline. As illustrated in Figure 6, because UPS B and UPS D are both offline, electrical zone 5 is offline. However, instances stored on servers supported by electrical zone 5 in failure domain 1 are replicated across electrical zone 2. Electrical zones 1, 3, 4, and 6 lose power redundancy because UPS B is offline and UPS D is online. In Scenario 3, the impact of the failure is that electrical zone 5 is offline; there is a partial loss of failure domain 2 and block volume 1. In Scenario 4, only one failure domain and block volume will lose service.

[0044] In scenario 5, there is a double electrical failure because UPS C and UPS D are offline. As illustrated in Figure 6, electrical zone 6 is offline because both UPS C and UPS D are offline. However, instances stored on servers supported by electrical zone 6 in failure domain 3 are replicated across electrical zone 3. Electrical zones 2, 3, 4, and 5 lose power redundancy because UPS C and UPS D are offline. In scenario 3, the impact of the failure is that electrical zone 6 is offline; there is a partial loss of failure domain 3 and block volume 2. In scenario 5, only one failure domain and block volume will lose service.

[0045] FIG. 7 is a flowchart of an example process 700 related to a technique for generating a configuration for electrically isolating failure domains in a data center. In some implementations, one or more process blocks of FIG. 7 may be performed by a computer system (e.g., computer system 1300 shown in FIG. 13). In some implementations, one or more process blocks of FIG. 7 may be performed by another device or group of devices that are separate from or include the computer system. Additionally or alternatively, one or more process blocks of FIG. 7 may be performed by one or more components of computer system 1300, such as processing unit 1304, memory 1310, storage subsystem 1318, input / output subsystem 1308, bus 1302, and / or communication subsystem 1324.

[0046] 7, process 700 may include receiving a layout of a data center. The data center layout may identify the physical locations of a plurality of server racks, a plurality of power distribution units, and a plurality of power sources (block 710). For example, a computer system may receive a layout of a data center, as described above, where the layout of the data center identifies the physical locations of a plurality of server racks, a plurality of power distribution units, and a plurality of power sources.

[0047] 7, process 700 may include receiving a logical fault domain configuration for a datacenter, the logical fault domain configuration identifying virtual locations of multiple logical fault domains for distributing one or more compute instances, the compute instances running on separate physical hardware devices within the single logical fault domain based at least in part on the logical fault domain configuration (block 720). For example, a computer system may receive a logical fault domain configuration for a datacenter, as described above, the logical fault domain configuration identifying virtual locations of multiple logical fault domains for distributing one or more compute instances, the compute instances running on separate physical hardware devices within the single logical fault domain based at least in part on the logical fault domain configuration.

[0048] 7, process 700 may include determining a data center configuration by assigning at least some of the plurality of logical failure domains to at least some of the plurality of electrical zones, each electrical zone of the plurality of electrical zones providing a redundant power supply across the plurality of logical failure domains based at least in part on the occurrence of a power outage (block 730). For example, a computer system may determine a data center configuration, as described above, by assigning at least some of the plurality of logical failure domains to at least some of the plurality of electrical zones, each electrical zone of the plurality of electrical zones providing a redundant power supply across the plurality of logical failure domains based at least in part on the occurrence of a power outage.

[0049] The value of the electrical zone is a number; the combination of the redundant number of "electrical zones" will be different at different locations. Mathematically, the number of combinations can be expressed by the following formula: C(n,r)=n!(nr)!r! where n is the number of power legs and r is the number of branch circuits required per rack.

[0050] For a data center with four separate UPS output feeder circuits (collectively labeled A, B, C, and D), this represents six unique combinations of "electrical zones" for racks requiring two branch circuits. The following matrix in Table 3 below can be used to determine and assign fault domains:

[0051] [Table 3]

[0052] Note: The total number of electrical zones within each Availability Domain (AD) will vary by location. An AD is one of three types of data centers: AD, Point of Presence (POP), and In-Line Amplifier (ILA). Because ADs are physically isolated from each other and do not share resources (e.g., power, cooling, etc.), ADs do not have correlated failure modes. A region consists of one or more ADs. Within a region, all member ADs are interconnected with a low-latency, high-bandwidth network.

[0053] The total number will depend on the number and configuration of UPS systems. This is more related to the quantity and size of the UPS, rather than a function of the tier rating. For example, a highly distributed data center may have six or more UPS systems per suite. This would present up to 15 unique electrical zones in a single data center, as shown in Table 4 below.

[0054] [Table 4]

[0055] Additionally, service teams may adjust their provisioning processes to query storekeeper location data to determine electrical zones (and respective compute fault domains). These instance label values ​​will be inherited from the storekeeper. Once the instances and fault domains are associated, as shown in Table 5, no further modifications to provisioning are expected.

[0056] [Table 5]

[0057] The disclosed technology utilizes capacity metrics published to a data warehouse. For each selected incoming platform type, the disclosed technology queries the data warehouse to determine which failure domain capacity pool has the fewest available instances. The disclosed technology then performs rack location allocation so that capacity is provisioned where needed.

[0058] If the failure domain label is lost during Host Provisioning System (HOPS) reprovisioning, any instances that require reprovisioning or repooling will need to be relabeled.

[0059] An additional layer of complexity is introduced with Oracle Cloud Infrastructure's current footprint of multiple data center rooms within the same building shell. This introduces a situation where multiple rooms may share critical infrastructure components. For this reason, the disclosed technology must be able to determine whether a given electrical zone is room-specific or shared within the building. Each storekeeper location entry will also contain the following objects:

[0060] [Table 6]

[0061] 7, process 700 may include transmitting the data center configuration to a device for display (block 740). For example, a computer system may transmit the data center configuration to a device for display, as described above.

[0062] Process 700 may include additional implementations, such as any single implementation or any combination of implementations described below and / or in connection with one or more other processes described elsewhere herein.

[0063] In a first implementation, the data center configuration is determined by dividing the power supply for the data center into an equal, separate set of power distribution groups.

[0064] In a second implementation, alone or in combination with the first implementation, a data center configuration may include a configuration in which each set of power distribution groups has N non-shared electrical paths from racks for logical fault domains within the data center upstream to utility power lines, where N conforms to the data center redundancy properties.

[0065] In a third implementation, alone or in combination with one or more of the first and second implementations, a data center configuration enables physical facility maintenance to be performed in one electrical zone without affecting other electrical zones while maintaining logical fault domain redundancy.

[0066] In a fourth implementation, alone or in combination with one or more of the first through third implementations, a data center configuration allows for power equipment failure in one electrical zone without affecting other electrical zones while maintaining logical fault domain redundancy.

[0067] In a fifth implementation, alone or in combination with one or more of the first through fourth implementations, the physical hardware within the logical fault domain has independent and redundant power supplies.

[0068] In a sixth implementation, alone or in combination with one or more of the first through fifth implementations, an electrical zone includes a grouping of rack locations within a data center whose upstream electrical distribution is supplied by a unique combination of two active power feeds.

[0069] 7 illustrates example blocks of process 700, in some implementations, process 700 may include additional blocks, fewer blocks, different blocks, or blocks arranged differently than those shown in FIG 7. Additionally or alternatively, two or more of the blocks of process 700 may be performed in parallel.

[0070] Figure 8 is a block diagram of a data center according to at least one embodiment. Figures 10 and 11 show trusted app subnets 1062, 1162 with VMs 1066(1), (2), and (n), 11662(1), (2), and (n). Figure 8 shows VM 802 in the context of failure domain 804 and electrical zone 806.

[0071] Figure 8 shows three availability domains 808-1, 808-2, and 808-3. Cloud infrastructure can be hosted in regions and availability domains. A region is a localized geographic area, and an availability domain is one or more data centers located within a region. Availability domains are isolated from each other, fault-tolerant, and highly unlikely to fail simultaneously.

[0072] Each availability domain 808 may include one or more compartments, which may include compartment A 810, compartment B 812, and compartment C 814. Compartment A 810 may include multiple bare metal (BM) Type 1 machines 816. The number and configuration of data center 800, including the number and configuration of various compartments, are for illustrative purposes only and not limiting. Bare metal machines 816 allow customers to run high-performance, latency-sensitive, specialized, and traditional workloads directly on dedicated server hardware—just as they would on-premises. Bare metal machines 816 are ideal for workloads that need to run in a non-virtualized environment. Bare metal machines 816 can be managed within a secure virtual cloud network (VCN), giving customers security, isolation, and management capabilities by default. Network connectivity is easily extended to access any adjacent cloud infrastructure services. Bare metal machines 816 provide customers with isolation, visibility, and control over dedicated servers. The Bare Metal Machine 816 can support applications that require high core counts, large amounts of memory, and high bandwidth, scaling up to 128 cores (the most in the industry), 2TB of RAM, and 1PB of block storage.

[0073] Compartment B may include multiple virtual machines 818. A virtual machine (VM) 818 is an emulation of a computer system. A virtual machine 818 may be based on a computer architecture and may provide the functionality of a physical computer. An implementation of a virtual machine 818 may include specialized hardware, software, or a combination.

[0074] Compartment C may contain one or more containers, as described above for containers 1071(1)-(N) in Figure 10. Container 820 may store data, as described above.

[0075] 8 shows how each of the BM machines 816, VMs 818, and containers 820 may be organized by failure domains 802 and in various electrical zones 806. In this manner, the data center 800 provides redundancy across both failure domains 802 and electrical zones 806.

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

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

[0078] In most cases, the cloud computing model will require the participation of a cloud provider, which may be, but need not be, a third-party service that specializes in providing (e.g., offering, renting, selling) IaaS. Entities may also choose to deploy private clouds and become their own provider of infrastructure services.

[0079] In some examples, IaaS deployment is the process of putting a new application or a new version of an application onto a prepared application server, etc. It may also include the process of provisioning the server (e.g., installing libraries, daemons, etc.), which is often managed below the hypervisor layer (e.g., server, storage, network hardware, and virtualization) by the cloud provider. Thus, the customer may be responsible for handling (e.g., on self-service virtual machines (which may be launched on demand, for example)), middleware, and / or application deployment, etc.

[0080] In some instances, IaaS provisioning may refer to obtaining computers or virtual hosts for use and even installing required libraries or services on them. In most cases, deployment does not include provisioning, which may need to be performed first.

[0081] In some cases, IaaS provisioning presents two distinct problems. First, there is the initial challenge of provisioning an initial set of infrastructure before anything works. Second, there is the challenge of evolving the existing infrastructure (e.g., adding new services, modifying services, removing services, etc.) once everything is provisioned. In some cases, these two challenges may be addressed by allowing the configuration of the infrastructure to be defined declaratively. In other words, the infrastructure (e.g., what components are needed and how they interact) may be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., what resources depend on which resources and how they work together with each other) may be described declaratively. In some examples, once the topology is defined, workflows may be generated to create and / or manage the different components described in the configuration files.

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

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

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

[0085] VCN 906 may include a local peering gateway (LPG) 910, which may be communicatively coupled to a secure shell (SSH) VCN 912 via an LPG 910 included in SSH VCN 912. SSH VCN 912 may include an SSH subnet 914, which may be communicatively coupled to a control plane VCN 916 via an LPG 910 included in control plane VCN 916. SSH VCN 912 may also be communicatively coupled to a data plane VCN 918 via LPG 910. The control plane VCN 916 and the data plane VCN 918 may be included in a service tenancy 919, which may be owned and / or operated by the IaaS provider.

[0086] The control plane VCN 916 may include a control plane demilitarized zone (DMZ) tier 920 that serves as a perimeter network (e.g., a portion of the enterprise network between the enterprise intranet and an external network). DMZ-based servers may have limited responsibilities and help keep security breaches contained. Additionally, the DMZ tier 920 may include one or more load balancer (LB) subnets 922, a control plane app tier 924 that may include an app subnet 926, and a control plane data tier 928 that may include a database (DB) subnet 930 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 922 included in the control plane DMZ tier 920 may be communicatively coupled to the app subnet 926 included in the control plane app tier 924 and to an Internet gateway 934 that may be included in the control plane VCN 916, and the app subnet 926 may be communicatively coupled to the DB subnet 930, a service gateway 936, and a network address translation (NAT) gateway 938 included in the control plane data tier 928. The control plane VCN 916 may include a service gateway 936 and a NAT gateway 938.

[0087] The control plane VCN 916 may include a data plane mirror app layer 940, which may include an app subnet 926. The app subnet 926 included in the data plane mirror app layer 940 may include a virtual network interface controller (VNIC) 942, which may run a compute instance 944. The compute instance 944 may communicatively couple the app subnet 926 of the data plane mirror app layer 940 to the app subnet 926, which may be included in the data plane app layer 946.

[0088] The data plane VCN 918 may include a data plane app layer 946, a data plane DMZ layer 948, and a data plane data layer 950. The data plane DMZ layer 948 may include a LB subnet 922 that may be communicatively coupled to an app subnet 926 of the data plane app layer 946 and an internet gateway 934 of the data plane VCN 918. The app subnet 926 may be communicatively coupled to a service gateway 936 of the data plane VCN 918 and a NAT gateway 938 of the data plane VCN 918. The data plane data layer 950 may also include a DB subnet 930 that may be communicatively coupled to the app subnet 926 of the data plane app layer 946.

[0089] The internet gateways 934 of the control plane VCNs 916 and data plane VCNs 918 may be communicatively coupled to a metadata management service 952, which may be communicatively coupled to the public internet 954. The public internet 954 may be communicatively coupled to NAT gateways 938 of the control plane VCNs 916 and data plane VCNs 918. The service gateways 936 of the control plane VCNs 916 and data plane VCNs 918 may be communicatively coupled to cloud services 956.

[0090] In some examples, a service gateway 936 of the control plane VCN 916 or the data plan VCN 918 may make an application programming interface (API) call to a cloud service 956 without traversing the public internet 954. The API call from the service gateway 936 to the cloud service 956 may be one-way: the service gateway 936 may make the API call to the cloud service 956, and the cloud service 956 may send the requested data to the service gateway 936. However, the cloud service 956 may not initiate the API call to the service gateway 936.

[0091] In some examples, secure host tenancy 904 can connect directly to service tenancy 919, which may otherwise be isolated. Secure host subnet 908 may communicate with SSH subnet 914 through LPG 910, which may allow bidirectional communication through otherwise isolated systems. Connecting secure host subnet 908 to SSH subnet 914 may give secure host subnet 908 access to other entities within service tenancy 919.

[0092] The control plane VCN 916 may enable users of the service tenancy 919 to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 916 may be deployed or otherwise used in the data plane VCN 918. In some examples, the control plane VCN 916 may be isolated from the data plane VCN 918, and the data plane mirror app layer 940 of the control plane VCN 916 may communicate with the data plane app layer 946 of the data plane VCN 918 via a VNIC 942, which may be included in the data plane mirror app layer 940 and the data plane app layer 946.

[0093] In some examples, a user or customer of the system may make a request, such as a create, read, update, or delete (CRUD) operation, via the public internet 954, which may communicate the request to a metadata management service 952. The metadata management service 952 may communicate the request to the control plane VCN 916 via an internet gateway 934. The request may be received by a LB subnet 922 included in the control plane DMZ layer 920. The LB subnet 922 may determine that the request is valid, and in response to this determination, the LB subnet 922 may send the request to an app subnet 926 included in the control plane app layer 924. If the request is validated and requires a call to the public internet 954, the call to the public internet 954 may be sent to a NAT gateway 938, which may make the call to the public internet 954. Memory that may be desired to be stored with the request may be stored in the DB subnet 930.

[0094] In some examples, the data plane mirror app layer 940 may facilitate direct communication between the control plane VCN 916 and the data plane VCN 918. For example, it may be desired that a configuration change, update, or other suitable modification be applied to resources included in the data plane VCN 918. Via the VNIC 942, the control plane VCN 916 may communicate directly with the resources included in the data plane VCN 918, thereby performing the change, update, or other suitable modification to the configuration.

[0095] In some embodiments, the control plane VCN 916 and the data plane VCN 918 may be included in the service tenancy 919. In this case, a user or customer of the system may not own or operate either the control plane VCN 916 or the data plane VCN 918. Instead, an IaaS provider may own or operate the control plane VCN 916 and the data plane VCN 918, both of which may be included in the service tenancy 919. This embodiment may enable network isolation that may prevent a user or customer from interacting with the resources of other users or other customers. This embodiment may also allow a user or customer of the system to store databases privately without having to rely on the public internet 954 for storage, which may not have the desired level of security.

[0096] In another embodiment, the LB subnet 922 included in the control plane VCN 916 may be configured to receive signals from the service gateway 936. In this embodiment, the control plane VCN 916 and the data plane VCN 918 may be configured to be called by customers of the IaaS provider without calling the public internet 954. Customers of the IaaS provider may desire this embodiment because databases used by the customers may be stored on the service tenancy 919, which may be controlled by the IaaS provider and isolated from the public internet 954.

[0097] 10 is a block diagram 1000 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1002 (e.g., service operator 902 of FIG. 9 ) may be communicatively coupled to a secure host tenancy 1004 (e.g., secure host tenancy 904 of FIG. 9 ), which may include a virtual cloud network (VCN) 1006 (e.g., VCN 906 of FIG. 9 ) and a secure host subnet 1008 (e.g., secure host subnet 908 of FIG. 9 ). VCN 1006 may include a local peering gateway (LPG) 1010 (e.g., LPG 910 of FIG. 9 ), which may be communicatively coupled to a secure shell (SSH) VCN 1012 (e.g., SSH VCN 912 of FIG. 9 ) via an LPG 910 included in SSH VCN 1012. SSH VCN 1012 may include an SSH subnet 1014 (e.g., SSH subnet 914 in FIG. 9 ), and SSH VCN 1012 may be communicatively coupled to a control plane VCN 1016 (e.g., control plane VCN 916 in FIG. 9 ) via an LPG 1010 included in control plane VCN 1016. Control plane VCN 1016 may be included in a service tenancy 1019 (e.g., service tenancy 919 in FIG. 9 ), and data plane VCN 1018 (e.g., data plane VCN 918 in FIG. 9 ) may be included in a customer tenancy 1021, which may be owned or operated by a user or customer of the system.

[0098] The control plane VCN 1016 may include a control plane DMZ tier 1020 (e.g., control plane DMZ tier 920 of FIG. 9 ) that may include a LB subnet 1022 (e.g., LB subnet 922 of FIG. 9 ), a control plane app tier 1024 (e.g., control plane app tier 924 of FIG. 9 ) that may include an app subnet 1026 (e.g., app subnet 926 of FIG. 9 ), and a control plane data tier 1028 (e.g., control plane data tier 928 of FIG. 9 ) that may include a database (DB) subnet 1030 (e.g., similar to DB subnet 930 of FIG. 9 ). The LB subnet 1022 included in the control plane DMZ layer 1020 may be communicatively coupled to an app subnet 1026 included in the control plane app layer 1024 and to an Internet gateway 1034 (e.g., Internet gateway 934 in FIG. 9 ) that may be included in the control plane VCN 1016, and the app subnet 1026 may be communicatively coupled to a DB subnet 1030 included in the control plane data layer 1028, to a service gateway 1036 (e.g., service gateway in FIG. 9 ), and to a network address translation (NAT) gateway 1038 (e.g., NAT gateway 938 in FIG. 9 ). The control plane VCN 1016 may include the service gateway 1036 and the NAT gateway 1038.

[0099] The control plane VCN 1016 may include a data plane mirror app layer 1040 (e.g., data plane mirror app layer 940 of FIG. 9 ), which may include an app subnet 1026. The app subnet 1026 included in the data plane mirror app layer 1040 may include a virtual network interface controller (VNIC) 1042 (e.g., VNIC 942) that may run a compute instance 1044 (e.g., similar to compute instance 944 of FIG. 9 ). The compute instance 1044 may facilitate communication between the app subnet 1026 of the data plane mirror app layer 1040 and the app subnet 1026 that may be included in the data plane app layer 1046 (e.g., data plane app layer 946 of FIG. 9 ), via the VNIC 1042 included in the data plane mirror app layer 1040 and the VNIC 1042 included in the data plane app layer 1046.

[0100] The internet gateway 1034 included in the control plane VCN 1016 may be communicatively coupled to a metadata management service 1052 (e.g., metadata management service 952 of FIG. 9 ), which may be communicatively coupled to the public internet 1054 (e.g., public internet 954 of FIG. 9 ). The public internet 1054 may be communicatively coupled to a NAT gateway 1038 included in the control plane VCN 1016. The service gateway 1036 included in the control plane VCN 1016 may be communicatively coupled to cloud services 1056 (e.g., cloud services 956 of FIG. 9 ).

[0101] In some examples, the data plane VCN 1018 may be included in the customer tenancy 1021. In this case, the IaaS provider may provide a control plane VCN 1016 for each customer, and the IaaS provider may set up a unique compute instance 1044, included in the service tenancy 1019, for each customer. Each compute instance 1044 may enable communication between the control plane VCN 1016 included in the service tenancy 1019 and the data plane VCN 1018 included in the customer tenancy 1021. The compute instance 1044 may enable resources provisioned in the control plane VCN 1016 included in the service tenancy 1019 to be deployed or otherwise used in the data plane VCN 1018 included in the customer tenancy 1021.

[0102] In another example, a customer of the IaaS provider may have a database residing in customer tenancy 1021. In this example, control plane VCN 1016 may include a data plane mirrored app tier 1040, which may include app subnet 1026. The data plane mirrored application tier 1040 may reside within the data plane VCN 1018, but the data plane mirrored application tier 1040 may not reside within the data plane VCN 1018. That is, the data plane mirrored application tier 1040 may have access to customer tenancy 1021, but the data plane mirrored application tier 1040 may not reside within the data plane VCN 1018 or be owned or operated by the IaaS provider's customer. The data plane mirrored application tier 1040 may be configured to make calls to the data plane VCN 1018, but may not be configured to make calls to any entities included in the control plane VCN 1016. A customer may desire to deploy or otherwise use resources in the data plane VCN 1018 that are provisioned in the control plane VCN 1016, and the data plane mirror application layer 1040 may facilitate the desired deployment or other use of the customer's resources.

[0103] In some embodiments, the IaaS provider's customer may apply filters to the data plane VCN 1018. In this embodiment, the customer may determine what the data plane VCN 1018 can access, and the customer may restrict access from the data plane VCN 1018 to the public internet 1054. The IaaS provider may not be able to filter or otherwise control the data plane VCN 1018's access to any external networks or databases. Applying filters and controls by the customer on the data plane VCN 1018 included in the customer tenancy 1021 can help isolate the data plane VCN 1018 from other customers and the public internet 1054.

[0104] In some embodiments, cloud services 1056 may be invoked by the service gateway 1036 to access services that may not reside on the public internet 1054, the control plane VCN 1016, or the data plane VCN 1018. The connection between the cloud services 1056 and the control plane VCN 1016 or the data plane VCN 1018 may not be live or continuous. The cloud services 1056 may reside on different networks owned or operated by the IaaS provider. The cloud services 1056 may be configured to receive calls from the service gateway 1036 and may not be configured to receive calls from the public internet 1054. Some cloud services 1056 may be isolated from other cloud services 1056, and the control plane VCN 1016 may be isolated from cloud services 1056 that may not be in the same region as the control plane VCN 1016. For example, the control plane VCN 1016 may be located in “Region 1,” and cloud service “Deployment 8” may be located in Region 1 and Region 2. If a call to a deployment 8 is made by a service gateway 1036 included in a control plane VCN 1016 located in Region 1, the call may be transmitted to the deployment 8 in Region 1. In this example, the control plane VCN 1016, or the deployment 8 in Region 1, may not be communicatively coupled to or otherwise in communication with the deployment 8 in Region 2.

[0105] 11 is a block diagram 1100 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1102 (e.g., service operator 902 of FIG. 9 ) may be communicatively coupled to a secure host tenancy 1104 (e.g., secure host tenancy 904 of FIG. 9 ), which may include a virtual cloud network (VCN) 1106 (e.g., VCN 906 of FIG. 9 ) and a secure host subnet 1108 (e.g., secure host subnet 908 of FIG. 9 ). VCN 1106 may include an LPG 1110 (e.g., LPG 910 of FIG. 9 ), which may be communicatively coupled to an SSH VCN 1112 via an LPG 1110 included in SSH VCN 1112 (e.g., SSH VCN 912 of FIG. 9 ). SSH VCN 1112 may include an SSH subnet 1114 (e.g., SSH subnet 914 in FIG. 9 ), which may be communicatively coupled to a control plane VCN 1116 via an LPG 1110 included in the control plane VCN 1116 (e.g., control plane VCN 916 in FIG. 9 ) and to a data plane VCN 1118 via an LPG 1110 included in the data plane VCN 1118 (e.g., data plane 918 in FIG. 9 ). The control plane VCN 1116 and the data plane VCN 1118 may be included in a service tenancy 1119 (e.g., service tenancy 919 in FIG. 9 ).

[0106] The control plane VCN 1116 may include a control plane DMZ tier 1120 (e.g., control plane DMZ tier 920 of FIG. 9 ) that may include a load balancer (LB) subnet 1122 (e.g., LB subnet 922 of FIG. 9 ), a control plane app tier 1124 (e.g., control plane app tier 924 of FIG. 9 ) that may include an app subnet 1126 (e.g., similar to app subnet 926 of FIG. 9 ), and a control plane data tier 1128 (e.g., control plane data tier 928 of FIG. 9 ) that may include a DB subnet 1130. The LB subnet 1122 included in the control plane DMZ tier 1120 may be communicatively coupled to an app subnet 1126 included in the control plane app tier 1124 and to an Internet gateway 1134 (e.g., Internet gateway 934 in FIG. 9 ) that may be included in the control plane VCN 1116, and the app subnet 1126 may be communicatively coupled to a DB subnet 1130 included in the control plane data tier 1128, as well as to a service gateway 1136 (e.g., service gateway in FIG. 9 ) and a network address translation (NAT) gateway 1138 (e.g., NAT gateway 938 in FIG. 9 ). The control plane VCN 1116 may include the service gateway 1136 and the NAT gateway 1138.

[0107] Data plane VCN 1118 may include a data plane app layer 1146 (e.g., data plane app layer 946 in FIG. 9 ), a data plane DMZ layer 1148 (e.g., data plane DMZ layer 948 in FIG. 9 ), and a data plane data layer 1150 (e.g., data plane data layer 950 in FIG. 9 ). Data plane DMZ layer 1148 may include LB subnet 1122, which may be communicatively coupled to trusted app subnet 1160 and untrusted app subnet 1162 of data plane app layer 1146 and to an Internet gateway 1134 included in data plane VCN 1118. Trusted app subnet 1160 may be communicatively coupled to service gateway 1136 included in data plane VCN 1118, NAT gateway 1138 included in data plane VCN 1118, and DB subnet 1130 included in data plane data layer 1150. The untrusted app subnet 1162 may be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118 and a DB subnet 1130 included in the data plane data layer 1150. The data plane data layer 1150 may include a DB subnet 1130 that may be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118.

[0108] The untrusted app subnet 1162 may include one or more primary VNICs 1164(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 1166(1)-(N). Each tenant VM 1166(1)-(N) may be communicatively coupled to a respective app subnet 1167(1)-(N), which may be included in a respective container egress VCN 1168(1)-(N), which may be included in a respective customer tenancy 1170(1)-(N). Each secondary VNIC 1172(1)-(N) may facilitate communication between the untrusted app subnet 1162 included in the data plane VCN 1118 and the app subnet included in the container egress VCN 1168(1)-(N). Each container egress VCN 1168(1)-(N) may include a NAT gateway 1138, which may be communicatively coupled to the public internet 1154 (e.g., public internet 954 in FIG. 9 ).

[0109] An internet gateway 1134 included in the control plane VCN 1116 and in the data plane VCN 1118 may be communicatively coupled to a metadata management service 1152 (e.g., metadata management system 952 of FIG. 9 ), which may be communicatively coupled to the public internet 1154. The public internet 1154 may be communicatively coupled to a NAT gateway 1138 included in the control plane VCN 1116 and in the data plane VCN 1118. A service gateway 1136 included in the control plane VCN 1116 and in the data plane VCN 1118 may be communicatively coupled to cloud services 1156.

[0110] In some embodiments, data plane VCN 1118 may be integrated with customer tenancy 1170. This integration may be useful or desirable for an IaaS provider's customer in some cases, such as when they may need support when running code. A customer may provide code to run that may be disruptive, may communicate with other customer resources, or may otherwise cause undesirable effects. In response, the IaaS provider may determine whether to run the code provided to the IaaS provider by the customer.

[0111] In some examples, a customer of an IaaS provider may grant temporary network access to the IaaS provider and request that a function be attached to a data plane layer app 1146. The code to perform the function may run in a VM 1166(1)-(N) and may not be configured to run anywhere else on the data plane VCN 1118. Each VM 1166(1)-(N) may be connected to one customer tenancy 1170. Each container 1171(1)-(N) contained in a VM 1166(1)-(N) may be configured to run code. In this case, there may be double isolation (e.g., containers 1171(1)-(N) may execute code and be included in at least VMs 1166(1)-(N) included in untrusted app subnet 1162), which may help prevent incorrect or otherwise unwanted code from damaging the IaaS provider's network or the network of a different customer. Containers 1171(1)-(N) may be communicatively coupled to customer tenancy 1170 and may be configured to send or receive data to or from customer tenancy 1170. Containers 1171(1)-(N) may not be configured to send or receive data to or from any other entity in data plane VCN 1118. Once the code execution is complete, the IaaS provider may kill or otherwise discard containers 1171(1)-(N).

[0112] In some embodiments, trusted app subnet 1160 may execute code that may be owned or operated by the IaaS provider. In this embodiment, trusted app subnet 1160 may be communicatively coupled to DB subnet 1130 and may be configured to perform CRUD operations within DB subnet 1130. Untrusted app subnet 1162 may be communicatively coupled to DB subnet 1130, but in this embodiment, the untrusted app subnet may be configured to perform read operations within DB subnet 1130. Containers 1171(1)-(N) that may be included in each customer's VMs 1166(1)-(N) and that may execute code from that customer may not be communicatively coupled to DB subnet 1130.

[0113] In other embodiments, the control plane VCN 1116 and the data plane VCN 1118 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 1116 and the data plane VCN 1118. However, communication may occur indirectly through at least one method. An LPG 1110 may be established by the IaaS provider to facilitate communication between the control plane VCN 1116 and the data plane VCN 1118. In another example, the control plane VCN 1116 or the data plane VCN 1118 may make a call to a cloud service 1156 through the service gateway 1136. For example, a call from the control plane VCN 1116 to the cloud service 1156 may include a request for a service that may communicate with the data plane VCN 1118.

[0114] 12 is a block diagram 1200 illustrating another exemplary pattern of an IaaS architecture, according to at least one embodiment. A service operator 1202 (e.g., service operator 902 in FIG. 9 ) may be communicatively coupled to a secure host tenancy 1204 (e.g., secure host tenancy 904 in FIG. 9 ), which may include a virtual cloud network (VCN) 1206 (e.g., VCN 906 in FIG. 9 ) and a secure host subnet 1208 (e.g., secure host subnet 908 in FIG. 9 ). VCN 1206 may include an LPG 1210 (e.g., LPG 910 in FIG. 9 ), which may be communicatively coupled to an SSH VCN 1212 via an LPG 1210 included in SSH VCN 1212 (e.g., SSH VCN 912 in FIG. 9 ). SSH VCN 1212 may include SSH subnet 1214 (e.g., SSH subnet 914 in FIG. 9 ), which may be communicatively coupled to control plane VCN 1216 via LPG 1210 included in control plane VCN 1216 (e.g., control plane VCN 916 in FIG. 9 ) and to data plane VCN 1218 via LPG 1210 included in data plane VCN 1218 (e.g., data plane 918 in FIG. 9 ). Control plane VCN 1216 and data plane VCN 1218 may be included in service tenancy 1219 (e.g., service tenancy 919 in FIG. 9 ).

[0115] The control plane VCN 1216 may include a control plane DMZ layer 1220 (e.g., control plane DMZ layer 920 of FIG. 9 ) that may include a LB subnet 1222 (e.g., LB subnet 922 of FIG. 9 ), a control plane app layer 1224 (e.g., control plane app layer 924 of FIG. 9 ) that may include an app subnet 1226 (e.g., app subnet 926 of FIG. 9 ), and a control plane data layer 1228 (e.g., control plane data layer 928 of FIG. 9 ) that may include a DB subnet 1230 (e.g., DB subnet 1130 of FIG. 11 ). LB subnet 1222 included in control plane DMZ tier 1220 may be communicatively coupled to app subnet 1226 included in control plane app tier 1224 and to an Internet gateway 1234 (e.g., Internet gateway 934 in FIG. 9 ) that may be included in control plane VCN 1216, and app subnet 1226 may be communicatively coupled to DB subnet 1230 included in control plane data tier 1228 and to a service gateway 1236 (e.g., service gateway in FIG. 9 ) and a network address translation (NAT) gateway 1238 (e.g., NAT gateway 938 in FIG. 9 ). Control plane VCN 1216 may include service gateway 1236 and NAT gateway 1238.

[0116] Data plane VCN 1218 may include a data plane app layer 1246 (e.g., data plane app layer 946 in FIG. 9 ), a data plane DMZ layer 1248 (e.g., data plane DMZ layer 948 in FIG. 9 ), and a data plane data layer 1250 (e.g., data plane data layer 950 in FIG. 9 ). Data plane DMZ layer 1248 may include a LB subnet 1222 that may be communicatively coupled to a trusted app subnet 1260 (e.g., trusted app subnet 1160 in FIG. 11 ) and an untrusted app subnet 1262 (e.g., untrusted app subnet 1162 in FIG. 11 ) of data plane app layer 1246 and to an Internet gateway 1234 included in data plane VCN 1218. Trusted app subnet 1260 may be communicatively coupled to service gateway 1236 included in data plane VCN 1218, NAT gateway 1238 included in data plane VCN 1218, and DB subnet 1230 included in data plane data layer 1250. Untrusted app subnet 1262 may be communicatively coupled to service gateway 1236 included in data plane VCN 1218 and DB subnet 1230 included in data plane data layer 1250. Data plane data layer 1250 may include DB subnet 1230, which may be communicatively coupled to service gateway 1236 included in data plane VCN 1218.

[0117] The untrusted app subnet 1262 may include primary VNICs 1264(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 1266(1)-(N) residing within the untrusted app subnet 1262. Each tenant VM 1266(1)-(N) may execute code in a respective container 1267(1)-(N), which may be communicatively coupled to an app subnet 1226, which may be included in a data plane app tier 1246, which may be included in a container egress VCN 1268. Each secondary VNIC 1272(1)-(N) may facilitate communication between the untrusted app subnet 1262, which is included in the data plane VCN 1218, and the app subnet included in the container egress VCN 1268. The container egress VCN may include a NAT gateway 1238, which may be communicatively coupled to the public internet 1254 (e.g., public internet 954 of FIG. 9 ).

[0118] An internet gateway 1234 included in the control plane VCN 1216 and in the data plane VCN 1218 may be communicatively coupled to a metadata management service 1252 (e.g., metadata management system 952 of FIG. 9 ), which may be communicatively coupled to the public internet 1254. The public internet 1254 may be communicatively coupled to a NAT gateway 1238 included in the control plane VCN 1216 and in the data plane VCN 1218. A service gateway 1236 included in the control plane VCN 1216 and in the data plane VCN 1218 may be communicatively coupled to cloud services 1256.

[0119] In some examples, the pattern illustrated by the architecture of block diagram 1200 in FIG. 12 may be considered an exception to the pattern illustrated by the architecture of block diagram 1100 in FIG. 11 , which may be desirable for an IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected area). Each container 1267(1)-(N) contained in VM 1266(1)-(N) for each customer may be accessed by the customer in real time. The containers 1267(1)-(N) may be configured to make calls to each secondary VNIC 1272(1)-(N) contained in app subnet 1226 of data plane app tier 1246, which may be contained in container egress VCN 1268. The secondary VNICs 1272(1)-(N) may send the calls to NAT gateway 1238, which may send the calls to the public Internet 1254. In this example, containers 1267(1)-(N) that may be accessed in real time by a customer may be isolated from control plane VCN 1216 and may be isolated from other entities included in data plane VCN 1218. Containers 1267(1)-(N) may also be isolated from resources from other customers.

[0120] In another example, a customer may invoke cloud service 1256 using container 1267(1)-(N). In this example, the customer may execute code within container 1267(1)-(N) that requests a service from cloud service 1256. Container 1267(1)-(N) may send the request to secondary VNICs 1272(1)-(N), which may send the request to a NAT gateway, which may send the request to public Internet 1254. Public Internet 1254 may send the request to LB subnet 1222, which is included in control plane VCN 1216, via Internet gateway 1234. In response to determining that the request is valid, LB subnet 1226 may send the request to app subnet 1226, which may send the request to cloud service 1256 via service gateway 1236.

[0121] It should be appreciated that the illustrated IaaS architectures 900, 1000, 1100, 1200 may have components other than those shown. Additionally, the illustrated embodiments are only a few examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In some other embodiments, the IaaS systems may have more or fewer components than those shown, may combine two or more components, or may have a different configuration or arrangement of components.

[0122] In one embodiment, the IaaS system described herein may include a suite of application, middleware, and database service offerings that are self-service, subscription-based, elastically scalable, reliable, highly available, and securely delivered to customers. An example of such an IaaS system is Oracle Cloud Infrastructure (OCI), offered by the present assignee.

[0123] 13 illustrates an exemplary computer system 1300 upon which various embodiments may be implemented. The computer system 1300 may be used to implement any of the computer systems described above. As shown in the figure, the computer system 1300 includes a processing unit 1304 that communicates with several peripheral subsystems via a bus subsystem 1302. These peripheral subsystems may include a processing acceleration unit 1306, an input / output (I / O) subsystem 1308, a storage subsystem 1318, and a communication subsystem 1324. The storage subsystem 1318 includes a tangible computer-readable storage medium 1322 and a system memory 1310.

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

[0125] Processing unit 1304 may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers) and controls the operation of computer system 1300. One or more processors may be included in processing unit 1304. These processors may include single-core processors or multi-core processors. In particular embodiments, processing unit 1304 may be implemented as one or more independent processing units 1332 and / or 1334, with each processing unit including a single-core processor or a multi-core processor. In other embodiments, processing unit 1304 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0126] In various embodiments, processing unit 1304 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. At any given time, some or all of the program code to be executed may reside on processing unit 1304 and / or on storage subsystem 1318. Through suitable programming, processing unit 1304 may provide the various functionality described above. Computer system 1300 may further include a processing acceleration unit 1306, which may include a digital signal processor (DSP), special purpose processor, etc.

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

[0128] 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 audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. In addition, user interface input devices may include medical imaging input devices, such as computed tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound machines, etc. User interface input devices may also include audio input devices, such as MIDI keyboards, digital musical instruments, etc.

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

[0130] Computer system 1300 may include a storage subsystem 1318 that includes software elements currently shown as located in system memory 1310. System memory 1310 may store program instructions that are loadable and executable on processing unit 1304, as well as data generated during the execution of these programs.

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

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

[0133] Storage subsystem 1318 may also include computer-readable storage medium reader 1320, which may be further connected to computer-readable storage medium 1322. Along with, and optionally in combination with, system memory 1310, computer-readable storage medium 1322 may collectively represent remote, local, fixed, and / or removable storage devices plus storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information.

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

[0135] By way of example, the computer-readable storage medium 1322 may include a hard disk drive that reads and writes to non-removable, non-volatile magnetic media, a magnetic disk drive that reads and writes to removable, non-volatile magnetic disks, an optical disk drive that reads and writes to removable, non-volatile optical disks such as CD-ROMs, DVDs, and Blu-Ray® disks, or other optical media. The computer-readable storage medium 1322 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, etc. The computer-readable storage medium 1322 may also include flash memory-based SSDs, enterprise flash drives, solid-state drives (SSDs) based on non-volatile memory such as solid-state ROM, SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, dynamic random access memory (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 associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 1300.

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

[0137] In some embodiments, the communications subsystem 1324 may also receive incoming communications in the form of structured and / or unstructured data feeds 1326, event streams 1328, event updates 1330, etc., on behalf of one or more users who may be using the computer system 1300.

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

[0139] Additionally, the communications subsystem 1324 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 1328 of real-time events and / or event updates 1330, which may be continuous or infinite in nature with no explicit termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial stock ticker boards, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0140] The communications subsystem 1324 may also be configured to output structured and / or unstructured data feeds 1326, event streams 1328, event updates 1330, etc. to one or more databases that may communicate with one or more streaming data source computers coupled to the computer system 1300.

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

[0142] Due to the ever-changing nature of computers and networks, the description of computer system 1300 shown in the figure is intended merely as a specific example. Many other configurations are possible, having more or fewer components than the system depicted in the figure. For example, customized hardware might also be used, and / or particular elements might be implemented in hardware, firmware, software (including applets), or a combination. Furthermore, connections to other computing devices, such as network input / output devices, might be employed. Based on the disclosure and teachings provided herein, those skilled in the art will recognize other aspects and / or methods for implementing the various embodiments.

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

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

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

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

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

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

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

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

Claims

1. 1. A method comprising: one or more processors receiving a layout of a data center; and receiving, by the one or more processors, a logical fault domain configuration for the datacenter, the logical fault domain configuration identifying virtual locations of multiple logical fault domains for distributing one or more compute instances, the compute instances executing on separate physical hardware devices within a single logical fault domain based at least in part on the logical fault domain configuration, the method further comprising: determining a data center configuration by the one or more processors by assigning at least some of the plurality of logical failure domains to at least some of a plurality of electrical zones, each electrical zone of the plurality of electrical zones providing a redundant power supply across the plurality of logical failure domains based at least in part on an occurrence of a power outage; The method includes the one or more processors transmitting the data center configuration to a device for display.

2. The method of claim 1 , wherein the data center configuration is determined by dividing a power supply for the data center into an equal, separate set of power distribution groups.

3. 3. The method of claim 2, wherein the data center configuration comprises a configuration in which each set of the power distribution groups has N non-shared electrical paths from a rack for a logical fault domain within the data center upstream to a utility power line, where N conforms to data center redundancy properties.

4. 10. The method of claim 1, wherein the data center configuration allows for physical facility maintenance to be performed in one electrical zone without affecting other electrical zones while maintaining logical fault domain redundancy.

5. 10. The method of claim 1, wherein the data center configuration allows for a power equipment failure in one electrical zone without affecting other electrical zones while maintaining logical fault domain redundancy.

6. The method of any one of claims 1 to 5, wherein the physical hardware within a logical fault domain has independent and redundant power supplies.

7. The method of any one of claims 1 to 6, wherein an electrical zone comprises a grouping of rack locations within the data center, the upstream electrical distribution of which is supplied by a unique combination of two active power feeds.

8. A computer readable program for causing one or more processors to carry out the method of any one of claims 1 to 7.

9. 1. A computer system comprising: one or more memories; one or more processors communicatively coupled to the one or more memories, the one or more processors: configured to receive a layout of a data center; and configured to receive a logical fault domain configuration for the datacenter, the logical fault domain configuration identifying virtual locations of a plurality of logical fault domains for distributing one or more compute instances, the compute instances executing on separate physical hardware devices within a single logical fault domain based at least in part on the logical fault domain configuration, the one or more processors further comprising: and determining a data center configuration by assigning at least some of the plurality of logical failure domains to at least some of a plurality of electrical zones, each electrical zone of the plurality of electrical zones providing a redundant power supply across the plurality of logical failure domains based at least in part on an occurrence of a power outage, the one or more processors further comprising: A computer system configured to transmit the data center configuration to a device for display.

10. 10. The computer system of claim 9, wherein the data center configuration is determined by dividing a power supply for the data center into an equal, separate set of power distribution groups.

11. 11. The computer system of claim 10, wherein the data center configuration further comprises a configuration in which each set of the power distribution groups has N non-shared electrical paths from a rack for a logical failure domain within the data center upstream to a utility power line, where N conforms to a data center redundancy property.

12. 10. The computer system of claim 9, wherein the data center configuration allows for physical facility maintenance to be performed in one electrical zone without affecting other electrical zones while maintaining logical fault domain redundancy.

13. 10. The computer system of claim 9, wherein the data center configuration allows for a power equipment failure in one electrical zone without affecting other electrical zones while maintaining logical fault domain redundancy.

14. 14. The computer system of claim 9, wherein an electrical zone comprises a grouping of rack locations within the data center whose upstream electrical distribution is supplied by a unique combination of two active power feeds.

Images