Shard Placement Policy
In Redis Enterprise Software (RS), the location of master and slave shards on the cluster nodes can impact the database and node performance. Master shards and their corresponding slave shards are always placed on separate nodes for data resiliency. The shard placement policy helps to maintain optimal performance and resiliency.
In addition to the shard placement policy, considerations that determine shard placement are:
- Separation of master and slave shards
- Available persistence and Redis on Flash (RoF) storage
- Rack awareness
- Memory available to host the database when fully populated
The shard placement policies are:
- dense - Place as many shards as possible on the smallest number of nodes to reduce the latency between the proxy and the database shards; Recommended for Redis on RAM databases to optimize memory resources
- sparse - Spread the shards across as many nodes in the cluster as possible to spread the traffic across cluster nodes; Recommended for Redis on Flash databases to optimize disk resources
When you create an RS cluster, the default shard placement policy (dense) is assigned to all databases that you create on the cluster. You can:
- Change the default shard placement policy for the cluster to sparse so that the cluster applies that policy to all databases that you create
- Change the shard placement policy for each database after the database is created
Shard placement policies
Dense shard placement policy
In the dense policy, the cluster places the database shards on as few nodes as possible. When the node is not able to host all of the shards, some shards are moved to another node to maintain optimal node health.
For example, for a database with two master and two slave shards on a cluster with three nodes and a dense shard placement policy, the two master shards are hosted on one node and the two slave shards are hosted on another node.
For Redis on RAM databases without the OSS cluster API enabled, use the dense policy to optimize performance.
Figure: Three nodes with two master shards (red) and two slave shards (grey) with a dense placement policy
Sparse shard placement policy
In the sparse policy, the cluster places shards on as many nodes as possible to distribute the shards of a database across all available nodes. When all nodes have database shards, the shards are distributed evenly across the nodes to maintain optimal node health.
For example, for a database with two master and two slave shards on a cluster with three nodes and a sparse shard placement policy:
- Node 1 hosts one of the master shards
- Node 2 hosts the slave for the first master shard
- Node 3 hosts the second master shard
- Node 1 hosts for the slave shard for master shard 2
For Redis on RAM databases with OSS cluster API enabled and for Redis on Flash databases, use the sparse policy to optimize performance.
Figure: Three nodes with two master shards (red) and two slave shards (grey) with a sparse placement policy
You can configure the shard placement policy for each database.