I’ve had several customers ask me what options they have for providing redundancy / high availability / load balancing for their VMware View Connection Servers and Security Servers.  VMware View does not provide its own load balancing functionality.  Many are smaller customers without any existing load balancers in place, or want something they can use during a View pilot or Proof of Concept engagement.  Administrators who find themselves in a similar situation have a few choices for providing high availability for View servers:

1. Buy a load balancer – F5, A10, Cisco ACE.  Expensive, complex for small environments.
2. Use  DNS Round Robin – DNS RR is easily configured, but has no awareness of the workloads behind it.  If a View Security Server or Connection Server fails, DNS Round Robin will continue to send clients to that failed server until the failed server is restored or removed from DNS (and the DNS TTL expires from client caches).
3. Use poor man’s DNS failover – have only one connection server responding to the DNS record for your View environment.  Have a 2nd View replica server running but not registered in DNS.  If the active host fails, switch your DNS to point to the replica (you don’t want to be changing IP’s of View servers).  This is a manual failover that would require some additional monitoring.  It is not very fast to fail over as the DNS TTL would have to expire for the change to be recognized by clients.
4. Microsoft Network Load Balancing (NLB) – This can be a pain to configure if your View Connection Servers and Security Servers are running on vSphere – see here for more: https://kb.vmware.com/kb/1006778.  Jon Owings has a post on how to configure View for NLB here: https://www.2vcps.com/2010/04/26/using-network-load-balancing-with-view/
5. Use VMware vShield Edge / vCloud Networking and Security if you are lucky enough to be licensed for these products.
6. Roll your own!  I created a virtual appliance based on SLES 11 SP2 using SUSE Studio.  My virtual appliance has HAProxy installed (as well as VMware tools, SUSEFirewall2, and a few other packages).

VMware offers support/subscription for SLES if you have an active Support and Subscription (SnS) agreement.  See here for more info: https://www.vmware.com/products/sles-for-vmware/overview.html

I have provided a sample configuration for HAProxy that will balance HTTP/HTTPS connections to your View Security Servers and View Connection Servers.  The appliance is very light weight – 512MB RAM, 5GB HDD, 1 vCPU.

I am using Source based balancing to provide session stickyness.  A client IP hash is used to assign the client to a host.  The client continues to use the designated host until the host is placed in maintenance mode or fails a health check.  This will help to keep PCoIP Secure Gateway and RDP Secure Tunnel sessions routed to the same Security/Connection server that brokered the session.

To add your View servers, edit the haproxy.cfg found in /etc/haproxy using vi, then restart haproxy for changes to take effect (/etc/init.d/haproxy restart).

You’ll probably want different View Load Balancers for your Security Servers and Connection servers as pictured below.  It is possible to multi-home these and bind different IP’s to different ethernet interfaces, but because the appliances are so small you might as well just make a few different ones.

 I have configured HAProxy to authenticate user logins to the stats page.  This allows the administrator to place load balanced Security or Connection Servers into maintenance mode with a simple web dashboard:

To get started with my VMware View load balancer appliance do the following:

1. Download it from SUSE Studio here: https://susestudio.com/a/R42GDM/vmtoday-vmware-view-load-balancer
2. Import OVA to vSphere.
3. Configure vSphere networking – assign to port group.
4. Power on appliance.
5. Accept SUSE license:  Press ‘q’ on license screen, then ‘y’ to accept
6. Accept EULA.  Promise not to sue me if this doesn’t work, has security flaws, or totally destroys your virtual datacenter.
7. Modify network configuration as appropriate (see Change option to assign a static IP) or next to accept the default DHCP.
8. Log in as root with the default password.
9. Edit the haproxy config file at /etc/haproxy/haproxy.cfg > vi /etc/haproxy/haproxy.cfg.  Uncomment the server lines for View HTTP and View HTTPS and add alias names and IP’s for your Connection Servers or Security Servers.
10. Restart HAProxy > /etc/init.d/haproxy restart.  If no errors are reported, HAProxy should now be running.
11. Change your DNS for desktop.example.com (or whatever your View DNS name is) to point to the IP of the load balancer.
12. Update your View environment’s External URL for HTTP(S) Secure Tunnel and PCoIP Secure Gateway for the IP of the load balancer.
13. Test with HTTP/HTTPS connections to be sure the View Portal opens.
14. Test with View Client.

To access the stats page, go to https://applianceIP:1936/haproxy?stats/.  Log in with the haproxy account.

Credentials for the haproxy and root accounts are included in the SUSEStudio page for the appliance.  I recommend you change these and update the haproxy.cfg to reflect your password changes.

For a LB deployed in the DMZ for Security Servers, you’ll need to open ports 80, 443, 4172 (UDP/TCP) from the internet to the load balancer (see this for more info: https://pubs.vmware.com/view-51/index.jsp?topic=%2Fcom.vmware.view.planning.doc%2FGUID-57D362EB-AC04-45B8-87AA-05A15A998211.html).

With a single virtual appliance, we have introduced a new single point of failure while trying to solve the single points of failure at our View Connection and Security servers.  It is possible to combine multiple copies of my View Load Balancer appliances together in a highly available cluster using keepalived (for cluster heartbeating) and Mercurial (for haproxy.cfg synchronization).  Nathan Evans has a great post on doing this here: https://nbevans.wordpress.com/2011/02/27/deploying-ha-proxy-keepalived-with-mercurial-for-distributed-config/.  Andy Leonard also has some tips for getting HAProxy and keepalived working here: https://andyleonard.com/2011/02/01/haproxy-and-keepalived-example-configuration/.

The next version if haproxy (1.5) will include native SSL support, with SNI and multi-process session sharing.  This will allow SSL offloading for your View Connection Servers and Security Servers, instead of just passing through as I have it in the haproxy 1.4 on this appliance.  Once 1.5 reaches a stable release I’ll rebuilt the appliance with 1.5 to support SSL offload.

F5 offers a good whitepaper on configuring their load balancers (Big-IP) for View 5.0 here: https://www.vmware.com/files/pdf/partners/f5networks/f5-vmware-view-deployment-guide-v17.pdf.  It may come in helpful if you want to make any additional modifications to the HAProxy config.

If you don’t want to go with my setup, no offense taken.  There are alternatives: pfSense https://www.viktorious.nl/2012/05/02/can-pfsense-be-used-as-a-free-load-balancer-for-vmware-view/ should work, as would Citrix NetScaler – https://virtualfuture.info/2012/02/free-load-balancing-for-vmware-view-with-citrix-netscaler-vpx-express/ (but it feels a bit dirty to use a Citrix solution for VMware View ;-))

You can use this haproxy appliance to load balance other traffic, such as Microsoft Remote Desktop / Terminal Services /RDP.  You could also apply it to an Exchange array to load balance Exchange 2010 CAS arrays as described here: https://www.stevieg.org/e2010haproxy/.

Let me know if you have any ideas or improvement in the comments section below!