Page 1 of 14 - Avi Networks · Design Considerations The considerations for deploying Avi for Horizon load balancing include: 1. Internal vs external clients 2. The number of public

Page 1 of 14

Avi Networks — Technical Reference (18.2)Reference Architecture for Horizon

Copyright © 2020 Avi Networks, Inc. Page 2 of 14

view onlineReference Architecture for Horizon

OverviewVMware 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 OverviewThe 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 ComponentsThe 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 HorizonAvi 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.

https://avinetworks.com/docs/18.2/avi-horizon-reference-architecture-guide/



Design ConsiderationsThe 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 ArchitecturesAvi 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 Single L4 * VIP virtual service (n+1) VIP

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 addressesUses L7 virtual service for HTTPS-XML, enabling rich analytics and logs to from Avi Vantage to provide insights into the connectionsIs 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 terminatorWhere HIPAA or NIST compliance is needed. This deployment will be HIPAA or NIST compliant as the UAG terminates SSLWhere 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 addressesEasy to configure and deploy

Caveats

Rich analytics into the HTTPS-XML primary protocol will not be available on Avi VantageRelies 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) VIPIf 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 VIPUsing 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 affinityUses standard port numbers

Configuration Summary

<th>Design Option</th>

<th>HTTPS/XML-API via Avi Vantage</th>

<th>Blast/PCoIP via Avi Vantage</th>

<th>Source IP Persistence Required</th>

<th>SSL Termination for L7</th>

<th>Remarks</th>

<td>L7+L4 virtual service Shared VIP</td>

<td>Yes</td>

<td>Yes</td>

<td>Yes</td>

<td>Yes</td>

<td> </td>

<td>L4 virtual service</td>

<td>Yes</td>

<td>Yes</td>

<td>Yes</td>

<td>No</td>

<td>Required for HIPAA/NIST compliance and smart card authentication</td>



1. 2.

<td>(n+1) VIP</td>

<td>Yes</td>

<td>No</td>

<td>No</td>

<td>Yes</td>

<td>Hub sites behind network address translated IP</td>

<td>Connection Servers</td>

<td>Yes</td>

<td>No</td>

<td>Yes</td>

<td>Yes</td>

<td>Internal clients</td>

Avi Vantage for Connection Server Load BalancingIn 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 UAGFrom 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.



1.

2.

3.

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

article. Vantage High Availability

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 article for sizing Avi Controller Sizingguidelines.

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.

https://avinetworks.com/docs/18.2//overview-of-vantage-high-availability/

https://avinetworks.com/docs/18.2//overview-of-vantage-high-availability/

https://avinetworks.com/docs/18.2//avi-controller-sizing/



4. 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 1250 users with small workloads (email, MS Office applications, multiple monitors) in a single site.

<th>No. of Users</th>

<th>Approximate Throughout Per User</th>

<th>Total Throughput = No. of Users X Throughput Per User</th>

<th>Active/Active HA</th>

<td>250</td>

<td>600 Kbps</td>

<td>150 Mbps</td>

<td>1 Core SE X 2</td>

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

<th>Number of Users</th>


<th>Total Throughput = Number of Users X Throughput Per User</th>


<td>1500</td>

<td>2 Mbps</td>

<td>3 Gbps</td>


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



<th>Total Throughput = Number of Users X Throughput Per User</th>




<td>1000</td>

<td>20 Mbps</td>

<td>20 Gbps</td>


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 45000 users with medium workloads(frequent file transfers, complex document editing, 480p video, MS office applications) in a single site.





<td>5000</td>

<td>2 Mbps</td>

<td>10 Gbps</td>


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

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





<td>10000</td>

<td>600 Kbps</td>

<td>6 Gbps</td>


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



<th>Throughput Per Users</th>

<th>Small<br>(Maximum of 600 kbps per user)</th>

<th>Medium<br>(Maximum of 2 Mbps Per User)</th>

<th>Large<br>(Maximum of 20 Mbps Per User</th>

<td>100</td>

<td>1 Core X 2 SEs</td>



<td>700</td>




<td>1000</td>



<td>4 Core X 4 SEs (L3 scaleout recommended)</td>

<td>5000</td>



<td>4 Core X 16 (L3 scaleout required)</td>

<td>10000</td>




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

<th>Site</th>


<th>Approximate Throughput per User</th>

<th>Total Throughput = Number of Users X Throughput per User<br>

(Maximum of 20 Mbps Per User</th>

<th>Number of SEs Active/Active HA</th>

<th>GSLB</th>

<td>Site 1</td>

<td>250</td>

<td>600 Kbps</td>

<td>150 Mbps</td>

<td>1 core SE X 2</td>

<td>1 core SE</td>

<td>Site 2</td>

<td>250</td>

<td>600 Kbps</td>

<td>150 Mbps</td>

<td>1 core SE X 2</td>

<td>1 core SE</td>

Total Cores = 6

Suggested ReadingConfiguration GuideGSLB Configuration Guide for Horizon

https://avinetworks.com/docs/18.2//configure-avi-vantage-for-vmware-horizon/

https://avinetworks.com/docs/18.2//gslb-for-horizon-in-avi-vantage/

Documents

Page 1 of 14 - Avi Networks · Design Considerations The considerations for deploying Avi for Horizon load balancing include: 1. Internal vs external clients 2. The number of public