Introduction to Cross-Cloud High Availability

In the modern digital landscape, downtime is more than just a technical inconvenience; it is a financial and reputational hazard. While standard high availability (HA) setups usually involve clustering virtual private servers (VPS) within a single data center or a single cloud provider's regions, true resilience demands more. Relying on a single infrastructure vendor introduces a critical single point of failure (SPOF). If that specific provider experiences a routing catastrophic failure, data center outage, or administrative lockdown, your entire cluster goes offline.

To mitigate this risk, enterprise architects implement cross-cloud high availability. This strategy involves distributing workloads across entirely different infrastructure vendors (for example, AWS and DigitalOcean, or Linode and Vultr). However, achieving seamless IP failover between disparate networks presents a unique challenge, as traditional Virtual Router Redundancy Protocol (VRRP) setups rely on a shared Layer 2 broadcast domain. This guide provides a comprehensive, step-by-step technical blueprint for manually configuring a "Failover IP" mechanism using Keepalived across two distinct VPS providers to establish robust, cross-cloud redundancy.

The Core Challenge: Bridging Disparate Networks

Before diving into the implementation, it is crucial to understand the underlying networking constraints. Keepalived fundamentally utilizes the VRRP protocol, which broadcasts heartbeats and manipulates IP addresses within a local area network (LAN). In a standard environment, when the master node fails, the backup node detects the lack of heartbeats and claims the Virtual IP (VIP) via Gratuitous ARP (GARP).

When your nodes reside in completely different cloud ecosystems, they cannot communicate via Layer 2 broadcasts. Their primary communication happens over Layer 3 (the public Internet). Therefore, a standard VIP cannot simply "float" across providers natively. To overcome this limitation, we must shift from relying on hardware-level ARP broadcasting to utilizing the API-driven routing manipulation provided by cloud platforms, or orchestrating an external routing switch. In this manual architectural blueprint, we will use Keepalived's powerful state-transition scripting engine to trigger external API calls or routing changes, forcing traffic redirection to the secondary provider upon failure detection.

Prerequisites and Architectural Topology

To follow this advanced guide, ensure you have the following components prepared:

Master VPS (Provider A): A Linux instance (e.g., Ubuntu 22.04 LTS) hosted with your primary vendor.
Backup VPS (Provider B): A Linux instance hosted with a completely independent secondary vendor.
A Floating/Failover IP or DNS-Based Traffic Switch: Depending on your cloud vendors, this can be a third-party Anycast IP, a highly responsive DNS service with a low Time-To-Live (TTL) and API access, or a BGP-routed IP space if you manage independent subnets. For the purpose of general applicability, we will focus on a Scripted API Switch model where traffic is routed via an external API gateway or dynamic DNS mapping.
Root or Sudo Access: Required on both server instances to modify network interfaces and system configurations.

Conceptual Workflow

Keepalived monitors the health of the application and the connection state between the Master (Provider A) and Backup (Provider B) over a secure Layer 3 tunnel (such as wireguard or a standard GRE tunnel) or via explicit public IP polling.
If the Master node fails, the Backup node detects the heartbeat timeout.
The Backup node transitions to the MASTER state and executes a custom shell script.
The script sends an authenticated API request to the routing layer (or DNS provider) to instantly point the production traffic to the Backup VPS's public IP address.

Step 1: Establishing a Secure Heartbeat Channel

Because VRRP packets cannot securely travel across the public Internet unprotected, we must establish a secure tunnel between our two distinct VPS instances. We will use a point-to-point tunnel to securely pass Keepalived heartbeats.

On the Master Server, edit your network configuration or initialize a secure tunnel interface. For instance, using a standard GRE or WireGuard tunnel ensures that both nodes can ping each other on a private subnet (e.g., 10.0.0.0/30). Let us assume the Master tunnel IP is 10.0.0.1 and the Backup tunnel IP is 10.0.0.2.

Note: Ensure that your cloud firewalls (Security Groups) explicitly allow VRRP traffic (IP Protocol 112) or UDP encapsulation traffic over the custom tunnel ports between the two specific public IPs of your servers.

Step 2: Installing and Configuring Keepalived on the Master Node

Install Keepalived on both instances using the native package manager. For Debian/Ubuntu-based systems, execute the following commands:

sudo apt update
sudo apt install -y keepalived

Once installed, navigate to the configuration directory and create the primary configuration file on the Master VPS:

sudo nano /etc/keepalived/keepalived.conf

Insert the following configuration structure, tailored for cross-cloud manual transitions:

vrrp_script chk_application {
    script "/usr/local/bin/check_app_health.sh"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface tun0
    virtual_router_id 51
    priority 101
    advert_int 1
    
    authentication {
        auth_type PASS
        auth_pass Secr3tTr4ff1c
    }
    
    track_script {
        chk_application
    }
    
    notify_master "/usr/local/bin/failover_trigger.sh MASTER"
    notify_backup "/usr/local/bin/failover_trigger.sh BACKUP"
    notify_fault "/usr/local/bin/failover_trigger.sh FAULT"
}

Step 3: Configuring Keepalived on the Backup Node

Now, mirror the installation on the Backup VPS at Provider B. Open the configuration file:

sudo nano /etc/keepalived/keepalived.conf

Populate it with the matching parameters, making sure to adjust the state to BACKUP and lowering the priority score:

vrrp_script chk_application {
    script "/usr/local/bin/check_app_health.sh"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state BACKUP
    interface tun0
    virtual_router_id 51
    priority 100
    advert_int 1
    
    authentication {
        auth_type PASS
        auth_pass Secr3tTr4ff1c
    }
    
    track_script {
        chk_application
    }
    
    notify_master "/usr/local/bin/failover_trigger.sh MASTER"
    notify_backup "/usr/local/bin/failover_trigger.sh BACKUP"
    notify_fault "/usr/local/bin/failover_trigger.sh FAULT"
}

Step 4: Developing the Automation and Failover Scripts

The magic of cross-provider failover lies within the notification scripts. When Keepalived changes its state, it executes the failover_trigger.sh script with the corresponding argument.

The Health Check Script

First, create a lightweight script to verify that your critical application service (e.g., Nginx, Apache, or a custom API) is actively running. Save this as /usr/local/bin/check_app_health.sh:

#!/bin/bash
# Verify if the web service is responding locally
curl --silent --fail http://localhost:80/health_check_url > /dev/null
exit $?

Make sure to grant execution permissions: sudo chmod +x /usr/local/bin/check_app_health.sh.

The State Transition Trigger Script

Next, create the script that interacts with your multi-cloud routing layer or DNS API. Save this file as /usr/local/bin/failover_trigger.sh on both servers:

#!/bin/bash

STATE=$1
LOG_FILE="/var/log/keepalived_failover.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

echo "[$DATE] Keepalived transitioned to state: $STATE" >> $LOG_FILE

case $STATE in
    "MASTER")
        echo "[$DATE] Initiating manual IP/Routing switch to this node..." >> $LOG_FILE
        # INSERT PROVIDER API CALL HERE
        # Example: Updating an Anycast IP target via cURL
        # curl -X POST -H "Authorization: Bearer $API_TOKEN" [https://api.provider.com/v1/failover-ip/switch](https://api.provider.com/v1/failover-ip/switch) --data '{"target_ip": "YOUR_CURRENT_PUBLIC_IP"}'
        ;;
    "BACKUP")
        echo "[$DATE] Entering standby mode." >> $LOG_FILE
        ;;
    "FAULT")
        echo "[$DATE] Application or interface fault detected." >> $LOG_FILE
        ;;
    *)
        echo "[$DATE] Unknown state parameter received." >> $LOG_FILE
        ;;
esac

Ensure that this script is also fully executable: sudo chmod +x /usr/local/bin/failover_trigger.sh.

Step 5: Initialization and Rigorous Verification

With configurations and orchestration scripts firmly in place, initialize the Keepalived service on both nodes, starting with the Master:

sudo systemctl daemon-reload
sudo systemctl start keepalived
sudo systemctl enable keepalived

To ensure your high availability setup works seamlessly during an actual crisis, execute a simulated failover test. Monitor the logs on the backup server using the following command:

tail -f /var/log/keepalived_failover.log

Now, forcefully stop the Keepalived daemon or the web service on the Master VPS to simulate an infrastructure crash:

# On Master VPS
sudo systemctl stop keepalived

Within seconds, the Backup node's log file should indicate a state shift from BACKUP to MASTER, followed by a log line confirming that the external API script was executed to update the traffic routing path. Verify your application availability globally to ensure the transition succeeded without user disruption.

Conclusion

Setting up a manual Failover IP mechanism via Keepalived across two distinct cloud ecosystems requires careful cross-layer planning, but the architectural payoff is unparalleled. By bridging separate cloud topologies through secure Layer 3 heartbeats and automated API triggers, you liberate your production infrastructure from vendor lock-in and create a resilient environment capable of withstanding massive, provider-wide outages. Maintain a continuous integration pipeline for your application data syncing across these providers, and you will achieve a hardened, enterprise-grade high availability platform.

Cross-Cloud High Availability: A Guide to Manual Failover IP Configuration Using Keepalived Across Different VPS Providers