Intelligent Management: dynamic cluster custom properties
Use dynamic cluster custom properties to change the behavior of our dynamic clusters and application placement.
To set the application placement custom properties, expand Servers > Clusters > Dynamic Clusters > [cluster name] > Custom Properties.
APC.predictor custom property
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
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 we configure multi-cell performance management in the environment, we can use the CenterCell custom property to designate one cell as the center cell. We also set the CenterCell custom property individually for each cell to designate as a point cell.
One and only one custom property should be set to true.
| 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
Configure multiple server instances to start when the ODR detects activity for an inactive dynamic cluster.
Prior to v6.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 our 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 |
We can also set this property via the console...
equalCPUFactor custom property
Tell 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:
- Average service time for a request sent to the server.
- The processor utilization of the node.
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 our site perceive the site performance, we might choose to optimize average service time. If we are more concerned with the usage of our hardware, we 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, we 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
Disable HTTP session rebalancing.
HTTP session rebalancing is automatically enabled. Use HTTP session rebalancing to reassign existing session affinities to new servers that become available for processing the given Web application.
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 your session sizes are large. If our 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. Use Performance Monitoring Infrastructure (PMI) data to make the decision to turn off session rebalancing. We might see in your PMI data that response time, memory utilization, and processor utilization increases on specific servers to transfer the session information.
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 WAS 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 WAS application servers, such as PHP or Tomcat servers: true (disabled) |
numVerticalInstances custom property
Define the number of dynamic cluster instances on a node.
Use this custom property only if the nodes in our dynamic cluster are heterogeneous and vary in power. If the nodes in our dynamic cluster are homogenous, we can define the number of dynamic cluster instances one time in the administrative console.
| Value | Description |
|---|---|
| Scope | Dynamic cluster |
| Name format | Specify the name of the custom property as numVerticalInstances.node, where node is the name of our node. |
| Valid values | Integer value for the stacking number |
proactiveIdleStop custom property
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. We 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 specified in the administrative console setting.
The application placement controller stops the instance at some point in time between the amount of time 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 we 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. 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 we 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). Default 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: