Dynamic clusters
The process of deploying an application in WebSphere XD begins with choosing or defining a node group that satisfies the application's requirements, and continues with the creation of a dynamic cluster. A dynamic cluster is a container construct that extends its static counterpart in WebSphere Network Deployment, the static cluster.
Dynamic clusters are associated with a single node group. Cluster applications (.ear files) are then deployed into a dynamic cluster in much the same fashion as they are deployed into WebSphere Network Deployment static clusters. However, WebSphere XD supports autonomic expansion and contraction of a dynamic cluster within its parent node group. Thus, periodic spikes in demand for an application result in a corresponding increase in that application's resource for processing requests. The strategy for increasing these resources is dictated by operational policies that reflect business goals.
Lazy application start
The lazy application start feature in WebSphere XD optimizes server resource allocation during times of inactivity. When a request for that application is received by the On Demand Router (ODR), the application is started automatically on any node in the node group.
A typical environment where the lazy application start feature is beneficial is an environment in which the ratio of the number of dynamic clusters to the number of servers is high, and where many dynamic clusters are not accessed for long periods of time. In such an environment, it is beneficial to hibernate idle dynamic clusters temporarily (stopping all server instances), thereby releasing valuable resources to be used by active dynamic clusters.
Note: Lazy application start can only be configured for the whole dynamic cluster.
Vertical stacking
WebSphere XD introduces a new feature called vertical stacking. This feature allows you to have more than one appserver instance in a dynamic cluster on the same node. The benefit of this capability is better hardware utilization if the CPU and memory of an LPAR is not fully used with a single appserver on a node.
To determine how many appserver instances can run in parallel on a node, take a look at the resources needed when only one instance is active. IBM recommends that you determine the stacking number for a dynamic cluster with no other appservers running on that node.
First, start one instance. While monitoring the effective throughput, increase the workload intensity. When throughput saturates, start one more instance. When adding a new instance does not improve the throughput, the stacking number is 1. If adding a new instance improves the throughput, you can conclude that the application has some internal bottleneck that prevents it from effectively using the entire box within a single appserver. Thus, you can continue to increase workload and (possibly) the number of active instances until no improvement in throughout can be achieved.
Repeat this approach individually for every application that can possibly run on that node. This way, you can decide for each cluster (and thus, application) whether it should be using stacking or not.
When determining the stacking number for a dynamic cluster, you do not have to consider any other dynamic clusters, because you only want to learn how many instances of this dynamic cluster are needed to fully utilize the system. So when you have multiple clusters or applications, each of them would be able to fully utilize the system if no other application is running concurrently (for example, because these applications only run at certain times of the day, week, or month).
The stacking number will become the maximum number of instances that are allowed to execute on a node for this dynamic cluster. However, at any time, a smaller number may be started, depending on the current workload. At run time, the application placement controller, ODR, and DWLM will work together to make sure that the node is not overloaded and that all applications meet their policies.
Alternatively, if vertical stacking is not necessary, then it is possible to remove resources from the LPAR.