At one of my projects we were discussing the high level design decisions and one of the discussion topics were setting-up the Delivery Controllers high available and redundant. During the talk we discussed the necessity of using Load Balancer appliances in front of the Delivery Controller. Based on that talk I thought it was a good idea to write an article about this topic including my opinion.
Logically we need to start which communication streams are being used to the Delivery Controllers which should be taken into account. Communicating to the delivery controller has three communication streams.
-
Virtual Delivery Agent (VDA) communication
-
StoreFront communication Application enumeration/ICA file creation (XML broker)
-
NetScaler (and StoreFront) STA communication
Let’s dig deeper in each communication stream.
VDA communication
The first stream is all communication between the Delivery Controller and the VDA. Each VDA communicates with one of the Delivery Controllers. At the discovery process the connection will be set-up with one of the delivery controllers. Before XenApp 7/XenDesktop .x it was a best practice to set-up a specific A record with a general name, which was configured into the VDA software. To make this option reliable a load balancer appliance was being used to distribute the VDA to a specific delivery controller.
From version 7.x this function is depreciated, it’s still available but you need to add a registry key called UseCnameLookup with a value of 1 on each VDA. However I won’t recommend to use depreciated features. Citrix currently expects that you define the real delivery controllers’ names at the VDA. There are several ways for adding the delivery controller names to the VDA agent, I personally like the GPO option the most (as this is the one most flexible). Citrix also added an additional policy called Delivery Controller auto-update. This settings is enabled by default and dynamically updates the list of Delivery Controllers and automatically notifies Delivery Agents when controllers are added to and removed from the site.
As Citrix has depreciated the CNAME option for this communication stream, it is not logical to not follow Citrix guidelines and don’t use the actual Delivery Controller names. Therefore no load balance appliance is needed for this communication stream when using XenApp/XenDesktop 7.x.
StoreFront communication Application enumeration/ICA file creation (XML broker)
The second communication stream is set-up at the StoreFront configuration. For StoreFront to show to show the icons of the applications and/or desktops to the end-user and getting the ICA file to set-up the actual session StoreFront communicates with the Delivery Controllers. In the early StoreFront servers you could specify more Delivery Controllers, but each request was handled in the order as the Delivery Controllers were specified (failover mode). So if the first server was available, it would handle all request. This is the case till StoreFront 2.5 and logically you would like to use a load balancer in this case. Using a load balanced CNAME all Delivery Controllers were used for this type of communication.
In StoreFront 2.6 the servers specified were automatically load balanced, so StoreFront used an own algorithm to assign the request to the available Delivery Controllers. If another later version the load balancing option is the default, but you can choose to choose the fail-over modus as well.
By the availability to load balance the servers within StoreFront the necessity of a load balancer appliance is reduced a lot. I still think there is one reason to use a load balancer appliance for this communication. However than your load balancer needs to be a Citrix NetScaler. The Citrix NetScaler has a specific monitor for the XML traffic. In this monitor an actual request is send, so the service is fully checked. StoreFront doesn’t do this check in advance, so using the NetScaler optimized this a bit more. However if you have another load balancer (Kemp, F5 or so on) I don’t see any reason to load balance this communication to the Delivery Controller using a load balancer appliance. In those cases the StoreFront capabilities are good enough, while a load balancer does not offer (much) added value but makes this configuration more complex.
Update 1-7-2020: Citrix released an interesting article on september 27 2019 about the possibilties of the NetScaler in combination with the CVAD Local Host Cache feature: https://www.citrix.com/blogs/2019/09/19/load-balancing-xml-services-and-local-host-cache-mode/
NetScaler Gateway (and StoreFront) STA communication
The last stream is only applies when using the Citrix NetScaler Gateway functionality. When using the NetScaler Gateway Secure Ticketing Authorities need to be configured. The STA functionality is embedded in the Delivery Controller component. STA’s need to be defined at the NetScaler Gateway configuration and in the Citrix StoreFront configuration when adding a NetScaler Gateway.
At the NetScaler Gateway side there is no possibility to load balance the STA during the configuration. This is because the StoreFront is actually doing the STA communication and the NetScaler Gateway only checks the STA ID.
So for the NetScaler Gateway part there is not necessity to set-up a STA load balanced service on a load balancer appliance. Also the STA needs to be defined within the StoreFront configuration at the NetScaler Appliance component. For a pretty long time the STA’s were added in a fail-over configuration only, so there was definitely space for using load balancer appliance. However since StoreFront 3.5 also the STA configuration with StoreFront offers automatically load balancing functionality. So also here the need for a load balancer appliance is not necessity anymore.
Are you not forgetting a stream: NetScaler Gateway Farm Communication?
You could wonder if you configured a NetScaler Gateway using the wizard in the NetScaler that you also need to enter the Delivery Controllers at the Xen Farm part in the wizard. This part creates a monitor to check if the XenApp/XenDesktop environment is up and running. This monitor is an optional component as it does not take the Gateway down if the monitor is failing (at least it looks in some environment I have set-up, did not find proof of this behavior). At the configuration you need to specify the Delivery Controllers based on their IP address. The wizard also offers the possibility to load balance the IP addresses within the wizard, which creates a load balance service on the same device as the NetScaler Gateway.
In my opinion this is not required, it is just a monitor. Why would you load balance those requests? The monitor will function without load balancing based on a fail-over mechanism, which is enough for this functionality. If load balancing is required, you can use the load balance option offered in the wizard on the same NetScaler Gateway device. I won’t build a load balanced services on an internal load balancer appliance for this communication flow.
Summarization
In this article I discussed the necessity of load balancing the Delivery Controllers via a load balancer appliance. If you are using the latest versions of the Citrix StoreFront (3.5 or higher) in most cased you do not need a load balancer appliance as the load balance functionality is already embedded within the products. For the VDA’s Citrix does not recommend using a load balancer anymore, while StoreFront offers the functionality included in the product. Only when you have Citrix NetScalers you could consider load balance the Deliver Controllers as the NetScaler provides a specific monitor to check if the Delivery Controller is functioning correctly. If you have other Load Balancer appliance I would not use the appliance but rely on the embedded load balancing functionalities.