Author: Craig

Load balancing Horizon View Connection and Security Servers is key to any VDI design, the ability to provide connectivity to a desktop internally or externally is a must.  The bad news is that Horizon View doesn’t come with any inbuilt load balancing techniques.

As a Horizon View Architect, we have four options open to us:

1. Don’t Load Balance
2. Use DNS Round Robin
3. Use Windows Network Load Balancing
4. Use a Load Balancer

For the purpose of this blog post, I’m going to discount Option 1 as it’s self explanatory. To perform any type of load balancing you need to have two target Connection or Security Servers. Let’s explore the rest of the options.

DNS Round Robin

This is the simplest form of load balancing.  Creation of two ‘A’ records pointing to different View Connection Servers.

When a client resolves view.vmfocus.com the DNS server will send both IP address’s to the client.  The client will always use the first one returned e.g.

view.vmfocus.com 10.0.0.1 10.0.0.2

The DNS server is intelligent, so that when the next client resolves view.vmfocus.com the DNS server again sends both IP Address’s.  However this time they are returned the other way round e.g.

view.vmfocus.com 10.0.0.2 10.0.0.1

DNS Round Robin Advantages

• It’s simple and easy to configure

DNS Round Robin Disadvantages

• Their is no monitoring of the Horizon View Connection Servers at any layer of the OSI model.  If a Horizon View Connection server has an issue or is powered off for maintence, DNS Round Robin will continue to send client connections.
• After the initial connection to the ‘A’ record view.vmfocus.com the client (local PC) caches the IP address that view.vmfocus.com resolves to.  Only when the TTL expires will the client (local PC) go to the DNS server to request another record which may be the same as the first!

Windows Network Load Balancing

More intelligent than DNS Round Robin is Windows Network Load Balancing which operates at Layer 3 of the OSI model.  A special driver is installed on each Windows host and a ‘cluster IP address’ is created.

When a client resolves view.vmfocus.com the Cluster will distribute the incoming connection to the appropriate Horizon View Connection Server, this can be configured on a weighted basis e.g.

1. View Connection Server 1 – 10
2. View Connection Server 2 – 90

Which means that 90% of the traffic will be directed to View Connection Server 2.

The servers in the cluster are rather chatty, exchanging heartbeat messages, if a server isn’t reached within five seconds it is failed and any new connections are sent to other surviving servers.

Windows Network Load Balancing Advantages

• Load can be distributed between the Horizon View Connection Server members using a weighted average.
• Support for up to 32 servers in a cluster
• Add/Remove servers into the cluster for expansion/patching
• Detect server failure at network level
• Included as part of Windows Server 2003/2008/2012

Windows Network Load Balancing Disadvantages

• Fairly complicated to configure and maintain
• Extensive network considerations such as separate Port Groups/VLANs to reduce network heartbeat chatter plus  MAC Address Changes and Forged Transmits have to enabled on your Port Groups that the NLB servers reside on
• Is not Layer 4 or above (service awareness)

Load Balancer

Load balancers are the ‘numero uno’ when it comes to load balancing Horizon View, offering features such as health checking where a probe is sent to the Horizon View Connection Server on a number of service connections e.g. TCP probe on 443 to ensure service availability. Perhaps the greatest reason for load balancer use is to stop new connections going to Connection/Security Server whose services are down.

The user is disconnected from the desktop and then when they reconnect they go back to the same desktop.

Load Balancer Advantages

• Service awareness, actively ‘polls’ the Horizon View services (PCoIP 4172 UDP, TCP and HTTPS) to ensure they are available
• Protect against failure at LAN or WAN depending on chosen model and features
• No session loss with failed components
• Weight load to Horizon View Connection Servers based on different factors
• Offload SSL, which can become a major part of the demand for Horizon View Connection Servers
• Can offer firewall features such as DDoS and IPS depending on chosen model and features
• Can be used in Global Server Load Balancing configuration to protect from WAN failures (note that Desktop Pools should not spam more than one physical location due to Java Message Service requirements, see this excellent post by Simon Long)

