WebSphere eXtreme Scale Product Overview > Availability > Replication for availability > Shard allocation: primary and replica
High-availability catalog service
A catalog service is the 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 grid for high availability.
Components of the catalog service
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 server grid is propagated to the clients through the Common Object Request Broker Architecture (CORBA) service context.
Configure at least three catalog servers.
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 server grid 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 server grid and the container server grid are very different. The catalog server grid is for high availability of the system data.
The container grid is for the data high availability, scalability, and workload management. Therefore, two different routing tables exist: the routing table for the catalog server grid and the routing table for the server grid shards.
The catalog responsibilities are divided into a series of services. The core group manager performs peer grouping for health monitoring, the placement service performs allocation, the administration service provides access to administration, and the location service manages locality.
Catalog grid deployment
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 JVMs 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 placement of shards across the set of available containers. The placement service is responsible for maintaining a balance of resources across physical resources.
The placement service is responsible for allocating individual shards to their host container. It runs as a one-of-N elected service in the grid, so there is always exactly one instance of the service 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.
Administration
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 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 containers that are registering hosted applications with the placement service. The location service runs on all of the grid members to scale out this function.
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 grid.
Plan
After a catalog grid is started, the members of the grid bind together. Carefully plan the catalog grid topology, because you cannot modify the catalog configuration at run time. Spread out the grid as diversely as possible to prevent errors.
- Start a catalog server grid
- Connect eXtreme Scale containers embedded in WAS to a stand-alone catalog grid
You can configure eXtreme Scale containers that are embedded in a WAS environment to connect to a stand-alone catalog grid. Use the same property to connect the application server to the catalog grid. However, the property does not manage the life cycle of the catalog with the servers. Instead, the property allows the containers to locate the remote catalog grid.
To set the property, see Start the catalog service process in a WAS environment.
Server name collision: Because this property is used to start the eXtreme Scale catalog server as well as to connect to it, catalog servers must not have the same name as any WAS server. See Catalog server quorums for more information.
Parent topic
Shard allocation: primary and replica