VMware Horizon 7 Enterprise Edition Multi-Site Reference ...euc-kiwi.com/wp-content/uploads/2017/11/vmware... · VMWARE HORIZON 7 ENTERPRISE EDITION MULTI-SITE REFERENCE ARCHITECTURE

TECHNICAL WHITE PAPER – NOVEMBER 2017

VMWARE HORIZON 7 ENTERPRISE EDITION MULTI-SITE REFERENCE ARCHITECTURE VMware Horizon 7 Version 7.2 and Later

T E C H N I C A L W H I T E PA P E R | 2

VMWARE HORIZON 7 ENTERPRISE EDITION MULTI-SITE REFERENCE ARCHITECTURE

Table of ContentsExecutive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

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

Design Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

JMP – Next-Generation Desktop and Application Delivery Platform . . . . . . . . . . . . . . . . . . . . . . . . 8

VMware Reference Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Business Drivers and Use Cases Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Meeting Business Requirements with Multi-Site Horizon 7 Deployments . . . . . . . . . . . . . . . . . . . 10

Use Case Recovery Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Recovery Service Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Active/Active Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Active/Passive Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Multi-Site Architecture Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Horizon 7 Pod and Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Architectural Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

General Multi-Site Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Horizon 7 Component Design with a Disaster Recovery Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

VMware Identity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Horizon 7 with Cloud Pod Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Unified Access Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

App Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

User Environment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

vSphere Infrastructure Design for Active/Active and Active/Passive Services . . . . . . . . . . . . . . . . . 44

View Pod and Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Storage Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

Environment Infrastructure Dependencies Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Distributed File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Global Load Balancing and Name Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Microsoft RDS Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Microsoft KMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52



Horizon 7 Components Required for Recovery Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Active/Active Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Active/Passive Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Reference Architecture Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Active/Active Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

Active/Passive Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

vSAN Stretched Cluster Active/Passive Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Recovery Service Definition for Stretched vSAN Active/Passive Service . . . . . . . . . . . . . . . . . . . 65

Architectural Approach for the Stretched Active/Passive Service . . . . . . . . . . . . . . . . . . . . . . . . . . 66

vSphere Infrastructure Design Using vSAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Horizon 7 Components Required for vSAN Stretched Cluster Recovery Services . . . . . . . . . . . . 71

Reference Architecture Validation for vSAN Stretched Cluster Active/Passive Service . . . . . . 72

Appendix A: Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Appendix B: Active/Active and Active/Passive Services with Replicating Storage Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Appendix C: Infrastructure Design for the Stretched vSAN Active/Passive Service . . . . . . . . . . . . 76

Appendix D: Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Active/Active Horizon 7 Service Failover Test/Recovery Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80

Active/Passive Horizon 7 Service Failover Test/Recovery Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Active/Passive Horizon 7 Service Failover Test/Recovery Plan on vSAN Stretched Cluster . . 86

Appendix E: F5 Load-Balancing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Appendix F: PowerShell Script for Replicating App Volumes Application Entitlements . . . . . . . . . 90

Appendix G: Setting Up VMware Identity Manager for High Availability in Multiple Sites . . . . . . . . .91

Create a Windows Server Failover Cluster and Configure Shared Storage . . . . . . . . . . . . . . . . . . . 92

Install the SQL Server Failover Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

Configure Cluster Quorum Settings and Possible Owners for Each Cluster Instance . . . . . . . . . 95

Create the VMware Identity Manager Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Create and Configure the SQL Server Always On Availability Group for VMware Identity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Deploy and Set Up VMware Identity Manager Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Configure Failover and Redundancy for VMware Identity Manager . . . . . . . . . . . . . . . . . . . . . . . 109

Deploy and Set Up the VMware Identity Manager Connectors Inside the Corporate Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Finalizing Failover Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113



Appendix H: Setting Up VMware App Volumes for High Availability in Multiple Sites . . . . . . . . . . . 114

Create a Windows Server Failover Cluster in Each Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Install SQL Server 2014 Stand-Alone in All VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Create the App Volumes Databases and Enable Availability Groups for the Clusters . . . . . . . . 120

Create Always On Availability Groups for App Volumes Databases . . . . . . . . . . . . . . . . . . . . . . . . 122

Configure Cluster Quorum Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Install App Volumes to Use a Highly Available Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Appendix I: Configuration Procedures for a Clustered App Volumes Database . . . . . . . . . . . . . . . . 131

Create the App Volumes Clustered Database Using Backup and Restore . . . . . . . . . . . . . . . . . . 132

Install and Configure App Volumes Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134

About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135



Executive Summary Building and implementing a VMware Horizon® 7 Enterprise Edition environment to deliver services from multiple sites can be done for a variety of reasons such as geographical usage, scale, or to provide business continuity. This reference architecture designs and validates the most typical configuration and requirements for a two-data-center strategy.

One initial aim that organizations have is to provide disaster recovery with the lowest possible Recovery Time Objective (RTO) and Recovery Point Objective (RPO) in case of a site failure while providing a consistent end-user experience. Ultimately, organizations want to keep the business operating during an extended or catastrophic technology outage, providing continuity of service and allowing staff to carry out their day-to-day responsibilities. With services, applications, and data delivered by Horizon 7, that means providing continuity of service and mitigating against component failure, all the way up to a complete data center outage.

This reference architecture details and shows validation of a Horizon 7 Enterprise Edition solution that delivers business continuity and disaster recovery to a set of identified use cases. The services designed and delivered to users focus on availability and recoverability, but can be easily adapted to general multi-site requirements.

Profile

User Apps

Desktop / RDSH Clone

Service

Attached Apps

Windows OS

ActiveSit

e 1 Instant or

Linked Clone AppStacksWritableVolume

ITConfig

Master VM

Desktop Pool/RDSH Farm

Apps

UserSettings

HomeFile

Shares

User Apps


Standby Service

Attached Apps

Windows OS

Active

Replication

Sit

e 2

Failover

Desktop Pool/RDSH Farm ProfileApps

Client(s)

User

Figure 1: Example Service Blueprint

To build the environment necessary to deliver highly available services to users, each product and component in Horizon 7 Enterprise Edition is architected and designed specifically to meet these requirements. This includes virtual desktops and published applications (RDSH), applications delivered through VMware App Volumes™ AppStacks and writable volumes, profile data with VMware User Environment Manager™, secure external access through VMware Unified Access Gateway™ (formerly called Access Point), and a single-sign-on workspace with VMware Identity Manager™. The availability of each part is considered, as is the replication and recovery of any data portion required to ensure the service is available at the second site.



Note: In Table 1:

• A low RTO means that the service is recovered within a brief period, such as 30 to 60 seconds. A medium RTO target might be 45 to 60 minutes. These time periods can vary dramatically, depending on the components included in the recovery service.

• A low RPO means a brief time period during which data might be lost, such as 30 to 60 seconds. A medium RPO target might be 45 to 60 minutes. These time periods can vary dramatically, depending on the components included in the recovery service.

• Active/active recovery mode means that the service is available from multiple data centers without manual intervention.

• Active/passive recovery mode requires that the passive instance of the service be promoted to active status in the event of a service outage.

USE CASE AND OBJECTIVES

DESCRIPTION SOLUTION

Active/Active RTO = Low RPO = Low

• User requires the lowest possible recovery time for service (for example, health worker).

• Mobile user might roam from continent to continent.

• User needs to get served from nearest geographical data center per continent.

• Service consumed is available in both primary and secondary data centers without manual intervention.

Horizon 7 Enterprise Edition using Cloud Pod Architecture (CPA) and storage area network capable of multi-site replication

Active/Passive RTO = Medium RPO = Medium

• User normally works in a single office location.

• Service consumed is pinned to a single data center.

• Failover of the service to the second data center ensures business continuity.

Horizon 7 Enterprise Edition using CPA and storage area network capable of multi-site replication

Stretched Active/Passive RTO = Medium RPO = Medium

• Environment uses full-clone desktops and IT wants to implement disaster recovery.

• 1:1 relationship between a user and a desktop.


• Data centers are in a metro or campus network environment with low network latency between sites.

Horizon 7 Enterprise Edition using a single pod recovered in a second site using VMware vSAN™

Table 1: Use Case Overview

To validate the design, an environment was built out and tests were run to simulate a real environment and use cases. To provide replicating storage, we used all-flash arrays in the two use cases for sites in geographically dispersed locations.

Important: Although we used all-flash arrays, you can use any other type of array that is capable of replication and that would suit these use cases (where appropriate replication is available).

For the third use case, in which data centers are near each other, such as in a metro or campus network environment with low network latency between sites, a stretched VMware vSphere® cluster using VMware vSAN is used between the two data centers. This provides both the data replication required and the high availability to recover the server components, desktops, and RDS hosts.



The integration of components to provide the service is done in a modular fashion, allowing for choices to be made in how parts of the service are reproduced at the second site. It also allows for choices that balance which components need to be recovered in an outage with allowing the user to be functional as quickly as possible. This ultimately allows for the lowest possible RTO and RPO to be achieved for each use case.

Audience This paper describes how to address business requirements and use cases by integrating the various components of VMware Horizon 7 Enterprise Edition to build services. It begins by defining business requirements and drivers, which can be mapped to use cases that can be adapted to most scenarios.

This paper is intended to help organizations—IT architects, consultants, and administrators—involved in the early phases of planning, design, and deployment of Horizon 7 Enterprise Edition in two data centers for Business Continuity (BC) and Disaster Recovery (DR) purposes. It offers a standard, repeatable, and highly scalable approach to design and integration that can easily be adapted to specific environments and requirements.

The reader should understand desktop and application virtualization, including infrastructure elements such as vSphere, storage, networking, Active Directory, and load balancing. Some familiarity with View desktops in VMware Horizon 7, including capabilities and features introduced in Horizon 7 Enterprise Edition, is also helpful.

Design Methodology When building a Horizon 7 Enterprise Edition environment, it is important to follow proper design methodology. The first steps are to address business requirements, identify users’ needs and organize these into use cases, and then to align and map those use cases against a set of integrated services built on Horizon 7 Enterprise Edition.

Business Drivers and Use Case Definition

Services Definition

ServicesIntegrationDesign

UserExperienceDesign

ArchitecturalPrinciples andConcepts

EnvironmentInfrastructureDesign

Horizon 7EnterpriseEdition ComponentDesign

vSphere 6Design

1

2

3

4

5

6

7

8

Figure 2: Reference Architecture Design Methodology



A Horizon 7 Enterprise Edition design should use components that address the identified use cases. Before these components can be assembled and integrated to form a service, the underlying Horizon 7 and vSphere infrastructure must be designed, built, and, typically, unified into the existing infrastructure environment.

As suggested by Figure 2, this process is cyclical. All important decisions should be revisited to make sure that subsequent decisions have not affected them in unexpected ways.

JMP – Next-Generation Desktop and Application Delivery Platform JMP (pronounced jump), which stands for Just-in-Time Management Platform, represents capabilities in VMware Horizon 7 Enterprise Edition that deliver Just-in-Time Desktops and Apps in a flexible, fast, and personalized manner. JMP is composed of the following VMware technologies:

• VMware Instant Clone Technology for fast desktop and RDSH provisioning

• VMware App Volumes for real-time application delivery

• VMware User Environment Manager for contextual policy management

JMP allows components of a desktop or RDSH server to be decoupled and managed independently in a centralized manner, yet reconstituted on demand to deliver a personalized user workspace when needed. JMP is supported with both on-premises and cloud-based Horizon 7 deployments, providing a unified and consistent management platform regardless of your deployment topology. The JMP approach provides several key benefits, including simplified desktop and RDSH image management, faster delivery and maintenance of applications, and elimination of the need to manage “full persistent” desktops.



VMware Reference Architectures VMware reference architectures are designed and validated by VMware and supporting partners to address common use cases, such as enterprise desktop replacement, remote access, and disaster recovery.

VMware reference architectures offer customers:

• Standardized, validated, repeatable components

• Scalable designs that allow room for future growth

• Validated and tested designs that reduce implementation and operational risks

• Quick implementation, reduced costs, and minimized risk

This Horizon 7 Enterprise Edition Multi-Site Reference Architecture is intended to provide configuration information and example architecture for deploying Horizon 7 Enterprise Edition in a two-site configuration for primarily active/active workloads. One of the uses is to show how to build a resilient environment that can deliver disaster recovery of Horizon 7 workloads.

This reference architecture does not provide performance data or stress-testing metrics; however, it does provide data for all functional tests carried out to prove the architecture and the achieved RTO and RPO numbers.

For details of the in-scope and out-of-scope components of this paper see Appendix A: Scope.

For detailed information on how to design and configure the individual Horizon 7 Enterprise Edition components within a single site, refer to the VMware Horizon 7 Enterprise Edition Reference Architecture. Additional information can also be found in the product documentation as referenced throughout this paper and in Appendix C: Active/Passive Service Stretched with vSAN.

http://www.vmware.com/files/pdf/techpaper/vmware-horizon-7-enterprise-validated-integration-design-reference-architecture.pdf


T E C H N I C A L W H I T E PA P E R | 1 0


Business Drivers and Use Cases Definition There are many ways and reasons to implement a multi-site solution for a Horizon 7 Enterprise Edition environment. The most typical setup and requirement is for a two-data-center strategy. The aim is to provide disaster recovery, with the lowest possible RTO and RPO; that is, to keep the business running with the shortest possible time to recovery and with the minimum amount of disruption.

Meeting Business Requirements with Multi-Site Horizon 7 Deployments The overall business driver for disaster recovery is straightforward: to keep the business operating during an extended or catastrophic technology outage, providing continuity of service and allowing staff to carry out their day-to-day responsibilities.

With services, applications, and data delivered by Horizon 7, that means providing continuity of service and mitigating against component failure, all the way up to a complete data center outage.

With respect to business continuity and disaster recovery, this reference architecture addresses the following common key business drivers:

• Provide essential services, and access to applications and data delivered by Horizon 7, to users, even when an outage has occurred.

• Minimize interruptions during outages.

• Provide the same or similar user experience during outages.

• Cope with differing levels and types of outages and failures.

• Develop predictable and planned steps to recover functionality in the event of failures.

• Provide mobile secure access.

Table 2 describes the strategy used for responding to each of the business requirements from the preceding list.

BUSINESS DRIVER COMMENTS

Provide essential services, and access to applications and data delivered by Horizon 7, to users, even when an outage has occurred.Minimize interruptions during outages.

By designing an architecture where all intra-site components are deployed in pairs and all services are made highly available—with services able to be delivered from multiple sites, either in an active/active or active/passive manner—the highest service level possible is delivered, minimizing downtime in case of an outage.

Provide a familiar user experience during outages.

Replicating the parts that a user considers persistent (profile, user configuration, applications, and more) and reconstructing a desktop in the second data center using those parts, makes it possible to give users personalized environments.VMware Identity Manager provides a common entry point to all types of applications, regardless of which data center is actively being used.

Cope with differing levels and types of outages and failures.

This paper details a design for multi-site deployments to cope with catastrophic failures all the way up to a site outage. The Horizon 7 environment design ensures that there is no single point of failure within a site.



BUSINESS DRIVER COMMENTS

Develop predictable and planned steps to recover functionality in the event of failures.

Horizon 7 Enterprise Edition services are constructed from several components and designed in a modular fashion. A proper design methodology, as followed in this reference architecture, allows each component to be designed for availability, redundancy, and predictability. Any recoverability steps or processes for each component and the whole end-user service can then be planned and documented.

Provide mobile secure access. Desktop mobility is a core capability in the Horizon 7 platform. As end users move from device to device and across locations, the solution reconnects end users to the virtual desktop instances that they are already logged in to, even when they access the enterprise from a remote location through the firewall. VMware Unified Access Gateway virtual appliances provide secure external access without the need for a VPN.

Table 2: Meeting Business Requirements with Multi-Site Horizon 7 Deployments

Use Case Recovery Requirements Because this paper focuses on disaster recovery, the main emphasis falls on the availability and recoverability requirements of the differing types of users.

Designing a Horizon 7 environment includes building out the functional definitions for the use cases and their requirements. For a detailed description of this process, see VMware Horizon 7 Enterprise Edition Reference Architecture, which defines five typical use cases that are adaptable to cover most scenarios and then defines services to deliver the requirements of those use cases. This reference architecture examines the differing requirement types for disaster recovery and later, when defining the disaster recovery services, maps them to each of the Horizon 7 services.

This reference architecture caters to three common disaster recovery classifications, which can be adapted to cope with most scenarios in a disaster recovery–enabled Horizon 7 Enterprise Edition environment.

USE CASE AND OBJECTIVES

DESCRIPTION

Active/Active RTO = Low RPO = Low

• User requires the lowest possible recovery time for service (for example, health worker).

• Mobile user might roam from continent to continent.

• User needs to get served from nearest geographical data center per continent.

• Service consumed is available in both primary and secondary data centers without manual intervention.

Active/Passive RTO = Medium RPO = Medium

• User normally works in a single office location.

• Service consumed is pinned to a single data center.


Stretched Active/Passive RTO = Medium RPO = Medium

• Environment uses full-clone desktops, and IT wants to implement disaster recovery.

• 1:1 relationship between a user and a desktop.


• Data centers are in a metro or campus network environment with low network latency between sites.

Table 3: Disaster Recovery Classifications





The RTO is defined as the time it takes to recover a given service. RPO is the maximum period in which data might be lost.

Low targets are defined as 30- to 60-second estimates. Medium targets are estimated at 45–60 minutes. These targets depend on the environment and the components included in the recovery service.



Recovery Service Definitions Combining business requirements with a use case enables the definition of a service that can deliver an appropriate solution. In this reference architecture, the services defined focus on availability and recoverability. Services are defined by identifying and aligning the right mix of products, features, and technologies to address each use case. The detail required to build out the products and components comes later, after the services are defined and the components required are understood.

This paper maps Horizon 7 services from the VMware Horizon 7 Enterprise Edition Reference Architecture to a disaster recovery service. Some of these services could be mapped to a different disaster recovery service, depending on the exact mix of Horizon 7 components being used in it.

Recovery services are designed to operate in either an active/active or an active/passive mode and should be viewed from the users’ perspective.

• In active/active mode, the loss of a View pod or data center instance does not impact service availability for the user because the remaining instance or instances continue to operate independently and can offer the end service to the user.

• In active/passive mode, loss of an active View pod or data center instance requires that the passive instance of the service be promoted to active status for the user.

In the use cases, a user belongs to a home site and can have an alternative site available to them. Where user pinning is required, an active/passive approach results in a named user having a primary site they always connect to or get redirected to during normal operations.

The following functionality is used across the use cases.

REQUIREMENT COMPONENT

Single sign-on, SaaS applications VMware Identity Manager

Infrastructure platform VMware vSphere

Storage platform All-flash arrays, other types of storage that offer replication, or, for data centers with low latency between sites, VMware vSAN

Virtual desktops and RDSH-remoted apps VMware Horizon 7

Application deployment VMware App Volumes

User profile, IT settings, and configuration for environment and applications

VMware User Environment Manager

Table 4: Recovery Requirements

Active/Active Service Requirement: Service is available from multiple data centers without manual intervention.

Overview: Windows applications are delivered as natively installed applications in the Windows OS, and there is little to no reliance on the Windows profile in case of a disaster. User Environment Manager provides company-wide settings during a disaster. Optionally, applications can be delivered through App Volumes AppStacks, with core and department-specific applications included in various AppStacks.

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-7-enterprise-validated-integration-design-reference-architecture.pdf

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-7-enterprise-validated-integration-design-reference-architecture.pdf



This generally requires the lowest possible RTO, and the focus is to present the user with a desktop closest to his or her geographical location. For example, when traveling in Europe, the user gets a desktop from a European data center; when traveling in the Americas, the same user gets a desktop from a data center in the Americas.

Horizon 7 services accommodated: Mobile Secure Workspace Service. Table 5 details the recovery requirements and the corresponding Horizon 7 component that addresses each requirement.

REQUIREMENT PRODUCTS/SOLUTIONS/SETTINGS

Lowest possible RTO during a disaster No reliance on services that cannot be immediately failed over.

Windows desktop or RDSH available in both sites

• Horizon 7 desktop and application pools are created in both data centers.

• Master VM can be replicated to ease creation.

• Cloud Pod Architecture (CPA) is used to ease user entitlement and consumption.

Native applications Applications are installed natively in the base Windows OS. No replication is required because native apps exist in both data center pools.

Attached applications(optional)

Applications contained in App Volumes AppStacks are replicated using App Volumes storage groups.

IT settings User Environment Manager IT configuration is replicated to another data center. The following RTO and RPO targets apply during a data center outage when a recovery process is required:• RTO = 30–60 seconds

• RPO = 30–60 seconds

User data and configuration (optional)

User Environment Manager user data is replicated to another data center. The following RTO and RPO targets apply during a data center outage when a recovery process is required:• RTO = 30–60 seconds

• RPO = Approximately 2 hours

Mobile access Unified Access Gateway, Blast Extreme

Table 5: Active/Active Service Requirements



Active/Active Service Blueprint

