Synchronization of 2 HAProxy nodes


#1

I would like to set up two haproxy’s nodes in master-master configuration. And to achieve that I would have to keep synchronizing their backends (servers status, number of connections, and so on).

I know it can be achieved using peers and stick-table, but I’m not able to find any solution suitable to me.

I’m kind of newby. Any advice or suggestion will be welcomed.

Here are my proxies conifgurations:

listen stats
bind 0.0.0.0:9990
mode http
stats enable

listen lorehaven
bind  0.0.0.0:8098
mode    tcp
balance leastconn
option  tcplog
option redispatch
timeout check 3s
timeout client 11m
timeout connect 600
timeout queue 5m
timeout server 11m
<a lot of servers>

#2

Why do think you need synchronization, what is the use-case here?


#3

I’m using HAProxy to load balance tcp connections. All servers in backend have maxcon set to 3.

I would like to have 2 HAProxy nodes to avoid single point of failure.

And now, if I run 2 nodes simultaneously with maxcon 3 and equip them with same servers list manually, it won’t work properly. It’s caused by nodes not being aware of each other - one doesn’t know that second one set up a connection / they will set up maximum 6 connections in sum to each server in the backend.

That’s why I want to synchronize them. I want them being aware their actions - e.g. if node A set up connection, node B updates its connection list.


#4

I understand, you want synchronization so that maxconn/rate-limiting works correctly when both haproxy nodes are active at the same time.

That’s not supported in haproxy.

Also I personally believe this is a bad idea for a number a technical and organizational reasons.

This includes:

  • when there any issue or a broken state in the active instance, you cannot failover to the standby unit, as it will have synchronized the same state.
  • when you make a change, you cannot deploy it on the standby unit and then failover to it, with a proper rollback possibility, instead you have to deploy on active instances
  • there is no clear advantage of an active/active design, and it is especially senseless when you just have 2 nodes in active/active mode (because the second node is either not needed to keep up with the traffic - or if it is needed then both nodes become a single point of failure, because one node won’t be able to handle the load). If you need 16 nodes in active/active, then your point is probably performance, but with 2 nodes you really don’t have an excuse to not use active/standby
  • the delay in synchronization will lead to race conditions, imprecise and wrong behavior (because global rate-limiting simply doesn’t work)