Reference Architecture for Horizon

Overview

VMware Horizon View delivers a virtualized desktop infrastructure (VDI) to manage and deliver desktops and applications on demand. Horizon transforms static desktops into on demand, secure digital workspaces. It can be deployed on premises or on cloud ecosystems.

Avi Vantage for Horizon

Avi Vantage can be deployed on on-prem or on any cloud ecosystem which allows for easy deployment to load balance Horizon traffic in any ecosystem (on-prem, AVS, HCoA etc.). Avi offers real time application insights and wide range of metrics to simplify troubleshooting.

Note: The sample topology illustrates UAG deployment in a DMZ network. However, Avi Vantage supports deployment in both DMZ and non-DMZ networks.

Design Considerations

The considerations for deploying Avi for Horizon load balancing include:

1. Internal vs external clients
2. The number of public IPs available
3. National Institute of Standards and Technology (NIST) or Health Insurance Portability and Accountability Act (HIPAA) compliance
4. The smart card or True SSO used to authenticate
5. Multi site architecture (requires GSLB)
6. Sizing

Reference Architectures

Avi Vantage can be used as the load balancer for Unified Access Gateways (UAG), Horizon Connection Servers and App Volume Managers deployed as part of the Horizon solution.

Load Balancing for UAG

The following methods can be used for load balancing external traffic to UAG:

Deployment Method	Reccomended/ Legacy	Remarks	Reference
Single VIP with Two Virtual Services Using 307 Redirect Solution	Recommended for the use cases in NAT Environment (Users behind NAT or UAG servers behind NAT)	This method does not rely on source IP affinity, so it works well in the cases where there are clients behind a single NAT (an edge site) and all connections present the same source IP address.​	Configuration Guide
(n+1)VIP Using 307 Redirect Solution	Recommended if requirement is to bypass Avi for secondary protocol		Configuration Guide
Single VIP with two virtual services	Legacy	It does not work well in the cases where there are clients behind NAT.	Configuration Guide
(n+1)VIP	Legacy		Configuration Guide
Single L4 VIP virtual service	Recommended for compliance use cases	Required for HIPAA/NIST compliance and smart card authentication	Configuration Guide

Single VIP with Two Virtual Services Using 307 Redirect

In this design, a single VIP configured on the Avi load balancer would be used for handling both primary protocols and secondary protocols. The virtual IP (VIP) will be listening on HTTPS:443 and on the required TCP/UDP ports for secondary protocols.

Load balancer routes secondary protocols to the same UAG appliance as that selected for the primary Horizon protocol using host header set as part of 307 redirect mechanism as discussed here.

Since this does not rely on source IP affinity it works well in the cases where there are many clients behind a single NAT (an edge site) and all connections present the same source IP address. This is the recommended design option for UAG load balancing.

For more information, click here.

Use Cases

• All typical L7 deployments

Advantages

• Does not require multiple public virtual IP addresses.
• Uses L7 virtual service for HTTPS-XML, enabling rich analytics and logs to and from Avi Vantage to provide insights into the connections
• Is easy to configure and deploy.

(n+1) VIP Using 307 Redirect Solution

This method dedicates an individual virtual IP (VIP) to each appliance in addition to the primary load balanced Avi VIP. Only the initial request goes through Avi Vantage.
If there are two UAG appliances, then three VIPs would be required. The primary Horizon protocol on HTTPS port 443 is load balanced on Avi Vantage to allocate the session to a specific UAG appliance, based on the health and the load.
The secondary protocols can bypass the load balancers and go directly to the UAG. The blast and PCoIP External URLs must be configured to point to itself on each UAG In such deployments, only a single VIP for primary protocol is required.

For more information, click here.

Caveat

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

Advantages

• Does not rely on source IP affinity.

Single VIP with Two Virtual Services

In this design, a single VIP configured on the Avi load balancer would be used for handling both primary protocols and secondary protocols. The virtual IP (VIP) will be listening on HTTPS:443 and on the required TCP/UDP ports for secondary protocols.

Load balancer routes secondary protocols to the same UAG appliance as that selected for the primary Horizon protocol using the Source IP affinity.

