When and How Should the OSS Cluster API be Configured?

Redis Enterprise Software
Client Libraries
python

Last updated 12, Jun 2024

Question

When and how should the OSS Cluster API configuration be used?

Answer

The default configuration of Redis Enterprise Cluster delegates to the proxy the operation of routing the commands from the client to the right shard (OSS Cluster API configuration is disabled). The OSS Cluster API is an endpoint discovery mechanism that allows the clients to know the cluster topology and connect the Redis Enterprise node that hosts the master shard of the data affected by a CRUD operation. This configuration has the advantage of removing cross-node communication when the data is not stored by the same node that received the command. Still, the client library needs to be cluster-aware to deal with the routing logic.

Considerations on performance

Before configuring the cluster using such a mechanism, it is usually worth making some previous considerations, such as:

  1. Are there any performance issues with the current database?
  2. What is the expected throughput at which latency?
  3. Does the application support the new discovery mechanism or it needs changes?
  4. What about the network bandwidth and payload size?
  5. Can the network sustain additional cross-node communication load?

First, to decrease latency and access times, it might be potentially good enough to change the proxy policy/shards-placement policy to all-master-shards/sparse. However, the downside is that this might lead to more cross-node communication, e.g., from proxy on node  A to shards on node B. Those additional network hops might have a negative impact on the average latency. So if very high throughput is desired together with quite aggressive latency requirements, then the OSS cluster API will help to avoid this cross-node communication (the proxy policy/shards placement is still all-master-shards/sparse, but a proxy on node A only communicates to master shards on node A because the client already knows which proxy is responsible for a given key).

In general, it makes sense to review the sizing of the cluster and then take the necessary actions in that case, which may include configuring the OSS Cluster API to reduce access times and latency.

Configuration of the OSS Cluster API

Configuring the OSS Cluster API can be done either via the UI or using the rladmin tool. Configure the right proxy policy and enable the oss_cluster parameter. Refer to the instructions in the official documentation to enable the OSS Cluster API.

Note that using CLUSTER SLOTS (CLUSTER SHARDS starting from Redis OSS version 7) in Redis Enterprise exposes by default the internal IPs for the OSS Cluster API supported database. Change the behavior using the related configuration:

rladmin> tune db db:<DB_ID> oss_cluster_api_preferred_ip_type external

Client libraries and OSS Cluster API

Client libraries must implement the logic to deal with Redis Enterprise Clusters configured with OSS Cluster API support. Once the support is granted (e.g. redis-py and Jedis support this configuration), it is possible to configure multiple IP addresses, one for each node in the cluster, to perform cluster discovery. This is especially useful for high availability and for those cases where no DNS resolution is available. Connecting to the cluster can be done as follows using the redis-py client library:

import redis
from redis.cluster import RedisCluster
from redis.cluster import ClusterNode

startup_nodes = [ClusterNode('10.10.1.15', 12000),
                ClusterNode('10.10.1.16', 12000),
                ClusterNode('10.10.1.17', 12000)]

rc = redis.RedisCluster(startup_nodes=startup_nodes, decode_responses=True)

print("Set: {}".format(rc.set("foo", "bar")))
print("Get: {}".format(rc.get("foo")))

References

Refer to the Redis Enterprise documentation to learn more about the Redis OSS Cluster API Architecture.