Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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 are looking for a Debian Squeeze, opensource multi site "wan fail over" solution (apologize if a post for this exists - didn't see one). Multi site is key....

In a Small Office context, we want to place two servers at two different sites. Each server would have it's own Public WAN static IP address.

E.g., and Site2:

We are planning to use DRDB, pacemaker and corosycn to keep the two boxes in sync.

Q: is there a way if the connection at site one goes down, that immediate fail over take place to site two?

The pacemaker examples we've seen seem to be configured for a single site (we may not have understood that the examples were multi site).

Is this what VIP is for? If we had a 3rd server at a 3rd site (e.g., a cloud server) with a public WAN static IP, and used it for a VIP, would we be on the right track? I.e., all traffic is aimed at this 3rd server which routes it to the public IP of Site1, and if Site1 goes down, this 3rd server routes all traffic to Site2?


share|improve this question
A "wan fail over" makes it sounds like you want redundnant links between the offices but the rest of your question leads to a service you want to replicate. Could you flesh out what your doing a bit more. Where are the clients for these services coming from? What services are you failing over between sites? Have the services been designed to be replicated/failed over? Can you get the business to define what 'immediate' really means, i.e. how long can you stand for it to be down. – Matt Feb 14 '13 at 23:44
Thanks for the response...we are providing virtual desktops over the Internet to external custs, so want high availability for those. We're "early on" but have set up some servers where we think have DRBD working on a LAN; we think next steps include getting the virtual desktop services we need to be "high available" to work in BRBD, then add in pacemaker/corosync....and finally figure out the "WAN failover issue", possibly using PowerDNS/PowerAdmin at 3rd site (or would pacemaker do this?). Please let me know if that's not the right level of info? PS we're doing this on a short budget... – Seattle Feb 15 '13 at 13:04

DNS failover

    /     \
 SiteA   SiteB

Most DNS failover TTL's will be set to 30 seconds, allowing about a maximum 60 seconds outage for a sites IP address to stop being advertised to clients after the time it takes for your service check to mark a site "bad". Most DNS caches will obey TTLs, some don't. Some clients can cache IPs too (java!).

Load Balancer

    /    \  
 SiteA  SiteB

The "VIP" option you alluded to in your post of a single cloud load balancer(vip) does allow you to fail sites over more quickly as you can move traffic from site to site as soon as the service is marked bad. That does add a single point of failure though.

Load Balancers + DNS failover

    /     \
   LB     LB
   |  \ /  |
   |   X   |
   |  / \  |
 SiteA   SiteB

If you have two cloud based load balancers (preferably in different sites, or different providers) and front them with DNS failover then you can move clients from SiteX to SiteN as soon as a failure is detected and also be protected in the off chance a load balancer goes down, which should be a lot less frequent than a virtual desktop service hosted over your office's net links.

There are other ways to achieve failover at the network level with BGP routing and BGP anycast, if you control your own IP ranges and have BGP routers. That sounds a bit above where you are aiming at?

For any failover to work well you need a thorough service check for the virtual desktop service to confirm a site is in fact working. I'm not sure how far you can check a virtual desktop beyond authentication unless you write a really nifty client. Maybe you could provide system metrics from your sites as well that might help indicate a site has "gone bad". These could probably come from the clustering you're doing inside a site as that will have to have a good idea about the status of the service.

Also, with multiple sites some consideration needs to go to where clients end up connecting to. Can they switch back and forth as often as they like. Is it better if they stay on the one path. Is active/passive a better way to go? Is geographic location a big factor? These are all very specific to what you're implementing. Always test what you think is best, and always test every failure scenario you can think of.

share|improve this answer
Wow - what a fantastic write up! Will need to read/digest (great summary of things we've been reading). Thanks! One Q: yes, early on BGP may be beyond what we'll do as we're trying to figure out/test all of this. Can you suggest an alternative toolset or approach, possibly PowerDNS/PowerAdmin? Or something else? – Seattle Feb 16 '13 at 12:53
The only "complete" DNS (failover) solution I have used in earnest is F5's Global Traffic Manager, otherwise they have been custom solutions configuring Bind or Djbdns as required. I haven't used PowerDNS and can't see specific support for failover but it allows anything for a backend so you can make it respond with whatever you need with a bit of smarts. In the default config you could update the mysql backend from your service monitoring scripts. There are dns service providers too. – Matt Feb 16 '13 at 14:15

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.