Intelligent Management: dynamic cluster custom properties

Use the APC.predictor custom property to enable the application placement controller function.

By setting the custom property, the application placement controller starts and stops servers based on CPU usage alone. The controller no longer retrieves data from the autonomic request flow manager (ARFM) regarding what servers to start and stop.

You can use the quiesceTimeOutMS custom property to set the quiesce timeout value for dynamic cluster instances.

Set the value of the custom property to the amount of time, in milliseconds, to wait before a dynamic cluster is stopped. For example, if you want a dynamic cluster to stop after 1 minute of quiescing, set the value to 60000. If servers are being stopped by the application placement controller, the server operation timeout value is used by default. If servers are being stopped by health management monitoring, the restart timeout value is used by default.

When you configure multi-cell performance management in your environment, you can use the CenterCell custom property to designate one cell as the center cell. You also set the CenterCell custom property individually for each cell that you want to designate as a point cell.

You can use the lazyStartMinInstances custom property to configure multiple server instances to start when the ODR detects activity for an inactive dynamic cluster.

Prior to Version 6.1.1.2, only one server instance was started when a dynamic cluster was configured for application lazy start and the ODR received requests for the inactive dynamic cluster. By setting the lazyStartMinInstances custom property on a specific dynamic cluster, however, multiple instances can be started by that particular dynamic cluster. If other dynamic clusters configured for application lazy start exist, those clusters start only one instance each.

Alternatively, you can set the custom property on the application placement controller so that all of your dynamic clusters are affected. However, the custom property value set at the dynamic cluster level overrides the custom property value set at the application placement level.

You can use the equalCPUFactor custom property to tell to the dynamic workload manager (DWLM) how to equalize the performance of the servers in a dynamic cluster.

To place most priority on equalizing average service time, set the value of the custom property to 0. To equalize processor utilization of the node, set the value to 1. To use a blend of both measures with a relative weight to each measure, set the value to a fraction value between 0 and 1, for example 0.4. By setting the value to a fraction, you are placing a relative weight of 0.4 to the processor utilization and 1–0.4, or 0.6 relative weight to the average service time.

Equalizing both measures at the same time might not be possible at all times. For example, in an environment where servers are heterogeneous or have varying amount of unequal background load, equalizing the processor utilization might result in unequal average service time. A fast and a slow server running at the same processor utilization can result in short and long average request service time, respectively. A request that spends a significant amount of time in one of several servers in a deeper tier might result in a different average service time. This variance can occur depending on the server to which the request was sent, even if the servers in the deeper tier are homogeneous and have equal processor utilization. Other situations exist where the service time of a request depends on resources other than the processor. The value of the equalCPUFactor custom property helps the DWLM controller determine a weighted measure of both average service time and processor utilization to be equalized.

Even without the equalCPUFactor custom property, the processor utilization of the servers in a given dynamic cluster has an effect on the behavior of the DWLM controller. In general, when processor utilization is low, equal distribution of load takes precedence over equalizing the performance of service time or utilization. Gradually, as the utilization goes up, equalizing performance begins to take precedence. At very high processor utilization values, the weights tend to not change as much to avoid instability. When processor utilization is high, the sensitivity of performance on load distribution at that extreme operating point increases.

You can use the HttpSessionRebalanceOff custom property to disable HTTP session rebalancing.

HTTP session rebalancing is automatically enabled. You can use HTTP session rebalancing to reassign existing session affinities to new servers that become available for processing the given Web application. For more information, read about HTTP session rebalancing

Use the HttpSessionRebalanceOff custom property if you want to return your configuration to the old HTTP session behavior, where session affinities are established with a particular application server and are not reassigned to any new servers that become available.

Session rebalancing is disabled by default on any dynamic clusters that consist of servers that are not running WebSphere® Application Server, such as PHP or Tomcat servers, because you might have another session clustering mechanism deployed for those servers.

You might consider disabling HTTP session rebalancing if your session sizes are large. If your sessions are large, the cost of moving the sessions to a new server might be more than the benefit of taking the workload off of the original server. You can use Performance Monitoring Infrastructure (PMI) data to make the decision to turn off session rebalancing. You might see in your PMI data that response time, memory utilization, and processor utilization increases on specific servers to transfer the session information. For more information about analyzing PMI data and best practices for using HTTP sessions, read about Performance Monitoring Infrastructure (PMI).

If you leave session rebalancing on, as sessions become more evenly distributed, and memory and processor utilization also become more evenly distributed across the servers in the cluster. If a cluster is more balanced, it is easier for Intelligent Management to make autonomic decisions.

Use this custom property to define the number of dynamic cluster instances on a node.

Use this custom property only if the nodes in your dynamic cluster are heterogeneous and vary in power. If the nodes in your dynamic cluster are homogenous, you can define the number of dynamic cluster instances one time in the administrative console. For more information about dynamic cluster instances, read about configuring a dynamic cluster with heterogeneous nodes to support vertical stacking.

You can use the proactiveIdleStop custom property to stop dynamic cluster instances during periods of inactivity.

This custom property adds function to the If other dynamic clusters need resources, stop all instances of this cluster during periods of inactivity setting in the administrative console. This setting must be enabled with this custom property. With the administrative console setting, instances stop only if other clusters in the cell need the resources that are being used by the inactive instances. You also specify an amount of time to wait before stopping instances for the cluster. By setting this custom property, inactive instances stop even if the resources are not required elsewhere in the environment. The cluster instance goes idle in the amount of time that you specified in the administrative console setting.

The application placement controller stops the instance at some point in time between the amount of time that you specified in the administrative console setting plus the value specified for Minimum time between placement changes setting on the Application Placement Controller configuration panel. For example, if you set the proactiveIdleStop custom property to true, the value of Minimum time between placement changes is 15 minutes, and the Time to wait before stopping instances value is 5 minutes, the dynamic cluster instance is stopped sometime between 5 minutes and 20 minutes after the last request was routed to the instance.

While a dynamic cluster member is being started, there is a period of time during which the member is not yet ready to process requests from the on demand router (ODR). Use the routableTimeoutMS custom property to define the ODR waiting time, in milliseconds, before routing traffic to a newly-started dynamic cluster member.

For example, when using the node or server maintenance mode, the application placement controller (APC) allocates resources to replace the ones that go into maintenance mode. Another example is when the APC relocates a dynamic cluster member from one node to another due to memory, CPU, or other constraints. In each of these cases, additional time beyond the default 60000 milliseconds might be required for the applications to become active on the newly started resources.

For z/OS® platforms, the serverSpecificShortNames custom property is specified on the dynamic cluster to indicate the specific short names of cluster members in a comma-separated list format, for example: SSN1,SSN2. Use commas to separate multiple short names. If you do not provide enough short names to be used for all of the cluster members, then the remaining cluster members are assigned generated generic short names, such as BBOS001, BBOS002, and so on.