Customize the optional statements in the Advisor's configuration file.
The update_interval statement controls how often each Agent updates the Advisor with data, and depending upon load balancer implementation and configuration, can control how often load balancers are updated with information from the Advisor. The default value is 60 seconds. At each update interval, each Agent refreshes the Advisor with the status of each registered member for which the Agent is responsible. This information includes the status of the target application (active or not), whether it is an application member, the operator quiesce state of the member, and various weights that measure the target system and application's ability to handle additional workload requests. The lower the update interval, the more up-to-date the load balancer's data will be with respect to the target's availability and capability to handle additional workload requests. Of course, the lower the update interval, the higher the network traffic and CPU overhead is.
Depending upon load balancer implementation and configuration, the update_interval statement might also determine how often the load balancer is updated with data from the Advisor. If the load balancer supports the SASP push flag, and it has been specified in the load balancer, the Advisor sends data to the load balancer at least every update interval. Regardless of what the update interval is set to, if this push flag is supported and configured in the load balancer, certain events might cause the Advisor to update the load balancer with information before the update interval timer expires. These events include the starting or stopping of a target application, or the addition or deletion of a member's IP address on the Agent host.
Therefore, the update interval is a key factor in determining the latency period between when changes occur on the target application system, and when the load balancer is informed of them. Each Agent updates the Advisor with new information every update interval. The Advisor, in turn, updates the load balancer with changes in weights every update interval, if the load balancer supports the push flag. In addition, if the push flag is supported and configured by the load balancer, the Advisor updates the load balancer with any change in the target's availability status as soon as it discovers such a change from the Agent, instead of waiting for the update interval to expire. Therefore, when the load balancer supports and configures the push flag, the maximum amount of latency expected between a change in a member's weight and when the load balancer is informed of it is twice the update interval (that is, one update interval for the Agent to report it to the Advisor and one update interval for the Advisor to report it to the load balancer). However, on the average, it should take one update interval for a change in the target application weight to reach the load balancer.
Use the optional wlm statement to specify the default type of WLM recommendation to be used for all groups. There are two choices for this, the basewlm and serverwlm values. If you do not specify this statement, the default is basewlm. If you want a specific group of applications to use a type of WLM recommendation other than the default, you can override the default WLM recommendation type for that group on a port number basis using the port_list statement. The WLM recommendation is a key component used in determining the net weight assigned to a member.
The type of WLM recommendation represented by the basewlm value indicates the overall displaceable capacity (general, zAAP, and zIIP) of the system where the application represented by the member is, relative to the other systems in the sysplex. This is referred to as a WLM system weight recommendation. Use the optional proctype parameter with basewlm to specify the proportion of general, zAAP, and zIIP CPU that is consumed by an application's workload.
The serverwlm value represents a different type of WLM recommendation, in that it reflects how well an individual server application is performing from a WLM perspective (based on the WLM policy). This type of recommendation is a server-specific recommendation and is referred to as a server-specific WLM recommendation. Server-specific WLM recommendations are composed of two key elements:
In addition, WLM provides an interface that enables applications to report the following additional information:
Using this additional information, WLM might reduce the server-specific recommendation. For more information, see Sysplex distributor.
Evaluate whether you can use WLM server-specific distribution as an alternative to WLM system weight distribution for an application. In addition to the above reasons, server-specific distribution has the added advantage that processor proportions are automatically determined and dynamically updated by WLM, based on the actual CPU usage by the application. If you need to use system weight distribution, to determine the processor proportions to configure, study the workload usage of assist processors by analyzing SMF records, using performance monitors reports such as RMF™, and so on.
System members (port and protocol are zero) always use WLM system weight recommendations and cannot be configured to consider zAAP and zIIP CPU, because the type of workload is unknown. This is true even if proctype is coded on the wlm statement.
Application members can use either type.
It is important that you choose the type of WLM recommendation that is best suited to each group of applications. Some types of applications are better suited to using WLM system weight recommendations rather than server-specific WLM recommendations. For most applications, server-specific WLM recommendations provide a more accurate way to distribute workload to their servers. However, when a server acts as an access point to applications that run in other address spaces (and therefore in a different service class), WLM system weight recommendations might be the preferred distribution method; if expected usage of general, zAAP, and zIIP processors is known, this recommendation can be further refined by using the proctype parameter. The sysplex distributor function can also use server-specific WLM recommendations or WLM system weight recommendations. For examples of some applications that might be better represented by WLM system weight recommendations, see Sysplex distributor.
The optional port_list statement enables you to override or specify parameters for members on a port number basis. The wlm parameter of the port_list statement enables you to override the value defined (or specified by default) on the wlm statement, for all members that use the port number specified. The actual WLM recommendation type used is still dependent upon the value specified and the z/OS® level of the Agents owning the members of the group.
When selecting the type of WLM recommendation to use for a given group, it is important to consider the following requirements:
For any groups where these requirements are not met, the Advisor uses WLM system weight recommendations, and a warning message is written to syslogd. The main rationale behind this is that WLM system weight recommendations and server-specific WLM recommendations cannot be directly compared to one another.
The Advisor can detect dynamically whether these requirements are being met. For example, if all owning Agents of a group, except one, support server-specific WLM recommendations, and the application on that one system is brought down, the WLM recommendation type would change dynamically from WLM system weight recommendations to server-specific WLM recommendations, provided the Advisor was configured to request server-specific WLM recommendations for that group. Similarly, if that same application is started back up, the WLM recommendation type would dynamically switch back to WLM system weight recommendations. A similar circumstance would arise if the member owned by the Agent that does not support server-specific WLM recommendations was quiesced by the z/OS operator or the load balancer administrator.
The optional debug_level statement determines how much trace data is captured in the Advisor's log file.
For more details on the Advisor configuration file statements, see z/OS Communications Server: IP Configuration Reference.