Manager, Advisors, and Metric Server functions for Dispatcher, CBR, and Site Selector

This chapter explains how to configure the load balancing parameters and how to set up the manager, advisors, and Metric Server functions of Load Balancer.

Note:
When reading this chapter, if you are not using the Dispatcher component, then substitute "dscontrol" with the following:
Table 16. Advanced configuration tasks for Load Balancer
Task Description Related information
Optionally, change load-balancing settings

You can change the following load-balancing settings:

  • Proportion of importance given to status information

    The default ratio is 50-50-0-0. If you use the default, information from advisors, Metric Server, and WLM are not used.

  • Weights
  • Manager fixed weights
  • Manager intervals
  • Sensitivity threshold
  • Smoothing index
Optimizing the load balancing provided by Load Balancer
Use scripts to generate an alert or record server failure when manager marks server(s) down or up Load Balancer provides user exits that trigger scripts that you can customize when the manager marks server(s) down or up Using scripts to generate an alert or record server failure
Use advisors Describes and lists the advisors, which report on specific statuses of your servers Advisors
Use HTTP or HTTPS advisor request and response (URL) option Define a unique client HTTP URL string, specific for a service that you want to query on the machine Configuring the HTTP or HTTPS advisor using the request and response (URL) option
Use self advisor Provides backend server load status in a Load Balancer two-tiered WAN configuration Using Self Advisor in a two-tiered WAN configuration
Create custom advisors Describes how to write your own custom advisors Create custom (customizable) advisors
Use Metric Server agent Metric Server provides system load information to Load Balancer Metric Server
Use Workload Manager advisor (WLM) WLM advisor provides system load information to Load Balancer Workload Manager advisor

Optimizing the load balancing provided by Load Balancer

The manager function of Load Balancer performs load balancing based on the following settings:

You can change these settings to optimize load balancing for your network.

Proportion of importance given to status information

The manager can use some or all of the following external factors in its weighting decisions:

Along with the current weight for each server and some other information required for its calculations, the manager gets the first two values (active and new connections) from the executor. These values are based on information that is generated and stored internally in the executor.

Note:
For Site Selector, the manager obtains the first two values (CPU and memory) from Metric Server.

You can change the relative proportion of importance of the four values on a per cluster (or site name) basis. Think of the proportions as percentages; the sum of the relative proportions must equal 100%. The default ratio is 50/50/0/0, which ignores the advisor and system information. In your environment, you may need to try different proportions to find the combination that gives the best performance.

Note:
When adding an advisor (other than WLM), if the port proportion is zero, then the manager increases this value to 1. Because the sum of the relative proportions must total 100, the highest value is then decreased by 1.

When adding the WLM advisor, if the system metric proportion is zero, then the manager increases this value to 1. Because the sum of the relative proportions must total 100, the highest value is then decreased by 1.

The number of active connections is dependent upon the number of clients as well as the length of time necessary to use the services that are being provided by the load balanced server machines. If the client connections are quick (such as small Web pages served using HTTP GET), then the number of active connections are fairly low. If the client connections are slower (such as a database query), then the number of active connections are higher.

You should avoid setting active and new connections proportions values too low. You will disable load balancing and smoothing unless you have these first two values set to at least 20 each.

To set the proportion of importance values use the dscontrol cluster set cluster proportions command. See dscontrol cluster -- configure clusters for more information.

Weights

Weights are set by the manager function based upon internal counters in the executor, feedback from the advisors, and feedback from a system-monitoring program, such as Metric Server. If you want to set weights manually while running the manager, specify the fixedweight option on the dscontrol server command. For a description of the fixedweight option, see Manager fixed weights.

Weights are applied to all servers on a port. For any particular port, the requests are distributed between servers based on their weights relative to each other. For example, if one server is set to a weight of 10, and the other to 5, the server set to 10 should get twice as many requests as the server set to 5.

