ENTERPRISE HYBRID CLOUD 4.1 - Dell EMC US · PDF fileENTERPRISE HYBRID CLOUD 4.1.2 Concepts...

SOLUTION GUIDE

ENTERPRISE HYBRID CLOUD 4.1.2

Concepts and Architecture

September 2017

Abstract

This solution guide provides an introduction to the concepts and architectural options

available within Enterprise Hybrid Cloud. It should be used as an aid to deciding on

the most suitable configuration for the initial deployment of Enterprise Hybrid Cloud.

H16266.2R

This document is not intended for audiences in China, Hong Kong, Taiwan, and

Macao.

Copyright

2 Enterprise Hybrid Cloud 4.1.2 Concepts and Architecture Solution Guide

The information in this publication is provided as is. Dell Inc. makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.

Use, copying, and distribution of any software described in this publication requires an applicable software license.

Copyright © 2017 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC, Dell EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries. Intel, the Intel logo, the Intel Inside logo and Xeon are trademarks of Intel Corporation in the U.S. and/or other countries. Other trademarks may be the property of their respective owners. Published in the USA September 2017 Solution Guide H16266.2R.

Dell Inc. believes the information in this document is accurate as of its publication date. The information is subject to change without notice.

Contents

3 Enterprise Hybrid Cloud 4.1.2 Concepts and Architecture

Solution Guide

Contents

Chapter 1 Executive Summary 6

Enterprise Hybrid Cloud ........................................................................................ 7

Document purpose ................................................................................................ 7

Audience ............................................................................................................... 7

Essential reading .................................................................................................. 7

Solution purpose ................................................................................................... 8

Business challenge ............................................................................................... 8

Technology solution .............................................................................................. 9

We value your feedback ........................................................................................ 9

Chapter 2 Cloud Management Platform Options 10

Overview ............................................................................................................. 11

Cloud management platform components ........................................................... 12

Cloud management platform model .................................................................... 15

Component high availability ................................................................................ 16

Chapter 3 Object Model and Key Foundational Concepts 18

Object model overview ........................................................................................ 19

Key foundational concepts .................................................................................. 21

Chapter 4 Multisite and Multi-vCenter Protection Services 25

vCenter endpoint types ....................................................................................... 26

SSO domain types .............................................................................................. 26

Protection services .............................................................................................. 27

Single-site protection service .............................................................................. 29

Continuous Availability (Single-site) protection service ........................................ 30

Continuous Availability (Dual-site) protection service .......................................... 32

Disaster recovery (RecoverPoint for Virtual Machines) protection service ........... 34

Disaster recovery (VMware Site Recovery Manager) protection service ............. 35

Combining protection services ............................................................................ 36

Scale considerations ........................................................................................... 48

Multi-vCenter and multisite topologies ................................................................. 50

Chapter 5 Network Considerations 57

Overview ............................................................................................................. 58

Cross-vCenter VMware NSX ............................................................................... 58

Logical network considerations ........................................................................... 59

Contents


Network virtualization .......................................................................................... 59

Network requirements and best practices ........................................................... 62

Enterprise Hybrid Cloud validated network designs using VMware NSX ............. 66

Chapter 6 Storage Considerations 78

Common best practices and supported configurations ........................................ 79

Non-replicated storages ...................................................................................... 80

Continuous availability storage considerations .................................................... 81

Disaster recovery (Site Recovery Manager) storage considerations ................... 85

Chapter 7 Data Protection (Backup as a Service) 87

Overview ............................................................................................................. 88

Data protection technology .................................................................................. 88

Backup types overview ....................................................................................... 89

Key Enterprise Hybrid Cloud backup constructs .................................................. 94

Controlling the backup infrastructure ................................................................... 99

Chapter 8 Enterprise Hybrid Cloud on Converged Infrastructure Systems 100

Enterprise Hybrid Cloud on VxRail Appliances .................................................. 101

Enterprise Hybrid Cloud on VxRack Systems .................................................... 105

Enterprise Hybrid Cloud on VxBlock Systems ................................................... 108

Chapter 9 Ecosystem Interactions 116

Single-site ecosystems ..................................................................................... 117

Continuous availability ecosystem ..................................................................... 118

Disaster recovery ecosystems........................................................................... 119

Chapter 10 Maximums, Rules, Best Practices, and Restrictions 121

Overview ........................................................................................................... 122

Maximums ........................................................................................................ 122

VMware Platform Services Controller rules ....................................................... 127

Active Directory ................................................................................................. 128

VMware vRealize tenants and business groups ................................................ 129

Dell EMC ViPR tenant and projects rules .......................................................... 130

Bulk import of virtual machines.......................................................................... 130

Resource sharing .............................................................................................. 131

Data protection considerations .......................................................................... 131

RecoverPoint for Virtual Machines best practices ............................................. 132

Software resources ........................................................................................... 132

Sizing guidance ................................................................................................. 132

Restrictions ....................................................................................................... 133

Component options ........................................................................................... 134

Contents


Solution Guide

Chapter 11 Conclusion 135

Conclusion ........................................................................................................ 136

Chapter 1: Executive Summary


Chapter 1 Executive Summary

This chapter presents the following topics:

Enterprise Hybrid Cloud ..................................................................................... 7

Document purpose ............................................................................................. 7

Audience .............................................................................................................. 7

Essential reading ................................................................................................ 7

Solution purpose................................................................................................. 8

Business challenge ............................................................................................. 8

Technology solution ........................................................................................... 9

We value your feedback ..................................................................................... 9



Solution Guide

Enterprise Hybrid Cloud

Dell EMC™ Enterprise Hybrid Cloud 4.1.2 is a converged cloud platform that provides a

completely virtualized data center, fully automated by software. It starts with a foundation

that delivers IT as a service (ITaaS), with options for high availability, backup and

recovery, and disaster recovery (DR) as tiers of service within the same environment. It

also provides a framework and foundation for add-on modules, such as encryption as a

service (EaaS).

Document purpose

This solution guide provides an introduction to the concepts and architectural options

available within Enterprise Hybrid Cloud. It should be used as an aid to deciding on the

most suitable configuration for the initial deployment of Enterprise Hybrid Cloud.

Audience

This solution guide is intended for executives, managers, architects, cloud administrators,

security manager, developers, and technical administrators of IT environments who want

to implement a hybrid cloud infrastructure as a service (IaaS) platform. Readers should be

familiar with the VMware vRealize Suite, storage technologies, general IT functions and

requirements, and how a hybrid cloud infrastructure accommodates these technologies

and requirements.

Essential reading

The Enterprise Hybrid Cloud 4.1.2 Reference Architecture Guide describes the reference

architecture for Enterprise Hybrid Cloud. The guide introduces the features and

functionality of the solution, the solution architecture and key components, and the

validated hardware and software environments.

The following guides provide further information about various aspects of Enterprise

Hybrid Cloud:

Enterprise Hybrid Cloud 4.1.2 Reference Architecture Guide

Enterprise Hybrid Cloud 4.1.2 Administration Guide

Enterprise Hybrid Cloud 4.1.2 Security Management Guide

Enterprise Hybrid Cloud 4.1.1 Infrastructure and Operations Management Guide



Solution purpose

Enterprise Hybrid Cloud enables customers to build an enterprise-class, multisite,

scalable infrastructure that enables:

Complete management of the infrastructure service lifecycle

On-demand access to and control of network bandwidth, servers, storage, and security

On-demand provisioning, monitoring, protection, and management of the infrastructure services by the line-of-business users

On-demand provisioning of application blueprints with associated infrastructure resources by line-of-business application owners

Simplified provisioning of backup, continuous availability (CA), and DR services as part of the cloud service provisioning process

Add, modify, or delete services to an application or virtual machine during its complete lifecycle

Maximum asset use

Increased scalability with centrally managed multisite platforms spanning IT services to all data centers

Business challenge

While many organizations have successfully introduced virtualization as a core technology

within their data center, the benefits of virtualization have largely been restricted to the IT

infrastructure owners. End users and business units within customer organizations have

not experienced many of the benefits of virtualization, such as increased agility, mobility,

and control.

Transforming from the traditional IT model to a cloud-operating model involves

overcoming the challenges of legacy infrastructure and processes, such as:

Inefficiency and inflexibility

Slow, reactive responses to customer requests

Inadequate visibility into the cost of the requested infrastructure

Limited choice of availability and protection services

The difficulty in overcoming these challenges has given rise to public cloud providers who

have built technology and business models catering to the requirements of end-user

agility and control. Many organizations are under pressure to provide similar service levels

within the secure and compliant confines of the on-premises data center without

sacrificing visibility and control. As a result, IT departments must create cost-effective

alternatives to public cloud services, alternatives that do not compromise enterprise

features such as data protection (DP), DR, and guaranteed service levels.



Solution Guide

Technology solution

Enterprise Hybrid Cloud integrates the best of Dell EMC and VMware products and

services, and empowers IT organizations to accelerate implementation and adoption of a

hybrid cloud infrastructure. The solution caters to customers who want to preserve their

investment and make better use of their existing infrastructure and to those customers

who want to build out new infrastructures dedicated to a hybrid cloud.

This solution takes advantage of the strong integration between Dell EMC technologies

and vRealize and VMware vCloud Suite. The solution, developed by Dell EMC and

VMware product and services teams, includes Dell EMC scalable storage arrays,

converged and hyper-converged infrastructures, integrated Dell EMC and VMware

monitoring, and data protection suites to provide the foundation for enabling cloud

services within the customer environment.

Enterprise Hybrid Cloud offers several key benefits to customers:

Rapid implementation—Enterprise Hybrid Cloud offers the foundation IaaS and can be designed and implemented in a validated, tested, and repeatable way based on Dell EMC converged and hyper-converged infrastructure. This increases the time-to-value for the customer while simultaneously reducing risk. Deliver ITaaS with add-on modules for backup, DR, CA, virtual machine encryption, applications, application lifecycle automation for continuous delivery, ecosystem extensions, and more.

Supported cloud platform—Implementing Enterprise Hybrid Cloud through Dell EMC results in a cloud platform that Dell EMC supports and further reduces risk that is associated with the ongoing operations of your hybrid cloud.

Defined upgrade path—Customers implementing Enterprise Hybrid Cloud receive upgrade guidance based on the testing and validation completed by the engineering teams. This upgrade guidance enables customers, partners, and Dell EMC services teams to perform upgrades faster and with much less risk.

Validated and tested integration—Extensive integration testing done across Enterprise Hybrid Cloud makes it simpler to use and manage, and more efficient to operate.

We value your feedback

Dell EMC and the authors of this document welcome your feedback on the solution and

the solution documentation. Contact us at [email protected] with your

comments.

Authors: Ken Gould, Fiona O’Neill

mailto:[email protected]?subject=Feedback:%20Enterprise%20Hybrid%20Cloud%204.1.2%20Concepts%20and%20Architecture%20Solution%20Guide%20(H16266R)

Chapter 2: Cloud Management Platform Options


Chapter 2 Cloud Management Platform Options


Overview ............................................................................................................ 11

Cloud management platform components ...................................................... 12

Cloud management platform model ................................................................ 15

Component high availability ............................................................................ 16



Solution Guide

Overview

To understand how the management platform is constructed, it is important to understand

how a number of terms are used throughout this guide. Figure 1 shows the relationship

between platform, pod, and cluster and their relative scopes as used in Enterprise Hybrid

Cloud.

Note: It is important to understand that the term “pod” does not imply a vSphere cluster. A pod

may be distributed across multiple vSphere clusters, or multiple pods may exist on the same

vSphere cluster.

Figure 1. Cloud management terminology and hierarchy

In respect of the scope of each term, the following distinctions exist:

Platform

The full name is Cloud Management Platform (CMP), which is an umbrella term

representing the entire management environment.

Pod

The full name is Management Pod. Each management pod is a subset of the overall management platform and represents a grouping of Enterprise Hybrid Cloud components designed to deliver specific functions.

Pods reside on compute resources but are not themselves the compute resource.

While it may be possible for pods to share compute resources with non- Enterprise Hybrid Cloud components (via Request Per Qualification (RPQ)), no component can be considered part of a pod without being expressly integrated and tested by Dell EMC Engineering.

Management Pod functions may be distributed between vSphere clusters or consolidated onto vSphere clusters, depending on the individual Enterprise Hybrid Cloud managed vCenter endpoint requirements.

Management

terminology and

hierarchy



Cluster

The term “cluster” refers to individual technology clusters. While clusters may refer

to vSphere clusters, it can also refer to Dell EMC VPLEX™ clusters, Dell EMC

RecoverPoint™ clusters, and so on.

Resource pools

Non-default resource pools are used only when two or more management pods are

collapsed onto the same vSphere cluster. In this case, they are used to control and

guarantee resources to each affected pod.

Cloud management platform components

When Enterprise Hybrid Cloud is deployed, the first location requires a full management

stack to be deployed. Figure 2 shows how the components of the full management stack

are distributed among the management pods.

Figure 2. Enterprise Hybrid Cloud full management stack

Note: Figure 2 includes Dell EMC ViPR™ Controller and ViPR SRM. Neither component is

required in Dell EMC VxRail™ Appliance deployments where VMware vSAN storage is used.

Full management

stack

components



Solution Guide

Note: The Automation Pod Platform Services Controller (PSC) appliance is not required in a

VxRail Appliance Enterprise Hybrid Cloud environment because it uses vRealize Automation as

the authentication mechanism.

The Core Pod function provides the base set of resources to establish Enterprise Hybrid

Cloud services and consists of:

VMware vCenter Server

Note: While Figure 2 depicts vCenter, Update Manager, and PSC as one cell of related

components, they are deployed as separate virtual machines.

Microsoft SQL Server

VMware NSX Manager

Log Insight Forwarders and vRealize Operations Manager collectors

EMC SMI-S Provider (on Dell EMC VxBlock Systems)

Dell EMC PowerPath/VE vApp (on VxBlock)

When deployed on Dell EMC converged infrastructure systems, the Core Pod is overlaid

on the existing management environment and uses the existing management

components.

The Network Edge Infrastructure (NEI) Pod function provides the convergence point for

the physical and virtual networks and is only required where VMware NSX is deployed.

The NEI Pod function consists of NSX controllers, north-south NSX Edge Services

Gateway (ESG) devices, NSX DLR control virtual machines, and an NSX Load Balancer

(NLB) to front-distributed vRealize components, such as VMware vRealize Automation

and VMware vRealize Orchestrator.

VMware vSphere Distributed Resource Scheduler (DRS) rules are used to ensure that

NSX controllers are separated from each other, and also to ensure that primary ESGs are

separated from primary DLRs so that a host failure does not affect network availability.

Note: VMware NSX is a mandatory component on VxRail Appliance as it is deployed by the

Enterprise Hybrid Cloud Automation Tool to provide the required load balancing function.

The Automation Pod function consists of the remaining components required for

automating and managing the cloud infrastructure, including those responsible for the

user portal, automated provisioning, monitoring, and metering.

It is managed by the Cloud vCenter Server instance but is dedicated to automation and

management services. Therefore, the compute resources that support the Automation

Pod function are not exposed to vRealize Automation business groups.

To ensure independent failover capability, the Automation Pod function may not share

storage resources with the workload clusters. For the same reasons, it may not share

networks and should be on a distinctly different Layer 3 network to both the Core Pod and

NEI Management Pod functions.

Core Pod

function

Network Edge

Infrastructure

Pod function

Automation Pod

function



Note: While Figure 2 depicts vRealize IaaS as one cell of related components, the individual

vRealize Automation roles are actually deployed as separate virtual machines.

Workload Pods are configured and assigned to fabric groups in vRealize Automation.

Available resources are used to host tenant workload virtual machines deployed by

business groups in the Enterprise Hybrid Cloud environment. All business groups can

share the available VMware vSphere ESXi cluster resources.

In VxBlock Systems and VxRack System FLEX configurations, ViPR service requests are

initiated from the vRealize Automation catalog to provision Workload Pod storage. For

VxRail Appliances, all storage is pre-provisioned at the time of the VxRail Appliance

deployment.

When an additional vCenter endpoint is configured for use in Enterprise Hybrid Cloud, that

endpoint only requires a subset of the management stack to operate. Figure 3 shows how

the components of the endpoint management stack are distributed among the

management pods.

Figure 3. Enterprise Hybrid Cloud endpoint management stack

As with the full management stack, the NEI Pod function is only required if VMware NSX

is being used.

vRealize Automation agents are deployed for each endpoint to follow best practice and

are geographically co-located to ensure predictable performance. Additional vRealize

distributed execution managers (DEMs) may also be required, depending on the overall

run rate of tasks in the cloud environment.

Workload Pods

Endpoint

Management

Stack



Solution Guide

Cloud management platform model

The Enterprise Hybrid Cloud management platform requires a minimum set of resources

to comply with the combined best practices of the components used to manage the cloud.

These minimums are shown in Table 1.

Note: Minimum host count is dependent on the specification of the compute resources being

sufficient to support the relevant management virtual machine requirements. The Enterprise

Hybrid Cloud sizing tool may recommend a larger number of hosts based on the server

specification chosen.

Table 1. Enterprise Hybrid Cloud management model minimums

Hosting platform Pod vCenter Cluster Minimum number of hosts

Resource pool

VxBlock System Core Cloud AMP Cluster 3* N/A

NEI (NSX configurations only)

Cloud Split between AMP and Edge clusters

Controllers are on AMP

4 for Edge

N/A

Automation Cloud Automation cluster

3 N/A

VxRack System FLEX

Core VXMA Management cluster

4 N/A

NEI (NSX configurations only)

Cloud Edge cluster 4 N/A

Automation Cloud Automation cluster

3 N/A

VxRail Appliance

Core

Cloud VxRail cluster 4

Core

NEI NEI

Automation Automation

* Based on AMP-2HAP or AMP-2S configuration.

Factors affecting minimum host counts

The following considerations are inherent in the numbers presented in Table 1:

The Core Pod function is overlaid on one of the following: the VxBlock AMP cluster, VxRack VXMA cluster, or VxRail cluster reducing the overall management requirements.

The ESXi cluster serving as the Edge cluster in VxBlock System and VxRack System configurations (for the NEI Pod function Edges and Controllers) must have at least four nodes when using VMware NSX to avoid short-term network outage if a host fails.

The ESXi cluster supporting the Automation Pod function must have at least three nodes to meet ViPR best practices for ViPR node separation (VxBlock System and VxRack System configurations only).



When an ESXi cluster supporting a management pod uses vSAN with, for example, VxRack Systems or VxRail Appliances, there must be at least four nodes in the ESXi cluster to ensure storage can suffer the loss of a cluster node without compromising storage integrity.

Note: For ultimate resilience and ease of use during maintenance windows, creating vSphere

cluster sizes based on N+2 sizing may be appropriate based on customer preference, where N is

calculated as the number of hosts required to support the Management Pod functions based on

the CPU and RAM requirements for the hosted virtual machines plus host system overhead. The

Enterprise Hybrid Cloud sizing tool sizes vSphere clusters based on an N+1 algorithm by default,

but also allows N+2 selection.

Component high availability

The use of vSphere ESXi clusters with VMware vSphere High Availability (HA) provides

general virtual machine protection across the management platform. Further levels of

availability are provided by using the high availability options of the individual components,

as outlined in the next section.

Enterprise Hybrid Cloud requires the use of distributed vRealize Automation installations.

In this model, multiple instances of each vRealize Automation role are deployed behind a

load balancer to ensure scalability and fault tolerance.

Note: All-in-one vRealize Automation installations are not supported for production use.

VMware NSX load balancing technology is fully supported, tested, and validated by

Enterprise Hybrid Cloud. Other load balancer technologies supported by VMware for use

in vRealize Automation deployments are permitted, but configuration assistance for those

technologies should be provided by VMware or the specific vendor.

Note: Use of a load balancer technology not officially supported by Enterprise Hybrid Cloud or

VMware with vRealize Automation requires an Enterprise Hybrid Cloud RPQ. VMware NSX is the

only supported Load Balancer technology on a VxRail Appliance configuration and is automatically

deployed and configured in that scenario.

General high

availability

Distributed

vRealize

Automation



Solution Guide

Both clustered and stand-alone vRealize Orchestrator installations are supported by

Enterprise Hybrid Cloud.

Table 2 details the specific component high availability options.

Table 2. vRealize Automation and vRealize Orchestrator HA options

Management model

Distributed vRealize Automation

Minimal vRealize Automation (AIO)

Clustered vRealize Orchestrator (active/active)

Stand-alone vRealize Orchestrator

Distributed Supported Not supported Supported (recommended)

Supported

Highly available configurations for VMware Platform Services Controller are not supported

in Enterprise Hybrid Cloud 4.1.2.

The cloud-management platform for Enterprise Hybrid Cloud can be made resilient across

sites using any of the supported multisite protection models that are deployed in the

Enterprise Hybrid Cloud environment.

