Let us take a closer look at active passive failover haproxy With the support of our server management support services at Bobcares we will give you a complete note on it.

Active Passive Failover Haproxy

Active-Passive Failover: The use of redundant systems in a failover arrangement to ensure high availability for key applications or services.

Active-passive failover is a strategy that we can use in the context of HAProxy. It is a prominent open-source load balancer and proxy server, to ensure that if one HAProxy instance fails, another instance may take over its job and continue to serve traffic.

Two or more HAProxy instances are running in parallel in an active-passive failover setup. The active node is in charge of processing all incoming traffic and forwarding it to the necessary backend servers. The other instances, referred to as passive nodes, are not actively processing traffic but are ready to take over if the active node fails.

Setup Active Passive Failover Haproxy

To establish active-passive failover in HAProxy, we must configure the active and passive nodes to communicate and monitor each other’s status. This is often accomplished through the use of a combination of health checks, heartbeat messages, and failover scripts.

When the active node fails, the passive node(s) notice it and one of them is promoted to become the new active node. This is referred to as failover, and it often entails adjusting network settings and updating DNS records to guarantee that all traffic is now sent to the new active node.

It is critical in an active-passive failover arrangement to keep the passive nodes in sync with the active node to minimize data loss or inconsistencies when a failover occurs. This can be accomplished through the use of shared storage or by duplicating data between nodes using a tool like rsync or DRBD.

Overall, active-passive failover is a useful technique for ensuring high availability and avoiding downtime in critical systems. However, it’s important to note that failover can still result in some disruption to the service, especially if the failover process takes a long time or if there are issues with the passive node(s) becoming fully operational.

Diagram

Let’s utilize a single HAProxy with two servers, s1 and s2.

When the system boots, s1 is the master and s2 is the backup:

1. ————-
2. |  HAProxy  |
3. ————-
4. |         `
5. |active    ` backup
6. |           `
7. ——       ——
8. | s1 |       | s2 |
9. ——       ——

Configuration: Automatic failover and failback

The setup below instructs HAProxy to utilize s1 when it is available and to fail over to s2 if it is not:

1. defaults
2. mode http
3. option http-server-close
4. timeout client 20s
5. timeout server 20s
6. timeout connect 4s
7. frontend ft_app
8. bind 10.0.0.100:80 name app
9. default_backend bk_app
10. backend bk_app
11. server s1 10.0.0.1:80 check
12. server s2 10.0.0.2:80 check backup

The most crucial term in the above sentence is “backup” on the s2 configuration line.

However, as soon as s1, done restoring, all traffic will fail back to it. This is fine for online apps but not for active/passive systems.

Automatic failover without failback

The setup below instructs HAProxy to utilize s1 when it is available and to fail over to s2 if it is not.

Dues to the stick table, no it wont execute failback automatically once a failover happens:

In this case, the stick table will retain persistence based on the target IP address (10.0.0.100):

1. show table bk_app
2. # table: bk_app, type: ip, size:20480, used:1
3. 0x869154: key=10.0.0.100 use=0 exp=0 server_id=1

With this configuration, we may force a fail back by deactivating s2 for a few seconds.

[Need assistance with similar queries? We are here to help]

Conclusion

To sum up we have now seen more about the active-passive failover haproxy. With the support of our server management support services at Bobcares we have gone through all of the steps in the process.