Geoff N. Hiten Blog

Last week I stopped by the SQL Lounge at the PASS summit in Denver.  I met a Microsoft employee named Max Verun, whose official title is Program Manager - Manageability and Servicing Platform.  Translated into ordinary geek-speak, he is in charge of Clustering and Cluster Installation.  This was a golden opportunity for me.  I spent the next hour or so listening to Max and talking with him about where SQL wants to go with clustering.  Since none of that conversation is under NDA, I thought I would share some of the highlights.

Clustering will remain a High Availability failover technology.  While I suspect something like what the other guys call "clustering" is on Microsoft's radar,  I doubt very much it will be called clustering when it finally surfaces.   This isn't any inside knowledge, it is speculation that the dev team is aware of the competition and is not stupid. 

Clustering will have some name changes.  The "Virtual Server" nomenclature will go away.  It is too confusing, especially now that Microsoft has gotten serious about platform Virtualization. So we will just be talking about Clustered SQL Instances in the future.  I hope this change is more successful than trying to forget the "Active/Passive..." terminology.

The actual guts of clustering will remain largely unchanged.  The failover detection and timeouts work well in most cases so that stays the same.  There may be some technical changes to the SQL Cluster  Resource DLL to fix some minor issues, but the actual workings of the SQL Clustering won't change.

The big changes in clustering come on the setup side.  The most important change is the division of the current installer into two pieces.  These two parts are are Setup and Configuration.  SQL Cluster install will mirror Windows Cluster Install.  With WIndows, you install the base bits including the clustering parts, then configure a cluster.  SQL will adopt the same approach.  The config tool creates a single-node clustered SQL instance.  You then add new nodes to the clustered instance.  This is a lot like WIndows Clustering, except that you can't do the SQL clustered install until the WIndows Cluster is built.  The config tool will build an INI file so you can clone the installation for the second and ssubsequent nodes.

The ultimate goal here is to be able to sysprep cluster nodes and ship them pre-configured from a system builder.  That feature may or may not make it into SQL 2008 due to several other dependencies, but we will get some foundation pieces that should make it easier to install a cluster and ultimately lead up to that possibility

One interesting side effect of splitting the installation functions is eliminating the current dependency on pre-qualifying hardware at the vendor level. Now, the SQL cluster configuration tool will determine if the hardware supports the desired configuration.  This should lead to some interesting configurations and lots opportunities for those of us who rescue people from their own cluster follies. 

Microsoft is adding iSCSI support for clustering.  According to Max, their tests have been good as far as performance and stability.  My experience so far with iSCSI and SQL has not been so good.  I suspect the difference is due to Microsoft not purchasing their iSCSI equipment from Billy Bob's bargain computer hardware and pool cleaning service. Maybe they will have good enough tests in their tool, but I still don't trust iSCSI on a cluster.

One feature Max seemed very proud of is support for up to 64 nodes in a cluster.  I guess 8 nodes isn't confusing enough.

I don't have any time frames for when we will be seeing these changes, whether it is in CTPs or even in the SQL 2008 release.  I do know this is the direction the SQL Clustering team is thinking and working, but until the next release ships, nothing is locked in.