Windows Cluster Types

The purpose of this article is to give in depth knowledge about all type of Windows Server Failover Cluster, their working principles, basic prerequisites, configuration parameter and use cases of each type of them so that you have a crystal clear idea about any cluster type you may be building. This article will be more like a case study about all types of clusters rather than defining the steps of building a particular cluster type.

Note: You should have fundamental knowledge of Windows Failover Clusters to best understand this article.

Summary/Purpose

Introduction to Windows Server Failover Cluster (WSFC)
What is Quorum in WSFC?
Why Quorum is necessary?
Types of Quorum
5.1 Node Majority
5.2 Node and Disk Majority (Disk Witness)
5.3 Node and File Share Majority (File Share Witness)
5.2 No Majority: Disk Witness(not recommended)
What is MSDTC?
Do we need MSDTC for SQL Installation?
Types of Cluster
8.1 Active/Active Cluster
8.2 Active/Passive Cluster
8.4 Always On Availability group with WSFC
8.5 File Cluster
8.6 Geo Cluster
8.6.1 Geo Cluster without Active/Passive
8.6.2 Geo Cluster with Active/Passive
Reference links

Introduction to Windows Server Failover Cluster (WSFC)

A Windows Server Failover Cluster (WSFC) is a group of independent servers that work together to increase the availability of applications and services. SQL Server takes advantage of WSFC services and capabilities to support Always On availability groups and SQL Server Failover Cluster Instances.

NOTE: i) LUNS used in VMs for SQL Failover cluster are called ‘RDM LUNS’
ii) LUNS used in Physical Servers for SQL Failover cluster are called ‘Shared LUNs’

What is Quorum in WSFC?

In WSFC Quorum acts as a repository for the configuration information of cluster and called as cluster configuration database, which has two important jobs. Firstly, it tells the cluster which node should be active and the other thing that the quorum does is to intervene when communications fail between nodes.

Why Quorum is necessary?

The quorum configuration in a failover cluster determines the number of failures that the cluster can support in order to keep working. Once the threshold limit is reached, the cluster stops working. When network problems occur the cluster would be split into two pieces called “Split Brain” and cluster is said to have been partitioned. Node from one partition cannot communicate with the nodes in other partition, this is the time when both partition will try to keep the cluster application(resources) running. Since cluster application can’t be run on multiple servers simultaneously, and there should be a way to determine which partition should run the application(resource). This is where the quorum comes in. The partition that “owns” the quorum can continue running the application(resource). The other partition is removed from the cluster.

So Quorum is design to handle the scenario when there is a problem with communication between sets of cluster nodes, so that two servers do not try to simultaneously host a resource group and write to the same disk at the same time. This is known as a “split brain” and we want to prevent this to avoid any potential corruption to a disk by having two simultaneous group owners.

In cluster, Quorum is based on voting algorithm, each node in cluster serves a vote. Cluster requires more than half of the total votes to be online. These votes constitute a majority(that is a quorum), when network problems occur if the number of votes go below the majority cluster stops running.

Types of Quorum

In Windows Failover Clustering, there are following types of Quorum used:

Node Majority

Is recommended for clusters with an odd number of nodes and only cluster nodes have voting rights. in Node Majority Quorum is maintained when more than half the nodes are online.

Node and Disk Majority (Disk Witness)

In this type of Quorum we use a shared disk witness for quorum and is recommended for clusters with even number of nodes. It can sustain failures of half
the node if disk witness remains online. For example a 4 nodes cluster can sustain 2 nodes failure if disk witness is online.
If disk witness goes offline it can sustain half the nodes mines one. For example in 6 nodes cluster with a failed disk witness could sustain two(3-1=2) node failure. Disk witness can be used in Active/Active and Active/Passive cluster types.

Node and File Share Majority (File Share Witness)

In this type of Quorum we use file share witness for quorum and works in a similar way to Node and Disk Majority. File Share witness can be used in Active/Active and Active/Passive cluster type. Note: In Geo Cluster (Multisite Cluster) only File Share witness can be used.

No Majority: Disk Witness(not recommended)

In this type only shared disk has vote. Cluster can sustain failures of all nodes if shared disk is online. However, this configuration is not recommended because the disk might be a single point of failure.

What is MSDTC?

MSDTC is known as Microsoft Distributed Transaction Coordinator. MSDTC is used by SQL Server and other applications when they want to make a distributed transaction between more than one machine. A distributed transaction is simple a transaction that spans between two or more machines. The basic concept is that machine 1 starts a transaction, and does some work. It then connects to machine 2 and does some work. The work on machine 2 fails and is canceled. The work on machine 1 needs to then be rolled back.