Note: When multisite protection is available within the Enterprise Hybrid Cloud environment, Dell

EMC recommends that the management platform is also protected, because it may not be

possible to recover tenant workloads to a secondary site without first recovering elements of the

management platform. We also recommend that you protect the management platform with the

highest form of multisite protection available in your Enterprise Hybrid Cloud environment.

Clustered

vRealize

Orchestrator

Highly available

VMware Platform

Services

Controller

Multisite

protection for

the management

platform

Chapter 3: Object Model and Key Foundational Concepts


Chapter 3 Object Model and Key Foundational Concepts


Object model overview ..................................................................................... 19

Key foundational concepts .............................................................................. 21



Solution Guide

Object model overview

Enterprise Hybrid Cloud 4.1.2 uses an object model that provides the framework for

storing and referencing metadata related to infrastructure and compute resources. The

object model acts as the rules engine for provisioning storage, backup service levels, and

inter-site or intra-site protection services.

Note: Upgrade of existing Enterprise Hybrid Cloud environments to the object model is fully

supported and covered by the included upgrade procedure.

The Enterprise Hybrid Cloud object model is presented to vRealize Orchestrator through a

combination of the Enterprise Hybrid Cloud vRealize Orchestrator plug-in and the VMware

Dynamic Data Types plug-in. All model data is stored in a Microsoft SQL Server database

on the Automation Pod SQL Server instance, and can be referenced by all vRealize

Orchestrator nodes.

Figure 4 shows the Enterprise Hybrid Cloud object model and the relationships between

the individual object types.

Overview



Figure 4. Enterprise Hybrid Cloud object model



Solution Guide

Figure 5 shows an example of Enterprise Hybrid Cloud connection objects created in the

Enterprise Hybrid Cloud object model as presented and referenceable through vRealize

Orchestrator.

Figure 5. vRealize Orchestrator view of onboarded Enterprise Hybrid Cloud connections in the object model

Key foundational concepts

Enterprise Hybrid cloud now supports up to eight sites, depending on the combination of

protection services deployed in the environment.

In Enterprise Hybrid Cloud, a site is a geographic location and is the key factor in

determining the following:

The workloads that may share the same Dell EMC Avamar™ and Dell EMC Data Domain™ backup infrastructure.

All workloads determined to be on the same site (irrespective of their hardware island, vCenter, or cluster) can share the same backup infrastructure for efficiencies in terms of data center space and backup deduplication.

The vCenters that may be used as partner vCenters for DR relationships.

The Enterprise Hybrid Cloud object model enforces the rule that vCenters in a DR relationship must contain two distinct sites.

From a metadata perspective, a site object contains just one user-defined property, that

is, the user-provided name for the site.

Viewing the

object model in

vRealize

Orchestrator

Sites



Enterprise Hybrid Cloud supports up to four Enterprise Hybrid Cloud-managed VMware

vCenter endpoints. Each managed vCenter endpoint can be configured as a vRealize

Automation endpoint with the ability to provide any of the following services (as relevant):

Infrastructure as a service (IaaS)

Storage as a service (STaaS)

Backup as a service (BaaS)

Disaster recovery as a service (DRaaS)

Note: The VxRail Appliance does not use STaaS in Enterprise Hybrid Cloud 4.1.2 because all

vSAN storage on the VxRail Appliance is pre-provisioned at deployment time.

To facilitate DRaaS, each vCenter endpoint may be configured with a vCenter partner for

VMware vCenter Site Recovery Manager (VMware SRM) or RecoverPoint for Virtual

Machines purposes. This allows the solution to scale out in the following ways:

Increases the number of workload virtual machines that may be protected by either SRM or RecoverPoint for Virtual Machines

Increases the number of target sites that workloads can be protected to (via different vCenter DR relationships)

vCenter endpoints can be added to the Enterprise Hybrid Cloud model as a Day 2

operation through the vRealize Automation Catalog item vCenter Endpoint

Maintenance.

Hardware islands allow multiple converged infrastructure platforms to be logically

aggregated (for scale) or partitioned (for isolation) inside a single vCenter while retaining

awareness of physical network, storage, and site boundaries. You can then use this

awareness to ensure that correct inter-site and intra-site protection services are applied to

cloud workloads. As a result, the hardware island concept is the key determining factor in

configuring vSphere clusters that offer inter- or intra-site resilience, that is, these services

must span more than one hardware island by definition.

The properties of a hardware island can be defined as:

A set of ESXi clusters and ViPR virtual arrays (ViPR virtual arrays properties are not required in a VxRail Appliance configuration).

Note: When only vSAN Storage on One Site (VS1S) clusters from a VxRail Appliance are

included in a hardware island, adding virtual arrays to the hardware island is not required.

Belonging to only one vCenter. Therefore, clusters assigned to a hardware island must be from the corresponding vCenter.

