Elasticity mode

Use elasticity mode to add logic that causes the application placement controller to minimize the number of nodes that are used, as well as remove nodes that are not needed, while still meeting service policy goals. Additionally, you can use elasticity mode to add logic so that, when the controller recognizes that a particular dynamic cluster is not meeting service policies and has started all possible servers, the controller adds a node.

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. As part of the steps for configuring elasticity mode, you create custom actions to define the actions that are associated with the elasticity operations: the add operation and the remove operation. The add operation is issued when all of the resources of the application placement controller are being used, but more resources are still needed to meet the current demand. The remove operation is issued when the application placement controller has an excessive amount of resources.

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: Define custom operations (for example, wasdmin scripts) to expand a dynamic cluster.
Note: For IBM® Workload Deployer or WebSphere Application Server Hypervisor Edition Intelligent Management Pack, predefined tasks add virtual machines and federating nodes to increase the capacity of a dynamic cluster.
Decrease in demand: Define custom operations (for example, wasdmin scripts) to contract a dynamic cluster.
Note: For IBM Workload Deployer or WebSphere Application Server Hypervisor Edition Intelligent Management Pack, predefined tasks remove virtual machines and federating nodes to decrease the capacity of a dynamic cluster.

Add operation

When elasticity mode is enabled, the application placement controller issues an add operation when all of the members of a dynamic cluster cannot meet the current demand. The controller attempts to consolidate and start all of the servers on the minimum number of nodes as possible.

When the action associated with the add operation is complete, the controller starts a server on the new node. The new node must be added as a member of the dynamic cluster that requested the addition. If a new node is not added, the controller continues to issue the add operation until all required resources are received or the demand decreases.

Remove operation

The remove operation first stops any started dynamic cluster instances before starting the associated actions. It is important to know that if the dynamic cluster is set to manual mode, the remove operation is issued on any nodes that do not have any started application servers. 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. Any nodes that are not part of any dynamic clusters with no running application servers are first removed. 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, the controller issues start and stop operations for application servers. 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 operation.

Considerations when using elasticity mode

Consider the following information when using elasticity mode.

The application placement controller will not issue a remove operation on any node that contains 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.
You must 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 you 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.
When you use elasticity mode in an environment in which multi-cell performance management is configured, you must 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.
Change the minTimeBetweenPlacementChange custom property from 15 minutes to 3 minutes to ensure that the application placement controller does not wait too long to issue an add operation. 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 WebSphere 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 WebSphere MQ.
When you use elasticity mode to manage JMS traffic that originates from WebSphere 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.