WebSphere eXtreme Scale Product Overview > Availability > Replication for availability
|
| |
Shard allocation: primary and replica
The catalog service is responsible for placing shards. Each ObjectGrid has a number of partitions, each of which has a primary shard and an optional set of replica shards. The catalog service does not place replica and primary shards for the same partition on the same container. It also does not place replica and primary shards on containers that have the same IP address (unless the configuration is in development mode). The catalog service allocates the shards by balancing them so that they are evenly distributed over the available containers.
If a new container starts, then eXtreme Scale retrieves shards from relatively overloaded containers to the new empty container. With this behavior, eXtreme Scale establishes and maintains its essential elasticity. The elasticity is manifest in its powerful ability for scaling horizontally, both to scale out and scale in.
Scaling out
Scaling out means that when extra Java™ virtual machines, or containers, are added to an eXtreme Scale grid, then eXtreme Scale tries to move existing shards, primaries or replicas, from the old set of JVMs to the new set. This movement allows the grid to expand to take advantage of the processor, network and memory of the newly added JVMs. The movement also balances the grid and tries to ensure that each JVM in the grid hosts the same amount of data. As the grid expands, each server hosts a smaller subset of the total grid. eXtreme Scale assumes that data is distributed evenly among the partitions. This expansion enables scaling out.
Scaling in
Scaling in means that if a JVM fails, then eXtreme Scale tries to repair the damage. If the failed JVM had a replica, then eXtreme Scale replaces the lost replica by creating a new replica on a surviving JVM. If the failed JVM had a primary, then eXtreme Scale finds the best replica on the survivors and promotes the replica to be the new primary. eXtreme Scale then replaces the promoted replica with a new replica that is created on the remaining servers.
To maintain scalability, eXtreme Scale preserves the replica count for partitions as servers fail.
Figure 1. Placement of an ObjectGrid mapset with a deployment policy of 3 partitions with a minSyncReplicas value of 1, a maxSyncReplicas value of 1, and a maxAsyncReplicas value of 1
shards. The replica shards on each Java Virtual Machine include one synchronous replica shard and one asynchronous replica shard." />
- 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. - Life cycle, recovery, and failure events
Shards go through different states and events to support replication. The life cycle of a shard includes coming online, run time, shut down, fail over and error handling. Shards can be promoted from a replica shard to a primary shard to handle server state changes.