If Source IP affinity is not the optimum choice for your environment, refer to the other methods of deployment as applicable.
The tunnel external URL, blast external URL and the PCoIP (PC over IP) external URL should be configured to the load balancer VIP/Fully Qualified Domain Name (FQDN) on the UAG.

Advantages

• Does not require multiple public virtual IP addresses
• Uses L7 virtual service for HTTPS-XML, enabling rich analytics and logs to and from Avi Vantage to provide insights into the connections
• Is easy to configure and deploy
• Using L7 for HTTPS XML and the tunnel enables the user to get rich analytics and logs to and from Avi Vantage to provide insights into the connections.

Caveat

• Relies on source IP address affinity which might not always be possible. Source IP affinity does not work where there are many clients behind a single NAT (an edge site) and all connections present the same source IP address.

Single L4 Virtual Service

This configuration option uses a single Virtual IP (VIP) and the load balancing is done at the TCP or UDP level.

Use Cases

• If smart card authentication is required, where the client cert is passed directly from the client to UAG using TLS and there cannot be an intermediate TLS terminator
• Where HIPAA or NIST compliance is needed. This deployment will be HIPAA or NIST compliant as the UAG terminates SSL
• Where a single public VIP and standard port numbers are required as we can have source IP affinity between primary and secondary protocols

Advantages

• Does not require multiple public VIP addresses
• Easy to configure and deploy

Caveats

• Rich analytics into the HTTPS-XML primary protocol will not be available on Avi Vantage
• Relies on source IP address affinity which might not always be possible. Source IP affinity does not work where there are many clients behind a single NAT (an edge site) and all connections present the same source IP address

(n+1) VIP

If source IP affinity is not the desired option for an environment such as Horizon deployed on an edge site behind a single network address translated IP, then this approach could be used for load balancing Unified Access Gateway (UAG) with Avi Vantage. This method dedicates an individual virtual IP (VIP) to each appliance in addition to the primary load balanced Avi VIP. If there are two UAG appliances, then three VIPs would be required.
The primary Horizon protocol on HTTPS port 443 is load balanced on Avi Vantage to allocate the session to a specific UAG appliance, based on the health and the load.

The tunnel external URL, blast external URL and the PCoIP external URL should be configured to the respective UAG IP as the UAG directly receives the traffic bypassing the load balancer.

Caveats

• Requires an additional public facing VIP for each UAG appliance in addition to the primary load balanced VIP
• Using L7 for HTTPS-XML and the tunnel enables user to get rich analytics and logs to and from Avi Vantage to provide insights into the connections
  The secondary protocols can bypass the load balancers and go directly to the UAG. The blast and PCoIP External URLs must be configured to point to itself on each UAG.
  In such deployments, only a single VIP for primary protocol is required.

Advantages

• Does not rely on source IP affinity
• Uses standard port numbers

Avi Vantage for Connection Server Load Balancing

In a deployment with multiple connection servers, Avi Vantage can be used to load balance traffic to the connection servers as well. There are two ways traffic can reach connection server:

1. From external clients via UAG
2. From internal clients directly to connection server

For external clients, the traffic reaches connection servers via UAG.
For internal clients, the traffic reaches the connection servers directly.
On using SmartCard or SecureID with True SSO or RADIUS with TrueSSO as the authentication method, the UAG should communicate directly with connection servers without any load balancers in between.

External Clients Traffic

Horizon traffic from external clients on the internet first lands on UAG via the load balancer. The primary protocol traffic is sent to the connection server and the secondary protocols are sent directly to the virtual desktops or RDS hosts. An L7 virtual service for port 443 with connection servers as the pool members can be configured with consistent hash with source IP as load balancing algorithm to ensure traffic from same UAG goes to same connection server if required. The Avi VIP should be entered as the connection server IP on the UAG. The SSL fingerprint configured on UAG would be that of Avi Vantage VIP which is in front of the connection servers.

From external clients via UAG
( SecureID/Radius with True SSO/Smart Card Authentication)

Horizon traffic from external clients is as shown below:

