Configure auto-scalable clusters for JVM elasticity

This task describes how to configure a collective to support JVM elasticity. The scaling controller starts and stops existing Liberty servers based on resource usage and optional scaling policies. There is no provisioning of new servers.

The types of collected resource usage information vary among JDKs. IBM JDK 1.7 for Windows and Linux operating systems, provides all necessary usage information for auto scaling and is the preferred JDK. Other JDKs may not provide all necessary usage information for auto scaling based on the individual JVM resource usage.

1. Configure a collective that uses auto scaling.

   For details on creating a collective controller and member server, see Configure a Liberty collective.

2. Add the scalingController-1.0 feature to server.xml of one or more collective controllers.

   <featureManager>
    <feature>jsp-2.2</feature>
    <feature>collectiveController-1.0</feature>
    <feature>scalingController-1.0</feature>
   </featureManager>

   After adding the feature, the following messages display in any order in the messages.log of the collective controller, provided the collective controller is running:

   CWWKV0300I: The StackManager service started.
   CWWKV0302I: The existing stacks are []
   CWWKV0100I: The ScalingController feature is activated.
   CWWKX1002I: Singleton service ScalingControllerSingletonService for scope 
   CWWKV0102I: This server is elected to be the primary scaling controller.
   CWWKF0012I: The server installed the following features: [scalingController-1.0].

   It might take some time for the scaling controller to register the member and display the CWWKV0121I message.

3. Add both the clusterMember-1.0 and scalingMember-1.0 features to all collective members which we want the scaling controller to control. If the server is not started when we add the features, we must start it manually once in order for the scaling controller to recognize the added features. Define a hostSingleton element with a port in the member server.xml files. All scaling members on the same host must use the same port. The following example uses port number 5164:

   <featureManager>
    <feature>jsp-2.2</feature>
    <feature>clusterMember-1.0</feature>
    <feature>scalingMember-1.0</feature>
   </featureManager>
   
   <hostSingleton name="ScalingMemberSingletonService" port="5164" />

   If the server is not started when we add the features and hostSingleton element, we must start it manually once for the scaling controller to recognize the added features. The following messages display in any order in the messages.log of the collective member:

   CWWKX1000I: The SingletonMessenger MBean is available.
   CWWKX7400I: The ClusterMember MBean is available.
   CWWKX1002I: Singleton service ScalingMemberSingletonService for scope host is created.
   CWWKV0200I: The ScalingMember feature is activated.
   CWWKV0203I: Server host=host_name; userdir=path_to_usr_directory; server=member_name; port=member_port_number; service=ScalingMemberSingletonService; scope=host is elected as the host leader.
   CWWKX1004I: Messenger connection is connected to host=controller_host_name, port=controller_port_number.

4. Optional: Change the default scaling policies to meet the needs of the environment. Refer to Defining scaling policies to manage workload for more information.

Tasks:

Set up Auto Scaling for Liberty collectives