Before Installing Failover Clustering

Before you install a Microsoft SQL Server 2005 failover cluster, you must select the hardware and the operating system on which SQL Server 2005 will run. You must also configure Microsoft Cluster Service (MSCS), and review network, security, and considerations for other software that will run on your failover cluster.

Preinstallation Checklist

Before you begin the failover cluster installation process, review the following items:

Verify Your Hardware Solution

• Your hardware must be listed on the Microsoft Windows Catalog and Hardware Compatibility List. The hardware system must appear under the category of a cluster solution.

  Important

  Individual cluster components added together do not represent an approved system for failover clustering. Only systems purchased as a cluster solution and listed in the cluster group are approved. When checking the Microsoft Windows Catalog and Windows Hardware Compatibility List, specify "cluster" as the category. All other categories are for OEM use. For more information, see The Microsoft support policy for server clusters, the Hardware Compatibility List, and the Windows Server Catalog.

• Special hardware compatibility testing is necessary when you implement a failover server cluster on a Storage Area Network (SAN). The complete hardware solution must be in the Cluster/Multi-cluster Device category of the Microsoft Windows Catalog and Hardware Compatibility List. For more information, see the Microsoft Knowledge Base article, Support for multiple clusters attached to the same SAN device.

• If the cluster solution includes geographically dispersed cluster nodes, additional items like network latency and shared disk support must be verified. The complete solution must be on the Geographic Cluster Hardware Compatibility List. For more information, see the Microsoft Knowledge Base article, Windows clustering and geographically separate sites.

• SAN configurations are also supported on Microsoft Windows 2000 Advanced Server and Datacenter Editions. The Windows Catalog and Hardware Compatibility List shows the set of SAN-capable storage devices that are supported as SAN storage units with multiple MSCS clusters attached. You can deploy a set of Windows servers and clusters on a SAN fabric and have Microsoft support. You do this by matching the devices on this list with the complete cluster configurations defined in the Microsoft Windows Catalog and Hardware Compatibility List cluster category. For more information, see the Microsoft Knowledge base article, The Datacenter Program and Windows 2000 Datacenter Server Product.

• If you deploy a SQL Server 2005 failover cluster on Internet small computer system interface (iSCSI) technology components, we recommend that you use appropriate caution. For more information, see the Microsoft knowledge base article, Support for SQL Server 2000 on iSCSI technology components.

• For support information, see the Microsoft Knowledge base article, Microsoft support policy for a SQL Server failover cluster.

• Consider quorum disk resource sharing. In a server cluster, the quorum disk contains a master copy of the server cluster configuration. It is also used as a tie-breaker if all network communication fails between cluster nodes. Depending on the type of server cluster you implement, the quorum disk might or might not be a physical disk on the shared cluster disk array. Although it is best to reserve a complete cluster disk for use as the quorum disk, resources other than the quorum resource might be permitted to access the quorum disk.
  However, the quorum resource share the same disk with other resources, you must decide between two unwanted alternatives. Either you must configure the resource so that its failure does not affect the group, or you must let the group be affected by the other resource's failures. In the first case, you lose failover support for the resource; in the second, the quorum resource fails over together with the rest of the group that contains both the quorum resource and the failed resource. As a result, the complete cluster is offline for as long as it takes the group to fail over.
  For more information about correct quorum drive configuration, see the Knowledge Base article, Quorum Drive Configuration Information.

• To install a SQL Server 2005 failover cluster when the source installation files and the cluster exist on different domains, copy the installation files to the primary node of the cluster. Then, start the installation from the primary node.

Verify Your Operating System Settings

