Redis Cluster Behind TCP Load Balancer?

[Kevin Johnson]

Hello All, 

I've been testing hosting a Redis cluster behind a TCP hardware load balancer, meaning the client only has to route requests to a single endpoint (a vip) to reach the cluster.  So far I haven't experienced any significant performance or other penalties with this setup, but I'm wondering what is really happening with request routing.

In particular, if a given request that is handled by a random Redis node (selected based on the LB routing mechanism) hashes to a different slot range, does this involve another round trip back to the client, which repeats the request through the vip until a node with the right slot coverage can ultimately satisfy it?

Thanks in advance!

-Kevin

[AlexanderB]

What is likely happening is that your commands are going to redis-cluster during it's initial bootstrap process where it issues a cluster slots command to get the cluster's topology. https://redis.io/commands/cluster-slots

From there in, it's using the results of that cluster slots command to do the routing, talking directly to the nodes via ip addresses, rather than the initial config you passed in about the tcp load balancer. This actually works just fine as all of the routing is really happening in the client itself, while the tcp load balancer still helps solve issues with bootstrapping the cluster's initial state without needing to hard code the ips or host names of the nodes behind it. 

[Kevin Johnson]

Hi AlexanderB and thanks for replying.

I've confirmed that this is indeed what is happening:

"...the tcp load balancer still helps solve issues with bootstrapping the cluster's initial state without needing to hard code the ips or host names of the nodes behind it. "

I guess this is the sole advantage of hosting the cluster hosts behind a load balancer.

Thanks again!

Kevin

[SANGEETH TALLURI]

Kevin

i created a 3 node cluster  where master shards are placed on node A ,B ,C port 9000 and slaves of these masters running 9001 port. 

10.X.X.1 9000 master 

10.X.X.2 9000 masrer

10.X.X.3  9000 master 

10.X.X.1 9001 slave

10.X.X.2 9001 slave

10.X.X.3  9001 slave

Can i put all these behind a tcp LB and share the LB ip to client applications to use?

[David Maier (Redis Labs)]

Hi Sangeeth,

the Redis Cluster API is designed in a way that the clients are smart enough to understand the topology of the cluster and to react to changes (e.g.,slot migrations, failovers). You are typically using a Cluster client library to access Redis Cluster (instead of client library for standalone Redis).

The way how it works is that the client is getting bootstrapped by then knowing which hash slots are mapped to which endpoints. The client will then try to send the command to the correct endpoint. If something changed, then the client would usually get a 'MOVED <somewhere else>' response to which it needs to react. Such a reaction would be to follow the redirect to another endpoint, OR to fetch the topology (slots to endpoint mapping) again.

Now, adding a simple load balancer on top of a Redis OSS Cluster does typically not work well because the load balancer doesn't know the slots to endpoints mapping. If the load balancer would do a round-robin across the endpoints, then this would lead to a lot of MOVED responses. Such a MOVED response contains the IP address and port of the Redis endpoint that is most likely responsible for the requested key, BUT the load balancer would then not know how to deal with this information.

Hope this helps.

Regards,

David

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/redis-db/2b6a0020-36e2-41c2-808e-6a77e23f8087n%40googlegroups.com.

--

David Maier

Director of Technical Enablement

Phone: +49.176.84481435

Twitter  LinkedIn  Facebook

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.