Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I would like to fallback to a static webpage if my main web server is down (currently a Rackspace Cloud instance). This would be a sort of worse-case scenario that shouldn't happen, but has before (e.g. Backspace hardware failure). Redundancy of the servers would be an optimal solution, but budget is a concern.. so I'm looking to a low cost autoMatic fallback if something happens to the only server currently

share|improve this question
    
Good question but the problems as I see it is where do you host that static page (you only have one server and it's down) and how do you redirect everyone to it? –  John Gardeniers Apr 12 '11 at 5:57
    
I should've stated that I have a willingness to bring up an additional server for this problem, although I'd like to keep it at a small instance or maybe one of Rackspace's new load balancers (which I need to research a bit on first). My current main server's needs are as Medium instance –  Dolan Antenucci Apr 12 '11 at 16:17
add comment

5 Answers

up vote 6 down vote accepted

Unless you have some sort of second server using a DNS round-robin setup then I'd suggest you speak with rackspace to see if there's a load-balancer in front of your server that can routinely check for service availability and redirect requests elsewhere upon an outage.

Basically there's nothing you can do with a single server as obviously your service outage may be due to total loss of the server, so it needs to be driven externally.

share|improve this answer
1  
FYI for everyone: I spoke with Rackspace, and they do not have a feature to load a static HTML page when all instances are offline. I went ahead and requested this feature, so if others like this idea, please vote it up on Rackspace: feedback.rackspacecloud.com/forums/71021-product-feedback/… I also requested the same feature from AWS, so add your two cents there as well: forums.aws.amazon.com/thread.jspa?threadID=64591 –  Dolan Antenucci Apr 15 '11 at 15:29
add comment

I'm looking to a low cost autoMatic fallback if something happens to the only server

The common way to do that is to:

  • Host a "Sorry we're down for maintenance" page on a cheap shared hosting plan somewhere.

  • Use a DNS provider who also has built-in HTTP health monitoring. During normal operation, the DNS host gives out the IP address of your main (Rackspace) server. If the main server is down, the DNS provider gives out the IP of the cheap shared hosting provider. Examples of such DNS providers are EdgeDirector, DNSMadeSimple, easyDNS.

But, please note, this is a ghetto solution. It more or less works, but DNS caches around the world will cache your IP address, and sometimes will do so for longer than the indicated Time To Live (caching time). Thus the fail over time will be large'ish. More than 1 hour is common regardless of your DNS Time To Live value.

The better way to do this is a HTTP load balancer in front of the server, with a fallback server, as Chopper3 & Scott Forsyth write.

share|improve this answer
add comment

+1 to Chopper3's comment.

If you setup a reverse proxy in front of a pair of cloud servers, you can setup a failback option, aka Sorry Server. Or, if you find that your app layer dies often but your server doesn't, then you can even do this on a single box. (not sure if that cloud instance is site only, or if you have access to the server)

In the Microsoft space, Application Request Routing works perfectly for this. I believe it's Squid in the Linux space.

share|improve this answer
add comment

I've used haproxy on debian to provide failover in front of some windows machines and it works really well. You can even pair these servers using heartbeat and get proxy failover.

share|improve this answer
add comment

The ideal mechanism for this would be SRV resource record support in WWW browsers. WWW server administrators have been calling for SRV resource record support for almost thirteen years because of this. Arranging for fallback when WWW browsers understand SRV resource records is a doddle, since one simply specifies the fallback HTTP server as a lesser priority than the normal HTTP servers, and WWW browsers act accordingly when they cannot reach the normal servers.

Sadly, WWW browsers are the one area where SRV support is lagging, much to the embarrassment and shame of several vendors. So one has to go with more complex mechanisms involving re-routing IP traffic on the fly, as outlined in several other answers here, instead.

share|improve this answer
1  
Proposing a fictnioan lnon working answer is not exactly helping. I take your point, but the poster is not asking for a wishlist for people to change the behavior of browsers. –  TomTom Apr 11 '11 at 16:49
add comment

Your Answer

 
discard

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.