Tip: When configuring a SQL Server 7.0 or 2000 cluster, ensure that the “Failback” option is set to “Prevent Failback.”
Explanation: One of the options clustering provides SQL Server is the ability to automatically failback after a failover. For example, let’s say that the primary node of a two-mode SQL Server cluster fails over to the secondary node. If “Failback” is set to “Prevent Failback,” then when the primary cluster comes back online, the secondary node will continue to be the active node until you manually failover the cluster back to the primary node.
If “Failback” is set to “Allow Fallback,” then when the primary node comes back on line, then the secondary node will automatically failback to the primary node. This might be immediate, or be during a designated time (you can choose one of these options when you select “Allow Fallback”).
As you can probably imagine, you want to be able to manually control exactly when failback from the secondary node the primary node occurs. Otherwise, you might end up failing back during a period of time that is not good for your users.
Be default, “Prevent Fallback” is selected. To see how your cluster is configured, right-click on a resource group in Cluster Administrator, and select “Properties,” then click on the “Failback” tab.
Version: 7.0, 2000
Date Added: 2-28-2002
*****
Tip: When configuring a SQL Server 7.0 or 2000 cluster, ensure that the “Failback” option is set to “Prevent Failback.”
Explanation: One of the options clustering provides SQL Server is the ability to automatically failback after a failover. For example, let’s say that the primary node of a two-mode SQL Server cluster fails over to the secondary node. If “Failback” is set to “Prevent Failback,” then when the primary cluster comes back online, the secondary node will continue to be the active node until you manually failover the cluster back to the primary node.
If “Failback” is set to “Allow Fallback,” then when the primary node comes back on line, then the secondary node will automatically failback to the primary node. This might be immediate, or be during a designated time (you can choose one of these options when you select “Allow Fallback”).
As you can probably imagine, you want to be able to manually control exactly when failback from the secondary node the primary node occurs. Otherwise, you might end up failing back during a period of time that is not good for your users.
Be default, “Prevent Fallback” is selected. To see how your cluster is configured, right-click on a resource group in Cluster Administrator, and select “Properties,” then click on the “Failback” tab.
Version: 7.0, 2000
Date Added: 2-28-2002
*****
Tip: Before you install Windows 2000 clustering, you must create a clustering service account that will be used by the Cluster Service. It is important that this account be setup correctly.
Explanation: One of the biggest reasons that people have problems installing Windows 2000 clustering and SQL Server 2000 clustering is because the Cluster Service account is not setup correctly. Be sure that you do the following when creating the Cluster Service account:
The Cluster Service account must be a domain account, but it does not have to be a member of the Domain Administers group.
When creating the Cluster Service account, ensure that the option, “User must change password at next logon” is not selected, that the option “Password never expires” is selected.
All of the nodes in a cluster must belong to the same domain, and belong to the same domain as the Cluster Service account.
The Cluster Service account must be a member of the local administrators group on all the servers in the cluster.
The Cluster Service account must have these server rights on each of the nodes in the cluster: “Logon as a service” and “Act as part of the operating system.” These rights will automatically be given in most cases when you install the Clustering Service properly.
Version: 7.0, 2000
Date Added: 3-8-2002
*****
Tip: Prefix the cluster nodes names, and the virtual cluster names, with appropriate prefixes so that you don’t get the names confused.
Explanation: Sometimes, it is easy to confuse the names of the cluster nodes, and the virtual server names. For example, in a two-node cluster, there are two cluster node names and two virtual cluster names (one for the Windows 2000 cluster, and one for the SQL Server cluster).
One way to help prevent confusion of these names is to add an appropriate prefix to them. For example:
n1_: For node one of the cluster
n2_: For node two of the cluster
vc_: For the virtual name of the Windows 2000 cluster
vsql_For the virtual name of the SQL Server cluster
You can choose any prefix scheme that makes sense for you.
Version: 7.0, 2000
Date Added: 3-8-2002
*****
Tip: When configuring the IP address and subnet mask of the private “heartbeat” network in a cluster, select a subnet other than the one you use for your public network, and ideally, select one that is not currently used by your company.
Explanation: The private “heartbeat” network is used by a cluster for internal communication between the nodes of the cluster. This network is isolated from all other networks in your company by the fact that it runs over its own network cable (often directly wired from network card to network card using a special cross-over cable).
To prevent any potential for IP address conflicts, should someone make a mistake and connect the internal network to the public network, the internal network should be on its own subnet. This way, should someone make a mistake and connect the internal network to the public network, then there won’t be any potential for IP address conflicts and other strange problems arising.
While this is not a requirement, consider it a good preventative measure against future potential problems.
Version: 7.0, 2000
Date Added: 3-11-2002