To specify the maximum weight boundary that any server can have, use the dscontrol port set port weightbound weight command. This command affects how much difference there can be between the number of requests each server will get. If you set the maximum weightbound to 1, then all the servers can have a weight of 1, 0 if quiesced, or -1 if marked down. As you increase this number, the difference in how servers can be weighted is increased. At a maximum weightbound of 2, one server could get twice as many requests as another. At a maximum weightbound of 10, one server could get 10 times as many requests as another. The default maximum weightbound is 20.

If an advisor finds that a server has gone down, it tells the manager, which sets the weight for the server to zero. As a result, the executor will not send any additional connections to that server as long as that weight remains zero. If there were any active connections to that server before the weight changed, they will be left to complete normally.

If all the servers are down, the manager sets the weights to half the weightbound.

Manager fixed weights

Without the manager, advisors cannot be run and cannot detect if a server is down. If you choose to run the advisors, but do not want the manager to update the weight you have set for a particular server, use the fixedweight option on the dscontrol server command. For example:

dscontrol server set cluster:port:server fixedweight yes

After fixedweight is set to yes, use the dscontrol server set weight command to set the weight to the value you desire. The server weight value remains fixed while the manager is running until you issue another dscontrol server command with fixedweight set to no. For more information, see dscontrol server -- configure servers.

Sending TCP reset to a down server (Dispatcher component only)

If TCP reset is activated, Dispatcher will send a TCP reset to the client when the client has a connection to a server whose weight is 0. A server's weight may be 0 if it is configured 0 or if an advisor marks it down. A TCP reset will cause the connection to be immediately closed. This feature is useful for long-lived connections where it hastens the client's ability to renegotiate a failed connection. To activate TCP reset, use the dscontrol port add|set port reset yes command. The default value for reset is no.

Note:
TCP reset applies to all of the Dispatcher's forwarding methods. However, to use the TCP reset feature, the clientgateway on the dscontrol executor command must be set to a router address.

A useful feature to configure, in conjunction with TCP reset, is advisor retry. With this feature, an advisor has the ability to retry a connection before marking a server down. This would help prevent the advisor from marking the server down prematurely which could lead to connection-reset problems. That is, just because the advisor failed on the first attempt does not necessarily mean that the existing connections are also failing. See Advisor retry for more information.

Manager intervals

To optimize overall performance, the manager is restricted in how often it can interact with the executor. You can make changes to this interval by entering the dscontrol manager interval and dscontrol manager refresh commands.

The manager interval specifies how often the manager will update the server weights that the executor uses in routing connections. If the manager interval is too low, it can mean poor performance as a result of the manager constantly interrupting the executor. If the manager interval is too high, it can mean that the executor's request routing will not be based on accurate, up-to-date information.

For example, to set the manager interval to 1 second, enter the following command:

 dscontrol manager interval 1

The manager refresh cycle specifies how often the manager will ask the executor for status information. The refresh cycle is based on the interval time.

For example, to set the manager refresh cycle to 3, enter the following command:

  dscontrol manager refresh 3

This will cause the manager to wait for 3 intervals before asking the executor for status.

Sensitivity threshold

Other methods are available for you to optimize load balancing for your servers. To work at top speed, updates to the weights for the servers are only made if the weights have changed significantly. Constantly updating the weights when there is little or no change in the server status would create an unnecessary overhead. When the percentage weight change for the total weight for all servers on a port is greater than the sensitivity threshold, the manager updates the weights used by the executor to distribute connections. Consider, for example, that the total weight changes from 100 to 105. The change is 5%. With the default sensitivity threshold of 5, the manager will not update the weights used by the executor, because the percentage change is not above the threshold. If, however, the total weight changes from 100 to 106, the manager will update the weights. To set the manager's sensitivity threshold to a value other than the default (for example, 6), enter the following command:

  dscontrol manager sensitivity 6

In most cases, you will not need to change this value.

Smoothing index

