Cassandra best practices : it is a good idea to add Ha Proxy in front of Cassandra?

Viewed 275

From my understanding, the Datastax driver is TokenAware :

Token-aware policy is used to reduce network hops whenever possible by sending requests directly to the node that owns the data.

The driver has also some DCAwareRoundRobinPolicy, in order to query an other datacenter if needed, and to repartitate the load :

This policy provides round-robin queries over the node of the local data center. It also includes in the query plans returned a configurable number of hosts in the remote data centers

Questions :

It seems out that with client driver configuration, it is already possible to do HighAvailability, LoadBalancing, and be TokenAware.

  • Regarding those elements, do you think it is still a good practice to also add HaProxy on top of Cassandra ?

  • If yes on first question, may I loose the TokenAware property ?

  • If yes on first question, will the contact point continue to send to the java driver the correct topology (ip/host list of nodes) ?

Thank you

2 Answers

Usually it's not recommended to have a proxy before Cassandra - the TokenAware load balancing policy will work just out of box (if you're using prepared statements). Besides the selecting correct replicas, it will take into account the status of the node, etc.

The problem with proxy is that after the first contact, the driver will receive the list of the all nodes in the cluster, so driver will try to use these nodes anyway, not the proxy node (until you're using whitelist code load balancing policy, or you implemented the address translation functionality).

It is not a good idea to place a hardware or software load-balancer in front of Cassandra. The same goes for virtual IPs.

As you already pointed out, the Cassandra drivers use a built-in load-balancing policy and are aware of the cluster topology including the health of the nodes. When you place a load-balancer or VIP in between the driver and the cluster, the driver loses the ability to intelligently route requests.

For example if you are using the Java driver, by default the driver uses a load-balancing policy that routes queries to the local data centre with a token-aware policy that prefers to route requests to replicas (nodes) that own the data being queried.

The driver knows about the nodes in the cluster because it connects to contact points (a list of node IP addresses) to establish a control connection at startup time. The driver uses the control connection to perform tasks that include querying the system tables to learn about the cluster topology. Using the control connection, the driver also listens for changes to the cluster automatically so it is aware of things like node additions, node outages, new data centres and decommissions in real time.

For these reasons, it is not advisable to use external load balancers or DNS virtual IPs since it affects the ability of the drivers to operate in the optimum way. Cheers!

Related