SQL Server 2000 Clustering Gotchas

Yes, I know that SQL Server 2005 is on the horizon. However, there are still many companies that are interested in clustering on SQL Server 2000. As a result, here are some of the most prevalent gotchas when attempting to cluster. These tips are from the ultimate guide to SQL Server 2000 clustering found here




  1. An instance of SQL Server 2000 cannot be run on a 6.5 or 7.0 cluster
  2. During a failover, applications will have to be smart about handling the potential split-second loss of connectivity. In web based applications it will be easy enough (potentially refresh the page if your app won't detect the error). It's a little tougher in thick client applications. However, .NET try catch blocks should allow you to tap the exception and resubmit if required.
  3. The cluster account "owns" the cluster and needs to be a domain admin. There are ways to make this compliant with many corporate security policies though.
  4. Kerberos will be used to connect to a SQL Server cluster by clients. If Kerberos is unavailable, NTLM will be used. 
  5. Hardware should always be on the HCL!
  6. Windows Server 2003 machines with Terminal Server enabled may not even cluster!
  7. Use AWE or PAE to allow for increased amounts of RAM utilization by the cluster. However, PAE may cause backup problems!
  8. NIC's should be sent to static speeds that match the LAN or WAN infrastructure and auto sensing should be disabled.
  9. NAS devices are not supported but SANs are, as well as multiple clusters connected to the same SAN.
  10. Dynamic Disks are not supported, nor is file compression or software RAID or database files on mounted drives
  11. Nothing goes on the Quorum disk
  12. No Anti Virus software on a cluster (close your eyes security guys)!