Server consolidation: a tech guide

Roger Howorth ZDNet.co.uk

Published: 07 May 2009

• 
• 
• 
• 
• 

Server consolidation is a high priority for many IT managers, and there are several ways to do it. One approach is to take a physical server and convert it — OS, applications and all — into a virtual machine (VM). Server virtualisation tools are then used to host multiple virtual servers on a smaller number of physical servers. A few years ago, VMware was the only supplier of virtualisation tools for x86-based servers. More recently, Microsoft and Citrix have both joined the fray with excellent virtualisation products (Hyper-V and XenServer respectively), while Red Hat is expected to launch a new platform later this year.

Alternatively, some IT managers take the software from existing tower or rack-mounted servers and run it on more compact blade servers.

More space, reduced power consumption
Whichever option you choose, server consolidation helps to reduce power consumption and lower the cost of datacentre air conditioning. It also provides an easy option for dealing with old server hardware that's running an important piece of software. Automatic migration tools can be used to move software onto VMs or blades without having to reinstall everything from scratch.

As well as freeing up much-needed space in your datacentre, server consolidation also reduces the number of LAN ports that are needed. And if your servers are connected to a Storage Area Network (SAN), it will reduce the number of SAN ports too. As a result, server consolidation should help to delay the purchase of new LAN and SAN adapters and switching kit.

Managing a consolidated infrastructure
Although space creation and power consumption are often the driving force behind server consolidation projects, once a consolidated infrastructure is up and running, IT managers often find that the biggest benefits come from better management, backup and disaster recovery options. It's usually much easier to move software from one virtual server or blade to another than it is using traditional server hardware.

Virtual environments have other valuable features, too. For example, snapshot-based backups enable an entire server to be backed up without any downtime. Whereas snapshots are normally only available to physical servers that also use SAN storage, it's easy to make snapshot backups of VMs without the need for SAN-based storage.

Live migration enables VMs to be moved from one host server to another without any downtime. Live migration is a planned feature of Microsoft Hyper-V 2008 R2, which is expected to be launched later this spring. The open-source Xen virtualisation tools and VMware ESX Server already have this feature. It allows server hardware to be maintained or replaced simply by migrating VMs to another host before working on the original. As there's no downtime, server maintenance can be done during normal working hours. Live migration can also be used to manage the performance of VMs — by moving a VM from a normal host to one with extra-fast CPUs, for example.

Virtualisation also makes it very easy to make a backup of a VM and restore the backup to another host. This kind of flexibility is extremely difficult to achieve with traditional servers because hardware differences between the physical servers are usually too difficult to overcome. However, restoring backups of VMs in this way forms the basis of many low-cost disaster recovery strategies.

Finally, both virtualised and blade-based systems make it quick and easy to deploy new server software. With virtual environments, rather than needing to go through a hardware acquisition cycle, creating a new VM is simply a matter of a few mouse clicks in the virtual platform's management console.

How to consolidate
Before embarking on a server consolidation project, the first step is to examine the existing workloads running in your environment. Make a list of all your server hardware, and look at the CPU and RAM utilisation of each server, preferably over a period of at least a week. You'll probably find that many servers use less than 10 percent of the CPU and RAM in the host server. These systems are ripe for virtualisation. In contrast, a busy email or database server may frequently use all the RAM or CPU at its disposal. Although it may still be virtualised, some IT managers prefer to consolidate this type of workload onto a dedicated blade server.

Whether you opt for virtualisation or blades, the next step is to select suitable new server hardware. HP, IBM and Dell are the big names in blade servers, and each vendor offers a slightly different mix of management tools and hardware characteristics.

Beware of vendor lock-in, because you can't really mix and match blades from various vendors, so once you invest with one blade vendor you'll find it easier to stick with them. Likewise, although it's easy to migrate a VM between hosts running the same hypervisor, it's trickier to move between the different hypervisors.

Before selecting host servers for virtual environments you will probably want to benchmark several candidates to see how many VMs server each can host. Intel and VMware both have benchmark tools to help with this. You'll also need to decide whether you want a small number of four-socket servers, each fitted with lots of RAM and I/O devices, or whether you prefer a larger number of lower-specification servers, such as dual-socket rack-mounted servers or blade systems.

Instruction set compatibility is another important factor when choosing host hardware for your virtual servers. This is because live migration is only possible between host servers that have similar CPUs from the same manufacturer. If you plan on repurposing a few old servers to host your VMs, you may find that live migration won't work with your hardware.

To use server virtualisation, you'll also need to choose one or more virtualisation software vendors. Factors that might affect your decision include the range of hardware and operating systems supported by their products, and the range of features offered by the management suites. For example, some products may be better than others at setting and managing service levels for the VMs under their control.

The next step is to plan your migration strategy. Whichever options you take, you'll need to decide if you want to do this yourself or use third-party consultants or contractors. You'll also need to buy special tools to migrate software from physical servers to virtual ones. Tools to move VMs back to physical servers may also be necessary: the application may fail to perform as expected in a virtual environment or you may need to call in technical support from a third-party application vendor, as some refuse to support their products running in a virtual environment.

Finally it's essential to educate and retrain staff so they can get the best from the new infrastructure. Although people that use or manage applications will probably not notice the switch to blades or virtual environments, people that manage server hardware will need retraining so they can access the consoles and work with blade systems and virtual hardware.

 

• 
• 
• 
• 

• Most Recent
• Most Popular