Uptime in the Real World: Real World Expectations vs Real Business Needs

In doing a needs analysis for a new customer, I came across an interesting problem: how much down time is too much down time? In a perfect world, the answer would be "none at all", but in a world where large ISP's suffer explosive down time, and where hurricanes, tornadoes, and the fits and spells of a turbulent world lay waste the best laid plans, what should the business owner expect?

The answer is that it's an asymptotic curve, where you never reach 100% uptime, and as you approach it, the cost skyrockets.

Take for example one single link in the delicate chain of data delivery between your web site and your customer: the web server. For a web server (such as Apache) to run correctly, it relies on a host of lower level components working correctly in order to do its job.

Server hardware, network connectivity on both sides of the connection (both at the data center and on your customers' computer), network speed, etc. all have to be working in order for Apache to do its job.

The difficulty and complexity of hardening these myriad interconnected components goes up sharply as you try to address each issue.

But what if we approached the problem a different way? What if we had an actual budget driving our decisions for finding vendors and configuring our setup? What would be a relatively easy, stable, and reliable setup?

The answer to these questions depend on your specific business needs and your budget. Personal web sites have no need of any fancy setups, just about any reputable shared host will meet your needs. Fortune 500 companies with large budgets simply throw money at the problem and "over-solve" the problem.

This post deals with the needs of a small business web site, where budget is a serious concern, but where down time really hurts the bottom line.

The Goods

One solution is to have two hosting accounts on two different vendors:

Primary Account - enough space and bandwidth to handle your day-to-day needs

Secondary Account - this is a second hosting account in a different location, either physically separate in the same datacenter, or with another provider in a completely different place.

And you have your domain with the DNS hosted with your domain provider. eNom, for example, provides full DNS control at no extra charge (we are an eNom reseller).

Finally, you set your DNS to point to your primary account. If anything goes wrong with the primary, you can quickly and easily forward traffic to the secondary account (either by setting a secondary nameserver to point to the second account, or by simply forwarding the traffic to an IP manually).

Of course automatic is better, but not having to wait for the switch to propagate is very good.

The Problem

The trick is making sure that both your primary and backup site are up to date. If you have a completely static site, this is easy: just upload changes to both locations when updating the site.

Dynamic, database-driven sites are a little trickier. CMS's such as Drupal, Joomla, and the like could have multiple database changes per second, and even hundreds on a busy site.

The bad news is that it's not realistic to keep the two databases synchronized up to the second.

The good news is that you don't have to. Most sites, although dynamic, don't actually change in critical ways so often. The average site gets content updates, then stays the same with the exception of logging and statistics (which, in the context of an emergency, we can afford to lose).

So it's a simple matter (to people like me, anyway) of setting up an automatic script that will update the data from the primary to the secondary.

The frequency of the updates, the thus the cost of bandwidth between the accounts, depends on how much data you can stand to lose. If you update your content every couple days, daily synchs are safe. If you run an e-commerce site that gets 10 orders an hour, then updating every few minutes is probably best (but again this will increase the cost of your accounts).

Conclusion

Like everything, it's all about reasoned, informed balance. A simple, real-world solution to a complicated problem instead of over-engineering a solution that is expensive and doesn't actually work is NOT the way to go.