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
- An instance of SQL Server 2000 cannot be run on a 6.5 or 7.0 cluster
- 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.
- 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.
- Kerberos will be used to connect to a SQL Server cluster by clients. If Kerberos is unavailable, NTLM will be used.
- Hardware should always be on the HCL!
- Windows Server 2003 machines with Terminal Server enabled may not even cluster!
- Use AWE or PAE to allow for increased amounts of RAM utilization by the cluster. However, PAE may cause backup problems!
- NIC's should be sent to static speeds that match the LAN or WAN infrastructure and auto sensing should be disabled.
- NAS devices are not supported but SANs are, as well as multiple clusters connected to the same SAN.
- Dynamic Disks are not supported, nor is file compression or software RAID or database files on mounted drives
- Nothing goes on the Quorum disk
- No Anti Virus software on a cluster (close your eyes security guys)!