+

Search Tips   |   Advanced Search

Intelligent Management: dynamic cluster custom properties

We can use dynamic cluster custom properties to change the behavior of the dynamic clusters and application placement.


APC.predictor custom property

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.

Value Description
Scope Cell
Valid value CPU


quiesceTimeOutMS custom property

We 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 we 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.

Value Description
Scope Dynamic cluster
Valid values Integer


CenterCell custom property

When you configure multi-cell performance management in our environment, we 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 to designate as a point cell.

Avoid trouble: One and only one custom property should be set to true.gotcha

Value Description
Scope Cell
Valid values true: Designates one cell as the center cell

false: Designates one cell as a point cell


lazyStartMinInstances custom property

We 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, we can set the custom property on the application placement controller so that all of the 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.

Value Description
Scope Dynamic cluster
Valid values An integer value that specifies the minimum number of instances to be lazily started
Default 1


equalCPUFactor custom property

We 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.

The DWLM calculates dynamic weights for the servers in a given dynamic cluster to equalize the performance of the servers. The two common measures of server performance are:

With the custom property, we can specify the relevance of one of these measures over the other. For example, if we want consistency in how the users of the site perceive the site performance, you might choose to optimize average service time. If we are more concerned with the usage of the hardware, you might choose processor utilization as the measure of performance.

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.

Value Description
Scope Cell, which applies to all dynamic clusters in the cell, or at the individual dynamic cluster level. If the custom property is specified at both the dynamic cluster and cell level, dynamic cluster level value overrides the value specified at the cell level.
Valid values A fraction value between 0 and 1
Default 0 for non-virtualized environments and 1 for virtualized environments


HttpSessionRebalanceOff custom property

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

  • HTTP session rebalancing is automatically enabled. We 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 to return the 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 we might have another session clustering mechanism deployed for those servers.

    We might consider disabling HTTP session rebalancing if the session sizes are large. If the 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. We can use Performance Monitoring Infrastructure (PMI) data to make the decision to turn off session rebalancing. We might see in the 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 we 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.

    Value Description
    Scope Dynamic cluster
    Valid values true: Disables HTTP session rebalancing.

    false: Enables HTTP session rebalancing. To disable HTTP session rebalancing for WebSphere Application Server application servers, we can delete the custom property.

    Default

    For dynamic clusters that consist of WAS application servers: false (enabled)

    For dynamic clusters that consist of servers that are not WebSphere Application Server application servers, such as PHP or Tomcat servers: true (disabled)


    numVerticalInstances custom property

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

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

    Value Description
    Scope Dynamic cluster
    Name format Specify the name of the custom property as numVerticalInstances.node, where node is the name of the node.
    Valid values Integer value for the stacking number


    proactiveIdleStop custom property

    We 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 console. This setting must be enabled with this custom property. With the 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 specified in the console setting.

    The application placement controller stops the instance at some point in time between the amount of time that specified in the console setting plus the value specified for Minimum time between placement changes setting on the Application Placement Controller configuration panel. For example, if 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.

    Value Description
    Scope Dynamic cluster, except for dynamic clusters of on demand routers (ODRs)
    Valid values Boolean
    Default false (disabled)


    routableTimeoutMS custom property

    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.

    Use this custom property only if you are experiencing HTTP error code 503 during dynamic cluster member transition states.

    Value Description
    Scope Dynamic clusters of on demand routers (ODRs)
    Valid values Max wait time for ODR routability
    Default 60000 milliseconds


    (zos) serverSpecificShortNames custom property

    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 we 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.

    Value Description
    Scope Dynamic cluster
    Valid values Comma-separated list of short names for dynamic cluster members, for example SSN1,SSN2


    updateWLM custom property

    When false, the DWLM controller will not update the calculated weights for the cluster members in the Work Load Management (WLM). The default value of this property is true. Cell recycle is required for this custom property to take effect. IBM recommends that updateWLM is set to false when HAManager is turned off through out the cell or on all the dynamic cluster members.

    This custom property can be set at dynamic cluster level and cell level:

    • If set at cell level, it applies to all dynamic clusters in the cell.

    • If set at DC level, it applies to that DC only.

    Value Description
    Scope Dynamic cluster or cell
    Valid values true or false
    Default true


    Related concepts

  • Dynamic clusters
  • HTTP session rebalancing
  • Performance Monitoring Infrastructure (PMI)


    Related tasks

  • Configure multi-cell performance management: Star Topology
  • Configure elasticity mode
  • Create dynamic clusters
  • Monitor and tune the application placement controller
  • Monitor and tune health management
  • Configure a dynamic cluster with heterogeneous nodes to support vertical stacking

  • Intelligent Management: dynamic cluster administrative tasks


    Related information:

  • Intelligent Management: application placement custom properties