Video: Configuring a Liberty auto-scalable cluster for JVM elasticity

The following transcript is for the "Configuring a Liberty auto-scalable cluster for JVM elasticity" video, which demonstrates how to configure a collective to support Java virtual machine (JVM) elasticity. This transcript is the video storyboard. Audio describes narration and captions. Onscreen Action describes the content shown in the video.

Video Configuring a Liberty auto-scalable cluster for JVM elasticity

Table 1. Title page. Show title and then animation that illustrates autonomic starting and stopping of servers based on resource use.
Scene Audio Onscreen Action
1 This video shows how to configure a Liberty collective to support Java virtual machine (or JVM) elasticity. Show title Configuring a Liberty auto-scalable cluster for JVM elasticity.
2 With JVM elasticity, a Liberty scaling controller can start or stop cluster members based on resource use. When resource use goes up, the scaling controller starts cluster members. When resource use goes down, the scaling controller stops cluster members. The IBM Java development kits (or JDKs) on the computers that host the cluster members provide the data on resource use. Show animation of scaling controller stopping and starting cluster member servers. When resource use goes up, the scaling controller starts member servers. When resource use goes down, the scaling controller stops member servers.
Table 2. Demo configuring the scaling controller. Show adding the scalingController-1.0 feature to the server.xml file of a collective controller.
Scene Audio Onscreen Action
3 To set up an auto-scalable cluster, you need at least one collective controller with at least two member servers joined to the controller. I have a collective controller with three member servers.

What you see here is my collective controller and member servers in the Explore tool of the Liberty Admin Center.

You also can see the server.xml file of the collective controller. I added the adminCenter-1.0 feature to the server.xml to view the collective's servers in Admin Center.

Show the four servers in the Explore tool of Admin Center.

Also show an editor open on the server.xml file of the collective controller, which has:

<featureManager>
   <feature>jsp-2.2</feature>
   <feature>adminCenter-1.0</feature>
</featureManager>
4 To make my collective controller a scaling controller, I add the scalingController-1.0 feature to its server.xml file. You can add the scalingController-1.0 feature to either feature manager. My preference is to add it below the collectiveController-1.0 feature.

Save the file.

In the editor open on the controller server.xml file, add the scalingController-1.0 feature to a feature manager:
<featureManager>
 <feature>collectiveController-1.0</feature>
 <feature>scalingController-1.0</feature>
</featureManager>
Then, save the file.
5 After adding the feature, I want to ensure the scaling controller feature is installed and activated. Before I enable auto scaling for the members, I want to see the message This server is elected to be the primary scaling controller in the controller's message log. Open an editor on the controller messages.log file and scroll to the end of the log.
6 myController is now the primary scaling controller so I can enable its members to be dynamic cluster members. In the controller messages.log file, highlight the message:
CWWKV0102I: This server is elected to be the primary scaling controller.
Table 3. Demo configuring a member server for auto scaling. Show adding the clusterMember-1.0 and scalingMember-1.0 features to the server.xml file of a collective member.
Scene Audio Onscreen Action
7 To make a collective member a dynamic cluster member, I add the clusterMember-1.0 feature and the scalingMember-1.0 feature to a feature manager of the collective member. I can add the features below the jsp-2.2 feature or below the collectiveMember-1.0 feature. I am adding the features below the collectiveMember-1.0 feature. In an editor open on the server.xml file of the myMember collective member, add the clusterMember-1.0 and scalingMember-1.0 features to a feature manager:
<featureManager>
 <feature>collectiveMember.0</feature>
 <feature>clusterMember-1.0</feature>
 <feature>scalingMember-1.0</feature>
</featureManager>
8 I also add a hostSingleton element to the server.xml file. I specify a hostSingleton name of ScalingMemberSingletonService and a port number of 5164. You can specify any port number, but the port number must be unique on the host computer.

All scaling members on the same host must use the same hostSingleton port.

