Tuesday, May 31, 2011

Best Practices on Clustering


  • Detailed planning is critical to the success of every SQL Server cluster installation. Fully plan the install before performing the actual install.
  • An expensive cluster is of little value if the supporting infrastructure is not also fault tolerant. or example, don’t forget power redundancy, network redundancy, etc.
  • Run only a single instance of SQL Server per node. Whether you have two or eight nodes in your cluster, leave one node as a failover node.
  • Cluster nodes must not be domain controllers, and all nodes must belong in the same domain and should have access to two or more domain controllers.
  • All cluster hardware must be on the Microsoft Windows Clustering Hardware Compatibility List, and certified to work together as part of a cluster.
  • Since clustering is not designed to protect data (only SQL Server instances), the shared storage device used by the cluster must incorporate fault tolerant technology. Consider log shipping or mirroring to further protect your production databases.
  • When initially installing Windows and SQL Server Clustering, be sure that all drivers and software are up-to-date, including the latest service packs or hot fixes.
  • Each node of a cluster should have identical hardware, drivers, software, and configuration settings.
  • Fiber channel shared arrays are preferred over SCSI, and Fiber channel has to be used if you include more than two nodes in your cluster.
  • The Quorum drive must be on its own fault-tolerant, dedicated, logical drive.
  • Once the cluster has been installed, test it thoroughly for every possible failure scenario.
  • Do not run antivirus or antispyware on a SQL Server cluster.
  • If you need to reconfigure any Windows or SQL Server clustering configuration options, such as IP addresses or virtual names, you will need to uninstall clustering and then reinstall it.
  • Monitor active production clusters on a daily basis, looking for any potential problems. Periodically test failover on production servers to ensure all is working well.
  • Once you have a stable SQL Server Cluster running, be very leery about making any changes to it, whatsoever.

No comments: