WebSphere eXtreme Scale Product Overview > Scalability > Partitioning
Placement and partitions
You have two placement strategies available for WebSphere eXtreme Scale: fixed partition and per container. The choice of placement strategy affects how the deployment configuration places partitions over the remote grid.
Fixed partition placement
You can set the placement strategy in the deployment policy XML file. The default placement strategy is fixed-partition placement, enabled with the FIXED_PARTITION setting.
The number of primary shards that are placed across the available containers is equal to the number of partitions configured with the numberOfPartitions element.
If you have configured replicas, the minimum total number of shards placed is defined by the following formula:
((1 primary shard + minimum synchronous shards) * partitions defined)The maximum total number of shards placed is defined by the following formula:
((1 primary shard + maximum synchronous shards + maximum asynchronous shards) * partitions)Your WebSphere eXtreme Scale deployment spreads these shards over the available containers. The keys of each map are hashed into assigned partitions based on the total partitions you have defined. They keys hash to the same partition even if the partition moves because of failover or server changes.
For example, if the numberPartitions value is 6 and the minSync value is 1 for MapSet1, the total shards for that map set is 12 because each of the 6 partitions requires a synchronous replica. If three containers are started, WebSphere eXtreme Scale places four shards per container for MapSet1.
Per-container placement
The alternate placement strategy is per-container placement, which is enabled with the PER_CONTAINER setting for placementStrategy in the map set element in the deployment XML file. With this strategy, the number of primary shards placed on each new container is equal to the number of partitions, P, configured. The WebSphere eXtreme Scale deployment environment places P replicas of each partition for each remaining container. The numInitialContainers setting is ignored when you are using per-container placement. The partitions get larger as the containers grow. The keys for maps are not fixed to a certain partition in this strategy. The client routes to a partition and uses a random primary. If a client wants to reconnect to the same session that it used to find a key again, it must use a session handle.
For more information see SessionHandle for routing.
For failover or stopped servers, the WebSphere eXtreme Scale environment moves the primary shards in the per-container placement strategy if they still contain data. If the shards are empty, they are discarded. In the per-container strategy, old primary shards are not kept because new primary shards are placed for every container.
For more information see Per-container placement strategy.
- Per-container placement strategy
As opposed to a fixed-partition placement policy, you may also enable per-container placement, which allows for different configurations that are not possible in a fixed-partition scenario.
Parent topic
PartitioningRelated reference
Deployment policy descriptor XML file