• Make sure that your operating system is installed correctly and designed to support failover clustering. For more information about supported operating systems, see Hardware and Software Requirements for Installing SQL Server 2005.
• Enable Windows Cryptographic Service Provider (CSP) on Windows Server 2003. If the CSP service is stopped or disabled on any cluster node, SQL Server Setup fails with a Windows Logo Requirement error message.
• Enable the Task Scheduler service on all operating systems for remote and cluster installation. If the Task Scheduler is disabled, SQL Server Setup fails with Error 1058. For more information, see How to: Enable Windows Task Scheduler Service.
• SQL Server 2005 supports mount points; the clustered installations of SQL Server are limited to the number of available drive letters. If you use only one drive letter for the operating system, you are limited to a maximum of 25 instances of SQL Server per failover cluster.
  A mounted volume, or mount point, lets you use a single drive letter to refer to many disks or volumes. If you have a drive letter D: that refers to a regular disk or volume, you can connect or "mount" additional disks or volumes as directories under drive letter D: without the additional disks or volumes requiring drive letters of their own.
  Special mount point considerations for SQL Server 2005 failover clustering:
  • SQL Server Setup requires that the base drive of a mounted drive has an associated drive letter. For failover cluster installations, this base drive must be a clustered drive.
  • The base drive, the one with the drive letter, cannot be shared among failover cluster instances. This is a normal restriction for failover clusters, but is not a restriction on stand-alone, multi-instance servers.
  • Take extra care when setting up your failover cluster to ensure that both the base drive and the mounted disks or volumes are all listed as resources in the resource group. SQL Server Setup does not take care of this automatically, nor does SQL Server check for this during CREATE/ALTER DATABASE.
  • Ensure that the mounted disks or volumes are mounted under the correct lettered base drive, and make sure that the mounted drive is set to be dependent on the parent drive.

Configure Microsoft Cluster Service

• Microsoft cluster service (MSCS) must be configured on at least one node of your server cluster. MSCS is only supported if it is installed on a hardware configuration that has been tested for compatibility with the MSCS software. You must also run SQL Server 2005 Enterprise Edition or Standard Edition together with MSCS. SQL Server 2005 Enterprise Edition supports failover clusters with up to 8 nodes. SQL Server 2005 Standard Edition supports 2-node failover clusters.
  For more information about how to install and configuring MSCS on Windows Server 2003, see Server clusters.
  For more information about installing and configuring MSCS on Windows 2000 operating systems, see Step by Step Guide to Installing Cluster Service.
• The resource DLL for the SQL Server service exports two functions that are used by MSCS Cluster manager to check for availability of the SQL Server resource. A simple check, LooksAlive, queries the service status by using the Windows NT Service Control Manager. A more rigorous check, IsAlive, connects to SQL Server as a user probe to perform a simple query. By default, LooksAlive is fired every 5 seconds and IsAlive is fired every 60 seconds. The LooksAlive and IsAlive polling intervals can be changed in MSCS Cluster Administrator from the Advanced tab for the SQL Server resource or using the cluster.exe command prompt utility.
• MSCS must be able to verify that the failover clustered instance is running by using the IsAlive check. This requires connecting to the server by using a trusted connection. By default, the account that runs the cluster service is configured as an administrator on all nodes in the cluster, and the BUILTIN\Administrators group has permission to log into SQL Server. These settings change only if you change permissions on the cluster nodes.
• If the BUILTIN\Administrators account is removed, ensure that the account that the Cluster Service is running under can log into SQL Server for the IsAlive check. If it cannot, the IsAlive check will fail. At a minimum, the MSCS Cluster Service account must have public rights to SQL Server so that it can run "SELECT @@servername" regularly. By default, the account that runs the cluster service is configured as an administrator on all nodes in the cluster, and the BUILTIN\Administrators group has permission to log into SQL Server. These settings change only if you change permissions on the cluster nodes.
  If the BUILTIN\Administrators account is removed, ensure that the account that the Cluster Service is running under can log into SQL Server for the IsAlive check. If it cannot, the IsAlive check will fail. At a minimum, the MSCS Cluster Service account must have public rights to SQL Server so that it can run @@servername on a regular basis.
• When you install MSCS, it is very important to use separate service accounts to log on to MSCS and SQL Server. Otherwise, the cluster service password cannot be changed using the cluster command.
• When using MSCS, one node must be in control of the shared SCSI bus prior to the other node coming online. Failure to do this can cause application failover to go into an online pending state and either prevent failover to the other node, or totally fail. If your cluster system has a proprietary install process, the proprietary process should be used.

