If you missed the other articles in this series please read:
- Citrix Presentation Server Load Management – Part 1
- Citrix Presentation Server Load Management – Part 3
Part two of this three-part series will uncover hidden secrets related to server load biasing and Intelligent Load Biasing. Several tips will be shared for utilizing and tuning these features to improve the success of your load management strategy.
Introduction
In part one of this three-part series we began with an overview of the components of the Citrix Presentation Server load management subsystem, as well as a detailed analysis of several aspects of the load balancing process. In this second part of the series we will take a look at server load biasing present in earlier versions of MetaFrame, as well as Intelligent Load Biasing (ILB), which is available for Presentation Server 4.0.
What is Server Load Biasing?
One potential issue introduced in the previous article was the risk of overloading a particular server by directing many new sessions to this server within a very short amount of time, usually measured in seconds to a few minutes. In order to address this potential server overloading situation (sometimes referred to as the “black hole effect”) Citrix implemented “load biasing”. Load biasing is simply a method to compensate for the potential short-term overloading of what appears to be an under-utilized server by temporarily adjusting the load value, or “score” of that server.
Remember, when the load management decision process (performed by the data collector) finds a server that is much less busy than its counterparts, the data collector will send requests for new sessions to that particular server until its load value, or “score” is no longer the lowest in the zone. What can actually happen is this particular server can become extremely busy processing requests for new sessions and launching applications within those new sessions. In fact, this server can become too busy to calculate and update its load value in a timely manner, rendering itself helpless to the point of becoming totally unresponsive. Hence, the term “black hole effect”, as user requests for applications are directed to an unresponsive server, or “black hole”.
Server Load Biasing Details
Server load biasing is in effect on all MetaFrame XP and Presentation Servers by default; however the default settings are usually not sufficient to eliminate the black hole effect. Citrix knowledge base article CTX103653 provides a brief explanation of load biasing within the load management system. There are two registry settings for load biasing; one to turn this feature on or off (on by default) and one to adjust the load biasing multiplier.
Figure 1 indicates only one of these two values is present by default, the LoadBias value, and it has a default value of 200 decimal, or c8 in hex.
Figure 1
If you wish to disable load biasing, create a REG_DWORD value named “ForceRegBias” in the registry key “HKLM\Software\Citrix\IMA\LMS” and set the value equal to “0” If you later wish to re-enable this feature, simply set this value to a “1”. In order to affect the manner in which load biasing values are calculated, adjust the REG_DWORD value “LoadBias” from the default value of 200. (A higher value will cause a server’s temporary load value to accelerate at a quicker pace) The load bias value is used to temporarily adjust the load value of each Presentation server in a given zone; that is the load value for each server in the zone, which is stored in memory on the data collector for that particular zone. The data collector applies this load bias value to a formula to immediately increase the load value of servers as the data collector directs requests for new sessions to those particular servers. The formula is as follows:
Server Load Value (score) = Current Load + (# of concurrent logons) X (load bias value)
The “Current Load” is the score of the particular server at a given point in time. The # of concurrent logons is the number of logons that particular server is currently processing, and the load bias value is the value present in the “LoadBias” value in the particular server’s registry. For example, let’s take a server (SERVER1) that was just inserted into the farm during a peak logon period. SERVER1 would initially have a Current Load at or near zero, causing the data collector to begin to send new sessions to this server. If in this example the data collector sent 10 new sessions to SERVER1 within a very short period of time (seconds), the data collector would adjust SERVER1’s load value as follows:
Server Load Value (score) = Current Load + (# of concurrent logons X load bias value)
2000 = 0 + (10 X 200)
As you can see sending 10 new sessions to SERVER1 will cause that server’s load value to be adjusted to 2000, far below the ceiling of 10,000, and most likely well below the load values of other servers in the zone. In a worst case scenario, the default load bias value of 200 could allow up to 50 new simultaneous logons to be sent to SERVER1 before the temporary load value reaches the maximum value of 10,000! Not many, if any server configurations could withstand such a burst of new sessions.
Intelligent Load Biasing
How can this risk be addressed? The LoadBias registry value could be increased to a higher number, in the hopes that the number of concurrent logons to a particular server would be limited to a more manageable value. Adjusting this value could be a viable solution; however the best solution would be to change the way load biasing is calculated in the first place by utilizing a more effective algorithm. Citrix did just that when they introduced Intelligent Load Biasing, or ILB with a Presentation Server 4.0 hot fix (PSE400R01W2K010 for Windows 2000, and PSE400R01W2K3027 for Windows 2003). This hot fix is also present in the currently available rollup 2 service pack (PSE400W2KR02 for Windows 2000 and PSE400W2K3R02 for Windows 2003). ILB introduced a “slow start” load biasing algorithm that significantly changed how the load management subsystem distributes new sessions. Basically, this new algorithm creates a temporary load value by assigning a bias value equal to one half of the remaining load capacity (using the default ILB Multiplier value of 2). The new formula looks like this:
Server Load Value (score) = (Max. Load – Current Load) / ILB Multiplier value
Table 1 illustrates how this algorithm works to raise the temporary load value, effectively limiting the number of concurrent logons to a given server. A comparison is shown between the corresponding load values using the default ILB Multiplier value of 2, and the effect changing the ILB Multiplier to a value of 4 would have on the temporary load values assigned by ILB. As you can see the premise behind this new algorithm is to very quickly raise the load value to a fairly high number, and then increase it less and less incrementally as additional logons are assigned to the particular server. This addresses two specific items; immediately assigning a temporary load value of 5000 for the first logon, and increasing the load value in a reverse logarithmic fashion as additional logons are processed assures a server will not be asked to process a significant amount of new logons simultaneously. Secondly, this algorithm will never allow a temporary load value of 10,000 to be assigned to a server, which in effect prevents this load biasing method from rendering all servers in a given zone unable to accept new logons. As further illustrated in Table 1 the temporary load value will be increased to 8750 with as few as three simultaneous logons (using the default ILB Multiplier of 2). However, if the ILB Multiplier is changed from 2 to 4, three simultaneous logons will result in a temporary load value of only 5781, much less than 8750. This reveals a very important fact; unlike the previous algorithm, increasing the registry value used by ILB actually decreases the temporary load value that will be assigned.
|
ILB Multiplier |
Current Load |
# Concurrent Logons |
Temporary Server Load Value |
|
2 |
0 |
1 |
5000 |
|
2 |
5000 |
2 |
7500 |
|
2 |
7500 |
3 |
8750 |
|
2 |
8750 |
4 |
9375 |
|
4 |
0 |
1 |
2500 |
|
4 |
2500 |
2 |
4375 |
|
4 |
4375 |
3 |
5781 |
|
4 |
5781 |
4 |
6834 |
TABLE 1
How significant is this change in load biasing? Well, in our above example without ILB, it was possible for up to 50 new sessions to be directed to a single server before that server’s load value reached the maximum value of 10,000. However, with ILB implemented using the default values, simultaneous logons will be limited to significantly less than 50, usually less than 5. At first glance this causes one to wonder if Citrix has over-corrected this issue. Relax; the controls are in place to allow tuning of this process to address the size and particular usage of your specific environment. Back to the registry we go!
A Citrix knowledge base article, CTX111085 provides a brief explanation of Load Biasing and Load Throttling (also referred to as “slow start” load biasing). Modifying the ILB Multiplier Value from the default value of 2 may provide better results for your particular environment. Taking steps to modify this value should include careful planning and testing prior to implementing any changes to the ILB process in a production environment. Figure 2 provides insight into the new registry values in place when ILB is active. Notice the original value of “LoadBias” is still present, even though it is not used unless ILB is disabled.
Figure 2
The ILB Multiplier value is found in the REG_DWORD value “ILBMultiplier” under HKLM\Software\Citrix\IMA\LMS. To disable ILB altogether, change the REG_DWORD value of “UseILB” in the same registry key to zero.
Conclusion
Intelligent Load Biasing is a great addition to Presentation Server, providing much improved distribution of new sessions than was previously possible. Prior to ILB the art of balancing loads amongst Presentation Servers could be difficult to achieve, especially during peak logon periods. Understanding how ILB functions as well as the available tuning options will allow for a more effective load management strategy and ultimately in better and more consistent performance for your users. The final article in this three part series will complete the load management puzzle by dissecting load evaluators and discussing monitoring options. Stay tuned!
If you missed the other articles in this series please read:
