BACKGROUND IMAGE: stock.adobe.com
Windows Server 2019 cluster sets bring traditional clustering to a new level to improve workload mobility and protect applications from interruptions. But it takes some work to build the high availability fabric.
First, administrators must configure a management client and install the failover cluster tools on the management server. Next, administrators create the member clusters, which should consist of at least two clusters with at least two Cluster Shared Volumes on each cluster. Finally, administrators make a separate management cluster that oversees the member clusters. Microsoft designed Windows Server 2019 cluster sets with a separate management cluster to keep its services alive in the event of a node failure.
Administrators must then run a series of PowerShell commands to create the Windows Server 2019 cluster set. Microsoft provides detailed instructions on its documentation site, but the overall process is summarized below.
First, construct at least two clusters consisting of at least two nodes, as well as a management cluster. Next, use PowerShell to create the cluster set, give it a name and then add the member clusters.
Once the cluster set is built, administrators can use PowerShell cmdlets to list the member clusters and nodes:
- Get-ClusterSetMember lists the nodes and properties of each node within the cluster set.
- Get-ClusterSet lists the member clusters, including management cluster nodes. Additional command-line switches can tell the command to list resource groups across the cluster set.
- Get-ClusterSetNode lists all the nodes from the member clusters.
Windows Server 2019 cluster sets produce debugging logs for member clusters and the management cluster. Use the Get-ClusterSetLog cmdlet to gather these logs for review, auditing and troubleshooting.
Establishing security in member clusters is an important part of this deployment. Administrators typically configure Kerberos constrained delegation for member clusters and also use Kerberos authentication for cross-cluster VM live migration among member clusters in the cluster set.
A final step is often to add the management cluster to the local administrators group on each member cluster.