VMware Hands-on Labs - HOL-1851-08-ADV


Lab Overview - HOL-1851-08-ADV - Horizon 7.1 Advanced: Architectural Concepts

Lab Overview



 

Lab Overview

Note: It will take more than 90 minutes to complete this lab. You should expect to only finish 2-3 of the modules during your time.  The modules are independent of each other so you can start at the beginning of any module and proceed from there. You can use the Table of Contents to access any module of your choosing.

The Table of Contents can be accessed in the upper right-hand corner of the Lab Manual.

This lab introduces the common architecctural concepts and considerations used to design a robust Horizon environment.  You will learn the architectural concepts used to design multi-site implementations, large scale implementations, and provide a robust end-user experience.

Lab Module List:

 Lab Captains:

 

This lab manual can be downloaded from the Hands-on Labs Document site found here:

http://docs.hol.vmware.com

This lab may be available in other languages.  To set your language preference and have a localized manual deployed with your lab, you may utilize this document to help guide you through the process:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf

 

 

Location of the Main Console

 

  1. The area in the RED box contains the Main Console.  The Lab Manual is on the tab to the Right of the Main Console.
  2. A particular lab may have additional consoles found on separate tabs in the upper left. You will be directed to open another specific console if needed.
  3. Your lab starts with 90 minutes on the timer.  The lab can not be saved.  All your work must be done during the lab session.  But you can click the EXTEND to increase your time.  If you are at a VMware event, you can extend your lab time twice, for up to 30 minutes.  Each click gives you an additional 15 minutes.  Outside of VMware events, you can extend your lab time up to 9 hours and 30 minutes. Each click gives you an additional hour.

 

 

Alternate Methods of Keyboard Data Entry

During this module, you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data which make it easier to enter complex data.

 

 

Click and Drag Lab Manual Content Into Console Active Window

You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console.  

 

 

Accessing the Online International Keyboard

 

You can also use the Online International Keyboard found in the Main Console.

  1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar.

 

 

Activation Prompt or Watermark

 

When you first start your lab, you may notice a watermark on the desktop indicating that Windows is not activated.  

One of the major benefits of virtualization is that virtual machines can be moved and run on any platform.  The Hands-on Labs utilizes this benefit and we are able to run the labs out of multiple datacenters.  However, these datacenters may not have identical processors, which triggers a Microsoft activation check through the Internet.

Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft licensing requirements.  The lab that you are using is a self-contained pod and does not have full access to the Internet, which is required for Windows to verify the activation.  Without full access to the Internet, this automated process fails and you see this watermark.

This cosmetic issue has no effect on your lab.  

 

 

Look at the lower right portion of the screen

 

Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes your lab has not changed to "Ready", please ask for assistance.

 

Module 1 - Horizon Cloud Pod Architecture (45 minutes)

Introduction to Cloud Pod Architecture



 

Introduction to Cloud Pod Architecture

Enabling the Horizon Cloud Pod feature allows multiple Horizon pods to provide resource access across multiple locations and very large scale implementations seamlessly to the user. You will learn about the fundamental components and walk through the implementation and resource entitlement of Horizon Cloud Pod Architecture.

This module contains the following lessons:

 

 

Horizon Cloud Pod Architecture

 

A key feature of the Horizon Cloud Pod Architecture is the ability to provide high availability and to scale-out virtual desktops in VMware Horizon 7.

Virtual desktops provided by Horizon are deployed using a block and pod design. (Refer to the View Architecture Planning Guide sections titled View Building Blocks and View Pods) A single View pod can contain up to five View blocks which in turn can provide up to 10,000 (10K) desktops at a single data center. Customers looking to scale beyond 10K desktops can deploy multiple View pods,  however each View pod is an independent entity with its own user entitlements and is managed separately. Using Horizon Cloud Pod Architecture, customers are able to aggregate multiple Horizon pods within the same or across multiple data centers.  A global entitlement allows user access to resources across multiple pods.  

Now, let's look at an example that describes this feature in its entirety. Figure 1 shows two View pods: Pod 1 and Pod 2. Pod 1 is located in a data center in the United States and Pod 2 is located in a data center in India. Each pod has two connection brokers: Pod 1 contains VCS1 and VCS2.  Pod 2 contains VCS3 and VCS4.  Pod 1 and Pod 2 maintain independent user entitlements to map end users to a virtual desktop within their respective pod.  With Cloud Pod Architecture, two new elements are introduced to provide user entitlements between pods:

This architecture provides three major benefits

 

 

Brokering a Desktop in a Cloud Pod Architecture

The previous example conceptually illustrates how two View pods can be used to entitle users to desktops from different data centers.

Brokering a desktop to a user who logs in from any location follows this workflow:

  1. The user enters the URL or IP address for their View environment.
  2. The broker (View Connection Server) looks up both the local and global entitlements for the user.
  3. The broker gets the current desktop state via the inter-pod protocol and returns a list of desktops to the client.
  4. The user selects a desktop.
  5. If the desktop is remote, the broker launches the remote desktop via the inter-pod protocol.
  6. The client connects to the remote desktop directly or through a local tunnel.

The top use cases for global end-user desktop access are:

 

 

Global Entitlement

 

The global entitlement layer controls the mapping of end users to desktops in a Cloud Pod Architecture. Global entitlement consists of a set of parameters as shown in Figure 2:

The various parameters of global entitlement:

The scope can be one of:

The search order favors local resources in the same pod that the user connected to, then extending to the same site, and then across the entire linked environment. In addition to the default search order, administrators can nominate a home site for a single or group of users. When a global entitlement has the FromHome policy set, the search for a new desktop starts from the users home site and not the current connected pod. This ensures that the user desktop session remains close to any required back end resources.

 

 

Scale Limits, Maximums, and Architectural Assumptions

Scale Limits and Maximums

The Cloud Pod Architecture was developed with the goal of scaling Horizon 7.1 desktop deployments to hundreds of data centers and tens of thousands of desktops. This capability is validated based on the following scale-out parameters:

Architectural Assumptions

A number of architectural assumptions have been made in delivering this feature:

 

 

Lesson Summary

You have learned about the components of Cloud Pod Architecture.

The following lessons in this module will teach you more about Cloud Pod Architecture.

 

Configure Cloud Pod Architecture



 

Configure Cloud Pod Architecture

In this lesson, you will review and modify a cloud pod configuration.

 

 

 

Access VMware Horizon Administrator Console for Pod A

 

  1. From the MainConsole desktop, open the Chrome web browser
  2. Click on the 'View-01A Admin' quick link or navigate to https://view-01a.corp.local/admin
  3. Log in as corp\administrator   password: VMware1!

 

 

 

Navigate to View Configuration

 

  1. Expand View Configuration
  2. Select Cloud Pod Architecture

 

 

Notice that the Pod Federation is already configured and has the name "CORP Horizon Cloud Pod Federation."

 

 

 

Initialize Cloud Pod Architecture

 

For the purposes of this lab, you do not need to initialize the Cloud Pod Architecture because it is already initialized and pre-configured.  

When configuring the Cloud Pod feature for the first time, you would enable the feature by clicking on the Initialize task as shown in the image.

 

 

Edit the Site Name

After the initialization is complete, an option called Sites will appear in the navigation tree on the left. We will rename the site to a more descriptive name.

 

  1. Navigate to View Configuration
  2. Select Sites
  3. Highlight the site named: CORP CPA
  4. Click Edit

 

 

Rename the Site

 

  1. Change the name to Las Vegas
  2. Click OK

 

 

Access VMware Horizon Administrator Console for Pod B

 

  1. From the MainConsole desktop, open the Chrome web browser
  2. Click on the 'View-02A Admin' quick link or navigate to https://view-02a.corp.local/admin
  3. Log in as corp\administrator  Password: VMware1!

 

 

Navigate to View Configuration

 

  1. Expand View Configuration
  2. Select Cloud Pod Architecture

 

Notice that this Pod is already a member of the "CORP Horizon Cloud Pod Federation"

 

 

Join an Existing Pod Federation

 

For the purposes of this lab, you do not need to join the pod federation because it is already a member.

When joining a pod to the federation for the first time, you would click on the Join task as shown in the image.

 

 

Add a New Site to the Federation

 

When Pod B is joined to the federation,  it is automatically placed in the first site (Las Vegas) that was created when we initialized Cloud Pod Architecture. To put pod B in it's own site, we must first create a new Site object.

  1. Navigate to View Configuration
  2. Select Sites
  3. Click Add
  4. Name the new site "Barcelona"
  5. Click OK

 

 

Move Pod B to the New Site

 

  1. Select the first site by clicking on Las Vegas - Notice that both pods are listed in the Las Vegas site
  2. Select Pod B (Cluster-View-02A) from the list
  3. Click Edit

 

 

Edit Pod

 

  1. From the Site list, select Barcelona
  2. Click OK

We now have two separate sites each containing one pod.

 

 

Lesson Summary

You have completed this lesson and have configured Horizon Cloud Pod Architecture, added two independent Pods to the federation, and defined two sites.

The following lessons in this module will teach you more about Cloud Pod Architecture.

 

 

Configure Global Entitlements



 

Configure Global Entitlements

In this lesson, you will work with global entitlements to allow desktop resources to be accessible between Pods.

 

 

View the Pod A Desktop Entitlements

You will log in to each Pod to determine what local desktop resources you are able to access before configuring a global entitlement.

 

Launch the VMware Horizon Client from the Main Console desktop.

 

 

Double-click on the View-01a.corp.local icon to connect to Pod A.

 

 

Log in to view-01a.

  1. User name: lab1user
  2. Password: VMware1!

 

 

  1. Note that you have access to the Windows 10 Instant Clone desktops in Pod A - It is not necessary to launch the desktop for this step.
  2. Close the VMware Horizon Client Window

 

 

View the Pod B Desktop Entitlements

 

  1. Launch the VMware Horizon Client from the Main Console desktop.
  2. Double-click on the View-02a.corp.local icon to connect to Pod B.

 

Log in to view-02a.

  1. User name: lab1user
  2. Password: VMware1!

 

 

