Fault tolerance in virtualised environments

Trevor Pott
Infrastructure Support Engineer

Fault tolerance and high availability were once distinct concepts which have blurred into one single goal. Two decades ago high availability was a pipe dream for even the largest corporations. Basic fault tolerance was itself something that required massive planning. Resumption of service or data availability was limited to the speed at which a system could be rebuilt or a backup restored.

As the ability to back up systems and data became commonplace, the ability to recover from failure quickly became the pressing demand. RAID allowed (with varying degrees of success) disk failures without service interruption. ECC and chipkill were born to help us survive RAM glitches. Technologies to make networks robust proliferated enough to require their own article. Eventually some bright spark lit upon the idea of SANs, rendering entire servers nothing but disposable nodes and finally turning the entire network into one big computer.

Virtualisation, when handled properly, can lead to some pretty amazing uptimes. Let us mentally design a very small and basic high availability system using VMs. Take two SANs, each kept in sync with the other and visible to the rest of the network as “a single SAN.” The SANs themselves are attached to network via redundant network interfaces to redundant switches. Three server nodes (A, B and C) are also attached to these switches with their own redundant interfaces. If SAN A has an accident, SAN B takes up the slack. If a switch goes down, or the boss trips over a network cable, the network deals with it.

Populate Servers A and B with virtual machines configured in a cluster, and leave Server C as an idle spare. Go kill Server A with an axe. The virtual machine on Server B senses the loss of its clustered partner, and continues on with its duties. Remap the virtual machine that used to be on Server A over to Server C and bring it online. The cluster members sense each other, sync up, and are fault tolerant once more.

This basic example can be scaled as appropriate, and is something that hardware vendors are eagerly waiting to sell you right now. You can add even more layers of redundancy and there are entire symposiums dedicated to exactly that. Add neat virtualisation tricks like the ability to “VMotion” a live VM from one node to another and even routine maintenance doesn’t have to affect availability.

Those happy thoughts aside, in the real world of High Availability cost is asymptotic to perfect uptime. The closer you attempt to get to it, the more resources you will be forced to expend. Though we now have tools that can allow getting within a fraction of a percentage of perfect uptime, not even a company with Google’s resources has yet achieved it.

Martin Atherton
Research Director, Freeform Dynamics Ltd

There are rarely any ‘single’ answers to problems we face in IT. The question here is a good example. A way to think about protecting the operational performance of a virtualised server could be to take examples from different parts of its lifecycle. A good place to start when thinking about desirable attributes of any system is… at the start. Design them in. From a cost efficiency point of view in terms of avoiding redesigns, rewrites and re-engineering — basically getting it right first time — it makes perfect sense.

However, we know this doesn’t usually happen. For numerous reasons, but primarily due to the fragmented nature of the management of the steps involved from requirements to technical specification through testing and operational rollout, areas such as operational resiliency are often short-changed, as many operational IT staff will attest to.

Another side of the coin is to consider the context in which the virtualised server will be used in. For example, the services being supported by a particular server should define or at least guide the specific fault tolerances and other protective measures required in the first place. These contextual requirements are much more relevant to the business — and thus what it pays for — than taking a purely ‘technical’ approach to this area.

As always though, the answer in practice is likely to lie in a combination of approaches, not one or the other — or indeed any other options that exist — in isolation. It’s important to appreciate the strengths, weaknesses and risks of different approaches and how they complement or amplify any specific attributes in each other.

If you think you've got what it takes to contribute to our experts sessions, answer the question above and email it to: philip.mitchell (at) theregister.com.