The manager calculates the server weights dynamically. As a result, an updated weight can be very different from the previous one. Under most circumstances, this will not be a problem. Occasionally, however, it may cause an oscillating effect in the way the requests are load balanced. For example, one server can end up receiving most of the requests due to a high weight. The manager will see that the server has a high number of active connections and that the server is responding slowly. It will then shift the weight over to the free servers and the same effect will occur there too, creating an inefficient use of resources.

To alleviate this problem, the manager uses a smoothing index. The smoothing index limits the amount that a server's weight can change, effectively smoothing the change in the distribution of requests. A higher smoothing index will cause the server weights to change less drastically. A lower index will cause the server weights to change more drastically. The default value for the smoothing index is 1.5. At 1.5, the server weights can be rather dynamic. An index of 4 or 5 will cause the weights to be more stable. For example, to set the smoothing index to 4, enter the following command:

  dscontrol manager smoothing 4

In most cases, you will not need to change this value.

Using scripts to generate an alert or record server failure

Load Balancer provides user exits that trigger scripts that you can customize. You can create the scripts to perform automated actions, such as alerting an Administrator when servers are marked down by the manager or simply record the event of the failure. Sample scripts, which you can customize, are in the ...ibm/edge/lb/servers/samples installation directory. In order to run the files, you must move them to the ...ibm/edge/lb/servers/bin directory and remove the "sample" file extension. The following sample scripts are provided:

If all servers on a cluster are marked down (either by the user or by the advisors), the managerAlert (if configured) starts, and Load Balancer attempts to route traffic to the servers using a round-robin technique. The serverDown script does not start when the last server in the cluster is detected as offline.

By design, Load Balancer attempts to continue to route the traffic in case a server comes back online and responds to the request. If Load Balancer instead dropped all traffic, the client would receive no response.

When Load Balancer detects that the first server of a cluster is back online, the managerClear script (if configured) starts, but the serverUp script (if configured) is not run until an additional server is brought back online.

Considerations when using serverUp and serverDown scripts:

Advisors

Advisors are agents within Load Balancer. Their purpose is to assess the health and loading of server machines. They do this with a proactive client-like exchange with the servers. Advisors can be considered as lightweight clients of the application servers.

The product provides several protocol-specific advisors for the most popular protocols. However, it does not make sense to use all of the provided advisors with every component of Load Balancer. (For instance, you do not use the Telnet advisor with the CBR component.) Load Balancer also supports the concept of a "custom advisor" that allows users to write their own advisors.

Limitation on using bind-specific server applications: In order to use advisors on bind specific servers, start two instances of the server: One instance to bind on the cluster:port and the other instance to bind on the server:port. To determine if the server is bind specific, issue the netstat -an command and look for the server:port. If the server is not bind specific, the result from this command will be 0.0.0.0:80. If the server is bind specific, you will see an address such as 192.168.15.103:80.

For HP-UX and Solaris systems, limitation on using bind-specific server applications: If using arp publish instead of ifconfig alias command, Load Balancer will support the use of advisors when load-balancing servers with bind-specific server applications (including other Load Balancer components such as CBR or Site Selector) when they are binding to the cluster IP address. However, when using advisors against bind-specific server application, do not collocate Load Balancer on the same machine with the server application.

Note:
When Load Balancer is running on a computer with multiple network adapter cards, and if you want the advisor traffic to flow over a particular adapter, you can force the source IP address of the packets to be a particular address. To force the advisor packet source address to a particular address, add the following to the java...SRV_XXXConfigServer... line of the appropriate Load Balancer start script file (dsserver, cbrserver, or ssserver):
-DLB_ADV_SRC_ADDR=IP_address

How advisors work

Advisors periodically open a TCP connection with each server and send a request message to the server. The content of the message is specific to the protocol running on the server. For example, the HTTP advisor sends an HTTP "HEAD" request to the server.

