Hi cluster fans,
The Cluster Program Management team recently returned from one of our biggest industry events and the second most popular question was “What is the best way to deploy Hyper-V with Failover Clustering?” (The most popular question being “What’s new in 2008 Failover Clustering” – see our recent post for that discussion: http://blogs.msdn.com/clustering/archive/2008/06/16/8607114.aspx )
The answer really depends on your enterprise’s needs.
You can host and fail over virtual machines (VMs) by making your physical machines highly available – this is known as ‘Host Clustering’ and is perhaps the most common and recommended deployment. This allows you to put each service or application in multiple individual VMs which are highly available. If a VM becomes unavailable, only that single service in that VM will fail over (assuming each VM has its own LUN). Failure of a single VM hosting multiple services would cause all those services to become unavailable. However you may not want to make this too granular and have too many VMs since each VM requires additional memory and resources to host the virtual OS, so consider the total processing capacity of your machines. For storage you can use iSCSI, Fibre Channel, or Serial Attached SCSI (SAS). When the physical host and VM are in a running state, the admin can gracefully failover the VM to another physical machine and the end user should only need to wait a few seconds until the VM is reconnected. The admin can perform this “Quick Migration” by selecting the “Move Virtual Machine(s)” action. In the background, Failover Clustering will save the current running state of the VM on the shared storage, stop it on the first node and start it on the new node. Failover Clustering also monitors the health of the VMs, so if the virtual OS crashes, hangs, or blue screens, it can be automatically restarted, however the end user would need to wait a little longer while the VM state is loaded and started. While Host Clustering can monitor the state of the virtual OS, it does not monitor the health of applications inside the VMs, however that can be accomplished using “Guest Clustering”.
Guest Clustering enables highly-available of services and applications in the virtual layer and is fully supported in Windows Server 2008. This is done through installing Failover Clustering on several VMs, then clustering them as if they were physical nodes. All of these VMs can use the same shared iSCSI storage which will store the state of the running applications within the VM. You can even run ‘Validate a Cluster Configuration’ on the VMs to ensure that the Failover Clustering component works! Making your services highly available in the virtual layer allows you monitor their health and fail them over if the VM is experiencing downtime.
By combining your guest and host clustering you can create high-availability in both your physical and virtual layers. Here’s an example of this combined deployment.
· Physical Node p1a and p1b form a physical host cluster. They host virtual servers v1a, v2a and v3a. These virtual server fail over between p1a and p1b allowing high-availability at the physical layer.
· Physical Node p2a and p2b form a physical host cluster. They host virtual servers v1b, v2b and v3b. These virtual server fail over between p2a and p2b allowing high-availability at the physical layer.
· Virtual nodes v1a and v1b are clustered in the virtual layer.
· Virtual nodes v2a and v2b are clustered in the virtual layer.
· Virtual nodes v3a and v3b are clustered in the virtual layer.
· Applications are now made highly-available in the virtual layer, and they can failover, while the virtual machines are made highly-available at the physical layer, and they can failover. This allows you to have high availability for both the physical machines and the virtual machines.
For additional information, some great visual representations of these scenarios, and a discussion of a few more Failover Clustering / Hyper-V configuration, check out Jose Barreto’s blog post: http://blogs.technet.com/josebda/archive/2008/06/17/windows-server-2008-hyper-v-failover-cluste...
Thanks,
Symon Perriman
Program Manager
Cluster & HA