18 WebSphere eXtreme Scale Best Practices for Operation and Management
A catalog server uses a host name and two ports to communicate with its peer catalog
servers to provide the catalog service for the grid. This set of host names and port numbers
from all the catalog servers defines the catalog service, and it is the grid’s catalog service
endpoints. Each catalog server must be given the complete set of catalog service endpoints
when it starts. The catalog servers communicate among themselves on these ports to
provide a highly available catalog service for the grid. Each catalog server listens on a
separate port for container servers and grid clients. This combination of a host name and port
on which a catalog server listens is also called a
catalog server endpoint. You have to keep
the context straight. Usually, you deal with container servers and clients, so this use is the
predominant sense of the term. When a container server starts, it is given its catalog server
endpoint, by which it will connect to the catalog service.
The good news is that a WebSphere eXtreme Scale grid is defined by the catalog service’s
catalog service endpoints. Container servers and clients connect to the grid by using a
catalog server’s client catalog service endpoint.
Container servers connect to the catalog service when they start. The catalog service thus
knows the identity of all its container servers, and it distributes the shards over these
containers. Catalog servers are not involved in normal gets and puts to the grid, so they are
not a bottleneck that interferes with scaling.
2.3.2 Shards
The catalog service plays an instrumental role in the elastic nature of the grid configuration. It
is responsible for the replication, distribution, and assignment of the shards (containing the
data) to grid containers, as illustrated in Figure 2-5 on page 19. The catalog service evenly
distributes the primary shards and their replicas among the registered container servers.
Chapter 2. WebSphere eXtreme Scale architecture 19
Figure 2-5 WebSphere eXtreme Scale grid
The shard distribution algorithms ensure that the primary and replica shards are never in the
same container server (more specifically, never in two containers that have the same IP
address) to ensure fault tolerance and high availability.
If the machine or grid container hosting the primary shard fails, the catalog service promotes
a replica shard to be the primary shard, and creates a new replica shard in another grid
container on another IP address (usually a separate machine). The replica shard is then
populated in a background thread by copying the data from the new primary. If a machine or
grid container hosting a replica shard fails, the catalog service creates a new replica in
another grid container on another IP address, and is then populated by copying the data from
the primary.
Shard types
There are three types of shards:
Primary:
– Handles read requests and all insert, update, and remove requests. (Replicas are
read-only.)
– Replicates data (and changes) to the replicas.
– Manages commits and rollbacks of transactions.
– Interacts with a back-end data store for read and write requests.
Synchronous replica:
– Maintains the exact state as the primary shard.
Grid container server
Grid container
Grid container server
Grid container
Catalog service
Grid container server
Grid container
Catalog
Server
Catalog
Server
Catalog
server
Grid A
Primary Shard 0
Replica Shard 1
Replica Shard 0
Replica Shard 2Replica Shard 2
Primary Shard 1
Primary Shard 0
Replica Shard 2
Replica Shard 1
Primary Shard 3
Primary Shard 1
Replica Shard 0
Replica Shard 1
Primary Shard 2
Replica Shard 0
Primary Shard 2
Replica Shard 3
Get WebSphere eXtreme Scale Best Practices for Operation and Management now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
