Thoughts on Microsoft’s Hyper-V feature called Quick Migration vs. VMware VMotion
Quick Migration in Hyper-V is Microsoft’s way to provide high availability in their virtual infrastructure. Quick Migration requires setup of a Microsoft Cluster to be able to failover VMs from one Hyper-V host to another. This requires Enterprise or Datacenter licenses for Windows. But what does this mean?
Microsoft does not support two Hyper-V hosts accessing the same LUN at the same time. You have to setup Cluster Disks that only one host can access. This means that when you want to do a failover with Quick Migration – you failover the whole LUN. All guests (VMs) that use that specific LUN will be suspended in a short period and then moved to another host. It happens within seconds – but the VM is not accessible in that period and users may lose connectivity.
To be able to move a single guest from one Hyper-V host to another host requires that this guest use its own dedicated LUN. This could potentially limit the number of VMs running on a Hyper-V host. For database servers, like SQL, Exchange, where you split the load on more than one LUN to separate random IO from sequential IO, this will dramatically limit the number of guests on one specific host or cluster. One host or cluster can only address up to 255 LUNs. 16 nodes are supported in a MS Cluster.
If you decide to put more guests on the same LUN – this group of guests will all be failed over to the same destination host. In the end this means that you would need more hosts to support the same amount of guests compared to VMware, because you need available resources within the other hosts to be able to take over the load from all guests within a same LUN. One thing to consider is how long a failover takes. This should be tested thoroughly. In prior versions of MS clustering the more resources in the resource group that you want to failover the longer it took.
Also you would not be able to separate the load from one Hyper-V host (that has failed) to multiple hosts. It all depends on design – but it makes it more complicated in my opinion.
I think the way VMware does this is far more flexible and scales a lot better and potentially it is possible to use more resources on each hosts and still have capacity to lose a single or two hosts within a cluster. VMware can failover multiple guests to multiple hosts – sharing the same LUN and by that spreading the load from the failed host on multiple hosts.
Many customers are not very confident with running a Microsoft Cluster solution based on the reputation the cluster features has on stability, management and complexity. I have prior build and setup multiple MS cluster solutions and they have became a lot more stabile in Windows Server 2003 and hopefully even more with Server Windows Server 2008.
Final note is that Quick Migration can’t be compared with VMware’s VMotion. Quick Migration suspends the guest or guests before they are failed over with a minimal downtime. VMware VMotion moves the VM guest within hosts without downtime. Several other features from VMware is built on top of VMotion – which is VMware Update Manager, VMware Distributed Resource Scheduling (DRS – automatic load balancing on CPU and memory), VMware Storage VMotion, VMware Distributed Power Management (DPM – currently in experimental support only)
For more info on Microsoft Quick Migration read this whitepaper: http://download.microsoft.com/download/3/B/5/3B51A025-7522-4686-AA16-8AE2E536034D/Quick%20Migration%20with%20Hyper-V.doc
For more information on VMware VMotion read this datasheet: http://www.vmware.com/pdf/vmotion_datasheet.pdf
Microsoft does not support two Hyper-V hosts accessing the same LUN at the same time. You have to setup Cluster Disks that only one host can access. This means that when you want to do a failover with Quick Migration – you failover the whole LUN. All guests (VMs) that use that specific LUN will be suspended in a short period and then moved to another host. It happens within seconds – but the VM is not accessible in that period and users may lose connectivity.
To be able to move a single guest from one Hyper-V host to another host requires that this guest use its own dedicated LUN. This could potentially limit the number of VMs running on a Hyper-V host. For database servers, like SQL, Exchange, where you split the load on more than one LUN to separate random IO from sequential IO, this will dramatically limit the number of guests on one specific host or cluster. One host or cluster can only address up to 255 LUNs. 16 nodes are supported in a MS Cluster.
If you decide to put more guests on the same LUN – this group of guests will all be failed over to the same destination host. In the end this means that you would need more hosts to support the same amount of guests compared to VMware, because you need available resources within the other hosts to be able to take over the load from all guests within a same LUN. One thing to consider is how long a failover takes. This should be tested thoroughly. In prior versions of MS clustering the more resources in the resource group that you want to failover the longer it took.
Also you would not be able to separate the load from one Hyper-V host (that has failed) to multiple hosts. It all depends on design – but it makes it more complicated in my opinion.
I think the way VMware does this is far more flexible and scales a lot better and potentially it is possible to use more resources on each hosts and still have capacity to lose a single or two hosts within a cluster. VMware can failover multiple guests to multiple hosts – sharing the same LUN and by that spreading the load from the failed host on multiple hosts.
Many customers are not very confident with running a Microsoft Cluster solution based on the reputation the cluster features has on stability, management and complexity. I have prior build and setup multiple MS cluster solutions and they have became a lot more stabile in Windows Server 2003 and hopefully even more with Server Windows Server 2008.
Final note is that Quick Migration can’t be compared with VMware’s VMotion. Quick Migration suspends the guest or guests before they are failed over with a minimal downtime. VMware VMotion moves the VM guest within hosts without downtime. Several other features from VMware is built on top of VMotion – which is VMware Update Manager, VMware Distributed Resource Scheduling (DRS – automatic load balancing on CPU and memory), VMware Storage VMotion, VMware Distributed Power Management (DPM – currently in experimental support only)
For more info on Microsoft Quick Migration read this whitepaper: http://download.microsoft.com/download/3/B/5/3B51A025-7522-4686-AA16-8AE2E536034D/Quick%20Migration%20with%20Hyper-V.doc
For more information on VMware VMotion read this datasheet: http://www.vmware.com/pdf/vmotion_datasheet.pdf
Comments
Post a Comment