Enterprise Hybrid Cloud Multisite Services

The release of Enterprise Hybrid Cloud v4.0 has enabled EHC customers to leverage EHC services across multiple sites. This multi-site functionality is one of the major themes for the v4.0 release and is based upon the ability to provide EHC services to multiple vCenter endpoints.

This post will explain some of the options available to EHC customers.

The EHC user portal and service catalog uses VMware vRA, which has the native ability to connect to multiple endpoints. These endpoints can be private or public, and include platforms such as vCenter, KVM, Hyper-V, Amazon EC2, OpenStack, vCloud Air, or  vCloud Director.

EHC services are VMware vCenter-based for the private cloud, and leverage vCloud Air for Public Cloud services. For private cloud instances, EHC offers the following services:

Of course vRA itself has always been able to connect to multiple vCenter endpoints and sites. This meant that those endpoints could offer mainly IaaS, but didn’t have the ability to leverage the automated Data Protection or Storage Services that EHC provides.

ehc_multisite-ehc_global_crop

Enterprise Hybrid Cloud MultiSite Services

As of EHC v4.0, the full EHC services are available for up to 4 vCenter Server endpoints, enabling customers to provision workloads to multiple sites from a single Catalog, with each site capable of full EHC services.

EHC services can implemented in different combinations across the sites, with various protection services. Some sites may have replication for Disaster Recovery, some with Continuous Availability, or a mix of each as required. The following are some (not all) examples:

Example 01: 4 Sites / 4 vCenter Endpoints / No inter-site replication

ehc_multisite-ehc_global_blocks_racks01

In example 01 we have 4 separate sites, each with their own CI platform(s) which could be VxBlock or VxRack. Each site is independent from the other, with no replication or recovery between sites.

Most EHC management components are located at the primary site, with remote agents (vRA), collectors (vR Ops) and forwarders (Log Insight) deployed at the remote sites as appropriate on smaller scale EHC Management clusters. Advanced networking services with VMware NSX are possible on each of the sites where the platform allows it (Currently VxBlock only. VxRack coming soon!).

All EHC services are available from the single portal and service catalog as follows:

  • IaaS –  Virtual machines can be deployed to each of the sites
  • BaaS – Each site also has it’s own Avamar instance to enable BaaS at each site, where all VM backups will be to the local Avamar instance.
  • STaaS – Storage is managed and provisioned to all sites from the primary ViPR instance, with SMI-S components deployed local to each site if/where required.
  • Custom services are possible at each of the sites. EHC uses a clustered vRO instance at the primary site. Additional vRA DEMs can be deployed at the remote sites as required for custom (non-Out-of-the-Box EHC) work.

 

Example 02: 4 Sites / 4 vCenter Endpoints / 2-site VM-level Inter-site DR

ehc_multisite-ehc_global_blocks_racks02-fulldrIn example 02 we have 4 separate sites, each with their own CI platform(s) which could be VxBlock or VxRack. Disaster Recovery services are configured between Site A and Site B, proving replication and full DR capabilities for all cloud management services as well as the tenant workloads.

EHC DRaaS can be implemented using either RecoverPoint with VMware SRM providing storage-level replication, or with RP4VM providing VM-level replication. Where VMware NSX is used, EHC DRaaS with RP4VM leverages Cross-vCenter NSX with Universal Objects.

Again, all EHC services are available from the single portal and service catalog as follows:

  • DRaaS – Disaster recovery services are available, bi-directional, between the DR-paired sites, allowing production services to run on each site, using each other as their DR target. All EHC management services, tenant VMs, and backups are protected across sites, so in the event of a full site failover, all Cloud services, including portal and provisioning services resume as well as the tenant workload VMs.
  • IaaS –  Virtual machines can be deployed to each of the sites. DR-protected VMs on Site A or Site B will be replicated to their DR site (A to B, and B to A)
  • BaaS – Each site also has it’s own Avamar instance to enable BaaS at each site, where all VM backups will be to the local Avamar instance. For the DR-protected Sites, VM backups are replicated to their DR partner site, to be used for continued backup services in the event of a site failover/recovery.
  • STaaS – Storage is managed and provisioned to all sites from the primary ViPR instance, with SMI-S components deployed local to each site if/where required. All sites can contain local-only storage, while Site A and Site B can use RP/SRM protected storage also. If RP4VM is used for DRaaS, then the replication is at the VM-level, not the storage level.
  • Custom services are possible at each of the sites. EHC uses a clustered vRO instance at the primary site. Additional vRA DEMs can be deployed at the remote sites as required for custom (non-Out-of-the-Box EHC) work.

 

