Weblogic 12C Feature - Elasticity for Dynamic Clusters

The elasticity capabilities leverage the WebLogic 12c Dynamic Clusters for on-Demand scaling (or manual scaling) and the WLDF Policies and Actions (the same as Watches and Notifications from previous versions) to implement auto scaling. When a certain Policy is met a Scale up or Scale down Action can be triggered.

Cluster in weblogic 12c provide simplicity and elasticity.

Few Terms used in clustering:

dynamic server: A server instance that is generated by WebLogic Server when creating a dynamic cluster. Configuration is based on a shared server template.

configured server : A server instance for which you manually configure attributes and not by template.

configured cluster: A cluster in which you manually configure and add each server instance.

dynamic cluster: A cluster that contains one or more generated (dynamic) server instances that are based on a single shared server template.

mixed cluster: A cluster that contains both dynamic and configured server instances.

server template: A prototype server definition that contains common, non-default settings and attributes that can be assigned to a set of server instances, which then inherit the template configuration. For dynamic clusters, the server template is used to generate the dynamic servers

What Are Dynamic Clusters?

Dynamic clusters consist of server instances that can be dynamically scaled up to meet the resource needs of your application. A dynamic cluster uses a single server template to define configuration for a specified number of generated (dynamic) server instances. When you create a dynamic cluster, the dynamic servers are preconfigured and automatically generated for you, enabling you to easily scale up the number of server instances in your dynamic cluster when you need additional server capacity. You can simply start the dynamic servers without having to first manually configure and add them to the cluster.

Why Do You Use Dynamic Clusters?

With dynamic clusters, you can easily scale up your cluster when you need additional server capacity by simply starting one or more of the preconfigured dynamic server instances. You do not need to manually configure a new server instance and add it to the cluster or perform a system restart.

The WebLogic Server Elasticity Framework

The diagram below shows the different parts to the elasticity framework for WebLogic Server:

The Elastic Services Framework are a set of services residing within the Administration Server for a for WebLogic domain, and consists of

A new set of elastic propertieson the DynamicServersMBean for dynamic clusters to establish the elastic boundaries and characteristics of the cluster
New capabilitiesin the WebLogic Diagnostics Framework (WLDF) to allow for the creation of automated elastic policies
A new “interceptors” framework to allow administrators to interact with scaling events for provisioning and database capacity checks
A set of internal services that perform the scaling
(Optional) integration with Oracle Traffic Director (OTD) 12c to notify it of changes in cluster membership and allow it to adapt the workload accordingly

Note that while tighter integration with OTD is possible in 12.2.1, if the OTD server pool is enabled for dynamic discovery, OTD will adapt as necessary to the set of available servers in the cluster.

Starting and Stopping Servers in Dynamic Clusters:

To easily manage server startup and shutdown in dynamic clusters, use the WLST scaleUp and scaleDown commands.

scaleUp: The scaleUp command increases the number of running servers for the specified dynamic cluster. The non-running server instance with the lowest server ID starts first, followed by the next highest non-running server ID, until the specified number of server instances is started. You can start one, all, or any number of server instances in the dynamic cluster by specifying the desired number with the numServers argument in the scaleUp command. If all available server instances are already running, the scaleUp command increases the size of the cluster to the minimum number of requested server instances before starting the specified number of servers.

scaleDown: The scaleDown command gracefully shuts down the specified number of running servers. The server instance with the highest server ID shuts down first, followed by the next highest ID, until the specified number of server instances is shut down.

Note: You can also start and stop server instances in dynamic clusters using the same methods you use to start and stop server instances in configured clusters: the WebLogic Server Administration Console, Fusion Middleware Control, WLST start and shutdown commands, Node Manager, and start scripts.

Expanding or Reducing Dynamic Clusters:

To Expand: you can increase the maximum number of dynamic servers in the dynamic cluster configuration. To increase the number of dynamic servers in the dynamic cluster, use the scaleUp command and enable the updateConfiguration argument. WLST will increase the maximum size of the cluster by the specified number of servers and start the server instances.

