Before Installing Failover Clustering
Before you install a SQL Server failover cluster, you must select the hardware and the operating system on which SQL Server 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 items below.
Verify Your Hardware Solution
If the cluster solution includes geographically-dispersed cluster nodes, additional items like network latency and shared disk support must be verified. The entire solution must be on the Geographic Cluster Hardware Compatibility List. For more information, see Windows clustering and geographically separate sites in the Microsoft Knowledge Base.
SAN configurations are also supported on Windows 2000 Advanced Server and Datacenter Server editions. The Windows Catalog and Hardware Compatibility List category "Cluster/Multi-cluster Device" lists the set of SAN-capable storage devices that have been tested and are supported as SAN storage units with multiple MSCS clusters attached. By matching the devices on this list with the complete cluster configurations defined in the Windows Catalog and Hardware Compatibility List cluster category, it is possible to deploy a set of Windows servers and clusters on a SAN fabric with shared storage devices in a way that is supported by Microsoft. For more information, see The Datacenter Program and Windows 2000 Datacenter Server Product in the Microsoft Knowledge Base.
If you deploy a SQL Server failover cluster on iSCSI technology components, we recommend that you use appropriate caution. For more information, see Support for SQL Server 2000 on iSCSI technology components in the Microsoft Knowledge Base.
For support information, see SQL Server support policy for Microsoft Clustering in the Microsoft Knowledge Base.
Consider quorum disk resource sharing. In a server cluster, the quorum disk contains a master copy of the server cluster configuration, and 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 an entire cluster disk for use as the quorum disk, resources other than the quorum resource may be permitted to access the quorum disk.
However, making the quorum resource share the same disk with other resources forces you to choose between two undesirable alternatives. Either you must configure the resource so that its failure does not affect the group, or you must allow the group to 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 along with the rest of the group that contains both the quorum resource and the failed resource. As a result, the entire cluster is offline for as long as it takes the group to fail over.
For more information about proper quorum drive configuration, see the Microsoft Knowledge Base article, Quorum Drive Configuration Information.
To install a SQL Server failover cluster when the source installation files and the cluster exist on different domains, copy the installation files to the current domain available to the SQL Server failover cluster.
Verify Your Operating System Settings
Make sure that your operating system is installed properly and designed to support failover clustering. The following table is a list of SQL Server editions and the operating systems that support them.
Observação
SQL Server 2008 R2 Evaluation has the same hardware and software requirements as SQL Server 2008 R2 Datacenter.
SQL Server edition |
Windows Server 2003 Enterprise SP2 |
Microsoft Windows 2003 Datacenter Server SP2 |
Microsoft Windows 2008 Enterprise |
Microsoft Windows 2008 Datacenter Server |
Microsoft Windows 2008 R2 Enterprise |
Microsoft Windows 2008 R2 Data Center |
SQL Server 2008 R2 Datacenter (64-bit) IA641 |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
SQL Server 2008 R2 Datacenter (64-bit) x641 |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
SQL Server 2008 R2 Datacenter (32-bit) |
Yes |
Yes |
Yes |
Yes |
||
SQL Server 2008 R2 Enterprise (64-bit) IA641 |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
SQL Server 2008 R2 Enterprise (64-bit) x641 |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
SQL Server 2008 R2 Enterprise (32-bit) |
Yes |
Yes |
Yes |
Yes |
||
SQL Server 2008 R2 Developer (64-bit) IA641 |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
SQL Server 2008 R2 Developer (64-bit) x641 |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
SQL Server 2008 R2 Developer(32-bit) |
Yes |
Yes |
Yes |
Yes |
||
SQL Server 2008 R2 Standard (64-bit) x641 |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
SQL Server 2008 R2 Standard (32-bit) |
Yes |
Yes |
Yes |
Yes |
SQL Server 2008 R2 clusters are not supported in WOW mode. That includes upgrades from SQL Server 2000 and SQL Server 2005 which had been originally installed in WOW. For those the only upgrade option is to install the new version side by side and migrate. For SQL Server 2000 IA64, in-place upgrade is not supported.
For more information, see Hardware and Software Requirements for Installing SQL Server 2008 R2.
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 dialog.
SQL Server supports mount points; the clustered installations of SQL Server are limited to the number of available drive letters. Assuming that you use only one drive letter for the operating system, and all other drive letters are available as normal cluster drives or cluster drives hosting mount points, you are limited to a maximum of 25 instances of SQL Server per failover cluster.
A mounted volume, or mount point, allows you to 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.
Additional mount point considerations for SQL Server 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. Volume GUIDs are not supported in this release.
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 validates drive configuration as part of a failover cluster installation.
SQL Server Setup automatically sets dependencies between the SQL Server cluster group and the disks that will be in the failover cluster. Do not set dependencies for disks before Setup.
During SQL Server 2008 R2 Failover Cluster installation, computer object (Active Directory computer accounts) for the SQL Server Network Resource Name is created. In a Windows 2008 cluster, the cluster name account (computer account of the cluster itself) needs to have permissions to create computer objects. For more information, see Failover Cluster Step-by-Step Guide: Configuring Accounts in Active Directory. If you are installing the SQL Server cluster on a Windows 2003 cluster, the cluster service needs to have the permissions to create the computer objects. For more information, see the following Microsoft Knowledge Base articles:
To enable Kerberos authentication with SQL Server, see How to use Kerberos authentication in SQL Server in the Microsoft Knowledge Base.
Configure Microsoft Cluster Server
Microsoft Cluster Server (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 Datacenter, SQL Server Enterprise or SQL Server Standard in conjunction with MSCS. SQL Server Datacenter, and SQL Server Enterprise supports failover clusters with up to 8 nodes. SQL Server Standard supports two-node failover clusters.
For more information about installing and configuring MSCS on Windows Server 2003, see Server clusters.
The resource DLL for the SQL Server service exports two functions used by MSCS Cluster manager to check for availability of the SQL Server resource. There is a simple check, LooksAlive, that queries the service status through the Windows NT Service Control Manager. There is also a more stringent check, IsAlive, that 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 by 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 not configured as an administrator on nodes in the cluster, and the BUILTIN\Administrators group does not have permission to log into SQL Server. These settings change only if you change permissions on the cluster nodes.
Ensure that the group or 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 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 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, Workstation Components, or if you will use distributed transactions, you must install MSDTC. Note that MSDTC is not required for Analysis Services-only instances.
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.
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 installations in side-by-side configurations with previous versions, SQL Server services must use accounts found only in the global domains group. Additionally, accounts used by SQL Server services must not appear in the local Administrators group. Failure to comply with this guideline will result in unexpected security behavior.
Windows Server 2003 cluster nodes in an environment where there are no pre-existing Windows Server 2003 domain controllers, see Windows 2000 and Windows Server 2003 cluster nodes as domain controllers.
Install prerequisite software - Before running Setup to install or upgrade to SQL Server 2008 R2, install the following prerequisites to reduce installation time. You can install prerequisite software on each failover cluster node and then restart nodes once before running Setup.
.NET Framework 3.5 SP1. Setup does not install .NET Framework 3.5 SP1 on a clustered operating system. You must install .NET Framework 3.5 SP1 before you run Setup. To avoid problems with the .NET Framework 3.5 installer, ensure that the Windows Update Service is running.
Windows Installer 4.5.
If you are using Windows Server 2003 SP2, install hotfix 937444. This is a requirement for the FILESTREAM feature of the Database Engine Services.
SQL Server Setup support files. You can install these files by running SqlSupport.msi located on your SQL Server 2008 R2 installation media.
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.
Importante
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 Microsoft Knowledge Base article, Antivirus software may cause problems with cluster services.
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, Port, and Firewall 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.
Importante
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 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.
To ensure correct failover cluster functionality, add exceptions to firewall configuration settings for the SQL Server port, SQL Browser port, File and Printer Sharing (TCP 139/445 and UDP 137/138), and Remote Procedure Call (TCP port 135).
Note that ISA server is not supported on Windows Clustering and consequently is also not supported on SQL Server failover clusters.
The Remote Registry service must be up and running.
Remote Administration must be enabled.
For the SQL Server port, use SQL Server Configuration Manager to check the SQL Server network configuration for the TCP/IP protocol for the instance you want to unblock. You must enable the TCP port for IPALL if you want to connect to SQL Server using TCP after installation. By default, SQL Browser listens on UDP port 1434.
Failover cluster Setup operations include a rule that checks network binding order. Although binding orders might seem correct, you might have disabled or "ghosted" NIC configurations on the system. "Ghosted" NIC configurations can affect the binding order and cause the binding order rule to issue a warning. To avoid this situation, use the following steps to identify and remove disabled network adapters:
At a command prompt, type: set devmgr_Show_Nonpersistent_Devices=1.
Type and run: start Devmgmt.msc.
Expand the list of network adapters. Only the physical adapters should be in the list. If you have a disabled network adapter, Setup will report a failure for the network binding order rule. Control Panel/Network Connections will also show that adapter was disabled. Confirm that Network Settings in Control Panel shows the same list of enabled physical adaptors that devmgmt.msc shows.
Remove disabled network adapters before you run SQL Server Setup.
After Setup finishes, return to Network Connections in Control Panel and disable any network adapters that are not currently in use.
Other Considerations
To create a failover cluster, you must be a local administrator with permissions to log on 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.
On Windows Server 2008, service SIDs are generated automatically for use with SQL Server 2008 R2 services. For SQL Server 2008 R2 failover cluster instances upgraded from SQL Server 2000 or SQL Server 2005, existing domain groups and ACL configurations will be preserved.
Domain groups must be within the same domain as the machine accounts. For example, if the machine where SQL Server will be installed is in the SQLSVR domain which is a child of MYDOMAIN, you must specify a group in the SQLSVR domain. The SQLSVR domain may contain user accounts from MYDOMAIN.
On Windows Server 2003, create domain groups for the clustered services that will be installed as part of your SQL Server failover cluster. The SQL Server service, SQL Server Agent service, Analysis Services service, and iFTS service must run as domain accounts that are members of the domain group. If necessary, ask your domain administrator for the names of existing domain groups, or to create domain groups for your failover cluster.
If you are installing a SQL Server 2008 R2 failover cluster instance in a Windows 2000 mixed mode domain, you must use domain global groups for SQL Server Clustered Services.
Observação
Windows 2000 domain controllers can operate in mixed mode and native mode. Mixed mode allows down-level domain controllers in the same domain.
SQL Server failover clustering cannot be installed 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 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.
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 Getting Started with SQL Server 2008 R2 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.