WebSphere eXtreme Scale technical overview
WebSphere® eXtreme Scale is an elastic, scalable, in-memory data grid. It dynamically caches, partitions, replicates, and manages application data and business logic across multiple servers.
Because WebSphere eXtreme Scale is not an in-memory database, you must consider specific configuration requirements. The first step to deploying a data grid is to start a core group and catalog service. The catalog service acts as coordinator for all other Java™ virtual machines that are participating in the data grid and manages configuration information. WebSphere eXtreme Scale processes are started with commands that you issue on the command line.
The next step is to start container server processes for the data grid to store and retrieve data. As container servers are started, they automatically register themselves with the core group and catalog service. By registering, the catalog servers can cooperate in providing data grid services. More servers increase both data grid capacity and reliability.
A local data grid is a simple, single-instance grid where all the data is in the one data grid. To effectively use WebSphere eXtreme Scale as an in-memory database processing space, you can configure and deploy a distributed data grid. The data in the distributed grid is spread out over the various eXtreme Scale servers so that each server contains only some of the data. This portion of data is a partition.
A key distributed data grid configuration parameter is the number of partitions in the grid. The grid data is partitioned into this number of subsets, each of which is called a partition. The catalog service locates the partition for the data based on its key. The number of partitions directly affects the capacity and scalability of the data grid. A server can contain one or more data grid partitions. As a result, the memory space of the servers limits the size of a partition. Conversely, increasing the number of partitions increases the capacity of the data grid. The maximum capacity of a data grid is the number of partitions times the usable memory size of each server. A server can be a JVM, but you can define your container server to suit your deployment environment.
The data of a partition is stored in a shard. For availability, a data grid can be configured
with replicas, which can be synchronous or asynchronous. Changes to the grid data are made to the
primary shard, and replicated to the replica shards. The total memory that is used or required by a
data grid can be calculated with the following equation: the size of the data grid times (1
(for the primary) + the number of replicas).
WebSphere eXtreme Scale distributes the shards of a data grid over the number of servers that are in the data grid. These servers might be on the same or different physical servers. For availability, replica shards are placed in separate physical servers from primary shards.
WebSphere eXtreme Scale monitors the status of its servers and moves shards during shard or physical server failure and recovery. For example, if the server that contains a replica shard fails, WebSphere eXtreme Scale allocates a new replica shard, and replicate data from the primary to the new replica. If a server that contains a primary shard fails, the replica shard is promoted to be the primary shard, and, a new replica shard is constructed. If you start an extra server for the data grid, the shards are balanced over all servers. This rebalancing is called scale-out. Similarly, for scale-in, you might stop one of the servers to reduce the resources that are used by a data grid. As a result, the shards are balanced over the remaining servers.