To Reduce: To reduce the number of server instances in the dynamic cluster, decrease the value of the maximum number of dynamic servers attribute. Before lowering this value, shut down the server instances you plan to remove. To decrease the maximum size of the dynamic cluster, use the scaleDown command and enable the updateConfiguration argument. WLST will gracefully shut down the specified number of running server instances and remove them from the dynamic cluster.

Deploying Applications to Dynamic Clusters:

When deploying applications to a dynamic cluster, you must target the application to the entire cluster. You cannot target an application to an individual server instance because dynamic clusters do not have individual dynamic server configuration. When you deploy an application to the dynamic cluster, all servers in the cluster, both dynamic and static, will deploy the application.

Configuring Elasticity for Dynamic Clusters:

The new properties to be configured include

The starting dynamic cluster size
The minimum and maximum elastic sizes of the cluster
The “cool-off” period required between scaling events

The starting dynamic cluster size: There are several other properties regarding how to manage the shutdown of Managed Servers in the cluster, but the above settings control the boundaries of the cluster (by how many instances it can scale up or down), and how frequently scaling events can occur.

The minimum and maximum elastic sizes of the cluster: The Elastic Services Framework will allow the dynamic cluster to scale up to the specified maximum number of instances, or down to the minimum you allow.

The “cool-off” period required between scaling events: The cool-off period is a safety mechanism designed to prevent scaling events from occurring too frequently. It should allow enough time for a scaling event to complete and for its effects to be felt on the dynamic cluster’s performance characteristics.

Scaling Dynamic Clusters:

Scaling of a dynamic cluster can be achieved through the following means:

On-demand through WebLogic Server Administration Console and WLST
Using an automated calendar-based schedule utilizing WLDF policies and actions
Through automated WLDF policies based on performance metrics

On-Demand Scaling:

WebLogic administrators have the ability to scale a dynamic cluster up or down on demand when needed:

Through the WLST scaleUp()and scaleDown() commands
Using the WebLogic Administration Console, on the dynamic cluster’s “Control/Scaling” tab(see image below)

In the console case, the administrator simply indicates the total number of desired running servers in the cluster, and the Console will interact with the Elastic Services Framework to scale the cluster up or down accordingly, within the boundaries of the dynamic cluster.

2. Automated Scaling:

In addition to scaling a dynamic cluster on demand, WebLogic administrators can configure automated polices using the Polices & Actions feature (known in previous releases as the Watch & Notifications Framework) in WLDF.Typically, automated scaling will consist of creating pairs of WLDF policies, one for scaling up a cluster, and one for scaling it down.

Each scaling policy consists of

(Optionally) A policy (previously known as a “Watch Rule”) expression
A schedule
A scaling action

To create an automated scaling policy, an administrator must

Configure a domain-level diagnostic system module and target it to the Administration Server
Configure a scale-up or scale-down action for a dynamic cluster within that WLDF module
Configure a policy and assign the scaling action

Calendar Based Elastic Policies in automated scaling:

Policies that monitor MBeans according to a specific schedule are called “scheduled” policies.

A calendar based policy is a policy that unconditionally executes according to its schedule and executes any associated actions. When combined with a scaling action, you can create a policy that can scale up or scale down a dynamic cluster at specific scheduled times.

Each scheduled policy type has its own schedule (as opposed to earlier releases, which were tied to a single evaluation frequency) which is configured in calendar time, and allowing the ability to create the schedule patterns such as (but not limited to):

Recurring interval based patterns(e.g., every 5th minute of the hour, or every 30th second of every minute)
Days-of-week or days-of-month(e.g., “every Mon/Wed/Fri at 8 AM”, or “every 15th and 30th of every month”)
Specific days and times within a year(e.g., “December 26th at 8AM EST”)
1. Through automated WLDF policies based on performance metrics: [Performance-based Elastic Policies]