Note that you do not have access to any desktop pools in Pod B.

 

You have confirmed that you have:

 

 

 

Access VMware Horizon Administrator Console for Pod A

 

  1. From the Main Console desktop, launch the Chrome web browser
  2. Click on the'View-01A Admin' quick link or navigate to https://view-01a.corp.local/admin
  3. Log in as corp\administrator

 

 

Add a Global Entitlement

 

  1. Navigate to Catalog
  2. Select Global Entitlements
  3. Click Add

 

 

Select the Entitlement Type

 

  1. Choose Desktop Entitlement
  2. Click Next

 

 

Configure Global Entitlement Policies

 

Configure the following details for the Global Entitlement:

1.  Name: Desktops_Anywhere

2.  User Assignment: Floating

3.  Scope: All Sites

Specifies where to look for desktops that satisfy a desktop request from the global entitlement. You can select only one scope policy.

4.  Use Home Site: Not Selected

Causes View to search for desktops to start at the users defined home site location. If the user does not have a home site defined, the site to which the user is currently connected is assumed to be the home site.

Entitled Users must have home site:  The global entitlement will be available only if the user has a home site.

5.  Automatically clean up redundant sessions: Not Selected

Logs off extra user sessions for the same entitlement. This option is available only for floating desktop entitlements.

Multiple sessions can occur when a pod hosting a user session becomes inaccessible and the user logs in again and starts another session.  When the inaccessible pod becomes available, the users original session is still active. When multiple sessions occur, the Horizon Client prompts the user to select a session. Selecting the option to automatically clean up redundant sessions will end the session that the user does not select. If you do not select the option to automatically cleanup redundant sessions, the user must manually end their extra sessions.

 6.  Default Display Protocol: VMware Blast

7. Allow Users to choose protocol:  No

8.  Click Next

 

 

Add Desktops to Global Entitlement

Notice that 1 user is associated with the global entitlement but 0 Pods are associated to the global etitlement.

 

  1. Double-click on the global entitlement.

 

  1. Select the Local Pools tab
  2. Click Add

 

  1. Highlight the Win10-IC Pool
  2. Click Add
  3. You can close or minimize the View Administrator browser window

 

 

Verify Global Entitlement

When you logged in to Pod B at the beginning of this module, you noticed that you were not authorized to any desktop resources from Pod B.

 

  1. Launch the VMware Horizon Client from the Main Console desktop.
  2. Double-click on the View-02a.corp.local icon to connect to Pod B.

 

Log in to view-02a.

  1. User name: lab1user
  2. Password: VMware1!

 

Notice that you now have access to a desktop pool when logged in to Pod B.  You may launch the desktop if desired.

Close the Horizon Client window.

 

 

Lesson Summary

You should have an understanding of how global entitlements allow desktop resources to be presented across Pods in different sites.

In this lesson, Lab 1 User was not able to access any desktop resources when logging in to the Barcelona site.  Once the Global entitlement was configured, desktop resources from Pod A were accessible to Lab 1 User when logging in to Pod B.

The following lessons in this module will teach you more about Cloud Pod Architecture.

 

 

Conclusion



 

You've finished Module 1 - Horizon Cloud Pod Architecture

Congratulations on completing Module 1 - Horizon Cloud Pod Architecture.  

You should now have a foundational understanding of the Horizon Cloud Pod Feature and be able to configure and entitle desktops resources for a cloud pod.

Proceed to any module below which interests you most.

 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 2 - Integrating Identity Manager with Horizon 7.1 with Cloud Pod Architecture (60 minutes)

Introduction



 

Integrating Identity Manager with Horizon 7.1 with Cloud Pod Architecture 

In this Module we explain how to setup vIDM as part of highly available Cloud Pod Architecture (CPA).

 

Configuring Failover and Redundancy in a Single Data Center

To achieve failover and redundancy, you can add multiple VMware Identity Manager virtual appliances in a cluster. If one of the virtual appliances shuts down for any reason, VMware Identity Manager is still available. You first install and configure a VMware Identity Manager virtual appliance, then you clone it. Cloning the virtual appliance creates a duplicate of the appliance with the same configuration as the original. You can customise the cloned virtual appliance to change the name, network settings, and other properties as required. Before you clone the VMware Identity Manager virtual appliance, you must configure it behind a load balancer and change its fully qualified domain name (FQDN) to match the load balancer FQDN. Also, complete directory configuration in the VMware Identity Manager service before you clone the appliance. After cloning, you assign the cloned virtual appliance a new IP address before powering it on. The cloned virtual appliance IP address must follow the same guidelines as the IP address of the original virtual appliance. The IP address must resolve to a valid host name using forward and reverse DNS. All nodes in the VMware Identity Manager cluster are identical and nearly stateless copies of each other. Syncing to Active Directory and to resources that are configured, such as View or ThinApp, is disabled on the cloned virtual appliances.
The VMware Identity Manager appliance includes Elasticsearch, a search and analytics engine. Elasticsearch has a known limitation with clusters of two nodes and can cause "split brain".

A VMware Identity Manager cluster with two nodes provides failover capability with a few limitations related to Elasticsearch. If one of the nodes shuts down, the following limitations apply until the node is brought up again:

There is no data loss during the time the node is down. Audit event and sync log data is stored and will be displayed when the node is restored. Therefore it is highly recommended setting up a VMware Identity Manager cluster with three nodes.

When deploying a multi-node Identity Manager environment, you need to have a load-balancer in front of all the appliances, to direct traffic coming in from the clients. The diagram below illustrates how the client devices would connect to the IDM cluster.

 

This document illustrates the first part of setting up a highly-available cluster. From the diagram below, it would be the equivalent of setting up the IDM, SQL and load balancer environment in the primary data center. Once the first site is done, you can repeat the process for the second site, modifying your database setup to become a SQL AlwaysOn deployment. We will not detail how to setup SQL AlwaysOn, as this process is well documented.

 

Guidelines for a multi-data center deployment

You have learned about the components of Cloud Pod Architecture for Identity Manager.

The following lessons in this module will teach you more about Identity Manager in Cloud Pod Architecture.

 

Preparation



 

Preparation

 

 

DNS Preparation

DNS Configuration

If you intend to build multiple appliances (3 or more) and load balance them, specify a unique DNS name for each appliance. The Load Balancing DNS name is different from the appliance DNS names. For example:

We only deployed two vIDM appliances due to resource constraints. And we will use vidm02a to walk you through the configuration of the SQL DB.

 

 

SQL DB preparation

Open RDP Client and connect to SQL Server SQL-01a

 

  1. Launch RDP client from Control center
  2. Log in with Corp\administrator and password VMware1!
  3. Select OK to connect

Launch SQL Server 2014 Management Console

 

  1. Click the Windows Icon on the bottom right corner and select the arrow pointing downwards
  2. Select the SQL Server 2014 Managment Studio

Login to SQL Server 2014 Managment Studio

 

  1. Select Database Engine from Server type
  2. Select SQL-01a\corp from Server Name
  3. Select Windows Authentication from Authentication
  4. Select connect

SQL DB setup

The SQL script is located in the readme file on the control center

Before boot the first vIDM appliance you have to setup the SQL DB. In our example we use “saas” for the DB name, it can be a different name. You will have to remember the DB name, as you will need it when you initiate the initial setup of the SQL JDBC in the Identity Manager on-boarding web-based setup. Also, the actual user is required. The username in our example is "vIDM" but you can use any name; make sure the user that has DB_Owner permissions to that database.

Create database saas 
collate Latin1_General_CS_AS; 
Alter database saas set READ_COMMITTED_SNAPSHOT ON; 
go


begin 
CREATE login vidm with password = N'H0rizon!'; 
end 
go


USE saas; 
IF EXISTS (SELECT * FROM sys.database_principals WHERE name = N'vidm') 
DROP USER [vidm] 
go

create user vidm for login vidm 
with default_schema = saas; 
go 

create schema saas authorization vidm 
grant all on database::saas to vidm; 
go

 

Run Script to create DB for vidm

 

 

  1. Select the database folder on the right-hand side
  2. Select New Query
  3. A new Query window appears
  4. Copy the SQL script from the readme file of the control center
  5. Paste the script into the Query window
  6. Select execute to create the saas DB

Verify saas DB is created and user vdim exists

 

  1. Check that DB saas exists
  2. Expand the saas DB
  3. Expand Security and users
  4. Verify that vidm user exists

 

 

User account Verifcation

 LDAP Accounts

All accounts synced with Identity Manager must have First Name, Last Name, and E-mail Address configured. This includes the Bind account. Please make sure that all accounts have an entry in the email field of the user account.

The email field must contain an email address, even if the email address is not valid.

 

 

 

Power on vIDM appliance

Launch Chrome Browser and launch vCenter Web Client

 

  1. Launch the Chrome browser for Control Center
  2. Launch the vCenter Web Client

Log in to vCenter Web Client

 

  1. Log in to vCenter Web client with the admin credentials administrator@vsphere.local with password VMware1!
  2. Click Login

Power on vidm-02a

 

  1. Navigate to vidm-02a
  2. Right-click on the icon
  3. Navigate to Power and Power on vidm-02a

 

 

Configure vIDM

Open Browser Tab and navigate to https://vidm-02a.corp.local:8443/

 

 

  1. Click and Advanced to show the advanced options
  2. Click on Proceed to vidm-02a.corp.local

VMware Identity Manager Welcome Screen

 

  1. Click on continue to start the configuration on vIDM

Appliance Administrator Accounts

 

 

  1. Configure password for admin user to VMware1!
  2. Configure password for root user to VMware1!
  3. Configure password for sshuser user to VMware1!
  4. Click on continue

Select Database

 

 

  1. Select external Database
  2. Insert the JDBC URL jdbc:sqlserver://192.168.110.45;DatabaseName=saas
  3. Provide user name for DB vidm
  4. Provide Password for DB user H0rizon!
  5. Select Test connection
  6. Verify that test was successful
  7. Select continue to progress

 

Configuration of vIDM gets finalized

 

After the db setup is finalised you will be presented with the login screen for vidm

  1. Log in with user account: admin
  2. Provide the password: VMware1!

 