At a high level, this service consists of a Windows environment delivered by a desktop or an RDS host available at both data centers. With this service, applications can be natively installed in the OS, attached using App Volumes AppStacks, or some combination of the two. If required, the user profile and user data files can be made available at both locations and can also be recovered in the event of a site outage.

Profile


Service

Windows OS

ActiveSit

e 1 Instant or

Linked CloneIT

Config

Master VM AppStacks (Optional)


Apps

UserSettings

HomeFile

Shares


Windows OS

Active

Replication

Sit

e 2

Failover


Client(s)

User

Active

Active

Service

Figure 3: Active/Active Service Blueprint



Active/Active App Volumes Blueprint

Although applications can be installed in the base OS, they can alternatively be delivered by App Volumes AppStacks. Applications are attached either to the desktop, at user login, or to the RDS host as it boots. Because AppStacks are read-only to users and are infrequently changed by IT, AppStacks can be replicated to the second, and subsequent, locations and are available for assignment and mounting in those locations as well.

AppVolumesManagers

Database


Service

Attached Apps ActiveSit

e 1

AppStacks SQL

Apps

AppVolumesManagers DatabaseApps


Service

Attached Apps

Active

Replication Entitlement Replication

Sit

e 2

Client(s)

User

Figure 4: Active/Active App Volumes Option Blueprint



Active/Active Profile Blueprint

The user profile and data can be included as an optional component of this service. Although profile data can be made available to both data centers, there is a failover process in the event of the loss of Site 1 that can impact the RTO and RPO.

Operational decisions can be made in these scenarios as to whether the service in Site 2 would be made available with reduced functionality (for example, available with the Windows base, the applications, and the IT configuration but without the user-specific settings).

File Server Shares


ActiveSit

e 1

Profile and Files

ConfigShare

Profile

File Server SharesProfile

UserShare

HomeShare


Active

Replication

Sit

e 2

Failover

Client(s)

UserAct

ive

Active

ITConfig

ITConfig

UserSettings

HomeFile

Shares

UserSettings

HomeFile

Shares

Profile and Files

Service

Service


Figure 5: Active/Active Profile Option Blueprint

Active/Passive Service Requirement: Service is run from a specific data center but can be failed over to a second data center in the event of an outage.

Overview: The core Windows desktop is an instant clone or linked clone, which is preferably kept to a vanilla Windows OS, allowing it to address a wide variety of users. The core could also be a desktop or session provided from an RDSH farm of linked clones or instant clones.

Although applications can be installed in the master image OS, the preferred method is to have applications delivered through App Volumes, with core and department-specific applications included in various AppStacks. Individual or conflicting applications are packaged with VMware ThinApp® and are available through the VMware Identity Manager catalog.

If the use case requires the ability for users to install applications themselves, App Volumes writable volumes can be assigned.

User Environment Manager applies the profile, IT settings, user configuration, and folder redirection.



Horizon 7 services accommodated: Business Process Application Service, Dedicated Power Workspace Service, High-Performance Workspace Service. Table 6 details the recovery requirements and the corresponding Horizon 7 component that addresses each requirement.

REQUIREMENT COMMENTS

Windows desktop or RDSH available in both sites

• Horizon 7 pools or farms are created in both data centers.

• Master VM can be replicated to ease creation.

• Cloud Pod Architecture (CPA) is used for user entitlement and to control consumption.

Native applications Applications are installed natively in the base Windows OS. No replication is required because native applications exist in both data center pools.

Attached applications (optional)

Applications contained in App Volumes AppStacks are replicated using App Volumes storage groups.

User-installed applications(optional)

App Volumes writable volumes.• RTO = 60–90 minutes

• RPO = 1–2 hours (array dependent)

IT settings User Environment Manager IT configuration is replicated to another data center.• RTO = 30–60 seconds

• RPO = Approximately 5 minutes

User data and configuration

User Environment Manager user data is replicated to another data center.• RTO = 30–60 seconds


SaaS applications VMware Identity Manager is used as a single-sign-on workspace and is present in both locations to ensure continuity of access.

Mobile access Unified Access Gateway, Blast Extreme

Table 6: Active/Passive Service Requirements



Active/Passive Service Blueprint

At a high level, this service consists of a Windows environment delivered by either an instant- or linked-clone desktop or RDS host, with identical pools created at both data centers. With this service, applications can be natively installed in the OS, provided by App Volumes AppStacks, or some combination of the two. User profile and user data files are made available at both locations and are also recovered in the event of a site outage.

Profile

User Apps


Service

Attached Apps

Windows OS

ActiveSit

e 1 Instant or


ITConfig

Master VM


Apps

UserSettings

HomeFile

Shares

User Apps


Standby Service

Attached Apps

Windows OS

Active

Replication

Sit

e 2

Failover


Client(s)

User

Figure 6: Active/Passive Service Blueprint



VMware Identity Manager/Workspace ONE Blueprint

Horizon 7 can optionally be integrated with Workspace ONE through VMware Identity Manager. It is not a required component in all the services defined in Table 6.

Database

Workspace ONE

Service

ActiveSit

e 1

VMware Identity Manager

Appliances

Profile

SQL AlwaysOn

Standby ServiceReplication

Sit

e 2

Failover

Client(s)

User

Workspace ONE

Apps

Apps

Failover


AppliancesDatabase

Figure 7: VMware Identity Manager/Workspace ONE Option Blueprint



Active/Passive App Volumes Blueprint

App Volumes AppStacks are used to attach applications to either the desktop or the RDS host. Because these AppStacks are read-only to users and are generally infrequently changed by IT, they are replicated to the second, and subsequent, locations and are available for assignment and mounting there as well.

If writable volumes are used for content such as user-installed applications, these writable volumes must be replicated and made available at the second site. Due to the nature of the content, writable volumes can have their content updated frequently by users. This can affect the RPO and RTO achievable for the overall service. Operational decisions can be made as to whether to activate the service in Site 2 with or without the writable volumes to potentially reduce the RTO.

AppVolumesManagers

Database

User Apps


Service


e 1

AppStacksWritableVolume SQL

Apps


User Apps


Standby Service

Attached Apps

Active


Sit

e 2

Failover

Client(s)

User

Figure 8: Active/Passive App Volumes Option Blueprint



Profile Blueprint

Operational decisions can be made in a recovery scenario as to whether the service in Site 2 would be made available with reduced functionality (for example, without some of the profile components).

File Server Shares


ActiveSit

e 1

Profile and Files

ConfigShare

Profile


UserShare

HomeShare


Active

Replication

Sit

e 2

Failover

Client(s)

User

Activ

e

Active

ITConfig

ITConfig

UserSettings

HomeFile

Shares

UserSettings

HomeFile

Shares

Profile and Files

Service

Service


Figure 9: Profile Option Blueprint



Multi-Site Architecture Principles This reference architecture documents and validates the deployment of all features of Horizon 7 Enterprise Edition across two data centers.

The architecture has the following primary tenets.

• Site redundancy – Eliminate any single point of failure that can cause an outage in the service.

• Data replication – Ensure that every layer of the stack is configured with built-in redundancy or high availability so that the failure of one component does not affect the overall availability of the desktop service.

To achieve site redundancy,

• Services built using Horizon 7 are available in two data centers that are capable of operating independently.

• Users are entitled to equivalent resources from both the primary and secondary data center.

• Some services are available from both data centers (active/active).

• Some services require failover steps to make the secondary data center the live service (active/passive).

To achieve data replication,

• Any component, application, or data required to deliver the service in the second data center is replicated to a secondary site.

• The service can be reconstructed using the replicated components.

• The type of replication depends on the type of components and data, and the service being delivered.

• The mode of the secondary copy being active or passive depends on the data replication and service type.

Horizon 7 Pod and Block One key concept in a VMware Horizon 7 environment design is the use of pods and blocks, which enables a repeatable and scalable approach. A View pod is made up of a group of interconnected Connection Servers running in the same LAN segment that broker desktops or published applications.

Important: A single View pod and the Connection Servers in it must be located within a single data center and cannot span locations. Multiple View pods and locations must be interconnected using Cloud Pod Architecture (CPA).



Architectural Approaches Besides the principles outlined in this section, this paper also adheres to some architectural guidelines that address the recoverability targets defined in Recovery Service Definitions.

Active/Active Architecture

Active/active architecture uses two or more View pods, with at least one pod located in each data center. The pods are joined using Cloud Pod Architecture, which is configured with global entitlements that allow named users to access either site at any given point in time.

CPA

Pod 1

Connection Servers

Pod 2

Connection Servers

Site 2Site 1

Figure 10: Active/Active Architecture

Active/Passive Architecture

Active/passive architecture uses two or more View pods with at least one located in each data center. They are joined together using Cloud Pod Architecture configured with global entitlements. This strategy effectively aligns a named user to a given data center. Essentially, this is the same architecture as active/active, with the difference being how the global entitlement and user home sites are configured.

CPA

Pod 1

Connection Servers

Pod 2

Connection Servers

Site 2Site 1

Figure 11: Active/Passive Architecture



Stretched Active/Active Architecture (Unsupported)

This architecture is unsupported and is only shown here to stress why it is not supported. Connection Servers within a given site must always run on a well-connected LAN segment and therefore cannot be running actively in multiple geographical locations at the same time.

vSphere HA

Pod 1

Connection Servers

Pod 2

Connection Servers

Site 2Site 1

Figure 12: Stretched Active/Active Architecture

General Multi-Site Best Practices There are numerous ways to implement a disaster recovery architecture, but some items can be considered general best practices.

Components That Must Always Run with a Primary Instance

Even with an active/active usage model across two data centers, one of the data centers holds certain roles that are not multi-master defined. The following components must run with a primary instance in a given site:

• User profile and data shares containing User Environment Manager user data

• Active Directory FSMO roles (specifically, PDC Emulator, because it is required to make changes to domain-based DFS namespaces)

• Microsoft SQL Server Always On availability groups (if used)

• VMware Identity Manager

Steps should be taken to secure those resources that are not multi-master by nature or that cannot be failed over automatically. Procedures must be put in place to cover what needs to happen to recover them.

For this reference architecture design, we chose to place the primary availability group member in Site 1 as well as all AD FSMO roles on a domain controller in Site 1. We made this choice because we had a good understanding of the failover steps required if either Site 1 or Site 2 failed.

Component Replication and Roaming Users

Use Horizon 7 components to create effective replication strategies and address the needs of users who roam between sites:

• Create a disaster plan up front that defines what a disaster means in your organization. The plan should specify if a 1:1 mapping in terms of resources is required, or what portion of the workforce is required to keep the organization operational.

• Replicate desktop and server (RDSH) master image templates between sites to avoid having to build the same templates on both sites. You can use a vSphere Content Library or perform a manual replication of the resources needed across the whole implementation.



• Use Cloud Pod Architecture (CPA) and avoid metro-cluster with vSAN stretched cluster unless you have a persistent desktop model in the organization that cannot easily be transformed into a nonpersistent use case.

• With regard to initial user placement, even with a roaming use case, a given user must be related to user profile data (User Environment Manager user data), meaning that a relationship must be established between a user account and a data center. This also holds true when planning how users in the same part of the organization (such as sales) should be split between sites to avoid an entire function of the company being unable to work should a disaster strike.

• For a roaming use case, where User Environment Manager is used to control the user profile data, VMware recommends that FlexEngine be used whenever possible in combination with folder redirection. This keeps the core profile to a minimum size and optimizes login times in the case where a profile is loaded across the link between the two data centers.

• Use Microsoft SQL Server failover cluster instances and Always On availability groups for VMware Identity Manager where possible. This is not required for VMware vCenter Server®, the Connection Server event database, and vCenter Server Update Manager. We used Microsoft SQL Server 2014, but Microsoft SQL Server 2016 is also supported.



Logical Architecture Figure 13 illustrates at a high level a logical architecture that contains all the major components. This architecture is designed to meet the business requirements as defined under Business Drivers and Requirements.

SQL Servers

https://identity.company.comhttps://horizon.company.com

Site 1 Site 2Global Load Balancer

Local Load Balancer

VMware Identity Manager AG Listener

SQL Always On(Asynchronous)

SQL FCI #1(Primary)

SQL FCI #2(Secondary)

Composer

SQL

SQL SQL SQL SQL

SQL


Connectors

VMware Identity Managers

Connection Servers

App Volumes Mangers

Horizon Events

AG Listener

Horizon Events

AG Listener

ComposerAG Listener

ComposerAG Listener

App VolumesAG Listener


SQL Always On(Synchronous)


Site 1 – ManagementvCenter Server

Site 1 – VDI vCenterServer


Site 2 –VDI vCenterServer

AppStack Entitlement Replication

Volume for SMB Share

Site 1 - Storage Array Site 2 - Storage Array Storage Replication


SQL Servers

Active DirectoryServices


App Volumes Mangers

SQL Servers

iSCSI

SQL Servers

RDM iSCSIRDM

Local Load Balancer

Local Load Balancer

DMZDMZ

Unified Access Gateways

Local Load Balancer

Composer


Connectors


Connection Servers


Figure 13: Logical Architecture



In this diagram, only the global virtual IPs (VIPs) and names at the very top would be used for user access. These are horizon.company.com and identity.company.com. Global namespaces make it easier to handle user redirection during outages because they give access to either site through the same URL.

The site-specific VIPs (vidm-a.company.com, hzn-a, vidm-b, and so on) are the local load-balanced names for each of the different server components. End users would never enter these URLs. Administrators would use these URLs only when configuring targets for the global VIPs.



Horizon 7 Component Design with a Disaster Recovery Focus To be able to deliver the Horizon 7 Enterprise Edition services outlined and to address the requirements and goals, it is necessary to design and build out the infrastructure components required for the two data centers.

This section covers a high-level design of each of the products or areas that need to be considered. It is not meant to be an exhaustive configuration or installation guide, for which the reader should consult the product documentation cited under References. This document does aim to give detail where general product documentation presents multiple options and the recommendation needs to be clearly stated. It also gives best-practice recommendations for deploying these components across two data centers.

For this reference architecture design, certain design choices were made for the shared infrastructure components that are relied upon between sites. For the Microsoft SQL Server Always On primary node placement,

• Site 1 is the primary site.

• The primary database instance runs in Site 1.

• When services that rely on SQL Server Always On availability groups (VMware Identity Manager, in this case) are running in Site 2, they incur some cross-site traffic when performing read and write operations.

VMware Identity Manager does not implement any read-only intent features from SQL Server Always On.

VMware Identity Manager VMware Identity Manager is the primary entry point for end users to consume Horizon 7 virtual desktops and all types of applications, including SaaS, web, Horizon 7 published applications, Citrix XenApp, and mobile apps. Therefore, we deploy it to be highly available within a site, and we deploy VMware Identity Manager in a secondary data center for failover and redundancy. The failover process that makes the secondary site’s VMware Identity Manager appliances active requires a change at the global load balancer to direct traffic of the namespace to the desired instance. You must also clear the caches on the original primary data center, as described in the topic Failover to Secondary Data Center, in Installing and Configuring VMware Identity Manager.

VMware Identity Manger consists of the following layers, which make up the service and need to be designed for redundancy:

• VMware Identity Manger appliances and connectors

• Database

• Unified app catalog that can contain SaaS, web, Horizon 7 published applications, Horizon 7 virtual desktops, Citrix XenApp, and mobile apps

VMware Identity Manager Appliances and Connectors

To provide site resilience, each site requires its own group of VMware Identity Manager virtual appliances to allow the site to operate independently, without reliance on another site. One site runs as the active VMware Identity Manager, while the second site has a passive group. The determination of which site has the active VMware Identity Manager is usually controlled by the global load balancer’s namespace entry or a DNS entry, which sets a given instance as the target for the namespace in use by users.

Within each site, VMware Identity Manager must be installed with a minimum of three appliances. This provides local redundancy and ensures that services such as Elasticsearch function properly. The VMware Identity Manager appliances are hosted in the DMZ network. For more information, see Deploying VMware Identity Manager in the DMZ.

https://docs.vmware.com/en/VMware-Identity-Manager/


https://docs.vmware.com/en/VMware-Identity-Manager/2.9.1/com.vmware.vidm-dmz-deployment/GUID-8E453C0D-3E4C-403D-9CA5-CB30A08B4706.html



A local load balancer distributes the load between the local VMware Identity Manager instances, and a failure of individual appliances is handled with no outage to the service. Each local site load balancer is also load-balanced with a global load balancer.

At each site, two VMware Identity Manager Connector virtual appliances are hosted in the internal network and can use an outbound-only connection mode. These connectors point to the global load balancer.

Database

VMware Identity Manager 2.9 (and later) supports Microsoft SQL Server 2014 (and later) and its cluster offering Always On availability groups. This allows us to deploy multiple instances of VMware Identity Manager, pointing to the same database protected by an availability group with an availability group listener as the single Java Database Connectivity (JDBC) target for all instances.

VMware Identity Manager is supported with an active/passive database instance with failover to the secondary site if the primary site is unavailable. Depending on the configuration of SQL Server Always On, inter-site failover of the database can be automatic, though not instantaneous.

For this design, an Always On implementation with the following specifications was chosen:

• No shared disks are used.

• The primary database instance is running in Site 1 during normal production.

Within a site, Windows Server Failover Clustering (WSFC) is used to improve local database availability and redundancy. In a WSFC cluster, two Windows servers are clustered together to run one instance of SQL Server, which is called a SQL Server failover cluster instance (FCI). Failover of the SQL Server services between these two Windows servers is automatic.



This architecture is depicted in Figure 14.

Local Load Balancer

VM

war

e Id

enti

ty M

anag

er

Gro

up 1

Win

do

ws

Fai

love

rC

lust

er 1

PrimarySQL ServerDatabase

WindowsServer 1

Site 1

VM

war

e Id

enti

ty M

anag

er

Gro

up 2

Win

do

ws

Fai

love

rC

lust

er 2

Local Load Balancer

Site 2

SecondarySQL ServerDatabase

Standby ConnectionActive Connection


SQL ServerAlways On Listener

Global Load Balancer

VMwareIdentityManagerNode 1






WindowsServer 2

WindowsServer 1

WindowsServer 2

Figure 14: VMware Identity Manager Architecture

For this design, VMware Identity Manager was configured as follows:

• It uses an active-hot standby deployment.

• VMware Identity Manager nodes in Site 1 form an Elasticsearch cluster and an Ehcache cluster. Nodes from Site 2 form a separate Elasticsearch cluster and Ehcache cluster. Elasticsearch and Ehcache are embedded in the VMware Identity Manager virtual appliance. Elasticsearch is a search and analytics engine used for auditing, reports, and directory sync logs. Ehcache provides caching capabilities.

– Only the active site can service user requests.

– An active VMware Identity Manager group exists in the same site as the primary replica for the Always On access group.

• The design uses a single identity provider with nodes from both sites.

Important: To implement this strategy, you must perform all the tasks described in the section Setting Up a Secondary Data Center, in Installing and Configuring VMware Identity Manager.

Note: All JDBC connection strings for VMware Identity Manager appliances should point to the SQL Server availability group listener (AGL) and not directly to an individual SQL Server node. For detailed instructions about deploying and configuring the VMware Identity Manager, creating SQL Server failover cluster instances, creating an Always On availability group, and configuring VMware Identity Manager appliances to point to the AGL, see Appendix G: Setting Up VMware Identity Manager for High Availability in Multiple Sites.




If your organization has already deployed Always On availability groups, consult with your database administrator (DBA) about the requirements for the database used with VMware Identity Manager.

The SQL Server Always On setup can be configured to automatically fail over and promote the remaining site’s database to become the primary.

For detailed guidance on how to configure F5 with VMware Identity Manager, please refer to Appendix E: F5 Load Balancing Configuration.

Horizon 7 with Cloud Pod Architecture A key component in this reference architecture, and what makes Horizon 7 Enterprise Edition truly scalable and able to be deployed across multiple locations, is Cloud Pod Architecture (CPA).

CPA introduces the concept of a global entitlement (GE) through joining multiple View pods together into a federation. This feature allows us to entitle users and groups to a global entitlement that can contain desktop pools or RDSH-published applications from multiple different View pods that are members of this federation construct.

This feature provides a solution for many different use cases, even though they might have different requirements in terms of accessing the desktop resource.

Figure 15 is a logical overview of a basic two-site CPA implementation, as deployed in this reference architecture design.

For the full documentation on how to set up and configure CPA, refer to Administering View Cloud Pod Architecture.

Inter-PodCommunication

Local ADLDS and JMS

Global ADLDS

Local ADLDS and JMS

Global ADLDS

Site 1 Site 2

Figure 15: Cloud Pod Architecture

Important: This type of deployment is not a stretched deployment; each pod is distinct, and all Connection Servers belonging to each of the individual pods are required to reside in a single location and run on the same broadcast domain from a network perspective.

As well as being able to have desktop pool members from different pods in a global entitlement, this architecture also allows for a property called scope. Scope allows us to define where new sessions should or could be placed and also allows users to connect to existing sessions (disconnected state) when contacting any of the pod members in the federation.