Install Microsoft Distributed Transaction Coordinator

• Before installing SQL Server 2005 on a failover cluster, determine whether the Microsoft Distributed Transaction Coordinator (MSDTC) cluster resource must be created. If you are installing only the Database Engine, the MSDTC cluster resource is not required. If you are installing the Database Engine and SSIS, Notification Services, or Workstation Components, you must install MSDTC. This requirement applies to both Windows 2000 and Windows Server 2003 operating systems.
  The MSDTC transaction manager, MSDTC proxy, and Component Services administrative tools are installed on each node of the Windows-based server cluster. The cluster uses Microsoft Cluster Services (MSCS) as part of the setup of the Windows-based server cluster.
  To manually configure MSDTC on a Windows Server 2003 operating system (running MSCS), see the Knowledge Base articles How to configure Microsoft Distributed Transaction Coordinator on a Windows 2003 cluster and How to enable network DTC access in Windows Server 2003.
  To help ensure availability between multiple clustered applications, Microsoft highly recommends that the MSDTC have its own resource group and resources. If MSDTC cannot be configured to have its own resource group, the recommended alternate choice is to use the Cluster group and Quorum drive.

Configure Microsoft Distributed Transaction Coordinator

• After you install the operating system and configure your cluster, you must configure MSDTC to work in a cluster by using the Cluster Administrator. Failure to cluster MSDTC will not block SQL Server Setup, but SQL Server application functionality may be affected if MSDTC is not properly configured.
  Any process running on any node in the cluster can use MSDTC. These processes simply call the MSDTC proxy, and the MSDTC proxy automatically forwards MSDTC calls to the MSDTC transaction manager, which controls the entire cluster.
  If the node running the MSDTC transaction manager fails, the transaction manager is automatically restarted on another node in the cluster. The newly restarted transaction manager reads the MSDTC log file on the shared cluster disk to determine the outcome of pending and recently completed transactions.
  Resource managers reconnect to the transaction manager and perform recovery to determine the outcome of pending transactions. Applications reconnect to MSDTC so they can initiate new transactions.
  For example, suppose that the MSDTC transaction manager is active on system B. The application program and resource manager on system A call the MSDTC proxy. The MSDTC proxy on system A forwards all MSDTC calls to the MSDTC transaction manager on system B.
  If system B fails, the MSDTC transaction manager on system A takes over. It reads the entire MSDTC log file on the shared cluster disk, performs recovery, and then serves as the transaction manager for the entire cluster.

Other Software Considerations

• Ensure that all cluster nodes are configured identically, including COM+, disk drive letters, and users in the administrators group.

• Verify that the cluster interconnect (heartbeat) is properly configured. For more information, see the Knowledge Base article, Recommended private "Heartbeat" configuration on a cluster server.

• Verify that you have cleared the system logs in all nodes and viewed the system logs again. Ensure that the logs are free of any error messages before continuing.

• For SQL Server 2005 installations in side-by-side configurations with previous versions of SQL Server, SQL Server 2005 services must use accounts found only in the global domains group. Additionally, accounts that are used by SQL Server 2005 services must not appear in the local Administrators group. Failure to comply with this guideline will result in unexpected security behavior.

• If you install SQL Server 2005 into a Windows 2000 cluster group with multiple disk drives and choose to place your data on one of the drives, the SQL Server resource is set to be dependent only on that drive. To put data or logs on another or additional disk resources, you must first add a dependency to the SQL Server resource for the additional disk. For more information, see How to: Add Dependencies to a SQL Server 2005 Resource.

• If you are deploying Windows 2000 or Windows Server 2003 cluster nodes in an environment where there are no pre-existing Microsoft Windows 2000, or Windows Server 2003 domain controllers, see Windows 2000 and Windows Server 2003 cluster nodes as domain controllers.

