Administration guide > Plan the WebSphere eXtreme Scale environment > Catalog service

High-availability catalog service

A catalog service domain is the data grid of catalog servers you are using, which retain topology information for all of the containers in the eXtreme Scale environment. The catalog service controls balancing and routing for all clients. To deploy eXtreme Scale as an in-memory database processing space, cluster the catalog service into a catalog service domain for high availability.

Components of the catalog service domain

When multiple catalog servers start, one of the servers is elected as the master catalog server that accepts Internet Inter-ORB Protocol (IIOP) heartbeats and handles system data changes in response to any catalog service or container changes.

When clients contact any one of the catalog servers, the routing table for the catalog service domain is propagated to the clients through the Common Object Request Broker Architecture (CORBA) service context.

Configure at least three catalog servers. Catalog servers must be installed on separate nodes or separate installation images from the container servers to ensure that you can seamlessly upgrade the servers at a later date. If the configuration has zones, you can configure one catalog server per zone.

When an eXtreme Scale server and container contacts one of the catalog servers, the routing table for the catalog service domain is also propagated to the eXtreme Scale server and container through the CORBA service context. Furthermore, if the contacted catalog server is not currently the master catalog server, the request is automatically rerouted to the current master catalog server and the routing table for the catalog server is updated.

A catalog service domain and the container server data grid are very different. The catalog service domain is for high availability of the system data. The container server data grid is for the data high availability, scalability, and workload management. Therefore, two different routing tables exist: the routing table for the catalog service domain and the routing table for the container server data grid shards.

The catalog service domain responsibilities are divided into a series of services:

Core group manager

The catalog service uses the high availability manager (HA manager) to group processes together for availability monitoring. Each grouping of the processes is a core group. With eXtreme Scale, the core group manager dynamically groups the processes together. These processes are kept small to allow for scalability. Each core group elects a leader that has the added responsibility of sending status to the core group manager when individual members fail. The same status mechanism is used to discover when all the members of a group fail, which causes the communication with the leader to fail.

The core group manager is a fully automatic service responsible for organizing containers into small groups of servers that are then automatically loosely federated to make an ObjectGrid. When a container first contacts the catalog service, it waits to be assigned to either a new or existing group. An eXtreme Scale deployment consists of many such groups, and this grouping is a key scalability enabler. Each group is a group of Java™ virtual machines that uses heart beating to monitor the availability of the other groups. One of these group members is elected the leader and has an added responsibility to relay availability information to the catalog service to allow for failure reaction by reallocation and route forwarding.

Placement service

The catalog service manages the placement of shards across the set of available container servers. The placement service is responsible for maintaining balance across physical resources. The placement service is responsible for allocating individual shards to their host container. The placement service runs as a One of N elected service in the data grid, so exactly one instance of the service is running. If that instance fails, another process is then elected and it takes over. For redundancy, the state of the catalog service is replicated across all the servers that are hosting the catalog service.


The catalog service is also the logical entry point for system administration. The catalog service hosts an Managed Bean (MBean) and provides Java Management Extensions (JMX) URLs for any of the servers that the catalog service is managing.

Location service

The location service acts as the touchpoint for both clients that are searching for the containers that host the application they seek, as well as for the container servers that are registering hosted applications with the placement service. The location service runs on all of the data grid members to scale out this function.

Catalog service domain deployment

The catalog service hosts logic that is typically idle during steady states. As a result, the catalog service minimally influences scalability. The service is built to service hundreds of containers that become available simultaneously. For availability, configure the catalog service into a data grid.


After a catalog service domain is started, the members of the data grid bind together. Carefully plan the catalog service domain topology, because you cannot modify the catalog service domain configuration at run time. Spread out the data grid as diversely as possible to prevent errors.

Start a catalog service domain

For more information about creating a catalog service domain, see .

Connect eXtreme Scale containers embedded in WAS to a stand-alone catalog service domain

You can configure eXtreme Scale containers that are embedded in a WAS environment to connect to a stand-alone catalog service domain.

See Catalog server quorums for more information.

Parent topic:

Catalog service


Search Tips   |   Advanced Search