vTeardown

Business Continuity is a Highly Valued Virtualization Function

Among the primary reasons why companies virtualize their applications is to improve business continuity – or in other words to make all applications as available as possible, as often as possible. Actually, we are now seeing a lot of customers value this virtualization capability even more than server consolidation. With vSphere, there are several established methods available to improve application availability; it all depends on the type of failure you want to protect against and the amount of downtime one can tolerate. For this post however, we’re going to examine VMware vSphere High Availability and a very helpful, vSphere exclusive, feature that enables an organization to prioritize which VMs restart first in the event of a hardware failure – pretty interesting stuff.

VMware HA Enables Unheard of Levels of Application Availability

As we all probably know by now, VMware HA has been a widely adopted solution to minimize application downtime in case of server failure. Once HA has been enabled on a vSphere cluster (directly from vSphere Client with just a few clicks), vSphere will continuously monitor the status of all VMs running in a specific cluster. Should a host failure occur, vSphere will then automatically restart the affected VMs on a different host, greatly reducing application Recovery Time Objective (RTO). With vSphere 4 we have extended the capabilities of VMware HA to enable automatic VM restart in the case of a guest operating system failure. So now, even if the hardware is fine, but a single virtual machine’s operating system fails, that application will restart. That is pretty good!

vSphere Exclusive Feature – Prioritize which Applications Restart First

That’s a cool advancement, but in terms of HA triggered by a server failure, we still felt that we needed to do better, because all applications on a host aren’t equal are they? The ability to prioritize mission critical apps to recover first, before tier-2 applications, could result in a lot of benefits to an organization. That ability could save a lot of money, could limit revenue loss, and could even protect a company’s reputation. Consequently, a primary objective of HA should be to further minimize the cost of downtime by prioritizing the restart of mission critical applications. Well, vSphere 4 has a solution for that – with vSphere, one can easily configure a failover restart prioritization level of a VM. It only takes a mouse click – or three.

By setting the failover restart priority level of a VM to “High”, vSphere will make sure the VM is restarted before those with a “Medium” or “Low” priority. Even better, the failover restart prioritization is a VM attribute, independent from the host, and will follow the VM even if you migrate it or restart it on a different host in the cluster.

This Feature Does Not Exist in Hyper-V R2

Even with Windows Server 2008 R2, it appears that Hyper-V won’t provide failover restart prioritization capabilities. Yes, with Microsoft Clustering Services, one could make a VM highly available – but when it comes to prioritizing VMs for restart, the user is really left with three insufficient alternatives:

1) Forget about automated VM restart and go back to manual restart – sounds fun…others have already written on this limitation

2) Spend time and effort creating and maintaining scripts for prioritized restart – this option sounds like a management nightmare considering that scripts would have to be updated every time a new VM is created or migrated to a different host

3) Run fewer apps per server so that you reduce the risk of extending the RTO of mission critical apps – but that increases the overall TCO of your virtualization infrastructure as you are then using more physical servers.

Or you could challenge Murphy’s Law and hope for the best. Yes, I am biased, but I think you’d agree that 1) The ability to prioritize VM restart in the event of failure is an important, valuable capability and 2) A single click in the vSphere console to prioritize VM restart beats any of these Hyper-V alternatives.

Can Mythbusters themselves be busted? Is something like that even possible?

I think it was always theoretically possible, like time travel or the yeti, but I don’t think there has even been documented proof before – until now.  As Stu has written on vinternals – and there is no sense in me trying to recreate the details here, he’s written an excellent article – a Microsoft technical case study, internally written and available on TechNet, summarizes the experience a Microsoft IT department had when deploying Hyper-V.  It is surprising that the Microsoft paper ever saw the light of day, as it essentially lays out a strong case for why, contrary to Microsoft’s ubiquitous marketing claims, Hyper-V 1) is not equivalent to a VMware solution and 2) is not ready for use in a production datacenter – at any cost – for any workload.  Is Hyper-V the new Corvair? The Microsoft case study actually validates a number of the lab findings we have made available on Why Choose VMware and “un-validates” much of Microsoft’s own virtualization marketing and myth-busting rhetoric.

The external validation is nice, we just never thought it would come from Microsoft

I do have to say that it is nice to have some external validation of what we’ve found to be true in our lab analyses and of what many of our customers have told us regarding Hyper-V.  At times we feel like we may be buried under a tidal wave of Microsoft marketing spend. (They do have a cool robot though!) We just never thought that Microsoft itself would be our ally in refuting Microsoft’s marketing rhetoric and in getting to a more accurate, fact-based comparison of currently available products.  Thanks guys!  Myth-busters-busted.

The low consolidation ratios make Hyper-V even more expensive than we had thought

And one more thing, as this paper relates to our Cost Per Application calculator, and our findings that due to ESX’s ability to drive a higher consolidation of workloads on a single host, VI3 is actually less expensive than Microsoft’s Hyper-V offering – with only 1-2 additional virtual machines per host.  Microsoft’s paper states that when using Hyper-V in production, on a server with 8-12 processors and 32 GB of RAM, they were able to run only 5-6 virtual machines.  In our calculator, we had assumed Microsoft Hyper-V could support a pretty standard 1-1.5 machines per core, or 12 virtual machines on that type of server.  Well, we gave Hyper-V too much credit.  With such limited consolidation on Hyper-V hosts, Hyper-V is way more expensive than even our top of the line VMware VI3 Enterprise edition than we had originally calculated.  And VI3 is a proven solution with a lot more functionality.   Perhaps we should rerun the numbers? Perhaps it doesn’t matter?

One last thing

Sorry, one additional item, before all you conspiracy theorists out there start speculating.  We did not infiltrate Microsoft’s IT department and brainwash or bribe someone to write and publish this paper…so I hope we can put an end to that theory right now. Although I did hear that Oliver Stone is now working on a screenplay.