Advisors then listen for a response from the server. After getting the response, the advisor makes an assessment of the server. To calculate this "load" value, most advisors measure the time for the server to respond, and then use this value (in milliseconds) as the load.

Advisors then report the load value to the manager function, where it appears in the manager report in the "Port" column. The manager then calculates aggregate weight values from all its sources, per its proportions, and sets these weight values into the executor function. The Executor will then use these weights for load balancing new incoming client connections.

If the advisor determines that a server is alive and well, it will report a positive, non-zero load number to the Manager. If the advisor determines that a server is not active, it will return a special load value of negative one (-1). The Manager and the Executor will not forward any further connections to that server until that server has come back up.

Note:
Before sending the initial request message, the advisor will ping the server. This is intended to provide quick status to determine if the machine is online. After the server responds to the ping, no more pings are sent. To disable the pings, add -DLB_ADV_NB_PING to the Load Balancer start script file.

Starting and stopping an advisor

You can start an advisor for a particular port across all clusters (group advisor). Or, you can choose to run different advisors on the same port, but on different clusters (cluster/site specific advisor). For example, if you have Load Balancer defined with three clusters (clusterA, clusterB, clusterC), each having port 80 you can do the following:

Using the previous configuration example for the group advisor, you can choose to stop the custom advisor ADV_custom for port 80 on just one of the clusters or for both clusters (clusterB and clusterC).

Advisor intervals

Note:
The advisor defaults should work efficiently for the great majority of possible scenarios. Be careful when entering values other than the defaults.

The advisor interval sets how often an advisor asks for status from the servers on the port it is monitoring and then reports the results to the manager. If the advisor interval is too low, it can mean poor performance as a result of the advisor constantly interrupting the servers. If the advisor interval is too high, it can mean that the manager's decisions about weighting will not be based on accurate, up-to-date information.

For example, to set the interval to 3 seconds for the HTTP advisor for port 80, enter the following command:

  dscontrol advisor interval http 80 3

It does not make sense to specify an advisor interval that is smaller than the manager interval. The default advisor interval is seven seconds.

Advisor report timeout

To make sure that out-of-date information is not used by the manager in its load-balancing decisions, the manager will not use information from the advisor whose time stamp is older than the time set in the advisor report timeout. The advisor report timeout should be larger than the advisor polling interval. If the timeout is smaller, the manager will ignore reports that logically should be used. By default, advisor reports do not timeout -- the default value is unlimited.

For example, to set the advisor report timeout to 30 seconds for the HTTP advisor for port 80, enter the following command:

dscontrol advisor timeout http 80 30 

For more information on setting the advisor report timeout, see dscontrol advisor -- control the advisor.

Advisor connect timeout and receive timeout for servers

For Load Balancer, you can set the advisor's timeout values at which it detects a particular port on the server (a service) is failed. The failed-server timeout values (connecttimeout and receivetimeout) determine how long an advisor waits before reporting that either a connect or receive has failed.

To obtain the fastest failed-server detection, set the advisor connect and receive timeouts to the smallest value (one second), and set the advisor and manager interval time to the smallest value (one second).

Note:
If your environment experiences a moderate to high volume of traffic such that server response time increases, be careful not to set the connecttimeout and receivetimeout values too small, or the advisor may prematurely mark a busy server as failed.

For example, to set the connecttimeout and receivetimeout to 9 seconds for the HTTP advisor on port 80, type the following command:

dscontrol advisor connecttimeout http 80 9
dscontrol advisor receivetimeout http 80 9  

The default for connect and receive timeout is 3 times the value specified for the advisor interval time.

Advisor retry

Advisors have the ability to retry a connection before marking a server down. The advisor will not mark a server down until the server query has failed the number of retries plus 1. The retry value should be no larger than 3. The following command sets a retry value of 2 for the LDAP advisor on port 389:

dscontrol advisor retry ldap 389 2

List of advisors

Configuring the HTTP or HTTPS advisor using the request and response (URL) option

