TOP 10 Best Practice Tips for Windows Server 2003 Cluster Service (MSCS)
1. Under no circumstance should any other resource be created in the Cluster Group other than the default ones which are Quorum, Cluster IP Address and Cluster Network Name. (ref: KB 168948 ) If MS DTC is installed in the Cluster Group using the cluster’s resources and it’s not going to be used heavily by SQL, then this is the only exception that is supported as long as the MS DTC resource has the “Affect the group” box on the Advanced tab unchecked.
NOTE: Using the “Affect the group” box on the Advanced tab to uncheck this option before trying to bring any resource Online, is always a Best Practice tip to avoid unnecessary group failovers from one node to the other when the resource itself fails.
2. The most efficient way to create many file shares on a cluster is to create sub-folder shares, because this option can significantly reduce the number of resources and overhead. Using the same methodology as if you were creating user’s home folders. (ref: KB 256926 ) This option also simplifies administration and disaster recovery. If you must use individual File Share resources for several hundred shares, it may be necessary to add more CPUs or memory to the server.
NOTE: When setting the permissions, do it on the File Share resource through Cluster Administrator to set share level permissions. Only domain level groups should be used in defining share level permissions, because local groups and user accounts do not reside on the other node, and the permissions will not take effect when the file share is failed over. The only exception to this is if all nodes in the cluster are domain controllers (which is not something we normally recommend due to the overhead on the DC). It is recommended for security granularity at the file level, to use NTFS permissions instead of share level permissions on a server cluster.
3. You can surpass the 26-drive-letter limitation, by using volume mount points feature. If you use the root (host) volume exclusively for mount points, the size of the host volume only has to be several MB. This reduces the probability that the volume is used for anything other than the mount points. This feature can also decrease the amount of time it can take to defragment a drive, backup/restore and run CHKDSK against a volume as oppose executing these tasks on a terabyte volume. (ref: KB 280297 )
4. The dependency hierarchy in cluster is important. Most resources should depend on Physical Disk and Network Name resource within its own group, especially Server Message Block (SMB) File Share resource which requires both a Physical Disk and Network Name dependencies. The only resource types that do not usually depend on another resource are the Physical Disk and IP Address resources. (ref: KB 171791 ) The only exception of a Physical Disk having any kind of dependency, is when it’s a Mount Point that is dependent of the root Physical Disk coming Online first before the actual Mount Point. (ref: KB 280297 )
5. When configuring Microsoft Distributed Transaction Coordinator (MS DTC) on a cluster, make sure to create a separate MS DTC Group with its unique Physical Disk, Network Name and IP Address resources. (ref: KB 301600 ).
NOTE: Before brining MS DTC resource online, you should confirm Enable Network DTC Access is enabled. (ref: KB 817064 )
Under some situations, applications that can heavily us MS DTC may require Enable Network COM+ Access to be enabled. (ref: KB 817065 )
6. You should not change the default privileges or set the Cluster Service Account (CSA) to be a member of the domain Administrators group. By giving the minimal possible user rights to the Cluster service account, you avoid potential security issues if that account is compromised. When you remove a required right from the CSA, you may cause unexpected behavior. (ref: KB 269229 ) Before you apply more restrictive security settings to the Windows Server 2003-based and/or domain policies that apply to the cluster server nodes, you should read and apply certain recommended guidelines. (ref: KB 891597 )
7. When installing Cluster Services on the first node, make sure to read the article that talks about Recommended private "Heartbeat" configuration on a cluster server. Even though the article states the Private “Heartbeat” should be set at 10/Half Duplex, it is perfectly acceptable and supported to set at 100/Full Duplex. (ref: KB 258750 )
NOTE: Even though Auto-Detect/Auto-Sense is discouraged in a cluster environment, there are circumstances (like on brand new hardware such as certain blade servers) where vendors may ship network adapters that do not support manual settings. In these cases we have to suggest customer follow the adapter vendor's matrix, which sometimes they usually posted on their website. (ref: KB 174812 )
8. Make sure to download the latest drivers/firmware from the vendor’s website for the Cluster Solution. Especially, the latest drivers/firmware that will be used for the Cluster Solution such as network, fiber (HBA) and/or multi-path (MPIO) for the storage. (ref: KB 814607 )
9. Before creating a cluster, use the Microsoft Cluster Configuration Validation Wizard ( ClusPrep ) tool to validate that your system is configured properly by taking inventory of your system configuration and highlighting discrepancies in service pack levels, driver versions, etc.; evaluating and testing your network and storage configuration. (ref: KB 933462 )
10. Make sure to use a supported Cluster Solution from the Windows Server Catalog . (ref: KB 309395 & KB 828262 )
For additional details regarding “Best practices for configuring and operating server clusters”, please click on the following link:
https://technet2.microsoft.com/windowsserver/en/library/2798643f-427a-4d26-b510-d7a4a4d3a95c1033.mspx
Author: Mike Rosado
Support Engineer
Microsoft - Windows Server - Enterprise Platforms Support - Core team (Setup, Cluster and Performance)