Do we need MSDTC for SQL Installation?

With Windows Server 2008, 2012, 2016, 2019 and later you do not need to cluster MSDTC to utilize the functionality of the MSDTC service. This is because MSDTC was re-designed in Windows Servers 2008 and all new editions and unlike Windows Server 2003 if Windows Failover Cluster was installed you had to install MSDTC as well. This is no longer the case with new version of Windows servers (i.e. 2008, 2012, 2016, 2019 and later) since MSDTC is running locally, even with Failover Clustering installed.

SQL 2005 does require MSDTC for setup, since it uses a transactions to control setup on multiple nodes. However, SQL Server 2008/2008R2/2012, 2014, 2016, 2017 and SQL 2019 setup does NOT require MSDTC to install SQL.
MSDTC is only needed for transactions etc. after installation.
It requires 1GB of shared LUN and one Exnet IP to be configured.

Note: MSDTC is not required for Windows 2008R2 and above as per Microsoft.

More about MSDTC requirement: https://techcommunity.microsoft.com/t5/sql-server-support-blog/msdtc-recommendations-on-sql-failover-cluster/ba-p/318037

Types of Cluster

In Windows Clustering following types of cluster are configured:

Active/Active Cluster

Active/Active Cluster is used to run multiple SQL Server instances where each node has separate instance. Active/Active means that both nodes are active and accessing the shared disk resources, but are running independent SQL instances. In two-node Active/Active Cluster each node works as failover node for other node therefore if node A goes down the resources fail over to Node B, and node B will have 2 SQL instances running on it. Active/Active cluster setup is conceptually the same as having two Active/Passive nodes, except that one node must be a named instance.

Active/Active Clustering requirements:

One NTClus object with one Exnet IP only.
Depending on number of SQL instances SQLClus object will be same, for two SQL instances two SQLClus objects will be required.
Depending on number of SQLClus objects, each SQLClus object will have one Exnet IP and one Snet IP
At least one shared LUN is required for SQL database.
One 1GB shared LUN or a file-share for Quorum witness. If Quorum witness will be a file-share then it should be configured on another server, the preferred one is Active Directory server.
If MSDTC is requested then one 1GB shared LUN will be required with one Exnet IP.
SKUs for the SQL licensing go on the SQLClus devices.

Note: In Active/Active SQL cluster, SQL ports will be dynamic since two difference SQL instances will be running on a same server.

Active/Passive Cluster

In Active/Passive cluster only a single SQL instance runs on a single node at a given time. Active/Passive means only a single node will be active and accessing the shared disk resources,. In two-node Active/Passive SQL cluster node A will be active with 1 SQL instance and node B will be passive with no instances. If node A goes down the resources failover to node B.

Active/passive clustering requirements

One NTClus object with one Exnet IP only.
One SQLClus object with one Exnet and one Snet IP
At least one shared LUN is required for SQL database.
One 1GB shared LUN or a file-share for Quorum witness. If Quorum witness will be a file-share then it should be configured on another server, the preferred one is Active Directory server.
If MSDTC is requested then one 1GB shared LUN will be required with one Exnet IP.
SKUs for the SQL licensing go on the SQLClus device.
For Cluster Setup either customer domain is required.

Always On Availability group with WSFC

In Windows Server Failover Clustering, Always On Availability group is configured for high-availability and disaster recovery solution that provides an enterprise level of administration to database mirroring. In WSFC Always on availability group can be configured on a same datacenter called ‘simple AOAG’ cluster and on multiple datacenter called ‘Geo Cluster’.

Always On Availability group with WSFC requirements (Single Datacenter)

One NTClus object with one Exnet IP only.
Local drives are used, no shareddrives.
File-share for Quorum witness can be used only.
AOAGListener objects should be sku’d as per standard.
SKUs for the SQL licensing go on the DBs, not on the windows cluster device.
MSDTC device is not required.
Depending on number of nodes, SQL is installed as Standalone on each node with same instance name.
Enable ‘Always On Availability Group‘ feature in SQL Server Configuration Manager.
Keep same SA password for all SQL instances.
For Cluster Setup either customer domain is required.

File Cluster

File Cluster is used for ‘file share’ purpose and is built as Active/Passive Failover Cluster. There can be requirement when along with File Cluster, SQL Active/Passive Failover Cluster or SQL ‘Always On Availability group’ is also requested by the customer. So File Cluster can be built with both ‘SQL Always On Availability Group’ and ‘SQL Active/Passive failover cluster’ within a same datacenter.