The URL option for the HTTP or HTTPS advisor is available for the Dispatcher and CBR components.

After you have started an HTTP or HTTPS advisor, you can define a unique client HTTP URL string, specific for the service that you want to query on the server. This allows the advisor to assess the health of the individual services within a server. You can do this by defining logical servers with unique server names that have the same physical IP address. See Server Partitioning: logical servers configured to one physical server (IP address) for more information.

For each defined logical server under the HTTP port you can specify a unique client HTTP URL string, specific for the service that you want to query on the server. The HTTP or HTTPS advisor uses the advisorrequest string to query the health of the servers. The default value is HEAD / HTTP/1.0. The advisorresponse string is the response that the advisor scans for in the HTTP response. The advisor uses the advisorresponse string to compare to the real response that is received from the server. The default value is null.

Important: If a blank is contained within the HTTP URL string:

When you create the request that the HTTP or HTTPS advisor sends to back-end servers to see if they are functioning, you type the start of the HTTP request and Load Balancer completes the end of the request with the following:

\r\nAccept:
*/*\r\nUser-Agent:IBM_Load_Balanacer_HTTP_Advisor\r\n\r\n 

If you want to add other HTTP header fields before Load Balancer appends this string to the end of the request, you can do so by including your own \r\n string in the request. The following is an example of what you might type to add the HTTP host header field to your request:

GET /pub/WWW/TheProject.html HTTP/1.0 \r\nHost: www.w3.org
Note:
After starting an HTTP or HTTPS advisor for a specified HTTP port number, the advisor request and response value is enabled for servers under that HTTP port.

See dscontrol server -- configure servers for more information.

Using Self Advisor in a two-tiered WAN configuration

The self advisor is available on the Dispatcher component.

For Load Balancer in a two-tiered WAN (wide area network) configuration, Dispatcher provides a self advisor that collects load status information on backend servers.

Figure 31. Example of a two-tiered WAN configuration using the self advisor
Two-tiered WAN configuration using the self advisor

In this example, the self advisor along with Metric Server reside on the two Dispatcher machines that are being load balanced by the top tier Load Balancer. The self advisor specifically measures the connections per second rate on backend servers of the Dispatcher at the executor level.

The self advisor writes the results to the dsloadstat file. Load Balancer also provides an external metric called dsload. The Metric Server agent on each Dispatcher machine runs its configuration that calls the external metric dsload. The dsload script extracts a string from the dsloadstat file and returns it to the Metric Server agent. Subsequently, each of the Metric Server agents (from each of the Dispatchers) returns the load status value to the top-tiered Load Balancer for use in determining which Dispatcher to forward client requests.

The dsload executable resides in the ...ibm/edge/lb/ms/script directory for Load Balancer.

See Configure wide area Dispatcher support for more information on using Dispatcher in WAN configurations. See Metric Server for more information on Metric Server.

Create custom (customizable) advisors

The custom (customizable) advisor is a small piece of Java code, which you provide as a class file, that gets called by the base code. The base code provides all administrative services, such as starting and stopping an instance of the custom advisor, providing status and reports, and recording history information in a log file. It also reports results to the manager component. Periodically the base code will perform an advisor cycle, where it individually evaluates all servers in its configuration. It starts by opening a connection with a server machine. If the socket opens, the base code will call the "getLoad" method (function) in the custom advisor. The custom advisor then performs whatever steps are necessary to evaluate the health of the server. Typically, it will send a user-defined message to the server and then wait for a response. (Access to the open socket is provided to the custom advisor.) The base code then closes the socket with the server and reports the load information to the Manager.

The base code and custom advisor can operate in either normal or replace mode. Choice of the mode of operation is specified in the custom advisor file as a parameter in the constructor method.

In normal mode, the custom advisor exchanges data with the server, and the base advisor code times the exchange and calculates the load value. The base code then reports this load value to the manager. The custom advisor needs only return a zero (on success) or negative one (on error). To specify normal mode, the replace flag in the constructor is set to false.

In replace mode, the base code does not perform any timing measurements. The custom advisor code performs whatever operations are desired for its unique requirements, and then returns an actual load number. The base code will accept the number and report it to the manager. For best results, normalize your load number between 10 and 1000, with 10 representing a fast server, and 1000 representing a slow server. To specify replace mode, the replace flag in the constructor is set to true.

With this feature, you can write your own advisors that will provide the precise information about servers that you need. A sample custom advisor, ADV_sample.java, is provided with the Load Balancer product. After installing Load Balancer, you may find the sample code in
...<install directory>/servers/samples/CustomAdvisors
installation directory.

The default install directory is:

Note:
If you add a custom advisor to Dispatcher, or any other applicable Load Balancer component, you must stop and then restart dsserver (or the service for Windows systems) to enable the Java process to read the new custom advisor class files. The custom advisor class files are loaded only at startup. It is not necessary to stop the executor. The executor continues to run even when dsserver, or the service, has been stopped.

If the custom advisor references additional Java classes, the classpath in the Load Balancer start script file (dsserver, cbrserver, ssserver) should be updated to include the location.

WAS advisor

Sample custom advisor files specifically for the WebSphere Application Server (WAS) advisor are provided in the Load Balancer installation directory.

The WebSphere Application Server advisor sample files reside in the same samples directory as the ADV_sample.java file.

Naming Convention

Your custom advisor file name must be in the form "ADV_myadvisor.java." It must start with the prefix " ADV_" in uppercase. All subsequent characters must be in lowercase letters.

As per Java conventions, the name of the class defined within the file must match the name of the file. If you copy the sample code, be sure to change all instances of "ADV_sample" inside the file to your new class name.

Compilation

Custom advisors are written in Java language. Use the Java compiler that is installed with Load Balancer. These files are referenced during compilation:

Your classpath must point to both the custom advisor file and the base classes file during the compile.

For Windows systems, a sample compile command is:

install_dir/java/bin/javac -classpath 
    install_dir\lb\servers\lib\ibmlb.jar ADV_fred.java

where:

The output for the compilation is a class file, for example

ADV_fred.class

Before starting the advisor, copy the class file to the ...ibm/edge/lb/servers/lib/CustomAdvisors installation directory.

Note:
If you wish, custom advisors may be compiled on one operating system and run on another. For example, you may compile your advisor on Windows systems, copy the class file (in binary) to an AIX machine, and run the custom advisor there.

For AIX, HP-UX, Linux, and Solaris systems, the syntax is similar.

Run

To run the custom advisor, you must first copy the class file to the proper installation directory:

...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_fred.class

Configure the component, start its manager function, and issue the command to start your custom advisor:

dscontrol advisor start fred 123

where:

If the custom advisor references additional Java classes, the classpath in the Load Balancer start script file (dsserver, cbrserver, ssserver) should be updated to include the location.

Required routines

Like all advisors, a custom advisor extends the function of the advisor base, called ADV_Base. It is the advisor base that actually performs most of the advisor's functions, such as reporting loads back to the manager for use in the manager's weight algorithm. The advisor base also performs socket connect and close operations and provides send and receive methods for use by the advisor. The advisor itself is used only for sending and receiving data to and from the port on the server being advised. The TCP methods within the advisor base are timed to calculate the load. A flag within the constructor in the ADV_base overwrites the existing load with the new load returned from the advisor if desired.

Note:
Based on a value set in the constructor, the advisor base supplies the load to the weight algorithm at specified intervals. If the actual advisor has not completed so that it can return a valid load, the advisor base uses the previous load.

These are base class methods:

Search order

Load Balancer first looks at the list of native advisors that it provides. If it does not find a given advisor there, Load Balancer then looks at the customer's list of customized advisors.

Naming and path

Sample advisor

The program listing for a sample advisor is included in Sample advisor. After installation, this sample advisor can be found in the ...ibm/edge/lb/servers/samples/CustomAdvisors directory.

Metric Server

This feature is available for all the Load Balancer components.

Metric Server provides server load information to the Load Balancer in the form of system-specific metrics, reporting on the health of the servers. The Load Balancer manager queries the Metric Server agent residing on each of the servers, assigning weights to the load balancing process using the metrics gathered from the agents. The results are also placed into the manager report.

Note:
When two or more metrics are gathered and normalized for each server into a single system load value, rounding errors may occur.

For information on operating Metric Server (starting and stopping) and using Metric Server logs see Using the Metric Server component.

For a configuration example see Figure 5.

WLM Restriction

Like the WLM advisor, the Metric Server reports on server systems as a whole, rather than on individual protocol-specific server daemons. Both WLM and Metric Server place their results into the system column of the manager report. As a consequence, running both the WLM advisor and Metric Server at the same time is not supported.

Prerequisites

The Metric Server agent must be installed and running on all servers that are being load balanced.

How to Use Metric Server

Below are the steps to configure Metric Server for Dispatcher. Similar steps can be used for configuring Metric Server for the other components of Load Balancer.

To have Metric Server run on an address other than the local host, you need to edit the metricserver file on the load balanced server machine. After the occurence of "java" in the metricserver file, insert the following:

-Djava.rmi.server.hostname=OTHER_ADDRESS

In addition, before the "if" statements in the metricserver file, add the following line: hostname OTHER_ADDRESS.

For Windows platform: You will also need to alias the OTHER_ADDRESS on the Microsoft stack of the Metric Server machine. For example:

call netsh interface ip add address "Local Area Connection" 
   addr=9.37.51.28 mask=255.255.240.0

When gathering metrics across different domains, you must explicitly set the java.rmi.server.hostname in the server script (dsserver, cbrserver, etc) to the fully qualified domain name (FQDN) of the machine that is requesting the metrics. This is necessary because, depending on your setup and operating system, InetAddress.getLocalHost.getHostName() might not return the FQDN.

Workload Manager advisor

WLM is code that runs on MVS mainframes. It can be queried to ask about the load on the MVS machine.

When MVS Workload Management has been configured on your OS/390 system, Dispatcher can accept capacity information from WLM and use it in the load balancing process. Using the WLM advisor, Dispatcher will periodically open connections through the WLM port on each server in the Dispatcher host table and accept the capacity integers returned. Because these integers represent the amount of capacity that is still available and Dispatcher expects values representing the loads on each machine, the capacity integers are inverted by the advisor and normalized into load values (that is, a large capacity integer but a small load value both represent a healthier server). The resulting loads are placed into the System column of the manager report.

There are several important differences between the WLM advisor and other Dispatcher advisors:

  1. Other advisors open connections to the servers using the same port on which flows normal client traffic. The WLM advisor opens connections to the servers using a port different from normal traffic. The WLM agent on each server machine must be configured to listen on the same port on which the Dispatcher WLM Advisor is started. The default WLM port is 10007.
  2. Other advisors only assess those servers defined in the Dispatcher cluster:port:server configuration for which the server's port matches the advisor's port. The WLM advisor advises upon every server in the Dispatcher configuration (regardless of the cluster:port). Therefore you must not define any non-WLM servers when using the WLM advisor.
  3. Other advisors place their load information into the manager report under its "Port" column. The WLM advisor places its load information into the manager report under its system column.
  4. It is possible to use both protocol-specific advisors along with the WLM advisor. The protocol-specific advisors will poll the servers on their normal traffic ports, and the WLM advisor will poll the system load using the WLM port.

Metric Server Restriction

Like the Metric Server agent, the WLM agent reports on server systems as a whole, rather than on individual protocol-specific server daemons. Metric Server and WLM place their results into the system column of the manager report. As a consequence, running both the WLM advisor and Metric Server at the same time is not supported.