Home / server / Questions / 282360
In Process
Sasha
Asked: 2011-06-21 13:14:08 +0800 CST

Hyper-V cluster VS regular cluster

  • 772

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

Update:

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?

hyper-v cluster hyper-v-server-2008-r2

2 Answers

  1. 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.

    • 2

  2. 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.
    • 1