Chasing virtualisation nirvana

In the first three instalments of this series of Industry Insights on how to make the most of a virtualised IT environment, I looked at how to stop virtual machine (VM) sprawl, allocate resources efficiently and plan future capacity expansion - all in a context where many of the rules have changed. In this final Industry Insight, I will look at how to put it all together to move beyond the final hurdle: virtualising not just peripheral functions, but the tier 1 applications that make a business tick.

A phased approach to virtualisation is very common. With such a potentially disruptive new technology to master, most CIOs choose to start with what's easy - the 'low-hanging fruit' of corporate jargon. When starting with non-essential file and print servers, there is an opportunity to learn new tools, approaches and methods thoroughly before tackling the serious business of the SAP or core ERP system servers.

At the end of phase one, however, what many CIOs and IT managers face is a complete stall. They've reached 40%-50% virtualisation, but are facing problems that make them reluctant to commit to the next phase. Sometimes these involve unreliable backups; sometimes phase one has consumed so many resources that the budget is gone, but the expected benefits haven't materialised. In either case, virtualisation isn't making good on its promises.

This kind of stall can be a nightmare for a CIO, who secured the budget for virtualisation and has bought all the licences on the basis of ROI calculations that are looking increasingly impossible to achieve.

If this description sounds familiar, don't panic! There is a way out.

The first step is to bring that sprawling, resource-guzzling virtual environment under control. Get rid of VM sprawl, zombie machines and long-ignored project servers that are being kept on life support "just in case". Then take a cool, hard look at the resource allocations and change them to fit the company's needs better. In most cases, these two steps should free up significant resources and start to make ROI calculations look a great deal healthier.

Concerns about the reliability of backups can also be dealt with relatively easily. The first step is to accept that retrofitting the company's existing backup solution, designed for a conventional hardware environment, is just not going to work. Just as trying to remove a screw using a hammer will probably cause more problems than it solves, so will using a traditional agent-based backup solution in an virtualised IT environment. Backups will take too long and they won't be reliable. Who'd trust their tier 1 apps with that?

To overcome stall and complete the virtualisation process by virtualising tier 1 apps, what is needed is a set of tools specifically designed to make it easy to manage virtual environments. Backups must be tested, reliable and quick - and to really make the grade, they should deliver much better recovery point and recovery time objectives than anything that could be hoped for in a physical environment.

A backup solution should also offer item-level restore ability for everything from a single e-mail to a single database entry. Some backup applications don't support item-level recovery in a physical environment, especially highly customised apps or those developed in-house. If the environment is virtualised, however, a plan can be made.

Take a cool, hard look at the resource allocations and change them to fit the company's needs better.

This is particularly important in large and complex IT shops, where high levels of customisation and in-house development are common. In these cases, if a company needs to restore an entire application environment just to recover one file, the time, effort and money involved are probably not worth it. To make matters worse, the restore might not even work.

A tool that provides a business-view layer over the IT infrastructure is also essential. For example, when an SQL server goes down, it's important to be able to see which applications and departments are affected. Each department may have its own SQL instance running on the database, and if the VM in question is having performance issues, they'll all feel it. But, which problem should be dealt with first? The production environment, for example, will normally take precedence over HR - unless it's a payroll day, in which case HR will be bumped up the priority list.

All this is only possible if the company knows which virtual machines are carrying which workloads, and how that maps onto the structure of the business. The business won't care that cluster seven in DC2 has a performance issue - it cares that a specific business unit like the call centre is running slowly. In a virtual environment, where all resources are shared, knowing how to pinpoint affected areas of the business is critical.

With the right tools in place, the company will be able to cut through all the levels of abstraction - from the application through to the operating system, down to the virtual environment and then the bare metal. Once it has achieved this, getting beyond that halfway virtualisation stall should be well within reach.