If you ask web and infrastructure hosting clients what they consider the most important factors in their choice of service provider, they answer performance and availability. They want fast reliable services, and they want predictably available services — services that don’t go down or become unreachable.
Given the nature of technology, it’s impossible to guarantee that any particular server or network connection will always be available. In fact, on a long enough timescale, the chances of something failing approach 100%; or to put it another way: for a large enough deployment of IT hardware, there will be frequent failures of at least one component.
We can’t rely on the availability of any particular part of the system; we have to design the system itself to be tolerant of the failure of its components — and that means building in redundancy.
Take the simplest scenario: an application serving resources from a single server. If something goes wrong with the server or the network connection, everything hosted on that server become unavailable.
The obvious step is to make the application redundant. We put the files and applications on a couple of different servers on different network connections, so that if one of them fails, the other can take up the slack. But we also need to introduce a third component to direct requests to the redundant servers: a load balancer.
Load balancers distribute requests to two or more servers. The major benefit is that we can easily scale the network behind the load balancer by simply more servers. A corollary benefit is that a failure of any one or more of the servers behind the load balancers doesn’t lead to the application becoming unavailable — so long as there are enough redundant servers to handle the load, the load balancer can ignore the failed server and route requests to its redundant peers.
This is a typical scenario and it’s the way that many high-traffic application and web hosting networks are configured. But it’s not yet good enough to be called a highly available system.
When we introduced the load balancer, we created a system of redundant servers, but the load balancer itself remains a single point of failure. Load balancers run on ordinary servers and they’re just as prone to failure as any other part of the system.
The solution should be fairly obvious at this point: we use redundant load balancers. By having another load balancer waiting in the wings ready to step in if anything goes awry with the primary, the system has no single point of failure and we’re justified in calling it high availability hosting.
Of course, the examples we’ve discussed here are simplified. Real-world high availability setups are considerably more complex.
InterWorx is capable of supporting high availability load balancing at a fraction of the price of other enterprise load balancing solutions.