WLDF provides the ability to create scaling policies based on performance conditions within a server (“server-scoped“) or cluster (“cluster-scoped”). WLDF also provides a set of pre-packaged, parameterized, out-of-the-box functions called “Smart Rules” to assist in creating performance-based policies.

Cluster-scoped Smart Rules allow you to look at trends in a performance metric across a cluster over a specified window of time and scale up or down based on criteria that you specify. Some examples of the metrics that are exposed through Smart Rules include:

Throughput (requests/second)
JVM Free heap percentage
Process CPU Load
Pending user requests
Idle threads count
Thread pool queue length

Additionally, WLDF provides some “generic” Smart Rules to allow you to create policies based on your own JMX-based metrics.

Configure elasticity for a dynamic cluster

Before you begin Create dynamic clusters.

Elasticity enables the automatic scaling of dynamic clusters and re-provisioning of associated resources based on demand. For more information about elasticity, see Configuring Elasticity in Dynamic Clusters.

To configure a dynamic cluster for elasticity:

If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit(see Use the Change Center).
In the left pane of the Console, select Environment > Clusters.
In the Clusters table, select the name of the dynamic cluster you want to configure.
Select Configuration > Servers.
1. In Dynamic Cluster Size, enter the initial number of dynamic server instances provisioned for this dynamic cluster.
2. In Max Dynamic Cluster Size, enter the maximum number of running dynamic server instances allowed for scale up operations in this dynamic cluster. This number is the sum of the Dynamic Cluster Size and the additional number of dynamic server instances allowed for scale up operations. If a scale up operation attempts to exceed this limit, the operation will not fail, but WebLogic Server will only add running dynamic server instances up to this limit.
3. In Min Dynamic Cluster Size, enter the minimum number of running dynamic server instances to keep in this dynamic cluster. During a scale down operation, attempts to scale down below this limit are not allowed.
4. In Dynamic Cluster Cool-off Period In Seconds, enter the cool-off period (in seconds). After a scale up or scale down operation is performed, subsequent requests for scale up or scale down operations will be ignored during this period.
5. In Dynamic Cluster Shutdown Timeout In Seconds, enter the timeout period (in seconds) to use while gracefully shutting down a dynamic server instance to allow inflight work to complete.
6. In Enable Ignore Sessions During Shutdown, select this checkbox to ignore inflight HTTP sessions while shutting down dynamic server instances during scale down activities.
7. In Enable Wait For All Sessions During Shutdown, select this checkbox to wait for all (persisted and non-persisted) inflight HTTP sessions while shutting down dynamic server instances during scale down operations.

Note: For more information, see “Configuring Dynamic Clusters” in Configuring Elasticity in Dynamic Clusters.

Click Save.
To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Not all changes take effect immediately—some require a restart

Limitations and Considerations When Using Dynamic Clusters

When using dynamic clusters with WebLogic Server, note the following limitations and considerations:

You cannot override values in the server template at the individual dynamic server level because there are no individual server definitions in the xmlfile when using dynamic clusters.
You must ensure you have the performance capacity to handle the maximum number of server instances you specify in the dynamic cluster configuration.
Dynamic clusters do not support targeting to any individual dynamic server instance. Therefore, the following cannot be used with dynamic clusters:
- Deployments that cannot target to a cluster, including migratable targets. Therefore, you cannot create a migratable target for a dynamic cluster.
- Configuration attributes that refer to individual servers. This includes JTA migratable targets, constrained candidate servers, user preferred server, all candidate servers, and hosting server. Therefore, you cannot specify a dynamic server as the user preferred server for a migratable target.
- Configuration attributes that are server specific. This includes replication groups, preferred secondary groups, and candidate machines (server level).
- Constrained candidates for singleton services. You cannot limit a singleton service to dynamic servers.
For whole server migration with a dynamic cluster, you cannot limit the list of candidate machines that the dynamic cluster specifies, as the server template does not list candidate machines.
Dynamic clusters also have JMS limitations. For more information, see “Simplified JMS Cluster Configuration”in Administering JMS Resources for Oracle WebLogic Server.