Windows allows us to create two or more node failover clusters between servers.

SQL Server Availability Groups were introduced in SQL Server 2012 as a replacement to Database Mirroring. While Database Mirroring was intended to be either a high availability OR disaster recovery solution, Availability Groups can be used for both local high availability AND disaster recovery. You can have multiple Availability Group replicas, depending on the version of SQL Server that you are using.

Here at Ibmi Media, as part of our Server Management Services, we regularly help our Customers to perform related Windows queries.

In this context, we shall look into Workgroup Failover Cluster without Active Directory.

Workgroup Failover Cluster without Active Directory in Windows

The new version of Windows allows us to create two or more nodes failover clusters between servers joined to different domains.

We can also create nodes between workgroup servers – a so-called Workgroup Cluster.

Obviously, we need to install Windows Server 2016 on all cluster nodes.

It supports the following cluster scenarios:

Service          Status                          Comment
SQL server       Supported                        It is recommended to use the integrated SQL Server authentication
File server      Supported, but not recommended   Kerberos authentication for SMB is not supported
Hyper-V          Supported, but not recommended   Live Migration is not supported, only Quick migration is available
Message Queuing  Not supported                    MSMQ stores its properties in Active Directory

On all future cluster nodes:

1. Initially, we install the Failover Clustering role:

Install-WindowsFeature Failover-Clustering –IncludeManagementTools<

2. Then we create a local account with the administrator privileges with the same passwords:

net user /add clustadm Sup33P@ssw0Rd!
net localgroup administrators clustadm /add

3. In case of the error, Requested Registry access is not allowed, we edit the remote UAC parameter in the registry:

New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1

4. We set the same primary DNS suffix. It enables the cluster servers to communicate by FQDN names.

5. Then we uncheck Register DNS connection addresses in the Advanced TCP/IP Settings.

6. We make changes to the host’s file so that the servers can resolve the names of other cluster members and the name of the cluster.

We add the names to c:\windows\system32\drivers\etc\hosts as follows:

Set file=”%windir%\System32\drivers\etc\hosts”
echo 192.168.1.21 clust-host1 >> %file%
echo 192.168.1.21 clust-host1.mylocal.net >> %file%
echo 192.168.1.22 clust-host2 >> %file%
echo 192.168.1.22 clust-host2.mylocal.net >> %file%
echo 192.168.1.20 cluster1 >> %file%
echo 192.168.1.20 cluster1.mylocal.net>> %file%

To validate cluster nodes, we run:

test-cluster -node “clust-host1.mylocal.net”,” clust-host2.mylocal.net”

Then to create a cluster using PowerShell, we run:

New-Cluster -Name cluster1 -Node clust-host1.mylocal.net, clust-host2.mylocal.net -AdministrativeAccessPoint DNS -StaticAddress 192.168.1.20

We can check the status of the cluster and its components using get-cluster and get-clusterresource cmdlets.

To connect the cluster through a GUI, we need to use Failover Cluster Manager snap-in.

Then, using Connect to cluster menu item, we can connect to the created cluster.

Suppose, the cluster has an even number of servers, then we have to configure a witness resource. 

However, we cannot use the SMB shared folder as a quorum witness.

It supports two modes:

• Disk Witness – a shared disk.
• Cloud Witness – a cloud disk resource in Azure.

[Need help with the cluster settings? We'd be happy to assist. ]