Load Balance Disadvantages

• Expensive!
• Need to purchase at least two otherwise you have no high availability
• Configuring can be complicated, if no ‘Horizon View’ templates are available

Horizon View Design

The purpose of this blog post was to consider the design for load balancing for Horizon View.  Now that we have covered the techniques that can be used, we need to consider the requirements:

• Is redundancy required?
• What network throughput is required?
• Can users access their desktop remotely? If so by Blast and View Client?
• Can users access their desktop internally by Blast?
• How will routing maintenance be undertaken?
• How will upgrades be undertaken?
• Is Smart Card authentication required?
• Is Two Factor authentication required?
• Is a Secure Connection required to the desktop?

These are some off the questions that will influence your Horizon View design.  A common question is: ‘How do we govern who has access to their desktops internally and externally?’ This can only be achieved by having ‘Connection Server Tags’.  Connection Server Tags are a unique reference from a desktop pool to a Connection Server to allow manipulation of desktop pool variables. Let’s work over a scenario, different users require internal and external access.  To achieve this we would need at minimum:

• One Security Server for remote access
• One Connection Server for internal access tagged ‘internal’
• One Connection Server for external access tagged ‘external’
• One Desktop Pool for internal users with Connection Server restriction to ‘internal’
• One Desktop Pool for external users Connection Server restriction to ‘internal and external

In reality you probably wouldn’t design for the above scenario due the single point of failures.  The design below is what I would expect to see as a minimum.

Note: You need 4 x Load Balancers in this design.

Key Concept

Secure Tunnel/Gateway connection to desktop for HTTP(S) and PCoIP are key to the expected results you will achieve on your load balancing design.

HTTP(S) Secure Tunnel, PCoIP Secure Gateway & Blast Secure Gateway unticked

The connection from the View Client goes to the Connection Server, authentication is achieved and the desktop is loaded.  The connection from the View Client is then established DIRECTLY to the View Desktop bypassing the View Connection Server.

• Step 1 (Login to Desktop) View Client > Connection Server > View Desktop
• Step 2 (Logged into Dekstop) View Client > View Desktop

In this design your Connection Servers are only required for the login, after this they become redundant.  Considerations for this design:

1. Communications are not secure between View Client and View Desktop
2. Can only be used for LAN connections, Security Server requirement is to have Secure Connection/Gateway enabled (ticked).
3. Consider using for a design when requirement is to have desktop ‘always on’ with no disconnect if a Connection Server fails.

HTTP(S) Secure Tunnel, PCoIP Secure Gateway & Blast Secure Gateway ticked

The connection from the View Client goes to the Connection Server, authentication is achieved and the desktop is loaded.  The connection from the View Client is then always PROXIED via the Connection Server to the View Desktop.

• Step 1 (Login to Desktop) View Client > Connection Server > View Desktop
• Step 2 (Logged into Dekstop) View Client > Connection Server > View Desktop

This can be confirmed in the View Administrator Portal be selecting Remote Sessions and you will see the Secure Gateway the desktop connection is using.

In this design your Connection Servers are always required.  Considerations for this design:

1. Communications are secure between View Client and View Desktop
2. Requirement to use Security Servers (your View Client will connect and authenticate successfully, however you will see a black desktop background then a disconnect).
3. If you loose the Connection/Security Server, the user will be disconnected and will need to reconnect.

Basic Principles

 

The fundamentals of a Horizon View Load Balancing Design are driven by the requirements from the customer.  The basic principles that need to be followed are:

• Security Server to Connection Server is a 1 – 1 relationship.
• Two Factor & Smart Card Authentication are at Connection Server level
• Internal and external access control is governed by Connection Server ‘Tags’
• Differences between Pool Settings require different Desktop Pools (obvious eh?)
• Desktop session will always get disconnected if using Secure Connection/Gateway

In the next blog post, I will look at Horizon View Load Balancing Failure Scenarios so that you know what results to expect.