• To use encryption, install the server certificate with the fully qualified DNS name of the MSCS cluster on all nodes in the SQL Server failover cluster. For example, if you have a two-node cluster, with nodes named "Test1.DomainName.com" and "Test2.DomainName.com" and a SQL Server failover cluster instance named "Virtsql", you must get a certificate for "Virtsql.DomainName.com" and install the certificate on the test1 and test2 nodes. Then you can select the Force protocol encryption check box on the SQL Server Configuration Manager to configure your failover cluster for encryption.

  Important

  Do not select the Force protocol encryption check box until you have certificates installed on all participating nodes in your failover cluster instance.

• Verify that anti-virus software is not installed on your MSCS cluster. For more information, see the Knowledge Base article, Antivirus software may cause problems with cluster services.

• SQL Server 2005 is not supported on Windows Server 2003 Terminal Server. For more information, see the Knowledge Base article, SQL Server 2000 is not supported on Windows Server 2003 Terminal Server application server.

• Verify that the disk where SQL Server will be installed is uncompressed. If you attempt to install SQL Server to a compressed drive, SQL Server Setup fails.

• When naming a cluster group for your failover cluster installation, you must not use any of the following characters in the cluster group name:

  • Less than operator (<)
  • Greater than operator (>)
  • Double quote (")
  • Single quote (')
  • Ampersand (&)
    Also verify that existing cluster group names do not contain unsupported characters.

Network Considerations

• Verify that you have disabled NetBIOS for all private network cards before beginning SQL Server Setup.

• The network name and IP address of your SQL Server should not be used for any other purpose, such as file sharing. If you want to create a file share resource, use a different, unique network name and IP address for the resource.

  Important

  Microsoft recommends that you do not use file shares on data drives, as they can affect SQL Server behavior and performance.

• Even though SQL Server 2005 supports both named Pipes and TCP/IP Sockets over TCP/IP within a cluster, Microsoft recommends that you use TCP/IP Sockets in a clustered configuration.

Other Considerations

• To create a failover cluster, you must be a local administrator with permissions to logon as a service, and to act as part of the operating system on all nodes of the failover cluster instance.
• Before you install or update a SQL Server failover cluster, disable all applications and services that might use SQL Server components during installation, but leave the disk resources online.
• Create domain groups for the clustered services that will be installed as part of your SQL Server 2005 failover cluster. SQL Server service, SQL Server Agent service, Analysis Services service, and Full-Text Search service must run as domain accounts that are members of the global or local domain group. If necessary, ask your domain administrator for the names of existing domain groups, or to create domain groups for your failover cluster. For more information, see Domain Groups for Clustered Services.
• SQL Server failover clustering is not supported where cluster nodes are domain controllers.
• Configure Domain Name Service (DNS) or Windows Internet Name Service (WINS). A DNS server or WINS server must be running in the environment where your SQL Server failover cluster will be installed. SQL Server Setup requires dynamic domain name service (DDNS) registration of the SQL Server IP interface virtual reference. If the dynamic registration cannot be completed, Setup fails and the installation is rolled back. If no dynamic registration is available, you must have pre-registered your server in DNS.
• ISA server is not supported on Windows Clustering, and therefore is not supported on SQL Server failover clusters.
• Review content in Security Considerations for a SQL Server Installation.
• Review content in Check Parameters for the System Configuration Checker.
• Consider whether the SQL Server tools, features, and components you want to use are supported with failover clustering. For more information, see Failover Clustering.
• Consider how you will monitor and maintain your failover cluster to achieve your high availability goals. For more information, see Maintaining a Failover Cluster and Using SQL Server Tools with Failover Clustering.
• To reduce the time required to install a SQL Server 2005 failover cluster, you can pre-install Microsoft .NET Framework version 2.0 on all failover cluster nodes before running SQL Server Setup.

See Also

Concepts

Installing a Failover Cluster

Other Resources

Hardware and Software Requirements for Installing SQL Server 2005
Check Parameters for the System Configuration Checker
Security Considerations for a SQL Server Installation

Help and Information

Getting SQL Server 2005 Assistance

Change History