Redundant Arrays of Internet Service Providers (RAISP) for 100% Uptime

Problem: Good or Cheap Internet Hosting Companies

Solution: Good and Cheap Internet Hosting Companies

The cost of casual web hosting has dropped through the floor and one can expect it to remain there. If you need to host a dozen domains, downloading about 500 gigabytes of bandwidth each month, storing some hundreds of gigabytes of graphics, handling email accounts, and programming with a full Unix shell including tools like Subversion, Python, and MySQL, then that will set you back about $8 per month. DreamHost’s feature list (sign up here) would be unheard of five or ten years ago. With minor variations, so does everyone else. The catch? These servers are not 100% reliable; more like 98% reliable. I noticed DreamHost had about two or three days of outages or severely degraded performance last year.

Hold it, you think, we handle nearly 100% reliability with unreliable hard drives, unreliable communications channels, and even unreliable employees. Why can’t we handle nearly 100% reliability with unreliable web hosting? What can we do?

Redundant Arrays of Independent Service Providers

Tactic 0 — Sharing the Static Load

Web hosting companies slow down or run out of bandwidth quota far more often than actually crashing. Also, graphic files and other static data account for the bulk of the data served. One common tactic is to serve the the static files from several different domains. One can use an Apache plug-in to rewrite outgoing html, a periodic (cron) program to occasionally rewrite your images directory location, a client-side JavaScript routine to display from whichever server provided the picture fastest, mirroring downloads onto a new server, or several other methods. The effect is that loading a web page may load data from more than one domain.

Only the smaller main page needs to be served from the primary ISP when it is slow. All other data comes from faster, inexpensive ISPs. Similarly, a graphics intensive site, such as Girl Genius, could use this method to serve many terabytes of data for about a hundred dollars per month.

Tactic 1 — Dumb DNS Failover or Load Splitting

Another tactic that commonly works to failover to another site. Using various tricks with DNS or BGP, traffic to a downed site can route to a backup or traffic from different geographies can route to different servers. The site is mirrored, but the the URL remains the same.

Tactic 2 — Failover with Transactions Intact. Distributed ACID Transactions.

The hard part of failing over is making sure the important state is preserved when a site goes down. There are ways to do this, with varying degrees of bandwidth efficiency and latency. Each service would need to notify other servers in some scheme in order keep databases intact. Lots of trade-offs present themselves. It is doable, but requires a fair amount of custom work.

Summary

Getting the high availability out of these redundant ISPs is just work. More complex tactics require more engineering. The business model, as always, is to mask all of the complexity of these tactics so that the customer’s problem just “goes away”.

One could provide a service that set up all the failover options, signed up for the ISPs, wrote the scripts to maintain transaction state for a flat fee. Alternately, one could simply sell themselves as a “high availabilty, high transaction volume” service provider while actually running the service off a number of inexpensive ISPs.

There is money sitting there people. Go pick it up!