In the editor open on the myMember server.xml file, add the hostSingleton element:
<hostSingleton name="ScalingMemberSingletonService" port="5164" />
9 I save the file.

For the scaling controller to recognize these changes to a member configuration, the member must be running.

Save the myMember server.xml file.

The auto scaling icon displays on the myMember card in the Explore tool.

10 To make sure that the scaling member feature is activated, I look at the member messages.

The messages show that the scaling member feature is activated, ScalingMemberSingletonService is elected the host leader, and the messenger connection goes to my scaling controller.

Open an editor on the myMember messages.log file and highlight the messages:
CWWKV0200I: The ScalingMember feature is activated.
...
CWWKV0203I: Server host=wasid.raleigh.ibm.com; userdir=C:/wlp/usr; server=myMember; port=9444; service=ScalingMemberSingletonService; scope=host is elected as the host leader.
11 I now copy the changes that I've made to myMember's server.xml file and make similar changes to the server.xml files of the other collective members.

Notice that after I save the changes, an auto scaling icon displays on the member cards in the Explore tool.

In the editor open on the myMember server.xml file, copy the following elements:
<featureManager>
 <feature>collectiveMember.0</feature>
 <feature>clusterMember-1.0</feature>
 <feature>scalingMember-1.0</feature>
</featureManager>

<hostSingleton name="ScalingMemberSingletonService" port="5164" />
Then, highlight the second feature manager in the myMember2 server.xml file:
<featureManager>
 <feature>collectiveMember.0</feature>
</featureManager>
Paste the copied elements into the file, and save the changes.

The auto scaling icon displays on the myMember2 card in the Explore tool. Position the cursor over the auto scaling icon on the myMember and MyMember2 cards.

Repeat this scene for myMember3.

12 Because I did not specify a cluster name, the dynamic cluster members are added to the defaultCluster.

I now have three dynamic cluster members joined to my scaling controller.

The name of the cluster, defaultCluster, displays on the member cards in the Explore tool.
Table 4. Demo changing a default scaling policy. Mention the default scaling policies and demo changing a scaling policy.
Scene Audio Onscreen Action
13 One of the default scaling policies requires that at least two dynamic cluster members be running.

The other default scaling policies control when a dynamic cluster member is started or stopped. A member is started when the average members' resource use exceeds 90%. And a member is stopped when the average resource use is less than 30%.

I'm going to change the first default scaling policy to require that only one to two dynamic cluster members be running. Because I have three members, one of the members should stop.

List information about the default scaling policies:
Default scaling policies

At least two cluster members are active

Another cluster member starts when the average CPU, process memory use, or heap use of all active members exceeds 90%

A cluster member stops when the average CPU, process memory, and heap use drops below 30%
14 I go to the scaling controller server.xml file and add a scaling definition that sets minimum equal to 1 and maximum equal to 2 for the default scaling policy.

Save the changes.

In the editor open on the server.xml file of the collective controller, add:
<scalingDefinitions>
 <defaultScalingPolicy enabled="true" min="1" max="2"/>
</scalingDefinitions>
Then, save the file changes.
15 The Explore tool shows that the scaling controller stopped one of the dynamic cluster members because of my change to the default scaling policy.

I have configured an auto-scalable cluster with JVM elasticity.

In the Explore tool, the number of stopped servers changes from 0 to 1. The status of myMember3 goes from running, to stopping, to stopped.
Table 5. Conclusion. Show where to find more information about auto scaling with JVM elasticity.
Scene Audio Onscreen Action
16 For more information about Liberty auto scaling and changing the default scaling policies, see WASdev.net and the WebSphere Application Server Liberty documentation on IBM Knowledge Center. Show information on documentation:
WASdev
http://developer.ibm.com/wasdev
WebSphere Application Server Liberty documentation on IBM Knowledge Center
http://www-01.ibm.com/support/knowledgecenter/

For more information, see Configuring auto-scalable clusters for JVM elasticity.


Icon that indicates the type of topic Concept topic

File name: video_transcript_autoscaling_jvm.html