https://www.vmware.com/support/pubs/view_pubs.html




For this reference architecture, the following global entitlements were used.

GE SETTING VALUE

Name Roaming

Scope All Sites (ANY)

Entitlements VMWEUC\All_Sales_People

Use home site Disabled

Table 7: Global Entitlement Settings for Roaming User Use Case

The above configuration allows anyone connecting to the federation through the global namespace, https://horizon.vmweuc.com for this environment, to get a desktop no matter which pod they get connected to.

This fits with our requirements because our global load balancer (F5 BIG-IP DNS/GTM) is configured to point the user to an available pod closest to their current geographical location.

If a member of the group VMWEUC\All_Sales_People is closest to Site 1, a session is brokered with the pod in Site 1. The same logic applies if that same member is closest to Site 2.

GE SETTING VALUE

Name PowerUser

Scope Within Site

Entitlements VMWEUC\Site1-PowerUsers VMWEUC\Site2-PowerUsers

Use home site Enabled

Entitled user must have home site Enabled

Table 8: Global Entitlement Settings for Power User Use Case

The above global entitlement configuration splits a group of users, PowerUsers, into two groups. This allows for initial user placement by making sure all the members of PowerUsers are not working from the same data center.

The configuration above also enables and forces the presence of a home site for the entitled groups in conjunction with defining the scope to be Within Site. This effectively means that the two groups are associated with a home site that dictates their preferred placement.

The home site configuration for the above two groups looks like the following:

GROUP DOMAIN SITE

Site1-PowerUsers VMWEUC Site 1


Table 9: Initial Placement in Different Data Centers



With this configuration, and under normal operating conditions,

• A member of Site1-PowerUsers is always given a desktop resource in Site 1.

• A member in Site2-PowerUsers always gets a desktop resource in Site 2.

Home Site Override – Preparing for Failover

The configuration shown in the preceding section is suitable when both sites are online and fully operational. But using just this global entitlement would cause issues because, in the event of either of the sites being unavailable, part of the user base would not be able to log in.

Additional configuration is required to reverse the logic so that users associated with a site that is currently offline can be temporarily allowed to connect and log in to another site.

For a given global entitlement, it is possible to configure a home site override option that does exactly this.

NAME DOMAIN SITE



Table 10: Override Configurations to Use During an Outage

Notice how this effectively overrides the home site configuration for those groups at the global entitlement level to reverse the logic, allowing members from group Site1-PowerUsers to connect to Site 2 and members from group Site2-PowerUsers to connect to Site 1.

Note: This change should only be made for the group impacted by a data center outage. At no point in time would both the override options be configured as depicted in the table above; the override should be configured only for the group impacted.

The home site override configuration should only be changed after a failed site’s resources have been fully failed over. The reverse-logic configuration is of no use if users access the site before their resources are available.

Unified Access GatewayUnified Access Gateway (formerly known as Access Point) appliances provide secure edge services for users accessing the environment from outside the corporate network. A Unified Access Gateway appliance can be used in front of Connection Servers to provide access to on-premises Horizon 7 desktops and published applications. This document describes the multi-site considerations and does not cover the design implications of network placement of components.

There is no difference in the deployment method when deploying Unified Access Gateway to be used in a multi-data-center setup. Unified Access Gateway in itself is only aware of the data center context it is running in, and the global load balancer is the component that directs users to a site that is available to serve user requests.



Figure 16 shows the logical deployment model for each site.

VMware vSphere

Internet

Horizon 7 Desktopsand RDS Hosts

DMZ

HorizonClients

CS

CS

VMwareIdentityManager

UnifiedAccess

Gateway

Figure 16: Unified Access Gateway Topology

For this reference architecture, Unified Access Gateway virtual appliances were deployed in each of the sites in front of the Connection Servers to avoid any single point of failure.

Each Unified Access Gateway is deployed with a dual NIC configuration, with the northbound connection placed in the DMZ and the southbound connection being the back-end network that in this case is also used for management purposes. Other deployment options are available for Unified Access Gateway, including single NIC.

The Unified Access Gateway pair for Connection Servers sits behind the F5 BIG-IP Local Traffic Manager (LTM) module that points user requests to an available Unified Access Gateway. Only the initial handshake over TLS is load balanced, but the actual client connection (Blast Extreme or PCoIP) is directed to the Unified Access Gateway the user gets connected to.

Affinity is based on source IP address and is configured only on the LTM layer because the Global Traffic Manager (GTM) flow checks only whether the LTM module of a given site is available or not. No affinity or session management occurs at the GTM layer; it is simply doing the initial placement based on geo-location of the user for external access. For internal access, the user is directed to one of the sites based on their client subnet value as defined by the VLAN (port group) associated with the desktop pool.

This allows for the control of the traffic flow for on-premises users because they are in known internal subnets and can be directed accordingly. For example, if GTM sees a connection associated with a subnet in Site 1, it directs the requests to Site 1 unless that site’s LTM instance is not responding to requests.

For a full reference on how F5 BIG-IP DNS (GTM) was used in this reference architecture, refer to Appendix E: F5 Load Balancing Configuration.



App Volumes App Volumes Manager 2.12.1 is used in this reference architecture to deploy applications to the desktops and RDS hosts.

VMware App Volumes delivers applications that are not in the master image for VDI and RDSH. App Volumes groups applications into AppStacks (virtual disks) based on the requirements of each use case. The AppStacks can then be assigned to a user, group, OU, or machine (RDSH).

For VDI use cases, AppStacks can be mounted either on demand or at login. With RDSH use cases, AppStacks are assigned to the machine account so AppStacks are mounted only when the App Volumes service starts.

App Volumes can also provide user-writable volumes for use with VDI desktops. Writable volumes provide a mechanism to capture user-installed applications that are not, or cannot be, delivered by AppStacks. This reduces the likelihood that persistent desktops would be required for a use case. The user-installed applications follow the user as they connect from one session to another.

There are two deployment options for the App Volumes database across multiple sites.

• Separate databases – This option uses a separate SQL Server database at each site. The App Volumes Managers at each site point to the local database instance and have only machine managers registered for vCenter Servers from their own site. Windows Server Failover Clustering (WSFC) and SQL Server Always On availability groups can be used within a site to provide local high availability.

• Clustered database – This option uses an Always On availability group to stretch the database instance across two sites. The App Volumes Managers at both sites point to the availability group listener rather than an SQL Server node or a clustered instance. The App Volumes Managers at both sites also have machine managers for vCenter Servers from both Site 1 and Site 2, including mapping their corresponding datastores. Local site availability of the database can be achieved by using an SQL Server failover cluster instance (FCI), which is installed on a WSFC cluster.

The separate-databases approach is much simpler to implement than setting up a clustered database for both sites. It also allows for easy scaling if you have more than two sites. Additionally, if the latency between App Volumes Manager and SQL Server is higher than 15 ms, VMware recommends that you use separate databases. The disadvantage is that user-based entitlement to AppStacks must be replicated in both sites. This process can be automated, as described in Appendix F: PowerShell Script for Replicating App Volumes Application Entitlements.

With both strategies,

• At least two App Volumes Managers are used in each site for local redundancy and scalability.

• Storage groups are used to replicate AppStacks.

• Replication across sites is achieved when one of the datastores is a member of storage groups from each of the sites and is visible to at least one vSphere host from each site.

• These common datastores are used as swing targets for cross-site replication and are marked as non-attachable.



App Volumes with Separate Database Instances

For this reference architecture, the decision was made to use separate database instances rather than using a clustered database across sites. With this option, you can still use Always On availability groups, but each site would have its own availability group to achieve automatic failover within a site. To make user-based entitlements for AppStacks available between sites, you can either manually reproduce the entitlements at each site or use a PowerShell script, which VMware provides.

Datastore 5Datastore 4

Storage Group #2

Datastore 3

SQLDatabase

SQLDatabase


Non-AttachableStorage Group #1

vSphere Hosts

vSphere Hosts

Site 2Site 1

App Volumes Managers App Volumes Managers

Figure 17: App Volumes Multi-Site Separate-Databases Option

With this option,

• Separate instances of App Volumes are deployed in each site.

• A separate database is used for each site; that is, you have a separate WSFC cluster and an SQL Server Always On availability group listener for each site.

• A local load balancer in each site is generally used to provide a local namespace for the site’s App Volumes instance.

• Operational procedures must be put in place for reproducing user entitlements in the other site. VMware provides a PowerShell script that replicates entitlements. See Appendix F: PowerShell Script for Replicating App Volumes Application Entitlements.



Configuration with Separate Databases

When installing and configuring the App Volumes Managers in a setup like this, each site uses a standard SQL Server installation.

1. Install the first App Volumes Manager in Site 1. If using Always On availability groups to provide a local highly available database, use the local availability group listener for Site 1 when configuring the ODBC connection.

Important: For step-by-step instructions on this process, see Appendix H: Setting Up VMware App Volumes for High Availability in Multiple Sites.

2. Complete the App Volumes Manager wizard and add the vCenter Servers for Site 1 as machine managers, including mapping their corresponding datastores.

3. Continue with installing the subsequent App Volumes Managers for Site 1. Add them as targets to the local load balancer virtual IP.

4. Repeat steps 1–3 for Site 2 so that the App Volumes Managers in Site 2 point to the local availability group listener for Site 2, and register the local vCenter Servers for Site 2 as machine managers.

5. For details on setting up storage groups for replicating AppStacks from site to site, see Active/Active Applications Delivered Just in Time by App Volumes.

6. Configure and run the PowerShell script for replicating AppStack entitlements between the sites, as described in Appendix F: PowerShell Script for Replicating App Volumes Application Entitlements.

With this design, the following is achieved:

• Each site has its own namespace for the local App Volumes Managers. This is generally a local load balancer virtual IP that targets the individual managers. App Volumes Agents must be configured to use the appropriate local namespace.

• AppStacks are made available in both sites.

• AppStacks are replicated from site to site through storage groups defined in App Volumes Manager and through the use of a common datastore that is configured as non-attachable.

• User-based entitlements for AppStacks are replicated between sites.

• A writable volume is normally active in one site for a given user.

• Writable volumes can be replicated from site to site using processes such as array-based replication. An import operation might be required on the opposite site. The order and details for these steps are outlined in Active/Passive Horizon 7 Service Failover Test/Recovery Plan.

• Entitlements for writable volumes are available between sites.

Failover with Separate Databases

In this model, each site works independently, with its own set of App Volumes Managers and its own database instance. During an outage, the remaining site can provide access to AppStacks with no intervention required.

• The AppStacks have previously been copied between sites using non-attachable datastores that are members of both sites’ storage groups.

• The entitlements to the AppStacks have previously been reproduced, either manually or through an automated process.



In use cases where writable volumes are being used, there are a few additional steps:

1. Mount the replicated datastore that contains the writable volumes.

2. Perform a rescan of that datastore. If the datastore was the default writable volume location, App Volumes Manager automatically picks up the user entitlements after the old assignment information has been cleaned up.

3. (Optional) If the datastore is not the default writable volume location, perform an Import Writables operation from the App Volumes Manager at Site 2.

For detailed information on the steps required and the order in which they need to be executed, refer to Appendix D: Test Plan.

App Volumes with a Clustered Database

This option uses an SQL Server Always On availability group listener that is common across both sites. One site is the primary instance and the second site the secondary. Database failover is needed if the primary instance fails, and failover can be automatic.

vSphere Hosts


Storage Group #2

Datastore 3

ClusteredSQL

Database

vSphere Hosts



Site 2

Storage Group #1

Site 1

Non-Attachable

P S

Figure 18: App Volumes Multi-Site Clustered Database Option

If you choose this option, it means using an Always On availability group with an availability group listener to which all App Volumes Manager instances are pointed for their database (ODBC) configuration. This setup is similar to the VMware Identity Manager configuration, except that the App Volumes Managers from both sites can be active at the same time.



The use of an Always On availability group effectively shares the configuration between all App Volumes Manager instances, resulting in user-based entitlements being available across sites as well as the two vCenter Server instances being configured in the same context.

Each site has a local load balancer that provides a local namespace for the site’s App Volumes instance. This is consumed by a global load balancer, which provides a global namespace that is common across both sites.

Configuration with a Clustered Database

When installing and configuring the App Volumes Managers in a setup like this, it is recommended to perform the following tasks in the specified order:

1. Install the first App Volumes Manager in the primary site where the primary SQL Server failover cluster instance (FCI) is running using the availability group listener when configuring the ODBC connection.

2. Complete the App Volumes Manager wizard and add vCenter Servers from both Site 1 and Site 2 as machine managers, including mapping their corresponding datastores.

3. Continue with installing the subsequent managers in the same site as the first manager.

4. Repeat steps 1–3 for Site 2 so that the App Volumes Managers in Site 2 point to the availability group listener.

5. For details on setting up storage groups for replicating AppStacks from site to site, see Active/Active Applications Delivered Just in Time by App Volumes.

For details on configuration of a clustered database for App Volumes, see Appendix I: Configuration Procedures for a Clustered App Volumes Database.

With this design, the following is achieved:

• Global load balancing directs the App Volumes Agent (and therefore, the user) to the corresponding App Volumes Manager used with the user’s associated site. This allows for the configuration of the App Volumes Agent with the same namespace across master images.

• AppStacks are made available in both sites.

• The AppStacks are replicated from site to site through storage groups defined in App Volumes Manager, and through the use of a common datastore that is configured as non-attachable.

• User-based entitlements for AppStacks are readily available between sites.

• A writable volume is only active in one site for a given user.

• Writable volumes can be replicated from site to site using processes such as array-based replication. During an outage, you must perform a restore operation to mount the datastore that contains the replicated writable volumes. You must then use App Volumes Manager to rescan the datastore.

• Entitlements for writable volumes are available between sites.

Failover with a Clustered Database

When performing a failover, the App Volumes Manager marks the vCenter Server in the site that has failed as being offline. Full functionality can still be achieved in the failover site.

• The configuration is shared through the Always On availability group for the database.

• The AppStacks have previously been copied between sites using non-attachable datastores that are members of both sites’ storage groups.



The only operation required during a site outage—and then, only if it is Site 1 that fails—is manually forcing the SQL Server Always On availability group to promote the secondary SQL Server FCI to become the primary. For instructions, see Perform a Forced Manual Failover of an Availability Group (SQL Server).

In use cases where writable volumes are being used, there are a few additional steps:

1. Mount the replicated datastore that contains the writable volumes.

2. Perform a rescan of that datastore. If the datastore was the default writable volume location, App Volumes Manager automatically picks up the user entitlements after the old assignment information has been cleaned up.

3. (Optional) If the datastore is not the default writable volume location, perform an Import Writables operation from the App Volumes Manager at Site 2.

For detailed information on the steps required and the order in which they need to be executed, refer to Appendix D: Test Plan.

User Environment Manager VMware User Environment Manager provides profile-like management by capturing user settings for the operating system and applications. User Environment Manager leverages file shares to store this configuration and data, so it relies on that underlying infrastructure to be highly available.

User Environment Manager data consists of the following types. This data is typically stored on separate shares and can be treated differently for availability:

• IT configuration data – IT-defined settings that give predefined configuration for the user environment or applications

• User settings and configuration data – The individual end user’s customization or configuration settings

It is possible to have multiple sets of shares to divide the user population into groupings. This can provide separation, distribute load, and give more options for recovery. By creating multiple User Environment Manager configuration shares, you create multiple environments. You can use a central installation of the Management Console to switch between these environments and export and import settings between environments. You can also use User Environment Manager group policies to target policy settings to specific groups of users, such as users within a particular Active Directory OU.

To meet the requirements of having User Environment Manager IT configuration data and user settings data available across the two sites, this design uses Distributed File System Namespace (DFS-N) for mapping the file shares.

Although we used DFS-N, you are not required to use DFS-N. Many different types of storage replication and common namespaces can be used. The same design rules apply.

https://technet.microsoft.com/en-us/library/ff877957(v=sql.120).aspx




IT Configuration Share

For IT configuration file shares, DFS-Namespace (DFS-N) is fully supported.

Note: The configuration share should allow users only to read and not to write or make any changes. Only administrators should be able to make changes to the content of the share.

User Environment Manager

Config Share(America)


Config Share(EMEA)

User Environment Manager Config Share (Master)


ManagementConsole


Config Share(APAC)

Figure 19: Supported DFS Topology for User Environment Manager IT Configuration Share

User Settings Shares

For user settings file shares, DFS-Namespace is fully supported.


Profile ShareFileserver 1

Laptops



RDSH or VDI

SyncTool

Desktops

DFS-Namespace

Figure 20: Supported DFS Topology for User Environment Manager User Settings Share



Switching to another file server in the event of an outage requires a few simple manual steps:

1. Manually disable the active DFS-N folder target.

2. Enable the passive DFS-N folder target.

3. Remove the read-only option on the target.


Profile Share Fileserver 1

Laptops



RDSH or VDI

SyncTool

Desktops

DFS-Namespace

Figure 21: Supported DFS Topology for the User Environment Manager User Settings Share (Failover State)

The management console can be installed on as many computers as desired. If the management console is not available after a disaster, you can install the management console on a new management server or on an administrator’s workstation, and point that installation to the User Environment Manager configuration share.



vSphere Infrastructure Design for Active/Active and Active/Passive ServicesStandard VMware vSphere design and installation should be followed to create a compute and storage platform to run Horizon 7 resources. This section describes the design used for a Horizon 7 multi-site deployment. For a vSAN stretched cluster, within a metro or campus network environment with low network latency between sites, see vSphere Infrastructure Design Using vSAN.

The active/active and the active/passive services for a multi-site setup are based on separate sets of vSphere clusters in each site. The storage used was all-flash arrays. Horizon 7 Cloud Pod Architecture was used to give global entitlements across both sites. Details in this section are specific to the environments put in place to validate the designs in this paper. Different choices in some of the configurations, hardware, and components are to be expected.

The vSphere infrastructure is deployed identically in both data centers, following VMware best practices for pod and block design concepts. For further details, see the VMware Horizon 7 Enterprise Edition Reference Architecture document.

View Pod and Block Horizon 7 design is based around the use of pods and blocks, which allow for a repeatable and scalable approach to building systems.

A View pod is a logical entity that can support up to 10,000 users or sessions. A pod contains a management block and one or more resource blocks for hosting desktops or RDS hosts.

The management block contains all the vSphere and Horizon 7 server virtual machines. One vCenter Server instance is deployed for managing the management cluster infrastructure, and there is also a dedicated vCenter Server for each resource block.

A resource block can host up to 2,000 virtual desktops or RDSH server VMs. (Although each vCenter Server can support up to 4,000 virtual desktops, keeping the number to 2,000 improves operation times.)





In the validation of this design, two data centers were built. Each site had two vSphere clusters, one for management VMs forming the management block and one for desktop and RDSH VMs that reside in the first resource block.

Management Block

3 x Dell R720 2 x Intel Xeon E5-2697 v2 24 C @ 2.7 GHz 256 GB RAM

Datastores:- Management

1 x vCenter Server(Management)

1 x vCenter Server (Desktop)

2 x Connection Servers

1 x Composer

2 x SQL

2 x App Volumes Managers

2 x Unified Access Gateways

3 x VMware Identity Manager

2 x Domain Controller

2 x Load Balancers

vCenter ServerManagement

Desktop Block

3 x Dell R720 2 x Intel Xeon E5-2697 v2 24 C @ 2.7 GHz 256 GB RAM

Datastores:- Linked Clones- Instant Clones- RDSH Servers- AppStacks- Writable Volumes

Windows 10 Linked Clones

Windows 10 Full Clones

Windows 2012 R2RDSH Servers

Windows 10Instant Clones

vCenter ServerDesktops

Figure 22: Horizon 7 Blocks



Networking All network components should be configured redundantly, either as active/passive or as active/active where possible. This design used 10-GbE adapters to simplify networking infrastructure and to avoid other 1-GB drawbacks such as inadequate bandwidth and lower utilization.

10 Gb Switches

10 Gb10 Gb

vmk0 vmk1 vmk2 vmk3

VirtualMachines

ESXiManagement

NetworkvMotion iSCSI 1 iSCSI 2

vSphere Distributed Switch

Figure 23: vSphere Networking

A single vSphere distributed switch was created with two 10-Gb interfaces in a team. Five port groups isolate network traffic:

• Virtual machines

• VMware ESXi™ management network

• VMware vSphere vMotion®

• iSCSI 1 and iSCSI 2

Note: Two iSCSI port groups are required in order to configure vmknic-based iSCSI multi-pathing.

Quality of Service is enforced with network I/O control (NIOC) on the distributed virtual switch, guaranteeing a share of bandwidth to each type of traffic. A vmkernel interface (vmknic) is created on the ESXi management port group, vSphere vMotion port group, and on each iSCSI port group.

Both 10-Gb adapters are configured as active/active for the VM port group, ESXi management network port group, and the vSphere vMotion port group.

