First and most important thing to remember when working on designing a SQL Server cluster is it is entirely dependent upon the underlying base architecture that you choose to implement for the operating system.  Here, it really pays to do your homework as the newer versions of Windows Server have some AMAZING features that will change the way we have traditionally thought about clustering.

In my opinion, Windows Server 2008 changes the story that can be told surrounding clustering and disaster recovery.  For the first time, without the headache (licensing cost, training, additional complexities) of third party products you can create geographically separated clusters.  Well, whoop de do you say?  We could do this with previous versions. The big gotcha was, all nodes of the cluster  had to reside on the same subnet.  Just about every time I see geographically separated offices or data-centers, they each have their own sub-netting scheme. 

Now pair this with Hyper-V clustering.... whoa Nelly.  Game Changer!  Geographically separated Hyper-V clusters.  Talk about simplicity of administration, and powerful disaster recovery.  Oh yea, don't forget that we're also adding live migration (the ability to move a Hyper-V guest machine from one node to another without taking the guest offline) in Windows Server 2008 R2 (coming soon!).  My co-worker Dave Ziembicki's blog ( has a cool video of an actual live migration on an early release of R2

Some additional cool changes in Windows Server 2008 is the ability to use IPSEC between not only clients and the clusters, but between the cluster nodes.  This is a major step forward for cluster security.  My other personal favorite is not requiring NetBIOS and WINS anymore... clusters can support IPv6 and DNS rather than the ancient WINS subsystem.  My days will suddenly be more productive as I won't have to troubleshoot nasty WINS problems anymore!

Anyway, I think you understand that SQL server's clustering is significantly dependent on the architecture that is chosen for the host operating system.  I hope this came across as passionate about the changes Windows Server 2008 brings to the table and not like a bad Saturday night infomercial, these changes are really amazing.

Onto what I really intended to write about today... SQL Clustering.

Here's the bulleted list:

  • SQL Server 2008 clustering was re-aligned to follow the Windows Server 2008 paradigm this allows:
    • Up to 16-node failover cluster
    • IPv6 and DCHP support
    • Removal of Domain Groups by creation of the Service SID
    • Heterogeneous hardware and ISCSI support (no more HCL list)
    • Cluster validation tool includes SQL Server's cluster health
  • Rolling Upgrades
  • No remote execution on cluster nodes

To me personally, this is the biggest shift everyone will have to get used to who has created a SQL Server cluster in previous versions.  In previous versions of SQL Server, when the cluster was being created, as long as all nodes of the cluster were visible to the primary node at the time of installation, the cluster was installed on all nodes.  Going forward, each node in the cluster will need to be attended to to join it into the cluster.  Some may take this as a negative, but really, it was a by-product of the increased security posture taken in Windows Server 2008. 

To conclude, SQL Server clustering is a great option for ensuring your data is highly available.  With the changes made in Windows Server 2008, I think the disaster recovery story got significantly better.  Remember, before setting up any HA or DR solution, look at the problem you are trying to solve to ensure you are providing the right technological solution. 

Related Links:

Overview of Failover Clustering in Windows Server 2008

Features Supported by the Editions of SQL Server 2008