Smaller than a single storage area network (SAN) or storage array (in line with the capability of a virtual array.

Can include multiple storage arrays if they are all in the same storage area network.

Note: This does not apply to VxRail Appliance.

vCenter

endpoints

Hardware

islands



Solution Guide

Including items from different storage area networks if all clusters and arrays assigned to the hardware island are connected to each of those networks. This allows for independent SAN fabrics for redundancy.

Note: A ViPR virtual array may not be a member of more than one hardware island.

Note: A vCenter can contain multiple hardware islands.

Note: When workloads reside on different hardware islands on the same site, they may share the

same backup infrastructure, if required.

A cluster object is created in the Enterprise Hybrid Cloud object model when a vSphere

cluster is onboarded through the vRealize Automation catalog. When clusters are

onboarded, each cluster must be given a type, which then dictates the type of storage that

may be provisioned to the cluster. Table 3 shows the cluster types available in the model.

Table 3. Cluster types

Datastore type Storage description

LC1S Local Copy on One Site

VS1S vSAN Storage on One Site (not used by STaaS)

CA1S CA VPLEX Metro Storage on One Site

CA2S CA VPLEX Metro Storage across Two Sites

DR2S DR Dell EMC RecoverPoint Storage across Two Sites

Note: VS1S clusters currently only apply to VxRail Appliance converged infrastructure systems.

Note: Refer to the Enterprise Hybrid Cloud Support Matrix for up-to-date information on supported

converged systems.

Dell EMC RecoverPoint for Virtual Machines workloads use LC1S clusters, as the storage

is single-site storage and workloads are selectively replicated by EMC RecoverPoint for

Virtual Machines rather than underlying logical unit number (LUN)-level storage

technology.

Datastore objects are created in the Enterprise Hybrid Cloud model when a storage

provisioning operation is carried out by STaaS workflows against an onboarded Enterprise

Hybrid Cloud cluster. The cluster type is used to guide the user to provision only suitable

storage to that cluster.

After a datastore object is created, the datastore properties regarding its service level

offering (Storage Reservation Policy), and other details that support the BaaS operations,

are recorded.

VS1S datastores are not created by STaaS but are ingested into the object model when a

VS1S cluster is onboarded.

Clusters

Datastores



Table 4 shows the available datastore types that can be created, in keeping with the

cluster types that may be onboarded.

Table 4. Datastore types

Cluster type Storage description

LC1S Local Copy on One Site

VS1S vSAN Storage on One Site (not used by STaaS)

CA1S CA VPLEX Metro Storage on One Site

CA2S CA VPLEX Metro Storage across Two Sites

DR2S DR RecoverPoint Storage across Two Sites

Chapter 4: Multisite and Multi-vCenter Protection Services


Solution Guide

Chapter 4 Multisite and Multi-vCenter Protection Services


vCenter endpoint types .................................................................................... 26

SSO domain types ............................................................................................ 26

Protection services ........................................................................................... 27

Single-site protection service .......................................................................... 29

Continuous Availability (Single-site) protection service ................................ 30

Continuous Availability (Dual-site) protection service ................................... 32

Disaster recovery (RecoverPoint for Virtual Machines) protection service .. 34

Disaster recovery (VMware Site Recovery Manager) protection service ...... 35

Combining protection services ........................................................................ 36

Scale considerations ........................................................................................ 48

Multi-vCenter and multisite topologies ........................................................... 50



vCenter endpoint types

An Enterprise Hybrid Cloud-managed vCenter endpoint implies that the endpoint, when

configured as a vRealize Automation endpoint, can use the virtual-machine lifecycle

operations provided as part of vRealize Automation, and can use the value-add Enterprise

Hybrid Cloud as-a-service offerings.

An IaaS vCenter endpoint implies that the endpoint, when configured as a vRealize

Automation endpoint, can only use the virtual-machine lifecycle operations provided as

part of vRealize Automation and cannot use the Enterprise Hybrid Cloud as-a-service

offerings.

Table 5 shows a side-by-side comparison of vCenter endpoint types.

Table 5. vCenter endpoint types comparison

Feature Managed vCenter endpoint IaaS vCenter endpoint

Services supported

IaaS (vRealize Automation Native Functionality)

STaaS

Continuous Availability

DRaaS

BaaS

IaaS (vRealize Automation Native Functionality)

Note: STaaS and DRaaS are not available on VxRail Appliance platforms in Enterprise Hybrid

Cloud 4.1.2.

SSO domain types

An Enterprise Hybrid Cloud-managed single sign-on (SSO) domain hosts managed

vCenter endpoints (refer to Enterprise Hybrid Cloud-managed vCenter endpoint).

When the Enterprise Hybrid Cloud management platform is running on a VxBlock or

VxRack System FLEX:

vRealize Orchestrator uses SSO as the authentication mechanism to support all

forms of protection services.

As a result, all managed vCenter endpoints configured in the Enterprise Hybrid

Cloud instance must be part of the same (managed) SSO domain.

There should be only one managed SSO domain per hybrid cloud instance.

A managed SSO domain can also host IaaS-only vCenter endpoints, if required, up

to the maximum number of vCenter endpoints configured per domain (refer to

vCenter maximums).

When the Enterprise Hybrid Cloud management platform is running on a VxRail:

vRealize Orchestrator uses vRealize Automation as the authentication mechanism.

Enterprise

Hybrid Cloud-

managed

vCenter endpoint

Infrastructure-

as-a-service

vCenter endpoint

vCenter endpoint

types

comparison

Enterprise

Hybrid Cloud-

managed SSO

domains



Solution Guide

Each managed vCenter endpoint may be in its own managed SSO domain.

There can be as many managed SSO domains as there are managed vCenter

endpoints (up to the maximum number of managed vCenter endpoints supported

by Enterprise Hybrid Cloud).

VxRail Appliances that run their own PSC (and therefore their own SSO domain)

can only host a single vCenter endpoint, which can be either a managed or an

IaaS-only endpoint.

An IaaS-only SSO domain only hosts IaaS vCenter endpoints. The domain may host more

than one IaaS vCenter endpoint. Enterprise Hybrid Cloud can support multiple IaaS-only

SSO domains up to the maximum number of SSO Domains permitted per hybrid cloud

instance (refer to SSO maximums).

Protection services

Enterprise Hybrid Cloud provides the following intra-site and inter-site protection features,

which can be combined to offer multiple tiers of service to different workloads within the

same Enterprise Hybrid Cloud deployment. The attributes of the protection services are:

Converged/hyper-converged infrastructure redundancy—Virtual machine workloads benefit from the redundancy of the internal components of a converged infrastructure platform, such as VxRail Appliances, VxRack Systems, or VxBlock Systems, including redundant compute, network, and storage components.

Inter-converged/hyper-converged infrastructure redundancy—Virtual machine workloads are insulated against the failure of a converged/hyper-converged infrastructure platform by replicating that workload to a second converged infrastructure platform on the same site.

Inter-site redundancy—Virtual machine workloads are insulated against failure of an entire site location by replicating that workload to a second converged infrastructure platform on an alternate site.

Local backup—Virtual machine workloads can be backed up locally to shared backup infrastructure with a single copy of each backup image retained.

Replicated backup—Virtual machine workloads can be backed up locally to shared backup infrastructure, and each backup image is replicated to, and restorable from, a shared backup infrastructure on an alternate site.

Note: When both local and replicated backup options are available within the Enterprise Hybrid

Cloud environment, the backup type applied to a given virtual machine workload matches the level

of intra- or inter-site protection applied to the workload itself, for example, a workload protected

using DR protection service is automatically assigned a replicated backup.

Enterprise Hybrid Cloud offers several types of protection services:

Single-site protection—Suitable when you have just a single site and do not require inter-site protection. It can be used in its own right or as the base deployment on top of which you can layer additional multisite protection services. It is designed to permit use of shared backup infrastructure with non-replicated backups.

Infrastructure-

as-a-service SSO

domain

Protection

service

availability

attributes

Protection

service offerings



Continuous Availability (Single-site) protection—Suitable when you want to provide additional resilience for single-site workloads. It is designed to provide storage and compute resilience for workloads on the same site, using shared backup infrastructure but maintaining non-replicated backups.

Continuous Availability (Dual-site) protection—Suitable when you want to provide inter-site resilience for workloads and have two sites within a 10 ms latency of each other. It is designed to provide storage and compute resilience for workloads across sites, using local shared backup infrastructure and replicating backup images between sites.

Disaster recovery (RecoverPoint for Virtual Machines) protection—Suitable when you want to provide inter-site resilience for workloads, with individual workload level failover, but have sites greater than 10 ms latency apart. It is designed to provide storage and compute resilience for workloads across sites, using local shared backup infrastructure and replicating backup images between sites.

Disaster recovery (Site Recovery Manager) protection—Suitable when you want to provide inter-site resilience for workloads, but have sites greater than 10 ms latency apart and where recovering virtual machine workloads at the ESXi cluster level of granularity is acceptable. It is designed to provide storage and compute resilience for workloads across sites, using local shared backup infrastructure and replicating backup images between sites.

The detailed features of each protection service are described in subsequent sections.

Table 6 presents the protection types and their attributes.

Table 6. Available Enterprise Hybrid Cloud protection services

Protection service

Converged/ hyper-converged infrastructure redundancy

Inter-converged/hyper-converged infrastructure redundancy

Inter-site

redundancy

Local backup

Replicated backup

Single site √ √


(Single-site) √ √ √


(Dual-site) √ √ √ √ √

Disaster recovery (RecoverPoint for Virtual Machines)

√ √ √ √ √

Disaster recovery (Site Recovery Manager)

√ √ √ √ √



Solution Guide

Single-site protection service

Figure 6 shows an example of single-site protection service, where multiple vCenters and

hardware islands are used on a single site, managed by Enterprise Hybrid Cloud.

Figure 6. Enterprise Hybrid Cloud single-site service

The single-site protection service has the following attributes:

Allows a maximum of four VMware vCenter endpoints to be configured for use as Enterprise Hybrid Cloud-managed vCenter endpoints. This allows up to four sites to be configured when no other protection service is available.

Each vCenter endpoint can have between one and four hardware islands configured (where a hardware island is an island of compute and storage such as a converged infrastructure).

Workloads that use this protection service are bound by the confines of the site to which they were deployed such that:

Virtual machine workloads cannot be restarted on any other sites.

Virtual machine backup images are not replicated to any another site.

There is no inter-converged infrastructure (intra-site) protection available to the virtual machine workloads.

Workloads on any vCenter, hardware island, or cluster may share the same backup infrastructure.

Architecture



Continuous Availability (Single-site) protection service

Figure 7 displays an example of Continuous Availability (Single-site) protection service,

where one vCenter and two hardware islands are used on a single site, managed by


Figure 7. Enterprise Hybrid Cloud Continuous Availability (Single-site) service

The Continuous Availability (Single-site) protection service has the following attributes:

This service allows a maximum of four vCenter endpoints to be configured for use as Enterprise Hybrid Cloud-managed vCenter endpoints. This allows up to four sites to be configured like this when no other protection services are available.

Each vCenter endpoint may have between one and four hardware islands configured (where a hardware island is an island of compute and storage, such as a converged infrastructure).

Workloads using this protection service are bound by the confines of the site to which they were deployed such that:

Virtual machine workloads cannot be restarted on any other sites.

Virtual machine backup images are not replicated to any another site.

Architecture



Solution Guide

Virtual machine workloads using this service may be recovered from one converged infrastructure platform to another on the same site using VMware vSphere Metro Stretched Cluster backed by Dell EMC VPLEX Metro™ storage.

This combination allows the use of VMware vSphere vMotion for proactive

movement of workloads before a known event, or the use of vSphere HA for

reactive restart of those workloads if an unpredicted failure event occurs.

Workloads may exist on both sides of the continuous availability clusters in active/active fashion.

Workloads on any vCenter, hardware island, or cluster may use shared backup infrastructure.

When single-site continuous availability is deployed, there are two copies of storage

volumes on the same site controlled by VPLEX Metro. In this case, each leg of the

stretched cluster is provided by a different hardware island associated with the same

vCenter and the same site. Each hardware island should be backed by a different

converged infrastructure platform (such as VxBlock Systems) to provide inter-converged

infrastructure redundancy.

To maximize uptime of workloads in a failure scenario, virtual machine workloads

deployed to a CA1S (CA VPLEX Metro Storage on One Site) cluster are automatically

added to VMware DRS affinity groups. The affinity group that an individual workload is

associated with is based on the storage chosen by the user, and the hardware island that

hosts the winning leg for that distributed storage if a storage partition event occurs.

As a result, only the failure of the winning leg of a distributed storage volume requires a

vSphere HA restart of that virtual machine workload on another member of the vSphere

cluster that is associated with the other hardware island.

To make use of single-site continuous availability protection, the

hwi_srp_policy_enabled Enterprise Hybrid Cloud global option must be set to True. This

ensures that Enterprise Hybrid Cloud STaaS operations create VMware vRealize Storage

Reservation Policies (SRPs) that convey to the user which hardware island is the winning

site when selecting storage for use by a virtual machine workload.

Changing the value of this option can be done with the vRealize Automation catalog

Global Options Maintenance item.

If the Enterprise Hybrid Cloud management stack is protected by single-site continuous

availability, then the management component virtual machines should be configured in

affinity groups in a similar way as tenant workloads. This is done as part of the Enterprise

Hybrid Cloud deployment process.

Hardware island

affinity for tenant

virtual machines

Hardware island

affinity for

management

platform

machines



Continuous Availability (Dual-site) protection service

Figure 8 shows an example of Continuous Availability (Dual-site) protection service,

where one vCenter and two hardware islands are used across two different sites, and

managed by Enterprise Hybrid Cloud.

Figure 8. Enterprise Hybrid Cloud Continuous Availability (Dual-site) service

The Continuous Availability (Dual-site) protection service has the following attributes:

This service allows a maximum of four vCenter endpoints to be configured for use as Enterprise Hybrid Cloud-managed vCenter endpoints. This allows up to eight sites to be configured in this manner when no other protection services are available.

Each vCenter endpoint may have between one and four hardware islands configured (where a hardware island is an island of compute and storage such as a converged infrastructure).

Workloads using this protection service may operate on either of the two sites participating in any given CA relationship such that:

Virtual machine workloads may be restarted on either of the two sites.

Virtual machine backup images are replicated to the other site and are available for restore.

Virtual machine workloads using this service may be recovered from one converged infrastructure platform to another on different sites using vSphere Metro Stretched

Architecture



Solution Guide

Cluster backed by VPLEX Metro storage. This combination allows the use of VMware vSphere vMotion for proactive movement of workloads before a known event or the use of vSphere HA for the reactive restart of those workloads if an unpredicted failure event occurs.

Workloads may exist on both sides of the continuous availability clusters in active/active fashion.

Workloads on hardware islands or clusters on the same site may all use the shared backup infrastructure local to that site. When workloads move to the other site, the shared backup infrastructure on that site takes ownership of executing backups for those workloads.

When dual-site continuous availability is deployed, there are two copies of storage

volumes on different sites controlled by VPLEX Metro. In this case, each leg of the

stretched cluster is provided by a different hardware island, on a different site, but

associated with the same vCenter. Each hardware island should be backed by a different

converged infrastructure platform (such as VxBlock Systems) to provide inter-converged

infrastructure redundancy.

To maximize uptime of workloads in a failure scenario, virtual machine workloads

deployed to a CA2S (CA VPLEX Metro Storage across Two Sites) cluster are

automatically added to VMware DRS affinity groups. These groups are used to subdivide

the vSphere ESXi hosts in each workload cluster into groupings of hosts corresponding to

their respective sites.

The specific affinity group that an individual workload is associated with is based on the

storage chosen by the user and the hardware island or site that hosts the winning leg for

that distributed storage, if a storage partition event occurs.

As a result, only the failure of the winning leg of a distributed storage volume requires a

vSphere HA restart of that virtual machine workload on another member of the vSphere

cluster that is associated with the other hardware island.

If the Enterprise Hybrid Cloud management stack is protected by dual-site continuous

availability then the management component virtual machines should be configured in

affinity groups in a similar fashion to tenant workloads. This is done as part of the

Enterprise Hybrid Cloud deployment process.

Site affinity for

tenant virtual

machines

Site affinity for

management

platform

machines



Disaster recovery (RecoverPoint for Virtual Machines) protection service

Figure 9 displays an example of a RecoverPoint for Virtual Machines-based disaster

recovery protection service, where two vCenters and two hardware islands are used

across two different sites, and managed by Enterprise Hybrid Cloud.

Figure 9. Enterprise Hybrid Cloud (EMC RecoverPoint for Virtual Machines) disaster recovery service

The RecoverPoint for Virtual Machines-based disaster recovery protection service has the

following attributes:

This service allows a maximum of four vCenter endpoints to be configured for use as Enterprise Hybrid Cloud-managed vCenter endpoints. This allows up to four sites to be configured when no other protection services are available.

Each vCenter endpoint may have between one and four hardware islands configured (where a hardware island is an island of compute and storage, such as a converged infrastructure).

Workloads using this protection service may operate on either of the two sites participating in any given DR relationship such that:

Virtual machine workloads may be recovered on either of the two sites.

Virtual machine backup images are replicated to the other site and are available for restore

Architecture



Solution Guide

Virtual machine workloads using this service may be individually recovered from one converged infrastructure platform to another, on different sites, using the failover mechanisms provided by RecoverPoint for Virtual Machines.

Tenant workload clusters are logically paired across vCenters and sites to ensure networking and backup policies operate correctly both before and after failover.

Workloads may exist on both sides of the cluster pairing in active/active fashion.


Disaster recovery (VMware Site Recovery Manager) protection service

Figure 10 shows an example of the VMware SRM-based disaster recovery service, where

two vCenters and two hardware islands are used across two different sites, and managed

by Enterprise Hybrid Cloud.

Figure 10. Enterprise Hybrid Cloud (VMware Site Recovery Manager) disaster recovery service

The SRM-based disaster recovery protection service has the following attributes:

This service allows a maximum of two vCenter endpoints to be configured for use as Enterprise Hybrid Cloud-managed vCenter endpoints. This allows up to two sites to be configured in this manner when no other protection service is available.

Architecture



Note: Only one Enterprise Hybrid Cloud-managed vCenter DR pair is permitted to

offer VMware SRM-based disaster recovery protection services.

Each vCenter endpoint may have between one and four hardware islands configured (where a hardware island is an island of compute and storage such as a converged infrastructure).

Workloads using this protection service may operate on either of the two sites participating in any given DR relationship such that:

Virtual machine workloads may be recovered on either of the two sites.

Virtual machine backup images are replicated to the other site and are available for restore.

Tenant workload clusters are logically paired across vCenters and sites to ensure networking and backup policies operate correctly both before and after failover, and failover is at a cluster-level granularity, in that all virtual machine workloads on a specified cluster pair must fail over and back as a unit.

Virtual machine workloads using this service can recover from one converged infrastructure platform to another on a different site using the failover mechanisms provided by VMware SRM.

Workloads may exist on only one side of the cluster pairing in active/passive fashion. Additional active/passive clusters in an opposite configuration are required to achieve active/active sites.


Combining protection services

Protection services may be combined within a single Enterprise Hybrid Cloud environment

to offer the multiple tiers of service within the same hybrid cloud. The protection levels

described earlier can be combined in the following ways:

Two services: Single site plus RecoverPoint for Virtual Machines DR

Two services: Single site plus VMware Site Recovery Manager-based DR

Three services: Single site plus single/dual-site CA

Three services: Single site plus RecoverPoint for Virtual Machines DR plus Site Recovery Manager DR

Four services: Single site plus single/dual-site CA and RecoverPoint for Virtual Machines-based DR

Four services: Single site plus single/dual-site CA and Site Recovery Manager-based DR

Five services: Single site, single/dual-site CA, RecoverPoint for Virtual Machines-based DR, and Site Recovery Manager-based DR



Solution Guide

The RecoverPoint for Virtual Machines-based disaster recovery service inherently offers

both single-site and RecoverPoint for Virtual Machines protection services, because the

compute and storage resources to provide both options are the same.

When RecoverPoint for Virtual Machines-based DR is deployed in Enterprise Hybrid

Cloud, any virtual machine workload can be individually “toggled” from the single-site

protection service to RecoverPoint for Virtual Machines protection service and back again,

as required. When this is done, the backup protection level automatically changes from

local to replicated backup as appropriate.

Figure 11 shows an example where RecoverPoint for Virtual Machines has been deployed

within the Enterprise Hybrid Cloud environment, using two vCenter endpoints.

Figure 11. Combining single-site and RecoverPoint for Virtual Machines-based disaster recovery protection services

Figure 11 shows an example where two protection services are provided within the same

Enterprise Hybrid Cloud environment, using a single vCenter endpoint:

Single-site workloads—These workloads are not associated with any RecoverPoint for Virtual Machines replication components. Backups occur to the relevant local backup infrastructure only. In Figure 11, these workloads reside on the compute resource labeled Local/RP4VM Clusters.

RecoverPoint for Virtual Machines workloads—RecoverPoint for Virtual Machines protected workloads are associated with the RecoverPoint for Virtual Machines replication components. Backups occur to the relevant local backup

Two services:

Single site plus

RecoverPoint for

Virtual Machines

DR



infrastructure, and are replicated to the backup infrastructure on the other site. In Figure 11, these workloads reside on the compute resource labeled Local/RP4VM Clusters.

Additional vCenters can be added to provide additional scale, or to provide the same type

of protection service between a different combination of sites.

When single-site and SRM-based disaster recovery protection levels are combined in an

Enterprise Hybrid Cloud environment, virtual machine workloads can choose from two

different tiers of protection service, as shown in Figure 12.

Figure 12. Combining single site and Site Recovery Manager-based disaster recovery protection services

Figure 12 shows an example where both protection services are provided within the same

Enterprise Hybrid Cloud environment, using two vCenter endpoints:

Single-site workloads—Are automatically directed to compute resources, storage, and backup policies that reflect that tier of service, that is, non-replicated storage and non-replicated backups. They are not associated with SRM replication components. In Figure 12, these workloads reside on the compute resource labelled Local Clusters. Backups occur to the relevant local backup infrastructure only.

Site Recovery Manager workloads—SRM-protected workloads are associated with SRM replication components. Backups occur to the relevant local backup

Two services:

Single site plus

VMware Site

Recovery

Manager-based

DR



Solution Guide

infrastructure, and are replicated to the backup infrastructure on the other site. In Figure 12, these workloads reside on the compute resource labeled DR Clusters.

Additional vCenters can be added to provide additional scale, or to provide the same type of protection service between a different combination of sites.

Note: Only one Enterprise Hybrid Cloud-managed vCenter DR pair is permitted to offer

Site Recovery Manager-based disaster recovery protection services.

When single-site and continuous availability protection levels are combined in an

Enterprise Hybrid Cloud environment, virtual machine workloads can choose from three

different tiers of protection service, as shown in Figure 13.

Figure 13. Combining single-site and continuous availability protection services

Figure 13 shows an example where all three protection services are provided within the

same Enterprise Hybrid Cloud environment, using a single vCenter endpoint:

Single-site workloads—Are automatically directed to compute resources, storage, and backup policies that reflect that tier of service, that is, non-replicated storage and non-replicated backups. In Figure 13 these workloads reside on the compute resource labelled Local Clusters. Backups occur to the backup infrastructure on Site A only.

Three services:

Single site plus

single/dual-site

CA



CA single site—If multiple VPLEX clusters are deployed on the same site, then workloads may make use of the replicated storage on the same site, but continue to use non-replicated backups. In Figure 13 these workloads reside on the compute resource labeled Continuous Availability Clusters (Single Site). Backups occur to the backup infrastructure on Site A only.

CA dual site—If VPLEX clusters are deployed to both sites, then workloads may make use of the replicated storage to a different site, but additionally make use of replicated backups. In Figure 13 these workloads reside on the compute resource labeled Continuous Availability Clusters (Dual Site). Backups occur to the relevant local backup infrastructure and are replicated to the backup infrastructure on the other site.

Additional vCenters can be added to provide the same type of protection service between

a different combination of sites.

When single site, RecoverPoint for Virtual Machines-based disaster recovery and SRM-

based disaster recovery protection levels are combined in an Enterprise Hybrid Cloud

environment, virtual machine workloads can choose from three different tiers of protection

service, as shown in Figure 14.

Figure 14. Combining single site, RecoverPoint for Virtual Machines disaster recovery, and Site Recovery Manager-based disaster recovery protection services

Three services:

Single site plus

RecoverPoint for

Virtual Machines

DR plus Site

Recovery

Manager DR



Solution Guide

In this combination, Site Recovery Manager and RecoverPoint for Virtual Machines

protection services can be provided by the same or different vCenter pairs. Figure 14

shows an example where all three protection services are provided within the same

Enterprise Hybrid Cloud environment, using two vCenter endpoints.

Single-site workloads—These workloads are not associated with any RecoverPoint for Virtual Machines replication components. Backups occur to the relevant local backup infrastructure only. In Figure 14, these workloads reside on the compute resource labeled Local/RP4VM Clusters.

RecoverPoint for Virtual Machines workloads—RecoverPoint for Virtual Machines protected workloads are associated with the RecoverPoint for Virtual Machines replication components. Backups occur to the relevant local backup infrastructure, and are replicated to the backup infrastructure on the other site. In Figure 14, these workloads reside on the compute resource labeled Local/RP4VM Clusters.

Site Recovery Manager workloads—SRM-protected workloads are associated with SRM replication components. Backups occur to the relevant local backup infrastructure, and are replicated to the backup infrastructure on the other site. In Figure 14, these workloads reside on the compute resource labeled DR Clusters.


Note: Only one Enterprise Hybrid Cloud-managed vCenter DR pair is permitted to offer

Site Recovery Manager-based disaster recovery protection services.



When single site, continuous availability, and RecoverPoint for Virtual Machines protection

levels are combined in an Enterprise Hybrid Cloud environment, virtual machine

workloads can choose from four different tiers of protection service, as shown in Figure

15.

Figure 15. Combining single site, continuous availability, and RecoverPoint for Virtual Machines-based disaster recovery protection services

Four services:

Single site plus

single/dual-site

CA and

RecoverPoint for

Virtual

Machines-based

DR



Solution Guide

Figure 15 shows an example where all four protection services are provided within the

same Enterprise Hybrid Cloud environment, using two vCenter endpoints:

Single-site workloads—Are automatically directed to compute resources, storage, and backup policies that reflect that tier of service, that is, non-replicated storage and non-replicated backups. These workloads are not associated with any RecoverPoint for Virtual Machines replication components. In Figure 15, these workloads reside on the compute resource labeled Local/RP4VM Clusters. Backups occur to the relevant local backup infrastructure only.

CA single site—If multiple VPLEX clusters are deployed on the same site, then workloads may make use of the replicated storage on the same site, but continue to use non-replicated backups. In Figure 15, these workloads reside on the compute resource labeled Continuous Availability Clusters (Single Site). Backups occur to the backup infrastructure on Site A only.

CA dual site—If VPLEX clusters are deployed to both sites, then workloads may make use of the replicated storage to a different site, but additionally make use of replicated backups. In Figure 15, these workloads reside on the compute resource labelled Continuous Availability Clusters (Dual Site). Backups occur to the relevant local backup infrastructure and are replicated to the backup infrastructure on the other site.





When single site, continuous availability, and Site Recovery Manager protection levels are

combined in an Enterprise Hybrid Cloud environment, virtual machine workloads can

choose from four different tiers of protection service, as shown in Figure 16.

Figure 16. Combining single site, continuous availability, and Site Recovery Manager-based disaster recovery protection services

Four services:

Single site plus

single/dual-site

CA and Site

Recovery

Manager-based

DR



Solution Guide

Figure 16 shows an example where all four protection services are provided within the

same Enterprise Hybrid Cloud environment, using two vCenter endpoints:

Single-site workloads—Are automatically directed to compute resources, storage, and backup policies that reflect that tier of service, that is, non-replicated storage and non-replicated backups. In Figure 16, these workloads reside on the compute resource labeled Local Clusters. Backups occur to the relevant local backup infrastructure only.


CA dual site—If VPLEX clusters are deployed to both sites, then workloads may make use of the replicated storage to a different site, but additionally make use of replicated backups. In Figure 16, these workloads reside on the compute resource labeled Continuous Availability Clusters (Dual Site). Backups occur to the relevant local backup infrastructure and are replicated to the backup infrastructure on the other site.



Note: Only one Enterprise Hybrid Cloud-managed vCenter DR pairs is permitted to offer Site

Recovery Manager-based disaster recovery protection services.



When single site, RecoverPoint for Virtual Machines-based disaster recovery and SRM-

based disaster recovery protection levels are combined in an Enterprise Hybrid Cloud

environment, virtual machine workloads can choose from five different tiers of protection

service, as shown in Figure 17.

Figure 17. Combining single site, CA, RecoverPoint for Virtual Machines-based disaster recovery, and Site Recovery Manager-based disaster recovery protection services

In this combination, Site Recovery Manager and RecoverPoint for Virtual Machines

protection services can be provided by the same or different vCenter pairs. Figure 17

shows an example where all five protection services are provided within the same

Enterprise Hybrid Cloud environment, using two vCenter endpoints.

Single-site workloads—These workloads are not associated with any RecoverPoint for Virtual Machines replication components. Backups occur to the

Five services:

Single site,

single/dual-site

CA,

RecoverPoint for

Virtual

Machines-based

DR, and Site

Recovery

Manager-based

DR



Solution Guide

relevant local backup infrastructure only. In Figure 17, these workloads reside on the compute resource labeled Local/RP4VM Clusters.


CA dual site—If VPLEX clusters are deployed to both sites, then workloads may make use of the replicated storage to a different site, but additionally make use of replicated backups. In Figure 17, these workloads reside on the compute resource labeled Continuous Availability Clusters (Dual Site). Backups occur to the relevant local backup infrastructure and are replicated to the backup infrastructure on the other site.




Note: Only one Enterprise Hybrid Cloud-managed vCenter DR pairs is permitted to offer Site

Recovery Manager-based disaster recovery protection services.

Note: RecoverPoint for Virtual Machines-based disaster recovery and Site Recovery Manager-

based disaster recovery services can both be provided from the same pair of hardware islands.

Figure 17 shows them in separate hardware islands to show that this is also possible.



Scale considerations

This section provides guidance on the parameters you need to consider when designing a

topology that meets your requirements.

A VxBlock/VxRack FLEX-based management platform uses SSO as the authentication

mechanism. As a result, the scale of the environment is dictated by the limits of a single

SSO domain, and the number of PSC deployed. Table 7 outlines the relevant limits.

Table 7. Scale considerations when running CMP on VxBlock/VxRack FLEX

Scale consideration Limit

Number of vCenter endpoints with full Enterprise Hybrid Cloud services 4*

Number of managed vCenter endpoints that can support the continuous availability single-site and continuous availability dual-site protection services

4

Number of vCenter DR pairs 2

Number of vCenter pairs that can support RecoverPoint for Virtual Machines-based disaster recovery protection service

2

Number of vCenter pairs that may offer SRM-based disaster recovery protection

1

Number of Site Recovery Manager-based disaster recovery protected virtual machine workloads

5,000

Number of managed vCenter endpoints that can support backup as a service

4

*This must be VxBlock/VxRack FLEX-based, because you cannot use VxRail Appliances with

their own SSO domain/vCenter endpoint.

Scale

considerations

with a

VxBlock/VxRack

FLEX-based

management

platform



Solution Guide

A VxRail Appliance-based management platform uses vRealize Automation as the

authentication mechanism. As a result, the scale of the environment is not affected by the

limits of a single SSO domain, resulting in a different set of maximums. Table 8 outlines

the relevant limits.

Table 8. Scale considerations when running CMP on a VxRail Appliance


Number of vCenter endpoints with full Enterprise Hybrid Cloud services 4

Number of managed vCenter endpoints that can support the continuous availability single-site and continuous availability dual-site protection services

0*

Number of vCenter DR pairs 2**

Number of vCenter pairs that can support RecoverPoint for Virtual Machines-based disaster recovery protection service

2

Number of vCenters pairs that may offer SRM-based disaster recovery protection

0

Number of Site Recovery Manager-based disaster recovery protected virtual machine workloads

0

Number of Managed vCenter endpoints that can support backup as a service

4

*Continuous Availability is not supported in a VxRail Appliance-based CMP environment.

**You must use RecoverPoint for Virtual Machines-based disaster recovery only.

Table 9 shows the common scale considerations that apply irrespective of the type of

converged infrastructure the Cloud Management Platform (CMP) runs on.

Table 9. Common scale considerations


Number of Associated Hardware Islands per managed vCenter endpoint 4

Number of vCenter DR partners per managed vCenter endpoint 1

Number of RecoverPoint for Virtual Machines-based disaster recovery protected virtual machine workloads per vCenter pair

1,024*

Number of virtual machines across the full solution assuming full a vCenter count

35,000

*If you protect the Automation Pod using RecoverPoint for Virtual Machines, then the vCenter DR

pair that supports the Automation Pod can only support 896 individually protected tenant virtual

machine workloads as a consequence.

Scale

considerations

with a VxRail

Appliance-based

management

platform

Common scale

considerations



Multi-vCenter and multisite topologies

This section provides sample topologies. You can use these samples along with the

information in Scale considerations to inform your decision making when designing a

topology to meets your requirements.

Figure 18 shows how four vCenters on the same site might be deployed. The first vCenter

requires the full management stack while other vCenters require just the endpoint

management stack.

Figure 18. Four vCenters on one site sample topology

The type of topology shown in Figure 18 is suitable when you:

Have a single site but have multiple vCenter endpoints

Want to provide STaaS and BaaS services to all vCenters on the site

Sample

topology: Four

vCenters on a

single site



Solution Guide

Figure 19 shows how four vCenters across five sites might be deployed. The first vCenter

requires the full management stack to be deployed, and in this example that vCenter is

protected via continuous availability between sites. Subsequent vCenters require just the

endpoint management stack.

Figure 19. Four vCenters across five sites with all services sample topology

Sample

topology: Four

vCenters across

five sites with all

protection

services




Have five geographical sites

Want to provide STaaS, BaaS, and DRaaS services to all sites/vCenters

Want to provide CA services to Site A and Site B vCenters

Have two sites with 10 ms latency of each other to provide Continuous Availability (Dual-site) protection

Have other sites that exceed 10 ms latency from each other but that still need inter-site protection for virtual machine workloads. In this case, the topology offers RecoverPoint for Virtual Machines disaster recovery and Site Recovery Manager-based disaster recovery protection for those workloads.

Figure 20 shows how four vCenters across four sites might be deployed. The first and

second vCenters both require the full management stack in this example because the

Automation Pod is to be protected between sites A and B via either Site Recovery

Manager or RecoverPoint for Virtual Machines. Subsequent vCenters require just the

endpoint management stack.

Figure 20. Four vCenters across four sites with DR services sample topology


Have four sites and four vCenters


Want to provide inter-site protection for the management platform.

Want to provide both RecoverPoint for Virtual Machines and Site Recovery Manager-based disaster recovery protection services to virtual machine workloads

Do not want to provide continuous availability protection services, or the distances between sites exceed 10 ms and therefore preclude that option

Sample

topology: Four

vCenters across

four sites with

RecoverPoint for

Virtual Machines

and SRM-based

DR protection

services



Solution Guide

Figure 21 shows how four vCenters across three sites might be deployed. The first

vCenter and second vCenters between Site A and Site B both require the full

management stack to be deployed, because the Automation Pod is protected between

those vCenters using RecoverPoint for Virtual Machines. Subsequent vCenters require

just the endpoint management stack.

Figure 21. Four vCenters across three sites with DR services sample topology


Have three sites and four vCenters

Want to provide STaaS, BaaS, and DRaaS services for all sites/vCenters


Want to provide both RecoverPoint for Virtual Machines and Site Recovery Manager-based disaster recovery protection services to virtual machine workloads


Figure 22 shows another example of how four vCenters across four sites might be

deployed. The first vCenter and second vCenters both require the full management stack

to be deployed, because the Automation Pod is protected between those vCenters using

Site Recovery Manager. Subsequent vCenters require just the endpoint management

stack.

Sample

topology: Four

vCenters across

three sites with

RecoverPoint for

Virtual Machines

and SRM-based

DR protection

services

Sample

topology: Four

vCenters across

four sites with

SRM-based DR

protection

service and

remote

endpoints



Figure 22. Four vCenters across four sites including SRM and two remote/branch endpoints



Want to provide STaaS and BaaS services for all sites/vCenters.

Want to provide DR services between two sites/vCenters only

Want to provide just Site Recovery Manager-based disaster recovery protection services to virtual machine workloads between those two sites

Want to provide single-site protection only to the remaining two sites/vCenters





to be deployed, because the Automation Pod is protected between those vCenters using

RecoverPoint for Virtual Machines. Subsequent vCenters require just the endpoint

management stack.

Sample

topology: Four

vCenters across

four sites with

RecoverPoint for

Virtual Machines

-based DR

protection

service and

remote

endpoints



Solution Guide

Figure 23. Four vCenters across four sites including RecoverPoint for Virtual Machines and two remote/branch endpoints



Want to provide STaaS and BaaS services for all sites/vCenters.

Want to provide DR services between two sites/vCenters only

Want to provide just RecoverPoint for Virtual Machines-based disaster recovery protection services to virtual machine workloads between those two sites

Want to provide single-site protection only to the remaining two sites/vCenters





to be deployed, as the Automation Pod is protected between those vCenters using

RecoverPoint for Virtual Machines. Subsequent vCenters require just the endpoint

management stack.

Sample

topology: Four

vCenters across

four sites

RP4VM-based

DR protection

service



Figure 24. Four vCenters across four sites with RecoverPoint for Virtual Machines protection




Want to provide just RecoverPoint for Virtual Machines-based disaster recovery protection services to virtual machine workloads

Want to provide inter-site protection for the management platform


Chapter 5: Network Considerations


Solution Guide

Chapter 5 Network Considerations


Overview ............................................................................................................ 58

Cross-vCenter VMware NSX ............................................................................. 58

Logical network considerations ....................................................................... 59

Network virtualization ....................................................................................... 59

Network requirements and best practices ...................................................... 62

Enterprise Hybrid Cloud validated network designs using VMware NSX ..... 66



Overview

Enterprise Hybrid Cloud provides a network architecture that is resilient in the event of

failure, enables optimal throughput, and provides secure separation.

This chapter presents a number of generic logical network topologies, details on the

requirements for networking under the different protection services available within

Enterprise Hybrid Cloud and the networking designs that are pre-validated by Enterprise

Hybrid Cloud.

Cross-vCenter VMware NSX

Enterprise Hybrid Cloud permits the use of cross-vCenter VMware NSX networking

objects in all except the Site Recovery Manager-based DR protection service.

This feature allows multiple NSX managers to be federated together in a

primary/secondary relationship. This enables the deployment of NSX network and security

components across multiple vCenters.

These cross-vCenter network and security components are referred to as “universal” and

can only be managed on the primary manager. Some network and security objects are not

universal; they are referred to as standard or local objects, and must be managed from

their associated NSX manager. Replication of universal objects takes place from the

primary NSX managers to the secondary managers so that each manager has the

configuration details for all universal objects. This allows a secondary NSX manager to be

promoted if that primary NSX manager has failed.

The universal distributed logical router (UDLR) and the universal logical switch (ULS) are

used to span networks and create east-west routing across vCenters.

Note: The version of vRealize Automation used with Enterprise Hybrid Cloud 4.1.2 supports

universal network objects. Enterprise Hybrid Cloud supports universal network objects under all

protection services except Site Recovery Manager-based disaster recovery.

The universal section of the Distributed Firewall (DFW) and universal security group can

be used to apply firewall rules across vCenters.

Note: While the version of vRealize Automation used with Enterprise Hybrid Cloud 4.1.2 supports

universal security objects, Enterprise Hybrid Cloud disaster recovery protections services currently

support only standard NSX security objects.

There is a single primary NSX manager and a single universal controller cluster in a

cross-vCenter NSX environment, therefore the placement and protection of these

components must be considered carefully. The primary NSX manager is connected to one

of cloud vCenters in the Enterprise Hybrid Cloud system. The universal controllers cluster

can only be deployed to clusters that are part of that cloud vCenter.

Introduction to

Enterprise

Hybrid Cloud

networking

Using cross-

vCenter NSX

Universal

network objects

Universal

security objects

Protecting the

primary NSX

manager and the

universal

controller cluster



Solution Guide

If the Enterprise Hybrid Cloud system uses VPLEX to support either Continuous

Availability (Single-site) or Continuous Availability (Dual-site) protection, then the primary

NSX manager and the universal controller cluster should be VPLEX protected with the

higher of the two levels available.

Logical network considerations

There must be at least one distributed vSwitch in the cloud vCenter if NSX is in use.

Multiple distributed vSwitches are supported.

Note: While the minimum is one distributed vSwitch per vCenter, Dell EMC recommends two

distributed switches in the Cloud vCenter. The first distributed switch should be used for cloud

management networks and the second distributed switch for tenant workload networks. The

sample layouts provided later in this chapter use this model and indicate which networks are on

each distributed switch by indicating vDS1 or vDS2. Additional distributed switches can be created

for additional tenants if required.

Enterprise Hybrid Cloud has validated network designs using both Open Shortest Path

First (OSPF) and Border Gateway Protocol (BGP) in DR environments. Dell EMC

recommends BGP over OSPF, but both have been validated.

Note: Dell EMC recommends BGP for DR solutions because it offers more granular control for

path selection and exceeds the flexibility of OSPF in cross vCenter NSX networks.

Network virtualization

Enterprise Hybrid Cloud supports two different virtual networking technologies:

VMware NSX for vSphere (recommended)

VMware vSphere Distributed Switch (VDS) (backed by appropriate technologies)

The dynamic network services with vRealize Automation highlighted in this guide require

NSX. VDS supports static networking configurations only, precluding the use of VXLANs.

Distributed

vSwitch

requirements

Supported

routing

protocols

Supported

technologies



Table 10 compares the attributes, support, and responsibility for various aspects of the

Enterprise Hybrid Cloud protection services when used with, and without, VMware NSX.

Table 10. Comparing Enterprise Hybrid Cloud attributes with and without VMware NSX

Protection service Attributes with NSX Attributes without NSX

Single Site and Continuous Availability (Single-site)

Provides the fully tested and validated load balancer component for vRealize Automation and other Automation Pod components.

vRealize Automation multi-machine blueprints may use networking components provisioned dynamically by NSX.

Supports the full range of NSX functionality supported by VMware vRealize Automation.

Requires a non-NSX load balancer for vRealize Automation and other Automation Pod components. Load balancers listed as supported by VMware are permitted, but support burden falls to VMware and/or the relevant vendor.

vRealize Automation blueprints must use pre-defined vSphere networks only (no dynamic provisioning of networking components is possible.)

Possesses fewer security features due to the absence of NSX.

Reduces network routing efficiency due to the lack of east-west kernel level routing options provided by NSX.

Continuous Availability (Dual-site)


vRealize Automation multi-machine blueprints may use networking components provisioned dynamically by NSX.

Supports the full range of NSX functionality supported by VMware vRealize Automation.

Enables automatic path fail over when the ‘preferred’ site fails.

Enables VXLAN over Layer 2 or Layer 3 DCI to support tenant workload networks being available in both physical locations.

Requires a non-NSX load balancer for vRealize Automation and other Automation Pod components. Load balancers listed as supported by VMware are permitted, but the support burden falls to VMware and/or the relevant vendor.




Requires Layer 2 VLANs present at both sites to back tenant virtual machine vSphere port groups.

Enterprise

Hybrid Cloud

attributes with

and without

VMware NSX



Solution Guide

Protection service Attributes with NSX Attributes without NSX

RecoverPoint for Virtual Machines-based disaster recovery


Does not support inter-site protection of dynamically provisioned VMware NSX networking artefacts.

Supports consistent NSX security group membership by ensuring virtual machines are placed in corresponding predefined standard security groups across sites via Enterprise Hybrid Cloud workflows.

Provides IP mobility and simultaneous network availability on both sites using cross-vCenter NSX network configuration and universal NSX networks objects for both the management pods as well as the tenant workloads.

Honors NSX security tags applied to a virtual machine on the protected site prior to failover.

Requires a non-NSX load balancer for vRealize Automation and other Automation Pod components. Load balancers listed as supported by VMware are permitted, but the support burden falls to VMware and/or relevant vendor.




Requires customer-supplied technology to ensure network is available simultaneously on both sites to enable IP mobility.

Site Recovery Manager-based disaster recovery


Does not support inter-site protection of dynamically provisioned VMware NSX networking artefacts.

Supports consistent NSX security group membership by ensuring virtual machines are placed in corresponding predefined standard security groups across sites via Enterprise Hybrid Cloud workflows.

Allows fully automated network re-convergence for tenant resource pods networks on the recovery site via Enterprise Hybrid Cloud workflows, the redistribution capability of BGP/OSPF and the use of NSX redistribution polices.

Does not honor NSX security tags applied to a virtual machine on the protected site prior to failover.

Requires a non-NSX load balancer for vRealize Automation and other Automation Pod components. Load balancers listed as supported by VMware are permitted, but the support burden falls to VMware and/or relevant vendor.



Reduces network routing efficiency due to lack of east-west kernel level routing options provided by NSX.

Requires customer-supplied IP mobility technology.

Requires manual or customer provided re-convergence process for tenant resource pods on the recovery site.



Enterprise Hybrid Cloud with VMware NSX can coexist with Cisco Application Centric

Infrastructure (ACI), but integration with Cisco ACI is not supported.

Supported with Enterprise Hybrid Cloud RPQ

ACI as data center fabric

In this configuration, the Top-of-Rack (ToR) switches are in NX-OS mode and

connected to ACI leaf switches.

ACI as underlay:

In this configuration, the ToR switches are configured as ACI leaf switches.

The configuration must match the VMware reference design, refer to Design Guide for VMware NSX running with a Cisco ACI Underlay Fabric.

Support for any issues that arise with this configuration is provided by VMware's Network and Security Business Unit (NSBU).

Not supported

ACI integration with vSphere/vCenter.

This includes the use of Cisco AVS or VMM integration (APIC controlled VDS).

Enterprise Hybrid Cloud integration with Cisco ACI.

There are currently no plans to integrate Enterprise Hybrid Cloud with Cisco ACI.

Network requirements and best practices

Single site

Single-site workloads do not migrate from one site to another; therefore, there is no

requirement for IP mobility technology to support this protection level.

Continuous Availability (Single-site)

Single-site continuous availability workloads do not migrate from one site to another;

therefore, there is no requirement for IP mobility technology to support this protection

level.

Continuous Availability (Dual-site)

Continuous availability workloads can operate on either site, or be divided between sites.

As virtual machine workloads may potentially migrate at any time, the network they use

should span sites so that the workloads continue to operate if this happens.

When using VMware NSX, this can be provided by VXLAN technology.

Disaster recovery (Site Recovery Manager)

All SRM-based disaster recovery workloads on a DR2S (DR RecoverPoint storage across

two sites) cluster pair may operate on one site, or the other at any given time. The

networks for that cluster therefore must be active only on the protected side of that cluster

pair. During failover, those networks must be re-converged to the other site so that the

workloads can benefit from using the same IP addressing.

NSX co-

existence with

Cisco ACI

IP mobility

https://communities.vmware.com/docs/DOC-30849

https://communities.vmware.com/docs/DOC-30849



Solution Guide

When using VMware NSX, this can be provided by Enterprise Hybrid Cloud

customizations that dynamically find those networks and interact with multiple NSX

manager instances to achieve that re-convergence.


RecoverPoint for Virtual Machine-based DR workloads may move individually between

sites and vCenter endpoints. This requires that the underlying network infrastructure is

able to support two or more virtual machines with IPv4 addresses from the same subnet,

running on different sites and vCenters at the same time.

When using VMware NSX, this can be achieved using cross-vCenter NSX VXLAN

networking configurations.

Best practices common to all protection services

VMware anti-affinity rules should be used to ensure that the following conditions are true

during optimum conditions:

NSX controllers reside on different hosts

NSX ESGs using ECMP reside on different hosts

NSX DLR Control virtual machines reside on different hosts

NSX ESG and DLR Control virtual machines reside on different hosts

Note: This enforces a four-node minimum on the cluster hosting the NSX Edges and DLRs.

Continuous availability additional best practices

VMware anti-affinity rules should be used to ensure that the following conditions are true

during optimum conditions:

All NSX controllers should reside on a given converged infrastructure (CI) platform/site, and move laterally within that platform/site before moving to the alternate platform/site.

VMware NSX

best practices



Table 11 indicates the effect on NEI Pod sizing of combining VMware NSX best practices

with your chosen Enterprise Hybrid Cloud protection services.

Table 11. Effect on vSphere cluster sizing for hosting the NEI function

Protection services vSphere cluster nodes to host NSX Controllers

vSphere cluster nodes to host NSX Edges/DLRs

Single Site 3 4

Continuous Availability Single Site (NEI function on vSphere Metro storage clusters)

6 8

Continuous Availability Single Site (NEI function on common infrastructure in third fault domain)

3 3

Continuous Availability Single Site (NEI function on one of the two CI platforms)*

3 4

Continuous Availability Dual Site (NEI function on vSphere Metro storage clusters)

6 8

Disaster Recovery (Site Recovery Manager and RecoverPoint for Virtual Machines)**

3 4

*This places a dependency on one of the CI systems, such that the failure of that system could

result in network outage for the remaining CI systems.

**Because there is an independent cluster per site in these configurations, the requirement is per

cluster (that is, per site).

Note: The numbers in Table 11 do not indicate the need for a dedicated vSphere cluster to host

the NEI Pod. They indicate that the cluster must have this number of nodes to facilitate best

practice placement of NEI Pod components. The same cluster (depending on the configuration)

can also host other management pod components, for example, in a VxRail Appliance topology

the same four-node cluster can support Core, NEI, Automation, and Tenant pods.

NEI Pod sizing

considerations



Solution Guide

Table 12 describes the considerations for network traffic and egress when deciding on the

NEI Pod configuration.

Table 12. Traffic and egress considerations

Protection services Considerations

Single Site No special considerations. All traffic bound to single site.

Continuous Availability (Single Site) No inter-site latency considerations. Review NEI Pod sizing considerations as the method of Edge cluster protection may affect routing and bandwidth between CI platforms.

Continuous Availability (Dual Site) To enable local egress on both sides, Dell EMC recommends that you configure separate NSX DLRs that are peered with independent NSX Edge devices per site. Workloads should then be connected to the DLR/Edge combination that is local to their preferred site.

After site failure or majority move of workloads from one site to another, Edge gateways should be migrated to surviving site/site with majority of workload.

Disaster recovery (Site Recovery Manager) Any given network is only active on the protected side of a DR2S cluster pair.

As each member of a cluster pair is in a different vCenter and uses only the NSX Edges relevant to that vCenter and site, there are no special traffic routing considerations for these workloads.


All networks on LC1S clusters are simultaneously spread across two different sites and vCenters.

The NSX Edge gateway for any given network can only reside on one site, or the other. As a result, any virtual machine on that network residing on the opposite site to the Edge gateway must cross inter-site link to exit the network.

After site failure or a majority move of workloads from one site to another, networks should be re-converged to route through Edge gateways on a surviving site/site with the majority of the workload.

Traffic ingress

and egress

considerations



Enterprise Hybrid Cloud validated network designs using VMware NSX

While Enterprise Hybrid Cloud provides the following validated network designs, many

other custom designs are possible and permitted as long as those designs provide the

basic network requirements outlined in Network requirements and best practices. You

should work with your account team and professional services team to design the network

configuration that is most suited to your deployment needs.

Figure 25 shows an example of an environment that uses the VMware NSX-based

network configuration for the single-site protection service, as tested and validated by


Figure 25. Verified single site network configuration

Custom network

designs

Single-site

network design



Solution Guide

Supported configurations

While the diagram in Figure 25 shows the use of standard (local) DLRs and logical

switches, if multiple vCenter instances are present on the same site, then universal DLRs

and logical switches are also supported, although they would not provide any additional

benefits in this scenario.

Normal operation

Under normal operating conditions, the network operates as follows:

Egress from the DLR—Routes learned by the ESGs from the ToR switches via External Border Gateway Protocol (eBGP) are advertised to the DLR. All routes from the ESGs are installed in the routing table.

Ingress to the DLR—Routes learned by the ESGs from the DLR via Interior Border Gateway Protocol (iBGP) are advertised to the ToR switches.


network configuration for the Continuous Availability (Single-site) protection service as

tested and validated by Enterprise Hybrid Cloud.

Continuous

Availability

(Single-site)

network design



Figure 26. Verified Continuous Availability (Single-site) network configuration

Note: The configuration shown in Figure 26 is in the context of a single network, which is

configured to ingress/egress through the Edge cluster in Hardware Island 1. In this example,

where balance of ingress/egress traffic between Edge clusters is required or desirable, you may

deploy additional DLRs and networks, which are configured to ingress/egress through the Edge

cluster in Hardware Island 2.


While the diagram in Figure 26 shows the use of standard (local) DLRs and logical

switches, universal DLRs and logical switches are also supported, although they do not

provide any additional benefits in this scenario. This statement is true for two reasons:

The local egress feature in VMware NSX is not utilized.

Because a single vCenter is in use, a standard or a universal DLR are both capable of spanning hardware islands or sites.



Solution Guide

In Figure 26, Hardware Island 1 is the primary egress/ingress path for one or more tenant

clusters. It is also possible to make Hardware Island 2 the primary egress/ingress path

for one or more tenant clusters. This network design allows the egress/ingress path to

switch to Hardware Island 2 automatically if Hardware Island 1 fails (and conversely, if

Hardware Island 2 is primary).

Note: To influence the routing of ingress traffic, this network design uses BGP autonomous

system (AS) path prepend. This requires support for BGP routing in the customer network.

Normal operation


Egress from the DLR—Routes learned by the ESGs from their respective ToR switches via eBGP are advertised to the DLR. Only routes from Hardware Island 1 ESGs are installed in the DLR routing table due to a higher BGP weight.

Ingress to the DLR—Routes advertised by the DLR are learned by both the Hardware Island 1 and Hardware Island 2 ESGs via iBGP. The ESGs will in turn advertise these routes to their respective ToR switches. The Hardware Island 1 ToR switches will advertise the DLR routes to the customer’s network without manipulation. The Hardware Island 2 ToR switches will also advertise the DLR

routes to the customer’s network, but will first elongate the AS path.

Operation if Hardware Island 1 fails

If Hardware Island 1 fails, the network operates as follows:

Egress from the DLR—The DLR will no longer be peered with the Hardware Island 1 ESGs. Routes learned from the Hardware Island 1 ESGs will timeout and routes learned from the Hardware Island 2 ESGs will now become the best (and only) option and will be installed in the DLR routing table.

Ingress to the DLR—DLR routes learned by the customer’s network from the Hardware Island 1 ToR switches will timeout and the DLR routes learned from the Hardware Island 2 ToR switches will now become the best (and only) option and will be installed in upstream routing tables.

Operation if Hardware Island 1 is restored

When Hardware Island 1 is restored, the network operates as follows:

Egress from the DLR—The peering relationship between the DLR and the Hardware Island 1 ESGs are automatically restored. Routes from the Hardware Island 1 ESGs are again learned by the DLR.

Ingress to the DLR—The peering relationship between the ToR switches and the customer’s network is automatically restored. The customer’s network again learns the DLR routes from the Hardware Island 1 ToR switches.




network configuration for the Continuous Availability (Dual-site) protection service as

tested and validated by Enterprise Hybrid Cloud.

Figure 27. Verified Continuous Availability (Dual-site) network configuration

Note: The configuration shown in Figure 27 is in the context of a single network, which is

configured to ingress/egress through the Edge cluster in Hardware Island 1. In this example,

where balance of ingress/egress traffic between Edge clusters is required or desirable, you may

deploy additional DLRs and networks, which are configured to ingress/egress through the Edge

cluster in Hardware Island 2.

Continuous

Availability

(Dual-site)

network design



Solution Guide


While the diagram in Figure 27 show the use of standard (local) DLRs and logical

switches, universal DLRs and logical switches are also supported, although they would

not provide any additional benefits in this scenario. This statement is true for two reasons:

The local egress feature in VMware NSX is not utilized.

Because a single vCenter is in use, a standard or universal DLR are both capable of spanning hardware islands or sites

In Figure 27, Site A is the primary egress/ingress path for the tenant cluster(s). It is also

possible to make Site B the primary egress/ingress path for the tenant cluster(s). This

network design allows the egress/ingress path to switch to Site B automatically if Site A

fails (and conversely, if Site B is primary).

Note: Using a stretched Edge cluster to support the ESGs and DLR is also supported.

Normal operation


Egress from the DLR—Routes learned by the ESGs from their respective ToR switches via eBGP are advertised to the DLR. Only routes from Site A ESGs are installed in the DLR routing table due to a higher BGP weight.

Ingress to the DLR—Routes advertised by the DLR are learned by both the Site A and Site B ESGs via iBGP. The ESGs turn advertise these routes to their respective ToR switches. The Site A ToR switches will advertise the DLR routes to the customer’s network without manipulation. The Site B ToR switches also advertises the DLR routes to the customer’s network, but first elongates the AS path.

Operation if Site A fails

If Site A fails, the network operates as follows:

Egress from the DLR—The DLR will no longer be peered with the Site A ESGs. Routes learned from the Site A ESGs will time out and routes learned from the Site B ESGs will now become the best (and only) option and will be installed in the DLR routing table.

Ingress to the DLR—DLR routes learned by the customer’s network from the Site A ToR switches will time out and the DLR routes learned from the Site B ToR switches, will now become the best (and only) option and will be installed in upstream routing tables.

Operation if Site A is restored

When Site A is restored, the network will operate as follows:

Egress from the DLR—The peering relationship between the DLR and the Site A ESGs will be automatically restored. Routes from the Site A ESGs will again be learned by the DLR.

Ingress to the DLR—The peering relationship between the ToR switches and the customer’s network will be automatically restored. The customer’s network will again learn DLR routes from the Site A ToR switches.




network configuration for the SRM-based disaster recovery protection service as tested

and validated by Enterprise Hybrid Cloud.

Figure 28. Verified Site Recovery Manager-based disaster recovery network configuration


The SRM-based DR service currently supports only standard (local) DLR usage as

Enterprise Hybrid Cloud network convergence customizations were built to work with

standard DLRs only.

Disaster

recovery (Site

Recovery

Manager)

network design



Solution Guide

In Figure 28, Site A is the primary egress/ingress path for workloads on the DR cluster

pair. It is also possible to make Site B the primary egress/ingress path for a DR cluster

pair (this is done by the Enterprise Hybrid Cloud network convergence customizations

during failover). For active/active sites, it is possible to have separate tenant clusters

active at each site, each with a primary egress/ingress path at the active site.

Note: As the SRM-based DR protection service does not influence upstream routing in the same

way as the continuous availability protection services, BGP is not required to be supported on the

customer network (upstream of the ToR switches). Other routing protocols such as OSPF can be

used; however, for consistency and ease of deployment, the same routing protocol should be

used between the UDLR and ESGs and between the ESGs and the physical network.

Normal operation


Egress from the DLR—At each site, routes learned by the ESGs from the ToR switches via eBGP are advertised to the DLR via iBGP. These routes are installed in the DLR routing table.

Ingress to the DLR—At Site A, routes are advertised by the DLR, because a redistribution policy of permit is configured. These DLR routes are learned by the ESGs via iBGP and then advertised to the ToR switches via eBGP. The ToR switches then advertises these DLR routes to the customer’s network. At Site B, routes are NOT advertised by the DLR, because a redistribution policy of deny is configured. No DLR routes are learned by the ESGs, ToR switches, or the customer’s network.



Egress from the DLR—If Site A fails, then the Site A DLR and ESGs will be down. Since no failover operation has been performed, all virtual machines lose the ability to reach the external network and there is no egress traffic.

Ingress to the DLR—DLR routes learned by the customer’s network from the Site A ToR switches will timeout. Since no DLR routes were ever learned by the customer’s network from the Site B ToR switches, there will no longer be any DLR routes in upstream routing tables. Since no failover operation has been performed, all virtual machines are no longer reachable from the external network and there would be no endpoint for ingress traffic.

Programmatic failover

As part the of SRM failover process, the network “convergence” scripts are run. These

scripts:

On Site A DLR—Attempt to change the redistribution policy from permit to deny. Because Site A is down, this operation will fail. The operation is attempted in case this is a scheduled failover, if so the Site A DLRs would have been online.

On Site B DLR—Change the redistribution policy from deny to permit.




When Site A is restored, the network operates as follows:

Egress from the DLR—The peering relationship between the Site A DLR and the ESGs will be automatically restored. Routes from the Site A ESGs will again be learned by the DLR and installed in the DLR routing table.

Ingress to the DLR—If Site A is restored, then the peering relationship between the Site A DLR and the ESGs will be automatically restored, but since the redistribution policy was set to deny during the programmatic failover, the ESGs will NOT learn any routes from the DLR and will NOT advertise any DLR routes to the ToR switches. The peering relationship between the ToR switches and the customer’s network will also be automatically restored, but the customer’s network will NOT learn DLR routes from the Site A ToR switches, since none were learned from the Site A ESGs.

Programmatic failback

As part the of SRM failback process, the network “convergence” scripts are run. These

scripts:

On Site B DLR—Change the redistribution policy from permit to deny.

On Site A DLR—Change the redistribution policy from deny to permit.


network configuration for the RecoverPoint for Virtual Machines-based DR protection

service as tested and validated by Enterprise Hybrid Cloud.

Disaster

recovery

(RecoverPoint

for Virtual

Machines)

network design



Solution Guide

Figure 29. Verified RecoverPoint for Virtual Machines-based DR network configuration


The RecoverPoint for Virtual Machines-based DR service currently only supports

universal DLR usage. This is a requirement to have VMware NSX-based networks

federated across two vCenters and NSX Manager instances.

In Figure 29, Site A is the primary egress/ingress path for virtual machines running at

either site (see above configuration). Switching the egress/ingress path to Site B can only

be done programmatically.



Normal operation


Egress from the UDLR—Routes learned by the ESGs from their respective ToR switches via eBGP, are advertised to the UDLR. Only routes from Site A ESGs are installed in the routing table due to BGP weighting.

Ingress to the UDLR—Routes learned from the UDLR by the Site A ESGs via iBGP are advertised to the Site A ToR switches. The Site B ESGs do not learn any routes from the UDLR due to the BGP route filters. The Site A ToR switches advertise the UDLR routes to the customer without manipulation. The Site B ToR switches did not learn any UDLR routes from the Site B ESGs, so they do not advertise any UDLR routes to the customer.



Egress from the UDLR—The UDLR is no longer peered with the Site A ESGs. Routes learned from the Site A ESGs time out and routes learned from the Site B ESGs now become the best (and only) option and are installed in the UDLR routing table. Since no failover operation has been performed, all virtual machines lose the ability to reach the external network and there is no egress traffic.

Ingress to the UDLR—UDLR routes learned by the customer’s network from the Site A ToR switches time out. Since no UDLR routes were learned by the customer’s network from the Site B ToR switches, there are no longer any UDLR routes in upstream routing tables. Since no failover operation has been performed, all virtual machines are no longer reachable from the external network and there is no endpoint for ingress traffic.

Programmatic failover

To programmatically fail over the networks in this configuration:

On the UDLR—Raise the BGP weights for the neighbor relationships with Site B ESGs from 40 to 140. This preserves Site B as the primary egress path, even if Site A comes back online.

On the UDLR—Remove the BGP filters, so that the Site B ESGs learn routes from the UDLR.

On the UDLR—Add the BGP filters, so that the Site A ESGs do NOT learn routes from the UDLR.


When Site A is restored, the network operates as follows:

Egress from the DLR—The peering relationship between the UDLR and the Site A ESGs is automatically restored. Routes from the Site A ESGs are again learned by the UDLR. These routes have a lower BGP weight, due to changes made during programmatic failover, and therefore are NOT installed in the UDLR routing table.

Ingress to the DLR—The peering relationship between the UDLR and the Site A ESGs is automatically restored, but because BGP filters were added during the programmatic failover, the ESGs does NOT learn any routes from the UDLR and does NOT advertise any UDLR routes to ToR switches. The peering relationship between the ToR switches and the customer’s network is also automatically restored, but the customer’s network does NOT learn UDLR routes from the Site A ToR switches, because none were learned from the Site A ESGs.



Solution Guide

Programmatic failback

To programmatically fail back the networks in this configuration:

On the UDLR—Lower the BGP weights for the neighbor relationships with Site B ESGs from 140 to 40. This allows Site A to become the primary egress path.

On the UDLR—Remove the BGP filters, so that the Site A ESGs learns routes from the UDLR.

On the UDLR—Add the BGP filters, so that the Site B ESGs will NOT learn routes from the UDLR.

Chapter 6: Storage Considerations


Chapter 6 Storage Considerations


Common best practices and supported configurations ................................. 79

Non-replicated storages ................................................................................... 80

Continuous availability storage considerations ............................................. 81

Disaster recovery (Site Recovery Manager) storage considerations ............ 85



Solution Guide

Common best practices and supported configurations

Dell EMC recommends that you follow the best practice guidelines when deploying any of

the supported platform technologies. Enterprise Hybrid Cloud does not require any

variation from these best practices.

For block-based provisioning, ViPR virtual arrays must not contain more than one

protocol. For Enterprise Hybrid Cloud, this means that Dell EMC ScaleIO™ storage and

FC block storage must be provided with separate virtual arrays.

Note: Enterprise Hybrid Cloud supports combining multiple physical arrays into fewer virtual

arrays to provide storage to virtual pools.

Enterprise Hybrid Cloud does not support vSphere datastore clusters for the following

reasons:

Linked clones do not work with datastore clusters, causing multi-machine blueprints to fail unless configured with different reservations for edge devices.

vRealize Automation already performs capacity analysis during initial placement.

VMware Storage DRS operations can result in inconsistent behavior when virtual machines report their location to vRealize Automation. Misalignment with vRealize reservations can make the virtual machines uneditable.

Enterprise Hybrid Cloud STaaS operations do not place new LUNs into datastore clusters, therefore all datastore clusters would have to be manually maintained.

Specific to SRM-based DR protection service:

Day 2 storage DRS migrations between datastores would break the SRM protection for the virtual machines moved.

Day 2 storage DRS migrations between datastores would result in re-replicating the entire virtual machine to the secondary site.

VMware raw device mappings (RDMs) are not created by, or supported by, Enterprise

Hybrid Cloud STaaS operations. If created outside of STaaS services, any issues arising

from RDM use is not supported by Enterprise Hybrid Cloud customer support. If changes

are required in the environment to make them operate correctly, then an Enterprise Hybrid

Cloud RPQ should be submitted first for approval. If issues arise related to these changes,

then Enterprise Hybrid Cloud support teams may request that you back them out to

restore normal operation.

Storage platform

best practices

ViPR virtual

pools

vSphere

datastore

clusters

VMware raw

device mappings



Non-replicated storages

Non-replicated storage is used for the single-site and RecoverPoint for Virtual Machines

DR protection services. This section addresses the storage considerations for such

storage.

Table 13 outlines the categories of non-replicated storage, how it is provisioned, the

cluster type it is assigned to, and the underlying supported storage technology for each

category.

Table 13. Non-replicated storage and supported underlying storage platforms

Storage type Cluster assigned to

Provisioned by Supported storage

LC1S LC1S Enterprise Hybrid Cloud STaaS workflows using Dell EMC ViPR Controller

Dell EMC VMAX

Dell EMC VNX

Dell EMC XtremIO

Dell EMC ScaleIO

Dell EMC VPLEX Local

Dell EMC Isilon™ (workload use only)

Dell EMC Unity

VS1S VS1S Pre-provisioned (VxRail Appliance only)

vSAN

With single-site protection, storage provisioned to serve these workloads has no

LUN-based replicas, and therefore by definition, it is bound to a single site and hardware

island.

LC1S or VS1S clusters are created using hosts from a single hardware island, therefore

workloads placed on these clusters do not require any form of site or hardware island

affinity.

RecoverPoint for Virtual Machines-based DR workloads use LC1S and VS1S vSphere

clusters and storage without any LUN-based replicas, as replication for these workloads is

carried out at the Virtual Machine Disk (VMDK) level and not at the datastore level.

While the storage these workloads use are bound to one site, the replicated version of the

workload uses a second set of non-replicated storage bound to a different site.

RecoverPoint for Virtual Machines-based disaster recovery functionality can be enabled or

disabled globally using the rp4vms_enabled global option. Changing the value of this

option can be done with the vRealize Automation Global Options Maintenance catalog

item.

Applicability

Non-replicated

storage types

and supported

storage

platforms

Single-site

workloads

RecoverPoint for

Virtual Machines

disaster

recovery

workloads



Solution Guide

vSphere clusters that use non-replicated storage are made eligible for use within

Enterprise Hybrid Cloud using the Cluster Maintenance vRealize Automation catalog

item.

LC1S clusters are onboarded using the Onboard Local Cluster option, which makes

them available for selection when the Provision Cloud Storage catalog item is used.

This process ensures that only the correct type of storage is presented to the single-site

(LC1S) vSphere clusters and no misplacement of virtual machines intended for LUN-

based inter-site protection occurs.

VS1S clusters are onboarded using the Onboard VSAN Cluster option, which discovers

vSAN datastores on the cluster and ingests them in the Enterprise Hybrid Cloud object

model.

When onboarding an LC1S or VS1S clusters in an environment where RecoverPoint for

Virtual Machines is also enabled, this catalog item also ensures a partner cluster is

selected to allow machines to fail over to the other site.

Continuous availability storage considerations

Continuous availability provided by VPLEX Metro is used for both the Continuous

Availability (Single-Site) and Continuous Availability (Dual-site) protection services. This

section addresses the storage considerations for the VPLEX Metro configuration.

Table 14 outlines the categories of continuous availability storage, how it is provisioned,

the cluster type it is assigned to, and the underlying supported storage technology for

each category.

Table 14. CA (VPLEX) storage and supported underlying storage platforms

Storage type

Assigned to cluster

Provisioned by VPLEX cluster locations

Underlying storage

CA1S CA1S Enterprise Hybrid Cloud STaaS workflows using ViPR Controller

Both on one site Dell EMC VMAX

Dell EMC VNX

Dell EMC XtremIO

CA2S CA2S Enterprise Hybrid Cloud STaaS workflows using ViPR Controller

One on each of two sites

Dell EMC VMAX

Dell EMC VNX

Dell EMC XtremIO

With continuous availability protection, storage provisioned to serve these workloads is

replicated across two different physical backend storage platforms. These platforms may

be in two different hardware islands on the same physical site (CA1S) or may be in two

different hardware islands on two separate sites (CA2S).

Onboarding

process for

clusters with

non-replicated

storage

Applicability

Continuous

availability

storage and

supported

storage

platforms

Continuous

availability

workloads



As described in Site affinity for tenant virtual machines Enterprise Hybrid Cloud workflows

use the “winning” site in a VPLEX configuration to determine to which site/hardware island

to map virtual machines.

ViPR virtual pools for block storage offer two options under high availability: VPLEX local

and VPLEX distributed. Continuous availability protection uses VPLEX Distributed only.

Figure 30 shows this configuration in the context of Continuous Availability (Dual-site),

where VPLEX High-Availability Virtual Pool represents the VPLEX high-availability pool

created.

Figure 30. Interactions between local and VPLEX distributed pools

To enable active/active clusters, you must create two sets of datastores – one set that will

win on Hardware Island/Site A and another set that will win on Hardware Island/Site B.

vSphere clusters that use continuously available storage are made eligible for use within

Enterprise Hybrid Cloud using the vRealize Automation Cluster Maintenance catalog

item.

Both CA1S and CA2S clusters are onboarded using the Onboard CA Cluster option,

which makes them available for selection when you use the Provision Cloud Storage

catalog item. This process ensures that only the correct type of storage is presented to the

CA1S or CA2s vSphere clusters and no misplacement of virtual machines intended for

LUN-based inter-site protection occurs.

Continuous availability functionality may be enabled or disabled globally using the

ca_enabled global option. Changing the value of this option can be done using the

vRealize Automation Global Options Maintenance catalog item.

Continuous

availability ViPR

virtual pools

Onboarding for

clusters with

continuously

available storage



Solution Guide

VMware classifies the stretched VPLEX Metro cluster configuration with VPLEX into the

following categories:

Uniform host access configuration with VPLEX host cross-connect—vSphere ESXi hosts in a distributed vSphere cluster have a connection to the local VPLEX system and paths to the remote VPLEX system. The remote paths presented to the vSphere ESXi hosts are stretched across distance.

Non-uniform host access configuration without VPLEX host cross-connect—vSphere ESXi hosts in a distributed vSphere cluster have a connection only to the local VPLEX system.

Use the following guidelines to help you decide which topology suits your environment:

Uniform (cross-connect) is typically used where:

Inter-site latency is less than 5 ms.

Stretched SAN configurations are possible.

Non-Uniform (without cross-connect) is typically used where:

Inter-site latency is between 5 ms and 10 ms.

Stretched SAN configurations are not possible.

VPLEX uses consistency groups to maintain common settings on multiple LUNs. To

create a VPLEX consistency group using ViPR, a ViPR consistency group must be

specified when creating a new volume. ViPR consistency groups are used to control multi-

LUN consistent snapshots and have a number of important rules associated with them

when creating VPLEX distributed devices:

All volumes in any given ViPR consistency group must contain only LUNs from the same physical array. As a result of these considerations, Enterprise Hybrid Cloud STaaS workflows create a new consistency group per physical array, per vSphere cluster per site.

All VPLEX distributed devices in a ViPR consistency group must have source and target backing LUNs from the same pair of arrays.

As a result of these two rules, it is a requirement of Enterprise Hybrid Cloud that an

individual ViPR virtual pool is created for every physical array that provides physical pools

for use in a VPLEX distributed configuration.

Enterprise Hybrid Cloud STaaS workflows use the name of the ViPR virtual pool chosen

as part of the naming for the vRealize SRP that the new datastore is added to. The Virtual

Pool Collapser (VPC) function of Enterprise Hybrid Cloud collapses the LUNs from

multiple virtual pools into a single SRP.

Where multiple physical arrays provide physical storage pools of the same service level to

VPLEX through different ViPR virtual pools, the VPC function can be used to ensure that

all LUNs provisioned across those physical pools are collapsed into the same SRP.

VPC can be enabled or disabled at a global Enterprise Hybrid Cloud level using the

ehc_vpc_disabled global option. Changing the value of this option can be done with the

vRealize Automation catalog item entitled Global Options Maintenance.

Supported

VPLEX

topologies

Deciding on

VPLEX topology

ViPR and VPLEX

consistency

groups

interaction

Virtual Pool

Collapser

function



When ehc_vpc_disabled is set to False, Enterprise Hybrid Cloud STaaS workflows

examine the naming convention of the virtual pool selected to determine which SRP it

should add the datastore to. If the virtual pool includes the string ‘_VPC-’, then Enterprise

Hybrid Cloud knows that it should invoke VPC logic.

Virtual Pool Collapser example

Figure 31 shows an example of VPC in use. In this scenario, the administrator has

enabled the VPC function and created two ViPR virtual pools:

GOLD_VPC-000001, which has physical pools from Array 1

GOLD_VPC-000002, which has physical pools from Array 2

Figure 31. Virtual Pool Collapser example

When determining how to construct the SRP name to be used, the VPC function only

uses that part of the virtual pool name that exists before ‘_VPC-’. This example results in

the term ‘GOLD’, which then contributes to the common SRP name of:

SITEA_GOLD_CA_Enabled. This makes it possible to conform to the rules of ViPR

consistency groups, as well as providing a single SRP for all datastores of the same type,

which maintains abstraction and balanced datastore usage at the vRealize layer.

In the example shown in Figure 31, all storage is configured to win on a single site (Site

A). To enable true active/active vSphere Metro storage clusters, additional pools should

be configured in the opposite direction.



Solution Guide

Disaster recovery (Site Recovery Manager) storage considerations

The SRM-based DR protection service for Enterprise Hybrid Cloud incorporates storage

replication using RecoverPoint, storage provisioning using ViPR, and integration with

SRM to support DR services for applications and virtual machines deployed in the hybrid

cloud. SRM natively integrates with vCenter and NSX to support DR, planned migration,

and recovery plan testing.

Table 15 outlines the categories of DR RecoverPoint storage, how it is provisioned, the

cluster type it is assigned to and the underlying supported storage technology for each

category.

Table 15. DR (RecoverPoint) storage and supported underlying storage platforms

Storage type

Assigned to cluster

Provisioned by Underlying storage

DR2S DR2S (one on each hardware island/site)

Enterprise Hybrid Cloud STaaS workflows using ViPR Controller

Dell EMC VMAX

Dell EMC VNX

Dell EMC XtremIO

Dell EMC VMAX3™ (must reside behind a Dell EMC VPLEX unit)

With SRM-based disaster recovery protection, storage provisioned to serve these

workloads is replicated across two different physical backend storage platforms using Dell

EMC RecoverPoint. These must be in two different hardware islands on two separate

sites.

Affinity to a site is determined by the storage choice of the user when deploying a virtual

machine workload, as the storage reservation policy presented to the user indicates the

site on which the storage is usually active.

When you specify RecoverPoint as the protection option for a virtual pool, the ViPR

storage provisioning services create the source and target volumes and the source and

target journal volumes, as shown in Figure 32.

Applicability

Disaster

recovery (SRM)

storage and

supported

storage

platforms

SRM-based

disaster

recovery

workloads

SRM-based

disaster

recovery ViPR

virtual pools



Figure 32. ViPR/EMC RecoverPoint protected virtual pool

Each SRM DR-protected/recovery DR2S cluster pair has storage that replicates (under

normal conditions) in a given direction, for example, from Site A to Site B. To allow

active/active site configuration, additional SRM DR cluster pairs should be configured

whose storage replicates in the opposite direction.

vSphere clusters that use disaster recovery storage are made eligible for use within

Enterprise Hybrid Cloud using the vRealize Automation Cluster Maintenance catalog

item.

DR2S clusters are onboarded using the Onboard DR Cluster option, which makes them

available for selection when you use the Provision Cloud Storage catalog item. This

process ensures that only the correct type of storage is presented to the DR2S vSphere

clusters and no misplacement of virtual machines intended for LUN based inter-site

protection occurs.

SRM-based DR functionality can be enabled or disabled globally using the dr_enabled

global option. You can change the value of this option by using the vRealize Automation

Global Options Maintenance catalog item.

Every RecoverPoint-protected LUN requires access to a journal LUN to maintain the

history of disk writes to the LUN. The performance of the journal LUN is critical in the

overall performance of the system attached to the RecoverPoint-protected LUN and

therefore its performance capability should be in line with the expected performance

needs of that system.

By default, ViPR uses the same virtual pool for both the target and the journal LUN for a

RecoverPoint copy, but it does allow you to specify a separate or dedicated pool. In both

cases, the virtual pool and its supporting physical pools should be sized to provide

adequate performance.

Onboarding

clusters with

SRM-based

disaster

recovery storage

RecoverPoint

journal

considerations

Chapter 7: Data Protection (Backup as a Service)


Solution Guide

Chapter 7 Data Protection (Backup as a Service)


Overview ............................................................................................................ 88

Data protection technology .............................................................................. 88

Backup types overview..................................................................................... 89

Key Enterprise Hybrid Cloud backup constructs ........................................... 94

Controlling the backup infrastructure ............................................................. 99



Overview

This chapter discusses the considerations for implementing data protection, also known

as backup as a service (BaaS), in the context of Enterprise Hybrid Cloud.

This solution uses Avamar as the technology to protect your datasets. Using Avamar, this

backup solution includes the following characteristics:

Abstracts and simplifies backup and restore operations for cloud users

Uses VMware storage APIs for data protection, which provides changed block tracking for faster backup and restore operations

Provides full image backups for running virtual machines

Eliminates the need to manage backup agents for each virtual machine in most cases

Minimizes network traffic by de-duplicating and compressing data

Note: Dell EMC recommends that you engage an Avamar product specialist to design, size, and

implement a solution specific to your environment and business needs.

Data protection technology

Avamar instances (known as Avamar grids in the Enterprise Hybrid Cloud object model)

are the physical targets for Enterprise Hybrid Cloud backup data. They may be optionally

backed by a Data Domain infrastructure for even greater efficiencies.

Day 2 catalog items are available through vRealize Automation that are used to onboard

the grids and their details. Part of the onboarding process assigns the grid to one of the

sites that exist in the model. That information is subsequently used to ensure that users

are guided to choose from only the applicable grids when setting up BaaS constructs.

Enterprise Hybrid Cloud backup configurations add scalable backup by adding the ability

to configure multiple Avamar grids/instances per site across multiple sites. BaaS

workflows automatically distribute workloads in a round-robin fashion across the available

Avamar instances available to the workloads in question.

Additional Avamar grids, or new relationships between existing Avamar grids, can be

added to increase the scalability. By using Avamar Site Relationships and Avamar

Replication Relationships, this new capacity is transparently discovered and used as new

workloads are deployed.

Avamar

instances/grids

Scalable backup

architecture

through multiple

Avamar grids



Solution Guide

Backup types overview

Backup types, as shown in Table 16 are the rulesets that are automatically applied to

Enterprise Hybrid Cloud workloads based on the type of cluster on which they reside and

the protection options that are available within the environment.

Table 16. Backup types

Type Description

1C1VC One backup copy. Virtual machines are only on one site (one vCenter).

2C1VC Two backup copies. Virtual machines move between two sites (one vCenter).

2C2VC Two backup copies. Virtual machines move between two sites (two vCenters).

MC2VC Mixed number of copies. Virtual machines can be in up to two sites (two vCenters).

The 1C1VC backup model is designed to back up workloads that are bound to a single

site and may never move. As a result, the backup strategy that is applied to these

workloads has a single copy per backup image (that is, non-replicated) on a single

Avamar grid, as shown in Table 17.

Table 17. Characteristics of one-copy-one-vCenter backup type

Applies to workload

Number of sites involved

Number of images created

Number of vCenters involved

Number of vCenter folders

Number of Avamar grids required

Single Site 1 1 1 1 1

You can deploy multiple Avamar grids in the environment to enable scale, and backup is

automatically balanced across the number of grids deployed. Figure 33 shows an

example of the folders and backup groups involved in a 1C1VC backup type.

Backup types

One-Copy One-

vCenter (1C1VC)



Figure 33. 1C1VC folders and backup groups

The 2C1VC backup model is designed to back up dual-site CA workloads that may move

between sites, but remain in the same vCenter endpoint. As a result, the backup strategy

that is applied to these workloads has two copies per backup image replicated from the

grid that took the backup to the relevant partner grid.

Table 18. Characteristics of two-copy-one-vCenter backup type

Applies to workload







2 2 1 2 2

In this configuration, two vCenter folders are created (one per site) in the same vCenter

and one Avamar grid in each site has primary ownership of the set of folders local to its

own site with ability to take over ownership of the set corresponding to the other site.

When workloads move sites, the same Avamar grid continues to backup those workloads

until the backup policies on the Avamar grid are toggled via “Failover Avamar policies for

an offline Avamar grid” or “Failover Avamar grids after a site failure” (depending on failure

scenario) so that the partner Avamar grid will take over monitoring of the vCenter folder in

which the workloads reside.

Multiple Avamar grids may be deployed in the environment to enable scale, and backup is


example of the folders, backup groups, and replication groups involved in a 2C1VC

backup type.

Two-Copy One-

vCenter (2C1VC)



Solution Guide

Figure 34. 2C1VC folders, backup groups, and replication groups

The 2C2VC backup model is designed to back up DR (SRM) workloads that may move

between sites and that change vCenter endpoint when they do so. As a result, the backup

strategy that is applied to these workloads has two copies per backup image replicated

from the grid that took the backup to the relevant partner grid.

Table 19. Characteristics of two-copy-two-vCenter backup type

Applies to workload






DR SRM 2 2 2 4 2

In this configuration, four vCenter folders are created (two per site) with two residing in

each vCenter endpoint. One Avamar grid on each site has sole ownership of the folders

local to its own site or vCenter. When workloads move sites, the Avamar grid on the target

site automatically starts backing up those workloads when they appear in the vCenter

folders that it is monitoring.

Multiple Avamar grids may be deployed in the environment to enable scaling, and backup

is automatically balanced across the number of grids deployed. Figure 35 shows an

example of the folders, backup groups, and replication groups involved in a 2C2VC

backup type.

Two-Copy Two-

vCenter (2C2VC)



Figure 35. 2C2VC folders, folder mappings, backup groups, and replication groups

The MC2VC backup model is designed to back up disaster recovery (RecoverPoint for

Virtual Machine) workloads. This is slightly different from the other models in that two

different types of workloads may co-exist on the same tenant compute cluster, and those

workloads may change type from single-site to RecoverPoint for Virtual Machines-based

DR protection and back again at any time.

Table 20. Characteristics of mixed-copy-two-vCenter backup type

Applies to workload






Single Site

DR RP4VMs

2 1 or 2 2 6 2

In this configuration, six vCenter folders are created (three per site) with three residing in

each vCenter endpoint. One Avamar grid on each site has sole ownership of the set of

folders local to its own site/vCenter. When workloads move sites, the Avamar grid on the

Mixed-Copy

Two-vCenter

(MC2VC)



Solution Guide

target site automatically starts backing up those workloads when they appear in the

vCenter folders that it is monitoring.

Single-site workloads reside in folders designated for local protection only. Therefore, they

are backed up by a single grid and the backup image is not replicated, similar in concept

to the 1C1VC model.

RecoverPoint for Virtual Machines DR workloads reside in folders designated for dual-site

protection. Therefore, they are backed up by a single grid and the backup image is

replicated, similar in concept to the 2C2VC model.

When a workload changes RecoverPoint for Virtual Machines DR protection status, it is

moved from one vCenter folder to another, thereby self-adjusting its backup strategy to

stay in line with its overall protection status, while maintaining all the previous backup

images that were taken of that workload.

Multiple Avamar grids may be deployed in the environment to enable scale, and backup is


example of the folders, backup groups, and replication groups involved in a MC2VC

backup type.

Figure 36. MC2VC folders, folder mappings, backup groups, and replication groups



To establish the types of backups that should be applied to given workload types,

Enterprise Hybrid Cloud ensures that all workloads on a given cluster type map to

corresponding backup types. Table 21 shows how individual cluster types map to backup

types.

Table 21. Cluster type to backup type mapping

Cluster type Backup type

LC1S or VS1S 1C1VC (without RecoverPoint for Virtual Machines)

MC2VC (with RecoverPoint for Virtual Machines)

CA1S 1C1VC

CA2S 2C1VC

DR2S 2C2VC

Key Enterprise Hybrid Cloud backup constructs

An Avamar Site Relationship (ASR) is a relationship between sites for backup purposes.

When it is determined that two sites must have a backup relationship, an ASR is created

and assigned one of the backup types listed in Backup types. This backup type then

defines the nature of the relationships that must be subsequently configured between

physical Avamar grids to achieve that type of backup.

The individual relationships created between grids are referred to as Avamar Replication

Relationships (ARRs), and each ARR created becomes a child of the ASR that defined it.

ARRs are covered in detail in Avamar Replication Relationships.

The following rules apply to an ASR:

Each ASR must correspond to a single backup type, as shown in Backup types.

Each ASR may have one or two sites associated with it.

The sites and type of an ASR become the ruleset for all ARRs that are added to it as children.

ASRs may contain multiple ARRs to facilitate scale.

Onboarded Enterprise Hybrid Cloud clusters may be associated with a single ASR. Therefore, all workloads on a specified cluster follow the backup policy structure of the mapped ASR.

ASRs provide an abstraction between the vSphere cluster and the ARRs that are the children of the ASR to which the cluster is mapped. This allows additional ARRs to be added and used without altering the cluster mapping.

During provisioning of backup services to an individual workload, round-robin algorithms examine the ASR mapped to the workload cluster and choose the ARR the workload will use.

Multiple ASRs of the same type can exist at the same time.

Mapping cluster

types to backup

types

Avamar Site

Relationships



Solution Guide

Multiple ASRs of the same type in a single Enterprise Hybrid Cloud instance

There are several use cases for using multiple ASRs of the same type in the same

environment:

There could be a 1C1VC ASR in each of several sites.

There could be multiple 2C1VC ASRs if multiple CA relationships exist in the Enterprise Hybrid Cloud environment.

There could be multiple 2C2VC ASRs if multiple DR relationships exist in the Enterprise Hybrid Cloud environment.

Multiple ASRs with the same set of sites could also be used to separate clusters onto dedicated sets of Avamar infrastructure.

Note: In the earlier versions of Enterprise Hybrid Cloud, Avamar grids were paired, resulting in a

single backup type being available for any given Avamar grid. ASRs and ARRs break this

dependency and allow multiple backup types to co-exist on the same physical grid infrastructure.

An Avamar Replication Relationship (ARR) is a relationship between up to two Avamar

grids.

When creating an ARR, you must assign it to a parent ASR. This ensures that the grids

available for selection during its creation are only from the sites defined in the ASR itself.

Avamar grids may participate in multiple ARRs. In this way, the same grid may:

Provide multiple protection levels between the same set of sites by being a member of multiple ARRs whose parent ASR has the same set of sites but a different ASR type.

Provide protection between different sets of sites by being a member of multiple ARRs whose parent ASRs have different combinations of sites.

Both of the above at the same time.

The following rules are associated with an ARR:

An ARR must be associated with an ASR.

When creating an ARR, it inherits its type based on the parent ASR to which it is associated.

Enterprise Hybrid Cloud workflows only present Avamar grids from the relevant sites for inclusion in the ARR based on the choice of ASR.

As ARRs are added to an ASR, vSphere clusters associated with that ASR automatically pick up new ARRs and use them without needing to modify the cluster mapping.

Avamar image-level backups work by mounting snapshots of VMDKs to Avamar proxy

virtual machines and then backing up the data to the Avamar instance to which the

Avamar proxy is registered.

In a fully deployed Enterprise Hybrid Cloud with up to 10,000 user virtual machines per

vCenter and hundreds of vSphere clusters, this could lead to Avamar proxy sprawl if not

properly configured and controlled.

Avamar

Replication

Relationships

Avamar Site

Relationship to

vSphere cluster

association



To do this, Enterprise Hybrid Cloud associates vSphere clusters to a subset of ASRs (of

which there may be many). In this way, different clusters may be mapped to different

ASRs to enable backup to distinct sets of Avamar infrastructure.

This means that a reduced number of Avamar proxy virtual machines are required to

service the cloud. Associations between a vSphere cluster and an ASR are made via the

Enterprise Hybrid Cloud vRealize Automation Cluster Maintenance catalog item.

Note: When a cluster is mapped to a 2C2VC or MC2VC ASR, its partner cluster is automatically

associated with the same ASR to ensure full access to all backup images taken before, during, or

after failover or virtual machine workloads.

Cluster, ASR, ARR, and Avamar grid configuration example

Figure 37 shows an example of the concepts described previously with the following

characteristics:

Two sites are in use

Site A provides the single-site protection service through Cluster 01

Site A/Site B provide SRM-based the disaster recovery protection service through the DR2S cluster pair represented as Cluster 02

Both cluster types are serviced by a common set of grids

Cluster 01 local workloads can load balance backups to Grid 01 and Grid 02 because the ASR it is mapped to has two different child ARRs

Cluster 02 DR workloads can load balance backups to Grid 01 and Grid 02 on Site A or Grid 03 and Grid 04 on Site B as appropriate because the ASR it is mapped to has two different child ARRs



Solution Guide

Figure 37. Cluster, ASR, ARR, and Avamar grid configuration example

Avamar backup groups are automatically created on Avamar grids during the creation of a

backup service level. They control the vCenter elements that are monitored by scheduled

backup policies and are triggered by on-demand backups. These backup groups are

recorded in the object model and used to ensure that backup policies can follow their

workloads as they are recovered to different sites.

Avamar replication groups are automatically created on Avamar grids during the creation

of a backup service level when multisite ASRs and ARRs exist. They control the

replication settings for scheduled backups and are triggered by on-demand backups.

These replication groups are recorded in the object model and used to ensure that

replication policies can follow their workloads as they are recovered to different sites.

Backup service levels appear to the user as the available options when specifying the tier

of backup that a virtual machine workload will use. They are created using the vRealize

Automation Backup Service Level Maintenance catalog item.

A backup service level includes the following attributes:

Cadence—At what frequency a backup should run (daily, weekly, monthly, or custom)

Backup Schedule—Time of day/window that the backup should run

Avamar backup

groups

Avamar

replication

groups

Backup service

levels



Replication Schedule—Time of day when backup images should be replicated to another site (where appropriate)

Retention—How long the backup image should be retained for

When you create a backup service level the vRealize Automation Backup Service Level

Maintenance catalog item, it creates an associated set of folders in the cloud vCenter

endpoints that are added to the Enterprise Hybrid Cloud object model.

When doing this, the Enterprise Hybrid Cloud workflows cycle through all available ASRs

and find vCenter endpoints that match the site relationships in those ASRs. They then

cycle through the associated ARRs so that new vCenters folders are created

appropriately.

The number of folders created depends on how many ARRs are present, and these

folders become part of the mechanism for distributing the backup load. The format of the

folder name varies slightly depending on the ASR/ARR type, as shown in Table 22.

Table 22. vCenter folder name structure by backup type

Backup type Folders Folder name structure

1C1VC 1 BackupServiceLevelName-ARRName-Site, for example, Gold-ARR00001-NewYork

2C1VC 2 BackupServiceLevelName-ARRName-Site for each site, for

example:

Gold-ARR00002-NewYork

Gold-ARR00002-Boston

2C2VC 4 BackupServiceLevelName-ARRName-Site plus BackupServiceLevelName-ARRName-Site_PH for each site, for example:

Gold-ARR00003-NewYork

Gold-ARR00003-NewYork_PH

Gold-ARR00001-Boston

Gold-ARR00001-Boston_PH

MC2VC 6 BackupServiceLevelName-ARRName-Site-Protected plus BackupServiceLevelName-ARRName-Site-Protected_PH plus BackupServiceLevelName-ARRName-Site-Local for each site, for

example:

Gold-ARR00003-NewYork-Protected

Gold-ARR00003-NewYork-Protected _PH

Gold-ARR00003-NewYork-Local

Gold-ARR00001-Boston-Protected

Gold-ARR00001-Boston-Protected _PH

Gold-ARR00001-Boston-Local

When Enterprise Hybrid Cloud custom lifecycle operations must enable a workload for

backup, they:

1. Check the cluster the workload resides on.

2. Check the ASR that the cluster is mapped to.

VMware vCenter

folder structure

and backup

service level

relationship



Solution Guide

3. Enumerate the child ARRs assigned to that ASR and determine which of the grids local to that workload has the least current load.

4. Look up the appropriate vCenter folder for the chosen grid.

5. Move the workload to the correct vCenter folder.

Controlling the backup infrastructure

Determining that a backup target, in this case an Avamar instance, has reached capacity

can be based on a number of metrics of the virtual machines it is responsible for

protecting, including:

The number of virtual machines assigned to the instance

The total capacity of those virtual machines

The rate of change of the data of those virtual machines

The effective deduplication ratio that can be achieved while backing up those virtual machines

The available network bandwidth and backup window size

Because using these metrics can be subjective, Enterprise Hybrid Cloud enables an

administrator to preclude an Avamar instance (and therefore any ARRs it participates in)

from being assigned further workload by setting a binary Admin Full flag set via the

vRealize Automation Avamar Grid Maintenance catalog item.

When a virtual machine is enabled for data protection via Enterprise Hybrid Cloud BaaS

workflows, the available ARRs are assessed to determine the most suitable target. If an

ARR is set with the Admin Full flag, then that relationship is excluded from the selection

algorithm but continues to back up its existing workloads through on-demand or

scheduled backups.

If workloads are retired and an Avamar grid is determined to have free capacity, the

Admin Full flag can be toggled back, including it in the selection algorithm again.

If Data Domain is used as a backup target, Avamar is responsible for replication of

Avamar data from the source Data Domain system to the destination Data Domain

system. As a result, all configuration and monitoring of replication is done via the Avamar

server. This includes the schedule on which Avamar data is replicated between Data

Domain units.

You cannot schedule replication of data on the Data Domain system separately from the

replication of data on the Avamar server. There is no way to track replication by using

Data Domain administration tools.

Note: Do not configure Data Domain replication to replicate data to another Data Domain system

that is configured for use with Avamar. When you use Data Domain replication, the replicated data

does not refer to the associated remote Avamar server.

Avamar instance

full

Replication

control

Chapter 8: Enterprise Hybrid Cloud on Converged Infrastructure Systems


Chapter 8 Enterprise Hybrid Cloud on Converged Infrastructure

Systems


Enterprise Hybrid Cloud on VxRail Appliances ............................................ 101

Enterprise Hybrid Cloud on VxRack Systems .............................................. 105

Enterprise Hybrid Cloud on VxBlock Systems ............................................. 108



Solution Guide

Enterprise Hybrid Cloud on VxRail Appliances

Table 23 provides details on the Enterprise Hybrid Cloud features that are supported on a

VxRail Appliance.

Table 23. Characteristics of Enterprise Hybrid Cloud on VxRail Appliances

Feature Supported Not supported

EHC Services Single-site protection

RecoverPoint for Virtual Machines-based DR protection

BaaS

Encryption as a service

Continuous availability protection

Site Recovery Manager-based DR protection

Cluster Types VS1S LC1S

CA1S

CA2S

DR2S

Backup Types 1C1VC

MC2VC

2C1VC

2C2VC

Use the following information to understand which of the management platform

architectural overlays is relevant to your deployment:

Single-site protection (VxRail Appliance)—Use this overlay when you have a single-site deployment and do not intend to provide inter-site protection for the CMP.

RecoverPoint for Virtual Machines DR protection (VxRail Appliance)—Use this overlay when you have a multisite deployment and want to provide inter-site protection for the CMP with RecoverPoint for Virtual Machines.

When Enterprise Hybrid Cloud is deployed on a VxRail Appliance with single-site

protection:

The Core, NEI, and Automation management pod functions are all hosted on the VxRail Appliance cluster

The Data Protection Pod components are distributed as follows:

Avamar Virtual Edition appliance(s) reside on the VxRail cluster

Data Domain virtual appliances(s) reside on Dell PowerEdge Servers

The Enterprise Hybrid Cloud management platform is auto-installed on the customer site using the Enterprise Hybrid Cloud Automation Tool

Tenant workloads also reside on the VxRail Appliance cluster

Figure 38 shows how Enterprise Hybrid Cloud is overlaid on a VxRail Appliance when the

single-site protection services are deployed.

Enterprise

Hybrid Cloud

features

supported on a

VxRail Appliance

Understanding

which

architectural

overlay to use

Architecture

overlay: Single-

site protection

(VxRail

Appliance)



Figure 38. Architecture overlay: Single-site protection with VxRail Appliance

When Enterprise Hybrid Cloud is deployed on a VxRail Appliance with RecoverPoint for

Virtual Machines-based DR protection:

The Core, NEI, and Automation management pod functions are all hosted on the VxRail Appliance cluster

The Data Protection Pod components are distributed as follows:

Avamar Virtual Edition appliance(s) reside on the VxRail Appliance cluster

Data Domain virtual appliances(s) reside on Dell PowerEdge servers

The Enterprise Hybrid Cloud management platform is auto-installed on the customer site using the Enterprise Hybrid Cloud Automation Tool

Tenant workloads also reside on the VxRail Appliance cluster

Sufficient capacity is made available on the target system to accept failover of the Automation Pod

Figure 39 shows how Enterprise Hybrid Cloud is overlaid on a VxRail Appliance when the

RecoverPoint for Virtual Machines-based protection services are deployed.

Architecture

overlay:

RecoverPoint for

Virtual Machines

DR protection

(VxRail

Appliance)



Solution Guide

Figure 39. Architecture overlay: RecoverPoint for Virtual Machines-based DR protection with VxRail Appliance

The following rules and considerations are relevant to Enterprise Hybrid Cloud

deployments on VxRail Appliance:

A VxRail Appliance can only be used in an Enterprise Hybrid Cloud environment where the CMP is VxRail Appliance-based.

If the VxRail Appliance hosts the CMP:

VxBlock System or VxRack System platforms can exist in the same hybrid cloud instance as Enterprise Hybrid Cloud-managed vCenter endpoints with the caveats shown in Table 24.

Table 24. Characteristics of VxBlock/VxRack endpoints with VxRail Appliance-based CMP

Supported Not supported

Single-site protection

RecoverPoint for Virtual Machines-based DR

Backup as a service



Site Recovery Manager-based DR

VxBlock System or VxRack System platforms can also be added as

infrastructure-as-a-service vCenter endpoints

The management platform requires the use of VMware NSX for the Automation Pod load balancing function. No other load balancing technology is supported.

Rules and

considerations

(VxRail

Appliance)



Note: VMware NSX is the only load balancer technology currently supported for

automated Enterprise Hybrid Cloud deployment. Automated deployment is the only

supported method of installing the CMP on a VxRail Appliance.

When data protection (BaaS) is used to protect workloads on a VxRail Appliance:

Avamar Virtual Appliance(s) are loaded onto the VxRail Appliance cluster.

Data Domain Virtual Appliance(s) are loaded onto a distinct Dell PowerEdge server(s)

Relevant considerations are:

While it is possible for you to order and deploy a VxRail Appliance system with a single ToR switch, Dell EMC recommends using dual ToR switches to avoid a single point of failure in the overall system.

VxRail Appliance groups traffic in the following categories during deployment: Management, vSphere vMotion, vSAN, and Virtual Machine. Dell EMC recommends (but it is not required) traffic isolation on separate VLANs in the VxRail Appliance.

If you are using multiple switches, connect them via VLAN trunked interfaces and ensure that all VLANs used for VxRail are carried across the trunk. Any additional port groups created for Enterprise Hybrid Cloud including NSX specific port groups should also be added to the trunk ports.

VxRail Appliance nodes advertise themselves on the network using the “loudmouth” service, which relies on multicast. The switch must support IPv6 multicast traffic.

vSAN requires IPv4 multicasting. It is not necessary to enable multicasting on the entire switch. It is only required for the ports supporting VxRail Appliance node traffic.

Each VxRail Appliance node uses two 10 GbE network ports, and each port must be connected to a switch that supports IPv4 multicast and IPv6 multicast.

When using advanced NSX functionality each VxRail appliance uses two additional

10 GbE network ports for VXLAN traffic.

To ensure vSphere vMotion traffic does not consume all available bandwidth on the port, VxRail Appliance limits vSphere vMotion traffic using Network I/O Control (NIOC).

Physical

connectivity

considerations



Solution Guide

Enterprise Hybrid Cloud on VxRack Systems


VxRack FLEX.

Table 25. Characteristics of Enterprise Hybrid Cloud on VxRack Systems




Backup as a service




Cluster Types LC1S CA1S

CA2S

DR2S

VS1S

Backup Types 1C1VC

2C2VC

2C1VC

MC2VC



Single-site protection (VxRack Systems)—Use this overlay when you have a single-site deployment and do not intend to provide inter-site protection for the CMP.

RecoverPoint for Virtual Machines DR protection (VxRack Systems)—Use this overlay when you have a multisite deployment and want to provide inter-site protection for the CMP via RecoverPoint for Virtual Machines.

When Enterprise Hybrid Cloud is deployed with single-site protection on a VxRack

System:

Dual vCenters are the default. The ‘VxRack Management vCenter’ is provided with VxRack System and hosts native management applications. The second production vCenter is used as the Enterprise Hybrid Cloud Cloud vCenter role.

Core and NEI Pod functions are deployed and configured in the Dell EMC factory with the exception of the Automation Pod NSX Load Balancer.

The Enterprise Hybrid Cloud NEI Pod function is deployed on the Edge cluster.

The Edge cluster for NEI Pod is deployed on Dell 630 servers.

Automation Pod components consume production blades. They are deployed in the Dell EMC factory but are configured onsite.

Figure 40 shows how Enterprise Hybrid Cloud and components overlay in this

configuration.

Enterprise

Hybrid Cloud

features

supported on a

VxRack System

Understanding

which

architectural

overlay to use

Architecture

overlay: Single-

site protection

(VxRack System)



Figure 40. Architecture overlay: Single-site protection with VxRack Systems

When Enterprise Hybrid Cloud is deployed with RecoverPoint for Virtual Machines

disaster recovery protection on a VxRack System:

Dual vCenters are the default. The ‘VxRack Management vCenter’ is provided with the VxRack System and hosts native management applications. The second ‘Production vCenter’ is used as the Enterprise Hybrid Cloud ‘Cloud vCenter’ role.

Core and NEI Pod functions are deployed and configured in the Dell EMC factory with the exception of the Automation POD NSX Load Balancer

The Enterprise Hybrid Cloud NEI Pod function is deployed on the Edge cluster.

The Edge cluster is deployed on Dell 630 servers.


RecoverPoint for Virtual Machines is required for virtual machine replication.

Reserved compute capacity in the secondary for Automation Pod failover is required.

Architecture

overlay:

RecoverPoint for

Virtual Machines

DR protection

(VxRack

Systems)



Solution Guide

Virtual RecoverPoint Appliances (vRPAs) are deployed to tenant resource pods and scale in line with the number of protected virtual machines.


configuration.

Figure 41. Architecture overlay: RecoverPoint for Virtual Machines DR protection with VxRack Systems


deployments on VxRack Systems:

If VxRack Systems is to partner with another converged infrastructure platform to provide RecoverPoint for Virtual Machines-based disaster recovery protection service, then both the VxRack System production vCenter and its partner’s production vCenter must co-exist in the same VMware SSO domain.

Note: To avoid onsite remediation of the partner VxRack System, ideally both VxRack

Systems should be installed in-factory.

The VxRack System management vCenters may remain in distinct VMware SSO domains if required

VxRack Systems cannot be partnered with VxRail Appliances for RecoverPoint for Virtual Machines-based disaster recovery protection services.

Rules and

considerations

(VxRack

Systems)



VxRack Systems were designed with NSX in mind, therefore configuring NSX on VxRack

Systems for Enterprise Hybrid Cloud is relatively straightforward. Relevant considerations

are:

VxRack Systems are built with ToR switches that are configured for Layer 3. This is ideal for NSX deployments.

VxRack Systems, since they have ToR switches that are configured for Layer 3, are not normally deployed with virtual port channel connections between the ToR switches and the customer’s switches.

When deploying NSX on VxRack Systems, some servers must be dedicated to the Edge cluster. This Edge cluster forms the physical to virtual demarcation point between NSX and the customer’s physical network.

All north-south traffic flows through the ESGs in the Edge cluster, Dell 630/730 servers are used to provide 10 GB connectivity to TOR switches.

Enterprise Hybrid Cloud on VxBlock Systems


VxBlock System.

Table 26. Characteristics of Enterprise Hybrid Cloud on VxBlock Systems



Backup as a service





None

Cluster types LC1S

CA1S

CA2S

DR2S

VS1S

Backup types 1C1VC

2C2VC

2C1VC

MC2VC

None

Physical

connectivity

considerations

Enterprise

Hybrid Cloud

features

supported on a

VxBlock System



Solution Guide



Single-site protection (VxBlock Systems)—Use this overlay when you have a single-site deployment and do not intend to provide inter-site protection for the CMP.

Continuous availability protection (VxBlock Systems)—Use this overlay when you have a multisite deployment, and want to provide inter-site protection for the CMP via continuous availability.

RecoverPoint for Virtual Machines DR protection (VxBlock Systems)—Use this overlay when you have a multisite deployment and want to provide inter-site protection for the CMP via RecoverPoint for Virtual Machines.

Site Recovery Manager DR protection (VxBlock Systems)—Use this overlay when you have a multisite deployment and want to provide inter-site protection for the CMP via Site Recovery Manager.

When Enterprise Hybrid Cloud is deployed with single-site protection on VxBlock

Systems:

The high-performance Advanced Management Platform (AMP-2HAP) option from Dell EMC is required. AMP-2HAP ensures sufficient compute resources exist to run all native AMP management components and the Enterprise Hybrid Cloud Core Pod components.

A single vCenter is the default as the Enterprise Hybrid Cloud ‘Cloud vCenter’ role is provided by the AMP vCenter.

Core and NEI Pod functions are deployed and configured in-factory.

The Enterprise Hybrid Cloud NEI Pod function is split across the AMP and Edge clusters.

The Edge cluster uses Cisco UCS C-Series (configurable based on bandwidth requirements) or B-Series.

Automation Pod components consume production blades. They are deployed in-factory but are configured onsite.


configuration.

Understanding

which

architectural

overlay to use

Architecture

overlay: Single-

site protection

(VxBlock

Systems)



Figure 42. Architecture overlay: Single-site protection with VxBlock Systems

When Enterprise Hybrid Cloud is deployed with continuous availability protection on

VxBlock Systems:

The high-performance AMP-2HAP option is required. AMP-2HAP ensures sufficient compute resources exist to run all native AMP management components, and the Enterprise Hybrid Cloud Core Pod components.

A single vCenter is the default as the Enterprise Hybrid Cloud ‘Cloud vCenter’ is provided by the AMP vCenter.

Core and NEI Pod functions are deployed and configured in-factory.

Selected components are deployed on each site and use local storage. The

remaining components are shared across sites and use VPLEX storage.

The Enterprise Hybrid Cloud NEI Pod function is split across the AMP and Edge clusters.

Architecture

overlay:

Continuous

availability-

protection

(VxBlock

Systems)



Solution Guide

The Edge cluster uses Cisco UCS C-Series (configurable based on bandwidth requirements).

Automation Pod components consume production blades. They are deployed in-factory but are configured onsite.

VPLEX Metro is required for storage replication.


configuration.

Figure 43. Architecture overlay: Continuous Availability Site Protection with VxBlock Systems



When Enterprise Hybrid Cloud is deployed with RecoverPoint for Virtual Machines

disaster recovery protection on a VxBlock System:

The high-performance AMP-2HAP option is required. AMP-2HAP ensures sufficient compute resources exist to run all native AMP management components as well as the Enterprise Hybrid Cloud Core Pod components.

A single vCenter per site is the default as the Enterprise Hybrid Cloud ‘Cloud vCenter’ role is provided by the AMP vCenter.

Core and NEI Pod functions are deployed and configured in the Dell EMC factory.

The Enterprise Hybrid Cloud NEI Pod function is split across AMP and Edge clusters.



RecoverPoint for Virtual Machines is required for virtual machine replication.


Virtual RecoverPoint Appliances (vRPAs) are deployed to tenant resource pods and scale in line with the number of protected virtual machines.


configuration.

Architecture

overlay:

RecoverPoint for

Virtual Machines

DR protection

(VxBlock

Systems)



Solution Guide

Figure 44. Architecture overlay: RecoverPoint for Virtual Machines DR protection with VxBlock Systems

When Enterprise Hybrid Cloud is deployed with SRM-based disaster recovery protection

on a VxBlock System:

The high-performance AMP-2HAP option is required. AMP-2HAP ensures sufficient compute resources exist to run all native AMP management components as well as the Enterprise Hybrid Cloud Core Pod components.

A single vCenter per site is the default as the Enterprise Hybrid Cloud ‘Cloud vCenter’ role is provided by the AMP vCenter.

Core and NEI Pod functions are deployed and configured in the Dell EMC factory.

The Enterprise Hybrid Cloud NEI Pod function is split across AMP and Edge clusters.



RecoverPoint is required for storage replication.


Architecture

overlay: Site

Recovery

Manager DR

protection

(VxBlock

Systems)




configuration.

Figure 45. Architecture overlay: Site Recovery Manager DR protection with VxBlock Systems


deployments on VxBlock Systems:

If VxBlock Systems is to partner with another converged infrastructure platform to provide RecoverPoint for Virtual Machines or Site Recovery Manager-based disaster recovery protection service, then both the VxBlock System vCenter and its partner’s vCenter must co-exist in the same VMware SSO domain.

Note: To avoid onsite remediation of partner VxBlock Systems, the ideal situation is to

have both VxBlock Systems installed in-factory.

VxBlock Systems cannot be partnered with VxRail Appliances for RecoverPoint for Virtual Machines-based disaster recovery protection services.

Rules and

considerations

(VxBlock

Systems)



Solution Guide

Dell EMC VxBlock Systems were designed with NSX in mind, so configuring NSX on a

VxBlock System for Enterprise Hybrid Cloud is relatively straightforward. Relevant

considerations are:

VxBlock Systems are built with ToR switches that are configured for Layer 3. This is ideal for NSX deployments.

VxBlock Systems already have a disjointed Layer 2 (DJL2) configuration between the fabric interconnects and the ToR switches to support dynamic routing.

VxBlock Systems, since they have ToR switches that are configured for Layer 3, are not normally deployed with virtual port channel connections between the ToR switches and the customer’s switches.

When deploying NSX on VxBlock Systems, some servers must be dedicated to the Edge cluster. This Edge cluster forms the physical to virtual demarcation point between NSX and the customer’s physical network. All north-south traffic flows through the edge cluster. VxBlock Systems support C-Series servers for use in the Edge cluster. C-Series servers have an excellent throughput profile. Two different types of C-Series are offered: One that supports 10 Gb/s of throughput, and one that supports 20 Gb/s of throughput, so sizing the Edge cluster is still important.

Physical

connectivity

considerations

Chapter 9: Ecosystem Interactions


Chapter 9 Ecosystem Interactions


Single-site ecosystems................................................................................... 117

Continuous availability ecosystem ................................................................ 118

Disaster recovery ecosystems ....................................................................... 119



Solution Guide

Single-site ecosystems

Figure 46 shows how the concepts in this guide combine under the single-site protection

service.

Figure 46. Single-site protection ecosystem

Single-site

ecosystem



Continuous availability ecosystem

Figure 47 shows how the concepts in this guide combine under the Continuous Availability

(Dual-site) protection service.

Figure 47. Continuous Availability (Dual-site) protection ecosystem

Continuous

Availability

(Dual-site)

ecosystem



Solution Guide

Disaster recovery ecosystems

Figure 48 shows how the concepts in this guide combine under the RecoverPoint for

Virtual Machines-based disaster recovery protection service.

Figure 48. RecoverPoint for Virtual Machines-based disaster recovery protection ecosystem

Disaster

recovery

(RecoverPoint

for Virtual

Machines)

ecosystem



Figure 49 shows how the concepts in this guide combine under the SRM-based DR

protection service.

Figure 49. SRM-based disaster recovery protection ecosystem

Disaster

recovery (Site

Recovery

Manager)

ecosystem

Chapter 10: Maximums, Rules, Best Practices, and Restrictions


Solution Guide

Chapter 10 Maximums, Rules, Best Practices, and Restrictions


Overview .......................................................................................................... 122

Maximums ....................................................................................................... 122

VMware Platform Services Controller rules .................................................. 127

Active Directory .............................................................................................. 128

VMware vRealize tenants and business groups ........................................... 129

Dell EMC ViPR tenant and projects rules ...................................................... 130

Bulk import of virtual machines ..................................................................... 130

Resource sharing ............................................................................................ 131

Data protection considerations ...................................................................... 131

RecoverPoint for Virtual Machines best practices ....................................... 132

Software resources ......................................................................................... 132

Sizing guidance ............................................................................................... 132

Restrictions ..................................................................................................... 133

Component options ........................................................................................ 134



Overview

This chapter looks at the maximums, rules, best practices, restrictions, and dependencies

between Enterprise Hybrid Cloud components and their constructs, outlining how this

influences the supported configurations within the cloud.

Maximums

Table 27 shows the maximums related to vCenter endpoints in Enterprise Hybrid Cloud.

Table 27. vCenters per Enterprise Hybrid Cloud instance

Total number of Maximum

Managed vCenter endpoints with full Enterprise Hybrid Cloud services (VxBlock/VxRack FLEX-based CMP)

4*

Managed vCenter endpoints with full Enterprise Hybrid Cloud services (VxRail Appliance-based CMP)

4

vCenter endpoints (Managed or IaaS-only) in a single SSO domain 10

vCenter endpoints configured as vRealize Automation endpoints 10

vCenters that may offer continuous availability protection (VxBlock/VxRack FLEX-based CMP)

4**

vCenters pairs that may offer SRM-based disaster recovery protection (VxBlock/VxRack FLEX-based CMP)

1**

vCenters pairs that may offer RecoverPoint for Virtual Machines-based disaster recovery protection (VxBlock/VxRack FLEX-based CMP)

2

*All managed vCenter endpoints must be part of the same SSO domain (also known as Enterprise

Hybrid Cloud-managed SSO domain).

**CMP must be VxBlock/VxRack FLEX-based and the source target endpoints must be VxBlock-

based.

Table 28 shows the maximums that apply per vCenter endpoint.

Table 28. Per vCenter maximums


Enterprise Hybrid Cloud sites (VxBlock/VxRack FLEX-based CMP) 2

Enterprise Hybrid Cloud sites (VxRail Appliance-based CMP) 1

Hosts per cluster 64

Virtual machines per cluster 8,000

Hosts per vCenter Server 1,000

Powered-on virtual machines per vCenter Server 10,000

Registered virtual machines per vCenter Server 15,000

vCenter

maximums



Solution Guide

Table 29 shows the maximums that apply to SSO domains used in Enterprise Hybrid

Cloud.

Table 29. SSO maximums


Managed SSO domains (VxBlock/VxRack FLEX-based CMP)* 1

Managed SSO domains (VxRail Appliance-based CMP)** 4

SSO domains 10***

*VxBlock/VxRack FLEX systems must reside in the same SSO domain.

**VxRail Appliances may reside in different SSO domains.

***External SSO domains (if used) do not contribute to this number.

Table 30 shows the maximums that apply to Enterprise Hybrid Cloud sites.

Table 30. Site maximums


Standalone sites per Enterprise Hybrid Cloud instance (VxBlock/VxRack FLEX-based CMP)

4

Standalone sites per Enterprise Hybrid Cloud instance (VxRail Appliance-based CMP)

4

Sites where all managed vCenter endpoints provide continuous availability protection (VxBlock/VxRack FLEX-based CMP)

8

Note: Enterprise Hybrid Cloud with VxBlock/VxRack FLEX-based CMP supports a maximum of

four sites when using single-site protection or DR protection. This may be increased to eight sites

when all the vCenters in the solution have two sites associated with it.

Note: The number of sites supported is influenced by the number of vCenters per site. For

example, if four vCenters are provisioned on the first site, then vCenter maximums take

precedence.

Table 31 shows the maximums that apply for Platform Service Controllers (PSCs).

Table 31. PSC maximums


PSCs per vSphere domain 8

PSCs per site, behind a load balancer 4

Active Directory or OpenLDAP Groups per user for best performance 1,015

VMware Solutions* connected to a single PSC 4

VMware Solutions* in a vSphere domain 10

SSO maximums

Site maximums

PSC maximums



*VMware Solutions is a term provided by VMware. In the case of Enterprise Hybrid Cloud, this

equates to VMware vCenter Server instances.

Table 32 shows the maximums that apply for virtual machines.

Table 32. Virtual machines maximums


Virtual machines managed by Enterprise Hybrid Cloud 30,000*

Powered-on virtual machines protected by CA 10,000

Registered virtual machines protected by CA 15,000

Virtual machines protected by SRM-based DR 5,000

Virtual machines protected by RecoverPoint for Virtual Machines-based DR (individually recoverable) per vCenter

5,120**

Virtual machines protected by RecoverPoint for Virtual Machines-based DR (using multi-machine consistency groups) per vCenter

5,120**

Virtual machines protected by RecoverPoint for Virtual Machines-based DR (individually recoverable) for each Enterprise Hybrid Cloud instance

10,240**

Virtual machines protected by RecoverPoint for Virtual Machines-based DR (using multi-machine consistency groups) for each Enterprise Hybrid Cloud instance.

10,240**

*This number is governed by the maximum number of virtual machines supported by a two-node

vRealize Orchestrator cluster.

**If the Enterprise Hybrid Cloud Automation Pod is also being protected using RecoverPoint for

Virtual Machines, then a RecoverPoint vRPA cluster must be dedicated for this purpose,

effectively reducing the number of individually protected virtual machine workloads by 128.

Table 33 shows the maximums that apply with respect to latencies in the solution.

Table 33. Latency maximums

Context Maximum

VPLEX uniform (cross-connect) configuration 5ms

VPLEX non-uniform (Non-cross-connect) configuration 10ms

Cross-vCenter NSX network latency 150ms

RecoverPoint for Virtual Machines latency between sites 200ms

Virtual machine

maximums

Latency

maximums



Solution Guide

Protection maximums

Table 34 shows the maximums that apply for SRM-protected resources.

Table 34. SRM protection maximums


Virtual machines configured for protection using array-based replication 5,000

Virtual machines per protection group 500

Protection groups 250

Recovery plans 250

Protection groups per recovery plan 250

Virtual machines per recovery plan 2,000

Replicated datastores (using array-based replication) and >1 RecoverPoint cluster

255

Recovery maximums

Table 35 shows the maximums that apply for SRM recovery plans.

Table 35. SRM protection maximums


Concurrently executing recovery plans 10

Concurrently recovering virtual machines using array-based replication 2,000

Storage maximums

Table 36 indicates the storage maximums with SRM-based DR in Enterprise Hybrid

Cloud, when all other maximums are taken into account.

Table 36. Implied Enterprise Hybrid Cloud storage maximums


DR-enabled datastores per RecoverPoint consistency group 1

DR-enabled datastores per RecoverPoint cluster 128

DR-enabled datastores per Enterprise Hybrid Cloud environment 250

To ensure maximum protection for DR-enabled vSphere clusters, Enterprise Hybrid Cloud

STaaS workflows create each LUN in its own RecoverPoint consistency group. This

ensures that ongoing STaaS provisioning operations have no effect on either the

synchronized state of existing LUNs or the history of restore points for those LUNs

maintained by RecoverPoint.

Because there is a limit of 128 consistency groups per RecoverPoint cluster, there is

therefore a limit of 128 Enterprise Hybrid Cloud STaaS provisioned LUNs per

RecoverPoint cluster. To extend the scalability further, additional RecoverPoint clusters

are required.

Site Recovery

Manager

maximums



Each new datastore is added to its own SRM protection group. Because there is a limit of

250 protection groups per SRM installation, this limits the total number of datastores in a

DR environment to 250, irrespective of the number of RecoverPoint clusters deployed.

There is a limit of 64 consistency groups per RecoverPoint appliance and 128 consistency

groups per RecoverPoint cluster. Therefore, the number of nodes deployed in the

RecoverPoint cluster should be sized to allow appropriate headroom for surviving

appliances to take over the workload of a failed appliance.

Table 37 shows the maximums that apply for latencies in the solution.

Table 37. RecoverPoint for Virtual Machines maximums


Enterprise Hybrid Cloud vCenter endpoints connected to a vRPA cluster 1*

vRPA clusters connected to a vCenter Server instance 50

Recommended number of vRPA clusters per ESXi cluster 4**

Virtual machines protected by a single Enterprise Hybrid Cloud LC1S cluster

512***

Virtual machines in a vCenter protected 5,120

Protected VMDKs per vRPA cluster 2,048

Protected VMDKs per ESXi cluster 5,120

ESXi hosts with a splitter that can be attached to a vRPA cluster 64

Enterprise Hybrid Cloud LC1S/VS1S clusters connected to a vRPA cluster

1*

Consistency groups per vRPA cluster 128

Virtual machines per consistency group 128

Replica sites per RecoverPoint for Virtual Machines system 1*

Replica copies per consistency group 1*

Capacity of a single VMDK 10 TB

Capacity of a replicated virtual machine 40 TB

*These figures are Enterprise Hybrid Cloud best practices based on architecture design and differ

from the numbers that RecoverPoint for Virtual Machines natively supports.

**Recommendation based on Enterprise Hybrid Cloud tested configurations.

***Based on best practice of four vRPA clusters per ESXi cluster, and 128 consistency groups per

vRPA cluster.

RecoverPoint

cluster

limitations

RecoverPoint for

Virtual Machines

maximums



Solution Guide

VMware Platform Services Controller rules

The section on Platform Services Controller rules only applies to Enterprise Hybrid Cloud

instances that run on a VxBlock or VxRack FLEX-based CMP.

A VMware PSC is deployed on a dedicated virtual machine in each Core Pod (multiple

Core Pods in multisite environments) and an additional PSC (Auto-PSC) is deployed in

the Automation Pod.

The Auto-PSC provides authentication services to all the Automation Pod management

components requiring PSC integration. This configuration enables authentication services

to fail over with the other automation components and enables a seamless transition

between sites. There is no need to change IP addresses, Domain Name System (DNS),

or management component settings.

Enterprise Hybrid Cloud uses one or more SSO domains, depending on the management

platform deployed. PSC instances are configured within those domains according to the

following model:

External SSO domain (external core function only)

First external PSC

Additional external PSCs (multisite/multi-vCenter configurations)

Managed (also known as Cloud) single sign-on (SSO) domain (all topologies)

First Cloud PSC

Automation Pod PSC

Additional Cloud PSCs (multisite/multi-vCenter configurations only)

IaaS-only SSO domains

First IaaS-only PSC

Additional IaaS-only PSCs as required

Note: An external SSO domain is only used in Enterprise Hybrid Cloud where an external vCenter

is used to host the Core Pod and Cloud vCenter. This is true in case of VxRack Systems and in

Enterprise Hybrid Cloud instances that were upgraded from the Distributed Management Model

used in older releases.

Figure 50 shows an example of how the PSC domains and each PSC instance and

domain required could be configured in an environment with the following characteristics:

Three sites, each with their own Cloud vCenter endpoint

Site A is the primary location for the CMP

Inter-site protection of the CMP is required between Site A and Site B

No external PSC domain was required

Note: The partner replication relationships within the SSO domain shown in Figure 50 are

permitted to be in different sequences depending on when each geographical location was

deployed. The key factor is that a replication ring is formed between all the PSC instances.

Applicability

Platform

Services

Controller

domains



Figure 50. SSO domain and vCenter PSC instance relationships

The first VMware PSC deployed in each SSO domain is deployed by creating a new

vCenter SSO domain and enabling it to participate in the default vCenter SSO namespace

(vsphere.local). This primary PSC server supports identity sources, such as Active

Directory, OpenLDAP, local operating system users, and SSO-embedded users and

groups.

This is the default deployment mode when you install VMware PSC.

Additional VMware PSC instances are installed by joining the new PSC to an existing

SSO domain, making them part of the existing domain but in a new SSO site. When you

create PSC servers in this way, the deployed PSC instances become members of the

same authentication namespace as the PSC instance. This deployment mode should only

be used after you have deployed the first PSC instance in each SSO domain.

In vSphere 6.0, VMware PSC SSO data (such as policies, solution users, application

users, and identity sources) is automatically replicated between each PSC instance in the

same authentication namespace every 30 seconds.

Active Directory

All vCenter endpoints (managed and IaaS only) must be integrated with the same active

directory domain.

First PSC

instance in each

SSO domain

Subsequent PSC

instances in

each single sign-

on domain

Active directory

considerations



Solution Guide

VMware vRealize tenants and business groups

Enterprise Hybrid Cloud is designed for use in single vRealize Automation tenant

configurations. Enterprise multitenancy may be provided by using a single vRealize

Automation tenant with multiple vRealize Automation business groups. To deploy multiple

vRealize Automation tenants, use separate Enterprise Hybrid Cloud instances. As the

vRealize Automation IaaS administrator is a system-wide role, having multiple vRealize

Automation tenants within the same vRealize Automation instance may not provide any

additional value over and above the use of a single tenant with multiple business groups.

Enterprise Hybrid Cloud uses two system business groups. The first, EHCSystem, is

used as the target for installation of the vRealize Automation advanced services, EHC

Configuration and Storage-as-a-Service catalog items. It does not require any compute

resources. The second system business group, EHCOperations, is used as the group

where Enterprise Hybrid Cloud administrators are configured. It is given entitlements to

Storage-as-a-Service and EHC Configuration service catalog items. It has no compute

resource requirements.

Dell EMC recommends that applications provisioned using vRealize Automation

Application Services each have a separate business group per application type to enable

administrative separation of blueprint creation and manipulation.

Figure 51 shows an example where the EHCSystem and EHCOperations system

business groups are configured alongside three tenant business groups (IT, HR, and

Manufacturing) and three application business groups used by vRealize Automation

Application Services for Microsoft SharePoint, Oracle, and Microsoft Exchange.

Figure 51. Software-defined data center tenant design and endpoints

vRealize

Automation

multi-tenancy

vRealize

Automation

Business Group

Design

vRealize

Automation

business group

best practice



Dell EMC ViPR tenant and projects rules

Enterprise Hybrid Cloud uses a single ViPR tenant. The default provider tenant or an

additional non-default tenant may be used.

Enterprise Hybrid Cloud storage-as-a-service operations use a single ViPR project as

defined by the default_vipr_project global option. Changing the value of this option is

done using the vRealize Automation catalog item entitled Global Options Maintenance.

ViPR consistency groups are an important component of the CA and SRM-based DR

protection services for Enterprise Hybrid Cloud. Consistency groups logically group

volumes within a project to ensure that a set of common properties is applied to an entire

group of storage volumes during a fault event. This ensures host-to-cluster or application-

level consistency when a failover occurs.

Consistency groups are created by Enterprise Hybrid Cloud STaaS operations and are

specified when VPLEX or RecoverPoint protected volumes are provisioned. Consistency

group names must be unique within the ViPR environment.

When used with VPLEX in the CA protection service, these consistency groups are

created per physical array, per vSphere cluster, and per site.

When used with RecoverPoint in the SRM-based DR protection service, these

consistency groups are created in 1:1 relationship with the vSphere datastore/LUN.

Bulk import of virtual machines

For environments that require existing virtual machines to be imported into Enterprise

Hybrid Cloud, the bulk import feature of vRealize Automation enables the importation of

one or more virtual machines.

This functionality is available only to vRealize Automation users who have Fabric

Administrator and Business Group Manager privileges. The bulk import feature imports

virtual machines intact with defining data such as reservation, storage path, blueprint,

owner, and any custom properties.

Enterprise Hybrid Cloud offers the ability to layer Enterprise Hybrid Cloud services onto

pre-existing virtual machines by using and extending the bulk import process. Before

beginning the bulk import process, the following conditions must be true:

Target virtual machines are located in an Enterprise Hybrid Cloud vCenter endpoint.

Target virtual machines must be located on the correct vRealize Automation managed compute resource cluster and that cluster must already be onboarded as an Enterprise Hybrid Cloud cluster, where:

SRM-based DR protection is required for the target virtual machines, they must be on a DR2S cluster.

ViPR tenants

ViPR projects

ViPR

consistency

groups

Importing from

virtual machines

and adding

Enterprise

Hybrid Cloud

services



Solution Guide

Data protection services are required for the target virtual machines, they must be on a cluster that is associated with an ASR.

Target virtual machines must be located on the correct vRealize Automation managed datastore, where:

SRM-based DR protection is required for the target virtual machines, they must be on a datastore protected by EMC RecoverPoint.

Data protection services are required for the target virtual machines, they must be on a datastore that is already registered with an Avamar proxy.

Note: The process for importing these virtual machines and adding Enterprise Hybrid Cloud

services is in the Enterprise Hybrid Cloud 4.1.2 Administration Guide.

Resource sharing

As vRealize Automation endpoints are visible to all vRealize Automation IaaS

administrators, resource isolation in the truest sense is not possible. However, use of

locked blueprints and storage reservation policies can be used to ensure that certain

types of workload (such as those whose licensing is based on CPU count) can be

restricted to only a subset of the Workload Pods available in the environment. This

includes the ability to control those licensing requirements across tenants by ensuring that

all relevant deployments are on the same set of compute resources.

All endpoints configured across the vRealize Automation instance by an IaaS

administrator are available to be added to fabric groups, and therefore consumed by any

business group across any of the vRealize Automation tenants.

Provisioning to vCenter endpoints, however, can still only be done through the tenant

configured as part of the Enterprise Hybrid Cloud process.

Dell EMC recommends that applications provisioned using vRealize Automation

application services each have their own business group by application type to enable

administrative separation of blueprint creation and manipulation.

Data protection considerations

Enterprise Hybrid Cloud supports physical Avamar infrastructure in the combinations in

Table 38, based on the converged infrastructure platform in use.

Table 38. Supported Avamar and Data Domain combinations

Converged infrastructure

Avamar

infrastructure

Backed by Data Domain

infrastructure

VxRail Appliances Avamar Virtual Edition Data Domain Virtual Edition

Avamar Physical Edition Data Domain Physical Edition

VxRack Systems Avamar Virtual Edition Data Domain Virtual Edition

Resource

isolation

Resource

sharing

Application

tenant

integration

Supported

Avamar and Data

Domain

combinations



Converged infrastructure

Avamar

infrastructure

Backed by Data Domain

infrastructure

Avamar Physical Edition Data Domain Physical Edition

VxBlock Systems Avamar Physical Edition Data Domain Physical Edition

Note: When using the Avamar Virtual Edition and Data Domain Virtual Edition combinations, the

Data Domain Virtual Edition appliance must be hosted on Dell PowerEdge Servers.

Note: Avamar Virtual Edition and Data Domain Virtual Edition combinations should only be based

on sizing efforts by Dell EMC ascertaining that they are appropriate to support the scale of the

particular environment.

RecoverPoint for Virtual Machines best practices

Use of RecoverPoint for Virtual Machines requires the deployment of virtual RecoverPoint

Appliances (vRPAs). These vRPAs are considered tenant workloads, and are therefore

deployed to the tenant pods and not to the Enterprise Hybrid Cloud management pods.

Best practice suggests that distinct tenant resource pods are used to host the vRPAs to

separate the vRPAs from the workloads that they are protecting. The Enterprise Hybrid

Cloud sizing tool provides sizing for RecoverPoint for Virtual Machines based on this best

practice.

Dell EMC recommends a default ratio of four vRPA clusters to every onboarded LC1S

(Local Copy on One Site) cluster. This allows for up to 512 individually recoverable virtual

machines on that cluster.

The Enterprise Hybrid Cloud sizing tool provides sizing for RecoverPoint for Virtual

Machines based on this best practice.

Software resources

For information about components required for the initial release of Enterprise Hybrid

Cloud 4.1.2, refer to Enterprise Hybrid Cloud 4.1.2 Foundation Infrastructure Reference

Architecture. For up-to-date supported version information, refer to the Enterprise Hybrid

Cloud Simple Support Matrix on Dell EMC Online Support.

Sizing guidance

For all Enterprise Hybrid Cloud sizing operations, refer to the EHC Management Sizing

Tool.

Resources for

Virtual

RecoverPoint

Appliances

Ratio of Virtual

RecoverPoint

Appliances to

vSphere clusters

Enterprise

Hybrid Cloud

software

resources

Enterprise

Hybrid Cloud

sizing

https://mainstayadvisor.com/go/emc

https://mainstayadvisor.com/go/emc



Solution Guide

Restrictions

Load balancers cannot be deployed as part of a DR-protected multi-machine blueprint, as

the corresponding load balancers would not be deployed on the secondary site. However,

you can manually edit the upstream Edge to include load-balancing features for a newly

deployed multi-machine blueprint.

Provisioning during SRM-based disaster recovery protection failed-over state

Provisioning of virtual machines to a protected DR2S cluster is permitted at any time, as

long as that site is operational. If you provision a virtual machine while the recovery site is

unavailable due to vCenter SRM DR failover, you must run the DR Remediator catalog

item to bring it into protected status when the recovery site is back online.

During STaaS provisioning of a protected datastore to a DR2S cluster, Enterprise Hybrid

Cloud workflows issue a DR auto-protect attempt for the new datastore within vCenter

SRM. If both sites are operational when the request is issued, this should be successful.

However, if one site is offline when the request is made, the datastore will be provisioned,

but you must run the DR Remediator catalog item to bring it into a protected status.

Note: The DR Remediator catalog item can be run at any time to ensure that all DR items are

protected correctly.

SRM-based DR protection

While replication is at the datastore level, the unit of failover with SRM-based DR

protection DR2S-enabled cluster, that is, all workloads on a specified DR2S cluster must

fail over at the same time. It is not possible to fail over a subset of virtual machines on a

single DR2S cluster. This is because all networks supporting these virtual machines

converge to the recovery site during a failover.


With RecoverPoint for Virtual Machines-based DR protection, failover granularity is set at

the RecoverPoint for Virtual Machines consistency group level in that all workloads in a

specified consistency group must fail over at the same time. Given that it is possible to

have just one virtual machine in a consistency group, this means that failover can happen

at an individual virtual machine level.

SRM-based DR protection

Enterprise Hybrid Cloud provides fully automated network re-convergence during disaster

recovery failover when using VMware NSX only. The use of vSphere distributed switches

backed by other networking technologies is also permitted, but requires that network re-

convergence is carried out manually in accordance with the chosen network technology or

that automation of network re-convergence is developed as a professional services

engagement.

Multi-machine

blueprints

vRealize

Automation

Disaster

recovery failover

granularity

Disaster

recovery

network support




In this case, the networking requirements for the solution mandate that the network is

simultaneously available on both sites. Enterprise Hybrid Cloud fully tests and supports

the use of cross-vCenter VMware NSX to achieve this. The use of vSphere distributed

switches backed by other networking technologies is also permitted, but requires that

network configuration is designed and carried out independently of Enterprise Hybrid

Cloud implementation or as part of a professional services engagement.

Enterprise Hybrid Cloud only supports the assignment of blueprint virtual machines to a

security group. It does not support the assignment of blueprints to security policies or

security tags.

Enterprise Hybrid Cloud supports RecoverPoint CL-and EX-based licensing only. It does

not support RecoverPoint SE.

Component options

The following assumptions and justifications apply to Enterprise Hybrid Cloud:

VMware PSC is used instead of the vRealize Automation identity appliance because PSC supports the multisite, SSO requirements of Enterprise Hybrid Cloud.

Appliance-based VMware PSCs are the default, but Windows-based instances are supported for backwards compatibility with older versions of Enterprise Hybrid Cloud. New deployments should use the appliance-based version.

Appliance-based vCenter Server instances are the default, but Windows-based instances are supported for backwards compatibility with older versions of Enterprise Hybrid Cloud. New deployments should use the appliance-based version.

Disaster

recovery NSX

security support

Supported

RecoverPoint

licensing types

Assumption and

justifications

Chapter 11: Conclusion


Solution Guide

Chapter 11 Conclusion


Conclusion ...................................................................................................... 136

Chapter 11: Conclusion


Conclusion

Enterprise Hybrid Cloud provides on-demand access and control of infrastructure

resources and security while enabling customers to maximize asset use across a multisite

deployment. Specifically, it integrates all the key functionality that customers demand of a

hybrid cloud and provides a framework and foundation for adding other services.

Enterprise Hybrid Cloud provides the following features and functionality:

Continuous availability

Disaster recovery

Data protection

Automation and self-service provisioning

Workload-optimized storage

Elasticity and service assurance

Monitoring

Metering and showback

Encryption

Enterprise Hybrid Cloud uses the best of Dell EMC and VMware products and services to

empower customers to accelerate the implementation and adoption of hybrid cloud while

still enabling customer choice for the compute and networking infrastructure within the

data center.

ENTERPRISE HYBRID CLOUD 4.1 - Dell EMC US · PDF fileENTERPRISE HYBRID CLOUD 4.1.2 Concepts...

Documents

Transcript of ENTERPRISE HYBRID CLOUD 4.1 - Dell EMC US · PDF fileENTERPRISE HYBRID CLOUD 4.1.2 Concepts...