Data center time to value

A system can receive an order to install a first data center on customer premises, wherein the first data center comprises a first instance of a virtualized overlay network and a first instance of virtualized volume identifiers. The system can, in response to determining that installing the first data center is threshold likely to take at least a defined amount of time to install, instantiate a second data center for the customer account at a colocation site, wherein the second data center comprises a second instance of the virtualized overlay network a second instance of the virtualized volume identifiers. The system can operate customer workloads using the second data center. The system can, after instantiating the second data center, and in response to determining that the first data center is operational, switch the operating of the customer workloads from the second data center to the first data center.

BACKGROUND

A data center can comprise a plurality of computers that are configured to store and/or operate on data. Managing a data center can comprise various operations.

SUMMARY

An example system can operate as follows. A system can receive an order from a customer account to install and manage a first data center on customer premises, wherein the first data center comprises a first instance of a virtualized overlay network that virtualizes physical network resources and a first instance of a group of virtualized volume identifiers that virtualize physical storage volumes. The system can, in response to receiving the order, and in response to determining that installing the first data center is threshold likely to take at least a defined amount of time to install, instantiate a second data center for the customer account at a colocation site, wherein the second data center comprises a second instance of the virtualized overlay network a second instance of the group of virtualized volume identifiers. The system can operate customer workloads using the second data center, wherein the customer workloads invoke the second instance of the virtualized overlay network and the second instance of the group of virtualized volume identifiers. The system can, after instantiating the second data center, and in response to determining that the first data center is operational, switch the operating of the customer workloads from the second data center to the first data center, wherein the customer workloads invoke the first instance of the virtualized overlay network and the first instance of the group of virtualized volume identifiers.

An example method can comprise receiving, by a system comprising a processor, order data representative of an order from a customer account to install and manage a first data center at a first physical location, wherein the first data center comprises a first instance of a virtualized overlay network that abstracts physical network resources and a first instance of a group of virtualized volume identifiers that abstract physical storage volumes. The method can further comprise, in response to receiving the order data, and in response to determining that there will be at least a threshold delay associated with installing the first data center, instantiating, by the system, a second data center for the customer account at second physical location, wherein the second data center comprises a second instance of the virtualized overlay network a second instance of the group of virtualized volume identifiers. The method can further comprise operating, by the system, customer workloads using the second data center, wherein the customer workloads invoke the second instance of the virtualized overlay network and the second instance of the group of virtualized volume identifiers. The method can further comprise, after instantiating the second data center, and in response to determining that the first data center is operational, switching, by the system, the operating of the customer workloads from the second data center to the first data center, wherein the customer workloads invoke the first instance of the virtualized overlay network and the first instance of the group of virtualized volume identifiers.

An example non-transitory computer-readable medium can comprise instructions that, in response to execution, cause a system comprising a processor to perform operations. These operations can comprise, in response to determining to instantiate a first data center at a first physical location for a customer account, wherein the first data center comprises a first overlay network that presents an overlay and a first storage virtualization that presents virtual storage, instantiating a second data center for the customer account at second physical location, wherein the second data center comprises a second overlay network that presents the overlay and a second storage virtualization that presents the virtual storage. These operations can further comprise operating customer workloads on the second data center, wherein the customer workloads invoke the second overlay network and the second storage virtualization. These operations can further comprise, after instantiating the second data center, and in response to determining that the first data center is operational, switching the operating of the customer workloads from the second data center to the first data center, wherein the customer workloads invoke the first overlay network and the first storage virtualization.

DETAILED DESCRIPTION

Example Architectures

FIG.1illustrates an example system architecture100that can facilitate data center time to value, in accordance with an embodiment of this disclosure.

System architecture100can facilitate deployment and management of infrastructure at customer premise or hosted locations. System architecture100can facilitate consuming infrastructure as a service. System architecture100generally targets full data center deployments (e.g., data centers106, in an architecture that can be referred to as data centers as a service (DCaaS)). System architecture100can comprise data centers that run virtual infrastructure (e.g., customer workload110operating on top of virtualization and overlay networking112) and can facilitate data protection and mobility use of those data centers.

A data center (e.g., data center108) in system architecture100can comprise compute (e.g., compute118), storage (e.g., storage116), and networking, and which has a virtualization layer (e.g., virtualization and overlay networking112). That is, system architecture100can deploy a data center that can run infrastructure as a service (IaaS) workloads. Where system architecture100deploys infrastructure as a service, this can be referred to as IaaS as a service (IaaSaaS).

System architecture100can differ from other cloud offerings. Some other cloud offerings support creating extensions of themselves, which can be hosted in other locations. In the example of system architecture100, cloud management102can be used to orchestrate and manage a completely independent customer data center (e.g., data center108). The manner in which technologies are used, and the way that layers (e.g., infrastructure114and virtualization and overlay networking112) can be decomposed in system architecture100can differ from that of other cloud offerings.

That is, in other cloud offerings, such as public clouds (where workloads for multiple customers are run on the same hardware and/or in the same data center), hardware resources can generally be shared between tenants (e.g., customers). This can lead to security concerns because one customer can be sharing hardware with a rival entity (e.g., two competing consumer packaged goods companies) or a malicious actor. A security hole or data leak can cause immediate damage. In contrast, with system architecture100, a small deployment can be created that is dedicated to a customer and data can be stored on customer premises or stored in a dedicated area for the customer.

In other cloud offerings, management can be optimized for a small number of large hardware locations. Other cloud offerings can rely on uniformity and consistency of hardware and access in order to optimize their maintenance. In contrast, system architecture100can be used to manage a larger number of customer locations, each with a relatively small deployment. With system architecture100, there can be differences in hardware between customer locations according to an age and/or version of deployment, or according to a price or service level agreement designation. The management issues associated with these two types of architectures can be different.

Cloud extensions can be additional hardware from a same cloud region located in a different physical place. In system architecture100, each location can be a separate instance, which can be connected and/or extended by utilizing the present techniques.

System architecture100can be utilized to connect to existing customer data center components, whereas with other cloud offerings this can constitute a security violation.