• The iSCSI 1 port group is bound to a single 10-Gb adapter, with only storage traffic permitted on that adapter.

• The iSCSI 2 port group is bound to the second 10-Gb network adapter, with only storage traffic permitted over that adapter.



Storage When designing storage for a Horizon 7 environment, consideration should be given to the mixed workloads. There are management servers running in the management block and desktops and RDSH VMs running in the resource blocks. The storage selected should be able to

• Handle the overall I/O load and provide sufficient space.

• Ensure performance for key components so that a noisy neighbor such as a desktop does not affect the performance of the environment.

Depending on the capability of the storage being used, it is generally recommended to separate these mixed workloads.

In the environment built to validate this reference architecture, the underlying physical storage, all-flash, was shared between the management block and the resource blocks running desktop and RDSH workloads. This was possible because all-flash storage can handle mixed workloads while still delivering great performance.

This approach can be seen in the logical diagram Figure 24.

SQL Composer

Connection Server

DC App VolumesManager

VMware IdentityManager

vCenter Server

vSphere Cluster

Storage

vCenter Server (Management)

vCenter Server

vSphere Cluster

Storage

vSphere Cluster (Management)

Storage

Figure 24: All-Flash Storage Usage



Storage Replication For some components of the active/passive service, which uses two geographically dispersed sites, storage array data replication is necessary to provide complete business continuity.

If possible, use an asynchronous replication engine that can support bi-directional replication, which facilitates use of DR infrastructure for DR and production. VMware recommends using a replication engine that compares the last replicated snapshot to the new one and sends only incremental data between the two snapshots, thus reducing network traffic. Snapshots that can be deduplicated provide space efficiency.

VMware recommends replicating User Environment Manager data between sites. In the case of a site failure, a protected volume that is replicated to the DR site can be recovered promptly and presented. In the case of an active/active deployment, User Environment Manager volumes are replicated in each direction.

For optimal performance, VMware recommends implementing the advanced vSphere configuration changes outlined in Appendix B: Active/Active and Active/Passive Service with Replicating Storage Arrays.

Storage Array 1

\\domain\uem\site1

Site 1

Storage Array 2

Copy snapshot to new volume

Site 2

IPNetwork

\\domain\uem\site2

\\array1\UEM-S1 \\array2\UEM-S2

\\domain\uem\site1

Figure 25: Asynchronous Replication



Environment Infrastructure Dependencies Design Several environment resources are required to support a Horizon 7 deployment. In most cases, they already exist, but some key items are especially important when the environment is used for a multi-site deployment.

Active Directory Horizon 7 requires an Active Directory (AD) domain structure for user authentication and management. See the View Installation guide for details on supported versions and preparation steps. Standard best practices for an Active Directory deployment should be followed to ensure that it is highly available.

Because cross-site traffic should be avoided wherever possible, configure AD sites and services so that each subnet used for desktops and services is associated with the correct site. This guarantees that lookup requests, DNS resolution, and general use of AD are kept within a site where possible. This is especially important in terms of Microsoft Distributed File System Namespace (DFS-N) to control which specific file server users get referred to.

Group policies can also be associated at a site level.

Distributed File System File shares are critical in delivering a consistent user experience. They are used to store various types of data used to configure or apply settings that contribute to a persistent-desktop experience.

The data can include the following types:

• IT configuration data, as specified in User Environment Manager

• User settings and configuration data, which are collected by User Environment Manager

• Windows mandatory profile

• User data (documents, and more)

• ThinApps

The design requirement is to have no single point of failure within a site while replicating the above data types between the two data centers to ensure their availability in a site failure scenario. This reference architecture uses Microsoft Distributed File System Namespace (DFS-N) with array-level replication.

DFS Namespace

The namespace is the referred entry point to the distributed file system.

• A single entry point is enabled and active for profile-related shares to comply with the Microsoft support statements (for example, User Environment Manager user settings).

• Other entry points can be defined but disabled to stop user referrals to them. They can then be made active in a recovery scenario.

• Multiple active entry points are possible for shares that contain data that is read-only for the users (for example, User Environment Manager IT configuration data, Windows mandatory profile, ThinApps).

More detail on how DFS design applies to profile data can be found in the User Environment Manager section of this document.




Global Load Balancing and Name Spaces Throughout this paper, in each of the sections specific to a component, the back-end design and the front-end access mechanism have been discussed to show how to design the components to be highly available both within a site and between sites, for example, by using Global Traffic Manager (GTM) from F5.

This section describes load balancing between the two sites in general and explains how the active/ active service differs from the active/passive service in terms of persistence and end-user access.

All DNS services are running as Active Directory integrated zones on Windows Server 2012 R2–based domain controllers with no changes beyond Microsoft best practices.

This reference architecture uses the following three global namespace resources:

• horizon.vmweuc.com

• avm.vmweuc.com

• my.vmweuc.com

Those namespaces are delegated to the F5 BIG-IP DNS (GTM) function because it is effectively in charge of deciding where a user is directed based on the topology setup defined on F5 BIG-IP DNS for each of those services.

For guidance on how to configure F5 BIG-IP DNS (GTM) for the services listed above, refer to Appendix E: F5 Load Balancing Configuration.

Load Balancing for an Active/Active Service

The active/active service in this design uses the end user’s current physical location. Geo-location attributes align a user in Europe with a data center in Europe and a user in the U.S. with a U.S. data center.

When a user travels from, for example, Europe to the U.S., existing sessions are honored and re-connected, but new connections are always established with the data center closest to the user.

This kind of intelligent placement relies on the load balancer or geographic DNS capabilities, or both, to be functional. This is critical for the active/active service to ensure that a user is always getting a desktop in a data center closest to their current physical location.



Figure 26 presents a logical overview. The load balancer monitors both pods for availability and health check status and then decides, based on availability and the end user’s physical location, where a session should be placed.

horizon.vmweuc.com

Pod

Pod

Figure 26: Multi-Geo Active/Active Load Balancing

Load Balancing for an Active/Passive Service

User affinity for the active/passive service is based on the source IP address and is configured only on the Local Traffic Manager (LTM) layer because the F5 GTM flow checks only whether the LTM module of a given site is available. No affinity or session management occurs at the GTM layer. F5 GTM performs the initial placement based on the following:

• For external access, the geo-location of the user is considered.

• For internal access, the user is directed to one of the sites based on their client subnet value as defined by the VLAN (port group) the desktop pool is associated with.

This allows for the control of the traffic flow for on-premises users because we know the internal IP subnets used and can direct users accordingly. For example, if F5 GTM sees a connection associated with a subnet in Site 1, it directs the requests to Site 1 unless that site’s LTM instance is not responding to requests.



DHCP In multi-site deployments, the number of desktops a given site is serving usually changes when a failover occurs. This reference architecture tested deploying 500 desktops in each site, which requires, at a minimum, a /23 subnet range for normal production.

Typically, the recommendation is to over-allocate a DHCP range to allow for seamlessly recomposing pools and avoiding scenarios where IPs are not being released from the DHCP scope for whatever reason. To ensure additional capacity in a failover scenario, a larger /21 subnet was used for the desktop range, which provided approximately 2,000 IP addresses, meeting the requirements for running 1,000 desktops in either site during a failover while still leaving enough capacity should reservations get released.

It is not a requirement that the total number of desktops be run in the same site during a failover, but this scenario was chosen to show the most extreme case of supporting the total number of desktops in each site during a failover.

There are other strategies for addressing this issue, for example, by using multiple /24 networks across multiple desktop pools or dedicating a subnet size you are comfortable using for a particular desktop pool. The most important consideration is that there be enough IP address leases available to run the total number of required desktops from each site and within a site in a failover scenario.

As with any virtual desktop environment, consumption of DHCP can be quite fluid, with floating pools created with clones potentially deleting desktops at logout and recreating replacements. It is therefore necessary to make sure the lease period is set to a relatively short period (this depends on the frequency of logouts and the lifetime of a clone).

Microsoft RDS LicensingHorizon 7 published applications use Microsoft RDSH servers as a shared server platform to host Windows applications. Microsoft RDS hosts require licensing through a Remote Desktop Licensing service. It is critical to ensure that the Remote Desktop Licensing service is highly available within each site and also redundant across sites.

Microsoft KMSThe cloning process for virtual desktops and RDSH server VMs uses a Microsoft volume license key to activate Windows. To configure the volume license key, you use Microsoft Key Management Service (KMS). It is critical to ensure that the KMS service is highly available within each site and also redundant across sites.



Horizon 7 Components Required for Recovery ServicesAt this stage, we have all of the disaster recovery components designed and deployed, and the environment should have all the functionality and qualities that are required to deliver the services defined earlier. The components required can now be created, assembled, and integrated into the recovery service to be consumed by end users.

The table below details the components required for each service. Some are optional, as indicated in the Recovery Service Definitions section. The rest of this section details the steps for implementing each of the service types.

Note: This section details the components of a multi-site active/active and active/passive deployment. For component details of a vSAN stretched active/passive service, within a metro or campus network environment with low network latency between sites, see the section Horizon 7 Components Required for vSAN Stretched Cluster Recovery Services.

COMPONENT ACTIVE/ACTIVE SERVICE

ACTIVE/ PASSIVE SERVICE

VSAN STRETCHED ACTIVE/ PASSIVE SERVICE

VMware Identity Manager X X

Windows instant clone X X

Windows linked clone X X

RDSH linked clone X X

Windows full clone X

App Volumes AppStack X X

App Volumes writable volume X

User Environment Manager X X

Folder redirection X X X

Mandatory profile X X X

Storage replication (active/active) X X

vSAN stretched cluster X

Table 11: Recovery Service Components



Some parts are prerequisites for any of the services. Ensure that these services are configured and functional before looking at the specifics for a given service:

• User Environment Manager GPO (ADMX) configuration

• DFS Namespace (for User Environment Manager profile global access)

• Storage array replication

• Mandatory profile

• SQL Server Always On (for App Volumes and VMware Identity Manager databases)

• Load balancing between sites

• Load balancing within sites

The emphasis in this paper is on the configuration and integration necessary for multi-site deployments and disaster recovery. For more detail on creating and configuring components such as master VM images and pools of desktops, refer to the Horizon 7 documentation and the VMware Horizon 7 Enterprise Edition Reference Architecture.

Active/Active Service This section covers the high-level steps required to build out the active/active service, which can be seen from a blueprint perspective in Figure 27.

Profile


Service

Windows OS

ActiveSit

e 1 Instant or

Linked CloneIT

Config

Master VM AppStacks (Optional)


Apps

UserSettings

HomeFile

Shares


Windows OS

Active

Replication

Sit

e 2

Failover


Client(s)

User

Active

Active

Service

Figure 27: Active/Active Service Components

http://https://www.vmware.com/support/pubs/view_pubs.html





Desktops and RDSH-Published Applications

The first step is to create the Windows component of the service. This consists of either desktops or RDS hosts in pools or farms at both sites. Cloud Pod Architecture is then configured to provide a global entitlement to pools of desktops and published applications from both sites.

STEP DETAILS

Load balancing Verify both global and local load balancing are functional.

Master VM Build out a master VM image in Site 1 to meet requirements. Replicate the master VM image to Site 2.

Create pool or farm For desktops, create identical desktop pools in both sites based on the master VM image.For RDSH-published applications: • Create RDSH server farms in both sites using the master VM image.

• Add application pools in both sites containing the required applications.

Cloud Pod Architecture Set up and initialize Cloud Pod Architecture between the two sites.• Create sites and assign the pods to their respective sites.

• Create global entitlements.

• Associate pools from both sites.

Table 12: Steps for Creating the Windows Component of an Active/Active Service

Profile (User Environment Manager) and User Creation

The next step is to set up file shares in Site 1, set up DFS-N so that the file shares are replicated to Site 2, and determine which site is primary for each user so that the profile service can function as shown in Figure 28.

File Server Shares


ActiveSit

e 1

Profile and Files

ConfigShare

Profile


UserShare

HomeShare


Active

Replication

Sit

e 2

Failover

Client(s)

User

Activ

e

Active

ITConfig

ITConfig

UserSettings

HomeFile

Shares

UserSettings

HomeFile

Shares

Profile and Files

Service

Service


Figure 28: Profile Service Component



STEP DETAILS

File shares Create four file shares on the file server in Site 1 and set the relevant permissions.• User Environment Manager IT configuration

• User Environment Manager user settings


• Home file shares for redirected folders (optional)

Set up DFS-N following the guidance given in the User Environment Manager and Distributed File System sections.

User placement 1. Decide where a given named user is initially placed (Site 1 or Site 2).

2. Map a user to a GPO that matches that placement from a User Environment Manager perspective.

3. Verify profile creation and functionality by performing a login with a user.

Table 13: Steps for Creating the User Profile Component of an Active/Active Service

Active/Active Design for Applications Delivered Just in Time by App Volumes

To set up this container-style technology that attaches applications to a VM when the user logs in, you must install redundant instances of App Volumes Manager, create AppStacks, which store applications in shared read-only virtual disks (VMDK files), and, optionally, create writable volumes if users need to install their own applications.

AppVolumesManagers

Database


Service


e 1

AppStacks SQL

Apps



Service

Attached Apps

Active


Sit

e 2

Client(s)

User

Figure 29: Active/Active App Volumes Service Component



APP VOLUMES

STEP DETAILS

Installation 1. Set up two or more App Volumes Managers in Site 1.2. Set up two or more App Volume Managers in Site 2.See the App Volumes design section for details.

Load balancing 1. Configure local load balancing within each site with a virtual IP (VIP) namespace for the local App Volumes Managers.

2. Point the desktop master images to their respective namespace based on their site.3. If you are using the clustered-database option (rather than separate databases for each

site), configure global load balancing between the sites if required to have a global namespace.

Storage groups Set up a storage group in Site 1.• Select Automatically Replicate AppStacks.

• Select all datastores to be used for AppStacks.

• Additionally, select one common datastore to be used to replicate AppStacks to Site 2. NFS is a good choice for this datastore.

• Mark this common datastore as non-attachable.

Set up a second storage group in Site 2.• Select Automatically Replicate AppStacks.


• Additionally, select the common datastore to be used to replicate AppStacks from Site 1.


AppStacks 1. Create AppStacks as required to address the use cases. Follow the instructions in Working with AppStacks in the VMware App Volumes User Guide.

2. Place the AppStacks in the local storage group to allow them to replicate to every datastore in the local storage group and also to the other site.

Entitlement replication

If you are using the separate-databases configuration, do one of the following:• Manually reproduce entitlements made at one site to the other sites.

• Or, configure PowerShell for replicating application entitlements between the sites, as described in Appendix F: PowerShell Script for Replicating App Volumes Application Entitlements.

Table 14: Steps for Creating the Streamlined Application Component of an Active/Passive Service

https://www.vmware.com/support/pubs/app-volumes-pubs.html



Active/Passive Service This section covers the high-level steps required to build out the active/passive service, which can be seen from a blueprint perspective in Figure 30.

Profile

User Apps


Service

Attached Apps

Windows OS

ActiveSit

e 1 Instant or


ITConfig

Master VM


Apps

UserSettings

HomeFile

Shares

User Apps


Standby Service

Attached Apps

Windows OS

Active

Replication

Sit

e 2

Failover


Client(s)

User

Figure 30: Active/Passive Service Components

Desktops and RDSH-Published Applications

The first step is to create the Windows component of the service. This consists of either desktops or RDS hosts in pools or farms at both sites. Cloud Pod Architecture is then configured to provide a global entitlement to pools of desktops and published applications from both sites.

STEP DETAILS


Master VM Build out a master VM image in Site 1 to meet requirements.Replicate the master VM image to Site 2

Create pool or farm

For desktops, create identical desktop pools in both sites based on the master VM.For RDSH-published applications: • Create RDSH server farms in both sites using the master VM image.

• Add application pools in both sites containing the required applications.

Cloud Pod Architecture

Set up and initialize Cloud Pod Architecture between the two sites.• Create sites and assign the pods to their respective sites.

• Create global entitlements.

• Associate pools from both sites.

Table 15: Steps for Creating the Windows Component of an Active/Passive Service



Profile (User Environment Manager) and User Creation

To manage user settings, user data, and users’ access to applications, set up file shares in Site 1, set up DFS-N so that the file shares are replicated to Site 2, and determine which site is primary for each user so that the profile service can function as shown in Figure 31.

File Server Shares


ActiveSit

e 1

Profile and Files

ConfigShare

Profile


UserShare

HomeShare


Active

Replication

Sit

e 2

Failover

Client(s)

User

Activ

e

Active

ITConfig

ITConfig

UserSettings

HomeFile

Shares

UserSettings

HomeFile

Shares

Profile and Files

Service

Service


Figure 31: Profile Service Component

STEP DETAILS

File shares Create four file shares on the file server in Site 1 and set the relevant permissions.• User Environment Manager IT configuration

• User Environment Manager user settings


• Home file shares for redirected folders (optional)

Set up DFS-N following the guidance given in the User Environment Manager and Distributed File System sections.

User placement 1. Decide where a given named user is initially placed (Site 1 or Site 2).2. Map a user to a GPO that matches that placement from a User Environment

Manager perspective.3. Verify profile creation and functionality by performing a login with a user.

Table 16: Steps for Creating the User Profile Component of an Active/Passive Service



Active/Passive Design for Applications Delivered Just in Time by App Volumes

To set up this container-style technology that attaches applications to a VM when the user logs in, you must install redundant instances of App Volumes Manager, create AppStacks, which store applications in shared read-only virtual disks (VMDK files), and, optionally, create writable volumes if users need to install their own applications.

AppVolumesManagers

Database

User Apps


Service


e 1

AppStacksWritableVolume SQL

Apps


User Apps


Standby Service

Attached Apps

Active


Sit

e 2

Failover

Client(s)

User

Figure 32: Active/Passive App Volumes Service Component

APP VOLUMES

STEP DETAILS

Installation 1. Set up two App Volumes Managers in Site 1.2. Set up two App Volume Managers in Site 2.See the App Volumes design section for details.

Load balancing 1. Configure local load balancing within each site with a virtual IP (VIP) for the local App Volumes Managers.

2. Point the desktop master images to their respective VIP based on their site.3. If you are using the clustered-database option (rather than separate databases for each

site), configure global load balancing between the sites if required to have a global namespace.



APP VOLUMES

STEP DETAILS

Storage groups Set up a storage group in Site 1.• Select Automatically Replicate AppStacks.


• Additionally, select one common datastore to be used to replicate AppStacks to Site 2. NFS is a good choice for this datastore.


Set up a second storage group in Site 2.• Select Automatically Replicate AppStacks.


• Additionally, select the common datastore to be used to replicate AppStacks from Site 1.


AppStacks 1. Create AppStacks as required to address the use cases. Follow the instructions in Working with AppStacks in the VMware App Volumes User Guide.

2. Place the AppStacks in the local storage group to allow them to replicate to every datastore in the local storage group and also to the other site.

Entitlement replication

If you are using the separate-databases configuration, do one of the following:• Manually reproduce entitlements made at one site to the other sites.

• Or, configure PowerShell for replicating application entitlements between the sites, as described in Appendix F: PowerShell Script for Replicating App Volumes Application Entitlements.

Writable volumes (optional)

1. Create writable volumes for each user that requires one. Follow the instructions in Working with Writable Volumes in the VMware App Volumes User Guide.

2. Place writable volumes on dedicated LUNs, which can later be configured to be protected using storage replication.

Table 17: Steps for Creating the Streamlined Application Component of an Active/Passive Service






The VMware Identity Manager service provides a common entry point to all types of applications, regardless of which data center is actively being used. To build this service, you deploy three instances in Site 1, three instances in Site 2, and set up global load balancing.

Database

Workspace ONE

Service

ActiveSit

e 1


Appliances

Profile

SQL AlwaysOn

Standby ServiceReplication

Sit

e 2

Failover

Client(s)

User

Workspace ONE

Apps

Apps

Failover


AppliancesDatabase

Figure 33: VMware Identity Manager Service Component

The following table provides a very general overview of the steps to configuring VMware Identity Manager.

Important: For detailed instructions about all the steps in this table, see Appendix G: Setting Up VMware Identity Manager for High Availability in Multiple Sites.

VMWARE IDENTITY MANAGER CONFIGURATION

STEP DETAILS

Load balancing Configure local and global load balancer virtual servers.

First appliance Deploy the VMware Identity Manager OVA in Site 1.Follow the guidelines in the VMware Identity Manager design section.

Site 1 Clone the deployed appliance two times for a total of three VMware Identity Manager appliances in Site 1.Verify the three VMware Identity Manager appliances are functional in Site 1.



VMWARE IDENTITY MANAGER CONFIGURATION

STEP DETAILS

Site 2 Export the first appliance from Site 1 as a vApp and import it to Site 2.Verify the imported VMware Identity Manager appliance in Site 2 can communicate with the appliances in Site 1.Clone this appliance two times for a total of three VMware Identity Manager appliances in Site 2.

Load balancing Verify that load balancers are working as expected.

