I gave a live webinar yesterday for Windows IT Pro on how to make your Hyper-V based virtual environment highly available the right way which can be seen on http://www.ittv.net and on my video archive at http://www.savilltech.com/videos.html.

I wanted to go over some of the key points of that presentation here and primarily the different types of high availability available to us with Failover Clustering and Hyper-V.

When we deploy Windows Server 2008 Enterprise or Datacenter Edition we can take advantage of the Virtual Machine application type which allows a guest operating system (a virtual machine) to be moved between nodes in the cluster with minimal down time, known as quick migration (more on this in a future post). The guest operating system has no knowledge it is moving between Hyper-V host servers. The configuration files and virtual hard disks are all stored on shared storage (such as a SAN) which can be connected via iSCSI, Serial Attached SCSI (SAS) or Fibre Channel. This is known as host clustering.

An alternate approach is to install Windows Server 2008 Enterprise edition (or datacenter but probably overkill) inside the guest operating system. We then install the Failover Clustering feature within the guest operating systems and create a cluster between the virtual machines. For the shared storage we need to use iSCSI since Hyper-V does not support the pass-through of Serial Attached SCSI (SAS) or Fibre Channel. We use the iSCSI initiator within the guest operating systems to connect to an iSCSI target and that storage then moves between the virtual operating systems. Because we are using clustering within the guest operating systems the service we are moving has to support Failover Clustering, such as Exchange Cluster Continuous Replication (CCR), a file service etc. While I have shown both the members of the cluster on the same Hyper-V server this does not need to be the case and ideally the members of the cluster would reside on separate Hyper-V servers for maximum availability. You just need to ensure you still have the right networks available for the client and cluster communications. This is known as guest clustering.

We can combine host and guest clustering as shown to provide very high availability. We have two sets of Hyper-V servers that are clustered together to provide high availability at a guest OS level allowing the guest OS to move between Hyper-V servers and then we actually cluster together the guest operating systems (one from each of the Hyper-V clusters) to enable service level failover. The storage used by the service would have to be iSCSI however the storage for the actual virtual machines could be iSCSI, SAS or Fibre Channel. This is known as hybrid clustering.

Last and least we have mixed clustering. In this case we actually cluster within a guest operating system on Hyper-V and a physical server. The failover is at an application/service level and so once again we have to use iSCSI so the virtual guest OS can see the storage. This is not typically used in production so only use in test environments (if you have to!).

So which should you use? If you have a service that supports Failover Clustering then you should use guest clustering because this way the service is aware of the high availability and may take extra steps to preserve integrity in the case of a failover. As an example Exchange Cluster Continuous Replication (CCR) takes special steps in the event of a failover to communicate with Hub Transport to make sure no messages have been lost. Also some services/applications do not support host clustering of their virtual environments. You could also use hybrid clustering if the application/service does not explicitly not support host level clustering.

If an application/service does not support clustering then you can use host level clustering to make the OS highly available that hosts the service.

Catch up with you again soon. Stay safe, its currently 21 degrees in Texas which for us, is REALLLLLY cold!