Install Windows Server 2008 Failover Cluster
This article describes how to install service packs or hotfixes on a Windows Server failover cluster. Applying a service pack or hotfix to a server cluster is the same as applying a service pack or hotfix to Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 (although Windows Server 2012 requires a different process). The goal of this series of tips is to be able to help DBAs who may be charged with installing SQL Server on a Windows Server 2008 cluster. Prepare the cluster nodes I will be working on a 2-node cluster throughout the series and you can extend it by adding nodes later on.
SQL Server failover clustering provides high-availability support for an entire SQL Server instance. SQL Server failover clusters are built on top of Windows Server failover clusters. To create a SQL Server failover cluster, you need to first create the underlying Windows Server failover cluster.
A SQL Server failover cluster, also known as a failover cluster instance, consists of the following:
One or more Windows Server failover cluster nodes
A cluster resource group dedicated for the SQL Server failover cluster which contains the following:
Network name to access the SQL Server failover cluster
IP addresses
Shared disks used for the SQL Server database and log storage
Resource DLLs that control the SQL Server failover behavior
Check-pointed registry keys that are automatically kept in sync across the failover cluster nodes
A SQL Server failover cluster appears on the network as a single SQL Server instance on a single computer. Internally, only one of the nodes owns the cluster resource group at a time, serving all the client requests for that failover cluster instance. In case of a failure (hardware failures, operating system failures, application or service failures), or a planned upgrade, the group ownership is moved to another node in the failover cluster. This process is called failover. By leveraging the Windows Server failover cluster functionality, SQL Server failover cluster provides high availability through redundancy at the instance level.
SQL Server 2008 failover cluster setup uses a new architecture, enabling functionality that was not possible with the previous versions. The following are the key differences from the previous versions of SQL Server with respect to failover cluster functionality:
There is no remote execution on the cluster nodes.
To install, upgrade or maintain a SQL Server failover cluster on multiple nodes, you must run SQL Server Setup separately on each node of the failover cluster.
To add a node to an existing SQL Server failover cluster, you must run SQL Server Setup on the node that is to be added and choose the Add Node functionality. Do not run Setup on the node that owns the cluster to add another node.
Note
Add Node increases high availability for the existing failover cluster and does not cause any downtime.
There is no uninstall SQL Server failover cluster option. To uninstall a SQL Server failover cluster, run Setup with the Remove Node functionality on each of the nodes of the failover cluster to be removed.
To remove a node from a SQL Server failover cluster, you must run SQL Server Setup on the node that is to be removed and chose the Remove Node functionality. Do not run Setup on the owning node to remove another node.
If Remove Node is run on the node that owns the cluster, and there are other nodes in the failover cluster, it causes a failover to another cluster node before the node is removed.
If Remove Node is run on the node that owns the cluster and there is no other node in the failover cluster, it removes the entire SQL Server failover cluster instance.
There are two installation options:
Integrated failover cluster install with Add Node
Advanced/Enterprise installation
Rolling upgrade and patch support with minimal downtime.
Increased setup reliability.
Alignment with Windows Server 2008 failover cluster features:
Heterogeneous hardware and ISCSI support without a need for certified hardware.
The Windows Server 2008 cluster validation tool is used to validate the Windows cluster and block SQL Server Setup when problems are detected.
Service SIDs remove the requirement for domain groups on Windows Server 2008.
IPV6 and DHCP support.
Up to 16-node failover clusters.
Note
SQL Server limits you to two nodes for SQL Server Standard.
Not aligned with OR dependencies.
Add features to a SQL Server 2008 failover cluster. For example, you cannot add the Database Engine to an existing Analysis Services-only failover cluster or add a Analysis Services to an existing Database Engine-only failover cluster.
SQL Server Failover Cluster Installation options
Option 1: Integrated installation with Add Node
SQL Server integrated failover cluster installation consists of two steps:
Create and configure a single-node SQL Server failover cluster instance. At the completion of a successful configuration of the node, you have a fully functional failover cluster instance. At this time it does not have high-availability because there is only one node in the failover cluster.
On each node to be added to the SQL Server failover cluster, run Setup with Add Node functionality to add that node.
Option2: Advanced/Enterprise installation
SQL Server Advanced/Enterprise failover cluster installation consists of two steps:
On each node that will be part of the SQL Server failover cluster, run Setup with Prepare Failover Cluster functionality. This step prepares the nodes ready to be clustered, but there is no operational SQL Server instance at the end of this step.
After the nodes are prepared for clustering, run Setup on the node that owns the shared disk with the Complete Failover Cluster functionality. This step configures and completes the failover cluster instance. At the end of this step, you will have an operational SQL Server failover cluster instance.
Note
Either installation option allows for multi-node SQL Server failover cluster installation. Add Node can be used to add additional nodes for either option after a SQL Server failover cluster has been created.
Important
Note that the operating system drive letter for SQL Server install locations must match on all the nodes added to the SQL Server failover cluster.
When to Use Failover Clustering
Use failover clustering to:
Administer a failover cluster from any node in the clustered SQL Server configuration. For more information, see Installing a SQL Server 2008 Failover Cluster.
Allow one failover cluster node to fail over to any other node in the failover cluster configuration. For more information, see Installing a SQL Server 2008 Failover Cluster.
Configure Analysis Services for failover clustering. For more information, see How to: install Analysis Services on a failover cluster.
Execute full-text queries by using the Microsoft Search service with failover clustering. For more information, see Using SQL Server Tools with Failover Clustering.
Installing Failover Clustering
To use failover clustering, you must follow specific installation steps.
To install, configure, and maintain a SQL Server failover cluster, use SQL Server Setup. Use SQL Server Setup in a failover cluster to do the following:
Install SQL Server to create a failover cluster.
Before installing failover clustering, you must ensure that your system meets minimum requirements, and configure the Microsoft Cluster Service (MSCS). For more information on specific requirements for a failover cluster, see Before Installing Failover Clustering.
All nodes in a failover cluster must be of the same platform, either 32-bit or 64-bit, and must run the same operating system edition and version. Also, 64-bit SQL Server editions must be installed on 64-bit hardware running the 64-bit versions of Windows operating systems. There is no WOW64 support for failover clustering in this release.
Add or remove nodes from a failover cluster configuration without affecting the other cluster nodes. For more information, see How to: Add or Remove Nodes in a SQL Server Failover Cluster (Setup).
Specify multiple IP addresses for each failover cluster instance. You can specify multiple IP addresses for each server, allowing you to use all available network IP subnets. SQL Server limits you to one IP address per network.
Failover Clustering Support
In SQL Server, the number of nodes supported for failover clustering depends on the operating system and the edition of SQL Server. For a list of tools, features, and services supported with SQL Server failover clustering, see Features Supported by the Editions of SQL Server 2008.
See Also
Tasks
Concepts
Change History
Updated content |
|---|
Introduction section was revised to provide a detailed overview. |
Added a new section to describe failover cluster installation options. |
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 Windows Server Failover Clustering (WSFC), and review network, security, and considerations for other software that will run on your failover cluster.
If a Windows cluster has a local disk drive and the same drive letter is also used on one or more cluster nodes as a shared drive, you cannot install SQL Server on that drive.
You may also want to review the following topics to learn more about SQL Server failover clustering concepts, features and tasks.
| Topic Description | Topic |
|---|---|
| Describes SQL Server failover clustering concepts, and provides links to associated content and tasks. | Always On Failover Cluster Instances (SQL Server) |
| Describes SQL Server failover policy concepts, and provides links to configuring the failover policy to suit your organizational requirements. | Failover Policy for Failover Cluster Instances |
| Describes how to maintain and your existing SQL Server failover cluster. | Failover Cluster Instance Administration and Maintenance |
| Explains how to install Analysis Services on a Windows Server Failover Cluster (WSFC). | How to Cluster SQL Server Analysis Services |
Best Practices
Review SQL Server 2017 Release Notes
Install prerequisite software. Before running Setup to install or upgrade to SQL Server 2017, 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.
Windows PowerShell is no longer installed by SQL Server Setup. Windows PowerShell is a prerequisite for installing SQL Server 2017Database Engine components and SQL Server Management Studio. If Windows PowerShell is not present on your computer, you can enable it by following the instructions on the Windows Management Framework page.
.NET Framework 3.5 SP1 is no longer installed by SQL Server Setup, but may be required while installing SQL Server on older Windows operating systems. For more information, see SQL Server 2017Release Notes.
Microsoft Update package: To avoid computer restart due to .NET Framework 4 installation during setup, SQL Server 2017 setup requires a Microsoft update to be installed on the computer. If you are installing SQL Server 2014 (12.x) on Windows 7 SP1 or Windows Server 2008 SP2 this update is included. If you are installing on an older Windows operating system, download it from Microsoft Update for .NET Framework 4.0 on Windows Vista and Windows Server 2008.
.NET Framework 4: Setup installs .NET Framework 4 on a clustered operating system. To reduce installation time, you may consider installing .NET Framework 4 before you run Setup.
SQL Server Setup support files. You can install these files by running SqlSupport.msi located on your SQL Server 2017 installation media.
Verify that antivirus software is not installed on your WSFC cluster. For more information, see the Microsoft Knowledge Base article, Antivirus software may cause problems with cluster services.
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.
Ensure that all cluster nodes are configured identically, including COM+, disk drive letters, and users in the administrators group.
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.
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.
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 Failover Cluster installation, computer object (Active Directory computer accounts) for the SQL Server Network Resource Name is created. In a Windows Server 2008 cluster, the cluster name account (computer account of the cluster itself) needs to have permissions to create computer objects. For more information, see Configuring Accounts in Active Directory.
If you are using SMB File share as a storage option, the SQL Server Setup account must have SeSecurityPrivilege on the file server. To do this, using the Local Security Policy console on the file server, add the SQL Server setup account to Manage auditing and security log rights.
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.
- For more information about Windows Server 2008 and Windows Server 2008 R2, see Validating Hardware for a failover cluster and Support Policy for Windows Failover Clusters.
Verify that the disk where SQL Server will be installed is not compressed or encrypted. If you attempt to install SQL Server to a compressed drive or an encrypted drive, SQL Server Setup fails.
SAN configurations are also supported on Windows Server 2008 and Windows Server 2008 R2 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 WSFC clusters attached. Run cluster validation after finding the certified components.
SMB File Share is also supported for installing data files. For more information, see Storage Types for Data Files.
Warning
If you are using Windows File Server as a SMB File Share storage, the SQL Server Setup account must have SeSecurityPrivilege on the file server. To do this, using the Local Security Policy console on the file server, add the SQL Server setup account to Manage auditing and security log rights.
If you are using SMB file share storage other than Windows File server, please consult the storage vendor for an equivalent setting on the file server side.
SQL Server supports mount points.
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.
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.
Tip
The 25 instance limit can be overcome by using SMB file share option. If you use SMB file share as the storage option, you can install up to 50 SQL Server failover cluster instances.
Formatting a drive after mounting additional drives is not supported.
SQL Server failover cluster installation supports Local Disk only for installing the tempdb files. Ensure that the path specified for the tempdb data and log files is valid on all the cluster nodes. During failover, if the tempdb directories are not available on the failover target node, the SQL Server resource will fail to come online. For more information, see Storage Types for Data Files and Database Engine Configuration - Data Directories.
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 on iSCSI technology components.
For more information, see SQL Server support policy for Microsoft Clustering.
For more information about proper quorum drive configuration, see Quorum Drive Configuration Information.
To install a SQL Server failover cluster when the SQL Server 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.
Review Security Considerations
To use encryption, install the server certificate with the fully qualified DNS name of the WSFC 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.
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.
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.
On Windows Server 2008, service SIDs are generated automatically for use with SQL Server 2017 services. For SQL Server 2017 failover cluster instances upgraded from previous versions of SQL Server, 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.
SQL Server failover clustering cannot be installed where cluster nodes are domain controllers.
Review content in Security Considerations for a SQL Server Installation.
To enable Kerberos authentication with SQL Server, see How to use Kerberos authentication in SQL Server in the Microsoft Knowledge Base.
SQL Server failover cluster instance (FCI) requires the cluster nodes to be domain joined. The following configurations are not supported:
- SQL FCI on workgroup clusters.
- SQL FCI on Multi-Domain cluster.
- SQL FCI on Domain + Workgroup Clusters.
Review 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.
Important
We recommend that you do not use file shares on data drives, because 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, we recommend that you use TCP/IP Sockets in a clustered configuration.
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 adapters 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.
Verify Your Operating System
Make sure that your operating system is installed properly and is designed to support failover clustering. The following table is a list of SQL Server editions and the operating systems that support them.
| SQL Server edition | Windows Server 2008 Enterprise | Windows Server 2008 Datacenter Server | Windows Server 2008 R2 Enterprise | Windows Server 2008 R2 Datacenter Server |
|---|---|---|---|---|
| SQL Server 2014 (12.x) Enterprise (64-bit) x64* | Yes | Yes | Yes** | Yes** |
| SQL Server 2014 (12.x) Enterprise (32-bit) | Yes | Yes | ||
| SQL Server 2017 -bit) Developer (64 | Yes | Yes | Yes** | Yes** |
| SQL Server 2017 Developer (32-bit) | Yes | Yes | ||
| SQL Server 2017 Standard (64-bit) | Yes | Yes | Yes | Yes |
| SQL Server 2017 Standard (32-bit) | Yes | Yes |
*SQL Server clusters are not supported in WOW mode. That includes upgrades from previous versions of SQL Server failover clusters that were originally installed in WOW. For those the only upgrade option is to install the new version side by side and migrate.
**Supported for SQL Server multi-subnet failover clustering.
Additional Considerations for Multi-Subnet Configurations
The sections below describe the requirements to keep in mind when installing a SQL Server multi-subnet failover cluster. A multi-subnet configuration involves clustering across multiple subnets, therefore involves using multiple IP addresses and changes to IP address resource dependencies.
SQL Server Edition and Operating System Considerations
For information about the editions of SQL Server that support a SQL Server multi-subnet failover cluster, see Features Supported by the Editions of SQL Server 2016.
To create a SQL Server multi-subnet failover cluster, you must first create the Windows Server 2008 R2 multi-site failover cluster on multiple subnets.
SQL Server failover cluster depends on the Windows Server failover cluster to make sure that the IP dependency conditions are valid if there is a failover.
Windows Server 2008 R2 requires that all the cluster servers must be in the same Active Directory domain. Therefore, SQL Server multi-subnet failover cluster requires that all the cluster nodes be in the same Active Directory domain even if they are in different subnets.
IP Address and IP Address Resource Dependencies
The IP Address resource dependency is set to OR in a multi-subnet configuration. For more information, see Create a New SQL Server Failover Cluster (Setup)
Mixed AND-OR IP address dependencies are not supported. For example, <IP1> AND <IP2> OR <IP3> is not supported.
More than one IP address per subnet is not supported.
If you decide to use more than one IP address configured for the same subnet, you may experience client connection failures during SQL Server startup.
Related Content
For more information about Windows Server 2008 R2 multi-site failover, see Windows Server 2008 R2 Failover Clustering Site and Design for a Clustered Service or Application in a Multi-Site Failover Cluster.
Configure Windows Server Failover Cluster
Microsoft Cluster Service (WSFC) must be configured on at least one node of your server cluster. You must also run SQL Server Enterprise, SQL Server Business Intelligence, or SQL Server Standard in conjunction with WSFC. SQL Server Enterprise support failover clusters with up to 16 nodes. SQL Server Business Intelligence and SQL Server Standard supports two-node failover clusters.
The resource DLL for the SQL Server service exports two functions used by WSFC Cluster Manager to check for availability of the SQL Server resource. For more information, see Failover Policy for Failover Cluster Instances.
WSFC 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 BUILTINAdministrators group does not have permission to log into SQL Server. These settings change only if you change permissions on the cluster nodes.
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. DNS server configuration should allow cluster nodes to dynamically register an online IP address map to Network Name. If the dynamic registration cannot be completed, Setup fails and the installation is rolled back. For more information, see this knowledgebase article
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.
On Windows Server 2008 and Windows Server 2008 R2, you can install multiple instances of MSDTC on a single failover cluster. The first instance of MSDTC that is installed will be the cluster default instance of MSDTC. SQL Server will take advantage of an instance of MSDTC installed to the SQL Server local cluster resource group by automatically using the instance of MSDTC. However, individual applications can be mapped to any instance of MSDTC on the cluster.
The following rules are applied for an instance of MSDTC to be chosen by SQL Server:
Use MSDTC installed to the local group, else
Use the mapped instance of MSDTC, else
Use the cluster's default instance of MSDTC, else
Use the local machine's installed instance of MSDTC
Important
If the MSDTC instance that is installed to the local cluster group of SQL Server fails, SQL Server does not automatically attempt to use the default cluster instance or the local machine instance of MSDTC. You would need to completely remove the failed instance of MSDTC from the SQL Server group to use another instance of MSDTC. Likewise, if you create a mapping for SQL Server and the mapped instance of MSDTC fails, your distributed transactions will also fail. If you want SQL Server to use a different instance of MSDTC, you must either add an instance of MSDTC to the local cluster group of the SQL Server or delete the mapping.
Install Failover Cluster Manager
Configure Microsoft Distributed Transaction Coordinator
Step By Step Install Windows Server 2008
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.
See Also
Hardware and Software Requirements for Installing SQL Server 2016
Check Parameters for the System Configuration Checker
Failover Cluster Instance Administration and Maintenance