I’ve been spending a lot of time in the “VMware Horizon*¹” sub-Reddit lately where I’ve been trying to help others with their Horizon questions. One common theme that keeps popping up is regarding load balancing, and I decided that it would be easier to write a blog post to address the common load balancing scenarios and use cases than rewriting or pasting a long-winded reply in each thread.

Load balancing is an important part of designing and deploying a Horizon environment. It is an important consideration for service availability and scalability, and there are multiple Techzone articles that talk about load balancing. I have links to some of these articles at the end of this post.

How load balancing fits into a Horizon deployment

Horizon can utilize a load balancer in three different ways. These are:

• load balancing the Horizon 8 Connection Servers 
• load balancing the Unified Access Gateways in Horizon 8 deployments
• load balancing App Volumes Managers.

While App Volumes can also benefit from a load balancer, I won’t be covering that topic in this post. I also won’t be covering global load balancing or multi-site load balancing, and I won’t be doing a comparison of different load balancers. If your question is “which load balancer should I use?” my answer is “yes” followed by “what are your requirements?”

Load balancing for Horizon Connection Servers (CS) and Unified Access Gateways (UAG) seems pretty simple. At least, it seems simple on the surface. But every load balancer or load balancer-as-a-service is implemented differently, and this may require different architectures to achieve the same outcome.

This post is going to focus on load balancing Internet-facing Unified Access Gateways in external access scenarios as this is what most people seem to struggle with.

Why Deploy A Load Balancer With Horizon

So let’s get the first question out of the way.  Why should you load balance your Horizon deployment?  What benefits does it provide?  

There are two reasons to deploy a load balancer, and they are somewhat related.  The first reason is to improve service availability, and the second reason is to support additional user sessions. Both of these are accomplished the same way – horizontally scaling the environment by adding additional CSes or UAGs. 

Adding additional CSs and UAGs increases the number of concurrent sessions that our environment can support, and it increases the availability of the Horizon service. With proper health checks enabled, you can maintain service availability even if a CS or UAG goes offline because the load balancer will just direct new sessions to other components that are available.

We can also provide a consistent user experience by using a single URL to access the service so users do not need to know the URL for each Connection Server or UAG.

Some load balancers can do more than just load balancing between components. Many load balancers can provide SSL offloading services. Some load balancers add security features, real-time analytics, web application catalogs, or other features. Those are out-of-scope for this guide, but it is important to understand what capabilities your load balancer solution can provide as this can shape your desired outcome.

Understanding Horizon Connectivity Flows

Before we talk about load balancing options for Horizon, it’s important to understand traffic flows between the Horizon Client, Unified Access Gateway, Connection Server, and the agent that is deployed on the virtual desktop or RDSH server.

Horizon uses two main protocols.  These are:

• XML-API over HTTPS: This is the protocol used for authentication and session management. The documentation considers this the “primary protocol.”
• Session Protocol Traffic: This is the protocol used for communication between the Horizon Client and Agent. Horizon has two protocols, PCoIP and Blast, and can use an HTTPS tunnel for side channel traffic like Client Drive Redirection (CDR) and Multimedia Redirection (MMR). The documentation refers to these protocols as “secondary protocols.”

Horizon also requires session affinity. When connecting to an environment, a load balancer will direct the user to a UAG or Connection Server to authenticate.  All subsequent primary and secondary traffic must be with that UAG or Connection Server. If you do not have session affinity, then a user will be required to reauthenticate when the load balancer directs their session to a new UAG or Connection Server, and it can interrupt their access to their sessions.

There are multiple ways to set up session affinity including Source IP Persistence, using multiple VIPs with one VIP mapped to each UAG, and providing a public IP for each UAG.

So what does session traffic flow look like?  The Omnissa Techzone page has a really good explanation that you can read here.

