Virtualization is often a game of numbers. As you choose virtual hardware, you have to consider some important...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
metrics, such as the number of virtual machines (VMs) that reside on a host or logical unit number (LUN).
If you haven't determined what these numbers should look like in your environment, your infrastructure will likely suffer from poor performance. This tip highlights key virtual hardware statistics to consider, which include consolidation ratios and virtual CPU counts. As you design and configure a VMware vSphere infrastructure, these performance metrics help prevent an infrastructure from becoming resource starved.
Virtual hardware consolidation ratios
When it comes to virtualization numbers, the most common questions pertain to the number of VMs on a host -- otherwise known as the consolidation ratio, or VM-to-host ratio. Unfortunately, there are no easy answers. It depends on many variables, including the physical host configuration and VM resource requirements. If a large host runs light VM workloads, it's possible to achieve a 60-to-1 VM-to-host ratio, for example. But a small host with heavy VM workloads may require an 8-to-1 ratio for solid performance.
There are two ways to attain denser consolidation ratios:
- Scaling up. With this method, you either add resources to an existing physical server or add a new, more powerful host -- such as a large, eight-socket server that supports 48 cores and 512 GB of memory.
- Scaling out. This approach adds smaller, physical machines -- such as a two-socket server that supports eight cores and 128 GB of memory -- so you can spread the resource load among several machines.
Each method has pros and cons. By scaling up, you buy fewer physical servers, but it also increases the risk that a greater number of VMs will crash during a server failure. When scaling out, on the other hand, you buy and manage more physical servers. But a scale-out architecture provides more flexible cluster design, and with this design, a server failure affects fewer VMs.
Many people choose to scale out, and a good sweet spot between larger and smaller servers is two- or four-socket servers with four to six cores and 256 GB of memory. Midrange servers, such as Hewlett-Packard Co.'s DL380 or DL580 models, provide good scalability at a reasonable cost.
With medium VM workloads, two-socket, midrange servers can achieve a 16-to-1 consolidation ratio, and a four-socket server can reach 32 to 1. Again, these virtual hardware statistics are dependent on workloads.
Remember to count virtual CPUs
The VM-to-host ratio is a general performance measurement. Because VMs can use multiple virtual CPUs (vCPUs), the ratio of vCPUs to physical CPUs (pCPUs) is a more granular virtual hardware measurement. A conservative ratio is typically 4 to 1.
A host with 12 CPU cores, for example, might support 48 vCPUs. With light CPU workloads, it's possible to reach an 8-to-1 vCPU-to-pCPU ratio, but only a 2-to-1 ratio under heavy workloads.
The number of multiple vCPUs (or vSMP) assigned to VMs also affects the vCPU-to-pCPU ratio. It's easier for the VMware CPU scheduler to allocate CPU times for single vCPU VMs. The total number of VMs on a host will decrease if there are several vSMP VMs -- especially ones with four or more vCPUs.
Think of the big picture
Virtualization streamlines resources use, and advanced features like Distributed Resource Scheduler (DRS) and Distributed Power Management (DPM balance hosts resources and reduce wasted activities. But that doesn't mean your hosts should run at nearly 100% utilization.
VMware's High Availability feature must have sufficient spare capacity for other hosts to absorb the resource load from failed-over VMs. Depending on your workloads and how many simultaneous host failures you want to protect against, you may want your hosts to run at 70% utilization.
LUNs and shared-storage performance
The number of VMs running on a shared storage data store (or LUN) is another important metric. Too many VMs on a single LUN can create metadata locking issues (SCSI reservations).
The optimal number of VMs residing on a LUN is dependent on several variables, but the following suggestions should provide a baseline:
- Average number of VMs per LUN: 14 to 16
- For light-I/O workloads, such as application servers: more than 100 VMs per LUN
- For disk I/O-intensive applications: 8 to 10 VMs per LUN
- For low- to medium-intensity workloads: 20 to 22 VMs per LUN
In some cases, you can put more VMs on a LUN -- particularly virtual desktop infrastructure implementations that have low disk-I/O requirements.
Your storage subsystem also plays an important role in this equation. Having more disk spindles in RAID groups and larger caches facilitate more VMs.
Avoid 100% virtualization
With vSphere's maturity and improvements, it's possible to virtualize just about any workload. A 100% virtualized data center is certainly achievable, but that doesn't mean you should do it.
Virtual environments are complex, and their dependencies and failures can have a major effect. Domain Name Servers, Dynamic Host Configuration Protocol and Active Directory are critical services for data center servers and the clients that connect to them. The loss of a major component, such as a storage area network or network switch, can make a large part of your virtual environment unavailable.
Critical services that run on physical servers have minimal dependencies. So they are less affected by an environmental failure. Physical servers are also quicker to bring up after an event. As a result, virtualizing 90% to 95% of your environment might be enough.
Certainly, virtualization is about the numbers, but don't be too aggressive with your virtual hardware goals. Remember: Data center performance and uptime are the most important figures. To achieve solid virtual hardware numbers without sacrificing performance and availability, you need to understand the effects of your architecture and configuration decisions.
About the expert
Eric Siebert is a 25-year IT veteran with experience in programming, networking, telecom and systems administration. He is a guru-status moderator on the VMware community VMTN forums and maintains vSphere-land.com, a VMware information site.