If you missed the other articles in this series please read:
- Citrix Presentation Server Load Management – Part 2
- Citrix Presentation Server Load Management – Part 3
Introduction
Citrix Presentation Server load management, or “load balancing” as it is commonly referred to, is a critical component in all multi-server Citrix Presentation Server farms. Knowing how to properly implement and monitor a successful load management system will increase the effectiveness of server utilization, increase user performance, and ensure server farm stability. We will begin with an introduction into the load management components and then look at the traffic flow and decision making process, as well as several critical factors affecting load management.
Load Management Architecture
The load management architecture consists of several components within the server farm. The first of these components is the modular piece of Presentation Server software code responsible for distributing user load amongst servers in a particular zone, as well as the entire farm. The primary library in this component is LmsSS.dll and will load into server memory during the Independent Management Architecture (IMA) service startup procedure. This .dll file should be running on every Presentation Server in the farm; however this process will not be present on any server licensed for the Standard version of Presentation Server, only Advanced and Enterprise versions.
Arguably the most critical component is the zone data collector located in each zone. The zone data collector is simply a Presentation Server which is performing the data collector role in a particular zone. You may control the data collector preference, but regardless of these settings there will always be a single Presentation Server in each and every zone that must fulfill this data collector role. The Presentation Server maintaining the data collector roll is responsible for directing all requests from ICA clients launching published applications; this in itself is no secret. What is not common knowledge is what factors come into play in the decision making process, and exactly how this decision process takes place. In order to effectively utilize the load management subsystem, one must fully understand the players and the rules of the game.
The next component is the published application itself; without publishing specific applications or a published desktop, actual load balancing does not take place. Simply connecting to a terminal server or Presentation Server via the server name or IP address will not invoke the load balancing subsystem. An additional factor that should not be overlooked is the zone preference and failover settings which may be present in one or more Citrix policies. These settings can determine which Presentation Servers in certain zones may provide the requested application to respective users. Figures 1 and 2 below depict the settings for a zone preference and failover policy. In this example all users in the 10.1.30.0/255.255.255.0 subnet will be directed to Presentation Servers in the zone named “Kentucky”, with the ability to automatically failover to Presentation Servers in the zone named “Ohio” if no Presentation Servers in the “Kentucky” zone are available to provide the desired application.
Figure 1
Figure 2
The final piece of the load management puzzle is the load evaluator or load evaluators applied to servers and/or published applications. A load evaluator is simply a set of rules that determine a particular server’s “score”, or current load value. It is this “score” that may eventually determine the decisions that distribute loads within the server farm. Load evaluators can be applied to servers and/or published applications. (Load evaluators and corresponding rules will be covered in depth in part III of this series.)
Load Management Decision Process
The load management process always begins with a user request to launch a published application or published desktop within a Presentation Server farm. The first step the user, or ICA client must take is to locate the data collector in the respective zone. Any Presentation Server reachable by the user will be able to supply the name and/or address of the data collector in the particular zone. Once the IP address of the data collector is discovered, the ICA client makes the request for the particular published application directly to the data collector. Once the user establishes communication with the data collector, the data collector may access data in the Local Host Cache (LHC) on the data collector Presentation Server, the in-memory session data (which sessions are active or in a disconnected state), as well as the in-memory database of server loads, or “scores” of all Presentation Servers in the given zone.
The first step in this decision making process is to determine if the particular user has any existing sessions, in either active or disconnected states. This may require inter-zone communication between data collectors in a multi-zone farm. The reason for this step is due to the default behavior related to “session sharing”, or the propensity for Presentation Server to run as many applications as possible within a single session, rather than spawning additional sessions. For example; User JDoe has an existing published application running in an ICA session on SERVER1. JDoe then attempts to launch a second application within the same server farm. If the requested application is available on SERVER1, and SERVER1 is not fully loaded (load value less than 10,000), the application will be opened in this existing session on SERVER1, and no new session will be spawned. One caveat is the requirement that certain properties of the newly requested published application match those of the application already running is a session (resolution, colors, audio settings, etc.). As you can see, this behavior could cause an already busy server to accept additional load, regardless of the load present on other servers. Although the benefits gained by session sharing far outweigh the associated risks, it would be remiss to not mention this possible outcome regarding load balancing server resources. (Note: A feature enhancement was released from Citrix to allow session sharing to be in effect on fully loaded servers – see Citrix hot fix PSE400R01W2K3010, or current knowledge base article CTX111085)
When the delivery of the requested application must result in spawning an entirely new session, the LHC is queried to determine which servers have the application available, as well as the potential Citrix policy data regarding zone preference and failover. This information provides a “short list” of potential servers which are available to provide the requested application to the particular user. It is only at this point in the process that the actual load management subsystem comes into play. The “score” or load value will now determine which server is selected from the short list and ultimately provide the requested application to the ICA client.
Load Value or “Score”
In order to understand and properly assist in this decision making process, we must get to know the importance of this “score”, or load value and understand how it is calculated and reported. Each and every Presentation Server generates its own “score” and sends this information to the data collector in the respective zone. This score will be a decimal number between 0 and 10,000, with zero representing a “no load” situation, and 10,000 indicating the particular server is fully loaded and is not accepting any more connections. Figure 3 shows the results of a QFARM /LOAD command executed in a Presentation Server farm. This command will display all servers in the farm along with each server’s respective load value. As you can see in Figure 3, if a request for an application was to result in a new session, the server named “Instructor2” would be the lucky winner at this point in time, due to its lower load value.
Figure 3
How is this vastly important number determined? It is a result of the calculations and sum of the values of all the rules in each and every load evaluator which applies to the given scenario. One important factor to understand is once any single rule reaches its maximum value, the load value for that server becomes 10,000, effectively removing the individual server from contention for new sessions. Individual servers continuously update the respective zone data collector with their current score every 15 seconds under normal conditions, or after each and every logon or logoff of a user session. In a very busy Presentation Server environment, a lot can happen in 15 seconds. An example of this would be a particular time of the work day when many users are launching applications simultaneously, such as the beginning of the business day. When a large number of users are simultaneously accessing Citrix published applications, load balancing amongst servers can become skewed. In the event one server has a very low load value in comparison with other servers on the “short list” of available servers, it is possible to temporarily overload this seemingly “not busy” server by directing many new sessions to this server in a very short period of time, even to the point of rendering it inoperable. It is also possible to see this skewed load balancing under another condition; If an administrator were to insert a Presentation Server with no load present into a busy farm (or reboot a Presentation Server), the end result could be similar to a new checkout line opening in your favorite retail establishment; a mad rush to the new checkout line resulting in a temporary and painful bottleneck. This particular situation with Presentation Server load balancing has been referred to as the “black hole effect”. The second part of this series will investigate Intelligent Load Biasing (ILB), a feature enhancement released for Presentation Server 4.0 that attempts to address this server overloading issue, or black hole effect.
Conclusion
As you can see the load management process is much more involved than most Citrix administrators may realize. Many factors can affect how user requests for published applications are processed, and ultimately how Presentation Server loads are distributed. Understanding how these different factors may impact your Presentation Server environment provides a solid foundation for implementing a successful load management strategy. The next steps will consist of gaining a better understanding of load evaluators, load evaluator rules, the new “Intelligent Load Balancing” and its capabilities, and monitoring the load management process. Stay tuned for parts II and III of this “Load Management” series.
If you missed the other articles in this series please read:
