SQL Server

Some tips for SQL Server 2016 clustering

Some tips for SQL Server 2016 clustering

Avoid running other software on the SQL Server 2016 cluster nodes.

To increase SQL Server 2016 performance, SQL Server clusters should be dedicated

to SQL Server only.


Consider using Distributed Availability Groups (DAG) if you have two availability

groups residing on different Windows Server Failover Clusters (WSFC).

DAG enables you to associate two availability groups residing on different WSFC.

One of the main uses of DAG is for disaster recovery where the primary site is

geographically dispersed from the DR site.

Create a cluster resource group before installing SQL Server 2016 clustering.

Avoid installing SQL Server 2016 into the default cluster group. To create

cluster resource group dedicated for SQL Server 2016, you can use the Cluster

Administrator tool. You should also place all the shared array drives that

will be used by SQL Server 2016 in this group.

Before installing SQL Server 2016 clustering, turn off all power saving features.

Because the activation of the power saving features may cause a cluster failover,

you should turn off them before installing SQL Server 2016 clustering.

You can use cross-cluster migration of AlwaysOn Availability Groups for OS

upgrade.

SQL Server 2016 supports the cross-cluster migration of AlwaysOn Availability

Groups for deployments to a new Windows Server Failover Clustering cluster.

A cross-cluster migration moves one AlwaysOn availability group to the new

destination Windows Server Failover Clustering cluster with minimal downtime.

Consider using the multi-subnet failover clusters.

SQL Server 2016 multi-subnet failover cluster is a configuration where each

failover cluster node is connected to a different subnet or different set of

subnets. These subnets can be in the same location or in geographically

dispersed sites. A multi-subnet failover cluster provides a disaster recovery

solution in addition to high availability.

Use minimum services on your SQL Server 2016 cluster.

You can start these services manually when you will need them. For example,

if you do not need to use Internet Information Server (IIS), turn off the IIS service.


Set the static IP addresses for both the Public and Private networks.

If you plan to use two node cluster configuration, consider using an

Active/Passive configuration.

Because using an Active/Active configuration requires so many SQL Server 2016

licenses, as you have nodes in cluster, consider using an Active/Passive

configuration. With an Active/Passive configuration you must have only single

SQL Server 2016 license.


Consider configuring at least two DNS servers for the Public network cards.

By using so, you can improve fault tolerance and simplify administering and
monitoring tasks.


Avoid setup SQL Server 2016 cluster on the domain controllers.

To increase SQL Server 2016 performance, cluster nodes should be member

servers, not domain controllers.

Ensure that the Task Scheduler service turned on before you setup
SQL Server 2016 clustering.


Configure the not critical services so that its failure will not cause

SQL Server 2016 to failover.

For example, if you do not use the Full-Text Service, you can configure it

to not failover the cluster.

Ensure that all shared disks, including the quorum disk, were physically

attached to a shared bus.

You should make it to ensure that all shared disks can be seen from all nodes in the cluster.

Before installing SQL Server 2016 clustering, ensure that each cluster node

have identical hardware and software.

If the cluster nodes have different hardware or software it may cause problems

with installing SQL Server clustering.


If you configure a clustered SQL Server 2016 as a Distributor, ensure that

a snapshot folder is located on a shared folder on the cluster shared disk

resource.

If you implement replication on SQL Server 2016 clustered server and configure

a clustered SQL Server as a Distributor, SQL Server needs to have access to a

snapshot folder during the replication process. If a snapshot folder is not

located on a shared folder on the cluster shared disk resource then when

failover occurs, replication may stop working.

Ensure that each node in the cluster has two network adapters.

One of these network adapters will be used for the private network connections

(node-to-node connections) and other network adapter will be used for the public

network connections. Avoid using multi-port NICs.


Consider using the Cluster Shared Volumes as cluster shared disks.

In SQL Server 2016, AlwaysOn Failover Cluster Instances supports Clustered

Shared Volumes in both Windows Server 2008 R2 and Windows Server 2012.

Avoid using Services tool to start or stop the MSSQLServer or SQLServerAgent services.

You should use the Cluster Administrator instead of the Services tool to start

or stop SQL Server services. In other case, you may corrupt your SQL Server 2016 cluster.

When you install Cluster Service, choose a “Typical” installation.

Because “Typical” installation is suited to the most hardware configuration,

use this installation type in the most cases. Use “Advanced” installation type

only for the complex configurations, such as fiber channel switched fabric with

multiple switches.

Place the paging file on the local disk on each cluster node.

Placing the paging file on the shared array may cause performance problems and

improve the chance of a cluster failover.

Set the performance boost for the foreground applications to “None” on the

SQL Server cluster.

This ensures that background applications (SQL Server, for example) will get

higher priority than foreground applications.

You should proper configure the SQL Server 2016 service accounts.

Ensure that each SQL Server 2016 service account is a domain account and a

member of the Local Administrators group of each cluster node and a member of

the Domain Users group. Set the SQL Server 2016 service accounts passwords to

be not expired.

Avoid running any antivirus software on your SQL Server cluster.

Because antivirus software can degrade the total cluster’s performance,

consider running any antivirus software on the client computers, which

connect to cluster.