1

I'm currently investigating the use of HAProxy as a Load Balancer. I've found that the recommended configuration for HA of the HAProxy itself (not the backends) involves using keepalived to establish a VIP that both systems respond to. This means that when the primary stops being active on the network, the passive HAProxy sends a gratuitous ARP message and instructs the network to send all traffic for that VIP to it instead.

This looks to be a good solution but it prevents an Active-Active Load Balancing setup for the HAProxies. I'm curious as to any methods that allow both HAProxies to respond to traffic and maintain reasonable uptime in case of a failure on one of them. DNS Round robin between two VIPs managed by the HAProxies, with opposite masters, seems like a reasonable solution but I haven't found any guidance on whether keepalived can support two VIPs on one system simultaneously.

Terrible MSPaint diagram to illustrate:

Example of proposed setup

Is this possible? Is this a reasonable solution? Have you seen any alternate solutions which are viable?

Edit: I found the following after posting which suggests it's possible but suggests using CLUSTERIP as an alternative. I'm not certain about the compatibility between CLUSTERIP and HAProxy.

duct_tape_coder
  • 755
  • 3
  • 12
  • Wouldn't this just introduce a new single point of failure outside of the HAProxies? DNS round robin just keeps round robining whether something actually listens on the other end or not, right? I'd say you've got a bigger design job in front of you than this if the failover time of HAProxy + keepalived is too long for you. – Mikael H Aug 08 '19 at 18:36
  • ..Also, if it's session data you're worried about there actually are other ways to handle it; both in terms of SSO systems with central token storage and by letting HAProxy instances communicate session information among themselves. – Mikael H Aug 08 '19 at 18:39
  • @MikaelH The idea being with the heartbeat that keepalived uses and the VIPs, it would allow the master VIP to fail over to the other HAProxy if the HAProxy went away. So you'd end up with two VIPs serviced by one HAProxy. There might be a brief delay between the failure and heartbeat switchover but that exists in a single VIP configuration as well. In this case, you'd actually only have ~50% of connections experiencing the delay due to the DNS round-robin. – duct_tape_coder Aug 08 '19 at 19:06
  • @MikaelH I've updated the diagram to include a failure scenario. – duct_tape_coder Aug 08 '19 at 19:12
  • Yes, that's what should happen and I think you're right in that only half the concurrent clients should have to fail over, but I'm still not convinced of the net benefit of this solution if you take all failure scenarios into account. For one, our primary Internet connection has had connectivity glitches more often than a HAProxy master node has gone down unexpectedly in the last three years, and neither of these events are at all common. I'm not saying you're wrong, but you may be overthinking this solution. But by all means: Build a set of test cases and see if it holds water. – Mikael H Aug 08 '19 at 19:21
  • The only benefit this provides over a standard single VIP keepalived in front of two HAProxies would be to load balance the traffic between the two HAProxy rather than forcing all traffic to the master. It seems like HAProxy is pretty robust and one would be sufficient for us but I'm investigating the possibility in case it's not. – duct_tape_coder Aug 08 '19 at 19:26
  • I think it's more than likely you'll be fine - it's an excellent piece of software that I recommend whenever appropriate - but I do understand your point. Good luck! – Mikael H Aug 08 '19 at 19:38
  • 1
    If you are in an network environment that supports ECMP you may wish to look at https://github.blog/2018-08-08-glb-director-open-source-load-balancer/ – Mark Wagner Aug 08 '19 at 23:38

0 Answers0