How to Set Up Automatic Failover With Two VPS Instances Using Heartbeat
Automatic failover between two VPS instances using Heartbeat works by running Heartbeat on both servers, having each one continuously check on the other over a dedicated link, and moving a shared virtual IP address, along with the service tied to it, over to the surviving node the moment the primary stops responding.
Two VPS instances set up this way form an active passive cluster. One node handles all real traffic while the second sits ready, and the switch takes seconds instead of the manual recovery time a single server setup requires. Heartbeat isn’t the only tool that does this today, but it remains one of the more direct ways to understand how failover actually works before reaching for something more complex.
What Is Automatic Failover and How Does Heartbeat Work?
Automatic failover is a standby server taking over automatically when the primary server stops responding, without anyone manually redirecting traffic. Heartbeat achieves this by running a small process on both servers that exchange periodic signals over a network link, and triggering a predefined failover action the moment those signals stop arriving.
Understanding high availability architecture
High availability, usually shortened to HA, describes infrastructure designed to keep a service running through individual component failures rather than assuming nothing will ever break.
The math behind uptime targets makes the stakes clear: 99.9% uptime still allows about 8.76 hours of downtime a year, while 99.99% brings that down to roughly 52 minutes.
A two node failover cluster is one layer of an HA strategy, sitting alongside backups, redundant network paths, and in some cases redundant storage, rather than a complete solution on its own.
It’s worth being specific about what a two node cluster does and doesn’t cover. It protects against a single server going down, whether that’s a kernel panic, a hardware fault, or a service that’s crashed and won’t restart on its own.
It does nothing to protect against a bug in the application itself, since that bug simply follows the failover to the second node and fails there too. Knowing that boundary up front avoids treating failover as a substitute for the rest of an HA strategy.
How Heartbeat detects server failures
Heartbeat’s core mechanism is simple by design. Each node sends a periodic signal to the other, at an interval set in configuration, commonly every one or two seconds. If the standby node stops receiving that signal for a defined deadtime, typically ten seconds or so, it concludes the primary is gone and starts the failover process.
That signal can travel over a regular network interface, a dedicated private link between the two servers, or in older setups even a serial cable, specifically to avoid a single network path being the thing that fails and triggers a false alarm. Some configurations add a separate ping node, a third reachable address like the network gateway, so a standby node can tell the difference between the primary actually being down and its own network connection being the real problem.
Active-passive failover explained
In an active passive setup, one node serves all live traffic while the second stays idle but ready, with a synced copy of the application and configuration so it can resume immediately if called on. This is the model Heartbeat is built around, and it avoids a harder problem: two nodes writing to the same data at once.
Active-active clustering, where both nodes serve live traffic simultaneously, solves a different problem and needs a different toolset, usually a load balancer in front of both nodes plus a database or storage layer built for concurrent writes. It offers more capacity, but it also introduces more ways for two nodes to disagree about the current state of things. Most two node Heartbeat deployments stick with active passive specifically because it sidesteps that complexity.
When Heartbeat is the right solution
Heartbeat fits a fairly specific case well: two servers, one virtual IP, and a handful of services that don’t need a complex web of dependencies between them. Worth saying plainly, Heartbeat is an older project, part of the original Linux-HA effort, and a lot of production environments have since moved to Corosync paired with Pacemaker for the same job, or to Keepalived for simpler VRRP based VIP failover without full resource management.
None of that makes Heartbeat the wrong choice today. Plenty of existing production deployments still run on it, the concepts translate directly to its newer replacements, and for a straightforward two node setup it remains one of the most direct ways to actually see failover happen rather than treating it as an abstract diagram.
What Do You Need Before Configuring Automatic Failover Between Two VPS Instances?
Before installing anything, both VPS instances need to run the same operating system and matching software versions, sit on a network that supports a floating virtual IP, and ideally have a private network link between them for heartbeat traffic that’s separate from public facing traffic.
Choosing compatible VPS servers
Match the distribution and version on both nodes closely. A failover that lands traffic on a server running a different PHP or database version than the one it just left causes a second incident on top of the first. Resource allocation should match too, since failover to an underpowered standby node just trades one outage for a slow, half working service. Where possible, ask your provider whether the two VPS instances can sit on different physical host machines, so a single hardware failure can’t take out both nodes in the same cluster at once.
Preparing network and firewall settings
Heartbeat’s node to node traffic needs to pass through the firewall between the two servers, historically over UDP, whether that’s broadcast, multicast, or a direct unicast connection depending on configuration. Restrict that specific traffic to the two node IP addresses rather than opening it broadly, and separately confirm the firewall still allows whatever port the actual clustered service uses, port 80 or 443 for a web server, or 3306 for MySQL, so failover doesn’t succeed technically while the service itself stays unreachable.
Configuring shared services and storage
Since active passive means only one node writes at a time, the data behind the service needs to be kept in sync separately from Heartbeat itself. Heartbeat only handles detecting failure and moving the IP address and service over. It doesn’t replicate a database or sync files on its own.
For a database, that usually means setting up replication ahead of time. For a simpler web application, scheduled or real time file syncing between the two nodes covers it. Disk performance matters here more than it first appears, since a slow sync job can leave the standby node meaningfully behind. Our comparison of NVMe drives against traditional SSDs covers why storage speed affects replication lag specifically.
Planning IP addressing and Virtual IP (VIP)
A Virtual IP is a floating address that isn’t permanently bound to either server’s network interface. Heartbeat assigns it to whichever node is currently active, and clients or DNS records point at that VIP rather than either node’s own address directly.
This is also the point where a plan can quietly fall apart. Not every hosting environment allows an arbitrary secondary or floating IP to be assigned to a VPS without the provider’s cooperation, since it depends on how IP routing is handled at the network layer. Confirm this specifically with a provider before designing the rest of the architecture around it, rather than assuming it will work the way it does on bare metal.
How Do You Configure Two VPS Servers for Automatic Failover Using Heartbeat?
With prerequisites in place, the actual configuration comes down to installing Heartbeat on both nodes, setting up three core configuration files nearly identically on each one, defining the VIP and the service as a managed resource, and then testing the failover deliberately before trusting it with real traffic.
Installing and configuring Heartbeat
On a Debian or Ubuntu based VPS, Heartbeat installs through the standard package manager. On RHEL based distributions, it may require an additional repository, since the project has aged out of some default package sets. Worth checking before assuming it’s a one line install on a newer server image.
sudo apt update sudo apt install heartbeat -y
The main configuration lives under /etc/ha.d/ on both nodes, split across three files that all need to agree with each other: ha.cf for cluster level settings, authkeys for authentication between nodes, and haresources for what actually gets managed.
Defining cluster nodes and resources
The ha.cf file defines the nodes by their hostnames, which need to match the output of the uname -n command exactly on each server, along with the keepalive interval, the deadtime threshold, and how the two nodes talk to each other.
node node1 node node2 keepalive 2 deadtime 10 ucast eth1 192.0.2.11
The authkeys file sets a shared secret both nodes use to authenticate heartbeat traffic to each other, and needs restrictive file permissions since it’s effectively a password.
auth 1 1 sha1 replace-with-a-real-shared-secret
sudo chmod 600 /etc/ha.d/authkeys
The haresources file is where the actual failover behavior gets defined: which node owns the resource group by default, the virtual IP, and the init script for the service that should follow it.
node1 192.0.2.50 apache2
That single line tells Heartbeat that node1 is the preferred owner, 192.0.2.50 is the virtual IP to manage, and the apache2 service should start wherever that IP currently lives.
Configuring service monitoring and failover policies
The setup above, using haresources, is Heartbeat’s simpler original approach, and it mainly answers one question: is the other node reachable. Heartbeat version 2 introduced a cluster resource manager with more granular monitoring, closer to what Pacemaker does today, and it’s worth knowing that distinction exists if a tutorial or an existing server references crm commands rather than a plain haresources file.
Either way, the more important practical addition is a monitoring check that looks past whether the node is up and confirms the actual service is responding, not just that the operating system is reachable over the network. A simple script that checks whether Apache answers a local request, or whether a database accepts a connection, catches a scenario a basic node level heartbeat check would miss entirely: the server is fine, but the service running on it has crashed.
Testing automatic failover before production deployment
Before pointing any real traffic at this setup, confirm the VIP is actually present on the primary node with a basic network interface check, then simulate a failure deliberately, by stopping the Heartbeat service on the primary, rather than waiting for a real outage to be the first test.
sudo ip addr show eth0 sudo service heartbeat stop
Within roughly the deadtime window set in ha.cf, the VIP should appear on the secondary node, and the managed service should be reachable at that same address. Check /var/log/ha-log on both nodes to confirm what actually happened matches what was expected, then bring the primary back and confirm it rejoins cleanly instead of both nodes trying to claim the VIP at once.
What Common High-Availability Mistakes Should You Avoid?
The most common mistakes are skipping split-brain protection, treating the initial setup test as sufficient forever, monitoring only whether a server is reachable instead of whether the actual application works, and never writing down what a human is supposed to do once the automated part of failover has already happened.
Ignoring split-brain protection
Split-brain happens when both nodes believe they’re the active one at the same time, most often during a network partition where the two nodes can’t see each other but are both actually still running and reachable from elsewhere. For a service writing to a database, that scenario can cause two nodes accepting writes independently, which is considerably harder to clean up afterward than a simple outage would have been.
Traditional Heartbeat deployments address this with fencing, sometimes called STONITH, shoot the other node in the head, where a node that should be dead gets forcibly powered off or rebooted before the surviving node takes over completely.
On a VPS, that usually means using a hosting provider’s API to stop or restart an instance rather than a physical power switch. A dedicated private link between nodes, plus a separate ping node used to verify real connectivity, reduces the odds of a false split-brain trigger, though it doesn’t eliminate the risk entirely on its own.
Skipping failover testing
A cluster tested once during setup and never again is a cluster nobody has actually verified lately. Configuration drifts over time: a patch changes a service name, a firewall rule gets tightened, a new interface gets added. Schedule a deliberate failover test periodically, during a planned maintenance window, rather than discovering a broken failover path during a real outage, which is the single worst time to learn a script has a typo in it.
Monitoring only server uptime instead of application health
A server can answer a ping and accept an SSH connection while the actual service it’s supposed to be running has crashed or hung entirely. A Heartbeat configuration that only checks node level reachability won’t catch that failure mode at all, since from the network’s perspective, nothing is wrong. Resource level health checks, actually confirming the application responds correctly, close this specific and fairly common gap.
Failing to document recovery procedures
Automatic failover handles the first few seconds of an incident. It doesn’t handle everything after that. Someone still needs a written procedure for what happens once the primary comes back online: how to safely resync any data that changed during the outage, how to confirm it’s safe to rejoin the cluster, and who needs to be told what happened. Working that out for the first time during an actual incident, under pressure, is how a fast automated recovery turns into a slow manual one.
How Does SkyNetHosting.Net Inc. Support High-Availability VPS Deployments?
SkyNetHosting provides the VPS infrastructure, root access, and support that a two node Heartbeat cluster runs on top of. That said, we don’t manage cluster configuration itself, and specific networking requirements like assignable secondary or floating IP addresses for a virtual IP should be confirmed directly with our team before designing the architecture, since availability of that feature can vary by plan and by location.
Reliable VPS infrastructure for production workloads
Over 20 years in business, we’ve hosted more than 700,000 websites across 25 server locations worldwide. Our VPS plans run on Intel Dual Xeon servers with NVMe storage and LiteSpeed, which gives a failover cluster’s standby node the same performance baseline as the primary instead of a slower fallback that just barely keeps the service alive.
Flexible server configurations for redundancy planning
Root access on our VPS plans means a systems administrator can configure Heartbeat, networking, and firewall rules exactly as the architecture requires, rather than working around a locked down environment. Choosing different data center locations for each of the two nodes is worth discussing directly with our team for setups that need geographic redundancy on top of basic failover, and our dedicated servers are worth considering for a node that needs to be fully isolated from any shared hardware.
Scalable resources for business-critical applications
As load grows, CPU, RAM, or storage can be scaled up on either node without redesigning the cluster from scratch. Our Next-Gen NVMe VPS plans are built around that kind of incremental scaling, which matters for a standby node that needs to keep pace with a primary node’s growing resource needs over time.
Infrastructure suitable for advanced VPS architectures
Our end user support team is available to talk through networking specifics, like secondary IP assignment or firewall configuration between two nodes, before a deployment rather than after something doesn’t work as expected. For architecture planning that goes beyond a standard two node setup, our live sales chat team can walk through what’s actually supported on our network before you commit to a design.
How Can You Build a Reliable High-Availability Strategy Beyond Basic Failover?
Automatic failover solves one specific problem: a single node going down. A complete high availability strategy still needs real backups, ongoing performance monitoring, and a plan for what the infrastructure looks like once traffic outgrows what two nodes can comfortably handle.
Combining failover with backups and disaster recovery
Failover protects against a hardware or software failure on one node. It does nothing to protect against data corruption, a ransomware event, or someone accidentally dropping a database table, since a corrupted or deleted dataset gets faithfully replicated to the standby node just as quickly as a healthy one would. Our reseller features page outlines the backup baseline we build into our own infrastructure, and any HA architecture should treat backups as a completely separate layer of protection, not something failover already covers.
Monitoring application performance continuously
Binary health checks answer whether a service is up or down, but they miss gradual degradation, rising response times, growing error rates, or a resource that’s slowly running out of headroom. Continuous monitoring catches that slide before it becomes a full outage that Heartbeat then has to react to.
Notification delivery matters here too. Alerts that depend on outbound email need that email to actually arrive, which is part of why we pair our infrastructure with tools like MailChannels for reliable outbound mail authentication.
Planning future scalability with redundant infrastructure
A two node active passive cluster has a ceiling. Once traffic genuinely needs more than one active node can handle, the architecture needs to evolve toward a load balanced active-active setup or a larger cluster, which is a bigger design conversation than adding a second server. Our live sales chat team can help map out what that next stage looks like, and our Next-Gen NVMe VPS plans give the current setup room to grow before that conversation becomes urgent.
