Collective architecture

The set of Liberty servers in a single management domain is called a collective. A collective consists of at least one server with the collectiveController-1.0 feature enabled that is called a collective controller. Optionally, a collective can have many servers with the collectiveMember-1.0 feature enabled that are called collective members and a collective can be configured to have many collective controllers.

For IBM i platformsFor Distributed operating systemsNote: 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 its collectiveController-1.0 feature to work with collective members from single-server products.

The collective controller provides for a centralized administrative control point to perform operations such as MBean routing, file transfer, and cluster management. A core role of collective controllers is to receive information, such as MBean attributes and operational state, from the members within the collective so that the data can be retrieved readily without having to invoke an operation on each individual member. As the following diagram shows, the set of Liberty servers in a single management domain is called a collective. A collective consists of at least one server with the collectiveController-1.0 feature enabled. Optionally, it has many collective members and exists within a set of many collective controllers.

Figure 1. Liberty collective architecture
collective architecture flowchart

A set of collective controllers is called a replica set. There is only one replica set per collective, and all controllers must be part of the replica set. When there is more than one collective controller, each collective controller replicates its data to the other collective controllers in the replica set to allow for high availability and data protection. The replica set is logically present even when only one controller is in use. When changing your configuration to multiple replicas in a set, include at least three replicas in the set. The controllers in the replica set communicate with each other using a collaboration scheme to ensure that data is replicated across the set of controllers no matter which controller in the set receives an operation to store data. Each controller has a dedicated port for use by the replication protocol. Communication between the controllers in the replica set is always authenticated and protected with SSL. To ensure consistency among controller replicas, a quorum algorithm is used. For high availability, the number of controllers in a replica set must be an odd number. Ensuring that quorum is maintained requires that collective controller replica set members not span multiple data centers. Lacking quorum, changes such as a server start or stop, or configuration updates cannot be made to the collective.

A collective member can be configured with multiple collective controller endpoints. A collective member communicates with only one collective controller at a time; however, a configuration with more than one collective controller endpoint provides failover and workload balancing. Member-to-controller communication is always in the form of MBean operations that are performed over the IBM® JMX Rest Connector. Communication between controllers and members is always authenticated and protected with SSL.

For more information, see Setting up the server-management environment for Liberty by using collectives.

Administrative domain security configuration:
The administrative domain security configuration is made up of two parts:
  • User domain

    This domain relies on Java™ role-based security that defines the Administrator role. This can be mapped to users within the configured user registry.

  • Server domain

    This domain relies on SSL certificate-based authentication.

For more on collective security, see Collective security.

Configured and standby replicas

Replicas that have been added to a configured replica set are running (active replicas) or stopped (inactive replicas). A replica that is started and that has never been added to a configured replica set, or was removed from a configured replica set, is called a standby replica. As the following diagram shows, a collective can contain a configured replica set that has running (active) replicas and stopped (inactive) replicas. A collective can also contain standby replicas, which are running replicas that have never been added to a configured replica set or were removed from a configured replica set.

Figure 2. Configured and standby replicas in a collective controller
replica flowchart

Summary of collective architecture terms

collective
The set of Liberty servers in a single management domain.
collective controller
A server that has the collectiveController-1.0 feature enabled.
collective member
A server that has the collectiveMember-1.0 feature enabled.
replica set
A set of collective controllers. For optimal functionality and high availability, a replica set must have at least three controllers.
replica port
A dedicated port on a controller that is used by the replication protocol.
configured replica set
The union of the active replicas and inactive replicas.
active replicas
The started replicas that have been added to the configured replica set.
inactive replicas
The stopped replicas that have been added to the configured replica set.
standby replica
The started replicas that have not been added to the configured replica set or that were removed from the configured replica set.