Table 18: Steps for Creating the Single Sign-On VMware Identity Manager Component of an Active/Passive Service

Storage Replication

You may use all-flash arrays or other types of storage that offer replication and can use common namespaces.

STORAGE

STEP DETAILS

Replication Set up and initialize storage replication capabilities to your vendors’ specification.Also see Appendix B: Active/Active and Active/Passive Services with Replicating Storage Arrays.

Replication targets Protect or replicate the datastores holding App Volumes writable volumes.

Table 19: Steps for Setting Up Storage Replication for an Active/Passive Service



Reference Architecture Validation This section details the impact to both users and services during failure and the behavior after failover for all the services.

Active/Active Service

DURING FAILURE AFTER FAILOVER

Logged in user Current sessions terminated. N/A

New user logging in User can log in to failover site immediately.

User can log in as normal.

VMware Identity Manager N/A (The VMware Identity Manager component is not supported in active/active mode.)

N/A

Access to user profile User Environment Manager

User gets temporary profile. User gets own profile.

Access to AppStacks User has access to AppStacks. User has access to AppStacks.

Access to writable volumes N/A N/A

Table 20: Active/Active Service Failure Impact

Active/Passive Service


Logged in user Current sessions terminated. N/A (After the current session is terminated, the user must log in again, and so becomes a new user logging in.)

New user logging in User cannot log in until CPA home site changed.

User can log in as normal.

VMware Identity Manager User might not have immediate access to VMware Identity Manager (depends on location of SQL primary node during failure).

User has access to VMware Identity Manager.

Access to user profile User Environment Manager

N/A User gets own profile.

Access to AppStacks User has access to AppStacks. User has access to AppStacks.

Access to writable volumes Writable volumes unavailable. User has access to writable volume.

Table 21: Active/Passive Service Failure Impact



vSAN Stretched Cluster Active/Passive ServiceFor the third use case, in which data centers are near each other, such as in a metro or campus network environment with low network latency between sites, a stretched VMware vSphere cluster using VMware vSAN is used between the two data centers. This provides both the data replication required and the high availability to recover the server components, desktops, and RDS hosts.

This use case uses full-clone desktop VMs to address existing Horizon 7 implementations that use full-clone persistent desktops that cannot easily be transitioned into a nonpersistent use case for various business reasons.

Recovery Service Definition for Stretched vSAN Active/Passive Service Requirement: The VMs used for VDI or RDSH run from a specific data center but can be failed over to a second data center in the event of an outage.

Overview: This service builds on the replication capability of vSAN and the high-availability (HA) features of vSphere when used in a stretched cluster configuration between two data centers. The Horizon 7 server components required are pinned to the vSphere hosts in one of the data centers using VM DRS groups, host DRS groups, and VM-Host affinity rules on the vSAN stretched cluster. vSphere HA fails them over to the second data center in the event of an outage.

Although the Windows component of the user service could be composed of full clones, linked clones, instant clones, or RDSH-published applications, this reference architecture shows full-clone desktop VMs. This addresses existing Horizon 7 implementations that use full-clone persistent desktops. Use cases involving floating desktop pools or RDSH-published applications are better served by adopting the active/active or active/passive use cases previously outlined. These use separate View pods per site with Cloud Pod Architecture for global entitlements.

Horizon 7 services accommodated: Legacy Full Clones, Developer Workspace Service. The overall RTO is between 15 and 30 minutes with an RPO of 15 to 30 minutes.

REQUIREMENT COMMENTS

Full-clone Windows desktop VMs

Persistent use case with 1:1 mapping of a VM to a user.VMs are replicated with a vSAN stretched cluster.• RTO = 15–30 minutes

• RPO = 15–30 minutes

Native applications • Applications are installed natively in a base Windows OS.

• Applications are replicated as part of the full-clone replication process above.

IT settings (optional) User Environment Manager IT configuration is replicated to another data center.• RTO = 30–60 seconds

• RPO = 30–60 seconds

User data and configuration (optional)

User Environment Manager user data is replicated to another data center.• RTO = 30–60 seconds


Table 22: Stretched vSAN Active/Passive Service Requirements



Stretched vSAN Active/Passive Service Blueprint

This service uses stretched storage to replicate both desktops and infrastructure components from one data center to the other. Only one data center is considered active, and in the event of a site outage all components would be failed over to the other site as a combined unit.

Profile

Desktop

Service

Windows OS

ActiveSit

e 1 Desktop

Clone Installed in Clone OSIT

Config

DesktopPool

Apps

UserSettings

HomeFile

Shares

Desktop

Standby Service

Windows OS

Replication

Sit

e 2

Failover

ProfileApps

Client(s)

User

StretchedStorage

Figure 34: Stretched vSAN Active/Passive Service Blueprint

Architectural Approach for the Stretched Active/Passive ServiceThis architecture relies on a single View pod with all required services always running at a specific site and never stretched between geographical locations. Only desktop workloads can run actively in both sites. The Connection Servers and other server components can fail over to Site 2 as a whole unit in the event of an outage of Site 1. This architecture relies on vSAN stretched cluster technology.

vSphere HA

Pod 1

Connection Servers

Pod 2

Connection Servers

Site 2Site 1

Figure 35: Stretched Active/Passive Architecture



vSphere Infrastructure Design Using vSANThe stretched active/passive service uses Horizon 7 hosted on a vSphere 6 environment with a vSAN stretched cluster and storage between the two sites.

In the validation of this design, a VMware vSAN storage environment was deployed as a vSAN stretched cluster to provide high availability and business continuity for the virtual desktops in a metro cluster deployment. The vSAN stretched cluster also achieves the high availability and business continuity required for the management server VMs.

In a stretched cluster, within a metro or campus network environment with low network latency between sites, VMware vSAN provides a radically simple business continuity solution, with short RTO time and no loss of data. The stretched cluster synchronously replicates data between two sites, providing high availability and protection against a single-site failure. This design is covered in more detail in Appendix C: Active/Passive Service Stretched with vSAN.

VMware vSAN supports active/active data sites with desktops and RDSH VMs active in both sites. Although these virtual desktops and Horizon 7 published applications can operate in active/active mode, the supporting management machines, and especially the Connection Servers, must all run within the one data center at a given time. To achieve this, the management servers should all be pinned to the same site at all times. Horizon 7 management services are deployed in an active/passive mode on a vSAN stretched cluster, failing over to the secondary site in the event of a site failure.

vSAN Configuration

A vSAN stretched cluster is organized into three fault domains, referred to as preferred, secondary, and witness. Each fault domain denotes a separate, geographically dispersed site.

• Preferred and secondary fault domains are data sites that contain an equal number of ESXi servers, with VMs deployed on them.

• The witness fault domain contains a single physical ESXi server or an ESXi virtual appliance whose purpose is to host the witness component of VM objects. When there is a failure or split-brain occurrence, the witness appliance contributes toward the object quorum so the VM can remain available.

Site 1(Active)

Fault Domain A

Site 2(Active)

Site 3(Witness)

Fault Domain BFault Domain C

Witness Appliance

vSAN Stretched Cluster

SSD SSD SSD SSD SSD SSD SSD SSD SSD

Storage


Figure 36: Stretched vSAN Configuration



The vSAN stretched cluster for Horizon 7 management VMs has a physical ESXi server located in the preferred fault domain (in our case Fault Domain A), an ESXi server in the secondary fault domain (in our case, B), and a dedicated witness virtual appliance running on an ESXi host located in the witness fault domain (C).

The six-node vSAN stretched cluster for Horizon 7 virtual desktops has three physical ESXi hosts located in the preferred fault domain, three physical ESXi hosts in the secondary fault domain, and a single witness virtual appliance located in the witness fault domain.

vSAN Network Requirements

Connectivity between vSAN data sites and the witness site must obey strict requirements. Both layer-2 (L2, same subnet) and layer-3 (L3, routed) configurations are used in a vSAN stretched cluster deployment.

VMware recommends that vSAN communication between the data sites be over stretched L2, and vSAN communication between data sites and the witness site be routed over L3.

vSAN traffic between data sites is multicast, whereas traffic between a data site and witness site is unicast.

Preferred Site 1(Active)

Data site to data site, L2 network, multicast, <5 ms latency, 10 Gbps

Witness to data site, L3 network, no multicast,

200 ms latency (500 ms latency for two nodes),

100 mbps

Witness to data site, L3 network, no multicast,

200 ms latency (500 ms latency for two nodes),

100 mbps

Secondary Site 2 (Active)

Witness Site 3

Stretched vSAN Cluster

vCenter Server

SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD SSD

Figure 37: Stretched vSAN Networking



A critical requirement for a vSAN stretched cluster is the amount of latency between sites. Latency between data sites should

• Not exceed 5 ms RTT (round-trip time)

• Be less than 2.5 ms each way

For a two-node vSAN stretched cluster configuration, latency between a data site and witness site can be a maximum of 500 ms RTT (250 ms each way).

It is recommended to have a minimum of 10-Gbps network bandwidth between sites.

View Pod and Blocks in a vSAN Stretched Cluster

In the validation of this design, a single vSAN stretched cluster is used for both the management block and the desktop block.

One vCenter Server was deployed for the management servers and the desktop resources.

VMware vSAN Stretched ClusterSites 1 and 2

vSphere 6.5 HA/DRS ClusterSite 3

6 x Dell PowerEdge R730 2 x Intel Xeon E5-2695 v3 24 C @ 2.3 GHz 256 GB RAM

All-Flash vSAN -1 x 400 GB Caching SSD -5 x 400 GB Capacity SSD

1 x vCenter Server Appliance

2 x Connection Servers

1 x Witness ESXi

Windows 10 Full Clones

vCenterServer

vSphere 6.5HA/DRS Cluster

Shared Storage

1 x Witness VA

WitnessHost

Figure 38: Horizon 7 Blocks on Stretched vSAN



Virtual Networking on vSAN

A single vSphere distributed switch was created with two 10-Gb interfaces in a team.

Four port groups isolate network traffic:

• Virtual machines

• ESXi management network

• vSphere vMotion

• vSAN traffic

Quality of Service is enforced with network I/O Control (NIOC) on the distributed virtual switch, guaranteeing a share of bandwidth for each type of traffic.

A vmkernel interface (vmknic) is created on the ESXi management port group, vSphere vMotion port group, and vSAN port group.

10 Gb Switches

10 Gb10 Gb

vmk2

VirtualMachines

vmk0

ESXiManagement

Network

vmk1

vSpherevMotion vSAN

vSphere Distributed Switch

Figure 39: vSphere Networking



Horizon 7 Components Required for vSAN Stretched Cluster Recovery ServicesThis section covers the high-level steps required to build out the stretched active/passive service (using a vSAN cluster), which can be seen from a blueprint perspective in Figure 40.

Profile

Desktop

Service

Windows OS

ActiveSit

e 1 Desktop

Clone Installed in Clone OSIT

Config

DesktopPool

Apps

UserSettings

HomeFile

Shares

Desktop

Standby Service

Windows OS

Replication

Sit

e 2

Failover

ProfileApps

Client(s)

User

StretchedStorage

Figure 40: Stretched Active/Passive Service

Table 23 outlines the steps required for creating a vSAN stretched cluster.

STEP DETAILS

Prerequisites Ensure the vSAN prerequisites in Appendix C: Active/Passive Service Stretched with vSAN are met.

Witnesses Deploy a vSAN witness appliance on a vSphere 6.5 HA/DRS cluster in Witness Site 3. Add the vSAN witness appliance to vCenter Server as a standalone ESXi host.

vSphere clusters Create the required vSphere stretched cluster by adding the ESXi hosts from Site 1 and Site 2.Enable vSAN for the cluster.Configure the fault domains and select the relevant witness hosts created earlier.

DRS and HA Configure DRS and HA settings as per Appendix C: Active/Passive Service Stretched with vSAN.

Affinity To pin the management servers as a unit to a particular site, you must create VMHost groups and VMHost rules.See Appendix C: Active/Passive Service Stretched with vSAN.

Complete Configure Horizon 7 servers and the VM template for the virtual desktops.Provision Horizon 7 full-clone desktops.

Table 23: Steps for Configuring a vSAN Stretched Active/Passive Service



Table 24 outlines the steps for creating the virtual desktops and published applications to be provided by a vSAN stretched cluster.

STEP DETAILS


Master VM Build out a master VM image in Site 1 to meet requirements.

Create desktop pool Create a desktop pool based on the master VM image.

Entitlements Entitle the users to the desktop pool as required.

Table 24: Steps for Creating the Windows Component of a vSAN Stretched Active/Passive Service

Note: With regards to the environmental infrastructure design, including Active Directory, distributed file systems, load balancing, and DHCP, you can use the same design as is used for the multi-site active/active and active/passive use cases, as described in Environment Infrastructure Dependencies Design.

Reference Architecture Validation for vSAN Stretched Cluster Active/Passive Service This section details the impact to both users and services during failure and the behavior after failover for all the services.


Logged in user Some sessions terminated (depends on location where desktop is running).

N/A

New user logging in User cannot log in. Once management services have resumed, user can log in as normal.

Access to user data If desktop is not disconnected, full-clone user has access to data.

User has access to data.

Table 25: vSAN Stretched Cluster Active/Passive Service Failure Impact



Appendix A: Scope Tables 26 and 27 summarize the components, services, and features in use in this reference architecture.

IN SCOPE COMMENTS

Horizon 7 version 7.2

VMware Identity Manager 2.9.1 On-premises version used.

Unified Access Gateway 2.9.1

User Environment Manager 9.2

App Volumes Manager 2.12.1

VMware vSAN 6.6 stretched cluster This component was used only for the Stretched Active/Passive service.

Table 26: In-Scope VMware Components

OUT OF SCOPE COMMENTS

3D workloads

Linux desktops

True SSO

Vendor-specific solutions for load balancing and storage replication

F5 BIG-IP is used for load balancing both inside and between sites; however, F5 is not a requirement.All-flash array replication was used to replicate App Volumes writable volumes between sites; however, any vendor that offers crash-consistent replication of datastores supported by vSphere 6.x can be used.

Table 27: Out-of-Scope Components



Appendix B: Active/Active and Active/Passive Services with Replicating Storage ArraysSome vSphere configuration changes are recommended for optimal performance. These changes and other settings are documented in this section.

VSPHERE HA SETTING

vSphere HA Turn on vSphere HA

Host Monitoring Enabled

Host Hardware Monitoring – VM Component Protection: “Protect against Storage Connectivity Loss”

Disabled (default)

Virtual Machine Monitoring Disabled (default)

Table 28: vSphere High Availability (HA) Settings

Leave all other HA settings set to the default.

VSPHERE DRS SETTING

vSphere DRS Turn on vSphere DRS

DRS Automation Fully Automated

Power Management Off

Table 29: vSphere Distributed Resource Scheduler Settings

Leave all other DRS settings set to the default.

Table 30 shows the distributed switch and port group policies.

PROPERTY SETTING DEFAULT REVISED

General Port Binding Static –

Policies: Security Promiscuous mode Reject –

MAC address changes Accept Reject

Forged transmits Accept Reject

Policies: Traffic Shaping

Status Disabled –

Policies: Teaming and Failover

Load balancing Route based on the originating virtual port ID

Route based on physical NIC load

Failover detection Caution Link Status only –

Notify switches Yes –




Policies: Resource Allocation

Network I/O Control Disabled Enabled

Advanced Maximum MTU 1500 9000

Table 30: Distributed Switch Settings



Appendix C: Infrastructure Design for the Stretched vSAN Active/Passive Service This appendix provides specifications for designing the infrastructure of the active/passive service stretched with vSAN, including settings for vSAN, vSphere, distributed switches, and storage.

Table 31 details the vSAN prerequisites.

REQUIREMENTS

Three dispersed sites • Two data sites, each with an equal number of ESXi hosts

• One witness site with dedicated ESXi physical server or virtual appliance, per vSAN stretched cluster

Network requirements

Data site to data site • < 5 ms latency round-trip time over 10 Gbps

• Layer-2 or Layer-3 network

• Connectivity with multicast

Witness site to data site • 200 ms latency over 100 mbps (500 ms permitted for two-node cluster)

• Layer-3 network

• Connectivity without multicast

Table 31: vSAN Prerequisites

The vSphere High Availability (HA) settings are summarized in Table 32.

VSPHERE HA SETTING

vSphere HA Turn on vSphere HA

Host Monitoring Enabled

Host Hardware Monitoring – VM Component Protection: “Protect against Storage Connectivity Loss”

Disabled (default)

Virtual Machine Monitoring Disabled (default)

Admission Control Set to 50%

Host Isolation Response Power off and restart VMs

Datastore Heartbeats Select Use datastores only from the specified list – Do not select any of the datastores.

Table 32: vSphere High Availability (HA) Settings



Settings for vSphere Distributed Resource Scheduler are summarized in Table 33.

VSPHERE DRS SETTING

vSphere DRS Turn on vSphere DRS

DRS Automation Partially Automated

Power Management Off

VMHost Groups For Management block onlyAdd new VMHost Groups • Name: Preferred-Site-Hosts

- Add ESXi hosts from Site 1 • Name: Secondary-Site-Hosts

- Add ESXi hosts from Site 2 Add new VM Group • Name: Management-VM-Group

- Add vSphere and Horizon 7 management VMs

VMHost Rules Add new VMHost Rule • Name: ManagementVMs-to-Preferred-Site

• Type: Virtual Machines to Hosts

• VM Group: Management-VM-Group

For Must run on hosts in group • Host Group: Preferred-Site-Hosts

vSphere HA Rule Settings VM to Host affinity rules: vSphere HA should respect rules during failover.

Table 33: vSphere Distributed Resource Scheduler Settings



The following table shows the distributed switch and port group policies.


General Port Binding Static –

Policies: Security Promiscuous mode Reject –

MAC address changes Accept Reject

Forged transmits Accept Reject

Policies: Traffic Shaping

Status Disabled –

Policies: Teaming and Failover

Load balancing Route based on the originating virtual port ID

Route based on physical NIC load

Failover detection Caution Link Status only –

Notify switches Yes –

Policies: Resource Allocation

Network I/O Control Disabled Enabled

Advanced Maximum MTU 1500 9000

Table 34: Distributed Switch Settings

Details for storage are listed in the following table.

FUNCTION DEVICE BACKING FILE SYSTEM STORAGE POLICY

ESXi local install 1 x 16-GB SD card VMFS v6 -

vSAN 1 x Disk Group per ESXi Caching: 1 x Intel S3700 DC 400 GB SSD Capacity: 5 x Intel S3700 DC 400 GB SSD

Disk Format v5 Default

Table 35: Storage Specifications



Appendix D: Test Plan This appendix includes sections for all three of the services described in this reference architecture:

• Active/Active Horizon 7 Service Failover Test/Recovery Plan

• Active/Passive Horizon 7 Service Failover Test/Recovery Plan

• Active/Passive Horizon 7 Service Failover Test/Recovery Plan on vSAN Stretched Cluster



Active/Active Horizon 7 Service Failover Test/Recovery Plan In the test plan depicted in Figure 41, a floating desktop user with a User Environment Manager profile and an assigned AppStack fails over from Site 1 to Site 2 after a disaster event.










iSCSI RDM iSCSIRDM

SQL Servers

Local Load Balancer



SQL FCI #1(Primary)


Composer

SQL

SQL SQL SQL SQL

SQL


Connectors


Connection Servers

App Volumes Mangers

Horizon Events

AG Listener

Horizon Events

AG Listener

ComposerAG Listener

ComposerAG Listener






SQL Servers



App Volumes Mangers

SQL Servers SQL Servers

Local Load Balancer

Local Load Balancer

DMZDMZ


Local Load Balancer

Composer


Connectors


Connection Servers


Figure 41: Active/Active Horizon 7 Service Failover Test/Recovery Plan



The following table lists the preliminary tests and checks to be performed.

TEST NAME DESCRIPTION EXPECTATION OUTCOME

0.1 Test user login in Site 1

Log in with user S1-sales1 to Site 1.Change the desktop background.

User logs in successfully and the desktop change is written to the background.

As expected


Log in with user S2-sales1 to Site 2.Change the desktop background.


As expected

0.3 Identify candidate site to bring offline

Select the site with the master-of-operations domain controller/SQL Server Always On primary role, in order to simulate a full site failover.

Candidate is identified for the failover test.

Site 1 identified

0.4 Prepare timing to record failover

Prepare a time device to record the time it takes for failover of services from the failed site to the remaining site.

Time source starts recording time when failover occurs.

As expected

Table 36: Active/Active Preliminary Tests

The following list of tests includes descriptions of occurrences during an active/active service failover, the recovery steps required, and the test results.


1.1 Site failure simulation initiated

Power is killed to all ESXi servers in Site 1: three servers for management VMs, and three servers for hosting desktops.

ESXi servers in Site 1 – management cluster and all management VMs are offline. ESXi hosts in Site 1 – desktop cluster and all virtual desktops are unavailable. Virtual desktop sessions to Site 1 are killed. Virtual desktop sessions to linked-clone and full-clone desktops in Site 2 are unaffected.