Example 03: 5 Sites / 4 vCenter Endpoints / CA / DR / Single Site

ehc_multisite-ehc_global_blocks_racks02-fulldr_ca_ss

This example may sound a bit strange at first, as in “How do we manage 5 sites, with 4 vCenter server Endpoints?”.

To explain: EHC Continuous Availability use a single vCenter Server endpoint, but stretches all operations across 2 sites, using VMware vMotion and HA combined with VPLEX Metro to stretch the solution.

In example 03 we have 5 separate sites, each with their own CI platform(s), with 2 different protection levels configured between the sites, as well as single ROBO site.

  • Disaster Recovery protection services are configured between Site A and Site B, providing replication and full DR capabilities for all cloud management services as well as the tenant workloads.
  • Continuous Availability protection services across Site C and Site D, providing disaster avoidance protection for the EHC solution.

Again, all EHC services are available from the single portal and service catalog as follows:

  • DRaaS – Disaster recovery services are available, bi-directional, between the DR-paired sites, allowing production services to run on each site, using each other as their DR target. All EHC management services, tenant VMs, and backups are protected across sites, so in the event of a full site failover, all Cloud services, including portal and provisioning services resume as well as the tenant workload VMs.
  • Continuous Availability – A single EHC instance is stretched across both sites, providing the ability to  online migrate/vMotion all systems, both Management and tenant, from either site to the other.
  • IaaS –  Virtual machines can be deployed to each of the sites. DR-protected VMs on Site A or Site B will be replicated to their DR site (A to B, and B to A). CA-protected VMs will be deployed to either Site C or SiteD, with the ability to vMotion to the other site (C to D, or D to C)
  • BaaS – Each site also has it’s own Avamar instance to enable BaaS at each site, where all VM backups will be to the local Avamar instance. For the DR and CA-protected Sites, VM backups are replicated to their partner site, to be used for continued backup services in the event of a site failover/recovery.
  • STaaS – Storage is managed and provisioned to all sites from the primary ViPR instance, with SMI-S components deployed local to each site if/where required. All sites can contain local-only storage, while Site C and Site D require stretched (VPLEX Metro) storage also for CA operations. When RP4VM is used for DRaaS, then the replication is at the VM-level, not the storage level.
  • Custom services are possible at each of the sites. EHC uses a clustered vRO instance at the primary site. Additional vRA DEMs can be deployed at the remote sites as required for custom (non-Out-of-the-Box EHC) work.

That’s a lot of services and a lot of protection for a lot of virtual machines, all managed from a common portal!

There are other options for a multisite EHC deployment, but the options listed above should provide a good idea of the flexibility possible with the available protection levels.

Keep in mind that Public Cloud endpoints can also be leveraged within the solution, as well as standard vCenter endpoints in vRA that can be used for IaaS (e.g. VxRail). This is where the endpoints could start to expand somewhat:

ehc_multisite-ehc_global_public_private

The maximum number of Virtual machines that vRA can manage: 50,000 VMs

The general maximum for vCenter endpoints is 10, which is not a vRA or EHC limit, but a VMware SSO limit. This is due to the to the maximum number of vCenter servers supported in a single VMware SSO domain is 10.

Below is a summary of which services are possible on which CI platforms (at this time):

  • VxBlock: IaaS, STaaS, BaaS, DRaaS, CA, NSX
  • VxRack Flex: IaaS, STaaS, BaaS, DRaaS (RP4VM only)
    • Why no CA? VPLEX does not support ScaleIO
    • Why no DR with RP/SRM? ScaleIO does not have an RP splitter
    • Why no NSX? Coming soon
  • VxRail: IaaS
    • Why no STaaS? ViPR does not support VSAN
    • Why no BaaS? EHC code changes required (It’s a future!)
    • Why no CA? VPLEX does not support VSAN
    • Why no DR with RP/SRM? VSAN does not have an RP splitter

More detailed information can be found in the EHC v4.0 Concepts and Architecture Guide.

Hope that helps!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s