{"id":987,"date":"2026-08-27T22:39:27","date_gmt":"2026-08-27T22:39:27","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=987"},"modified":"2026-09-06T22:07:42","modified_gmt":"2026-09-06T22:07:42","slug":"vps-high-availability-keepalived-vrrp-failover","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/vps-high-availability-keepalived-vrrp-failover\/","title":{"rendered":"Building a Two-Node VPS Failover Cluster with Keepalived and VRRP"},"content":{"rendered":"

A single VPS<\/a> is a single point of failure. Hardware failures, host crashes, and network outages all take your application offline. Keepalived uses the Virtual Router Redundancy Protocol (VRRP) to manage a floating IP address that automatically moves between two VPS nodes when one fails. This guide covers the complete setup: installation, configuration, health checks, and production-hardening steps.<\/p>\n

How VRRP Failover Works<\/h2>\n

VRRP elects one node as the MASTER. That node owns the floating IP address and responds to ARP requests for it. The MASTER sends heartbeat advertisements to the BACKUP node every second. If the BACKUP stops receiving those advertisements for three consecutive intervals, it assumes the MASTER is dead, promotes itself, and takes over the floating IP. Clients connect to the floating IP and never need to know which physical node is behind it.<\/p>\n

The key requirements are two VPS instances in the same layer-2 broadcast domain (same data center, same VLAN), and a spare public IP address that can be assigned to either node. Most providers offer floating IPs as an add-on service.<\/p>\n

Step 1: Network Preparation<\/h2>\n

Before installing Keepalived, verify that both VPS nodes can reach each other on their private or public interfaces and that VRRP traffic is allowed.<\/p>\n

# On both nodes, identify the interface for VRRP\nip addr show\n\n# Usually eth0 or ens3. Note the IP address and subnet.\n\n# Test connectivity between nodes\nping -c 3 <other-node-ip>\n\n# Verify VRRP protocol (112) is not blocked\n# On a modern system with nftables:\nsudo nft list ruleset | grep vrrp<\/code><\/pre>\n
If your VPS provider blocks multicast, you will use unicast mode \u2014 covered later in this guide.<\/p>\n
Step 2: Install Keepalived on Both Nodes<\/h2>\n
# Ubuntu\/Debian\nsudo apt update && sudo apt install keepalived -y\n\n# RHEL\/Rocky Linux\nsudo dnf install keepalived -y\n\n# Verify\nkeepalived --version\n# Should show version 2.2.x or later<\/code><\/pre>\n
Step 3: Configure the MASTER Node<\/h2>\n
Create \/etc\/keepalived\/keepalived.conf<\/code> on the primary VPS:<\/p>\n
global_defs {\n    router_id VPS_NODE_1\n    vrrp_skip_check_adv_addr\n    vrrp_garp_master_refresh 60\n}\n\nvrrp_script chk_service {\n    script \"\/etc\/keepalived\/check_service.sh\"\n    interval 2\n    weight -30\n    fall 2\n    rise 2\n}\n\nvrrp_instance VI_1 {\n    state MASTER\n    interface eth0\n    virtual_router_id 51\n    priority 100\n    advert_int 1\n\n    authentication {\n        auth_type PASS\n        auth_pass <generate-a-random-password>\n    }\n\n    virtual_ipaddress {\n        203.0.113.100\/24 dev eth0\n    }\n\n    track_script {\n        chk_service\n    }\n\n    notify_master \"\/etc\/keepalived\/notify.sh MASTER\"\n    notify_backup \"\/etc\/keepalived\/notify.sh BACKUP\"\n    notify_fault  \"\/etc\/keepalived\/notify.sh FAULT\"\n}<\/code><\/pre>\n
Step 4: Configure the BACKUP Node<\/h2>\n
The BACKUP configuration is nearly identical, with a lower priority and BACKUP state:<\/p>\n
global_defs {\n    router_id VPS_NODE_2\n    vrrp_skip_check_adv_addr\n}\n\nvrrp_script chk_service {\n    script \"\/etc\/keepalived\/check_service.sh\"\n    interval 2\n    weight -30\n    fall 2\n    rise 2\n}\n\nvrrp_instance VI_1 {\n    state BACKUP\n    interface eth0\n    virtual_router_id 51\n    priority 50\n    advert_int 1\n\n    authentication {\n        auth_type PASS\n        auth_pass <same-password-as-master>\n    }\n\n    virtual_ipaddress {\n        203.0.113.100\/24 dev eth0\n    }\n\n    track_script {\n        chk_service\n    }\n\n    notify_master \"\/etc\/keepalived\/notify.sh MASTER\"\n    notify_backup \"\/etc\/keepalived\/notify.sh BACKUP\"\n    notify_fault  \"\/etc\/keepalived\/notify.sh FAULT\"\n}<\/code><\/pre>\n
Step 5: Health Check Script<\/h2>\n
The health check script determines whether the node is healthy enough to hold the floating IP. A simple but effective check tests whether your main service is running and responding:<\/p>\n
#!\/bin\/bash\n# \/etc\/keepalived\/check_service.sh\n# Exit 0 = healthy, exit 1 = unhealthy\n\n# Check if nginx is running\nif ! systemctl is-active --quiet nginx; then\n    exit 1\nfi\n\n# Check if nginx responds on localhost\nif ! curl -sf --max-time 2 http:\/\/localhost:80\/health > \/dev\/null 2>&1; then\n    exit 1\nfi\n\nexit 0<\/code><\/pre>\n
sudo chmod +x \/etc\/keepalived\/check_service.sh<\/code><\/pre>\n
The weight of -30 means that when the check fails, the MASTER priority drops from 100 to 70. Since 70 is still above the BACKUP priority of 50, the MASTER retains the VIP unless two checks fail (dropping priority to 40, below the BACKUP). Adjust the weight and BACKUP priority to control how aggressively the cluster fails over.<\/p>\n
Step 6: Notification Script<\/h2>\n
#!\/bin\/bash\n# \/etc\/keepalived\/notify.sh\nSTATE=$1\nNOW=$(date -Iseconds)\n\necho \"[$NOW] Keepalived state changed to: $STATE\" | systemd-cat -t keepalived\n\n# Send to a webhook (Discord, Slack, etc.)\ncurl -s -X POST \"https:\/\/hooks.slack.com\/services\/YOUR\/WEBHOOK\/URL\" \\\n    -H \"Content-Type: application\/json\" \\\n    -d \"{\\\"text\\\":\\\"VPS failover: Node $(hostname) is now $STATE\\\"}\" \\\n    > \/dev\/null 2>&1 || true<\/code><\/pre>\n
sudo chmod +x \/etc\/keepalived\/notify.sh<\/code><\/pre>\n
Step 7: Start and Test the Cluster<\/h2>\n
# Start Keepalived on both nodes\nsudo systemctl enable --now keepalived\n\n# Check status\nsudo systemctl status keepalived\n\n# Verify which node holds the VIP\nip addr show eth0 | grep 203.0.113.100\n\n# Watch the logs during failover\nsudo journalctl -u keepalived -f<\/code><\/pre>\n
Test the failover by stopping Keepalived on the MASTER:<\/p>\n
# On the MASTER: simulate failure\nsudo systemctl stop keepalived\n\n# On the BACKUP: check that the VIP moved\nip addr show eth0 | grep 203.0.113.100\n# Should show the VIP now<\/code><\/pre>\n
When you restart Keepalived on the original MASTER, it reclaims the VIP because its priority is higher.<\/p>\n
Handling VPS Provider Limitations<\/h2>\n