The basic premise of server consolidation is to leverage unused computing power. Instead of operating 10 servers at 5% utilization, operate one server -- hosting those 10 virtual machines (VMs) -- at 50% utilization. The secret to successful server consolidation is to ensure that there are adequate resources to support all VMs that will reside on the server. If the same 10 physical servers are running at an average of 15% utilization, those virtualized workloads must be spread across two or more physical servers. If they're not, then the performance of those VMs -- and the user experience -- will suffer.
Prior to consolidation, each workload must be evaluated to ensure that it meets CPU, memory (RAM), I/O, storage and network connectivity (bandwidth) requirements. Those factors are then combined to yield the total approximate needs for the virtualized server. "Calculate your needs based on [the needs of each application] and leave resources for the host server [hypervisor/OS]," said Brien Posey, an independent technology consultant located in Rock Hill, S.C.
There is no single recipe for sizing a physical server, and there are countless possible exceptions. When calculating memory needs, for example, you don't need to add up all requirements for every OS because the virtualized server will only use one OS.
Similarly, you can get by with half a CPU for every workload. As a rule, don't use more than two VMs per CPU. A single NIC may supply enough bandwidth for several workloads. Generally, what's enough depends on the nature and criticality of the applications you plan to consolidate.
Server consolidation must make sense. There's no point in trying to over-reduce the number of physical servers for its own sake. There is nothing wrong with virtualizing a single application on a single server and foregoing consolidation, simply focus on migration.
Storage is one resource area that is frequently overlooked. Using a single huge disk drive on a virtualized machine isn't an option, Posey noted. Storage I/O demands from multiple VMs can seriously compromise performance. Instead, Posey recommends using a striped RAID array or a basic SAN with a separate LUN for each VM.
Determine and track VM needs
The actual number of VMs that can be hosted on a single physical server is largely subjective. In most cases, practical resource limitations of the physical server -- available CPU, RAM and other computing resources -- will halt VM growth long before any hard limits of the virtualization platform are reached. But the complexity and requirements of the VMs themselves govern this.
Backup needs can greatly limit the number of VMs on a single server. VMs must still be protected, and traditional backups are notoriously I/O intensive. Backing up multiple VMs simultaneously can cripple the virtual server.
"You need to start thinking about changing the way you do things," said Pierre Dorion, data center practice director at Long View Systems, an IT solutions and services company in Denver. For example, you may want to phase out traditional backups in favor of virtual machine migration tools, such as VMware Inc.'s VMotion.
One way to determine and track resource needs is to gather data using performance and capacity planning tools, such as IBM's Tivoli Monitoring Express, HP's Diagnostics software, and virtualization tools like VMware's Capacity Planner. Microsoft's Assessment and Planning Toolkit can help administrators assess infrastructures and recommend a variety of projects. It's important to collect data over time and during peak use times.
Finally, address the issue of VM assignments -- putting the right VMs on the right physical servers. Just because a server can be virtualized doesn't mean that it should be virtualized. Some applications, such as databases, can tax server resources and might run better unconsolidated and kept as the only virtual machine on a mission-critical server. Conversely, some applications that would not ordinarily coexist on the same physical server, such as Microsoft Office SharePoint Server 2007 and Outlook Web Access, could easily reside on the same physical system in separate VMs.
Complementary applications that would typically communicate with one another across the network may actually perform better when virtualized alongside each other on one server. This can eliminate a slower network link and allow applications to communicate internally across the server's backplane.
It's not enough to simply create new VMs and combine them based solely on available server resources. Administrators must understand how virtual machines interoperate and use physical resources before allocating them throughout the enterprise.