|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.|
Clustering the Data-Tier Server
You can make sure seamless, uninterrupted service from Team Foundation Server by installing the Team Foundation databases in a server cluster. A server cluster is a set of dedicated, matching computers configured to appear as a single server. By using a cluster, you can automatically start data-tier services on a second computer when you take the active computer offline for maintenance or if a failure occurs.
Typically, this availability strategy is cost effective for very large organizations with the resources to set up and maintain a complex topology.
You can use the following information to understand the specific configuration that Team Foundation Server supports.
Single Quorum in an Active/Passive Configuration
If you chose to invest resources in a server cluster, Team Foundation Server supports a configuration of an active node and a passive node that uses a single quorum device server. The quorum is the storage device controlled by the primary node for the data tier and tracks which node is acting as the primary node. Only one node at a time may own the quorum.
When the data tier fails over to the passive node, the passive node takes ownership of the quorum and the data tier. When the two nodes are attached to a single storage device, the quorum may be created on the storage device.
You manage a cluster through the Cluster Administrator snap-in that is installed with Windows Server 2003, Enterprise Edition or Datacenter Edition. During installation, SQL Server 2005 provides resources to both nodes of the cluster.
SQL Server in a Cluster
The setup for SQL Server recognizes clusters and manages the installation to the active and passive nodes for you.
For Team Foundation Server, you must plan to use the default instance of SQL Server that is running on the computer and not a named instance.
Before you install Team Foundation Server in a cluster, you must prepare the cluster for installation. For example, you must change settings for the SQL Server services to run automatically. For more information, see the topics "User Accounts Required for Team Foundation Server Setup," "Checklist: Team Foundation Server Cluster Deployment," and "Install Team Foundation Server Databases on a Cluster" in the Team Foundation Server Installation Guide.
Although the data-tier server automatically starts operations on the other computer in the cluster during failover, SQL Server requires some time to detect that the connections to the application tier must be restarted. For more information about clusters and SQL Server 2005, see the topic "Configuring High Availability" in the SQL Server 2005 Books Online (http://go.microsoft.com/fwlink/?LinkId=62398).
Recovery of Connections to Application Services
You can add a resource to the cluster that explicitly restarts the application services to establish connections between the data tier and application tier more efficiently. The application-tier cannot reside in a cluster.
The resource points to a script file that updates the DNS and explicitly establishes connections between the tiers. A generic script resource is a .wsh file that implements the interface Microsoft Windows Management Instrumentation (WMI) that is used by Clustering API services. For more information about the Cluster API and cluster resource files, see "Server Cluster API Reference" (http://go.microsoft.com/fwlink/?LinkID=82329).
For more information and an example of how to explicitly restart the connections on failover, see the topic "How to: Accelerate Server Recovery in a Cluster" in the Team Foundation Server Installation Guide.
By default, the user account used when the cluster was created becomes the Cluster Service Account.
You should not change the passwords for any one of the SQL Server service accounts when a failover cluster node is down or offline. If you have changed the password in this situation, you must reset the password using Enterprise Manager when all nodes are back online.
If you want to change the account that starts the Cluster service, you must use Computer Management for Windows Server 2003 to change the account on each node in the cluster.
To function correctly in Windows Server 2003, the Cluster service account explicitly requires the following permissions for both nodes in the cluster.
Act as part of the operating system
Adjust memory quotas for a process
Back up files and directories
Increase scheduling priorities
Log on as a service
Restore files and directories
Also, make sure that the Local Administrator group has access to the following user permissions.
Impersonate a client after authentication
Manage auditing and security log
You can grant these permissions in the following locations Local Security Policy\Security Settings\Local Policies\User Rights Assignment.
If the service account for SQL Server is not an administrator in a cluster, the administrative shares cannot be deleted on any nodes of the cluster. The administrative shares must be available in a cluster for SQL Server 2005 to function.
How to: Create a New SQL Server 2005 Failover Cluster (Setup) (http://go.microsoft.com/fwlink/?LinkId=82328).
For more information about required service accounts, see the topics "User Accounts Required for Team Foundation Server Setup," "Checklist: Team Foundation Server Cluster Deployment," and "Install Team Foundation Server Databases on a Cluster" in the Team Foundation Server Installation Guide. For more information about the installation guide, see.