Figure 1: Horizon Traffic Flow with UAGs and Load Balancers (Retrieved from https://techzone.omnissa.com/resource/understand-and-troubleshoot-horizon-connections#external-connections)

High-Level Horizon Load Balancer Architectures

There are two deployment architectures I’ve regularly encountered when designing for external access.  

The first, which I will refer to as N+1, is to just use the load balancer for XML-API over HTTPS traffic.  In this scenario, the XML-API over HTTPS traffic will be sent through the load balancer, and any session protocol (or secondary) traffic will occur directly with the UAG.  When configuring your UAGs in an N+1 scenario, you need to provide a unique URL for the Blast Secure Gateway or a unique public IP address for the PCoIP Secure Gateway, and your SSL certificate needs to contain subject alternative names for the load balanced URL and the UAG’s unique URL. 

(The Unified Access Gateway also supports HTTP Host Redirection for Horizon environments, but this is only used in some specific load balancer scenarios.)

The second deployment architecture is having all Horizon traffic pass through the load balancer. This includes both the XML-API over HTTPS and session protocol traffic.  This deployment option is typically used in environments where there is a limited number of public IP addresses.  

Session Affinity and throughput are the biggest concerns when using this approach.  The load balancer appliance can become a traffic bottleneck, and it needs to be sized to handle the number of concurrent sessions.  Session affinity is also a concern as an improperly configured load balancer can result in disconnects or failure to launch a session. 

Load Balancing Options for Horizon

At a high level, here are three categories of load balancers that can be used with Horizon.  These are:

• 3rd-Party external load balancers like NSX Advanced Load Balancer (Avi), F5, Netscaler, Kemp and others. This can also include open-source solutions like Nginx or HAProxy.
• Cloud Load Balancer Services
• Unified Access Gateway High-Availability

Unified Access Gateway High Availability

I want to talk about the Unified Access Gateway High-Availability feature first.  This is probably the most misunderstood option, and while it can be a great solution for some customers, it will not be a good fit for many customers. It’s worth reading the documentation on this feature if you’re considering this option.  

When deployed for Horizon, UAG HA uses Round Robin with Source IP Affinity for directing traffic between UAGs. But unlike other options, it can only provides high availability for the XML-API over HTTPs traffic.  It does not provide high availability for session protocol traffic like Blast or PCoIP.  

If you are looking to use this feature in an Internet-facing scenario, you would need N+1 public IP addresses and DNS names, where N is the number of UAGs you are deploying or plan to deploy plus one for the load balanced VIP shared by all of the UAGs. This is because the Horizon Client needs to be able to reach the UAG that it authenticated on for session traffic.

Unified Access Gateway High Availability may also not work in some public cloud scenarios where you are deploying into a native public cloud.

External 3rd-Party Load Balancers

The next option is the 3rd-party external load balancer. This is your traditional load balancer.  It can provide the most deployment flexibility, and most vendors have a guide for deploying their solution with Horizon.  

Third-party load balancers may also provide their own value-added features on top of basic load balancing. F5, for example, can integrate into Horizon when using their iApp, and the Avi documentation contains deployment guides for multiple customer deployment scenarios.

There are also open-source options here – NGINX and HAProxy being the two most common in my experience – but there may be some tradeoffs. Open-source HAProxy only supports TCP traffic with UDP load balancing included in their paid enterprise product. Open-source NGINX can support TCP and UDP traffic, but active health checks are part of the paid product (although there are ways to work around that – I just haven’t tested them any).

Cloud Native Load Balancer-as-a-Service

The final option to consider is Cloud Native Load Balancer-as-a-Service options.  These are useful if you are deploying into a cloud-based VMware SDDC Service like Google Cloud VMware Engine, Azure VMware Solution, or Oracle Cloud VMware, or into a native public cloud like Amazon Web Services for Horizon on Amazon Workspaces Core and EC2.

There are many varieties of cloud-native load balancer services. These come with different feature sets, supported network topologies, and price points. Some load balancing services only support HTTP and HTTPs, others can support all TCP and UDP traffic. Some only work with services that are in the same VCP or vNET as the load balancer while others can provide load balancing to services in other networks or even endpoints in remote data centers over a WAN or VPN connection.  

Public cloud scenarios are usually good for the N+1 IP deployment model.  Public cloud providers have large pools of IPv4 addresses that you can borrow from for a very small monthly fee.

Do I Need a Load Balancer Between My Unified Access Gateways and Connection Servers?

One of the benefits the UAG had over the old Horizon Security Server was that you didn’t need to map each UAG to a Connection Server. You could point them at a load balanced internal URL, and if a Connection Server went offline, the internal load balancer would just direct new sessions to a different Connection Server.

This was much easier than trying to load balance Security Servers, where complicated health check rules were required to detect when a Connection Server was down and take the Security Server offline.

But do you need a load balancer between the UAGs and Connection Servers?

Surprisingly, the answer is no.  While this is a supported deployment, it isn’t required. And it doesn’t require any complex health check setups.  

When configuring a load balancer health check for Horizon, you should point to favicon.ico. The UAG is a reverse proxy, and it proxies the favicon.ico file from the Connection Server (or load balanced set of Connection Servers).  If the Connection Server goes offline, the UAG health check will fail and the load balancer will mark it as down.

Questions to Ask When Getting Started with Horizon Load Balancers

Before we can start architecting a load balancer solution for Horizon, we have to define what our requirements and outcomes are. These should be defined during your discovery or design phase by asking the following questions:

1. Where are you deploying or hosting the environment?
2. What load balancers do you have in place today for other services? What sort of traffic types do your existing load balancers support? How much throughput can they handle?
3. What do your internal and external user traffic flows look like (or what do you want them to look like)? Are you currently or planning on sending both internal and external user sessions through UAGs or just external users?
4. Do you have any requirements around multi-factor authentication, Smart Card support, or TrueSSO?
5. What requirements does your security team have?
6. What is your budget?
7. How many public IP addresses do you have access to or are available to you for external access?

The answers to these questions will help define the load balancer and external access architecture. 

Learning More

If you want to learn more about load balancing Horizon environments, you can check out the following resources from Omnissa and VMware by Broadcom.  You should also check with your preferred load balancer vendor to see if they have any Horizon configuration guides or reference architectures.

• https://techzone.omnissa.com/resource/load-balancing-unified-access-gateway-horizon#purpose-of-this-tutorial
• https://techzone.omnissa.com/resource/understand-and-troubleshoot-horizon-connections#primary-and-secondary-protocols
• https://docs.vmware.com/en/VMware-NSX-Advanced-Load-Balancer/30.1/Solutions-Guide/GUID-643672EE-CA22-44EF-AB34-74E7881E5BA0.html
• https://docs.omnissa.com/bundle/UnifiedAccessGatewayDeployandConfigureV2312/page/UnifiedAccessGatewaySupportforHTTPHostRedirect.html

1. Yes…I am aware that the new name will be Omnissa Horizon, but this is the name of the channel until someone with admin rights changes it. I don’t want to hear it, Rob… ↩︎