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 Architecture Overview

The Avi Vantage platform is built on software-defined principles, enabling a next generation architecture to deliver the flexibility and simplicity expected by IT and lines of business. The Avi Vantage architecture separates the data and control planes to deliver application services beyond load balancing.

Avi Vantage Components

The Avi Vantage platform has two core components:

  • Avi Controller
  • Avi Service Engines

Avi Controller

The Avi Controller is the single point of management and control that serves as the brain of Avi Vantage. Avi Controllers continually exchange information securely with the SEs and with one another. The health of servers, client connection statistics, and client-request logs collected by the SEs are regularly offloaded to the Controllers, which share the work of processing logs and aggregating analytics.

Avi Service Engine

Avi Service Engines (SEs) handle all data plane operations within Avi Vantage by receiving and executing instructions from the Controller. The SEs perform load balancing and all client- and server-facing network interactions.

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. Avi offers real time application insights and wide range of metrics to simplify troubleshooting.

Avi Vantage for Horizon

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. Source IP address affinity requirement
  5. The smart card or True SSO used to authenticate
  6. Multi site architecture (requires GSLB)
  7. Sizing

The same deployment designs can be used both on premises on vCenter and on VMware Cloud.

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:

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.

Single VIP Two Virtual Services

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.

Use Cases

The use cases for this design are:

  • All typical Horizon 7 deployments
  • Cases 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 virtual IP addresses
  • Uses L7 virtual service for HTTPS-XML, enabling rich analytics and logs to from Avi Vantage to provide insights into the connections
  • Is easy to configure and deploy

Caveats

  • 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. Single L4 VIP Virtual Service

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. (n+1) VIP 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 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

Configuration Summary

Design Option HTTPS/XML-API via Avi Vantage Blast/PCoIP via Avi Vantage Source IP Persistence Required SSL Termination for L7 Remarks
L7+L4 virtual service Shared VIP Yes Yes Yes Yes
L4 virtual service Yes Yes Yes No Required for HIPAA/NIST compliance and smart card authentication
(n+1) VIP Yes No No Yes Hub sites behind network address translated IP
Connection Servers Yes No Yes Yes Internal clients.
Both L4 and L7 virtual services are supported to Load balance traffic to connection servers.ou can choose to use either one, as required. Refer to the Configure Avi Vantage for VMware Horizon article to know more.

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. External Clients 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.

It is recommended to use a separate SE group for load balancing Connection Servers to avoid flow of DMZ and non DMZ traffic via the same SEs.

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

Horizon traffic from external clients is as shown below: External Clients

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. Internal Clients

The same virtual service can be used for load balancing both internal and external clients to the connection servers as shown below: Internal and External Clients

App Volume Manager Load Balancing

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

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. Multi-site with GSLB

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:The Blast and PCoIP protocols flow via the Avi SEs, hence the SEs have to be sized for the Blast and PCoIP throughput.
  2. 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.
  3. (n+1) VIP: Only the XML-API protocol flows via Avi SE hence the number of SEs required would be lesser.
  4. SE Group Separation : It is recommended to have separate SEs for connection server load balancing to avoid traffic to flow back into the DMZ for internal clients. Additional SEs are required per pod to load balance connection servers. Please refer sizing examplesbelow.

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 recommended)
5000 2 Core X 2 SEs 4 Core X 2 SEs 4 Core X 16 (L3 scaleout required)
10000 2 Core X 2 SEs 4 Core X 4 SEs (L3 scaleout recommended) 4 Core X 32 SEs (L3 scaleout recommended)

Sizing Examples for n+1 VIP

Number of Users Number of SEs
Upto 1000 users 1 core * 2 SEs
More than 1000 users 2 core * 2 SEs

Sizing Examples for Connection Server Load Balancing

Number of Users Number of SEs
Upto 1000 users 1 core * 2 SEs
More than 1000 users 2 core * 2 SEs

Sizing Examples with Separate SEs for Connection Server and Single VIP with two Virtual Services for UAG

Number of Users Throughput per user Total Throughput No of SEs for UAG No of SEs for Connection Servers Total Cores required
1500 2 Mbps 3 Gbps 2 Core SE*2 2 Core SE*2 8 cores
10000 2 Mbps 20 Gbps 4 Core SE*4 2 Core SE*2 8 cores

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