File Cluster requirements:

One NTClus object with one Exnet IP only.
One FileClus object with one Exnet and one Snet IP
One shared LUN is must required for File Server role.
One 1GB shared LUN or a file-share for Quorum witness. If Quorum witness will be a file-share then it should be configured on another server, the preferred one is Active Directory server.
If SQL Active/Passive Cluster is also requested:
One SQLClus object with Exnet, Snet IP(s) along with same NTClus and Fileclus object as mentioned above.
Shared drive(s) for SQL database.
If MSDTC is also requested then one 1GB shared LUN will be required with one Exnet IP.
SKUs for the SQL licensing go on the SQLClus device.
For Cluster Setup either customer domain is required.

Geo Cluster

Geo Cluster Also known as multi-subnet failover cluster. Geo 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. As there is no shared storage that all the nodes can access, data should be replicated between the data storage on the multiple subnets. With data replication, there is more than one copy of the data available. Therefore, a geo cluster failover cluster provides a disaster recovery solution in addition to high availability.

Geo Cluster can be configured in two ways:

Geo Cluster without Active/Passive(Default Geo Cluster)
Geo Cluster with Active/Passive

Geo Cluster requirements(without Active/Passive)

Prod. node and NTClus object should be in same VLAN.
One NTClus object should have two IPs assigned in core, one from Prod. datacenter and one from DR datacenter, DR site will stay inactive.
Local drives are used, no shared drives.
File-share for Quorum witness can be used only.
AOAGListener objects should be sku’d as per standard.
SKUs for the SQL licensing go on the DB nodes.
Build ‘NT-cluster’ with Prod node first.
Check Connectivity between Prod. and DR nodes.
Enable ‘Always On Availability Group‘ feature in ‘SQL Server Configuration Manager’.
Keep same SA password for all SQL instances.
For Cluster Setup either customer domain oris required.

Note: Disk size of DR. nodes should be either equal or more than the disk size of Prod. nodes for a smooth failover.

Geo Cluster Doc: Geo Cluster Configuration

Geo Cluster with Active/Passive

In Active/Passive Geo Cluster Prod. nodes have different set of shared drives built as Active/Passive Cluster in Prod. datacenter, similarly DR. nodes have different set of shared drives and built as Active/Passive Cluster in DR datacenter. Means shared drives from Prod. datacenter won’t be accessible by DR. datacenter and shared drives of DR. datacenter won’t be accessible by Prod. datacenter. However, all the DB nodes and NTClus device should be communicating to each other and all required cluster ‘Ports’ should be opened. This setup requires 4 DB servers, 2 in Prod. datacenter and 2 in DR datacenter. Prod. and DR nodes will have different SQL instances running.

Ports requirement for Geo Cluster:

Application	Protocol	Ports
Cluster Service	TCP & UDP	3343
RPC	TCP	135
Cluster Administrator	UDP	137
NetBIOS	UDP	138
Randomly allocated high UDP ports	UDP	49152 and 65535
NetBIOS	TCP	139
File share(SMB)	TCP & UDP	445
AD port	TCP & UDP	53
Kerberos	TCP & UDP	464

Geo Cluster requirements(with Active/Passive)

PROD. site Nodes and NTClus object should be in same VLAN.
One NTClus object with two IPs assigned in core, one from Prod. datacenter and one from DR datacenter, DR site will stay inactive.
Two SQLClus objects for two different SQL instances, one from Prod. and another from DR.
Both SQLClus devices will have their own Exnet IP(s) and Snet(IPs).
Prod. nodes have different set of shared drives and DR. nodes have different set of shared drives.
For Quorum, File share witness should be used.
AOAGListener objects should be sku’d as per standard.
SKUs for the SQL licensing go on the SQLClus devices.
Build ‘NT-cluster‘ with Prod. node first.
Check Connectivity between Prod. and DR site nodes.
Enable ‘Always On Availability Group‘ feature in ‘SQL Server Configuration Manager’.
For Cluster Setup either customer domain is required.

Note: In Geo Cluster with Active/Passive, Prod. and DR should have same number of nodes and Shared LUN’s should be configured independently in Prod. and DR. In a three nodes Geo cluster (2 in Prod. and 1 in DR) if Prod. nodes have shared LUNs and DR node has local drives then Active/Passive Cluster will be built in Prod. datacenter and single node in DR will be built as standalone having Always On Available feature enabled on all three nodes.