Multi-Server Application Load Management - Citrix MetaFrame XP

We've already covered everything related to installing applications on a single MetaFrame XP server, but your MetaFrame environment will most likely consist of multiple servers.

By this point, we've already covered everything related to applications when it comes to installing them on a single MetaFrame XP server. However, your MetaFrame environment will most likely consist of more than one server. You'll probably want to install certain applications onto multiple servers. This is often done for scalability (if you have 1,000 users then you'll need more than one server) and reliability (if you have ten servers then you can lose one without affecting all users).

When you outgrow a single server or want to load-balance applications across more than one MetaFrame XP server, you'll need to use Citrix Load Manager (LM). Load Manager is the component of MetaFrame XPa and XPe that allows you to specify the criteria that make applications available for end users. It also allows you to customize the load balancing schemes when an application is published across two or more servers. With Citrix Load Manager enabled, users will continue to connect to published applications as they always have. The difference is that when Load Manager is used, the system will check all MetaFrame servers running the same application and automatically connect the user to the least busy server.

Citrix Load Manager is not a separate product from MetaFrame XP. It is built-in to MetaFrame XPa and XPe, and is required when applications are published across multiple servers. (If you have MetaFrame XPs then you will not be able to use Load Manager until you upgrade to XPa or XPe.)

How does Citrix Load Manager Work?

There are several components involved when users are load-balanced between multiple MetaFrame servers. Some components are specific to Citrix Load Manager and some are standard MetaFrame XP components that take on additional roles in load-balanced environments. The specific components that play a role in load-managed environments are:

  • Load Evaluators.
  • Rules.
  • Zone Data Collectors.

Load Manager Component 1. Load Evaluators

Load Evaluators are little programs that run on servers in the server farm that monitor the server's ever-changing utilization and usage. They calculate a "load index" for each server or application where they are applied. The load index always has an integer value somewhere between 0 and 10,000, its value changing depending on the actual load. A value of zero means that the load evaluator has calculated no load, and a value of 10,000 means that the load evaluator has calculated the maximum load. In the real world, the values of the load evaluators are constantly changing as server and application loads change.

Load evaluators are created via the Citrix Management Console and their properties are stored in the IMA data store. After they are created, Load Evaluators can be applied to farm servers or published applications.

Load Manager Component 2. Rules

Rules are the specific sets of criteria that the load evaluators use to calculate their load index. Each load evaluator is made up of one or more rules. For example, a rule might be established that correlates to CPU utilization-returning a load index value of 0 for 0% CPU utilization, and 10,000 for 100% utilization (and 5,400 to 54% utilization, etc). Many parameters exist that can be used to establish rules, including CPU or memory usage or the number of users logged into the server.

The number and configuration of rules that make up a load evaluator are also stored in the IMA data store.

Load Manager Component 3. The Zone Data Collector

Any time the load index of a MetaFrame server changes, that server sends the new load index to the zone data collector. (Remember from Chapter 3 that the zone data collector then sends that information to all other zone data collectors in the server farm.)

Because the zone data collector knows which of the servers has the least load at any given time, it is always ready to direct ICA clients to the least busy server when they request the address of a published application.

Figure 4.2 shows how the three components of Citrix Load Management work together.

Figure 4.2: The Citrix Load Manager components

The MetaFrame XP Load Management Process

The three Load Manager components work together to perform their tasks in a logical format. To illustrate this, let's look at the steps taken when a user connects to a published application that is load-balanced across multiple MetaFrame XP servers:

1. Even before an ICA user connects, each MetaFrame XP server's Load Evaluator keeps the zone data collector up to date on their server load, based on the various configured rules. This is shown in figure 4.3 on the next page.

  

Figure 4.3: Load Evaluator's on each server update the ZDC

2. Figure 4.4 picks up with step 2, when the ICA client requests a connection to the "MS Word" published application.

  

Figure 4.4: The client connecting process in a load-managed environment

3. As with any published application request, this request is received by the zone data collector (ZDC).

4. The ZDC knows which servers have the published application and what those servers' last reported loads were. From among those servers, the ZDC selects the one with the lowest load index.

5. The ZDC temporarily increases that server's load index in its own table by 200 points. (More on what this number means later.)

6. The ZDC sends the address of the server with the least load to the ICA client.

7. The ICA client connects to a MetaFrame XP server, based on the address received from the ZDC.

8. The MetaFrame XP server updates the ZDC with the new load number changed since the user connected.

Now that we have an overview of how the components of load balancing work together, let's examine each of them in depth, beginning with the Load Evaluators.

How Load Evaluators are used in Load Management

A Load Evaluator in a MetaFrame XP server farm is responsible for analyzing the various rules applied to it and returning a load index to the zone data collector. Remember that the load index can be any integer from 0 to 10,000. A value of 10,000 indicates that the server is full and is not accepting connections. Any value less than 10,000 indicates that the server is accepting connections. The zone data collector will ultimately send users to the server with the smallest load index. The load indexes get higher as they approach 10,000, starting all the way from a value of zero-meaning that a server has no detected load.

Each Load Evaluator has a name, description, and one or more assigned rules. When you assign a rule to an evaluator, you specify the parameters for that rule, such as when it reports a full load (10,000). These parameters vary depending on the rule you are working with. Each load evaluator must have at least one rule configured for it, although a single load evaluator could have all twelve different types of rules applied to it.

Load Evaluators are stored in the server farm. Depending on the rules they have configured, they are then applied to specific servers or published applications. You can create as many different Load Evaluators as you want in a single MetaFrame XP server farm. However, each server in the farm must have one (and only one) Load Evaluator applied to it. Published applications can also have one Load Evaluator applied to them.

Not all Load Evaluators will be used for every ICA client request. For example, different Load Evaluators will be applied to different published applications or different servers. When determining the load index for a server, the zone data collector will look at all the applicable Load Evaluators and use whichever one is greatest. That greatest number is compared to the greatest number of the other servers.

Having Load Evaluators is required in MetaFrame XP with Load Management enabled. There are two default evaluators that can be configured but not deleted. These evaluators always apply, even if you only have one server.

How "Rules" Affect Load Management

Remember that in order to calculate its load index, a Load Evaluator must have one or more "rules" applied to it. The Load Evaluator will use the rules to process current server utilization and generate the load index.

There are four classes of rules (and twelve rules total) that are based on various MetaFrame XP performance components. Each rule is used to create a load index based on a different type of information. There are different types of rules each used differently, depending on the type of performance data to be evaluated. The four types of rules are as follows:

  • Moving average, based on percentages.
  • Moving average, based on manual parameters over time.
  • Incremental.
  • Boolean.

Moving Average Rules, Based on Percentages

Percentage-based rules evaluate performance-based server metrics expressed in terms of percentages (such as the percentage of CPU utilization). To use percentage-based rules, you must specify two parameters: a high value and a low value. The Load Evaluator will then return a load index value based on your parameters. If the performance counter being evaluated is less than your configured minimum, the Load Evaluator will return a value of zero, indicating no server activity. If the counter is higher than the high parameter configured, the Load Evaluator will return a value of 10,000. If the performance counter falls between the high and low configured parameters, the server will return a value proportional to the configured parameters.

Even though the configured parameters are entered as percentages, this does not mean that the returned Load Evaluator will always match that percentage. (A 70% performance counter does not automatically mean that the load evaluator will return 7,000.) Let's consider an example to illustrate how this value is calculated.

Assume that you've configured the CPU utilization rule and have set the low value to 50% and the high value to 90%. Any time the CPU utilization is below 50% the Load Evaluator will return a load index of zero, effectively meaning that there is no load. Any actual CPU utilization over 90% will cause our Load Evaluator to return a load index of 10,000, indicating that the server is fully loaded and not taking on any more ICA sessions. With a high of 90% and a low of 50%, you are left with a 40% range that the Load Evaluator will use for its 0 to 10,000 load index. Simple arithmetic will show that each percentage point of CPU utilization is equal to 250 points in the load index (10,000 / 40 = 250). Therefore, an actual server load of 67% would cause the Load Evaluator to create a load index of 4250 (17 percentage points above 50% (because 50% = 0) multiplied by 250). This makes sense since 67 is 42.5 percent of the way between 50 to 90 (50 and 90 are the respective minimums and maximums that you configured for this rule).

These rules are called "moving average" rules because the actual load index is based on an average of the most recent ten samples. This method evens out unexpected spikes. Each MetaFrame XP server sends new load index samples to the ZDC each time a user event occurs or every 30 seconds. Because of this, the ten sample moving average window could be as long as five minutes or as short as a few seconds if ten people log on at once. There is no way to reset this average, other than by stopping and starting the IMA service.

Of the twelve rule types available, two operate in this percentage fashion:

  • CPU Utilization. On multiprocessor systems this is the average of all the processors.
  • Memory Usage. This is the percentage of the total memory used, including physical and virtual.

Moving Average Rules, Based on Manual Parameters over Time

Similar to the percentage-based moving average rules, some rules are based on actual performance metrics from the server. Instead of specifying the high and low percentages, you specify the actual high and low values. The load evaluator returns a load index between 0 and 10,000 proportionally based on the values you've specified.

There are five types of these rules available. Since they are time-based, they all are based on "per-second" values. Valid values for the high and low inputs for each of these are 0 to 2,147,483,647.

  • Context Switches. Occurs every time the server switches from one process to another.
  • Disk Data I/O. Evaluated based on the actual disk I/O throughput in kilobytes.
  • Disk Operations. The number of disk assesses per second, based on the percentage of high and low configured values.
  • Page Fault. Occurs every time the system must access memory that has been paged to disk.
  • Page Swap. Occurs when the system swaps data in physical memory to the pagefile on the disk.

As the previous type of rules, these rules are also "moving average" rules whose load index is based on an average of the ten most recent values.

In order to get starting points for these rules, you can use Performance Monitor to watch each appropriate counter. As your environment grows, you will most likely need to adjust these settings.

Incremental Rules

Incremental rules are based on the total number of users or licenses in use. Unlike the previous types of rules, incremental rules are not based on performance monitor metrics. You can configure the values that correspond to a full load for these incremental rules.

When an incremental rule is used, the Load Evaluator will return a load index of zero if the item specified for the rule evaluates to zero. If the item meets or exceeds the limit you set, the load evaluator sets the value to 10,000.

For incremental rules, you configure only one parameter-the maximum (because the minimum is assumed zero). Any number between zero and your configured maximum generates a load index proportional from 0 to 10,000.

There are three types of incremental rules. Each has a maximum configurable value of 10,000 (in case there is anyone out there that can actually fit 10,000 users on one server).

  • Application User Load. This is the total number of users accessing the published application that this rule is applied to. It can only be applied to one application. If you have multiple applications that you need to limit then you must create multiple Load Evaluators. This rule is useful if you only have a limited number of licenses for a published application. Be careful though; this rule only applies when running instances of the published application. It does not know about other users who might have connected directly to a server and started the application from there.
  • Server User Load. This rule is similar to the Application User Load rule except that it applies to all users connected to one server. It is based on active ICA sessions. It will not prevent users from reconnecting to disconnected ICA sessions.
  • License Threshold. This rule supports thresholds for two license types: assigned licenses and pooled licenses. You can enter two different limits for this rule, one for each license type. The license threshold will always evaluate to the higher of the two numbers. For example, consider the environment in Figure 4.5.

 

  • Assigned Licenses
    • Rule Threshhold: 80
    • Actual Licenses in Use: 26
  • Pooled Licenses
    • Rule Threshold: 120
    • Actual Licenses in Use: 32

Figure 4.5: License threshold sample configuration

In this case, assigned licenses are 32% in use (26 / 80) and pooled licenses are 27% in use (32 / 120). This means that the license threshold rule would evaluate based on the higher number-the assigned licenses. The load index calculated is 3250 (26 / 80 as a proportion from 0 to 10,000).

If you would like the license threshold rule to evaluate based on only one type of license, simply enter a value of 0 for the type that you would like to ignore.

Boolean Rules

The final rule type that can be configured are Boolean rules. Boolean rules are based on whether the criterion evaluates to be true or false. Unlike other rules that return a sliding scale load index from 0 to 10,000, Boolean rules have no load values. As the name implies, they have two states: "yes" or "no." They can return a value of 0 or 10,000-nothing in between.

Boolean rules are based on an external parameter, such as the time of day or a user's IP address. They are not based on actual performance or load of a MetaFrame XP server. This means that all Boolean rules must be used in conjunction with other rules. (Remember that you can add as many rules as your want to a single Load Evaluator.) As an example, suppose you had only one Boolean rule applied with no other rules across five servers. When the Boolean rule was true it would evaluate to "0" for all five servers-causing them all to have equal load balance indexes. In this case, the client would be connected to the machine with the lowest host ID. Subsequent ICA clients would experience the same scenario. Because the load index would never change they too would connect to the server with the lowest host ID. All users would connect to the same server because the load index would never change with only the Boolean rule applied, and the host ID would never change since it's a permanent internal setting.

Boolean rules can only be used to determine whether an ICA client can connect to a published application. These rules do not prevent a user from connecting to a server directly and running the application from the remote desktop session.

There are two types of Boolean rules:

  • IP Range. The Load Evaluator can enable or disable access based on an ICA client's IP address. You can configure multiple IP address ranges for this rule. The IP Range rule is evaluated through a two step process. First, the client's IP address is checked to see whether it's within any of the specified ranges for the rule. To be within range, the client's IP address must be greater than or equal to the first value and less than or equal to the second value. (Warning: When you configure this rule, there is no logic to ensure that the first value is less than the second value. If the first value is greater than the second, no IP addresses will ever evaluate within range.) If a client's IP address is determined to be in range, then access is granted or denied based on the setting of the rule, either granting access to all IP addresses within range or denying access to all IP addresses within range.
  • Scheduling. This rule's evaluation is based on the day of week and time of day as specified by the server's clock. This is useful if you only want to allow access to servers during business hours. (Hint: when you're applying this rule, you don't need to click in each individual little square. You can click and drag to turn on or turn off complete ranges.) However, this rule will not force users off of the system if they're already connected. Of course, you can use the native Microsoft tools to enforce logon hours. See the Chapter 15 for more details.

The Zone Data Collector's Role in Load Management

The zone data collector constantly keeps track of load indexes for every server in the farm. (Note: This is not a typo. Each zone data collector always knows the load information of every server in the entire server farm, not just its local zone.) When an ICA client makes a request to launch a published application, the zone data collector will return the address of the server with the least load. If all servers have a value of 10,000, the client connection is refused.

MetaFrame XP servers send their load index updates to the zone data collector anytime a user event occurs. Remember from Chapter 3 that "user events" include activities such as user logon, logoff, connection, or disconnection. If you perform a network analysis of that transaction, you'll see that a MetaFrame server sends both its load index and its current user count to the zone data collector.

Additionally, the MetaFrame XP server sends an updated load index value if no user events occur over a period of five minutes. You can change this interval via the Citrix Management Console. (CMC | Farm | Actions | Load Manager | Load Manager Settings) When Load Management is in use, MetaFrame XP servers will also update the zone data collector if their load index changes (up or down) by more than 500 points within a 30 second period.

When the zone data collector checks farm servers' load indexes (as when a client requests a connection to a published application), it does not take into consideration any user or protocol restrictions. If a user requests an application via the IPX protocol and the least loaded server only has TCP/IP, then the user will not be able to connect, because the zone data collector will provide the user with the address of a server that is not running the same protocol as the user. Realistically, this should not be an issue, because you should only publish applications where any user of the application could access it on one of the servers where it is configured. If you need to get more granular with user rights then you'll need to publish multiple applications.

Citrix Load Manager is only used when an ICA client starts a new session via a published application. There are some situations where Citrix Load Manager is not used to route users to a server, even if Load Management is enabled. These situations are as follows:

  • Direct connection to a MetaFrame XP server. If a user connects directly to a MetaFrame server (instead of a published application), their ICA client does not request server information from the zone data collector, so the zone data collector never has a chance to affect which server the user accesses.
  • Reconnecting to a disconnected session. When a user reconnects to a disconnected session, his session already exists on one server, causing their client device to connect back to that server. In this case, the ICA client still requests connection routing from the zone data collector, but the fact that an existing disconnected session is running takes precedence over the load balancing numbers, even if the server load is 10,000.
  • Session sharing with Seamless Windows. If a Windows client has one session established with a MetaFrame XP server via Seamless Windows, connecting to another published application will launch that application on the same server as the first session, unless that application is not published on the same server.

In all three cases, the MetaFrame XP server will notify the zone data collector of its new load index once the user connects.

Load Management Strategies

Now that you understand how load management works, let's see how it can be used in the real world. Figure 4.6 shows three servers, their specifications, and the applications that will be published on each.

  • Server A
    • Processors: 1 x 1.26 GHz
    • Memory: 1 GB
    • Published Applications: Word, Excel, Acrobat
  • Server B
    • Processors: 2 x 1.26 GHz
    • Memory: 2 GB
    • Published Applications: Word, Excel, Visio
  • Server C
    • Processors: 2 x 1.26 GHz
    • Memory: 4 GB
    • Published Applications: Word, Excel, Visio, Acrobat

Figure 4.6: A typical load-managed environment

Configuring Server Load

Remember that each MetaFrame XP server must have one Load Evaluator applied. A generic Load Evaluator called "Default" is applied to each server out of the box. This Load Evaluator consists of one rule-"Server User Load"-with the maximum number of users set at 10,000. Even without any additional configuration, this default Load Evaluator will successfully equalize the user load in the environment shown in Figure 4.6. However, because both Server B and Server C have twice the processing power as Server A, you wouldn't want your users distributed evenl between the servers. Ideally, you'd like twice as many users to go to Servers B and C. The easiest way to do this is to create a unique Load Evaluator for each of the two types of servers. Let's take a look at that process:

  1. Create a Load Evaluator for Server A called "1x1.26GHz."
  2. Create a Load Evaluator for Servers B and C called "2x1.26GHz."
  3. Like the default Load Evaluator, you would only need to apply one rule to your custom Load Evaluators. Also like the default Load Evaluator, you could use the "Server User Load" rule.
  4. Configure the maximum number of users for each Load Evaluator's rule so that the "2x1.26GHz" Load Evaluator's maximum is twice as large as the maximum for "1x1.26GHz."

Now that you've decided that the user load rule value for the "2x1.26GHz" rule should be twice as high as the "1x1.26GHz" rule, you need to decide what the rule's values should be. Should you enter realistic numbers that match your licenses, like "80" and "40," or should you enter false, high numbers, like "5,000" and "10,000?" To address this, think back to how load manager works.

In both cases, the load of the servers will be managed effectively. Consider this scenario:

  • Server A
    • Current Users: 3
    • Load Index with Max Users Set at 80/40: 750 (3 out of 40)
    • Load Index with Max Users Set at 10000/5000: 6 (3 out of 5000)
  • Server B
    • Current Users: 5
    • Load Index with Max Users Set at 80/40: 625 (5 out of 80)
    • Load Index with Max Users Set at 10000/5000: 5 (5 out of 10000)
  • Server C
    • Current Users: 4
    • Load Index with Max Users Set at 80/40: 500 (4 out of 80)
    • Load Index with Max Users Set at 10000/5000: 4 (4 out of 10000)

Figure 4.7: Light usage load indexes with various "Server User Load" values

Notice that the ratios of the load indexes between Servers A, B, and C are identical, regardless of whether the Load Evaluators have rules with maximum user limits that are sky-high (10000/5000) or more down to earth (80/40). In this case, the next user that connects will be routed to Server C. Now, let's re-examine this scenario taking into account servers more heavily used.

As you can see in Figure 4.8, no additional users would be able to connect with the lower limits (80/40) because a load index of 10,000 will not allow any more users to connect to a server. With high limits (10000/5000), the servers can take on more users. Because the load indexes for all three servers is the same (80), the user requesting the connection will be given the address of the machine with the lowest host ID.

  • Server A
    • Current Users: 40
    • Load Index with Max Users Set at 80/40: 10000 (40 out of 40)
    • Load Index with Max Users Set at 10000/5000: 80 (40 out of 5000)
  • Server B
    • Current Users:  80
    • Load Index with Max Users Set at 80/40: 10000 (80 out of 80)
    • Load Index with Max Users Set at 10000/5000: 80 (80 out of 10000)
  • Server C
    • Current Users:  80
    • Load Index with Max Users Set at 80/40: 10000 (80 out of 80)
    • Load Index with Max Users Set at 10000/5000: 80 (80 out of 10000)

Figure 4.8: Heavy usage load indexes with various "Server User Load" values

Fine Tuning Load Evaluators

You'll probably want to fine-tune your farm's load evaluators after you build your initial environment. This fine tuning usually involves adding more rules to the existing Load Evaluators. (Remember that even though only one Load Evaluator can be applied to each server, that Load Evaluator can be built upon more than one rule.)

For example, you might be worried that some of your servers will run out of memory because the current Load Evaluators are based only on one rule-"Server User Load." This means that even if a server runs out of memory the zone data collector will still try to have users connect to it because the Load Evaluators are not configured with any rules that look at memory usage. Ideally, you should create a Load Evaluator that would prevent users from connecting if the memory utilization was full.

Figure 4.9 shows the current Load Evaluator (named "1x1.26GHz") that is applied to Server A. This load evaluator has only one rule applied, the "Server User Load." Figure 4.10 shows the properties of the second rule-based on the memory usage-that could be added to the existing "1x1.26GHz" Load Evaluator.

  • Maximum Users
    • Server User Load: 40

Figure 4.9: The current Load Evaluator for Server A 

  • Minimum
    • Memory Usage %: 80
  • Maximum
    • Memory Usage %: 90

Figure 4.10: Properties for an additional rule for Server A's Load Evaluator

Once the second rule is added, the Load Evaluator will calculate its load index based on both rules. By setting the second rule's memory usage minimum to 80%, the second rule will always evaluate to zero until memory utilization hits 80%. At 90%, that rule will evaluate to a load index of 10,000, causing the server to be unavailable. (That rule will evaluate to a number between 0 and 10,000 for memory utilization between 80 and 90%.)

By adding this second rule, no additional users will be able to connect if the memory usage gets really high-even if only 10 or 20 users are currently connected. In effect, the memory utilization rule becomes a type of "circuit breaker," protecting the server from memory over-utilization.

Checking Server Load

As you're tuning your Load Evaluators, it's helpful to be able to view the various load indexes. This can be done with the "qfarm" command-line tool. There are two options that will return load management numbers:

  • qfarm /load. This command displays information about the load balanced servers in your farm.
  • qfarm /app. This command displays information about the load balanced published applications in your farm.

The "qfarm" command line utility will display the load indexes for servers or applications. Additionally, the qfarm utility can report other information about Load Manager (as detailed in Figure 4.11).

  • Load Value: 0-9999
    • Description: Load index value.
  • Load Value: 10000
    • Description: The server or application is full.
  • Description: Load Value: 20000
    • Description: The server is not a Load Managed server.
  • Load Value: 99990
    • Description: There is a problem with Load Management on the server.
  • Load Value: 99999
    • Description: There is no Load Evaluator attached to the application

Figure 4.11: Load Manager values as reported by the qfarm utility

Load Evaluators-Which rules to compare?

You can essentially build a customized load management environment by creating load evaluators with multiple rules applied. You can also create unique Load Evaluators based on completely different rules and apply them to different servers. You don't have to configure each Load Evaluator to calculate its load index in the same way.

The million-dollar question then becomes, "How do the Load Evaluators calculate their load indexes when multiple rules are applied?"

The "common denominator" in these cases is the load index calculated by each Load Evaluator. Remember that all the zone data collector cares about when looking at load is the load index (that number between 0 and 10,000 that each server sends to the zone data collector). The zone data collector isn't concerned with how the load index was calculated. For example, it is perfectly acceptable for one server (with one Load Evaluator applied) to calculate its load index based on memory utilization and another server (with another Load Evaluator applied) to calculate its load index based on processor utilization.

How does the zone data collector compare the processor utilization of one server to the memory utilization of another? It uses the load index numbers. Whichever server has the lowest load index gets the user. Consider the scenario in Figure 4.12. Each of the servers has a different Load Evaluator applied to it. Each Load Evaluator has one rule applied based on different criteria: processor utilization, memory utilization, or current users.

  • Server A
    • Load Evaluator Rule: % Proc Util
    • LE Rule Max / Min:60 / 0
    • Actual Number: 50% Actual
    • Load Index: 8333 (50 out of 60)
  • Server B
    • Load Evaluator Rule: % Mem Usage
    • LE Rule Max / Min: 90 / 0
    • Actual Number: 70% Actual
    • Load Index: 7777 (70 out of 90)
  • Server C
    • Load Evaluator Rule: Current Users
    • LE Rule Max / Min: 50 / na
    • Actual Number: 41 current users
    • Load Index: 8200 (41 out of 50)

Figure 4.12: Load indexes with different Load Evaluators applied

If an ICA client requests the address of the least busy server, the zone data collector will have no problem returning the address of Server B, since its load index is the lowest (7777) out of the three servers. However, can we, as administrators, really say that memory utilization alone made that server less busy than the processor utilization or number of users on Server A or C? In the real world, load scenarios like this are rare, mainly because they're confusing.

Applying Load Evaluators to Published Applications

So far, all analysis we've done regarding Load Evaluators relates to server load. If you think back to the introduction to this section, we also said that you can apply Load Evaluators to published applications (CMC | Published Applications | Right-Click | Select Load Manage).

Load Evaluators are configured for each instance of the published application running on each server. As with server-based Load Evaluators, it's possible to apply a different Load Evaluator to each instance of the published application on each unique server. This allows you to create extremely complex load management environments.

When a MetaFrame XP server sends its load information to the zone data collector, it sends the load index for itself (calculated via the Load Evaluator applied to the server) and any load indexes applied to published applications (calculated via the Load Evaluator applied to a specific published application on that server).

The main reason that you would use application-based Load Evaluators is if you had different types of applications with different requirements. You might create one Load Evaluator with the "Total User Sessions" rule and apply it to a server, and create another Load Evaluator with the "Schedule" rule and apply it to a published application. That way you can still get server-based load management while having scheduled time to take applications offline.

Creating Load Evaluators based on published applications could get you into a situation where a user is making a connection to a server and two load indexes apply-one for the server and one for the published application the user requested on that server. In this case, the zone data collector uses the higher of the two indexes. The zone data collector then sends the client to the server with the lowest load index.

Load Management Performance

Citrix Load Manager includes a Load Management logging tool (CMC | Load Evaluators | Logging). This logging tool can be used for troubleshooting the load manager. (Note that this tool should not be used for security auditing purposes because it is not always 100% reliable.)

When using the Citrix Management Console, you will notice that the performance is slow, especially when selecting servers for Load Management and when attaching Load Evaluators to servers. Interestingly, in large environments, the CMC will report that it is done enumerating servers and has found them all. Even after this message, the CMC may continue to find more servers.

 

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close