This topic has not yet been rated - Rate this topic

Prerequisites, Restrictions, and Recommendations for AlwaysOn Client Connectivity (SQL Server)

SQL Server 2012

The SQL Server 2012 Release Notes provides information about AlwaysOn Availability Groups support for client connectivity, as follows::

  • Driver support

  • MultiSubnetFailover keyword and associated features

  • Workarounds for using ADO.NET with .NET Framework 4.0 or SQL Native Client 11.0 OLEDB for multi-subnet failover.

For more information, see "5.7.1 Client-Connectivity for AlwaysOn Availability Groups" in the SQL Server 2012 Release Notes.

  • Availability group listeners support only the TCP/IP protocol. To connect to an availability group listener, a client must use a TCP connection string.

  • To avoid potential NetBIOS conflicts, we recommend that you use a unique 15-character prefix for every availability group listener name. If two WSFC clusters are controlled by the same Active Directory and you try to create availability group listeners in both clusters using names with more than 15 characters and with an identical 15 character prefix, you will get an error reporting that the Virtual Network Name resource could not be brought online.

    For information about prefix naming rules for DNS names, see Assigning Domain Names, in the Windows Server 2008 and Windows Server 2008 R2 documentation.

    Arrow icon used with Back to Top link [Top]

Depending on your cluster topology, several additional Windows Server 2008 Service Pack 2 (SP2) or Windows Server 2008 R2 hotfixes might be applicable for supporting connections to availability groups. The following table identifies these hotfixes. The hotfixes can be installed in any order.

Note Note

For information about all the hotfixes that support AlwaysOn Availability Groups, see Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server).

     

Applies to Win 2008 SP2

Applies to Win 2008 R2 SP1

To Support…

Hotfix

Link

Checkbox

    √

    √

Internet Protocol Security (IPsec)

If your environment uses IPsec connections, you could experience a long time delay (about two or three minutes) when a client computer reestablishes the IPsec connection to a virtual network name (in this context, to connect to the availability group listener). If you use IPsec connections, we recommend that you review the specific scenarios detailed in Knowledge Base article (KB 980915).

KB 980915:  A long time delay occurs when you reconnect an IPSec connection from a computer that is running Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2

Checkbox

    √

    √

IPv6

If your Windows Server topology uses IP version 6 (IPv6), the WSFC Cluster service requires about 30 seconds to fail over the IPv6 IP address. This causes clients to wait for about 30 seconds to reconnect to the IPv6 IP address.

If you use IPv6, we recommend that you review the specific scenarios detailed in Knowledge Base article 2578103 or 2578113, depending on your Windows Server operating system.

Checkbox

    √

    √

No Router Between cluster and application server

If no router exists between the failover cluster and the application server, the Cluster service fails over network-related resources slowly. This delays client reconnections after an availability group fails over. In the absence of a router, we recommend that you review the specific scenarios detailed in Knowledge Base article 2582281 and install the hotfix, if applicable to your environment.

KB 2582281:  Slow failover operation if no router exists between the cluster and an application server

Checkbox

    √

Faster failover to local replicas

If a WSFC node is running Windows Server 2008 R2 Service Pack 1 (SP1), ensure that the hotfix described in Knowledge Base article 2687741 is installed.

This hotfix improves the performance of AlwaysOn Availability Groups failover to local replicas.

KB 2687741:  A hotfix that improves the performance of the "AlwaysOn Availability Group" feature in SQL Server 2012 is available for Windows Server 2008 R2

Arrow icon used with Back to Top link [Top]

Note Note

For information about all the server-instance prerequisites and requirements for using AlwaysOn Availability Groups, see Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server).

To Support…

Prerequisite

Links

Checkbox

Keberos

If you want an availability group to work with Kerberos:

  • All server instances that host an availability replica for the availability group must use the same SQL Server service account.

  • The domain administrator needs to manually register a Service Principal Name (SPN) with Active Directory on the SQL Server service account for the virtual network name (VNN) of the availability group listener. If the SPN is registered on an account other than the SQL Server service account, authentication will fail.

Important note Important

If you change the SQL Server service account, the domain administrator will need to manually re-register the SPN.

Register a Service Principal Name for Kerberos Connections

Brief explanation:

Kerberos and SPNs enforce mutual authentication. The SPN maps to the Windows account that starts the SQL Server services. If the SPN is not registered correctly or if it fails, the Windows security layer cannot determine the account associated with the SPN, and Kerberos authentication cannot be used.

Note Note

NTLM does not have this requirement.

Arrow icon used with Back to Top link [Top]

The creation of a new availability group listener may fail upon creation because you have reached an Active Directory quota for the participating cluster node machine account. For more information, see the following articles:

Arrow icon used with Back to Top link [Top]

For information about the permissions required for creating or modifying an availability group listener, see Create or Configure an Availability Group Listener (SQL Server).

Did you find this helpful?
(1500 characters remaining)

Community Additions

ADD
© 2013 Microsoft. All rights reserved.