Setting up the server-management environment for Liberty by using collectives
To set up the server-management environment for the Liberty by using collectives, define the appropriate features in the server.xml file and run the corresponding collective command-line tasks to establish the administrative domain security configuration.
About this task
You can use collectives to manage multiple servers from a single management domain. For high availability, you can configure collective replica sets, clusters, or scaling. For general information about collectives, see Collective architecture.
Liberty provides multiple-server management in the following features:
- collectiveController-1.0
The
collectiveController-1.0
feature enables controller functionality for a management collective and includes collective- and cluster-management MBeans that are accessible using the REST JMX connector that is provided by therestConnector-1.0
feature. TherestConnector-2.0
feature is tolerated. The collective controller acts as a storage and collaboration mechanism to which collective members can connect. The administrative domain security configuration for thecollectiveController-1.0
feature is established using the collective command-line create and replicate tasks. For details about the feature, see Collective Controller.The
collectiveController-1.0
feature and its capabilities are available only in multiple-server products such as WebSphere® Application Server Network Deployment Liberty and WebSphere Application Server for z/OS® Liberty. The feature is not available in single-server products such as WebSphere Application Server Liberty, or WebSphere Application Server Liberty Core. If you have a multiple-server product installation, you can use itscollectiveController-1.0
feature to work with collective members from single-server products. - collectiveMember-1.0The
collectiveMember-1.0
feature enables a server to be a member of a management collective and be managed by the collective controller. The administrative domain security configuration for thecollectiveMember-1.0
feature is established using the collective command-line join task. For details about the feature, see Collective Member.Tip: All servers enabled with thecollectiveController-1.0
feature are managed; therefore, you do not need to specifycollectiveMember-1.0
if the server already has thecollectiveController-1.0
feature enabled. - clusterMember-1.0
The cluster member feature enables a collective member to participate in a static cluster. For details about the feature, see Static Cluster Member.
- dynamicRouting-1.0
The dynamic routing feature is an Intelligent Management feature of the WebSphere plug-in for Apache and IHS that provides On Demand Router capabilities for the plug-in. The dynamic routing feature enables a server to run a REST service to which the plug-in can connect to dynamically route to all servers in a collective. For details about the feature, see Dynamic Routing.
- scalingController-1.0
The scaling controller feature enables a collective controller to expand or contract an auto scaling cluster and manage the scaling controller. If an environment has many scaling controllers, only one of the running scaling controllers can make decisions. If that controller is stopped, another running scaling controller takes over for it. The scaling controller can start an auto scaling cluster member in response to increased resource usage, or it might stop an auto scaling cluster member in response to decreased resource usage. For details about the feature, see Scaling Controller.
- scalingMember-1.0
The scaling member feature monitors the workload within a server and its host, then sends this information to the scaling controller. The scaling controller feature is enabled in the collective controllers that are part of the collective. This feature also enables dynamic clustering of the collective members and allows the servers to dynamically start or stop based on criteria that is specified by the scaling policy. If more than one scaling member is on the same host, each scaling member must define a
hostSingleton
element with a port in the server.xml file. All scaling members on the same host must use the same port to identify a host leader. The host leader is the only scaling member that communicates with the scaling controller. It communicates metric data from the members to the controller and communicates scaling decisions that are made by the controller to the members in the host. For details about the feature, see Scaling Member.Restriction: The Scaling Member feature (scalingMember-1.0
) is not available on the IBM i platform.
Procedure
What to do next
You can administer the collective using the following tools: