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
-
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 GardeniersApr 12, 2011 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 AntenucciApr 12, 2011 at 16:17
5 Answers
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.
-
1FYI 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 Apr 15, 2011 at 15:29
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.
+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.
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.
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.
-
1Proposing 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.– TomTomApr 11, 2011 at 16:49
-
This is still interesting to know, that there is something that was designed to specifically fix this problem– Alex FJun 9, 2018 at 5:27