When I checked the statistics of the VanBragt.Net Virtualization website I noticed that several connections were based on search for Citrix Load Balancing. That brought me to the idea to write some more about it. In the same time in one of my project the Load Balancing part came into the picture so I can also share/use my personal experiences in the article. This article will describe when and why you would like to use Citrix Load Balancing and how you need to configure it.
Before we really start the article handles Citrix Load Balancing Policies which should not be confused with Citrix Load Evaluators which are often also called Citrix Load Balancing. The Load Evaluators are used to divide users equally over servers based on user load and/or used resources. However Load Balancing Policies are a step before that process by specifying which group of servers should be used to start the session on.
Update: As Andrew stated in the comments this component will only work when connecting via Access Gateway, Web Interface of Cloud Gateway. Old methods (like TCP via HTTP) often used on Thin Clients will ignore the configuration.
In which cases you would like to use Citrix Load Balancing Policies:
- The most common is where the XenApp servers are located on several sites, while also the users on several locations combined with the fact that the connections to those sites are not the same. For example a user is located on location X, with a connection of 1024 Kbps to Site A and 256 Kbps line to Site B. In that case you would like to set-up the session to Site A (and in case of a failure to Site B)
- When you have an active-passive set-up, where Site A is primary and Site B is there for disaster recovery/failure. By default you want users to start a session in Site A, while in case of failure the users should be assigned to Site B.
- In a case of an active-active setup where you would like to keep the user in the same data center where he connected to. This is case in one my project. Users are connecting to one of the CAG based on Load Balancing located in one of the sites. When the user is connected via CAG of Site 1, the session should also be hosted on a XenApp server in Site 1, so now traffic will flood between the two sites.
- For creating several delivery protocols for streamed applications based on the filters available within Load Balancing Policies.
Maybe there can be more scenarios to use Load Balancing Policies, but these are the most common I can think of. If you have another scenario let me know so I can add it to the article.
Before I continue describing how to configure Citrix Load Balancing I would like to mention that the method described is based on Citrix XenApp 6.x. In XenApp 5 for Windows 2003/Citrix Presentation Server 4.5 the same can be achieved but the configuration is completely different. I’m only going to describe the XenApp 6.x in detail. For CPS 4.5 you should configure zones and use the Zone Preference and Failover Policy in a similar way.
Citrix Load Balancing Policies are logically configured using the Citrix AppCenter where you can find in the root of XenApp farm view (Load Balancing Policies).
Via the right mouse button menu you can create a new Load Balancing policy. Logically the Load Balancing Policy needs a (unique) name).
The real Load Balancing configuration exists of two parts:
- Filters
- Load Balancing Policies
With the first part Filters will be determined in which cases the Load Balancing Policies defined in stage two are carried out. Filtering can be done based on 4 levels, which can be combined if necessary. So the filters are pretty powerful. Let’s go into those 4 levels a bit more detailed.
Filters
Access Control
This filter is based on accessing the farm using the Citrix Access Gateway. An Access Controller is required for the more advanced filtering. Only for using an Access Gateway as filter can be used without the Access Controller. Specific Access Gateway Filters can only be defined within the Access Controller.
Client IP Adress
The second option is based on the client IP-address. Both IPv4 as IPv6 can be used. Also you can specify an IP-address or an IP-range (combined with wildcards). This is useful for the use case with the different locations, which should be access a specific site.
Client Name
Using a client name is a third option. Most times this is a difficult one, because you are dependent on naming conventions that are being used. However I used this one of my customer without an Access Controller. My modifying the Web Interface code to use a different name convention, you make a differentiation between the Web Interface. We used two name conventions, one for Datacenter 1 and the second for Datacenter 2.
Users
The last option to use within the filters part is the username. Also wildcards are supported here. This option can be used if you have for example country codes in the username.
As stated before you can combine those filters. So if would like to have a load balancing policy for on IP range 192.168.10.* and Client Name start with WS this is possible.
Load Balancing Policies
The second part is actually applying the settings to the group based on the filtering above. Load Balancing Policies can arrange two things.
Worker Group Preferences
Probably this is most used part for the Load Balancing Policies, because this suites most of the use cases specified in the beginning of this article. Within XenApp 6.x Worker Groups are the way to go. Within this part you specify if the filters apply which Worker Group should be used to start the session on. For example (as shown in the below figure) you can specify two (or more) worker groups. By default when the filters apply the session will be started on a server in the Worker Group with priority 1. When this Worker Group cannot honor the request the session will be started within Worker Group 2. This can be used for the active-standby, the locations and the active-active setup use cases as stated earlier in the article.
Streamed App Delivery
Secondly you can use the Load Balancing Policies to define the way streamed applications should be delivered to the users. By default this is configured on the Published Application level, but with Load Balancing Policies you can override those settings. Can you can set-up that applications are forced to stream to the client, are not allowed to stream to client or allowed to stream/run on Terminal Server (yes, that term is still used).
Logically more Citrix Load Balancing policies can be defined. Often this is also required for the use case. In my project we would like that the users connected to the Web Interface in data center 1 was redirected to a server also locatied in data center 1 (and logically the same applies for data center 2). We made the modification in the Web Interface to use a different naming schema for the client name. The first Load Balancing Policies was filtered on the WI client name of data center 1, while the Worker Group for data center 1 has priority one (The data center 2 Worker Group was added as the second priority to in the case of failure in data center 1 the users are redirected to data center 2). The second policy logically was based on the WI Client Name of data center 2, assigning the session to the Worker Group for data center 2.
Conclusion
Load Balancing Policies are a separate component within a Citrix infrastructure and are not directly related to the other Policies of Load Evaluator (as sometimes thought). Load Balancing Policies is mainly used to assign a session to specific group of servers based on several use case scenarios. Configuration is based on two parts, the filters and the actual load balancing policy.