Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have implemented a failover soultion on Linux using DRBD and Heartbeat and it works great, Now we have a change in requirement that states the Nodes replicating are in different subnets, we will not have a common virtual IP that we use when the machines are on the same subnet.

When we have nodes in different subnets what would be the best way to failover?.

share|improve this question
up vote 3 down vote accepted

There are several approaches to implementing failover between subnets; but there are a lot of variants depending on the exact requirements. Regardless of specifics, what you seem to be trying to achieve is route health injection; that is, advertising a route to a specific service (usually via a VIP) based on the health/availability of that service.

Some ways of implementing this include:

3rd party appliances

e.g. Citrix Netscaler or F5 BIGIP. These appliances generally offer very rich feature sets. In addition to your high-availability requirement, they also provide load-balancing between multiple servers, as well as some advanced health check features for well-known applications protocols (e.g. HTTP, HTTPS, DNS etc). They are, however, very expensive.

Host-based routing daemons

e.g. Quagga or XORP. With a little bit of scripting, these daemons can provide a subset of the functionality of the appliances above, without the associated costs. If you configure your network to accept routing dynamic routing updates from your hosts, and put in some scripts that periodically check the health of your services, this will allow you to conditionally advertise a route to a VIP from each of your real servers. Some considerations here:

  • you will need to have adminisrative rights on your network hardware;
  • you will need controls in place to ensure that your host-based routing process does not any impact to your network infrastructure, e.g. through misconfiguration.

Some clarification of the requirements/constraints in your situation might be helpful. Some questions:

  • Do you require active/active, or active/standby failover?
  • Are these applications internet facing, or for internal use only?
  • Do you require automatic failover?
  • Is load-balancing a requirement?
  • Would you prefer an anycast solution, where users connect to the 'closest' instance of a service?
  • Do your back-end servers need to see client connections originating from their actual source IP address, or will a proxied solution be acceptable?
share|improve this answer

This mailing list page talks about using RIP routing advertisements to allow servers to answer to a common IP address even though they are on different subnets. You'll need some router magic to make it work.

ALternatively if you don't mind a little downtime you could use DNS entries with short TTLs. Just updater the DNS record to change servers.

share|improve this answer
Just thought it worth linking these two previous questions:…… – gyaresu May 12 '09 at 12:38

We were able to achieve this by making our linux servers act as a router (using zebra + ospf)
Here are some details if anyone is interested
-DRBD replicating using a different subnet advertised on lo:1 interface on both machines
-have Virtual IP configured on lo:2 that fails over
- For heartbeat use unicast for talking to the other node

share|improve this answer

Last time I had this requirement, I used one IP per machine, tied to the machine and a "service IP" (this is the IP clients have configured as the IP of the server). I used ultramonkey to monitor service and handle the failover, Zebra to interact with the routing protocol (injecting /32 routes for all service IPs; we had multiple services that needed moving, the primary host for each service was based on physical proximity to the clients).

The servers were located in London, UK and somewhere in California, US (no, I can't remember exactly where, I never lay my eyes on them), with GRE tunnels providing inter-network connectivity (both sites had independent Internet access).

We didn't use continous replication of data, however, as the service would work just fine with data replication happening every hour, or so (it was primarily read, not much write). The replication was done from "physical IP" to "physical IP".

share|improve this answer

Everything you need and more, - I won't start writing a book on it all, to help you out, but start with the FAQ and man pages and you'll be amazed once you see that it has everything you need in this case and more, much more.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.