⚡ ~/naveed Interview Prep
⚡ Portfolio Home 👤 About Naveed Bio & Credentials 📫 Contact Naveed Get In Touch ✍️ Engineering Blog Deep Dives 🎯 Interview Hub 1,000+ Scenarios ☸️ Kubernetes Mastery Hub 24 Modules 🎮 DevOps Arcade & Quizzes Subnet Blitz ⚡ 🗺️ DevOps Roadmaps PDFs & Guides 🤖 Morpheus Analysis AI Quant ↗ 🛠️ Developer Tools Utilities 🧪 Labs & Experiments 📄 Interactive CV & Certs 🔗 All Links & Socials ⚡ Join The Dispatch (Weekly SRE Newsletter) →
← Back to All Networking & Cloud DNS Interview Questions Scenario 58 of 58 in Networking & Cloud DNS
Senior DevOps / SRE Networking Load Balancing & Traffic Diagnostics High Availability
🎯 Target Role / Context: Senior DevOps / SRE High Availability & Fault Tolerance Interview Scenario

Q: Q: How do you design an active-passive HAProxy architecture using Keepalived VRRP, and how do you prevent split-brain during network partitions?

Practice HAProxy interview questions: design an active-passive load balancer cluster with Keepalived VRRP, floating VIPs, health tracking, and split-brain guards.

#HAProxy #Keepalived #VRRP #High Availability #Networking #Failover
🎙️ Candidate Opening & Architectural Context
"When addressing haproxy interview questions about enterprise high availability, I present a battle-tested active-passive cluster powered by Keepalived VRRP. A single load balancer is an intolerable single point of failure (SPOF). I demonstrate how floating Virtual IP (VIP) failover works, how kernel sysctl parameters permit non-local binding, and how custom health check scripts prevent dual-master split-brain scenarios during network partitions."
Advertisement
⚡ Recommended Practice Lab

Want to master this scenario in a live sandbox? KodeKloud's Istio Service Mesh & Advanced Kubernetes Networking Course covers this exact problem with hands-on terminal drills.

🛠️ Production Runbook & Step-by-Step Resolution

Direct Answer: When addressing haproxy interview questions about enterprise high availability, I present a battle-tested active-passive cluster powered by Keepalived VRRP. A single load balancer is an intolerable single point of failure (SPOF). I demonstrate how floating Virtual IP (VIP) failover works, how kernel sysctl parameters permit non-local binding, and how custom health check scripts prevent dual-master split-brain scenarios during network partitions.

1

Enable Kernel Non-Local IP Binding for Seamless Floating VIP Assignment

On the passive standby node, the floating Virtual IP does not exist on any physical network interface until failover triggers. By default, Linux kernels forbid binding daemons to non-existent IP addresses. We must enable net.ipv4.ip_nonlocal_bind=1 so HAProxy can initialize its listening sockets on the VIP even while in standby mode.

# Persist non-local IP binding on both primary and secondary nodes
echo 'net.ipv4.ip_nonlocal_bind = 1' | sudo tee -a /etc/sysctl.d/99-haproxy-vip.conf
sudo sysctl --system | grep ip_nonlocal_bind
2

Configure Keepalived VRRP Instances with Priority Weighting

I configure Keepalived on both nodes under the same virtual router ID (vrid). The primary node starts with priority 101, and the backup node runs at priority 100. Unicast VRRP packets are routed directly between the nodes rather than relying on unreliable broadcast/multicast packets in cloud or enterprise VLAN environments.

# /etc/keepalived/keepalived.conf (Primary Node)
vrrp_script check_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight 2
    fall 2
    rise 2
}

vrrp_instance VI_STATIC {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    
    unicast_src_ip 10.0.1.10
    unicast_peer {
        10.0.1.11
    }
    
    virtual_ipaddress {
        10.0.1.50/24 dev eth0
    }
    
    track_script {
        check_haproxy
    }
}
Advertisement
3

Implement Resilient Health Checking Scripts to Avoid Flapping Failovers

A basic process check with killall -0 only detects crashed processes; it cannot tell if HAProxy is unresponsive or socket-starved. I create a hardened tracking script that verifies both process execution and local loopback HTTP status endpoint responsiveness before adjusting VRRP weights.

#!/usr/bin/env bash
# /usr/local/bin/check_haproxy_health.sh
set -euo pipefail

# 1. Verify process PID exists
killall -0 haproxy || exit 1

# 2. Verify local health endpoint responds with HTTP 200 within 1 second
curl -sf -o /dev/null --max-time 1 http://127.0.0.1:8404/healthz || exit 1

exit 0
4

Prevent Split-Brain Dual-Master Disasters During Network Partitions

If the heartbeat link between nodes drops while both nodes are operational, both nodes declare themselves MASTER and bind the same Virtual IP, causing intermittent ARP poisoning and packet corruption across the subnet. I mitigate split-brain by configuring independent heartbeat networks, quorum fencing, and dual-interface tracking.

# Check current ARP cache and active VIP binding on the network
ip addr show dev eth0 | grep 10.0.1.50
arptables -L -n

# In Keepalived, configure notify_fault scripts to release VIP and notify alerting systems
# notify_fault "/usr/local/bin/vrrp_fault_alert.sh"
💡 The Senior SRE Gold Nugget (Key Architectural Takeaway)
"In haproxy interview questions, highlight that high availability pairs HAProxy with Keepalived VRRP. The non-local IP binding sysctl (ip_nonlocal_bind) enables cold-standby daemon initialization, while unicast VRRP and multi-tier health scripts prevent split-brain packet corruption."
⚡ 60-Second Elevator Pitch Talking Points
  • A single HAProxy node is an architectural single point of failure; we eliminate this by deploying active-passive pairs managed by Keepalived VRRP.
  • Both nodes run HAProxy concurrently with net.ipv4.ip_nonlocal_bind=1 enabled so the standby daemon binds the floating VIP before taking active ownership.
  • Keepalived constantly tracks HAProxy process and socket health via lightweight tracking scripts, shifting priority weights if the primary daemon degrades.
  • To avoid split-brain across virtualized subnets, we use unicast peer addresses instead of multicast and configure aggressive rise/fall thresholds to avoid flapping.
⛔ Critical Candidate Mistakes to Avoid in This Scenario

Senior hiring managers and bar raisers evaluate how you prioritize during outages. Avoid these common anti-patterns:

  1. Forgetting to enable net.ipv4.ip_nonlocal_bind=1 in sysctl Without this setting, the standby HAProxy daemon will fail to start during system boot because it cannot bind a VIP that belongs to the active node.
  2. Relying on multicast VRRP on cloud platforms like AWS or Azure Major public cloud hypervisors drop multicast and broadcast packets; you must configure explicit unicast_peer blocks or use cloud-native virtual load balancers.
  3. Using a naive ping check instead of functional application layer verification A ping check confirms the host OS is online but fails to notice when the HAProxy process has deadlocked or run out of file descriptors.
Advertisement
Want more Networking & Cloud DNS scenarios?
Explore our complete collection of scenario-based Networking & Cloud DNS interview runbooks.
Browse All Networking & Cloud DNS Questions →