Verify the setup is complete

 

 

Finalize configuration on vIDM

The next steps must be configured in a production environment.  These steps are not part of the this lab module

  1. Setup External DNS for VIP FQDN in our case identity.corp.com
  2. Modify firewall for traffic to External VIP (port 443 only)
  3. Remember that when going to the management port (8443), you always point to the individual appliance
  4. Change the FQDN to VIP of environment on your load balancer
  5. Changed FQDN on the appliance to reflect VIP FQDN identity.corp.com

One known issue is that the New Portal UI is disabled when the FQDN of IDM is changed. Make sure to leave the IDM1 web page up, need to re-enable the new UI portal before starting to use the FQDN.
Once you have successfully changed the FQDN, close down your browser (clearing cache and cookies), then open up your browser and log in to the FQDN of the IDM cluster (in our example:  https://identity.corp.com)

  1. Change the user required Attributes before doing anything else, otherwise you will need to remove the configuration and start over.
    1. Under Identity & Access Management, click on Setup (right side of screen), then choose: Change User Attributes (add UPN, Distinguished name, objectGUID)
  2. Join the Appliance into the domain
  3. Validate that the IDP hostname is pointing to the VIP FQDN.
    You might see here the IdP hostname as being the first node.
    Just change it to the FQDN of the external facing name (the one that is setup with the Load-Balancer).
  4. Shutdown node 1 and clone it
  5. Clone Node 3 right after node 2 is finished, before booting anything back up.
  6. Before booting 2nd node, make sure to go in settings, change the IP and FQDN of the 2nd node
  7. Boot 2nd node, once completely booted, join node to domain, from IDM Admin Console
    Important is to wait till the second node show up with status green before you make any changes
  8. After domain join, check the IDP to make sure it kept the FQDN hostname

 

 

  1. Click on the arrow on the dashboard
  2. Select System Diagnostics Dashboard
  3. Verify that you see both Appliances in the dashboard with green status
  4. Boot thr 3rd node. Once completely booted, join node to domain from the IDM Admin Console
    It is important is to wait until the second node shows up with a green status before making any changes.
  5. Check the status of the 3 nodes in your load balancer.  To obtain a green checkmark on node 2 & 3, you may to reboot the nodes once the setup is complete
  6. After the last node is rebooted, you can verify the status in the System Diagnostics Dashboard and should look like the screen below.

 

The final step is to replace the built-in certificates on all nodes.
There are a few use cases where you need to change the built-in certificates.
One of them is if your load-balancer does not accept untrusted certificates.

You will also need to upload the PEM file to your Load-Balancer trusted certificate list. You grab the PEM file from the Appliance Configuration page, under Certificates.

Information on how to replace built-in certificates can be found below.

http://pubs.vmware.com/identity-manager-28/topic/com.vmware.ICbase/PDF/vidm-28-install.pdf

 

Conclusion


In this module, you have learned how to configure to VMware Identity Manager to use it with an external SQL database.
You have also learned all the steps you have to carry out to create a 3 node vIDM cluster.

Proceed to any module below which interests you most.

 


 

VMware Identity Manager Resources

 

You can find more information on our website:

For more details on how to configure load balancing please take the lab:

Module 7 - F5 LTM with VMware Identity Manager Integration (45 min)

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 3 - Load Balancer Concepts (15 minutes)

Introduction to Load Balancer Concepts



 

Introduction to Load Balancer Concepts

This module contains the following topics:

You will be introduced to two load balancing concepts that can be useful in Horizon designs.

 

 

Simple Load Balancing

Simple load balancing operating at the transport layer (Layer 4) directs traffic based on an available path to the destination server.  If the path and the receiving application at the destination server responds to a simple heartbeat query sent by the load balancer, then the path is considered to be good and traffic will be sent in that direction.

In simple terms, the decision to direct traffic is based on the simple logic of the next destination being accessible.

Simple load balancers have the advantage of being relatively inexpensive and are limited to testing the next destination in the path.

 

 

A Fun Example of Simple Load Balancing

You arrive at VMworld in your Red Tesla Model S.  You are at the intersection where a traffic signal alternates sending vehicles to the East or West VMworld parking lots. You get directed to the East parking lot.  Your boss, who is right behind you in his yellow Chevy Spark, is directed to the West  parking lot.   As long as the signal can see an open road to the East and West parking lot, it will continue alternating between the two paths.  When access to the East parking lot is closed due to an accident, the traffic signal will only send vehicles to the West parking lot.  It doesn't matter why you are going to VMworld, you will make it to one parking lot or the other, and be able to locate your session once inside the building.

 

 

Advanced Load Balancing

Advanced load balancing operating at the application layer (Layer 7) is more robust and provides more options to make traffic decisions. By interpreting the contents of the network data, the load balancer can make routing decisions for the destination application.  If the application response is favorable, then the server is able to receive the client traffic.  Every application is unique and the load balancer must be able to interpret the application responses.  Several third party load balancers have features that are specifically designed to work with applications like the Horizon connection servers and security servers.  Being able to interpret the data of the application response allows client traffic to be directed towards the best access to that application.

If this was a security server scenario, the advanced load balancer would be able to fully test access through the security server, through the paired connection server, and into the desktop pool to determine if a desktop assignment can be made.  If so, the complete path is good and the traffic is directed accordingly.

 

 

A Fun Example of Advanced Load Balancing

You arrive at VMworld in your red Tesla Model S.  As you are waiting at the intersection before the parking lot, the traffic signal is able to look inside your vehicle and scan your VMworld itinerary.  Knowing that you are here to attend a Hands-On-Lab session in the West wing, you are directed to the West parking lot.  Meanwhile, your boss arrives at the same intersection in his yellow Chevy Spark.  His badge is recognized as a VMworld presenter and the session is in the East wing so he is directed to the East parking lot.  

Although all sessions are available once inside the building, the advanced traffic control knew what information to scan in order to direct you towards the most efficient available path to your destination.

 

 

Lesson Summary

You should have a basic understanding of simple (layer 4) load balancing and advanced (layer 7) load balancing.  

 

 

 

Conclusion



 

You've finished Module 3 - Load Balancer Concepts

Congratulations on completing Module 3 - Load Balancer Concepts. You should have a basic understanding between basic Layer-4 and advanced Layer-7 load balancing concepts.

Proceed to any module below which interests you most.

 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 4 - Load Balancing for Horizon Connection Servers (30 minutes)

Introduction to Load Balancing for Horizon Connection Servers


This Module contains the following lessons:


 

Architecture Principles and Concepts

A Horizon 7 Enterprise Edition design uses a number of complementary components to provide a variety of highly available services to address the identified use cases.
Before we can assemble and integrate these components to form the desired service, we first need to design and build the infrastructure required.

Pod and Block

One key concept in a VMware Horizon environment design is the use of pods and blocks, which gives us a repeatable and scalable approach.

A pod is made up of a group of interconnected View Connection Servers that broker desktops or published apps.
A pod can broker up to 10,000 sessions including desktop and RDSH sessions.
Multiple pods can be interconnected using Cloud Pod Architecture (CPA) for a maximum of 50,000 sessions.
For numbers above that, separate CPAs can be deployed.

A pod is divided into multiple blocks to provide scalability.
Each block typically serves up to 2,000 sessions and is made up of one or more resource vSphere clusters.
Each block has its own VMware vCenter Server®, a VMware View® Composer™ Server (where linked clones are to be used), and vSphere clusters.

A View pod and the Connection Servers in it must be located within a single data center and cannot span across locations. Multiple View pods and locations can be interconnected using Cloud Pod Architecture (CPA).
It is important to stress the fact that a single View pod cannot be stretched across multiple data centers. For such a scenario, multiple View pods must be deployed and linked using Cloud Pod Architecture.

 

 

 

Load Balancing of Connection Servers

One key design principle is to remove single points of failure in the deployment. For high availability and scalability, it is recommended that you build redundancy across all components.
Horizon 7 Enterprise Edition Logical Architecture below shows the redundant buildout of the components.

 

 

Logical Architecture

This section will focus on the following core elements of View.

The diagram below shows the high-level logical architecture of these core elements. Other components are shown for illustrative purposes, but the areas of focus are in dark blue.

 

 

View Connection Server A View Connection Server supports a maximum of:

To satisfy the requirements that the proposed solution be robust and able to handle failure, we will deploy (n+1).
2 x Connection Servers (n+1) will have to be deployed to satisfy the requirement of one resource block capable of hosting up to 2,000 sessions and also to provide high availability.

View Connection Servers broker client connections, authenticate users, and direct incoming requests to the correct endpoint.
The load balancer serves as a central aggregation point for traffic flow between clients and connection servers, sending clients to the best performing and most available View Connection Server instance.

Using a load balancer with multiple View Connection Servers also facilitates greater flexibility by enabling IT Administrators to perform maintenance, upgrades, and changes in the configuration without impacting users.

 

View requires the load balancer to have a session persistence setting. This is sometimes referred to as persistent connections or sticky connections and ensures data stays directed to the relevant View server.

A load balancer will be placed in front of the View Connection Servers for both internal connections and those coming externally via the Access Points.

It is highly recommended that users connect to Access Point using a load-balanced VIP. This ensures that user load is evenly distributed across all available Access Points. Using a load balancer also facilitates greater flexibility by enabling IT administrators to perform maintenance, upgrades, and changes in the configuration without impacting users.
Additionally, it is also recommended that connections from the Access Points to the View Connection Servers are also load-balanced, although this is not required.

 

Only the initial XML API connection is load balanced; PCoIP, Blast Extreme, or RDP connections will connect directly to the Access Point that brokered the initial XML API connection.
For load balancing to function correctly a connection must maintain persistence/affinity of the session.
To facilitate this, there are two methods that can be implemented in the environment to support session persistence/affinity:

The capabilities of the load balancer will determine which method will be used. If both are supported then a preference of SSL ID should be considered as this gives the most even spread of connections.

The following lessons in this module will teach you more about Load Balancing of Connection Servers in Cloud Pod Architecture.

 

Deploy Horizon Connection Servers



 

Installing the View Connection Server Software

Depending on the performance, availability, and security needs of your View deployment, you can install a single instance of View Connection Server, replicated instances of View Connection Server, and Security Servers.
You must install at least one instance of View Connection Server however, for redundancy it is recommended to deploy at least two instances.

When you install View Connection Server, you select a type of installation.

Installation Type Description/ Function
Standard installation
Generates a View Connection Server instance with a new View LDAP configuration.
Replica installation
Generates a View Connection Server instance with a View LDAP configuration that is copied from an existing instance.
Security server installation
Generates a View Connection Server instance that adds an additional layer of security between the Internet and your internal network.
Enrollment Server installation
Installs an enrollment server that is required for the True SSO (single sign-on) feature, so that after users log in to VMware Identity Manager, they can connect to a remote desktop or application without having to provide Active Directory credentials. The enrollment server requests the short-lived certificates that are used for authentication.

Enrollment server requires that a certificate authority also is set up, and specific configuration performed.

 

 

Installation Prerequisites for View Connection Server

You must join the View Connection Server host to an Active Directory domain. View Connection Server supports the following Active Directory Domain Services (AD DS) domain functional levels:

The View Connection Server host must not be a domain controller. View Connection Server does not make any schema or configuration updates to Active Directory.

When you install View Connection Server, you authorise a View Administrators account. You can specify the local Administrators group or a domain user or group account. View assigns full View Administration rights, including the right to install replicated View Connection Server instances, to this account only. If you specify a domain user or group, you must create the account in Active Directory before you run the installer.

A production Horizon Connection Server should have 10 GB of RAM and 4 vCPU. Each Horizon Connection Server can handle 2,000 virtual desktops.
Windows 2016 is supported with Horizon Connection Server 7.1 and newer.

 

 

Install Standard Server 7.1.0

 

  1. Select view connection server msi

 

In the Welcome to the Installation Wizard for VMware Horizon 7 Connection Server page, click Next.

 

In the License Agreement page, select I accept the terms, and click Next.

 

In the Destination Folder page, click Next.

 

In the Installation Options page, select Horizon 7 Standard Server, and click Next.

 

In the Data Recovery page, enter a password, and click Next.

 

In the Firewall Configuration page, click Next.

 

In the Initial Horizon 7 Administrators page, enter an AD group containing your Horizon administrators, and click Next.

 

In the User Experience Improvement Program page, uncheck the box, and click Next.

 

In the Ready to Install the Program page, click Install.

 

In the Installer Completed page, uncheck the box next to Show the readme file, and click Finish.

 

 

Install Replica Server 7.1.0

Additional internal Horizon Connection Servers are installed as Replicas. After installation, there is no difference between a Replica server and a Standard server.

 

  1. Select view connection server msi

 

In the Welcome to the Installation Wizard for VMware Horizon 7 Connection Server page, click Next.

 

In the License Agreement page, select I accept the terms, and click Next.

 

In the Destination Folder page, click Next.

 

In the Installation Options page, select Horizon 7 Replica Server, and click Next.

 

In the Source Server page, enter the name of another Horizon Connection Server in the group. Then click Next.

 

In the Ready to Install the Program page, click Install.

 

In the Installer Completed page, uncheck the box next to Show the readme file, and click Finish.

 

Configure Load Balancing for Horizon Connection Servers



 

Configure Load Balancing for Horizon Connection Servers with NSX

There are several products you could use to load balance the connection servers. In this lesson we will explain how you would configure load balancing with NSX.
If you are interested in understanding how to use F5 for load balancing please have a look at the lab below.

Module 1 - F5 LTM with Horizon Connection Servers (45 min)

 

 

Where do you need Load Balancing?

Where in the Horizon architecture do we need load balancers?  In the case of connection servers, you typically load balance the access points and connection servers.
We need them in our local pods and global load balancers when we have several sites.

Externally:

Internally:

 

For example, for the connection server load balanced configuration, the load balancer serves as a central point for authentication traffic flow between clients and the Horizon infrastructure, sending clients to the best performing and most available connection server instance.

In the lab, we use a simple configuration with one NSX edge and one connection server per site due to resource constraints.
Therefore we will only walk you through the NSX configuration.

 

 

 

Verify NSX and Configure Load Balancing

We assume a configuration with at least two connection servers. In production, you would have at least 2 x Connection Servers (n+1) to be deployed to satisfy the requirement of one resource block capable of hosting up to 2,000 sessions and also to provide high availability.

Launch Chrome Browser and Launch vCenter Web Client

 

  1. Launch the Chrome browser for Main Console
  2. Launch the vCenter Web Client

Login to vCenter Web Client

 

  1. Log in to vCenter Webclient with the admin credentials administrator@vsphere.local with password VMware1!
  2. Click Login

 

 

Verify NSX Edge configuration

 

  1. Hover over the home icon on the top of the console
  2. Select Networking & Security
  3. Select NSX Edges

 

  1. Verify the NSX manager shows on the top
  2. Double-click on the Edge-2 to verify the configuration

 

  1. Select Manage for the NSX Edge
  2. Select Load Balancer tab
  3. Select Global configuration
  4. Verify the Load balancer status shows enabled

 

 

Configure Application Profile

 

  1. Select Application Profiles
  2. Select the green cross to create an application profile

For this setup, you can leave the default HTTPS service monitor.
Normally you would also want to have service checks on, for example, the Blast gateway (8443) or PCoIP (4172) if components use this.

 

  1. Provide a Name for application profile
  2. Select Type: HTTPS
  3. Enable SSL Passthrough
  4. Select Persistence: SSI Session ID
  5. Select Ok to save

 

 

Configure Application Pool

 

  1. Select Pools
  2. Select the green cross to create a new application pool

 

  1. Provide a Name for the application pool
  2. Select Algorithm: IP Hash
  3. Select Monitors: default_https_monitor
  4. Select the green cross to add Connection Servers

 

  1. Provide the Name for the first member: View-01a
  2. Select State: Enable
  3. Insert Monitor Port:  443
  4. Insert Weight: 1
  5. Insert Max Connections and Min Connections: 0
  6. Click select to add IP or VC container and an additional window appears

 

  1. Select Object type Virtual Machine
  2. Select View-01a VM
  3. Select Ok to save

 

  1. Select OK to save and return to the pool configuration

 

 

You would repeat the above steps to add the second Connection Server into the pool.

  1. Then select OK to finish the Application Pool creation

 

 

Configure Virtual Server

 

  1. Select Virtual Servers
  2. Select the green cross

 

  1. Select Virtual Server
  2. Select Application Profile Horizon -CS
  3. Provide Virtual Server Name Horizon-SSL
  4. Optional Provide Description
  5. Select VIP IP address 192.168.110.32
  6. Select Protocol HTTPS
  7. Verify port 443
  8. Select Default Pool Horizon-CS-LB-HTTPS
  9. Add Connection limit and Connection rate limit 0
  10. Select OK to save

 

 

Verify NSX Loadbalancer

 

  1. Select Pools
  2. Select Show Pool Statistics
  3. Verify Pool Status by clicking on pool-2
  4. Verify Pool Member

In our scenario, we have only one connection server configured in the lab due to resource constraints.

 

Verify that you can reach the Connection Server through the URL https://nsx-lb.corp.local/ which is the IP of the VIP 192.168.110.32.

 

Conclusion



 

You've finished Module 4 - Load Balancing for Horizon Connection Servers

 

 

For More Information

 

 Additional information on installation or configuration of Horizon Connection Servers

 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 5 - Load Balancing for Horizon Unified Access Gateway (15 minutes)

Introduction to Load Balancing for Horizon Unified Access Gateway



 

Introduction to Load Balancing for Horizon Unified Access Gateway

This module contains the following lessons:

Unified Access Gateway

From version 2.9 the appliance is now called Unified Access Gateway (UAG) instead of the old name of Access Point.  UAG is a VMware virtual appliance designed to protect desktop and application resources to allow remote access from the Internet

It is used with:

Unified Access Gateway is typically deployed in a DMZ. For high availability and scalability requirements in a production deployment, several Unified Access Gateway appliances are usually setup behind a load balancer as shown below.

 

Load Balancing Requirements

This module focuses on the load balancing requirements for the Horizon use cases. It discusses the distinction between the primary and secondary Horizon protocols and describes the three methods for guaranteeing session affinity. The three methods ensure that all protocol traffic from a Horizon client session goes to the same Unified Access Gateway appliance. This module also covers health monitoring and SSL offload/SSL bridging for load balancers.

Transport Layer Security (TLS) and the predecessor Secure Sockets Layer (SSL) are both referred to in this document as just SSL. By default, SSL is disabled on UAG and only TLS 1.1 and TLS 1.2 are enabled.

Horizon Protocols

When a Horizon Client user connects to a Horizon environment, several different protocols are used. The first connection is always the primary XML-API protocol over HTTPS. Following successful authentication, one or more secondary protocols are also made.

Primary Horizon Protocol

The user enters a host name at the Horizon Client and this starts the primary Horizon protocol. This is a control protocol for authentication, authorization and session management. It uses XML structured messages over HTTPS (HTTP over SSL). This protocol is sometimes known as the Horizon XML-API control protocol. In a load balanced environment as shown above in figure 1, the load balancer will route this connection to one of the UAG appliances. The load balancer will usually select the appliance based first on availability, and then out of the available appliances will route traffic based on the least number of current sessions. This has the effect of evenly distributing the traffic from different clients across the available set of UAG appliances.

Secondary Horizon Protocols

After the Horizon Client has established secure communication to one of the UAG appliances, the user authenticates. If this authentication attempt is successful, then one or more secondary connections are made from the Horizon client. These secondary connections can include:

These secondary Horizon protocols must be routed to the same UAG appliance to which the primary Horizon protocol was routed. This allows UAG to authorize the secondary protocols based on the authenticated user session. An important security capability of UAG is that it will only forward traffic to the corporate data center if the traffic is from an authenticated user. If the secondary protocols were routed to a different UAG appliance other than the primary protocol's UAG, then they would not be authorized and would be dropped in the DMZ and the connection would fail. Misrouting the secondary protocols is a common problem if the load balancer is not configured correctly.

Health Monitoring

A load balancer monitors the health of each UAG appliance by periodically sending an HTTPS GET /favicon.ico request (e.g.https://ap1.myco-dmz.com/favicon.ico). This monitoring is configured on the load balancer. It will perform this HTTPS GET and expect a "HTTP/1.1 200 OK" response from UAG to know that it is "healthy". If it gets a response other than "HTTP/1.1 200 OK" response or doesn't get any response, it will mark the particular UAG appliance as down and will not attempt to route client requests to it. It will continue to poll so that it can detect when it is available again.

UAG can be put into "quiesce" mode after which it will not respond to the load balancer health monitoring request with a "HTTP/1.1 200 OK" response. Instead, it will respond with "HTTP/1.1 503" to indicate that the UAG service is temporarily unavailable. This setting is often used prior to scheduled maintenance, planned reconfiguration or planned upgrade of a UAG appliance. In this mode, the load balancer will not direct new sessions to this appliance because it will be marked as unavailable but can allow existing sessions to continue until the user disconnects or the maximum session time is reached. Consequently, this operation won't disrupt existing user sessions. The appliance will then be available for maintenance after a maximum of the overall session timer, which is typically 10 hours. This capability can be used to perform a rolling upgrade of a set of UAG appliances in a strategy resulting in zero user downtime for the service.

SSL Offloading or Bridging

Many load balancers have the capability of SSL offloading where the SSL connection terminates at the load balancer. This can be useful for managing SSL server certificates and ciphers at the load balancer.

In order for the client connection to be secure right to UAG, if the load balancer is configured to terminate SSL, then it is necessary to re-encrypt SSL traffic for communication between the load balancer and UAG. This is often known as SSL bridging as nothing is actually offloaded from UAG. SSL bridging is not necessary but it is supported. If SSL bridging is used, then it is important to install the same SSL server certificate on and the load balancer. This is because when a Horizon Tunnel connection is made by the client, it is expecting the same certificate at the point where TLS is terminated. It does this to detect a malicious MITM attack. In other words, UAG and the load balancer must have the same certificate.

UAG supports load balancers that use SSL bridging and load balancers that pass through the SSL communication for termination at UAG.

The following lessons in this module will teach you more about Load Balancing of Access Points.

 

Deploy Horizon Unified Access Gateway



 

Deploy Horizon Unified Access Gateway

This module provides information only - no lab work required. Please verify configuration in AP-01a.

With Horizon Unified Access Gateway you have two options to deploy the UAG.

  1. Use vCenter Server and the Deploy OVF Template wizard
  2. Use PowerShell

 

 

Deploy and configure Horizon Unified Access Gateway with the GUI

First step is to deploy the Horizon Unified Access Gateway in a VMware environment. This is a straight-forward, basic deployment and not that difficult. All the configuration is done afterwards in the GUI.
Download the OVA for Horizon Unified Access Gateway from VMware and save to a file share.

 

Login to vSphere Webclient

  1. Open vSphere Webclient and connect to vCenter
  2. Right-click the cluster where you want to deploy the Horizon Unified Access Gateway
  3. Select "Deploy OVF Template"

 

Deploy OVA

  1. Select Local file
  2. Select Browse
  3. Select Horizon Unified Access Gateway ova from the file location
  4. Select Open

 

Select Name and Location

  1. Provide Applicance name
  2. Select Datacenter
  3. Select folder
  4. Select next

 

 

Select Resource

  1. Select host or cluster
  2. Select Next

 

Review Details

  1. Review details
  2. Select Next

 

Select Network Configuration

  1. Select the desired network configuration according to the Configure Load Balancing for Horizon Unified Unified Access Gateway
  2. Select Next

 

 

Select Storage Location and Provisioning Method

  1. Select virtual disk format
  2. Select datastore
  3. Select Next

 

Select Networks

In the lab we use a single NIC configuration

  1. Select network configuration
  2. Select Next

 

Customize Template

  1. Configure DNS server, Gateway, Network mask
  2. Select NIC 1 IP address
  3. Scroll down to Password options

 

Password  Options

  1. Provide password for admin user
  2. Provide password for root user
  3. Select Next

 

Verify Summary

  1. Verify the configuration
  2. Select Finish to deploy

 

 

 

Configure Horizon Unified Access Gateway via GUI

After you have deployed the Horizon Unified Access Gateway using the vSphere client, you have to utilize the GUI to finish configuring the different options in Horizon Unified Access Gateway.  To start the configuration open a browser https://FQDN of the VMware Access Point:9443/Admin and you will see the login screen as shown below.

 

Login to Horizon Unified Access Gateway

  1. Insert admin user:  admin
  2. Insert admin password:  VMware1!
  3. Select Login

 

Once you logon, you see two options. You can either import Horizon Unified Access Gateway settings using a JSON file (perfect if you deploy multiple gateways) or you can configure manually.
You can select a JSON file with the settings and import them. This is a very interesting way to deploy and upgrade.

 

 

In this lab, Horizon Unified Access Gateway is configured for Horizon only

  1. Click on Select to verify the configuration

 

 

  1. The Edge Service Settings contain the Horizon Settings, Reverse Proxy, Per App Tunnel, and Proxy Settings.
  2. The Authentication Settings contain the two-factor authentication settings.
  3. The Advanced Settings section is used to configure the appliance settings, add an SSL server certificate, SAML, etc.
  4. The Support Settings section allows you to export logs and export the settings

We will have a closer look at the Edge Service Settings - these are the configurations you need to look at.

 

  1. Select the Show icon to verify the Horizon Configuration
  2. Select the Arrow to expand
  3. Select the gear icon to see the configuration details

 

You need to set at least the following settings;

 

 

Deploying VMware Access Point with PowerShell

What you need

How do I run the script?

  1. set-executionpolicy -scope currentuser unrestricted
  1. If you get a warning about running this script, you can unblock that warning by running the command:
  2. unblock-file -path .\uagdeploy.ps1
  3. or
  4. unblock-file -path .\apdeploy.ps1

Basic .INI File Example

 

##############################################

[General]

name=AG-01a

source=C:\APs\euc-unified-access-gateway-2.9.0.0-5562999_OVF10.ova

target=vi://administrator@vsphere.local:VMware1!@192.168.110.22/RegionA01/host/esx-01a.corp.local

ds=Local Disk 1

netInternet=VM-RegionA01-vDS-COMP

netManagementNetwork=VM-RegionA01-vDS-COMP

netBackendNetwork=VM-RegionA01-vDS-COMP

honorCipherOrder=true

 

[Horizon]

proxyDestinationUrl=https://view-01a.corp.local:443

##############################################

 

Configure Load Balancing for Horizon Unified Access Gateway



 

Configure Load Balancing for Horizon Unified Access points

Unified Access Gateway is used to ensure that the only traffic entering the corporate data center is traffic on behalf of a strongly authenticated remote user.

Unified Access Gateway directs authentication requests to the appropriate server and discards any unauthenticated request. Users can access only the resources that they are authorized to access. Unified Access Gateway also ensures that the traffic for an authenticated user can be directed only to desktop and application resources to which the user is actually entitled. This level of protection involves specific inspection of desktop protocols and coordination of potentially rapid changing policies and network addresses, to accurately control access.

Unified Access Gateway acts as a proxy host for connections inside your company's trusted network. This design provides an extra layer of security by shielding virtual desktops, application hosts, and servers from the public-facing Internet.

Unified Access Gateway is designed specifically for the DMZ. The following hardening settings are implemented.

Deployment Scenarios

Unified Access Gateway appliance in the DMZ can be configured to point to a server or a load balancer that fronts a group of servers. Unified Access Gateway appliances work with standard third-party load balancing solutions that are configured for HTTPS.

If the Unified Access Gateway appliance points to a load balancer in front of servers, the selection of the server instance is dynamic. For example, the load balancer might make a selection based on availability and the load balancer's knowledge of the number of current sessions on each server instance. The server instances inside the corporate firewall usually have a load balancer to support internal access. With Unified Access Gateway, you can point the Unified Access Gateway appliance to this same load balancer that is often already being used. You can alternatively have one or more Unified Access Gateway appliances point to an individual server instance. In both approaches, use a load balancer in front of two or more Unified Access Gateway appliances in the DMZ.

 

Network Configuration Options

You can use one, two, or three network interfaces and Unified Access Gateway requires a separate static IP address for each. Many DMZ implementations use separated networks to secure the different traffic types. Configure Unified Access Gateway according to the network design of the DMZ in which it is deployed.

Typical Single NIC DMZ Deployment

The simplest deployment of Unified Access Gateway is with a single NIC where all network traffic is combined onto a single network. Traffic from the Internet-facing firewall is directed to one of the available Unified Access Gateway appliances. Unified Access Gateway then forwards the authorized traffic through the inner firewall to resources on the internal network. Unified Access Gateway discards unauthorized traffic.

 

Dual NIC DMZ Deployment

An improvement over the single NIC deployment is to specify two NICs. The first is still used for Internet facing unauthenticated access, but the back-end authenticated traffic and management traffic are separated onto a different network.

 

Session Affinity Options

Method 1 - Source IP Affinity

This is the simplest configuration for a load balancer as it uses standard port numbers and a single load balanced VIP. It relies on the load balancer to route secondary protocols to the same UAG appliance as was selected for the primary Horizon protocol. It can do this on the basis of repeat connections coming from the same Horizon client IP address. Unfortunately, this method doesn't work in all situations. For example with certain Network Service Providers or NAT devices, the source IP address is not available for this affinity configuration. If source IP affinity can't be used in your environment, then one of the other two methods should be used as they don't rely on source IP affinity.

In this example, the public IP address is 10.20.30.40 (ap.myco.com) and would be translated to 192.168.0.100 (the load balanced VIP DMZ IP address).

UAG Configuration for External URLs for this configuration would be as shown in this table.

UAG Appliances Configuration Item
Value
AP01
tunnelExternalURL
https://ap.myco.com:443
AP01
blastExternalURL
https://ap.myco.com:443
AP01 pcoipExternalURL
10.20.30.40:4172
AP02 tunnelExternalURL
https://ap.myco.com:443
AP02
blastExternalURL
https://ap.myco.com:443
AP02 pcoipExternalURL
10.20.30.40:4172

Method 1 advantages:

  1. Uses standard port numbers.
  2. Does not require multiple public virtual IP addresses.

Method 1 disadvantages:

  1. Relies on source IP address affinity which is not always possible.

Method 1 is recommended for all environments where source IP address affinity is possible. Where it is not possible, then either method 2 or method 3 should be used.

Method 2 - Multiple Port Number Groups

Multiple port group affinity does not rely on source IP address for affinity. Instead the load balancer is configured to route the secondary Horizon protocols based on unique port numbers assigned to each UAG appliance. The primary Horizon protocol on HTTPS port 443 is load balanced to allocate the session to a specific UAG appliance based on health and least loaded. The secondary connections would then be routed to the correct UAG appliance based on the following load balancer configuration table.

Virtual IP Address
Primary/Secondary
Protocol
Name
Real Servers
192.168.0.100:443
Primary
TCP
APLB - HTTPS
192.168.0.101:443
192.168.0.102:443
192.168.0.100:10143
Secondary
TCP
AP01 - HTTPS
192.168.0.101:443
192.168.0.100:10143
Secondary
UDP AP01 - BLAST-UDP
192.168.0.101:443
192.168.0.100:10172
Secondary
TCP AP01 - PCOIP
192.168.0.101:4172
192.168.0.100:10172
Secondary
UDP AP01 - PCOIP-UDP
192.168.0.101:4172
192.168.0.100:10243
Secondary
TCP AP02 - HTTPS
192.168.0.102:443
192.168.0.100:10243
Secondary
UDP AP02 - BLAST-UDP
192.168.0.102:443
192.168.0.100:10272
Secondary
TCP AP02 - PCOIP
192.168.0.102:4172
192.168.0.100:10272
Secondary
UDP AP02 - PCOIP-UDP
192.168.0.102:4172

The same port mapping scheme can be used for additional UAG appliances 03 > 99. The virtual IP address for the load balancer might be behind a NAT device. In this example, the public IP address is 10.20.30.40 (ap.myco.com)and would be translated to 192.168.0.100 (the load balanced VIP IP address).

UAG Configuration for External URLs for this configuration would be as shown in this table.

UAG Appliance
Configuration Item
Value
AP01
tunnelExternalURL
https://ap.myco.com:10143
AP01
blastExternalURL
https://ap.myco.com:10143
AP01
pcoipExternalURL
10.20.30.40:10172
AP02
tunnelExternalURL
https://ap.myco.com:10243
AP02
blastExternalURL
https://ap.myco.com:10243
AP02
pcoipExternalURL
10.20.30.40:10272

Method 2 advantages:

  1. Does not rely on source IP affinity.
  2. Does not require multiple public virtual IP addresses.

Method 2 disadvantages:

  1. Uses non standard port numbers from the Internet although the port numbers on the UAG appliances themselves are standard.

Method 3 - Multiple VIPs

This method is similar to the multiple port groups method except instead of dedicating port number to each UAG appliance it dedicates an individual VIP to each appliance in addition to the primary load balanced VIP. If you have 2 UAG appliances then you would set up 3 VIPs.The primary Horizon protocol on HTTPS port 443 is load balanced to allocate the session to a specific UAG appliance based on health and least loaded. The secondary connections would then be routed to the correct UAG appliance based on the following Load Balancer configuration table.

Virtual IP Address
Primary/Secondary
Protocol
Name
Real Server
192.168.0.100:443
Primary
TCP APLB - HTTPS
192.168.0.101:443
192.168.0.102:443
192.168.0.101:443
Secondary
TCP AP01 - HTTPS
192.168.0.101:443
192.168.0.101:443
Secondary
UDP AP01 - BLAST-UDP
192.168.0.101:443
192.168.0.101:4172    
Secondary
TCP AP01 - PCOIP
192.168.0.101:4172
192.168.0.101:4172
Secondary
UDP AP01 - PCOIP-UDP
192.168.0.101:4172
192.168.0.102:443
Secondary
TCP AP02 - HTTPS
192.168.0.102:443
192.168.0.102:443
Secondary
UDP AP02 - BLAST-UDP
192.168.0.102:443
192.168.0.102:4172
Secondary
TCP AP02 - PCOIP
192.168.0.102:4172
192.168.0.102:4172
Secondary
UDP AP02 - PCOIP-UDP
192.168.0.102:4172

Note that the secondary protocols don't have to be routed via the load balancer. If required they can bypass the load balancer.

In this example

UAG Configuration for External URLs for this configuration would be as shown in this table.

UAG Appliance
Configuration Item
Value
AP01
tunnelExternalURL
https://ap1.myco.com:443
AP01
blastExternalURL
https://ap1.myco.com:443
AP01
pcoipExternalURL
10.20.30.41:4172
  tunnelExternalURL
https://ap2.myco.com:443
AP02
blastExternalURL
https://ap2.myco.com:443
AP02
pcoipExternalURL
10.20.30.42:4172

Method 3 advantages:

  1. Does not rely on source IP affinity.
  2. Uses standard port numbers.

Method 3 disadvantages:

  1. Requires an additional public facing VIP for each UAG appliance in addition to the primary load balanced VIP.

 

Conclusion



 

You've finished Module 5 - Load Balancing for Horizon Unified Access Gateway

Congratulations on completing Module 5 - Load balancing for Horizon Unified Access Gateway.  You should now have a foundational understanding how to deploy and configure Unified Access Gateway.

Proceed to any module below which interests you most.

 

 

 

For More Information

 

Additional  information on installation or configuration of Horizon Unified Access Gateway via PowerShell can be found:

 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 6 - Load Balancing for Horizon App Volumes (15 minutes)

Introduction to Load Balancing for Horizon App Volumes



 

Introduction

This module contains the following lessons:

This lesson describes VMware App Volumes™ capabilities, architecture, and implementation requirements and addresses frequently asked high-level questions about deploying an App Volumes solution. The example setting for this deployment is a View virtual desktop environment in VMware Horizon® 7.1.

 

 

App Volumes Overview

App Volumes is a real-time application delivery and life-cycle-management tool. Enterprises can use App Volumes to build real-time application delivery systems that ensure applications are centrally managed. Applications are delivered to desktops through virtual disks. With the App Volumes solution, you do not need to modify desktops or applications themselves, and you can scale out easily and cost-effectively, without compromising end-user experience.
App Volumes is an important part of the VMware Horizon 7 Enterprise Edition, which provides an application delivery mechanism for VDI desktops as well as RDSH-hosted desktops and applications.

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

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.

 

 

How App Volumes Works

In modern desktop environments, the demand for real-time application delivery often puts a strain on existing infrastructures.

Through App Volumes, VMware addresses this strain by virtualizing applications above the operating system (OS) and by offering an alternative to managing per virtual machine. Applications virtualized above the OS are delivered as if natively installed—without modification, in various configurations, to multiple groups of users. And, through file and registry virtualization, applications are organised into application management containers. This arrangement uses existing storage and networking services, reduces infrastructure strain and overhead, and simplifies application lifecycle management.

 

As illustrated in the above image, application-management containers are above the desktop OS, which has an App Volumes Agent installed.
Applications, data files, middleware, and configurations are in separate, layered containers. There are two types of App Volumes containers:

 

 

App Volumes Benefits

With App Volumes, applications become VM-independent objects that can be moved easily across data centers or to the cloud and shared with thousands of virtual machines. In a virtual desktop environment, App Volumes provides the following benefits:

Real-Time Application Delivery

Cost-Optimized Infrastructure

Seamless End-User Experience

 

 

App Volumes High-Level Architecture

App Volumes integrates a simple agent-server-database architecture into an existing View deployment. Centralised management servers are configured to connect to deployed virtual desktops that run an App Volumes Agent. An administrator can grant application access to shared storage volumes for users or virtual machines or both.

This image below shows the major components of a View environment where App Volumes is deployed in a single DC deployment.

 

 

The image below shows a stretched App Volumes environment with SQL DB across two sites with datastore replication.

 

In this scenario, AppStack replication and user group entitlements to the AppStacks are identical in each site.

  1. The AppStacks are replicated through a separate data-store configured for replication purpose only.
  2. The user entitlements to AppStacks are shared across the sites.

The image below shows separate App Volumes Managers and a separate SQL DB at each site with datastore replication between sites.

 

In this scenario, only the AppStacks are replicated across sites.  User group entitlements are maintained independently for each site.

  1. The App stack is replicated through a separate data store configured for replication purpose only.
  2. The user entitlements to AppStacks are independent of one another due to the separate SQL databases.  You will need to entitle the AppStack at each site.

 

 

Data Flow in an App Volumes Environment

The image shows the data flow for App Volumes in a typical View environment. The diagram illustrates a View pod in a single data center with multiple View blocks.

 

  1. The left side of image illustrates App Volumes without the direct-to-host connection option (Mount on Host).
  2. The right side illustrates App Volumes with the direct-to-host connection option.
  3. The dashed blue line in the diagram indicates an ongoing, periodic communication between the App Volumes Manager and vCenter Server.

The App Volumes Manager finds out if the host is up, if storage is still available, and if VMs are still online. App Volumes Manager then informs vCenter Server which volumes to attach to the desktop. This background communication is essential in all deployments, to ensure that the current status of the environment is communicated to the App Volumes Manager. App Volumes Manager periodically checks with vCenter Server to find out what has changed in the environment.

 

 

Direct-to-host Mount Option

The direct-to-host connection option is recommended for deployment at scale because AppStacks and writable volumes are mounted quicker when ESXi directly mounts them, rather than waiting for vCenter Server to instruct ESXi to mount the volumes.

The benefit of the direct-to-host-connection option is that vCenter Server is not part of the data flow. This is particularly useful in large-scale deployments, where vCenter Server might get overloaded and create a bottleneck.

Note: The direct-to-host connection requires that all ESXi hosts use the same login and password for App Volumes operations. Root is not required and a custom role can be used to set up this connection.

 

 

vCenter Mount Option

Note: Not using the direct-to-host-connection option is adequate in small-scale deployments.
For production deployments, we recommend the direct-to-host option in order to minimise the load on vCenter Server and eliminate potential performance bottlenecks.

The following lessons in this module will teach you more about Load Balancing of App Volumes.

 

Configure Load Balancing for Horizon App Volumes



 

App Volumes Communication

To be understand the positioning of the load balancer in an App Volumes environment, you to have to understand the communication flow between App Volumes Manager, App Volumes Agent, vCenter, and the web interface for App Volumes.

 

Please refer to the KB that explains how to repace the certificates https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2095969

 

 

SSL Certificates and Load Balancers

 

In a typical load-balanced environment, you would be terminating SSL at load balancer level.

We provide a way to disable SSL from agent to manager, but it's not recommended to fall back to http communication.

 

 

 

HTTP vs HTTPS

HTTP

In load balancer deployments, you can use the following configuration:

The option is provided during installation.

If you want to enable HTTP at a later stage, they can add a block in nginx.conf file for enabling it.

HTTPS

App Volumes Manager listening only on HTTPS.

The best option would be to replace certificates of all App Volumes Managers with a trusted CA-signed certificate.

Alternative

You can disable certificate validation in the load balancer, but this is insecure.

If a self-signed certificate is used in the load balancer, and certificate validation in App Volumes agents was not disabled.

If "certificate validation" is disabled in the App Volumes agent.

If load balancer is using a CA-signed certificate.

 

 

Conclusion



 

You've finished Module 6 - Load Balancing for Horizon App Volumes

Congratulations on completing Module 6 - Load Balancing for Horizon App Volumes You should now have a foundational understanding of how to deploy and configure Horizon App Volumes in a load-balancing scenario.

For more details on how to configure Load balancing with F5 please refer to the lab below.

Proceed to any module below which interests you most.

 

 

 

For More Information

 

 Additional information on installation or configuration of Horizon Connection Servers

 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 7 - The Remote Experience (15 minutes)

Introduction to The Remote Experience



 

Introduction to The Remote Experience

You will learn about various topics that will enhance the user experience of a Horizon design.

 

This module contains the following topics:

 

 

Choosing a Display Protocol

A display protocol provides end users with a graphical interface to a remote desktop or application that resides in the data center. Depending on the client device, you can choose Blast Extreme, PCoIP (PC-over-IP), or Microsoft RDP (Remote Desktop Protocol).

You can set policies to control which protocol is used or allow end users to choose the protocol when they log in to a desktop.

 

Blast Extreme

This protocol is optimized for the mobile cloud, VMware Blast Extreme supports the broadest range of client devices that are H.264 capable. Of the display protocols, VMware Blast offers the lowest CPU consumption for longer battery life on mobile devices. VMware Blast Extreme can compensate for an increase in latency or a reduction in bandwidth and can leverage both TCP and UDP network transports.

The VMware Blast display protocol can be used for remote applications and for remote desktops.

Key features of VMware Blast Extreme include the following:

PCoIP (PC over IP)

PCoIP provides an optimized desktop experience for the delivery of a remote application or an entire remote desktop environment, including applications, images, audio, and video content for a wide range of users on the LAN or across the WAN. PCoIP can compensate for an increase in latency or a reduction in bandwidth.

The PCoIP display protocol can be used for remote applications and for remote desktops.

Key features of PCoIP include the following:

RDP (Remote Desktop Protocol)

RDP is the same multichannel protocol many people already use to access their work computer from their home computer. Microsoft Remote Desktop Connection (RDC) uses RDP to transmit data.

Microsoft RDP is a supported display protocol for remote desktops that use virtual machines, physical machines, or shared session desktops on an RDS host. (Only the PCoIP display protocol and the VMware Blast display protocol are supported for remote applications.) Microsoft RDP provides the following features:

 

 

 

Using Hosted Applications

You can use Horizon Client to securely access remote Windows-based applications, in addition to remote desktops.

With this feature, users see all the remote applications they are entitled to use in addition to remote desktops. Selecting an application opens a window for that application on the local client device, and the application looks and behaves as if it were locally installed.

Deploying remote applications in this way might be preferable to deploying complete remote desktops under the following conditions:

To use this feature, you install applications on a Microsoft RDS host. View hosted applications are delivered using either the Blast Extreme display protocol or the PCoIP display protocol, for an optimized user experience.

 

 

 

USB Devices

Administrators can configure the ability to use USB devices, such as thumb flash drives, cameras, VoIP (voice-over-IP) devices, and printers on the virtual desktop. This feature is called USB redirection and works using the Blast Extreme, PCoIP, or Microsoft RDP display protocol. A remote desktop can accommodate up to 128 USB devices.

You can also redirect locally connected USB thumb flash drives and hard disks for use in RDS desktops and applications.

In most cases, you cannot use a USB device in your client system and in your remote desktop or application at the same time. Only a few types of USB devices can be shared between a remote desktop and the local computer. These devices include smart card readers and human interface devices such as keyboards and pointing devices.

Administrators can specify which types of USB devices end users are allowed to connect to. For composite devices that contain multiple types of devices, such as a video input device and a storage device, on some client systems, administrators can split the device so that one device (for example, the video input device) is allowed but the other device (for example, the storage device) is not.

The USB redirection feature is available only on some types of clients. See the feature support matrix to find out whether this feature is supported on your particular type of client.

 

 

 

Real-Time Audio and Video

With the Real-Time Audio-Video feature, you can use your local computer's webcam or microphone on your remote desktop. Real-Time Audio-Video is compatible with standard conferencing applications and browser-based video applications, and supports standard webcams, audio USB devices, and analog audio input.

End users can run Skype, Webex, Google Hangouts, and other online conferencing applications on their virtual desktops. This feature redirects video and audio data to the remote desktop with a significantly lower bandwidth than can be achieved by using USB redirection. With Real-Time Audio-Video, webcam images and audio input are encoded on the client and then sent to the remote desktop. On the remote desktop the stream is decoded and played by a virtual webcam and virtual microphone, which can be used by the third-party application.

 

 

 

Using 3D Graphics Applications

NVIDIA GRID vGPU (shared GPU hardware acceleration)

This feature allows a physical GPU (graphical processing unit) on an ESXi host to be shared among virtual machines. Use this feature if you require high-end, hardware-accelerated workstation graphics.

AMD Multiuser GPU using vDGA

This feature allows multiple virtual machines to share an AMD GPU by making the GPU appear as multiple PCI passthrough devices. This feature offers flexible hardware-accelerated 3D profiles, ranging from lightweight 3D task workers to high-end workstation graphics power users.

Virtual Dedicated Graphics Acceleration (vDGA)

This feature dedicates a single physical GPU on an ESXi host to a single virtual machine. Use this feature if you require high-end, hardware-accelerated workstation graphics.

Virtual Shared Graphics Acceleration (vSGA)

This feature allows multiple virtual machines to share the physical GPUs on ESXi hosts. You can use 3D applications for design, modeling, and multimedia.

Soft 3D

Software-accelerated graphics allows you to run DirectX 9 and OpenGL 2.1 applications without requiring a physical GPU. Use this feature for less demanding 3D applications such as Windows Aero themes, Microsoft Office 2010, and Google Earth.

 

 

Streaming Multimedia to Desktops

The Windows Media MMR (multimedia redirection) feature, for Windows 7 and Windows 8/8.1 desktops and clients, enables full-fidelity playback on Windows client computers when multimedia files are streamed to a remote desktop.

With MMR, the multimedia stream is decoded on the Windows client system. The client system plays the media content, thereby offloading the demand on the ESXi host.

Media formats that are supported by Windows Media Player are: M4V; MOV; MP4; WMP; MPEG-4 Part 2; WMV 7, 8, and 9; WMA; AVI; ACE; MP3; WAV.

 

 

 

Printing from a Remote Desktop

The virtual printing feature allows end users on some client systems to use local or network printers from a remote desktop without requiring additional print drivers to be installed in the remote desktop operating system. The location-based printing feature allows you to map remote desktops to the printer that is closest to the endpoint client device.

With virtual printing, after a printer is added on a local client computer, that printer is automatically added to the list of available printers on the remote desktop. No further configuration is required. For each printer available through this feature, you can set preferences for data compression, print quality, double-sided printing, color, and so on. Users who have administrator privileges can still install printer drivers on the remote desktop without creating a conflict with the virtual printing component.

To send print jobs to a USB printer, you can either use the USB redirection feature or use the virtual printing feature.

Location-based printing allows IT organizations to map remote desktops to the printer that is closest to the endpoint client device. For example, as a doctor moves from room to room in a hospital, each time the doctor prints a document, the print job is sent to the nearest printer. Using this feature requires the printer drivers to be installed in the remote desktop.

 

 

 

Using Single Sign-On to Log In

The single-sign-on (SSO) feature allows end users to supply Active Directory login credentials only once.

If you do not use the single-sign-on feature, end users must log in twice. They are first prompted for Active Directory credentials to log in to View Connection Server and then are prompted to log in to their remote desktop. If smart cards are also used, end users must sign in three times because users must also log in when the smart card reader prompts them for a PIN.

For remote desktops, this feature includes a credential provider dynamic-link library.

True SSO

With the True SSO feature, introduced with Horizon 7 and VMware Identity Manager 2.6, users are no longer required to supply Active Directory credentials at all. After users log in to VMware Identity Manager using any non-AD method (for example, RSA SecurID or RADIUS authentication), users are not prompted to enter Active Directory credentials in order to use a remote desktop or application.

True SSO works by generating a unique, short-lived certificate for the Windows logon process. You must set up a Certificate Authority, if you do not already have one, and a certificate Enrollment Server in order to generate short-lived certificates on behalf of the user. You install the Enrollment Server by running the View Connection Server installer and selecting the Enrollment Server option.

True SSO separates authentication from access. User credentials are secured by a digital certificate. No passwords are vaulted or transferred within the data center.

 

 

 

Monitors and Screen Resolution

You can extend a remote desktop to multiple monitors. If you have a high-resolution monitor, you can see the remote desktop or remote application in full resolution.

Select the 'All Monitors' display mode to display a remote desktop on multiple monitors.

Using One Monitor in a Multiple-Monitor Setup

Using High-Resolution Mode

 

 

Lesson Summary

You have been introduced to Horizon features that are aimed at designing the best user experience for your implementation.  These features and options can be managed and implemented across all desktop pools, or selected desktop pools depending on the administrator needs.  For further detail, consult the VMware View Architecture Planning documentation located at: https://www.vmware.com/support/pubs/view_pubs.html

 

 

Conclusion



 

You've finished Module 7 - The Remote Experience

Congratulations on completing Module 7 - The Remote Experience. You should now have a foundational understanding of user experience features and options available to you when designing a Horizon environment.

Proceed to any module below which interests you most.

 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Module 8 - Horizon Pod and Block Design Considerations (30 minutes)

Introduction to Horizon Pod and Block Design



 

Introduction to Horizon Pod and Block Design

You will learn the foundational design constructs of a Horizon Design.  Pod, Blocks, and Clusters are the logical objects that define a modular, scalable, and predictable Horizon Design.  Understanding these objects will allow you, as the architect, the means to design and implement a robust and manageable Horizon design to service your enterprise

This Module contains the following lessons:

 

 

Horizon Pod and Block Design

 

The diagram depicts a logical representation of a typical modular Horizon design.  Creating a design using Pod and Block constructs allows you to efficiently grow a seamingly basic design into a complex enterprise grade design.

To start this journey, lets start with some simple definitions:

Horizon Pod:  In simple terms, this is a Horizon View installation.  The Pod is the logical component that defines the environment, maintains the resource inventory, and holds the entitlement rules.  There is a database that stores this information and this database is the defining boundary of the Horizon Pod.

Horizon Block:  A Block is a logical grouping of resources.  A Horizon Pod can contain a single Horizon Block or multiple Horizon Blocks.  The Horizon Block is a logical container of resources used for scalability.

vSphere Cluster:  The vSphere cluster is the group of hosts that provide the hardware resources to the Horizon Block.  The vSphere cluster consists of a vCenter Management Server and at least a number of identical ESXi hosts.  Virtual Machines running on the ESXi hosts within a cluster can take advantage of vSphere Distributed Resource Scheduling (DRS) and vSphere High Availibility (HA).  Each Horizon Block will contain one or more vSphere Clusters.

Use-Case:  A Use-Case is a grouping of users with similar resource needs.  Defining use-cases will vary with each company, but a good example to start with is your company department structure.  Examples of Use-Cases may be: Executives, Call Center Operators, Developers, and Engineering.  The Use-Case definition and size helps determine the tangible resources (such as RAM, CPU, and Storage) required to support the users.

Desktop Pool:  A Desktop Pool is a group of similarly configured and managed desktop virtual machines.  

 

 

 

Want to learn more?

The following lessons in this module will teach you more about Cloud Pod Architecture.

 

Pods, Blocks, and Clusters - Why do they matter?



 

Pods, Blocks, and Clusters - Why do they matter?

Why do they matter?  It's a good question with an easy answer:  To prevent an outage that could affect all your users.

When designing a Horizon Environment for end users, the goals and outcomes are a bit different than a design for a server farm.

Horizon designs must always consider the end users first.  This is a good thing, as the end users are the revenue generating entities of an enterprise.  They can also be among the most difficult aspects of a design.  We quickly find that end users have multiple requirements, work at different times, and want everything all the time.  The proper Horizon Design will provide all their needs.

First and foremost, consolidation should never be the primary goal in a Horizon design.  That's not to say consolidation isn't important, but there are factors that must be considered before consolidation.  Users will be interfacing directly with the environment and any latency due to undersized or overutilized resources will be experienced by everyone on the system.

 

 

What Hardware Do I Need?

Determining what host hardware to buy (or budget) is always the first thing anyone wants to know.  If you approach with a server consolidation mindset, you will be undersized every time and the design will most likely fail.  Ultimately the design needs to have hardware purchased and that's where the modular Pod and Block design comes into play.

A good Horizon Design will consider the end user requirements, the business goals, and operational aspects for the organization.  

So to answer the question of "What do I need for my design," you will start with an internal inventory to determine:

Next you will want to assess each Use-Case and determine the resource requirements for the Use-Case:

This is not an exhaustive list, but you get the idea.  

At the end of this 'assessment' phase, you should have answers to each of these items and will be ready to start an initial design

 

 

 

The Horizon Pod

The Pod is the largest grouping object to understand.  This is the Horizon View installation and a single Horizon Pod generally fulfils the needs of most designs.  There are situations where a single Horizon Pod is not sufficient and you will need additional Horizon Pods for your design.  You should consider these questions when determining the Horizon Pod requirements:

One Pod per data center:

One Pod per 10,000 users:

Complete isolation between internal and external users:

High Availability Implementations:

This should get you thinking about the big picture for Horizon designs.  Each situation is unique and there may be exceptions, but the general guiding principle is to define the Horizon Pod by the geographical location, user population, availibility, and isolation requirements of your business.

 

 

The Horizon Block

Now that you have defined the Horizon Pod for your design, the next design consideration is the Horizon Block.

The Horizon block is the scalable construct within a Horizon Pod.  The Horizon Block contains the vSphere clusters and ESXi hosts where the desktop virtual machines and the RDSH server virtual machines will run.  Additionally, each Horizon Block is managed by a vCenter Server to control provisioning and power operations on the virtual machines and cluster operations.

During your assessment phase, you determined the use cases, use case requirements, and use case sizes for the design.  The next goal is to map the use cases to Horizon Blocks.

There are two perspectives to consider when designing a Horizon Block, and your company business requirements will dictate which perspective is more important:

From a resource perspective, the Horizon Block is designed to provide predictable performance and to allow the Horizon environment to be expanded within the Horizon Pod as your business grows.  

From an availability perspective, the Horizon Block is designed around risk tolerance.  To minimize the risk of a potential component causing an outage, each Horizon Block provides a failure domain around a subset of resources and also minimizes maintenance windows across the entire design.

For the technical and operational aspects, your block design must consider the following items:

Each Horizon Block requires a vCenter Server.

The Horizon Block resources should be predictable.

Each Horizon Block contains one fundamental set of resources.

 

 

 

 

The vSphere Cluster

The ESXi hosts running virtual machines for the Horizon Block are members of a vSphere cluster.  The cluster is managed by the Horizon Block's vCenter Management Server.  Without getting in too deep regarding cluster operations and features, we will understand that DRS and HA features are configured on the Horizon Block clusters according to the requirements of the use case.

Horizon limits the size of a vSphere cluster to a maximum of 32 ESXi nodes.  Your Use-Case will ultimately map to a desktop pool hosted on a cluster.  The requirements of the desktop pool will be determined by the use case, and the cluster size will be determined by the resource requirements.  

There will be several options when it comes to selecting host hardware.  Your operational requirements, risk tolerance, and data center space will all play a factor in cluster design and host sizing.  Starting with the resource requirements of a single Use-Case, determine what 125% CPU and 125% RAM requirements are needed for that use case.  Find a host from your favorite vendor and determine how many hosts and what configuration will be required to provide the compute requirement across 31 or less hosts.  (Note: 125% CPU and RAM provides an 80% utilization maximum, 31 hosts allows 1 additional host to provide HA overhead - adjust as necessary)

If you find a host configuration that supports your use case requirements and fits within the 32 node limit, your cluster is sized appropriately.  You can scale-up the host resources using fewer hosts with greater VM density, or scale-out the host resources using more hosts with lesser VM density.  

When use cases vary in resource requirements, you need to consider the impact on the host.  It is possible to share a cluster with 'closely' matched use cases.  However, cluster resources will be consumed differently between these use cases making it difficult to project future resource requirements per use case.  

When use cases have drastically different resource requirements, separate clusters are necessary.  In this situation, a cluster will be dedicated to a use case.  As an example, users requiring 3D graphics hardware and large compute resources would warrant a dedicated cluster of high performance hosts to service the use case.  It is possible to have multiple clusters within the same Horizon Block provided the vCenter provisioning operations and the 2000 user limit is not impacted.

When implementing RDSH virtual machines to serve desktops or applications, dedicate a block and cluster to these virtual machines.

Cluster Design considerations:

 

 

 

 

Lesson Summary

You have learned about the fundamental building blocks of a Horizon Desktop design.  The pod, block, and cluster components are the sizing elements of an enterprise Horizon design.  

For small Horizon designs consisting of a couple hundred desktops; the pod, block, and cluster components may represent the same resource boundary.  However, a design that must support several thousand users will see clear distinctions between these design components.  Each component will contain a capacity limit and each design will need to consider these limits depending on the use case requirements and use case placement within the design.

The pod and block concept is an easy way to design scalability and provide predictability for a Horizon design.

 

Additional information and guidance can be found in the Horizon 7.1 Architecture Planning Documentation

 

Tested Limits and Best Practice Maximums



 

Tested Limits and Best Practice Maximums

This lesson will summarize the maximum limits for individual Horizon 7.1 design components.  

In many cases, the limits are the tested limits of the technology and may not be appropriate based on individual design requirements.

Consider design requirements, SLA, provisioning times, and risk tolerance when determining component design limits.

 

 

 

Lesson Summary

You have learned about the Limits for several design components of Horizon 7.1

Additional guidance can be found in the Horizon 7.1 Architecture Planning Documentation

 

 

 

Conclusion



 

You've finished Module 8 - Horizon Pod and Block Design Considerations

Congratulations on completing Module 8 - Horizon Pod and Block Design Considerations.  You should now have a foundational understanding of the Horizon Pod and Block design components and be able to start your Horizon design with confidence.

Proceed to any module below which interests you most.

 

 

 

How to End Lab

 

To end your lab click on the END button.  

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-1851-08-ADV

Version: 20170920-142602