Desktop session for user S1-sales1 terminated

1.2 Verify user desktop session to Site 2 (Test 0.2) is still operating normally

Verify that the user experience of the Site 2 user, who is logged in to Site 2, is the same as before the failure of Site 1.

The S2-sales1 user continues to work as normal (AppStacks, VMware Identity Manager, User Environment Manager configuration and user data).

As expected

2 Verify Site 1 user can log in to Site 2

User S1-sales1 logs in to Site 2. The S1-sales1 user can log in and get a temporary profile and User Environment Manager configuration settings.No VMware Identity Manager features are available due to offline SQL.

As expected




3.0 Point the global load balancer to the load balancer in Site 2 for VMware Identity Manager

Modify the global load balancer or DNS record to point to the load balancer in the secondary data center.

For more details about this process, see Failover to Secondary Data Center, in Installing and Configuring VMware Identity Manager.

As expected

3.1 Always On failover for VMware Identity Manager

Move the primary role to a node on the SQL Server Always On cluster in Site 2, for the VMware Identity Manager protection groups.

The Always On availability group comes online in Site 2 and can be accessed through the VMware Identity Manager JDBC connection.

As expected

3.2 VMware Identity Manager Sync Connector

Use the VMware Identity Manager administration console to select a sync connector in Site 2.

The sync connector in Site 2 will sync users and groups from the enterprise directory to the VMware Identity Manager Service in Site 2.

As expected

3.3 VMware Identity Manager availability verification

VMware Identity Manager recognizes the Always On availability group listener has changed.

After a few minutes, VMware Identity Manager should be functional again. Verify by logging in as the admin user, and change an entitlement on an existing resource.

As expected

3.4 App Volumes Manager is unaffected

Because App Volumes uses separate standalone databases in each site, no failover action is required.

The S1-sales1 user can log in and get the correct AppStack because AppStack entitlements are replicated between sites.

As expected

3.5 Active Directory FSMO roles

Site 1 had the master-of-operations domain controller. Necessary to seize FSMO roles for the domain controller in Site 1.

Seizing of all roles successful and the DFS management console can access the domain-based namespace hosted fileservers in Site 1.

As expected

3.6 DFS replication

Remove unavailable referral points from Site 2 and add in a copy from Site 1.

The \\vmweuc.com\data\ s1-user-data folder can be written to.

As expected

4 Verify user login

Log in again with user S1-Sales1 (Step 2) and verify that the user receives a profile.

DFS referral is available, and the user receives a profile.

As expected

Table 37: Active/Active Test Results

Notes

• Step 3.1 is required only if the failed site held the primary SQL node, necessitating moving the primary role to the continuity site.

• Step 3.6 is required only if the failed site had the Master of Operations Domain Controller, necessitating moving FSMO roles to the continuity site.





Active/Passive Horizon 7 Service Failover Test/Recovery Plan In the following test, a persistent desktop user s1-Finance1, with a home site of Site 1, a User Environment Manager profile, and assigned AppStacks and a writable volume, fails over from Site 1 to Site 2 after a DR event.










iSCSI RDM iSCSIRDM

Site1 User: S1-Finance1

SQL Servers

Local Load Balancer



SQL FCI #1(Primary)


Composer

SQL

SQL SQL SQL SQL

SQL


Connectors


Connection Servers

App Volumes Mangers

Horizon Events

AG Listener

Horizon Events

AG Listener

ComposerAG Listener

ComposerAG Listener






SQL Servers



App Volumes Mangers

SQL Servers SQL Servers

Local Load Balancer

Local Load Balancer

DMZDMZ


Local Load Balancer

Composer


Connectors


Connection Servers


Figure 42: Active/Passive Horizon 7 Service Failover Test/Recovery Plan






Log in with user S1-Finance1 to Site 1. Change the desktop background.


As expected


Log in with user S2-Finance1 to Site 2. Change the desktop background.


As expected

0.3 Identify candidate site to bring offline

Select the site with master-of-operations domain controller/SQL Server Always On primary role, in order to simulate full site failover.

Candidate is identified for the failover test.

Site 1 identified


Prepare a time device to record the time it takes for failover of services from the failed site to the remaining site.


As expected

Table 38: Active/Passive Preliminary Tests

The following list of tests includes descriptions of occurrences during an active/passive service failover, the recovery steps required, and the test results.



Power is killed to all ESXi servers in Site 1: three servers for management VMs, and three servers for hosting desktops.

ESXi servers in Site 1 – management cluster and all management VMs are offline. ESXi hosts in Site 1 – desktop cluster and all virtual desktops are unavailable. Virtual desktop sessions to Site 1 are killed. Virtual desktop sessions to linked-clone and full-clone desktops in Site 1 are unaffected.

Desktop session for user S1-finance1 terminated

1.2 Verify user desktop session to Site 2 (Test 0.2) is still operating normally

Verify that the user experience of the Site 2 user, who is logged in to Site 2, is same as before the failure of Site 1.

The S2-Finance1 user continues to work as normal (AppStacks, VMware Identity Manager, User Environment Manager configuration and user data).

As expected

2 Verify Site 1 user can log in to Site 2

User S1-Finance1 logs into Site 2. The user gets an error and cannot launch a desktop.

As expected




3.0 Point the global load balancer to the load balancer in Site 2 for VMware Identity Manager

Modify the global load balancer or DNS record to point to the load balancer in the secondary data center.

For more details about this process, see Failover to Secondary Data Center, in Installing and Configuring VMware Identity Manager.

As expected

3.1 Always On failover for VMware Identity Manager

Move the primary role to a node on the SQL Server Always On cluster in Site 2, for the VMware Identity Manager protection groups.

The Always On availability group comes online in Site 2 and can be accessed through the VMware Identity Manager JDBC connection.

As expected

3.2 Mware Identity Manager Sync Connector

Use the VMware Identity Manager administration console to select a sync connector in Site 2.

The sync connector in Site 2 will sync users and groups from the enterprise directory to the VMware Identity Manager Service in Site 2.

As expected

3.3 VMware Identity Manager availability verification

VMware Identity Manager recognizes the Always On availability group listener has changed.

After a few minutes, VMware Identity Manager should be functional again. Verify by logging in as the admin user, and change an entitlement on an existing resource.

As expected

3.4 App Volumes Manager is unaffected

Because App Volumes uses separate standalone databases in each site, no failover action is required.

The S1- Finance1 user can log in and get the correct AppStack because AppStack entitlements are replicated between sites.

As expected

3.5 Active Directory FSMO roles

Site 1 had the master-of-operations domain controller. Necessary to seize FSMO roles for the domain controller in Site 2.

Seizing of all roles is successful and the DFS management console can access the domain-based namespace hosted file servers in Site 2.

As expected

3.6 DFS Replication

Remove unavailable referral points from Site 2 and add in a copy from Site 1.

The \\vmweuc.com\data\s1-user-data folder can be written to.

As expected

3.7 Recover writable volumes array snapshot

Copy the latest snapshot on the Site 2 all-flash array from source Site 1 all-flash array. Create a new volume and present it to the Site 2 host group of ESXi servers.

The snapshot is copied to a new volume, COPY-S1-writablevolumes-x.

As expected

3.8 Add storage to Site 2 ESXi cluster

Scan the storage adapters on the ESXi hosts in Site 2.Add a new datastore and resignature it. Label the vSphere datastore COPY-S1- writablevolumes-x.

The copy of the Site 1 writable volumes datastore is presented to all ESXi hosts in Site 2 and mounted successfully.

As expected






3.9 App Volumes Manager – Disable old Site 1 writable volumes reference

Log in to the App Volumes Manager console. Disable assignments to the S1-writablevolumes-x datastore.

All assignments to the writable volumes datastore in failed Site 1 are successfully disabled.

As expected

3.10 App Volumes Manager – Import new COPY-Site1- writable volumes-x datastore

Log in to the App Volumes Manager console. Import the COPY-S1-writablevolumes-x datastore.

All assignments to writable volumes are successfully added, but to the new valid location.

As expected

4 Horizon 7 CPA home site override for Site 1 user groups

Log in to the Horizon Administrator console and set the home site override on the Finance GE to S1-Finance > Site 2.

Override succeeds. As expected

5 Verify user login for Site 1 user to Site 2

Log in again with user S1-Finance1 (Step 2) and verify that the user is able to work as before the site failure

User receives User Environment Manager profile, writable volume, and VMware Identity Manager portal access.

As expected

Table 39: Active/Passive Test Results

Active/Passive Horizon 7 Service Failover Test/Recovery Plan on vSAN Stretched Cluster For this test, a whole site failure was simulated for one of the data sites in a vSAN stretched cluster configuration consisting of Horizon 7 management server VMs and virtual desktops running on a vSAN stretched cluster.

Users were logged into full-clone virtual desktops when the failure occurred.

Site 1(Active)

Fault Domain A

Site 2(Active)

Site 3(Witness)

Fault Domain BFault Domain C

Witness Appliance


Storage


vSAN Stretched Cluster

Figure 43: Active/Passive Horizon 7 Service Failover Test/Recovery Plan on vSAN Stretched Cluster





0.1 Identify candidate site for simulated failure

Select the site where all management VMs are running.

Management machines are pinned to the data site using DRS affinity rules.

Site 1 selected

0.2 Verify virtual desktops are ready for test

Check full-clone pool deployed across desktop vSAN stretched cluster.

Full-clone virtual desktops are available for login across both sites.

As expected

0.3 Verify vSAN fault domain, HA, and DRS settings

Verify that vSAN is operating effectively, with no errors.Also, verify HA and DRS are enabled and configured correctly to support vSAN site failover.

vSAN reports no issues with configuration. HA and DRS settings are optimal.

As expected

0.4 Users logged into virtual desktops

Log in test users to full-clone virtual desktops; one in each of Site 1 and Site 2.

Users are logged in to full-clone virtual desktops in Site 1 and Site 2.

As expected


Prepare a time device to record the time it takes for failover of services from Site 1 to Site 2.


As expected

Table 40: Active/Passive on vSAN Stretched Cluster Preliminary Tests

The following list of tests includes descriptions of occurrences during a stretched vSAN active/passive service failover, the recovery steps required, and the test results.



Power is killed to all ESXi servers in Site 1: one server for management VMs, three servers for hosting desktops.

The ESXi server that hosts the management VMs goes offline. Full-clone virtual desktops in Site 1 are unavailable. Virtual desktop sessions to full-clone desktops in Site 1 are killed. Virtual desktop sessions to full-clone desktops in Site 2 are unaffected.

As expected

2.0 vSphere High Availability fails the management VMs over to Site 2

HA starts up management VMs (vCenter Server, AD domain controller, SQL Server, Connection Servers, Composer, VMware vRealize® Operations for Horizon) in Site 2.

HA restarts the management VMs within 30 seconds.

HA restarts management VMs within 25 seconds.Management VMs show vSAN storage policy non-compliance.




2.1 vSphere High Availability fails over full-clone desktops to Site 2

HA starts up all full-clone desktops that had been running in Site 1 before failure occurred.

HA restarts virtual desktops. HA powers on all virtual desktops in 2 minutes.Desktop VMs show vSAN storage policy non-compliance.

Table 41: Active/Passive on vSAN Stretched Cluster Test Results



Appendix E: F5 Load-Balancing Configuration For more information about configuring F5 solutions, refer to the following resources:

• For setting up the global load balancer: Managing Horizon Traffic Across Multiple Data Centers with BIG-IP (used with Horizon 7 and VMware Identity Manager)

• For setting up the local, site-specific load balancers: Load Balancing VMware Identity Manager

• F5 with App Volumes Configuration Guide

https://devcentral.f5.com/Portals/0/userfiles/48273/HorizonView-GTM-Config.pdf


https://f5.com/Portals/1/PDF/Partners/f5-big-ip-vmware-workspaceone-integration-guide.pdf

https://devcentral.f5.com/Portals/0/userfiles/48273/F5-VMware App Volumes Configuration Guide v1 0.pdf



Appendix F: PowerShell Script for Replicating App Volumes Application EntitlementsTo use this script, you copy and paste the script, either to the database VM, to run the script locally on the server, or to another location, where you can run the script remotely as long as you have an account with the proper permissions and the machine meets the following software requirements:

• Windows Management Framework 4.0

• Microsoft .NET Framework 4.5

Next, open the script with a text editor and change the username, password, source server, and destination server to match your environment. These items are shown in bold text, in the first five lines of the following script. When you are finished, save the file with a .ps1 extension.

$Credentials = @{ username = 'domain\username' password = 'password'

}

$SourceServer = "SourceServerFQDN" $TargetServer = "DestinationServerFQDN"

Invoke-RestMethod -SessionVariable SourceServerSession -Method Post -Uri "https://$SourceServer/cv_api/sessions" -Body $Credentials Invoke-RestMethod -SessionVariable TargetServerSession -Method Post -Uri "https://$TargetServer/cv_api/sessions" -Body $Credentials

$SourceAssignments = (Invoke-RestMethod -WebSession $SourceServerSession -Method Get -Uri "https://$SourceServer/cv_api/assignments").assignments

$SourceAppstacks = Invoke-RestMethod -WebSession $SourceServerSession -Method Get -Uri "https://$SourceServer/cv_api/appstacks" $TargetAppStacks = Invoke-RestMethod -WebSession $TargetServerSession -Method Get -Uri "https://$TargetServer/cv_api/appstacks"

foreach ($Assignment in $SourceAssignments) { $SourceAppStack = $SourceAppStacks.Where({$_.id -eq $assignment.snapvol_id})[0] $TargetAppStack = $TargetAppStacks.Where({$_.name -eq $SourceAppstack.name})[0] Invoke-RestMethod -WebSession $TargetServerSession -Method Post -Uri "https://$TargetServer/cv_api/assignments?action_type=assign&id=$($TargetAppStack.id)&assignments%5B0%5D%5Bentity_type%5D=$($assignment.entityt)&assignments%5B0%5D%5Bpath%5D=$($assignment.entity_dn)"

}



Appendix G: Setting Up VMware Identity Manager for High Availability in Multiple SitesUse the procedures in this appendix to create SQL Server clustered instances that can fail over between sites and to set up a highly available database for VMware Identity Manager. The following diagram shows the architecture.

Local Load Balancer

VM

war

e Id

enti

ty M

anag

er

Gro

up 1

Win

do

ws

Fai

love

rC

lust

er 1

PrimarySQL ServerDatabase

WindowsServer 1

Site 1V

Mw

are

Iden

tity

Man

ager

G

roup

2W

ind

ow

s F

ailo

ver

Clu

ster

2

Local Load Balancer

Site 2

SecondarySQL ServerDatabase



SQL ServerAlways On Listener

Global Load Balancer







WindowsServer 2

WindowsServer 1

WindowsServer 2

Figure 44: VMware Identity Manager Architecture

The tasks you need to complete are grouped into the following procedures:

1. Create a Windows Server Failover Cluster and Configure Shared Storage

2. Install the SQL Server Failover Cluster

3. Configure Cluster Quorum Settings and Possible Owners for Each Cluster Instance

4. Create the VMware Identity Manager Database

5. Create and Configure the SQL Server Always On Availability Group for VMware Identity Manager

6. Deploy and Set Up VMware Identity Manager Appliances

7. Configure Failover and Redundancy for VMware Identity Manager

8. Deploy and Set Up the VMware Identity Manager Connectors Inside the Corporate Network

9. Finalizing Failover Preparation



Create a Windows Server Failover Cluster and Configure Shared StorageA Windows Server Failover Clustering (WSFC) failover cluster is a group of VMs that have the same software installed on them and work together as one instance to provide high availability for a service, such as a Microsoft SQL Server database. If a VM, or cluster node, in the cluster fails, another node in the cluster begins to provide the service.

To create a WSFC cluster with shared storage:

1. On two ESXi hosts in Site 1, create and configure the two VMs that will be used as a clustered instance of Microsoft SQL Server, and then do the same in Site 2.

For instructions, see Setup for Failover Clustering and Microsoft Cluster Service and use these chapters:

• Chapter 3: Cluster Virtual Machines Across Physical Hosts Using a cluster of VMs across physical hosts protects against software failures and hardware failures on the physical machine by placing the cluster nodes on separate VMware ESXi hosts. This configuration requires shared storage on a Fibre Channel SAN for the quorum disk. The VMs share a private network connection, for the private heartbeat, and a public network connection. This chapter guides you through the process of creating and configuring the VMs on which you will install the SQL Servers. This chapter also guides you through creating virtual hard disks using unformatted LUNs on SAN datastores. You will create an RDM (raw device mapping) disk in physical compatibility (pass-through) mode. Note: For this reference architecture, we used the Windows Server 2012 R2 Standard operating system in the VMs that run SQL Server.

• Chapter 5: Use MSCS in an vSphere HA and vSphere RDS Environment Because the cluster of MSCS (Microsoft Cluster Service) VMs goes across physical hosts, you must set VM-VM anti-affinity rules to specify that the VMs should be kept apart, on different physical hosts. You must also set VM-Host affinity rules, which requires creating a DRS group for VMs and a DRS group for ESXi hosts. The VM-Host affinity rules specify that the VMs in the VM DRS group can run on the ESXi hosts in the host DRS group.

2. To set up failover clustering on the SQL Server VMs, user Server Manager on each of the four VMs (two in Site 1 and two in Site 2), and use the Windows Server Add Roles and Features Wizard to add the Failover Clustering feature.

In the wizard, select to add the following features:

• .NET Framework 3.5 features

• Failover Clustering, including adding the Failover Clustering tools

For detailed instructions, see the Microsoft blog post Installing the Failover Cluster Feature and Tools in Windows Server 2012. One of the tools installed is the Failover Cluster Manager, which you will use for many of the steps that follow.

3. Create a file server in each site with a shared folder that you will use for the quorum witness; for example, the path to the file share in Site 1 might be something like \\S1-FILE\Quorum.

4. In each site, in Active Directory, give the cluster object full rights on each SQL server machine.

a. On the domain controller, open Active Directory Users and Groups.

b. On the View menu, make sure that Advanced Features is selected.

c. Navigate to the computer object for one of the SQL Server VMs in the cluster, right-click the object, and select Properties.

d. Click the Security tab, scroll through the list of users, and select the cluster name object (CNO).

If the cluster name is not in the list, click Add to add it.

https://docs.vmware.com/en/VMware-vSphere/index.html

https://blogs.msdn.microsoft.com/clustering/2012/04/06/installing-the-failover-cluster-feature-and-tools-in-windows-server-2012/




e. In the list of permissions, select the Full Control check box to allow full control, and click OK.

f. Repeat these steps for the other SQL Server VMs.

5. In each site, use vSphere Web Client to create RDM disks for the shared SQL disks:

• SQL_Data

• SQL_Logs

• SQL_Backup

SQL_Temp and SQL_Binaries are local drives to each SQL Server VM and do not need to be shared.

6. On each SQL Server VM, map the disks to drive letters.

For example, map the SQL_Data disk to drive F, map the SQL_Logs disk to drive G, and map the SQL_Backup disk to drive H, so that both VMs use the same drive letters for the same disks. Also, make sure the drive letters for local disks are the same on all VMs. Perform this task for the two SQL Server VMs in Site 1 and the two SQL Server VMs in Site 2.



7. Open Failover Cluster Manager in each site and verify that the disks appear as available storage.

Install the SQL Server Failover ClusterIn this procedure, you run the Setup.exe program from the SQL Server installation media to install a new failover cluster on the first SQL Server VM. On the second SQL Server VM, you run the Setup.exe program and select to add a node to the existing SQL Server failover cluster that you created on the first SQL Server VM.

To create SQL Server failover cluster instances for both sites:

1. In Site 1, on the first SQL Server VM, complete the SQL Server installation wizard, using the following guidelines:

• Installation page – Select New SQL Server failover cluster installation.

• Feature Selection page – Select all of the Database Engine Services features.

• Instance Configuration page – Select Named Instance and enter a name. For example, use S1Inst for the SQL Server failover instance in Site 1, and use S2Inst for the instance in Site 2.

• Cluster Resource Group page – Create a new cluster resource group name for each site.

• Cluster Network Configuration page – Select the IPv4 check box. Do not select the DHCP check box because the SQL Server VM has a static IP address. Site 1 and Site 2 will have different networks.

• Server Configuration page – Do not change the startup type for the services that use the Manual startup type. The cluster service must control these services.

• Database Engine Configuration page – On the Data Directories tab, for each item, select the disk that you created for that type of file. For example, place the data root directory, system database directory, and user data directory on the RDM disk you created for SQL data. For the database log directory, select the RDM disk you created for SQL logs, and so on. On the Server Configuration tab, select Mixed Mode (SQL Server authentication and Windows authentication), and enter credentials for a user account that will be part of the SQL Server administrators.

For detailed instructions, see Create a New SQL Server Failover Cluster (Setup).

2. On the second SQL Server VM in the cluster, run the SQL Server installation wizard, but on the installation page, select Add node to a SQL failover cluster.