System architecture100can be implemented to deploy or utilize hardware of a wide range of profiles and capabilities. This hardware can include one or more servers (e.g., compute118) with a central processing unit, memory, local storage, and peripheral devices; one or more primary storage systems (e.g., storage116, where primary storage can generally be optimized for performance (e.g., provide a low latency for reads and writes), and be used for running an organization's main applications and workloads); network switches and devices (e.g., network and/or a storage area network (SAN); and/or additional hardware for secondary storages (e.g., secondary storage120, where, in contrast to primary storage, secondary storage can generally be optimized for long term reliability and capacity, and used for backup and data protection systems) or other services. This hardware can also include object storage, file systems, network attached storage (NAS), hardware for performance acceleration (e.g., graphics processing units (GPUs), cache cards, central processing unit (CPU) offload cards, smart network interface cards (NICs), etc.), and/or specialized servers or other hardware for specific purposes like stream servers, messaging, artificial intelligence (AI), image processing and/or security.

In some examples, this hardware can be configured and wired by an entity that manages cloud management102, and on behalf of a customer that possesses data center108. The hardware can be delivered to data center108, or can be hosted by the entity that manages cloud management102, or by a third party. In some examples, in hosting sites, general hardware can already be available at the time of a customer order, and be allocated to a customer upon a service request.

In addition to hardware, multiple software components can be deployed and managed in accordance with customer requests.

Cloud management102can comprise a cloud portal that provides a purchasing and management user interface, and that facilitates ordering hardware resources; managing resource usage; monitoring and error handling; and upgrade and life cycle.

Cloud management102can store customer-related information and details pertaining to customer infrastructure (e.g., an architecture of data center108).

In system architecture100, deployed infrastructure (e.g., deployed infrastructure of data center108) can be managed by cloud management102, and in some examples, a customer can be billed according to the resources that the customer utilizes (which can be referred to as, pay as you go). In such examples, the customer can avoid allocating an information technology (IT) team to manage the infrastructure.

In some examples, system architecture100involves deploying a full data center (e.g., data center108), where the data center is entirely managed by cloud management102, and where the data center is targeted for a virtualized workload.

That is, system architecture100can involve a DCaaS where the data center is under cloud management102management (e.g., the customer does not provide infrastructure). Virtualized infrastructure (e.g., virtualization and overlay networking112) can comprise a hypervisor on which the customer allocates virtual workloads (e.g., customer workload110), which can be an IaaS implementation. That is, a full IaaS data center can be deployed as a service, and referred to as IaaSaaS.

Given those considerations, system architecture100can deploy an IaaS data center as a service. System architecture100can target a data center that is optimized for virtualized workloads on customer premises or a hosting facility. The customer can provide high-level resource definitions (e.g., intent-based provisioning) and service level agreements (SLAs) for a data center to cloud management102. From this information, cloud management102can derive a data center hardware definition. Hardware corresponding to this hardware definition can be shipped to customer premise, or shipped to or allocated on a hosting site. When the hardware is shipped and ready, cloud management102can configure the hardware and networking, and then deploy and configure a virtualization stack on the hardware. In some examples, the hardware can be shipped, wired, deployed, and then configured. In other examples, the hardware can be pre-wired, pre-deployed, pre-configured, and then shipped. For example, one or more racks of hardware can be wired and connected, have a stack deployed on the hardware, and then the racks of hardware can be shipped. Once the racks of hardware are received at a destination, they can be connected to power and an external network and begin operations.

A data center can comprise storage (e.g., storage116). A data center can also comprise compute (e.g., compute118), which can comprise servers that lack (or do not utilize) local storage and are configured to boot from and store their data to storage116. Booting can be implemented via technologies such as a preboot execution environment (PXE) book, or a network boot. The devices that the compute boots from can be configured by cloud management102as part of hardware and networking configuration. A data center can also comprise secondary storage (e.g., secondary storage120). In some examples, there can be multiple instances of each of these components, and multiple different hardware models of each component can be deployed within a data center.

In some examples, local storage can be omitted from compute servers to facilitate maintenance. In such a system architecture, server hardware can be added or replaced and booted from the storage, without maintaining data on the server itself. Additionally, using a common boot device for virtual infrastructure can facilitate easier upgrades and configuration. Then, data protection can be facilitated by using such a system architecture.

Virtualization and overlay networking112can comprise the following to support data protection and mobility use cases. Virtualization and overlay networking112can comprise virtualized overlay networking (which virtualizes underlying network resources to components that operate on top of the virtual overlay network), and storage that is configured to spoof or virtualize volume identifiers (such as world wide names (WWNs)).

Where cloud management102manages the deployment and configuration of a data center, cloud management102can have information about the data center and the customer that cloud management102can use to manage the data center. This information can include customer infrastructure services information; ordered, deployed, and in-use resources; a customer's physical location; and customer SLAs.

System architecture100comprises cloud management102, data centers106, and communications network122.

In turn, cloud management102comprises data center time to value component104. Data centers106comprises a plurality of data centers, including data center108. Data center108comprises customer workload110, virtualization and overlay networking112, and infrastructure114. Infrastructure114comprises storage116, compute118, and secondary storage120.

Each of cloud management102, data centers106, and data center108can be implemented with part(s) of computing environment1100ofFIG.11. Communications network122can comprise a computer communications network, such as the INTERNET.

Cloud management102can communicate with data centers106and data center108via communications network122to manage data centers106and data center108. In managing a data center, cloud management102can perform functions such as provisioning and managing virtualization and overlay networking112, and infrastructure114, and running customer workload110on data center108.

Data center time to value component104of cloud management102can facilitate installing a new data center. When a customer orders a new data center (e.g., data center108) installed on premises, while that installation occurs, data center time to value component104can instantiate a hosted data center for the customer (e.g., as part of colocation site514ofFIG.5), and run the customer's workloads on the hosted data center. When the ordered data center is ready, data center time to value component104can switch running the customer workloads from the hosted data center to the on-premises data center.

By running customer workloads on a hosted data center while installing the new data center, data center time to value component104can reduce a time to value for the customer between when the customer places the order and when the customer's workloads begin to operate. In effectuating data center time to value, data center time to value component104can implement part(s) of the operating procedures ofFIGS.8-10.

In addition to facilitating installing a new data center, data center time to value component104can facilitate other examples. For example, data center time to value component104can facilitate examples of adding hardware to an existing data center, re-evaluating hardware, and workload provisioning.

Regarding adding hardware to an existing data center, an order can be for additional hardware to a pre-existing data center (e.g., more servers). In this case, the data center can be established, but it will take time for the additional servers to be shipped and installed. In such a case, data center time to value component104can temporarily utilize hardware at another location (e.g., a colocation site) to run customer workloads while the additional hardware is shipped. This temporarily utilized data center can be decommissioned once the additional new hardware reaches the data center and workloads are migrated to it.

Regarding workload provisioning, in an example, a customer can wish to deploy a workload as a service. For example, a customer can want cloud management102to create a database cluster. Cloud management102can determine that there is not sufficient hardware resources at the customer's site for the database cluster, so can create a workload associated with the database cluster at a colocation site (allowing the customer to start working on the workload), ship the needed hardware to the customer site in parallel, and migrate the customer workload to the customer site once the new hardware is ready. A trigger for additional hardware in a workload provisioning example can be cloud management102deriving the need for additional hardware from customer workload needs.

Customer workload110can comprise workloads provided by a customer of data center108that operate on data center108. Customer workload110can comprise a virtualized workload—e.g., a virtual machine on which customer components operate, and where the virtual machine operates on top of virtualization and overlay networking112.

Virtualization and overlay networking112can comprise virtualization management component (e.g., a hypervisor) that supports the execution of customer workload110. Virtualization and overlay networking112can also comprise storage virtualization. In some examples, the virtualization management can comprise management for virtual machine-based virtualization, for container-based virtualization, for other types of virtualization, or for a combination of types of virtualization.

Infrastructure114can comprise computer hardware of data center108. Storage116can comprise storage devices upon which computer data can be stored. Compute118can comprise one or more servers that process data stored on storage116. In some examples, compute118omits using its own local storage, and instead uses storage116for storage. This separation of compute and storage hardware can facilitate managing a data center, as well as restoring a data center. Secondary storage120can be similar hardware to storage116. Where storage116is used by compute118, secondary storage can be used for backup and staging of data, such as to store a snapshot of storage116, or to store data send from cloud management102in the course of managing data center108.

FIG.2illustrates another example system architecture200that can facilitate data center time to value, in accordance with an embodiment of this disclosure.

System architecture200comprises cloud management202, data centers206, and communications network222(which can be similar to cloud management102, data centers106, and communications network122ofFIG.1, respectively).

In turn, cloud management202comprises data center time to value component104(which can be similar to data center time to value component104). Data centers206comprises a plurality of data centers, including data center208(which can be similar to data center108). Data center208comprises customer workload210, virtualization and overlay networking212, and infrastructure214(which can be similar to customer workload110, virtualization and overlay networking112, and infrastructure114, respectively). Infrastructure214comprises storage216and compute218(which can be similar to storage116and compute118, respectively).

A difference between system architecture200and system architecture100can be that system architecture200lacks secondary storage in data center208while system architecture100has secondary storage120in data center108. Despite this difference, system architecture200and system architecture100can still each be implemented to facilitate data center restoration.

FIG.3illustrates another example system architecture300that can facilitate data center time to value, in accordance with an embodiment of this disclosure.

System architecture300comprises cloud management302, customer workload310, virtualization and overlay networking312, infrastructure314A, infrastructure314B, and communications network322(which can be similar to cloud management102, customer workload110, virtualization and overlay networking112, infrastructure114, another instance of infrastructure114, and communications network122ofFIG.1, respectively).

In turn, cloud management302comprises data center time to value component304(which can be similar to data center time to value component104). Customer workload310and virtualization and overlay networking312can be similar to customer workload110and virtualization and overlay networking112, respectively.

Using storage mirroring (e.g., mirroring of storage316A and storage316B), networking technology (such as virtualization and overlay networking312), and with active compute (e.g., compute318A and compute318B), on both locations of a distributed data center (e.g., infrastructure314A and infrastructure314B), a distributed data center can automatically be created. Each component data center of a distributed data center can have active compute and workloads, and workloads can be run freely on both locations.

Storage316A and storage316B can be configured in a mirroring configuration, where writes written to one storage are immediately and inline mirrored to the other. This configuration can mean that data in storage316A and storage316B can be identical (or mirrored). In some examples, technologies such as redundant array of inexpensive disks (RAID)1, synchronous storage replicas, distributed storage volumes, synchronous clones, and active-active storage volumes can be used to implement mirroring between storage316A and storage316B.

While the example of system architecture300(and system architecture400ofFIG.4) illustrates two data centers in a distributed data center, it can be appreciated that there can be distributed data centers made up of more than two data centers. In some examples, component data centers in a distributed data center (e.g., infrastructure314A and infrastructure314B) can be referred to as “data center locations,” to distinguish these component data centers from the collected distributed data center.

A distributed data center as in system architecture300can be used for data center expansion beyond the physical limits of a data center facility. One data center location can run out of floor space, reach electricity load limits, or air conditioning limits, and so additional expansion is to happen at a different location.

In some examples, the data center locations in a distributed data center are not identical in terms of hardware capabilities, but are managed and exposed to users as one unified data center.

In some examples, cloud management302can communicate with virtualization management of virtualization and overlay networking312to create affinity between workloads, to designate coupled workloads to run at a same data center location. This approach of affinity between workloads can increase runtime efficiency.

In some examples, a distributed data center architecture can be distinguished from an availability zone architecture. In some examples, an availability zone architecture is active/passive between zones, whereas multiple data center locations of a distributed data center are active concurrently.

In some examples, an availability zone architecture involves nearly-identical data centers (where a passive data center is to handle all workloads being processed by an active data center), whereas data center locations in a distributed data center can be more heterogenous. An availability zone architecture can require identical storage in both locations, whereas it can be that a distributed architecture does not require this. An availability zone architecture can implement a high availability mechanism to orchestrate a failover between data centers for a workload to migrate, and this can be omitted in a distributed data center architecture. In some examples, an availability zone architecture involves separate power and infrastructure to make the availability zones separately available where one fails, and there can be examples of distributed data center architectures where this is neither required nor needed.

FIG.4illustrates another example system architecture400that can facilitate data center time to value, in accordance with an embodiment of this disclosure.

System architecture400comprises cloud management402, customer workload410, virtualization and overlay networking412, infrastructure414A, infrastructure414B, and communications network422(which can be similar to cloud management102, customer workload110, virtualization and overlay networking112, infrastructure114, another instance of infrastructure114, and communications network122ofFIG.1, respectively).

In turn, cloud management402comprises data center time to value component404(which can be similar to data center time to value component104). Customer workload410and virtualization and overlay networking412can be similar to customer workload110and virtualization and overlay networking112, respectively.

Infrastructure414A comprises storage416A, compute418A, and secondary storage420A (which can be similar to storage116, compute118, and secondary storage120, respectively). Infrastructure414B comprises compute418B (which can be similar to compute118). A difference between system architecture400and system architecture300ofFIG.3is that system architecture400depicts a distributed storage system where some infrastructure (infrastructure414B) omits storage. In some examples, a distributed data center can comprise at least two physical data center locations that have other hardware differences, such as differences in compute, secondary storage, object storage, file systems, NASes, hardware for performance acceleration, and specialized servers or hardware for specific purposes.

In such examples, storage416A can be used for storage for the distributed data center, and both compute418A of infrastructure414A and compute418B of infrastructure414B can operate on data that is stored in storage416A.

FIG.5illustrates another example system architecture500that can facilitate data center time to value, in accordance with an embodiment of this disclosure. System architecture500comprises cloud management502, data center508, customer workload510, virtualization and overlay networking512, colocation site514, and communications network522(which can be similar to cloud management102, data center108, customer workload110, virtualization and overlay networking112, one of data centers106, and communications network122ofFIG.1, respectively).

In turn, cloud management502comprises data center time to value component504(which can be similar to data center time to value component104). Customer workload510and virtualization and overlay networking512can be similar to customer workload110and virtualization and overlay networking112, respectively.

Data center508comprises storage516A, compute518A, and secondary storage520A (which can be similar to storage116, compute118, and secondary storage120, respectively).

A colocation site (sometimes referred to as a hosted site) can generally comprise a physical data center location that is separate from a customer's physical data location, that is managed and/or owned by an entity other than the customer, and that is configured to operate workloads for multiple customers. A colocation site can differ from an on-premises data center (e.g., data center508) in that an on-premises data center can be owned and/or controlled by one customer and used to operate that one customer's workloads.

In some examples, there can be a delay between a time when a customer orders hardware resources until a time when the hardware is shipped to the customer's premises and configured to create data center508. This time delay can be referred to as a time to value (TTV). A time involved with an order can comprise a time to fulfill an order, a time to physically ship the hardware, and a time to install the hardware. Furthermore, the customer's premises can have a physical issue (e.g., a problem with its floor, electricity, or air conditioning) that can add additional time to TTV.

The present techniques can be applied to lowering TTV while also permitting a customer to run its workloads in an on premises once the on premises order has been fulfilled.

In some examples, a customer can order a data center to be installed on customer premises by communicating with cloud management502. Cloud management502can create a data center on a colocation site (or data center separate from the customer premises, e.g., colocation site514), using the same (or compatible) storage (e.g., storage516B) as storage (e.g., storage516A) that is targeted for the customer order, and run customer workloads (e.g., customer workload510B) on this off-premises data center.

Compatible storage can be storage that meats at least a service level requests by a customer (e.g., with respect to access speed, compatible storage can be storage that is faster than that which is requested by the customer. A customer can request a data center with a certain service level (which can be stated by the customer, or derived from a SLA, or performance or service requirements). In this context, “the same storage” can be storage that meets these requirements, and “compatible storage” can be storage that exceeds these requirements.

In some examples, it can be determined to use compatible storage where the storage will be temporarily used for a particular customer (e.g., it will be decommissioned after a customer data center is instantiated and a customer workload is moved to the customer data center). In such a case, there can be minimal waste from using higher performant storage than is required.

The hardware for the customer data center (e.g., data center508) can be shipped to the customer premises, installed, and configured. Once the hardware is installed and configured on premises, the customer workloads (and associated data) can be migrated from the off-premises data center to the on-premises data center (e.g., from running as customer workloads510B on colocation site514to running as customer workloads510A on data center508).

In some examples where the on-premises data center and off-premises data center are close enough, the storage (e.g., storage516B) can be mirrored between the off-premises data center and the customer on-premises storage (e.g., storage516A). In some examples, an availability zone failover can be triggered from the off-premises data center to the on-premises data center, such as described with respect toFIG.7. In other examples, the customer workloads can gradually be moved over from the off-premises data center to the on-premises data center.

In some examples, “close enough” for data centers can refer to a measure of latency (which can be affected by geographical distance between data centers). Mirroring can be a synchronous paradigm that is sensitive to latency. The farther apart locations are, the higher latency can be, and at a threshold distance, the latency can be too high to mirror between data centers, based either on the customer workload or the equipment used for the mirroring.

In some examples, mirroring is limited to data centers that are at most 200-300 miles apart. There can be a latency associated with accessing a storage system. It can take approximately 1 millisecond for data to travel 200 miles. It can be that mirroring requires a latency of no more than 5 milliseconds (which can be a combination of latency associated with distance, equipment, and protocols used). Some protocols can require a full round trip (e.g., send the data and receive an acknowledgement), which can indicate that a 200 mile distance can involve a 2 millisecond latency, factoring in the acknowledgment.

In some examples, gradually moving a workload can comprise using load balancing and affinity techniques to transfer workloads between data centers. Where storage is mirrored between data centers, workloads can be migrated non-disruptively when ready. In such examples, parts of a workload at a time can be migrated, in contrast to an availability zone-type failover where all workloads are migrated.

Where mirroring is not implemented, a backup-restore migration can be implemented, where data from one data center is backed up and then restored to a different, destination data center. This approach can be disruptive because a workload can be taken down at the origin data center some point in the process, then the backup transferred and restored at the target, then the workload is brought up at the destination. Replication systems and other techniques can be implemented to minimize a disruption associated with backup-restore migration. In some examples, a backup-restore migration can be implemented at a time where disruption is predicted to have a minimal impact to a customer (e.g., late at night, or during a weekend).

In other examples, a data center migration can be performed, from the off-premises data center and to the on-premises data center, such as described with respect toFIG.6.

In some examples, after the customer workloads are moved to the on-premises data center, the off-premises data center can be removed. In other examples, after the customer workloads are moved to the on-premises data center, the off-premises data center can be kept as a secondary availability zone (relative to the on-premises data center serving as a primary availability zone), where latencies allow.

Cloud management502can manage configuration of both data centers (e.g., data center508and colocation site514), mirroring data and workloads between the two data centers, and a failover transition between the two data centers.

In some examples, an amount of hardware resources for the customer's on premises data center can be modified by measuring how customer workloads run on the off-premises data center. That is, the order can specify an amount of hardware resources that are a guess of how much resources are needed to run the customer workloads (or omit specifying an amount of resources). In actually running customer workloads on a hosted data center while instantiating the on premises data center, the amount of processing resources used in running the customer workloads can be measured. In some examples, the hardware resources for the customer order can be set, or modified, so that they are equal to an amount of resources used to run the customer workloads on the hosted data center, along with an additional amount of resources to handle expansion, or spikes in workloads.

FIG.6illustrates an example system architecture600for migrating to a data center, and that can facilitate data center time to value, in accordance with an embodiment of this disclosure.

System architecture600comprises cloud management602(which can be similar to cloud management102ofFIG.1), origin data center608A and target data center608B (which can each be similar to data center108), and communications network622(which can be similar to communications network122). In turn, cloud management602comprises restoration and migration component604(which can be similar to restoration and migration component104).

In an IaaSaaS scenario, where a provider (e.g., cloud management602) orchestrates full data centers, the provider can facilitate a full data center migration (e.g., from origin data center608A and to target data center608B) with little-to-no customer involvement. In some examples, migration can be performed with backup and restore constructs.

In some examples, a full migration can be effectuated as follows. Backup the data center (e.g., origin data center608A) or use an existing backup (e.g., a latest backup). Restore the backup to a new location (e.g., target data center608B). In some examples, the provider can orchestrate the infrastructure similar to as described with respect to system architecture400ofFIG.4or system architecture500ofFIG.5. In some examples, a network bubble is not created, and Re-IP is not implemented, and workloads are not powered up.

In some examples, restoring the backup to a new location can take time to complete. To mitigate against data changes that occur during this time, another diff backup (e.g., a diff backup of origin data center608A that reflects data changed on origin data center608A since a previous backup was taken) can be taken during the restore, and changes in the diff can be applied to the new target site. Power down (or disconnect from a network) the origin site, and power up the new target site. In some examples, this can involve routing changes, based on network topology.

In some examples, powering up the target site before the origin site is disconnected or down can cause IP collisions.

In some examples, the provider has full control of the process, and therefore can facilitate migration without customer intervention. Where a switchover can be disruptive, a final switchover can be coordinated with the customer to occur at a preferred time. In some examples, the network on the target side can be temporarily isolated in order to test the site before performing the switchover, and handling any issues that are uncovered by running the isolated target side.

In some examples, origin data center608A can be the customer data center operating as part of colocation site514ofFIG.5, and target data center608B can be data center508(the customer's on-premises data center). That is, when the customer's on-premises data center is installed and ready to run customer workloads, a migration such as described with respect toFIG.6can be performed to migrate data (including customer workloads) from colocation site514(e.g., origin data center608A) to data center508(e.g., target data center608B).

FIG.7illustrates another example system architecture700for failing over between availability zones, and that can facilitate data center time to value, in accordance with an embodiment of this disclosure.

System architecture700comprises cloud management702(which can be similar to cloud management102ofFIG.1), infrastructure714A and infrastructure714B (which can each be similar to infrastructure114), virtualization and overlay networking712(which can be similar to virtualization and overlay networking112), customer workload710A and customer workload710B (which can each be similar to customer workload110), and communications network722(which can be similar to communications network122).

In turn, cloud management702comprises restoration and migration component704(which can be similar to restoration and migration component104). Infrastructure714A comprises storage716A, compute718A, and secondary storage720A (which can be similar to storage116, compute118, and secondary storage120, respectively). Infrastructure714B comprises storage716B, compute718B, and secondary storage720B (which can be similar to storage116, compute118, and secondary storage120, respectively).

Storage716A and storage716B can be configured in a mirroring configuration, where writes written to one storage are immediately and inline mirrored to the other. This configuration can mean that data in storage716A and storage716B can be identical (or mirrored). In some examples, technologies such as redundant array of inexpensive disks (RAID)1, synchronous storage replicas, distributed storage volumes, synchronous clones, and active-active storage volumes can be used to implement mirroring between storage716A and storage716B.

As depicted, infrastructure714A depicts an active availability zone that is executing customer workload710A. Then, infrastructure714B comprises a standby availability zone that is configured to execute customer workload710B, but is not currently doing so. Where there is a failover (or otherwise a switch between availability zones), infrastructure714B can begin executing customer workload710B, while infrastructure714A stops executing customer workload710A. An availability zone can generally comprise a separate physical location (relative to a paired availability zone), with its own power and networking, so that should these resources fail for one availability zone, they can still be available at another availability zone.

An IaaSaaS offering can comprise a functionality to automatically create availability zones as a service (AZaaS). Availability zones can comprise (near) twin active/passive data centers that have data mirrored between them in real time. In a case of a service disruption in a main zone (e.g., infrastructure714A), workloads can startup on the other availability zone (e.g., infrastructure714B) and continue with little disruption.

An availability zone can be in a provider location, a third-party hosted location, or on another customer premise. In some examples, availability zones are within a low-latency distance of each other so that mirroring their data between the locations does not incur too high a latency.

In some examples, data is mirrored on both availability zone locations. Therefore, storage volume IDs can be identical in both locations. The network can comprise a stretched Layer2network, together with the overlay networking. A virtualization layer (e.g., virtualization and overlay networking712) can span both locations, so that workloads (e.g., customer workload710A and customer workload710B) can shift from zone to zone without being configured to operate on the new zone.

Activation of an availability zone can be done by a high availability mechanism that powers up a workload at a correct location, and is managed by the provider. In some examples, a high availability mechanism can kick in regardless of cloud connectivity—e.g., using an on-premises orchestrator and independently of a provider's cloud.

In some examples, workloads run on one site (e.g., customer workload710A on infrastructure714A), which can allow costs associated with the other site to be reduced (when no workload is running).

Where the availability zone is in a hosting, provider, or shared location, and where adding compute to the cluster can be done quickly, resources can be shared (or over-provisioned) between customers to improve a cost ratio. In some examples, storage is not shared because the data is populated and mirrored live. In some examples, compute can mostly be powered down, and possibly shared between customers.

In some examples, infrastructure714A can be the customer data center operating as part of colocation site514ofFIG.5, and infrastructure714B can be data center508(the customer's on-premises data center). That is, when the customer's on-premises data center is installed and ready to run customer workloads, an availability zone failover such as described with respect toFIG.7can be performed to switch from operating customer workloads on colocation site514(e.g., infrastructure714A) to data center508(e.g., infrastructure714B).

Example Process Flows

FIG.8illustrates an example process flow800for data center time to value, in accordance with an embodiment of this disclosure. In some examples, one or more embodiments of process flow800can be implemented by data center time to value component104ofFIG.1, data center time to value component204ofFIG.2, data center time to value component504ofFIG.5, or computing environment1100ofFIG.11.

Process flow800begins with802, and moves to operation804. Operation804depicts receiving an order from a customer account to install and manage a first data center on customer premises, wherein the first data center comprises a first instance of a virtualized overlay network that virtualizes physical network resources and a first instance of a group of virtualized volume identifiers that virtualize physical storage volumes. In some examples, this data center is data center508ofFIG.5, which the customer account orders to be installed, but is not yet installed.

After operation804, process flow800moves to operation806.

Operation806depicts, in response to receiving the order, and in response to determining that installing the first data center is threshold likely to take at least a defined amount of time to install, instantiating a second data center for the customer account at a colocation site, wherein the second data center comprises a second instance of the virtualized overlay network a second instance of the group of virtualized volume identifiers. The colocation site can be colocation site514ofFIG.5. In some examples, colocation site514can begin operating customer workloads faster than data center508(since data center508needs to be set up, such as by shipping hardware to the physical location of data center508, or configuring the hardware). In some examples, where it is determined that it will take at least a threshold amount of time (e.g., two weeks) to get data center508running, colocation site514can be configured to operate customer workloads until data center508is running.

In some examples, the first and second instances of the group of virtualized volume identifiers can provide the same virtualized volume identifiers to a workload. That is, while the underlying physical volumes (and physical volume identifiers) can vary between data centers, the virtualized volume identifiers can remain the same, so workloads can be migrated between data centers without being modified to address different physical volumes.

In some examples, there is a service commitment with the customer account on how fast it will be between the time of the order and when customer workloads are running Where it is determined that this commitment will not be met through running customer workloads on data center508, customer workloads can be run on colocation site514until data center508is ready.

In some examples, operation806comprises, in response to determining a type of storage associated with the first data center, using the type of storage with the second data center. In some examples, operation806comprises in response to determining a first type of storage associated with the first data center, using a second type of storage with the second data center, wherein the second type of storage is different than and compatible with the first type of storage. That is, the colocation site can run customer workloads using the same (or compatible) storage as the storage that is targeted for the data center.

After operation806, process flow800moves to operation808.

Operation808depicts operating customer workloads using the second data center, wherein the customer workloads invoke the second instance of the virtualized overlay network and the second instance of the group of virtualized volume identifiers. In some examples, the customer workloads can be customer workloads510B, running on colocation site514via virtualization and overlay networking512.

After operation808, process flow800moves to operation810.

Operation810depicts after instantiating the second data center, and in response to determining that the first data center is operational, switching the operating of the customer workloads from the second data center to the first data center, wherein the customer workloads invoke the first instance of the virtualized overlay network and the first instance of the group of virtualized volume identifiers. In some examples, when data center508ofFIG.5is ready to run customer workloads, customer workloads can be shifted from running on colocation site514to running on data center508. For example, customer workloads510B can operate on colocation site514. Then, those customer workloads can be shifted to run on data center508, in the form of customer workloads510A (which can be a different instance of customer workloads510B than customer workloads510B).

In some examples, operation810comprises in response to determining that the first data center is configured to store data, mirroring storage of the second data center to storage of the first data center. In some examples, operation810comprises mirroring the storage of the second data center to storage of the first data center in response to determining that a distance between the first data center and the second data center is below a defined threshold value. That is, in some examples where the first data center and the second data center are close, data can be transferred from the second data center and to the first data center via a mirroring operation.

In some examples, operation810comprises in response to determining that the first data center is operational, triggering an availability zone failover from the second data center to the first data center. That is, the first data center and the second data center can operate as availability zones, similar to as in system architecture700ofFIG.7. In such examples, workloads can be shifted from the second data center to the first data center by triggering a failover where the first data center becomes the primary data center in the availability zone, and the second data center becomes the standby data center in the availability zone.

In some examples, operation810comprises, in response to determining that the first data center is operational, iteratively switching the operating of the customer workloads from the second data center to the first data center. That is, once the first data center is operational, customer workloads can be shifted from the second data center to the first data center over time (such as when they are not actively operating on data). During this period of shifting, it can be that some customer workloads are operating on the second data center, and some customer workloads are operating on the first data center.

In some examples, operation810comprises in response to determining that the first data center is operational, disconnecting the second data center from a public communications network before performing the switching the operating of the customer workloads from the second data center to the first data center. That is, a migration can be performed, similar as described with respect toFIG.6.

FIG.9illustrates another example process flow900for data center time to value, in accordance with an embodiment of this disclosure. In some examples, one or more embodiments of process flow900can be implemented by data center time to value component104ofFIG.1, data center time to value component204ofFIG.2, data center time to value component504ofFIG.5, or computing environment1100ofFIG.11.

It can be appreciated that the operating procedures of process flow900are example operating procedures, and that there can be embodiments that implement more or fewer operating procedures than are depicted, or that implement the depicted operating procedures in a different order than as depicted. In some examples, process flow900can be implemented in conjunction with one or more embodiments of one or more of process flow800ofFIG.8, and/or process flow1000ofFIG.10.

Process flow900begins with902, and moves to operation904. Operation904depicts receiving order data representative of an order from a customer account to install and manage a first data center at a first physical location, wherein the first data center comprises a first instance of a virtualized overlay network that abstracts physical network resources and a first instance of a group of virtualized volume identifiers that abstract physical storage volumes. In some examples, operation904can be implemented in a similar manner as operation804ofFIG.8.

After operation904, process flow900moves to operation906.

Operation906depicts, in response to receiving the order data, and in response to determining that there will be at least a threshold delay associated with installing the first data center, instantiating a second data center for the customer account at second physical location, wherein the second data center comprises a second instance of the virtualized overlay network a second instance of the group of virtualized volume identifiers. In some examples, operation906can be implemented in a similar manner as operation806ofFIG.8.

After operation906, process flow900moves to operation908.

Operation908depicts operating customer workloads using the second data center, wherein the customer workloads invoke the second instance of the virtualized overlay network and the second instance of the group of virtualized volume identifiers. In some examples, operation908can be implemented in a similar manner as operation808ofFIG.8.

In some examples, operation908comprises determining a first amount of resources to install for the first data center based on determining a second amount of resources associated with operating the customer workloads using the second data center. That is, determining how much hardware resources to include in the first data center can be determined based on actually running the customer workloads on the second data center and determining how much hardware resources running the customer workloads actually takes. In some examples, the order specifies an amount of hardware resources, and this amount is modified. In other examples, the order does not specify the amount of hardware resources.

In some examples, the order identifies a first amount of computing resources, operation908comprises, in response to determining that the customer workloads being processed using the second data center consume a second amount of computing resources, and in response to determining that the first amount of computing resources differs from the second amount of computing resources by at least a specified amount, modifying an amount of computing resources associated with the order. That is, in some examples, the customer can specify an amount of hardware resources in the order, and this amount can be refined based on running the customer workloads at the second data center.

In some examples, the second amount of computing resources is greater than the first amount of computing resources, and wherein modifying the amount of computing resources associated with the order comprises increasing the amount of computing resources associated with the order. That is, where it turns out that the customer needs more hardware resources than ordered, then the amount of hardware resources for the first data center can be increased.

In some examples, the second amount of computing resources is less than the first amount of computing resources, and wherein modifying the amount of computing resources associated with the order comprises decreasing the amount of computing resources associated with the order. That is, where it turns out that the customer needs less hardware resources than ordered, then the amount of hardware resources for the first data center can be decreased.

After operation908, process flow900moves to operation910.

Operation910depicts, after instantiating the second data center, and in response to determining that the first data center is operational, switching the operating of the customer workloads from the second data center to the first data center, wherein the customer workloads invoke the first instance of the virtualized overlay network and the first instance of the group of virtualized volume identifiers. In some examples, operation910can be implemented in a similar manner as operation810ofFIG.8.

In some examples, a cloud management platform manages the first data center and the second data center, and controls the switching of the operating of the customer workloads from the second data center to the first data center. The cloud management platform can be cloud management502ofFIG.5.

FIG.10illustrates another example process flow1000for data center time to value, in accordance with an embodiment of this disclosure. In some examples, one or more embodiments of process flow1000can be implemented by data center time to value component104ofFIG.1, data center time to value component204ofFIG.2, data center time to value component504ofFIG.5, or computing environment1100ofFIG.11.

Process flow1000begins with1002, and moves to operation1004. Operation1004depicts, in response to determining to instantiate a first data center at a first physical location for a customer account, wherein the first data center comprises a first overlay network that presents an overlay and a first storage virtualization that presents virtual storage, instantiating a second data center for the customer account at second physical location, wherein the second data center comprises a second overlay network that presents the overlay and a second storage virtualization that presents the virtual storage. In some examples, operation1004can be implemented in a similar manner as operations804-806ofFIG.8.

In some example, the overlay comprises a first instance of virtualizing first physical network resources on the first data center, wherein the overlay comprises a second instance of virtualizing second physical network resources of the second data center, and wherein a same invocation of the overlay by the customer workloads on the first data center and the second data center, respectively, accesses different physical network resources on the first data center and the second data center. That is, the overlay can be the overlay network portion of virtualization and overlay networking512ofFIG.5.

In some examples, the virtual storage comprises a first instance of virtualizing first physical storage resources on the first data center, wherein the overlay comprises a second instance of virtualizing second physical storage resources of the second data center, and wherein a same invocation of the virtual storage by the customer workloads on the first data center and the second data center, respectively, accesses different physical storage resources on the first data center and the second data center. That is, the virtual storage can be a virtual storage portion of virtualization and overlay networking512ofFIG.5.

After operation1004, process flow1000moves to operation1006.

Operation1006depicts operating customer workloads on the second data center, wherein the customer workloads invoke the second overlay network and the second storage virtualization. In some examples, operation1006can be implemented in a similar manner as operation808ofFIG.8.

After operation1006, process flow1000moves to operation1008.

Operation1008depicts after instantiating the second data center, and in response to determining that the first data center is operational, switching the operating of the customer workloads from the second data center to the first data center, wherein the customer workloads invoke the first overlay network and the first storage virtualization. In some examples, operation1008can be implemented in a similar manner as operation810ofFIG.8.

In some examples, operation1008comprises, after switching the operating of the customer workloads from the second data center to the first data center, decommissioning the second data center. That is, after setting up the first data center and running the customer workloads on it, the second data center can be removed.

In some examples, operation1008comprises, after switching the operating of the customer workloads from the second data center to the first data center, configuring the first data center as a primary availability zone and the second data center as a secondary availability zone. In some examples, operation1008comprises determining to configure the second data center as the secondary availability zone based on determining that a latency between the first data center and the second data center is below a predetermined threshold value. That is, in some examples, after establishing the first data center and moving customer workloads to the first data center, the second data center can be kept as an availability zone (a standby data center relative to the first data center being the primary data center), where latencies permit such operation. Where availability zones mirror data, there can be a maximum latency in data transfer between the two availability zones to facilitate this mirroring (e.g., there can be a physical distance limit of 200-300 miles between the two data centers, as described in an example with respect to mirroring).

Example Operating Environment

In order to provide additional context for various embodiments described herein,FIG.11and the following discussion are intended to provide a brief, general description of a suitable computing environment1100in which the various embodiments of the embodiment described herein can be implemented.

For example, parts of computing environment1100can be used to implement one or more embodiments of cloud management102, data centers106, and/or data center108ofFIG.1, and/or cloud management202, data centers206, and/or data center208ofFIG.2.

In some examples, computing environment1100can implement one or more embodiments of the process flows ofFIGS.8-10to facilitate data center time to value.

While the embodiments have been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that the embodiments can be also implemented in combination with other program modules and/or as a combination of hardware and software.

The system bus1108can be any of several types of bus structure that can further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory1106includes ROM1110and RAM1112. A basic input/output system (BIOS) can be stored in a nonvolatile storage such as ROM, erasable programmable read only memory (EPROM), EEPROM, which BIOS contains the basic routines that help to transfer information between elements within the computer1102, such as during startup. The RAM1112can also include a high-speed RAM such as static RAM for caching data.

The computer1102further includes an internal hard disk drive (HDD)1114(e.g., EIDE, SATA), one or more external storage devices1116(e.g., a magnetic floppy disk drive (FDD)1116, a memory stick or flash drive reader, a memory card reader, etc.) and an optical disk drive1120(e.g., which can read or write from a CD-ROM disc, a DVD, a BD, etc.). While the internal HDD1114is illustrated as located within the computer1102, the internal HDD1114can also be configured for external use in a suitable chassis (not shown). Additionally, while not shown in environment1100, a solid state drive (SSD) could be used in addition to, or in place of, an HDD1114. The HDD1114, external storage device(s)1116and optical disk drive1120can be connected to the system bus1108by an HDD interface1124, an external storage interface1126and an optical drive interface1128, respectively. The interface1124for external drive implementations can include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1194 interface technologies. Other external drive connection technologies are within contemplation of the embodiments described herein.

A number of program modules can be stored in the drives and RAM1112, including an operating system1130, one or more application programs1132, other program modules1134and program data1136. All or portions of the operating system, applications, modules, and/or data can also be cached in the RAM1112. The systems and methods described herein can be implemented utilizing various commercially available operating systems or combinations of operating systems.

Computer1102can optionally comprise emulation technologies. For example, a hypervisor (not shown) or other intermediary can emulate a hardware environment for operating system1130, and the emulated hardware can optionally be different from the hardware illustrated inFIG.11. In such an embodiment, operating system1130can comprise one virtual machine (VM) of multiple VMs hosted at computer1102. Furthermore, operating system1130can provide runtime environments, such as the Java runtime environment or the .NET framework, for applications1132. Runtime environments are consistent execution environments that allow applications1132to run on any operating system that includes the runtime environment. Similarly, operating system1130can support containers, and applications1132can be in the form of containers, which are lightweight, standalone, executable packages of software that include, e.g., code, runtime, system tools, system libraries and settings for an application.

A monitor1146or other type of display device can be also connected to the system bus1108via an interface, such as a video adapter1148. In addition to the monitor1146, a computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

The computer1102can operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, such as a remote computer(s)1150. The remote computer(s)1150can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer1102, although, for purposes of brevity, only a memory/storage device1152is illustrated. The logical connections depicted include wired/wireless connectivity to a local area network (LAN)1154and/or larger networks, e.g., a wide area network (WAN)1156. Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to a global communications network, e.g., the Internet.

When used in a LAN networking environment, the computer1102can be connected to the local network1154through a wired and/or wireless communication network interface or adapter1158. The adapter1158can facilitate wired or wireless communication to the LAN1154, which can also include a wireless access point (AP) disposed thereon for communicating with the adapter1158in a wireless mode.

When used in a WAN networking environment, the computer1102can include a modem1160or can be connected to a communications server on the WAN1156via other means for establishing communications over the WAN1156, such as by way of the Internet. The modem1160, which can be internal or external and a wired or wireless device, can be connected to the system bus1108via the input device interface1144. In a networked environment, program modules depicted relative to the computer1102or portions thereof, can be stored in the remote memory/storage device1152. It will be appreciated that the network connections shown are example and other means of establishing a communications link between the computers can be used.

When used in either a LAN or WAN networking environment, the computer1102can access cloud storage systems or other network-based storage systems in addition to, or in place of, external storage devices1116as described above. Generally, a connection between the computer1102and a cloud storage system can be established over a LAN1154or WAN1156e.g., by the adapter1158or modem1160, respectively. Upon connecting the computer1102to an associated cloud storage system, the external storage interface1126can, with the aid of the adapter1158and/or modem1160, manage storage provided by the cloud storage system as it would other types of external storage. For instance, the external storage interface1126can be configured to provide access to cloud storage sources as if those sources were physically connected to the computer1102.

CONCLUSION

In the subject specification, terms such as “data store,” data storage,” “database,” “cache,” and substantially any other information storage component relevant to operation and functionality of a component, refer to “memory components,” or entities embodied in a “memory” or components comprising the memory. It will be appreciated that the memory components, or computer-readable storage media, described herein can be either volatile memory or nonvolatile storage, or can include both volatile and nonvolatile storage. By way of illustration, and not limitation, nonvolatile storage can include ROM, programmable ROM (PROM), EPROM, EEPROM, or flash memory. Volatile memory can include RAM, which acts as external cache memory. By way of illustration and not limitation, RAM can be available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM). Additionally, the disclosed memory components of systems or methods herein are intended to comprise, without being limited to comprising, these and any other suitable types of memory.