First published on MSDN on Aug 17, 2015
In Windows Server 2012 R2 and previous versions, a cluster could only be created between member nodes joined to the same domain. Windows Server 2016 breaks down these barriers and introduces the ability to create a Failover Cluster without Active Directory dependencies. Failover Clusters can now therefore be created in the following configurations:
- Single-domain Clusters: Clusters with all nodes joined to the same domain
- Multi-domain Clusters: Clusters with nodes which are members of different domains
- Workgroup Clusters: Clusters with nodes which are member servers / workgroup (not domain joined)
Pre-requisites
The prerequisites for Single-domain clusters are unchanged from previous versions of Windows Server.
- All servers must be running Windows Server 2016.
- All servers must have the Failover Clustering feature installed.
- All servers must use logo’d hardware that has been certified and the collection of servers must pass all cluster validation tests. For more information, see Failover Clustering Hardware Requirements and Storage Options and Validate Hardware for a Failover Cluster .
In addition to the pre-requisites of Single-domain clusters, the following are the pre-requisites for Multi-domain or Workgroup clusters in the Windows Server 2016:
- To create a new cluster or to add nodes to the cluster, a local account needs to be provisioned on all nodes of the cluster (as well as the node from which the operation is invoked) with the following requirements:
- Create a local ‘User’ account on each node in the cluster
- The username and password of the account must be the same on all nodes
- The account is a member of the local ‘Administrators’ group on each node
- When using a non-builtin local administrator account to create the cluster, set the LocalAccountTokenFilterPolicy registry policy to 1 , on all the nodes of the cluster. Builtin administrator accounts include the 'Administrator' account. You can set the LocalAccountTokenFilterPolicy registry policy as follows:
- On each node of the cluster launch a Microsoft PowerShell shell as an administrator and type:
new-itemproperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1
Without setting this policy you will see the following error while trying to create a cluster using non-builtin administrator accounts.
- The Failover Cluster needs to be created as an Active Directory-Detached Cluster without any associated computer objects. Therefore, the cluster needs to have a Cluster Network Name (also known as administrative access point) of type DNS.
- Primary DNS Suffix Requirements
- Each cluster node needs to have a primary DNS suffix.
- For Multi-domain Clusters: The DNS suffix for all the domains in the cluster, should be present on all cluster nodes…
Deployment
Workgroup and Multi-domain clusters maybe deployed using the following steps:
- Create consistent local user accounts on all nodes of the cluster. Ensure that the username and password of these accounts are same on all the nodes and add the account to the local Administrators group.
2. Ensure that each node to be joined to the cluster has a primary DNS suffix.
For Multi-domain Clusters ensure that the DNS suffix for all the domains in the cluster is present on all cluster nodes.
3. Create a Cluster with the Workgroup nodes or nodes joined to different domains. You may use the Failover Cluster Manager or Microsoft PowerShell.
Using Failover Cluster Manager
The following video shows the steps to create a Workgroup or Multi-Domain cluster using the Failover Cluster Manager UI.
[video width="1920" height="1080" mp4="https://msdnshared.blob.core.windows.net/media/2016/08/WorkgroupCluster.mp4"][/video]
Using PowerShell
When creating the cluster, use the AdministrativeAccessPoint switch to specify a type of DNS so that the cluster does not attempt to create computer objects.
New-Cluster –Name <Cluster Name> -Node <Nodes to Cluster> -AdministrativeAccessPoint DNS
Workload
The following table summarizes the workload support for Workgroup and Multi-site clusters.
Cluster Workload |
Supported/Not Supported |
More Information |
SQL Server |
Supported |
We recommend that you use SQL Server Authentication. This will apply to only SQL Server Always On Availability Groups (AGs). SQL Server Failover Cluster Instances (FCI) will require Kerberos for Active Directory authentication. |
File Server |
Supported, but not recommended |
Kerberos (which is not available) authentication is the preferred authentication protocol for Server Message Block (SMB) traffic. |
Hyper-V |
Supported, but not recommended |
Live migration is not supported. Quick migration is supported. |
Message Queuing (MSMQ) |
Not supported |
Message Queuing stores properties in AD DS. |
Quorum Configuration
The witness type recommended for Workgroup clusters and Multi-domain clusters is a Cloud Witness or Disk Witness. File Share Witness (FSW) is not supported with a Workgroup or Multi-domain cluster.
Servicing
It is recommended that nodes in a cluster have a consistent configuration. Multi-domain and Workgroup clusters introduce higher risk of configuration drift, when deploying ensure that:
- The same set of Windows patches are applied to all nodes in the clusters
- If group policies are rolled out to the cluster nodes, they are not conflicting.
DNS Replication
It should be ensured that the cluster node and network names for Workgroup and Multi-domain clusters are replicated to the DNS servers authoritative for the cluster nodes.