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.
Design Considerations
The considerations for deploying Avi for Horizon load balancing include:
- Internal vs external clients
- The number of public IPs available
- National Institute of Standards and Technology (NIST) or Health Insurance Portability and Accountability Act (HIPAA) compliance
- Source IP address affinity requirement
- The smart card or True SSO used to authenticate
- Multi site architecture (requires GSLB)
- 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.
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.
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 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:
- From external clients via UAG
- 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.
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:
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.
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:
- 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.
- 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.
- (n+1) VIP: Only the XML-API protocol flows via Avi SE hence the number of SEs required would be lesser.
- 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 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 |
| 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 |