Elasticity mode
Overview
Elasticity mode enables a WebSphere cell to grow or shrink dynamically by adding or removing nodes. An elasticity operation defines the runtime behaviors to monitor, and the corrective actions to take when the behaviors are present. The add operation is issued when all of the resources of the controller are being used, but more resources are still needed to meet the current demand. The remove operation is issued when the controller has an excessive amount of resources.
Use elasticity mode to add logic that causes the application placement controller to...
- Minimize the number of nodes used
- Remove nodes that are not needed
- Add nodes if service policies are not being met
If the elasticity mode is disabled, dynamic clusters start and stop cluster members in the following situations:
- Servers are started to:
- Maintain minimum active instances.
- Meet the CPU or memory demand for a cluster.
- Servers are stopped to:
- Ensure that the maximum number of instances is not exceeded.
- Meet the CPU or memory demand for a cluster.
- Stop cluster members if lazy start or proactive idle stop (custom property) is enabled.
- Balance resources and make them available to another cluster.
With elasticity enabled, additional options are:
| Increase in demand | Expand dynamic cluster using custom operations (for example, wasdmin scripts). |
| Decrease in demand | Contract dynamic cluster using customer operations (for example, wasdmin scripts). |
For IBM Workload Deployer or WAS Hypervisor Edition Intelligent Management Pack, predefined tasks add virtual machines and federate nodes to increase/decrease the capacity of a dynamic cluster.
Add operation
When elasticity mode is enabled, if all members of a dynamic cluster cannot meet the current demand, the application placement controller issues an add operation. When the action associated with the add operation is complete, the controller starts a server on the new node.
Remove operation
When elasticity mode is enabled and a node is no longer required to meet the current demand, the application placement controller issues a remove operation. Nodes that are not part of any dynamic clusters and with no running application servers removed first. Next, an attempt is made to remove a node that does contain a dynamic cluster instance as long as the instance is not running and no other application servers are running. Finally, an attempt is made to remove nodes that only have one or more started dynamic clusters. The remove operation occurs only if that node is not required to meet the minimum number of instances for a dynamic cluster, or is not required to meet the current demand.
When the application placement controller is running without elasticity mode enabled, servers are started due to an increased demand for CPU or memory, but the servers are not stopped after they are started. When elasticity mode is enabled and the servers are not needed, however, the stop operation is issued and the servers are stopped even after they are started. After all of the servers on the physical machine or virtual machine are stopped, the application placement controller issues the remove node operation.
Considerations when using elasticity mode
- Do not enable elasticity mode on any node that runs eXtreme Scale catalog or container servers. See IBM Support: WebSphere eXtreme Scale with Intelligent Management
- The application placement controller will not issue a remove operation on any node containing both static and dynamic cluster members.
- Do not enable application lazy start with elasticity mode. The application placement controller issues the remove operation for all of the nodes on that dynamic cluster. In certain environments, this might cause problems, because all of the custom nodes can then be lost.
- Configure the application placement controller to always start on the deployment manager or node that will not be removed. Doing so prevents the controller from issuing a remove operation for the node that the controller is active on. If we do not configure the controller to start on the deployment manager, an attempt to remove the node in which the controller is running might occur. As a result, data can be lost, any actions defined by the remove operation do not occur, and the runtime tasks in the administrative console are not properly updated.
To find where the application placement controller is running, we can use the administrative console or scripting. To check the location in the administrative console, click...
-
Runtime Operations > Component stability > Core components
See: Intelligent Management: application placement frequently asked questions
- When we use elasticity mode in an environment in which multi-cell performance management is configured, configure certain controllers to start on the deployment managers of the center cell and the point cells. Configure the application placement controller to start on the deployment manager of the center cell. Configure the cell agent to start on the deployment managers of the point cells.
- To ensure that the application placement controller does not wait too long to issue an add operation, change the minTimeBetweenPlacementChange custom property from 15 minutes to 3 minutes. If the default value of 15 minutes is used, the controller might issue two add operations over a period of 30 minutes.
Considerations when using elasticity to manage JMS traffic that originates from IBM MQ
- By default, the application placement controller (APC) uses information produced by the ODR to determine when to start or stop application servers in a dynamic cluster. Set the APC.predictor custom property to CPU to remove the APC dependency on ODR input. This enables Intelligent Management to support dynamic clusters of message-driven beans when loaded by IBM MQ.
- When we use elasticity mode to manage JMS traffic that originates from IBM MQ (Version 7.0.1.6 or later is required), go to System administration > Cell > Custom properties > New, and set the cell custom property JMS.CPU to true. Restart the cell.