For the other pages, follow the guidelines in the previous step. For detailed instructions about the wizard, see Add or Remove Nodes in a SQL Failover Cluster (Setup).

https://technet.microsoft.com/en-us/library/ms179530(v=sql.120).aspx




3. Open the Failover Cluster Manager, expand the cluster, and verify that the following items are working as expected:

a. Select Roles to verify that the SQL Server cluster instance is running.

b. Select Nodes to verify that SQL Server on both SQL Server VMs is running.

c. Under Storage, select Disks to verify that the RDM disks for data, logs, and backups are all online and are assigned to the SQL Server clustered instance.

4. Repeat these steps to create the SQL Server instance in Site 2.

Now we have a WSFC cluster with two SQL Server failover instances, and a total of four SQL servers.

Configure Cluster Quorum Settings and Possible Owners for Each Cluster InstanceAt this point, you will configure cluster quorum settings and specify which cluster nodes (VMs) each cluster instance can run on. Each element in a cluster can cast one “vote” to determine whether the cluster can run. Because you have two nodes in a cluster and you need an odd number of voting elements, create a file share quorum witness, which will cast the third vote. A file share witness is recommended when you need to consider multi-site disaster recovery with replicated storage.

To configure the cluster quorum settings:

1. Configure quorum votes for Site 1:

a. In Site 1, open Failover Cluster Manager, right-click the cluster for Site 1, and select More Actions > Configure Cluster Quorum Settings.

b. Complete the Configure Cluster Quorum Wizard, using the following guidelines:

• Select Quorum Configuration Option page – Select Advanced Quorum Configuration.

• Select Voting Configuration page – Click Select Nodes, and select the check boxes for the SQL Server VMs in Site 1 only. Leave the check boxes for the VMs in Site 2 deselected.

• Select Quorum Witness page – Select Configure a file share witness, click Next, and enter the path to the file share; for example, \\S1-FILE\Quorum. You created this file share in Step 3 of Create a Windows Server Failover Cluster and Configure Shared Storage.

For detailed instructions, see Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster.

c. To verify that the quorum is configured correctly, in Failover Cluster Manager, select Nodes and examine the Assigned Vote column.

https://technet.microsoft.com/en-us/library/jj612870(v=ws.11).aspx




2. Configure quorum votes for Site 2:

a. In Site 2, open Failover Cluster Manager, right-click the cluster for Site 2, and select More Actions > Configure Cluster Quorum Settings.


• Select Quorum Configuration Option page – Select Advanced Quorum Configuration.

• Select Voting Configuration page – Click Select Nodes, and select the check boxes for the SQL Server VMs in Site 2 only. Leave the check boxes for the VMs in Site 1 deselected.

• Select Quorum Witness – Select Configure a file share witness, click Next, and enter the path to the file share in Site 2; for example, \\S2-FILE\Quorum.

3. Configure the possible owners for each WSFC instance.

a. Select Roles in the left pane.

b. Select the cluster instance for Site 1 in the upper portion of the Roles pane.

c. Click the Resources tab in the lower pane.

d. Scroll down and select the resource under Server Name.

e. Right-click the resource and select Properties.

f. Click the Advanced Policies tab and deselect the check boxes for the two SQL Server VMs in Site 2. Only the two SQL Server VMs in Site 1 should be possible owners.



g. Click OK on the Advanced Properties tab.

h. Select the cluster instance for Site 2 (in this example, SQL Server (S2INST), and repeat the steps, but make the two SQL Server VMs in Site 2 the possible owners, and deselect the check boxes for the servers in Site 1.

We are now ready to create the database and configure an Always On availability group for the VMware Identity Manager database.

Create the VMware Identity Manager DatabaseIn this procedure, you create the database in Site 1 and make a backup. You also create the horizon login user.

To create the database and login user:

1. Log in to Microsoft SQL Server Management Studio as the sysadmin or as a user account with sysadmin privileges.

2. Connect to the SQL Server clustered instance in Site 1.

3. Follow the procedure provided in the product documentation to create a new saas database for VMware Identity Manager, along with a login user named horizon.

See the topic Configure a Microsoft SQL Database in the desired on-premises version of Installing and Configuring VMware Identity Manager. This topic provides a script with SQL commands you must run to create the database and login user.

Note: The default database name used in the script is saas. The default login user name is horizon. You can modify the script to use different names, but if you use a different name, write the name down.

4. After the database has been created, right-click the saas database (or, if you modified the database script to use a different name, select that name) and select Tasks > Back Up to create a full backup on Site 1, selecting the SQL_Backup disk (H drive) as the destination for the backup file.





5. In Site 1, use SQL Server Configuration Manager to set the default port for all IPs to 1433.

a. Under SQL Server Network Configuration, right-click Protocols for <Instance-name> in the left pane, and double-click TCP/IP in the right pane.

b. In the TCP/IP Properties dialog box, on the IP Addresses tab, scroll down to the IP All section.

c. Set TCP Port to 1433.

6. Use the Management Studio to export the horizon user credentials on Site 1 (or, if you modified the database script to use a different name, export that user’s credentials), as described in the Microsoft KB article How to transfer logins and passwords between instances of SQL Server.

Important: Use Method 2, which creates a login script with a blank password, and be sure to follow Step 3 of Method 2, which involves running the sp_help_revlogin statement. This step simplifies the process of keeping the SID for the horizon login the same when you create the login on any secondary nodes; otherwise user login association fails upon failover.

https://support.microsoft.com/en-us/kb/918992



7. In Site 2, use the Management Studio to create the horizon user, as described in Method 2 of the Microsoft KB article How to transfer logins and passwords between instances of SQL Server.

As described in the Microsoft documentation, you use the output script that the sp_help_revlogin stored procedure generates.

It is important to create the login before adding the saas database to the availability group (as described in the next procedure) because that information cannot otherwise be set correctly in the replica databases that are part of the availability group.

8. Create a new Windows file share that is accessible by each of the four SQL Servers.

Create and Configure the SQL Server Always On Availability Group for VMware Identity ManagerIn this procedure, you create an Always On availability group, add the SQL Server clustered instance from Site 1 as the primary replica and the instance from Site 2 as the secondary replica. You then configure some advanced parameters for the availability group listener.

To create the availability group:

1. In preparation for creating the availability group listener, choose a listener name and obtain a corresponding static IP address for Site 1 and a static IP for Site 2.

For example, in this reference architecture, the listener name is idm-agl, to designate VMware Identity Manager availability group listener.

2. In Site 1, in the Management Studio, right-click Always On High Availability in the left pane, and select New Availability Group Wizard.

3. Complete the New Availability Group wizard, using the following guidelines:

• Specify Name page – Use the name that you selected in Step 1.

• Select Databases page – Select the check box for the VMware Identity Manager database; for example, saas.


T E C H N I C A L W H I T E PA P E R | 1 0 0


• Specify Replicas > Replicas tab – The cluster instance from Site 1 should already be listed. Click Add Replica to connect to and add the cluster instance from Site 2.

• Specify Replicas > Backup Preferences tab – Select Any Replica. The two server instances are listed and they both have a backup priority of 50 (out of 100).

• Specify Replicas > Listener tab – Select Create an availability group listener, enter the listener name, set the port to 1433, and click Add to add the IP addresses of the two IP addresses you obtained in Step 1.



4. Select Data Synchronization page – Select Full.

The database is created on the secondary SQL Server failover cluster instance, in Site 2.

After you complete these pages, the Validation page, the Summary page, and the Results page take you through the process of creating the availability groups and listeners, and adding the replicas.

When the process is complete, you can view the new availability groups using the Management Studio.

5. In Microsoft SQL Management Studio, connect to both SQL Server cluster instances and expand the availability groups. You can see that the availability group (idm-ag) for Site 1 is the primary, as shown in the following figure.



The availability group for Site 2 is the secondary, as shown in the following figure, and the database synchronizes with the database in Site 1.



6. Open a PowerShell prompt and use the following PowerShell commands to configure advanced listener parameters.

a. Use the Get-ClusterResource and Get-ClusterParameter cmdlets to determine the name of the resource (idm-ag_idm-agl) and its settings, as shown in the following example.

b. Change the following settings:

– Use Set-ClusterParameter HostRecordTTL 120 to change HostRecordTTL to a lower value than the default in multi-site deployments. A generally recommended value is 120 seconds, or 2 minutes, rather than the default of 20 minutes. Changing this setting reduces the amount of time to connect to the correct IP address after a failover for legacy clients that cannot use the MultiSubnetFailover parameter.

– Use Set-ClusterParameter RegisterAllProvidersIP 0 to change RegisterAllProvidersIP to false in multi-site deployments. With this setting, the active IP address is registered in the Client Access Point in the WSFC cluster, reducing latency for legacy clients.



For instructions on how to configure these settings, see RegisterAllProvidersIP Setting and HostRecordTTL Setting. For sample scripts to configure the recommended settings, see Sample PowerShell Script to Disable RegisterAllProvidersIP and Reduce TTL.

c. Use stop-clusterresource and start-clusterresource to restart the idm-agl_idm-agl resource so that the new settings can take effect.

Now that the database is set up and the SQL Server Always On availability groups are configured, you can deploy and configure VMware Identity Manager to point to the Always On availability group for the database.

Deploy and Set Up VMware Identity Manager AppliancesThe VMware Identity Manager virtual appliance is a very standard VMware virtual appliance, with all the usual deployment wizard prompts. After deploying the virtual appliance, you point the appliance to the availability group listener you configured in the previous procedure. The VMware Identity Manager appliances reside in the DMZ within each site.

Important: As part of the following procedure, you will need to enter the fully qualified domain name (FQDN) of the global load balancer you are using. All administration tasks will be undertaken from the VMware Identity Manager administration console at the URL with this global FQDN (https://<global-LB-URL>/admin). You should also configure the local load balancer for Site 1. Before starting the procedure, complete the load balancer prerequisites:

https://msdn.microsoft.com/en-us/library/hh213080(v=sql.120).aspx#RegisterAllProvidersIP

https://msdn.microsoft.com/en-us/library/hh213080(v=sql.120).aspx#HostRecordTTL

https://msdn.microsoft.com/en-us/library/hh213080(v=sql.120).aspx#SampleScript

https://msdn.microsoft.com/en-us/library/hh213080(v=sql.120).aspx#SampleScript



• Verify that you have set up the local and global load balancers according to the vendor’s instructions, that the FQDN for each load balancer is configured in DNS, and that each load balancer server is assigned a static IP address.

• On the global load balancer, obtain and install an SSL certificate. You can use a wildcard certificate or a Subject Alternate Name (SAN) certificate. VMware recommends the use of SAN certificates so that you can define the node FQDNs (public or internal) within the load balanced VIP FQDN. If you use a SAN certificate, add the FQDNs of the following servers:

– Global load balancer

– Local load balancer for Site 1

– Local load balancer for Site 2

– The three VMware Identity Manager appliances in Site 1

– The three VMware Identity Manager appliances in Site 2

– The four VMware Identity Manager connectors (two in Site 1 and two in Site 2)

• On the local load balancer, install the SSL certificate described in the preceding bullet point. You will need to install the root certificate of this SSL certificate on the VMware Identity Manager appliance.

• Configure the load balancer settings to enable X-Forwarded-For headers, increase the request timeout, and enable sticky sessions. For more information, see the topic Load Balancer Settings to Configure in Installing and Configuring VMware Identity Manager.

• Add the FQDNs and IP addresses of three VMware Identity Manager appliances you plan to create for Site 1 to the local load balancer.

If you are using F5, see Load Balancing VMware Identity Manager. This document provides instructions for integrating VMware Identity Manager 2.9.1 nodes with the local load balancer. Also see Managing Horizon Traffic Across Multiple Data Centers with BIG-IP.

To set up VMware Identity Manager:

1. In vSphere Web Client, use the Deploy OVF Template wizard to deploy the VMware Identity Manager virtual appliance in Site 1.

Set a static IP address. See the topic Install the VMware Identity Manager OVA File in the on-premises version of Installing and Configuring VMware Identity Manager. For network port requirements, see Deploying VMware Identity Manager in the DMZ.

Note: In our example, the name of this first VMware Identity Manager appliance is s1-idm1.

2. After deployment is complete, log in to the VMware Identity Manager browser-based console and follow the prompts to complete the Appliance Setup wizard.

This involves entering the JDBC URL string and entering the credentials for the horizon database login user. The syntax of the JDBC URL is:

jdbc:sqlserver://<hostname-of-availability-group- listener>;DatabaseName=saas;multiSubnetFailover=true









Important: When deploying in a multi-subnet setup, be sure to add multiSubnetFailover=true as part of the JDBC connection string. This option enables faster failover. For more information, see the MultiSubnetFailover Keyword and Associated Features.

Note: When you test the connection, if you get a connection failed error, verify that you set the database port for all IP addresses to 1433, as described in Step 5 of Create the VMware Identity Manager Database.

For more information about the Appliance Setup wizard, see the topic Configure VMware Identity Manager Settings in the on-premises version of Installing and Configuring VMware Identity Manager.

3. When the Setup Complete page appears, click the link on the page to continue with other VMware Identity Manager configuration tasks.

https://msdn.microsoft.com/en-us/library/hh213080(v=sql.120).aspx#MultiSubnetFailover




4. Configure user attributes before changing any other configuration settings.

a. Under Identity & Access Management, click the Setup button on the right side of the screen, and choose Change User Attributes.

b. Select the userPrincipalName and distinguishedName attributes.

c. Add the objectGUID attribute.

For more information, see the topic Configure VMware Identity Manager Settings in the on-premises version of Installing and Configuring VMware Identity Manager.

5. Use the VMware Identity Manager console to install an SSL certificate and configure SSL for the appliance.

To offload SSL to your load balancer, see the vendor’s documentation for the load balancer.




For more information, see the topics Managing Appliance System Configuration Settings and Using SSL Certificates in the on-premises version of Installing and Configuring VMware Identity Manager.

Important: VMware recommends the use of certificates that support Subject Alternate Names (SANs). Ensure that the VMware Identity Manager certificate includes the FQDN of the load balancer from the primary data center, the FQDN of the load balancer from the secondary data center, and the FQDN of the global load balancer.

6. Obtain the root certificate for the local load balancer and install it, as described in Apply Load Balancer Root Certificate to VMware identity Manager, in Installing and Configuring VMware Identity Manager.

7. Configure the VMware Identity Manager FQDN by using the FQDN of the top-level, master load balancer server.

Important: You need a minimum of three VMware Identity Manager appliances in a cluster. We use a local load balancer virtual server for our pool of VMware Identity Managers in Site 1 (s1-idm). We use another local load balancer virtual server for our pool of VMware Identity Managers in Site 2 (s2-idm). We then use a global, master load balancer virtual server named identity, which is in place above s1-idm and s2-idm.

For more information about configuring the FQDN, see the topic Modifying the VMware Identity Manager Service URL in the on-premises version of Installing and Configuring VMware Identity Manager. As part of this procedure, after you change the FQDN to that of the global load balancer, you will enable the new portal UI.

8. Copy the root certificate of the VMware Identity Manager appliance to the local load balancer, as described in Apply VMware Identity Manager Root Certificate to the Load Balancer, in Installing and Configuring VMware Identity Manager.










Configure Failover and Redundancy for VMware Identity Manager You use the VMware Identity Manager appliance you just created to create additional appliances in both Site 1 and Site 2. After giving each appliance its own IP address and DNS name, you configure the built-in Elasticsearch and Ehcache clusters.

1. Clone the VMware Identity Manager appliance twice, to create two clones of the VMware Identity Manager appliance in Site 1, as described in Clone the Virtual Appliance, in Installing and Configuring VMware Identity Manager.

For our example, the original VMware Identity Manager appliance is named s1-idm1. The two clones for Site 1 are named s1-idm2 and s1-idm3.

2. Give the cloned appliances static IP addresses and verify that an Elasticsearch cluster is created, as described in Assign a New IP Address to Cloned Virtual Appliance, in Installing and Configuring VMware Identity Manager.

3. Configure Elasticsearch and Ehcache for replication, as described in Modify the Primary Data Center for Replication, in Installing and Configuring VMware Identity Manager.

4. Export the VMware Identity Manager appliance and use it to create a new cluster of three appliances in Site 2, as described in Create VMware Identity Manger Virtual Appliances in Secondary Data Center, in Installing and Configuring VMware Identity Manager.

5. Update the IP tables in Site 2, as described in Configure Nodes in Secondary Data Center, in Installing and Configuring VMware Identity Manager.

Deploy and Set Up the VMware Identity Manager Connectors Inside the Corporate NetworkAfter you set up the VMware Identity Manager virtual appliances inside the DMZ, you deploy four VMware Identity Manager Connectors inside the corporate network—two connectors in Site 1 and two connectors in Site 2. The connectors use a built-in identity provider rather than a load balancer. The connectors sync users and groups from your enterprise directory to the VMware Identity Manager Service.

1. In preparation for establishing a connection to VMware Identity Manager Connectors, navigate to the global load balancer URL (https://<global-LB-URL>/admin), log in to the VMware Identity Manager administrative console, and generate an activation code for the two connectors you will create, using the connector names s1-idmconn1 and s1-idmconn2.

For instructions on generating the activation code, see the topic Generate Activation Code for Connector in Deploying VMware Identity Manager in the DMZ.












2. Deploy two VMware Identity Manager Connectors in Site 1.

• When you complete the Deployment wizard for each connector, you will enter the connector name you used in Step 1.

• When you complete the Setup wizard for each connector, you will enter the activation code you generated in Step 1.

The Identity Manager Connectors run inside your trusted enterprise network. For instructions, see the topic Install and Configure the Connector Virtual Appliance in Deploying VMware Identity Manager in the DMZ.

3. (Optional) To replace the SSL certificate for the VMware Identity Manager Connector, go to this URL: https://<FQDN>:8443/cfg/ssl.





4. In Site 1, use the VMware Identity Manager administration console (at the global load balancer URL) to add a directory.

a. Click the link on the Setup is Complete page, which is displayed after you activate the connector.

b. On the Identity & Access Management > Directories tab, click Add Directory and select the type of directory you want to add.

c. Follow the wizard prompts, and add the first connector (s1-idmconn1) as your Sync Connector.

Adding a directory allows VMware Identity Manager to sync users and groups from your enterprise directory to the VMware Identity Manager Service. For more information, see the topic Integrating with Your Enterprise Directory in Installing and Configuring VMware Identity Manager.

Note: After you complete all the steps in this procedure, you will have four connectors—two in Site 1 and two in Site 2—and the sync connector will be the s1-idmconn1 connector in Site 1. If the s1-idmconn1 connector ever becomes unavailable, you will need to select a different connector as the sync connector. If Site 1 has a failure event, you will need to select a connector in Site 2. For more information, see the topic Enabling Directory Sync on Another Connector in the Event of a Failure in Deploying VMware Identity Manager in the DMZ.





5. Enable the connectors to operate in outbound-only connection mode.

a. In Site 1, enable outbound mode for the s1-idmconn1 connector, as described in the topic Enable Outbound Mode for the Connector in Deploying VMware Identity Manager in the DMZ.

b. In Site 1, add the s1-idmconn2 connector to the built-in identity provider that you created in the previous step.

For instructions, see the topic Add New Connector to Built-in Identity Provider in Deploying VMware Identity Manager in the DMZ.

6. In Site 2, just as you did for Site 1, navigate to the global load balancer URL (https://<global-LB-URL>/admin), log in to the VMware Identity Manager administrative console, and generate an activation code for the two connectors you will create in Site 2, using the connector names s2-idmconn1 and s2-idmconn2.

Important: You must use the VMware Identity Manager administration console at the global load balancer URL to generate this activation code. Otherwise, communication cannot be established between the connector and the service that end users need to use.

7. Deploy two VMware Identity Manager Connectors in Site 2.

• When you complete the Deployment wizard for each connector, you will enter the connector name you used in Step 6.

• When you complete the Setup wizard for each connector, you will enter the activation code you generated in Step 6.

8. (Optional) To replace the SSL certificate for the VMware Identity Manager Connector, go to this URL: https://<FQDN>:8443/cfg/ssl.

9. In Site 2, use the VMware Identity Manager administration console to add a directory.

a. Click the link on the Setup is Complete page, which is displayed after you activate the connector.

b. On the Identity & Access Management > Directories tab, click Add Directory and select the type of directory you want to add.

c. Follow the wizard prompts, and add the s1-idmconn1 connector as your Sync Connector.






10. In Site 2, add the s2-idmconn1 and s2-idmconn2 connectors to the built-in identity provider that you created previously.

You now have four connectors, with the s1-idmconn1 connector used for synching users and groups.

At this point, we have

• 3 VMware Identity Manager appliances for Site 1: s1-idm1, s1-idm2, s1-idm3

• 1 load balancer virtual server for site 1: s1-idm

• 2 VMware Identity Manager Connectors for Site 1: s1-idmconn1, s1-idmconn2

• 3 VMware Identity Manager appliances for Site 2: s2-idm1, s2-idm2, s2-idm3

• 1 load balancer virtual server for site 2: s2-idm

• 2 VMware Identity Manager Connectors for Site 2: s2-idmconn1, s2-idmconn2

• 1 master load balancer virtual server: identity

Finalizing Failover PreparationTo complete the setup, follow the instructions provided in the following topics from Installing and Configuring VMware Identity Manager:

• Configure Failover Order of Horizon View and Citrix-based Resources

• Clear Cache in Secondary Data Center





Appendix H: Setting Up VMware App Volumes for High Availability in Multiple SitesThis design uses separate App Volumes database instances for each site, rather than using a clustered database across sites. With this option, you still use Always On availability groups, but each site has its own availability group to achieve automatic failover within a site. To make user-based entitlements for AppStacks available between sites, you must use a PowerShell script, which VMware provides. This setup is shown in the following figure.


Storage Group #2

Datastore 3

SQLDatabase

SQLDatabase


Non-AttachableStorage Group #1

vSphere Hosts

vSphere Hosts

Site 2Site 1


Figure 45: App Volumes Multi-Site Using Separate Databases

To use this setup, perform the procedures in this appendix in the following order:

1. Create a Windows Server Failover Cluster in Each Site

2. Install SQL Server 2014 Stand-Alone in All VMs

3. Create the App Volumes Databases and Enable Availability Groups for the Clusters

4. Create Always On Availability Groups for App Volumes Databases

5. Configure Cluster Quorum Settings

6. Install App Volumes to Use a Highly Available Database



Create a Windows Server Failover Cluster in Each SiteA failover cluster is a group of VMs that have the same software installed on them and work together as one instance to provide high availability for a service, such as a Microsoft SQL Server database. If a VM, or cluster node, in the cluster fails, another node in the cluster begins to provide the service.

Note: For information about setting up F5 load balancers for use with App Volumes, see F5 with App Volumes Configuration Guide. If you are using another type of load balancer, verify that you have set up this load balancer according to the vendor’s instructions.

To create a Windows Server Failover Clustering (WSFC) cluster:

1. On two ESXi hosts in Site 1, create and configure the two VMs that will be used as a clustered instance of Microsoft SQL Server, and then do the same in Site 2.

• For this reference architecture, we used the Windows Server 2012 R2 Standard operating system in the VMs that run SQL Server.

• In this example, we named the VMs as follows: At Site 1, we created VMs named s1-sql4 and s1-sql5 on separate ESXi hosts. At Site 2, we created VMs named s2-sql4 and s2-sql5.

• Set up each VM in the same way, with a total of five 20-GB hard disks: one disk for the Windows OS and five disks for the various types of SQL Server data.





Inside the OS, the disks are mapped to drive letters as follows.

2. In preparation for creating the failover cluster, choose a cluster name and obtain a corresponding static IP address for the cluster in Site 1 and in Site 2.

For example, in this reference architecture, for the cluster names, we use s1-sqlclust-2 and s2-sqlclust-2.

3. To set up failover clustering on the SQL Server VMs, user Server Manager on each of the four VMs (two in Site 1 and two in Site 2), and use the Windows Server Add Roles and Features Wizard to add the Failover Clustering feature.

In the wizard, select to add the following features:

• .NET Framework 3.5 features

• Failover Clustering, including adding the Failover Clustering tools

For detailed instructions, see the Microsoft blog post Installing the Failover Cluster Feature and Tools in Windows Server 2012. One of the tools installed is the Failover Cluster Manager, which you will use for many of the steps that follow.





4. Use the Failover Cluster Manager to create a WSFC cluster that includes two SQL Server VMs in Site 1, and then do the same in Site 2.

For detailed instructions, see the Microsoft blog post Creating a Windows Server 2012 Failover Cluster, and see Create a Failover Cluster. The failover cluster for Site 1 includes the VMs s1-sql4 and s1-sql5. The cluster for Site 2 includes the VMs s2-sql4 and s2-sql5.

https://blogs.msdn.microsoft.com/clustering/2012/05/01/creating-a-windows-server-2012-failover-cluster/

https://blogs.msdn.microsoft.com/clustering/2012/05/01/creating-a-windows-server-2012-failover-cluster/

https://technet.microsoft.com/en-us/library/dn505754(v=ws.11).aspx



Install SQL Server 2014 Stand-Alone in All VMsYou install SQL Server Stand-Alone on each VM, rather than creating a SQL Server failover cluster, as you do for VMware Identity Manager. For App Volumes, you use stand-alone installations and then create Always On availability groups to achieve failover within a site.

To install SQL Server:

1. In Site 1, on the first SQL Server VM, complete the SQL Server installation wizard, using the following guidelines:

• Installation page – Select New SQL Server stand-alone installation.

• Feature Selection page – Select Database Engine Services and Management Tools - Basic.

• Instance Configuration page – Select Default instance. The instance ID is MSSQLSERVER.

• Server Configuration page – The startup type is Automatic for the SQL Server Agent and SQL Server Database Engine.

• Database Engine Configuration page– On the Server Configuration tab, select Mixed Mode (SQL Server authentication and Windows authentication), and enter credentials for a user account that will be part of the SQL Server administrators. On the Data Directories tab, for each item, select the disk that you created for that type of file during VM creation. Use the following screen shot as a guide.

For more information about the setup wizard, see Install SQL Server 2014 from the Installation Wizard (Setup).

2. Repeat Step 1 to install SQL Server on the other VM in Site 1 and on the VMs in Site 2.

https://msdn.microsoft.com/en-us/library/ms143219(v=sql.120).aspx

https://msdn.microsoft.com/en-us/library/ms143219(v=sql.120).aspx



3. Create a shared folder on the first SQL Server VM in each site; for this example, the VMs are s1-sql4 and s2-sql4).

a. Create a folder named Replication on the SQL_Binaries (E:) drive. You created this drive during Step 1 of Create a Windows Server Failover Cluster.

b. Give the SQL service account full permissions on the folder.



Create the App Volumes Databases and Enable Availability Groups for the ClustersThis document provides detailed instructions for creating a highly available database but does not give recommendations regarding the sizing of the database for various sizes of deployments. For information about database sizing, see VMware App Volumes 2.x Database Best Practices.

To create the databases:

1. On first SQL Server VM in each site, use Microsoft SQL Server Management Studio to create an App Volumes database.

For this example, the VMs are s1-sql4 and s2-sql4.

a. Log in to the Management Studio as the sysadmin or as a user account with sysadmin privileges.

b. Connect to the SQL Server instance on the VM, right-click the Databases folder, and select New Database.

c. Enter a database name and click OK.

For example, for Site 1, we named the database s1-appvolumes. For Site 2, we named the database s2-appvolumes.

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-app-volumes-database-best-practices.pdf



2. Open SQL Server Configuration Manager and enable Always On availability groups for the Windows Failover cluster in Site 1 and Site 2.

For instructions, see Enable and Disable AlwaysOn Availability Groups (SQL Server).

The cluster names are the names you created in Step 2 of Create a Windows Server Failover Cluster.

3. In each site, on the domain controller, open Active Directory Users and Groups, and create a new Computer object for the availability group.

For this example, for Site 1, the AD computer name for the group is s1-sqlclust2-ag1. For Site 2, the name is s2-sqlclust2-ag1.




Create Always On Availability Groups for App Volumes DatabasesIn this procedure, you create an Always On availability group, adding the SQL Server stand-alone instances from Site 1 as the primary replica and secondary replicas. You then do the same for Site 2, so that each site has its own Always On availability group to achieve automatic failover within each site (but not across sites).

To create the availability groups:

1. On the first SQL Server VM in Site 1, open the Management Studio, right-click Always On High Availability in the left pane, and select New Availability Group Wizard.

2. Complete the New Availability Group wizard, using the following guidelines:

• Specify Name page – Use the name of the AD computer object you just created. For this example, the name is s1-sqlclust2-ag1 for Site 1.

• Select Databases page – Select the check box for the local database, which is s1-appvolumes in this example.

• Specify Replicas > Replicas tab – The first SQL Server VM should already be listed. Click Add Replica to connect to and add the second SQL Server VM from this site.

Important: Select the Synchronous Commit and Automatic Failover check boxes. For the Readable Secondary setting, select No for the primary instance and Yes for the secondary instance.



3. Select Data Synchronization page – Select Full, and specify the shared Replication folder that you created in Step 3 of Install SQL Server 2014 Stand-Alone.

This share is used to synchronize the database on the secondary replica with that on the primary.

After you complete these pages, the Validation page, the Summary page, and the Results page take you through the process of creating the availability groups and listeners, and adding the replicas. On the Results page, you can see that the s1-appvolumes database is synchronized between both SQL servers.



When the process is complete, you can view the new availability groups using the Management Studio. The following screen shot shows the availability group with the primary replica on the s1-sql4 VM.



The following screen shot shows the availability group with the secondary replica on the s1-sql5 VM.

3. Repeat Steps 1 and 2 for Site 2.



Configure Cluster Quorum SettingsAt this point, you will configure cluster quorum settings to use a file share witness. Each element in a cluster can cast one “vote” to determine whether the cluster can run. Because you have two nodes in a cluster and you need an odd number of voting elements, create a file share quorum witness, which will caste the third vote. A file share witness is recommended when you need to consider multi-site disaster recovery with replicated storage.

To configure cluster quorum settings:

1. On a file server in each site, use Server Manager to open and complete the New Share wizard and create an SMB share, using the following guidelines:

• Select Profile page – Select SMB Share – Quick.

• Share Location page – For the share location, select Select by volume, and select the drive.



• Permissions page – Click Customize permissions and give the WSFC cluster object full control over the file share.

When you finish this step, you have two files shares: one for Site 1 and one for Site 2. For more details about accessing and using this wizard, see 12 Steps to NTFS Shared Folders in Windows Server 2012.

2. Configure the cluster quorum settings for each site:

a. Open Failover Cluster Manager on the first VM in Site 1, right-click the cluster, and select More Actions > Configure Cluster Quorum Settings.

https://blogs.technet.microsoft.com/keithmayer/2012/10/21/12-steps-to-ntfs-shared-folders-in-windows-server-2012/

https://blogs.technet.microsoft.com/keithmayer/2012/10/21/12-steps-to-ntfs-shared-folders-in-windows-server-2012/




• Select Quorum Configuration Option page – Select Select the quorum witness.

• Select Quorum Witness page – Select Configure a file share witness.

• Configure File Share Witness page – Enter the path to the file share you created in Step 1.

For detailed instructions, see Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster.

c. Repeat this procedure to set up a file share quorum witness in Site 2.

You are now ready to install App Volumes and point to the availability group we created.





Install App Volumes to Use a Highly Available DatabaseThis procedure focuses on the specific settings required for connecting App Volumes to a highly available database. For details about other aspects of App Volumes installation, including system requirements, see the VMware App Volumes User Guide.

To install App Volumes:

1. In preparation for installing App Volumes and connecting to the availability group listener, use SQL Server Configuration Manager on each SQL Server VM to enable named pipes.

For instructions, see Enable or Disable a Server Network Protocol.

Important: Restart the SQL Server service so the new setting can take effect.

2. In Site 1, on the first VM on which you want to install App Volumes, download the App Volumes Manager installer, start the installation wizard, and follow the prompts to the Database Server page.

3. Complete the Database Server page, using the following guidelines:

• Choose local or remote database server to use – Select the SQL Server Always On availability group listener that you created in Create Always On Availability Groups for App Volumes Databases.

• Name of database catalog to use or create – Select the database that you created in Create the App Volumes Databases and Enable Availability Groups for the Clusters.





Important: If you see an error message such as the following one, it means you need to enable named pipes, as described in Step 1.

4. On the Choose Network Ports page, verify that the HTTP port is set to 80 and the HTTPS port is set to 443.

5. Follow the rest of the wizard prompts to complete the installation.

6. Repeat Steps 1–5 on the second App Volumes VM in Site 1, but on the Database Server page, be sure to leave the Overwrite existing database (if any) check box deselected.

Both App Volumes Managers in Site 1 must point to the same highly available database.

7. Repeat this entire procedure in Site 2.

With App Volumes successfully installed, you can begin configuration. For detailed instructions see the VMware App Volumes User Guide. Also see the VMware App Volumes Reference Architecture.

The procedures in this appendix create a setup in which the App Volumes database can failover automatically within each site. Site 1 and Site 2 have separate databases, but during a failover, users for Site 1 will be able to use replicated App Volumes AppStacks in Site 2 as long as the user entitlements are also replicated. For configuration details, see Appendix F: PowerShell Script for Replicating App Volumes Application Entitlements.


https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-app-volumes-reference-architecture.pdf



Appendix I: Configuration Procedures for a Clustered App Volumes DatabaseThis configuration uses a clustered SQL database that is common across Site 1 and Site 2. Database failover is needed if the primary instance fails, as described in Perform a Forced Manual Failover of an Availability Group (SQL Server).

Note: Because most of the procedures for creating a clustered database for App Volumes are so similar to those for the VMware Identity Manager clustered database, the links in Steps 1, 2, 3, and 5 in the following list go to procedures in the VMware Identity Manager appendix. For App Volumes, the only change you need to make is to give items names that are appropriate for App Volumes, as described in the following steps.

To create a clustered highly available App Volumes database:

1. Follow the instructions for Create a Windows Server Failover Cluster and Configure Shared Storage.

Note: When creating a file share to use as the quorum witness, if you did this procedure for VMware Identity Manager, then create a different file share, with a different name, for App Volumes.

2. Follow the instructions for Install the SQL Server Failover Cluster.

Note: When creating the SQL Server failover cluster instances (FCIs), if you did this procedure for VMware Identity Manager, then use different instance names for the App Volumes SQL Server FCIs.

3. Follow the instructions for Configure Cluster Quorum Settings and Possible Owners for Each Cluster Instance.

4. Follow the instructions for Create the App Volumes Clustered Database Using Backup and Restore.

5. Follow the instructions for Create and Configure the SQL Server Always On Availability Group for VMware Identity Manager.

Note: When creating an availability group listener (AGL), use a different AGL name; for example, use avm-agl, and point to the App Volumes database rather than the VMware Identity Manger database.

6. Follow the instructions for Install and Configure App Volumes Manager.

After you perform the tasks listed in the first three steps—by clicking the links in those steps to go to the correct sections—you can continue to the next section in this appendix, Create the App Volumes Clustered Database Using Backup and Restore.





Create the App Volumes Clustered Database Using Backup and RestoreIn this procedure, you create the database in Site 1, make a backup, and then create the database in Site 2 by restoring from the backup you created in Site 1.

Note: This procedure is the fourth task in the configuration procedures listed at the beginning of this appendix. Be sure you complete the tasks for creating a WSFC cluster, SQL Server failover cluster instance (FCI), and cluster quorum before completing creating the database using the following procedure.

To create the databases in both sites:

1. Log in to Microsoft SQL Server Management Studio as the sysadmin or as a user account with sysadmin privileges.

2. Connect to the SQL Server FCI in Site 1.

3. Use SQL Server Management Studio to create a new database named app_volumes.

• Base the login on Windows Authentication pointing to the computer accounts of all the App Volumes Managers by specifying the name of the computer followed by a $ (for example, DOMAIN\AVM-01$).

• Associate that login with the app_volumes database as well as the db_owner user mapping. This ensures that all App Volume Managers can authenticate using their computer account and that they all have dbo mappings to the database. This document does not give recommendations regarding the sizing of the database for various sizes of deployments. For information about database sizing, see VMware App Volumes 2.x Database Best Practices.

4. After the database has been created, right-click the app_volumes database and select Tasks > Back Up to create a full backup on Site 1, selecting the SQL_Backup disk (H drive) as the destination for the backup file.


a. Under SQL Server Network Configuration, right-click Protocols for <Instance-name> in the left pane, and double-click TCP/IP in the right pane.

b. In the TCP/IP Properties dialog box, on the IP Addresses tab, scroll down to the IP All section.

c. Set TCP Port to 1433.

7. In Site 2, restore the database from the backup file you created in Step 3.

• On the General page, select Device and browse to and select the database backup file you created from Site 1 in Step 4 of this procedure.

• On the Options page, for Recovery state, select RESTORE WITH NORECOVERY.


9. Follow the instructions for Create and Configure the SQL Server Always On Availability Group for VMware Identity Manager.

Note: When creating an availability group listener (AGL), use a different AGL; for example, use avm-agl, and point to the App Volumes database rather than the VMware Identity Manger database.





Install and Configure App Volumes ManagerIf you have completed the preceding procedures in this appendix, you now have an availability group listener to point to when you install the App Volumes Managers in each site. Perform the following tasks in the specified order:

1. Install the first App Volumes Manager in the primary site where the primary SQL node is running using the availability group listener FQDN when configuring the ODBC connection.

2. Complete the App Volumes Manager wizard and add vCenter Servers from both Site 1 and Site 2, including mapping their corresponding datastores.

3. After machine manager access has been verified from Step 2, continue with installing the second manager in the same site as the first manager.

You can use a global namespace for the App Volumes Manager service between sites, but this is not a requirement. This model adds some complexity because the load balancer is responsible for making sure that desktops in Site 1 are connected to the App Volumes Manager in Site 1 and desktops in Site 2 are connected to the App Volumes Manager in Site 2. The benefit in doing this is in not having to maintain two different configurations in the desktop master image in terms of which FQDN the App Volumes Agent is pointing to. Keep in mind that using separate namespaces is equally valid.



Additional ResourcesVMware documentation:

• VMware Identity Manager 2.x Documentation Center

• VMware Horizon 7 Documentation Center

• VMware vSphere 6.0 Documentation Center

• VMware Horizon 7 Enterprise Edition Reference Architecture

• VMware App Volumes 2.x Database Best Practices

Microsoft articles:

• Microsoft Cluster Services (MSCS)

• MSCS Cluster Support KB – When using 2012 R2 and you have moved your cluster nodes from the default Computer container

• vSphere 6.0 MSCS configuration and support guidance

Microsoft distributed file system:

• Distributed File System Namespace (DFSN) and Distributed File System Replication (DFSR) Best practice guidance

• Microsoft support statement in terms of DFSN/DFSR and profile/user data

• Namespace hosting and data placement

• Read-Only replication

General:

Defining GPO security settings for IE trusted zones with VMware Identity Manager

F5 technical articles:

• Load Balancing VMware Identity Manager

• Load Balancing App Volumes Manager instances

http://pubs.vmware.com/identity-manager-27/index.jsp

http://pubs.vmware.com/horizon-7-view/index.jsp

http://pubs.vmware.com/vsphere-60/index.jsp



https://blogs.technet.microsoft.com/askpfeplat/2014/11/17/when-creating-a-new-resource-or-role-in-windows-server-2012-r2-failover-cluster-the-network-name-fails-to-come-online-or-failed-to-create-associated-computer-object-in-domain/

https://blogs.technet.microsoft.com/askpfeplat/2014/11/17/when-creating-a-new-resource-or-role-in-windows-server-2012-r2-failover-cluster-the-network-name-fails-to-come-online-or-failed-to-create-associated-computer-object-in-domain/

http://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-setup-mscs.pdf

https://blogs.technet.microsoft.com/askds/2012/07/24/common-dfsn-configuration-mistakes-and-oversights/

https://blogs.technet.microsoft.com/askds/2012/07/24/common-dfsn-configuration-mistakes-and-oversights/


https://blogs.technet.microsoft.com/askds/2011/04/19/dfsn-and-dfsr-ro-interoperability-when-good-dfs-roots-go-bad/

https://blogs.technet.microsoft.com/askds/2010/03/08/read-only-replication-in-r2/

https://blog.thesysadmins.co.uk/group-policy-internet-explorer-security-zones.html





About the Authors Graeme Gordon is a Senior Staff End-User-Computing (EUC) Architect in End-User-Computing Technical Marketing, VMware.

Donal Geary is a Reference Architect Engineer in End-User-Computing Technical Marketing, VMware.

Caroline Arakelian is a Senior Technical Marketing Manager, End-User-Computing Technical Marketing, VMware.

Jim Yanik is a Senior Manager, End-User-Computing Technical Marketing, VMware.

Rasmus Jensen co-authored the original version of this white paper. Rasmus is now a Lead Systems Engineer, End-User-Computing Technical Marketing, VMware.

Matt Coppinger co-authored the original version of this white paper. Matt is the Director of Technical Marketing and Enablement, End-User Computing, VMware.

To comment on this paper, contact VMware End-User-Computing Technical Marketing at [email protected].

mailto:euc_tech_content_feedback%40vmware.com?subject=

VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.comCopyright © 2017 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. Item No: VMW-TWP-HOR7ENTEDMSREFARCH-USLTR-20171116-WEB 11/17

Documents

VMware Horizon 7 Enterprise Edition Multi-Site Reference ...euc-kiwi.com/wp-content/uploads/2017/11/vmware... · VMWARE HORIZON 7 ENTERPRISE EDITION MULTI-SITE REFERENCE ARCHITECTURE