Should You Virtualize vCenter Server (and everything else?)
When concerns are raised around virtualizing vCenter Server, in my experience they usually revolve around either performance and/or out-of-band management. The VROOM! blog at VMware just published a whitepaper that looks closely at vCenter Server performance as a VM versus native (physical) which speaks to these concerns as well as for other workloads.
vCenter Performance as a VM
vCenter Server can use SQL, Oracle or DB2 for a database, and the VROOM! team chose Microsoft SQL Server 2008 for their tests, which might be the most commonly used scenario. In the tests the vCenter server would support a virtual inventory (populated tables) of 8,000 VM’s across 500 hosts and then compare a number of performance metrics between the VM version and the physical/native version running on an HP DL380 G6.
There’s many different tests that were run so I’ll share just a sample of the results that are in the whitepaper. One is the rollup stats function where vCenter takes captured performance metrics from hosts and VM’s and rolls them into different time-based tiers with varying levels of granularity. In other words, this task is essentially an I/O intensive SQL stored procedure:
When you first looked at this graph you were probably trying to answer the question “how much slower is it on a VM?” As you can see, that would have been the wrong question as the virtualized instance was actually faster than native!
This paradigm wouldn’t hold up for all tests however. The stored proceedure for TopN stat collection showed that while the VM was slower (for 3 of 4 tests) it was within 5% of native performance:
For the Purge stored proceedures, the VM was between 10-13% faster than the native instance:
On top of the vCenter specific test the team ran some IOP stress tests using different performance tools, and in each case, the VM was able to sustain greater IOPS than the native system:
This test – which mostly consisted of SQL stored procedures and raw IOPS throughput – showed that at worst a VM is no more than 5% slower than a native system, and depending on the workload in some cases the VM can actually be much faster.
This is consistent with what is taking place in the marketplace where IT organizations are virtualizing Exchange and even mission-critical SAP and Oracle instances.
Two more things I want to discuss. Should we virtualize everything else too? And what about other vCenter specific concerns?
vCenter Server as a VM
If you’re like me, you’re probably no longer terribly concerned about performance after reading the summary of the VROOM! Whitepaper, which leaves us with operational questions. As a general rule it wouldn’t seem right to manage a system from within that same system, but rather you’d opt for an out-of-band approach – which in the case of vCenter would require a physical server which is not dependent on the hypervisor and virtual infrastructure that you are managing.
However the potential failure levels are the OS, the VM (including its disks) and the host hardware. The risks of these can be mitigated by deploying vCenter Server Heartbeat which uses NeverFail technology to replicate the entire vCenter server to a stand-by VM, with its own virtual disks which are kept in sync via NeverFail’s replication engine. If there is a critical issue at either the guest OS, VMDK or host hardware levels, the stand-by VM will kick in and host the vCenter services.
For all these reasons it is actually an official VMware best practice to run vCenter Server as a VM.
Should we just virtualize everything?
Performance varies by application and I/O patterns but for most transactional workloads (SQL, Exchange, etc.) a well tuned vSphere environment will run at least 90% of native and usually closer to 95%. For some workloads the difference is less than 5% and some functions are actually faster on VMWare. For more examples see additional whitepapers from VROOM! on SAP and Sharepoint.
The answer (I think) is “It depends”. It depends on the application and your environment. In most cases, virtualization will be a viable option but curiosity is recommended.
The first reason virtualization is considered is usually for CAPEX (consolidation) benefits. But what if an application is so “big” that you’re looking at a 1-to-1 consolidation ratio? The CAPEX benefit is now gone but what about the OPEX and agility benefits of virtualization? As a VM, your application has new possibilities for backup, replication, HA and much more. And as we’ve seen above, in some cases workloads just simply run better as a VM.
Most workloads can be virtualized but it pays to be curious. Understand your application and your environment and consult with your storage/network teams to verify that your virtualized infrastructure can deliver the performance you need.