For the below listed authentication methods used for Horizon, there should be no load balancers between the UAG and connection servers. The UAG should communicate directly with the connection servers as required for the authentication methods:

• Smart card authentication
• SecureID with True SSO
• RADIUS with True SSO

Internal Client Traffic

Avi Vantage can be deployed in front of Connection Servers for internal clients. Typically, for internal clients, the primary protocol will be load balanced between connection servers while the secondary protocols are routed directly to the virtual desktops or RDS hosts, bypassing the load balancer. The same virtual service can be used for load balancing both internal and external clients to the connection servers as shown below:

App Volume Manager Load Balancing

Load balancing for app volume manager can be achieved by configuring an L7 virtual service with HTTPS application profile.

App Volumes servers do not support connections for the same client originating from different source IP addresses. In the case where the virtual service is deployed as an Active/Active scale out, it is possible that multiple connections from the same client are processed by different Service Engines. As each Service Engine uses a distinct SNAT IP, the servers may see multiple connections for the same client with a different source IP, resulting in authentication failures. To address this issue, use either one of the options given below:

• Option 1: Use an Active/Standby Service Engine group when load balancing App Volumes Or
• Option 2: If native scale out is being used, configure the flow distribution algorithm to be based only the client IP address rather than the client IP and port through the CLI:
  

configure virtualservice <appvol-vs-name>
flow_dist flow_dist consistent_hash_source_ip_address
save

Note:Option 2 is only applicable in the case of native scale out. In the case where ECMP scaleout is used (for example with BGP), the distribution of flows across Service Engines is dependent on the ECMP hash algorithm used by the upstream router. If that hash is based on the full 5-tuple (source/destination IP/port/protocol) then this issue will be encountered.

Multi-site with GSLB

Avi Vantage can be configured with GSLB using any load balancing algorithm (geo, source IP based etc) to direct the traffic to the required site. This avoids east-west traffic even within the same geo. Site 1 could be on any ecosystem and different to the site 2 ecosystem. For example, site 1 could be on prem and site 2 could be on VMC.

High Availability

It is recommended to deploy the Avi Service Engines in the elastic Active/Active high availability mode. In active/active high availability deployment mode, the Virtual Service is placed on both Service Engines. Hence a failure of one Service Engine will momentarily affect only the user traffic flowing via that particular SE. For more information Refer to the Overview of Avi Vantage High Availability article.

Note: For best performance, it is recommended to use separate Avi SEs for Horizon. Do not place any other virtual service on the same SEs.

Sizing Considerations

Avi Controller sizing: It is recommended to have 3 Controllers in a cluster configured for production deployments. Avi controller requires minimum specifications of CPU, RAM and storage. Refer to the Avi Controller Sizing article for sizing guidelines.

Avi SE sizing

For Horizon deployments, the SE sizing depends on number of users and the throughput per user. SE sizing also depends on the applications accessed over the VDI as higher bandwidth apps like video and 3D modeling would require higher throughput. Highest contributing factor to throughput would be the secondary protocols (Blast/PCoIP).

The number of SEs depends on the deployment model chosen to load balance UAGs as discussed below:

1. Single VIP with two virtual services using 307 redirect solution : The Blast and PCoIP protocols flow via the Avi SEs, hence the SEs have to be sized for the Blast and PCoIP throughput.

2. (n+1) VIP using 307 redirect solution: Only the XML-API protocol flows via the Avi SE and hence the number of SEs required would be lesser.

3. Single VIP with Two Virtual Services:The Blast and PCoIP protocols flow via the Avi SEs, hence the SEs have to be sized for the Blast and PCoIP throughput.
4. Single L4 Virtual Service: The Blast and PCoIP protocols flow via the Avi SEs, hence the SEs have to be sized for the Blast and PCoIP throughput.
5. (n+1) VIP: Only the XML-API protocol flows via Avi SE hence the number of SEs required would be lesser.
6. It is recommended to have separate SEs for connection server load balancing to avoid traffic to flow back into the DMZ for internal clients.

Active/Active high availability configuration requires a minimum of two service engines.

