I am pretty sure the term guest clustering is not a standard industry term nor is it official Microsoft speak, so what do I mean by it? I mean the business of creating a cluster out of a group of virtual machines – you might call this a virtual cluster but that might confuse it with clustering physical machines to run virtual machines on them so that no physical machine is a single point of failure.
Clustering of any kind is about improving availability and if your physical servers are clustered why would then cluster the virtual machines running on them?
The answer is to improve the availability of the application in the virtual machine. A physical cluster will fail over if there’s a hardware or physical operating system problem, but can’t respond to a dead service like SQL Server, while a guest cluster will do this and allow you take nodes off line for maintenance patching upgrade etc. while keeping the rest of the cluster running.
Windows clustering of any kind has traditionally been seen as difficult and for me this all changed in 2008 with the dramatic changes to clustering both in Windows Server 2008 and in SQL Server 2008:
I understand implementing guest clusters places a lot of restrictions on Vmware like:
note: I am not a Vmware expert so please check the Vmware resources and forums for the definitive word on this, and please correct me if I am wrong.
I do know that in Hyper-V a cluster behaves exactly like a real cluster and there isn’t this loss of functionality so virtual machines can be live migrated and moved between physical servers as required. In other words you so you have the power of clustering and the added flexibility of virtualisation and this shouldn’t affect your performance , licensing etc. compared with a physical cluster running on the same spec of machine.
Try it yourself:
Here is the problem I see with guest clustering: at the moment, the *only* form of shared storage supported is iSCSI. If you don't have iSCSI but you have another form of shared storage (e.g. DAS), that isn't supported.
But you might think that you could "work around" it by using the iSCSI target software to, in effect, republish the appropriate file storage over iSCSI within the Hyper-V local network. This could, in theory, work really well if the active SQL node is on the same physical host as the server providing the iSCSI target since there wouldn't really be any network traffic as such - just some data being thrown around the virtual network.
If, however, the active SQL node gets moved to a different physical node from that of the iSCSI target, you then do get real network traffic and thus a performance hit. It would be great if you could somehow keep the two virtuals on the same physical but I don't know how to do that.
I think, also, that guest clustering is quite a complicated concept to get your head around. Failover clustering, for example, requires multiple network interfaces for things like data, heartbeat, etc. To repeat that at the guest level does introduce complexity. It would be nice to have some step-by-step guidance - though there probably is some on TechNet if I were to look hard enough ;-)