We need to choice between Hyper-V and regular cluster technologies. What is the advantage and disadvantage of these approaches?


We have to physical servers and want to build reliably solution using cluster approach. We need to clustering our application and DB (MS SQL). We know that we can use:

  • Regular Windows Cluster Service. Application and DB will be migrating from one node to other.
  • Hyper-V Failover Cluster. Virtual machine will be migrating from one node to other.
  • Combined variant. DB mirroring for MS SQL and Hyper-V for our application.

We need to make a choice between this approach. So we need to know advantage and disadvantage of these approaches?

  • This is a bit of a non-question. What are you clustering? There's no such thing as a "regular cluster" as clustering is such a generic term it has no real meaning. Give us two clear examples, for example "A Hyper-V High Availability cluster with a SAN running a single instance of SQL Server that will be migrated to a secondary machine in the event of a failure", and "An SQL Server Cluster using Microsoft Clustering Service and SQL's native cluster, where the databases are stored on a replicated SAN". And that's just one common example. We need way more info. Jun 21 '11 at 0:21
  • are you trying to say hyper-v r2 the "product" vs regular windows 2008 r2 server running hyper-v in a clustered configuration. Cuz if so then there is no difference technically. If thats not your question then this is a non-question..
    – tony roth
    Jun 21 '11 at 1:39
  • I updated the question and tried to be more specific.
    – Sasha
    Jun 21 '11 at 16:04

Clustering the hosts and clustering the guests provide similar benefits. If one physical machine fails, another will provide a platform for getting your workload running again.

The main differences come in how the clusters are managed, and in what, exactly, happens at the moment of failover.

Host clustering:

  • You can configure groups of hosts that can run any VM.
  • Host failure results in the VM rebooting, hosted on a different physical machine.
  • Shared storage is required
  • The management of the cluster is at the host layer, and quite homogenous. All workloads are given high-availability properties.
  • Intra-cluster communication happens very reliably. It can't be interrupted because a VM didn't get CPU time or access to I/O.
  • Live migration depends on host clustering, so you probably are already on a path to enabling it.

Guest clustering:

  • Each individual VM needs to be configured as part of a cluster.
  • Each cluster is specific to the type of workload. If the workload doesn't support clustering, you can't cluster at this level.
  • Shared storage is probably required, but might not be.
  • Intra-cluster communication is harder to guarantee, so failovers sometimes happen unnecessarily, particularly during live migration. This might or might not matter to you.
  • Failover, when it happens, might be somewhat faster, as the OS doesn't have to boot. For databases, though, this usually isn't the large part of the failover time.

I used to think that you should always cluster at the guest level, if you could. Then people walked me through the management effort involved in that and showed me that it often makes a lot of sense to cluster at the host level.

  • You describe variants for Hyper-V, but what about regular Windows Cluster Service (application and DB will be migrating from one node to other). Does this approach has some advantages and disadvantages against using Hyper-V?
    – Sasha
    Jun 22 '11 at 7:52
  • Sasha, that's exactly what I was referring to with the term "guest clustering." Jun 22 '11 at 16:46

I can't think of many instances where providing high availability at the machine level is better than providing high availability at the application level. If you have the budget, and your application supports is (like SQL does), then provide your HA at the application level.

Machine level HA really only has the benefits of reduced cost when you're trying to keep several services up and the ability to provide HA for applications and services that don't natively support it.

There are some great things you can do with application level HA that machine level HA won't let you:

  1. You can update your operating system without suffering significant downtime. Machine level HA still requires that you reboot the VM in order to install updates. That's going to require more downtime than a simple service failover
  2. Keep your system running even if you have OS level failures.
  3. Be able to withstand application level disturbances. If you have a service fail and you're only failing over the VM, you're still down.
  • By "Machine level" you mean approach with virtual machine?
    – Sasha
    Jun 21 '11 at 16:24
  • @Sasha - Yes. I mean a Hyper V cluster setup for VM high availability.
    – Jason Berg
    Jun 21 '11 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.