Tip:
Highlight text to annotate it
X
This presentation describes support for Liberty collectives included in IBM
WebSphere Application Server V8.5.5
This presentation will provide an overview of Liberty collectives.
In WebSphere Application Server V8.5, the Liberty profile has
two options for administration: directly manager or managed by the Job Manager.
The stand-alone Liberty profile can be directly managed by way of JMX.
It can also be managed using the Job Manager,
which is capable of starting and stopping remote Liberty profile
servers, and deploying files to them to facilitate configuration
updates and application deployments.
New in WebSphere Application Server version 8.5.5 is the Liberty Collective.
The Liberty collective is the new multi-server administrative domain for the Liberty profile.
The Liberty collective model provides a single point of control,
called the collective controller, to enable fast, simple
management over many Liberty profile servers.
The Liberty collective helps reduce costs by simplifying numerous operational
concerns, including automation, security, lifecycle, monitoring, and inventory.
The Liberty collective is faster, lighter, easier,
more efficient, more scalable, more available and more flexible than the full profile cell model.
The Liberty collective also enables application clusters, which are
discussed in an alternate education module.
The Liberty collective is built on five core principles.
One, administration should be exposed through a standards-based API.
All administration for Liberty is provided by way of MBeans,
which enables a common tool set to for administrative actions.
Two, the entities within a collective are loosely coupled to the collective.
With this, all configuration belonging to the collective is isolated and self-contained.
This facilitates easily moving servers in and out of the collective.
Three, the administrative server, called a collective controller,
is designed to act as a distributed cache.
Application servers, within the collective, publish information to
the controller about themselves, such as which applications are
installed, their operational state, the available MBeans, and so on.
The controller also serves as a bi-directional JMX proxy,
allowing MBean operations to be routed to members within the collective.
Four, each member in the Liberty collective owns its own configuration.
There is no central master repository of configuration like there
is in the full WebSphere Application Server profile cell.
Finally, the administrative server is designed to be highly
scalable and highly available through a replica model, allowing
multiple instances of controllers to share data and perform the same operations.
The model is agent-less, which means a separate agent
process is not required on each host system within the collective.
Liberty collectives are very easy and quick to set up.
Given a blank Liberty profile installation, the initial step
to start a collective is to create a collective controller.
In order to create a collective controller, you can create a new server, or use an existing one.
Once the server exists, the collective create operation is
used to establish the necessary security configuration which allows collective
members to communicate securely with the controller.
In order to enable the collective controller functionality, the
collectiveController-1.0 feature must be enabled (along with some additional
security configuration) in the server.xml.
Once configured, the controller server can be started and
is now ready to accept joins for new members.
In order to join a server to a collective, the collective join operation is used.
The collective join operation requires an Administrative user of the
collective controller, and will establish the security configuration required
for the member to communicate with the collective controller.
The collective member functionality is enabled by the collectiveMember-1.0 or
clusterMember-1.0 features (along with some additional security configuration) in the server.xml.
Once configured, the member server can be started and
will automatically publish information about itself to the collective controller.
The following two actions result in a Liberty collective with one controller and one member.
By repeating the steps to join new members to the
collective, the collective can be easily expanded.
It is important to note that because the collective controller
functionality is enabled with a Liberty feature, the controller
can also serve normal applications workloads like any other Liberty profile server.
Whether the controller should be a dedicated process depends on
the size of the collective and the amount of management workload which is expected to be performed.
There are five new MBeans that provide new services for
systems management in WebSphere Application Server version 8.5.5.
The ServerCommands MBean provides methods to perform remote server start
and stop for any member server within the collective.
The ClusterManager MBean provides methods to perform operations on cluster
groups as a whole, and to do discovery about clusters defined within the collective.
The RoutingContext MBean allows MBean operations to be routed to
any member server within the collective.
The FileTransfer and FileService MBeans allow for file transfer and
file discovery operations to be performed on Liberty profile servers.
The file operation MBeans do not require a Liberty collective.
Each of these MBeans are covered more extensively in other education modules.
Liberty collectives are designed to provide scalable and resilient administration
by supporting multiple controllers within a collective.
The set of collective controllers within a collective is called a "replica set".
The replica set enables the size of a collective to
scale out, and to provide a highly available administrative server environment.
By using a horizontal scaling model for the new collective
controllers, a high availability administrative server environment is achieved.
The new collective controllers are called replicas because they perform
automatic data replication across all members of the replica set.
Any information written to one controller is automatically replicated to all other controllers.
Collective members can be configured with the set of available
collective controllers in order to allow collective members to automatically
perform connection balancing when establishing connections to the available collective controllers.
Should all controllers be unreachable, the member will periodically
attempt to connect to one of the available controllers.
In the case where the collective has a replica set,
if one controller fails the surviving replicas can take over
since any controller is capable of performing all controller operations.
As long as a simple mathematical majority of the replica
set remain active, there is no disruption in administrative operations.
Any members which were connected to the controller which failed
will automatically connect to one of the remaining controllers.
By doing this, there is effectively no disruption in
the information being published by the members.
Should a member lose connectivity to all of the controllers,
when the connection is re-established, the member will completely
republish its state to the controller to ensure the controller has no stale information.
Once the failed replica is restarted or replaced, it
is available to receive new client connections and is automatically
synchronized with any updates received by the surviving controllers.
The Liberty collective features are available in these editions:
The collectiveMember-1.0 and restConnector-1.0 features is available in all editions
of WebSphere Application Server Liberty Profile, including Liberty core.
The restConnector-1.0 feature includes the FileTransfer, FileService and RoutingContext MBeans.
The collectiveController-1.0 and clusterMember-1.0 features are only available in the
WebSphere Application Server Network Deployment edition.
The collectiveController-1.0 feature includes the ClusterManager and ServerCommands MBeans.
This section will show a Liberty with the collective command-line utility.
The collective command-line utility allows for easy creating of a collective.
The collective utility supports these operations:
Create, join and replicate opreations are used to create
the initial controller, join members and replicate additional controllers.
The remove operation can be used to remove a member from the collective once it has been joined.
The registerHost, updateHost and unregisterHost operations are used to
register host systems to the collective directly, without requiring
a Liberty installation be present on the host.
In order to set up a collective, you first need a collective controller.
Any Liberty server can act as a collective controller.
However, this example demonstrates the creation of a specific server to act as the controller.
Configuring the collective involves two steps: first, you must run the collective create task.
This task creates the security configuration necessary for collective members
to communicate securely.
Second, the server.xml for the server must be updated
ñ an example of a controller's server.xml is presented here.
Once the server is configured, start the server.
The next step is to add a member server.
Now that the collective controller is running, you can create and join a collective member.
Any existing server can join to the collective, but in this example a new server is created.
Once the server is created, use the collective join
task to register the server with the collective and establish
the security configuration necessary for secure communications.
Similar to the collective create task, the collective join
task output contains XML that needs to be copied into the member's server.xml.
Once the server is configured, start the member.
The member will automatically publish its information to the controller.
In order to increase the number of controllers which are
available in the collective, new controllers can be replicated from the original controller.
Each new controller is a replica of the original controller
as they share the same security configuration and the same root certificates.
You can create a new replica by using the collective utilities "replicate" operation.
Any existing server that is not part of the collective can be a new replica.
Similar to the collective create task, the collective replicate
task output contains XML that needs to be copied into the new controller's server.xml.
Once the server is configured, start the new replica.
The replica will automatically synchronize its data with the original controller.
Once the data synchronization is complete, the replica can
be activated by calling the RepositoryConfigurationMBean addReplica method.
To recap,..
The Liberty collective is the new administrative domain for the
Liberty profile, and can be easily built and configured using the collective command-line tool.
The new administrative server is called a collective controller,
and is enabled with the collectiveController-1.0 feature and members of
the collective are enabled using the collectiveMember-1.0 feature.
The Liberty collective can have thousands of members, and
provides for a scalable, highly available administrative server environment.
In summary, the new systems management model in Liberty 8.5.5 is:
Highly automated, requiring less input to establish a secure
configuration for all collective members.
It is fast and easy to script as collective topology
actions, such as create and join, are command-line enabled.
The collective model is agent-less, no longer requiring an
additional process to enable administrative actions, which means less cost on system resources.
And finally the collective uses a decentralized topology to allow
for very large scale, loose coupling of members and
each member retains control over its configuration.
See these references for additional information about Liberty collectives.
You can help improve the quality of IBM Education Assistant content by providing feedback.