When implementing HAProxy for load balancing, achieving true high availability requires more than just a single instance. The core challenge emerges when your domain (e.g., abcd.com) needs to point to multiple HAProxy servers while DNS typically resolves to a single IP address.

For budget-conscious implementations, DNS Round Robin provides a simple yet effective approach:

abcd.com.    IN  A   192.168.1.100
abcd.com.    IN  A   192.168.1.101

This configuration spreads requests across both IPs, though it's not true load balancing as DNS has no health checking capability.

Here's a basic HAProxy configuration for two backend servers with health checks:

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

defaults
    log global
    mode http
    option httplog
    option dontlognull
    timeout connect 5000
    timeout client 50000
    timeout server 50000

frontend http_front
    bind *:80
    default_backend http_back

backend http_back
    balance roundrobin
    option httpchk GET /health
    server web1 192.168.1.200:80 check
    server web2 192.168.1.201:80 check backup

For more robust failover, combine HAProxy with Keepalived to create a virtual IP (VIP):

vrrp_script chk_haproxy {
    script "killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    interface eth0
    state MASTER
    virtual_router_id 51
    priority 101
    virtual_ipaddress {
        192.168.1.50
    }
    track_script {
        chk_haproxy
    }
}

For cloud environments, consider these options:

• AWS: Elastic Load Balancer with multiple AZs
• Google Cloud: Global Load Balancing
• Azure: Traffic Manager with priority routing

Implement proper monitoring to ensure failover works:

backend stats
    stats enable
    stats uri /haproxy?stats
    stats realm Strictly\ Private
    stats auth admin:password
    stats refresh 10s

Remember to test your failover configuration thoroughly before deploying to production.

Traditional DNS resolution presents a fundamental limitation for HA setups - it typically points to a single IP address. When building a highly available HAProxy infrastructure, we need multiple entry points. Here's how to solve this without expensive hardware load balancers.

1. Round-Robin DNS (The Simple Approach)

Most DNS servers support multiple A records:

example.com.    IN  A  192.0.2.1
example.com.    IN  A  192.0.2.2

Clients will receive responses in rotating order. While not true failover, it provides basic distribution.

2. DNS Failover with Health Checks

Services like AWS Route 53 (paid) or free alternatives like:

• DNSMadeEasy (free tier available)
• ClouDNS (free plan)
• DigitalOcean DNS (with API automation)

These can automatically remove unhealthy endpoints.

The most robust solution combines:

# keepalived.conf example
vrrp_script chk_haproxy {
    script "killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    interface eth0
    state MASTER
    virtual_router_id 51
    priority 101
    virtual_ipaddress {
        192.0.2.100
    }
    track_script {
        chk_haproxy
    }
}

AWS Approach:

# Using Elastic IPs with Auto Scaling
resource "aws_eip" "haproxy" {
  count = 2
  vpc   = true
}

resource "aws_autoscaling_group" "haproxy" {
  health_check_type = "ELB"
  # ... other configs
}

Google Cloud Solution:

gcloud compute addresses create haproxy-vip \
    --region=us-central1 \
    --network-tier=PREMIUM

Essential checks for your failover system:

#!/bin/bash
# Basic health check script
if curl -Is http://localhost:8080/health | grep "200 OK"; then
    exit 0
else
    systemctl restart haproxy
    exit 1
fi

For budget-conscious setups:

• Use floating IPs with heartbeat
• Implement DNS TTL tuning (30-60 seconds)
• Consider Cloudflare Load Balancing (free tier)