Insufficient data from Andrew Fryer

The place where I page to when my brain is full up of stuff about the Microsoft platform

Guest Clustering–What is it and do you need it?

Guest Clustering–What is it and do you need it?

  • Comments 1
  • Likes

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:

  • Windows Server clustering is supported on any platform capable of running Windows Server itself as per the Hardware Compatibility List.  When you configure clustering in Windows it will run a series of checks to confirm it will work, and you’ll need to run this check if you want support as it’s the first thing the Microsoft engineers will ask for.    With SQL Server the resources you assign to an instance in the cluster must be available on each node to support automatic failover (cpu, memory storage etc.) .
  • SQL Server went back to its roots in 2008 as far as clustering was concerned – each node is maintained individually rather than trying to patch the whole cluster as was the case for SQL Server2005. In practice you take a node offline, patch it, upgrade etc. and than bring it on line and repeat for the next node.

I understand implementing guest clusters  places a lot of restrictions on Vmware like:

  • Only being able to use a 2 node cluster,
  • Only using fiber channel for shared storage,
  • No Vmotion,
  • No memory over commit

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:

Comments
  • 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 ;-)

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment