One of inherent difficulties with failover for Web Hosting companies operating on different networks is limitations imposed by DNS caching system.

As DNS records are passed from original DNS servers (i.e., ns1/ns2.your-domain.com), they are cached or stored at several different ISP’s along way. Which is why it takes a while for a newly registered domain name to resolve to its IP address.

Each DNS record has a TTL (time to live) setting assigned. By manipulating this value, it is possible to alter how long that particular IP address/ DNS record combo is stored. If your site is on 2 different servers with 2 different IP addresses, you could set ‘time to live’ with a value of, say, 2 minutes.

The failover software would check server availability by “pinging” web server every few minutes to determine whether it’s IP address is responding appropriately. (perhaps by looking for a particular text string in a web page).

If a failure is detected, then software would pull non-working web server IP address out of list of IP addresses assigned to your web site’s domain name. If/when your web server IP comes back online it would be restored to list.

With a TTL setting of 2 minutes, theoretically, your web site should be down for just 2 minutes, while switching DNS information to other web server.

The problem with this scenario, is that, while some ISP’s caching might respond to such low figures, other ISP’s may decide to ignore,(to save on bandwidth utilization), any TTL’s below a certain value, say, 60 minutes. So it is entirely possible that some of your visitors would see your websites and for others, your site would be down for 1 hour or more, even though one of your servers was operating perfectly.

Static non interactive web sites are great candidates for server clustering, but wicket becomes a bit sticky for dynamically generated sites. Most database application software in general, although having some replication capabilities, are not happy with multiple server master/slave relationships and real time updating between servers. The issue can become very problematic if your site requires frequent updates.

Then there is problem of how to keep your websites synchronized. Unix/Linux servers have a built in synchronizing software tool called rsync. You can also automate synchronizing process by setting up a cron job to run periodically. DNS caching and synchronizing issues can be so problematic so as to nullify advantages of server clustering. For example, a cron job to synchronize your servers every few minutes might very well use up your server capacity.

Your customers will also have to contend with their desktop email client software having dual email addresses for each email account on each web server. e.g. info@server1.net, info@server2.net.

It is important to realize that DNS operates by default in a round robin manner, so that, if you have same web site on 2 separate servers, it is very likely that server 1 will get 50% of all web traffic.

Now, this is important for a number of reasons, but one of principal reasons to keep this in mind, is that, you will not be able to effectively keep a ”back-up” site (as some providers would have you believe) which will only be used when primary server goes down. For e.g. a site saying” we’re sorry our main server is down but you may contact us at: www.yourdomain2.com.

On a final note, hardware based load balancing solutions tend to be quite expensive and also introduce a potential single point of failure into system, load balancer itself. There is a very prominent Data Center that began offering load balanced hosting solutions, where load balancer itself failed on several occasions, although web servers were operating perfectly. The net effect to public however, was that sites were unavailable.

Reasonable cost effective software based solutions may be obtained as a service model or by purchasing software yourself. Zoneedit is an example of a service model, and Simplefailover is an example of a software based model which maybe purchased on a server license basis.

In conclusion, at this point in time, there are several limiting factors to successfully implementing a “true” high availability multiple server web hosting system. Depending on your clientele and nature of their web sites,this may indeed be a very viable alternative. For others, simply setting up a server with high quality components, redundant RAID hard drives and a good supply of server spare parts may be best way to ensure high availability.

4)Fees. I'd rather pay a little more to get all features than fight it out with a sub par web hosting company who I can't reach if my site goes down. I've found decent web hosting for as cheap as $4 per month but generally pay around $15 per month if I want all bells and whistles that I'll need to host a larger site. A lot of people worry about hosting fees, but I've had experience that I generally get what I pay for. Finally, I'd look carefully at web hosting company's refund policy. Most offer a full refund if you aren't happy with your service. If you are paying for a full year of web hosting up front, you might want to examine company's refund policy in detail.

You may reproduce this article on your website. We would appreciate a link back to our site which has Vioxx articles and personal injury resources. This article may not be altered and links should be kept live. Thanks.