Each site will require to be sized for its own SEs with an additional SE for GSLB requirement between sites.

Sizing Examples

(Single VIP with Two Virtual Service and Single L4 Virtual Service)

Example 1
250 users with small workloads (email, MS Office applications, multiple monitors) in a single site.

No. of Users	Approximate Throughout Per User	Total Throughput = No. of Users X Throughput Per User	Active/Active HA
250	600 Kbps	150 Mbps	1 Core SE X 2

Example 2
1500 users with medium workloads (frequent file transfers, complex document editing, 480p video, MS office applications) in a single site.

Number of Users	Approximate Throughout Per User	Total Throughput = Number of Users X Throughput Per User	Active/Active HA
1500	2 Mbps	3 Gbps	2 Core SE X 2

Example 3
1000 users with high workloads (3D modeling, Hi DeF video, 3D graphics) in a single site.

Number of Users	Approximate Throughout Per User	Total Throughput = Number of Users X Throughput Per User	Active/Active HA
1000	20 Mbps	20 Gbps	4 Core SE X 4

Notes:

• For video or jitter sensitive applications, dedicated dispatcher is recommended for best performance.
• For high bandwidth applications like video, L3 scaleout is recommended for best performance.

Example 4
5000 users with medium workloads(frequent file transfers, complex document editing, 480p video, MS office applications) in a single site.

No. of Users	Approximate Throughout Per User	Total Throughput = No. of Users X Throughput Per User	Active/Active HA
5000	2 Mbps	10 Gbps	3 Core SE X 2

Note: It is recommended to have dedicated dispatcher for higher PPS for better performance.

Example 5
10000 users with small workloads (e-mail, MS Office applications, multiple monitors) in a single site.

No. of Users	Approximate Throughout Per User	Total Throughput = No. of Users X Throughput Per User	Active/Active HA
10000	600 Kbps	6 Gbps	2 Core SE X 2

The summary of sizing reference for a single site is as shown below:

Throughput Per Users	Small (Maximum of 600 kbps per user)	Medium (Maximum of 2 Mbps Per User)	Large (Maximum of 20 Mbps Per User
100	1 Core X 2 SEs	1 Core X 2 SEs	1 Core X 2 SEs
700	1 Core X 2 SEs	1 Core X 2 SEs	4 Core X 3 SEs
1000	1 Core X 2 SEs	1 Core X 2 SEs	4 Core X 4 SEs (L3 scaleout is recommended)
5000	2 Core X 2 SEs	4 Core X 2 SEs	4 Core X 16 (L3 scaleout is required)
10000	2 Core X 2 SEs	4 Core X 4 SEs (L3 scaleout is recommended)	4 Core X 32 SEs (L3 scaleout is required)

Sizing Examples for n+1 VIP

Number of Users	Number of SEs
Upto 1000 users	1 core * 2 SEs
1000 - 5000 users	2 core * 2 SEs
5000 - 10000 users	3 core * 2 SEs

Sizing Examples for Connection Server Load Balancing

Number of Users	Number of SEs
Upto 1000 users	1 core * 2 SEs
1000 - 5000 users	2 core * 2 SEs
5000 - 10000 users	3 core * 2 SEs

Sizing with GSLB

GSLB requires 1 SE per site. This can be a 1 core SE for GSLB for Horizon. For example, 250 users with small workloads (email, MS Office applications, multiple monitors) in site 1. 250 users with high workloads (3D modeling, Hi DeF video, 3D graphics) in site 2.

Site	Number of Users	Approximate Throughput per User	Total Throughput = Number of Users X Throughput per User (Maximum of 20 Mbps Per User	Number of SEs Active/Active HA	GSLB
Site 1	250	600 Kbps	150 Mbps	1 core SE X 2	1 core SE
Site 2	250	600 Kbps	150 Mbps	1 core SE X 2	1 core SE
Total Cores = 6				4	2

Suggested Reading

• 307 with 2 virtual services and single VIP
• Load Balancing for Horizon Environments in (n+1) Mode using 307 Solution
• VMware NSX Advanced Load Balancer in Azure
• Load Balancing UAGs in AVS