I have been working on a few VMware View designs over the last few months and one question that seems to sneak up on folks is how are they going balance their PCoIP/RDP traffic. As VMware View does not bundle or have a native mechanism within the product to balance connections between the Connection Brokers or Security Servers customers have a couple of 3rd party options available to them. Personally I refer to these as The Good, The Bad, and The Ugly (queue Western music). Of course I say that in a tongue a cheek fashion, as all three of these options are valid solutions for an environment. Depending on the customers functional requirements and/or project budget they may choose one solution over another.
The Good – Dedicated Load Balancer – Ideally in a VMware View deployment you would be leveraging either a physical or software (virtual) load balancer to maintain the connectivity into your View environment. These dedicated appliances offer the best in functionality compared to the other options listed. With the ability to balance load across View Connection Brokers/Security Servers based on geographic location, server load, server up/down, and many other metrics are available. There are several vendors who play in the space and provide quality solutions that can be leveraged; F5, Citrix NetScaler, and Kemp Technologies to name a few. What’s the catch you might be asking? Cost for most folks. As you will see below the other two options are essentially “free” as they are included with your Microsoft Server licensing and though they have a few challenges to work around, these sometimes can offset the associated cost of running a dedicated load balancer.
Recommendation – Dedicated Load Balancers are best suited for medium to large deployments where their benefits can offset the associated purchase price.
The Bad – DNS Round Robin – The simplest and easiest method of load balancing requests across your View Connection Brokers/Security Servers. Supported by default from Microsoft DNS since Windows Server 2003 functions by creating multiple “A” records with different associated IP’s address pointing to the same DNS name (see THIS Microsoft TechNet article). While this load balancing solution can be implemented to little or no cost, operationally it leaves something to be desired. As DNS does not have an understanding of server load or server up time it is possible to direct traffic to View Connection Broker/Security Server that could be either at connection capacity or maybe down or offline for maintenance.
Recommendation – DNS RR is recommended for smaller environments/deployments.
The Ugly – Windows Network Load Balancing (NLB) – I was a little torn between listing Windows NLB as The Bad or The Ugly, but then I remembered the added complexity Windows NLB brings with it when deploying in a VMware environment. Between choosing whether to deploy via Mulitcast (VMware KB Article 1006558) or Unicast (VMware KB Article 1006778) and ARP entries (VMware KB Article 1006525) in your switches this option ratchets up the complexity level. So why with these challenges why would someone deploy Windows NLB? Like DNS RR, Windows NLB is included with your MS licensing, so the price point is good. The other reason is it brings some intelligence to the load balancing unlike DNS RR. With Windows NLB the operational issue of servers being in or out of the rotation can be handled via the Network Load Balancing Manager. This will allow you to stop connections from being sent to a View Connection Broker/Security Server if it is done or offline for scheduled maintenance (though this is a manual intervention).
Recommendation – Utilize Windows NLB in small to medium environments where “application awareness” is better suited for load balancing over DNS RR. Consider VMware administrator and Network administrator knowledge for additional complexity.
Have any thoughts or comments? Please share them below.