Windows 2000 and Windows Server 2003 cluster nodes as domain controllers (281662)

MORE INFORMATION

To have Windows Clustering function properly (where the Cluster service starts on each node) the node that forms the cluster must be able to validate the Cluster service domain account, which is the account that you configure during the Windows Clustering installation. To accomplish this, each node must be able to establish a secure channel with a domain controller to validate this account. If the node cannot validate the account, the Cluster service does not start. This is also true for other clustered programs that must have account validation for services to start, such as Microsoft SQL Server and Microsoft Exchange.

Note Exchange 2000 and Exchange Server 2003 are not supported in a clustered configuration where the cluster nodes are domain controllers. For more information, click the following article number to view the article in the Microsoft Knowledge Base: If you have a cluster deployment in which there is no link with either a Windows NT 4.0 domain, a Windows 2000 domain, or a Windows Server 2003 domain, you must configure the cluster nodes as domain controllers so that the Cluster service account can always be validated to allow for proper cluster functionality.

If the connectivity between cluster nodes and domain controllers is such that the link is either slow or unreliable, consider having a domain controller co-located with the cluster, or configuring the cluster nodes as domain controllers.

Consider the following important points when you are deploying Windows Clustering nodes as domain controllers:

• Some hotfixes or service packs may not be recommened for application to a Windows Clustering enviroment. Make sure that you verify that the hotfix should be applied to a server cluster.
• We do not recommend that you combine the domain controller role and the server clusters role on a single computer.
• If one cluster node in a two-node cluster is a domain controller, all nodes must be domain controllers. It is recommended that you configure at least two of the nodes in a four-node Datacenter cluster as domain controllers.
• There is overhead that is associated with the running of a domain controller. A domain controller that is idle can use anywhere between 130 to 140 megabytes (MB) of RAM, which includes the running of Windows Clustering. There is also replication traffic if these domain controllers have to replicate with other domain controllers within the domain and across domains. Most corporate deployments of clusters include nodes with gigabytes (GB) of memory so this is not generally an issue.
• If the Windows 2000 or Windows Server 2003 cluster nodes are the only domain controllers, they each have to be DNS servers as well, and they should point to themselves for primary DNS resolution, and to each other for secondary DNS resolution. You must address the problem of the ability to not register the private interface in DNS, especially if it is connected by way of a crossover cable (two-node only). For additional information about how to configure the heartbeat interface, click the following article number to view the article in the Microsoft Knowledge Base:

  258750 Recommended private "heartbeat" configuration on a cluster server

  However, before you can accomplish step 12 in article 258750, you must first modify other configuration settings, which are outlined in the following article in the Microsoft Knowledge Base:

  275554 The host's "A" record is registered in DNS after you choose not to register the connection's address

• If the cluster nodes are the only domain controllers, they must each be global catalog servers, or you must implement domainlets.
• The first domain controller in the forest takes on all flexible single master operation roles (refer to article 197132). You can redistribute these roles to each node. However, if a node fails, the flexible single master operation roles that the node has taken on are no longer available. You can use Ntdsutil to forcibly take away the roles and assign them to the node that is still running (refer to article 223787). Review article 223346 for information about placement of flexible single master operation roles throughout the domain.
• If a domain controller is so busy that the Cluster service is unable to gain access to the Quorum drive as needed, the Cluster service may interpret this as a resource failure and cause the cluster group to fail over to the other node. If the Quorum drive is in another group (although it should not be), and it is configured to affect the group, a failure may move all group resources to the other node, which may not be desirable. For more information regarding Quorum configuration, please refer to the article 280345 listed in the "Reference" section.
• Clustering other programs, such as SQL or Exchange, in a scenario where the nodes are also domain controllers, may not result in optimal performance due to resource constraints.
• You cannot cluster domain controllers for fault tolerance. You can promote computers to be domain controllers, and then you can install the Cluster service on those computers, but there is no method to store Active Directory on any one of the cluster's managed drives. There is no "failover" of Active Directory.
• You may want to consider making cluster nodes domain controllers (refer to article 171390 for more information), but if a domain controller is already local, or there is a reliable high-speed connectivity to a domain controller available, Microsoft does not recommend implementing them on cluster nodes.
  
  Note You must promote a cluster node to a domain controller by using the Dcpromo tool prior to installing Windows Clustering (refer to article 269229 for more information).