HAProxy is a load balancer; this is a fact. It is used to route traffic to servers to primarily ensure application reliability.
Most of the time, the sessions are locally stored on a server. This means that if you want to split client traffic on multiple servers, you have to ensure each user can be redirected to the server which manages his session (if the server is available, of course). HAProxy can do this in many ways: we call it persistence.
Thanks to persistence, we usually say that any application can be load-balanced… This is true in 99% of the cases. In very rare cases, the application can’t be load-balanced. I mean that there might be a lock somewhere in the code or for some other good reasons…
In such cases, to ensure high availability, we build “active/passive” clusters, where a node can be active at a time.
HAProxy can be used in different ways to emulate an active/passive clustering mode, and this is the purpose of today’s article.
Bear in mind that by “active/passive”, I mean that 100% of the users must be forwarded to the same server. And if a failover occurs, they must follow it in the meantime!
Let’s use one HAProxy with a couple of servers, s1 and s2. When starting up, s1 is the master and s2 is used as backup:
------------- | HAProxy | ------------- | ` |active ` backup | ` ------ ------ | s1 | | s2 | ------ ------
Automatic failover and failback
The configuration below makes HAProxy use s1 when available, otherwise, failover to s2 if available:
defaults mode http option http-server-close timeout client 20s timeout server 20s timeout connect 4s frontend ft_app bind 10.0.0.100:80 name app default_backend bk_app backend bk_app server s1 10.0.0.1:80 check server s2 10.0.0.2:80 check backup
The most important keyword above is “backup” on the s2 configuration line.
Unfortunately, as soon as s1 comes back, then all the traffic will fail back to it again, which can be acceptable for web applications but not for active/passive
Automatic failover without failback
The configuration below makes HAProxy use s1 when available; otherwise, failover to s2 if available.
When a failover has occurred, no failback will be processed automatically, thanks to the stick table:
peers LB peer LB1 10.0.0.98:1234 peer LB2 10.0.0.99:1234 defaults mode http option http-server-close timeout client 20s timeout server 20s timeout connect 4s frontend ft_app bind 10.0.0.100:80 name app default_backend bk_app backend bk_app stick-table type ip size 2 nopurge peers LB stick on dst server s1 10.0.0.1:80 check server s2 10.0.0.2:80 check backup
The stick table will maintain persistence based on the destination IP address (10.0.0.100 in this case):
show table bk_app # table: bk_app, type: ip, size:20480, used:1 0x869154: key=10.0.0.100 use=0 exp=0 server_id=1
With such a configuration, you can trigger a failback by disabling s2 during a few second periods.
LinksSubscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.