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.
Configuring a Liberty auto-scalable
cluster for JVM elasticity
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. |
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:
|
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:
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:
|
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:
|
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:
|
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:
|
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:
Then,
highlight the second feature manager in the myMember2 server.xml
file:
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. |
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:
|
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:
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. |
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:
|
For more information, see Configuring auto-scalable clusters for JVM elasticity.