How to build a Failover Cluster with Windows Server 2022

This tutorial guides you through creating a Windows Server Failover Cluster (WSFC) to protect your critical applications. These steps apply to Windows Server 2022 Datacenter or Standard editions with the Failover Clustering feature installed. You will configure two nodes, validate the cluster, and create a resource group with a SQL Server or IIS role.

Prerequisites

• Operating System: Two Windows Server 2022 machines (Physical or Hyper-V VMs).
• Network: A dedicated private network for cluster communication (e.g., 10.0.0.x/24) and a public network for client access.
• Storage: Shared storage accessible by both nodes (SAN, iSCSI, or SMB 3.0 scale-out) or witness storage for a two-node cluster.
• Roles: Failover Clustering feature installed on both nodes via Server Manager or PowerShell.
• Privileges: Local Administrator account on both nodes and a domain admin account.
• Configuration: Ensure both nodes are in the same Active Directory domain and have matching DNS records.

Step 1: Install the Failover Clustering Feature

Open PowerShell as Administrator on both nodes. Run the following command to ensure the Failover Clustering feature is installed. This feature is required for the cluster service to function.

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools -Restart

Wait for the installation to complete. The system may prompt you to restart the server. Reboot both nodes immediately after the command finishes to apply the changes.

Restart-Computer -Force

After the reboot, verify the feature is installed by running the following command. You should see "True" for the Installed value.

Get-WindowsFeature -Name Failover-Clustering | Select-Object Name, Installed

Step 2: Configure Network Settings

Configure the network interfaces on both nodes. You need at least two network adapters: one for the cluster communication (private) and one for client access (public). Open Server Manager, go to Local Server, and click on Network Adapter. Assign a static IP address to the private network adapter on both nodes within the same subnet (e.g., 10.0.0.10 and 10.0.0.11).

Ensure the cluster network is set to "Private" in the network settings to prevent unauthorized access. Configure the public network adapter with a static IP for client connections. Verify the IP configuration by running the following command in PowerShell:

Get-NetIPAddress | Where-Object { $_.InterfaceAlias -like "*Ethernet*" }

Step 3: Create the Cluster

Open Failover Cluster Manager on one of the nodes. In the left pane, right-click on "Clusters" and select "New Cluster". Enter a name for the cluster (e.g., "Cluster01") and select the two nodes to include in the cluster.

Click "Next" to proceed to the validation wizard. This step checks for compatibility issues, such as mismatched versions, storage accessibility, and network configurations. If any errors appear, resolve them before proceeding. Once validation passes, click "Next" and then "Finish" to create the cluster.

The cluster service will start automatically. Verify the cluster status by running the following command in PowerShell:

Get-Cluster | Select-Object Name, State

You should see the cluster name and a state of "Running". If the state is not "Running", check the Event Viewer for errors related to the Cluster Service.

Step 4: Configure the Cluster Network

Inside Failover Cluster Manager, expand "Clusters", right-click on the cluster name, and select "Properties". Go to the "Network" tab. Click "Add" to create a new network interface for the cluster. Enter a name (e.g., "Cluster Network") and select the private network adapter configured in Step 2.

Click "Next" and ensure the "Private" option is selected for the network type. This ensures secure communication between nodes. Click "Finish" to create the network. Verify the network configuration by running:

Get-ClusterNetwork | Select-Object Name, State, Type

Step 5: Create a Resource Group

Right-click on the cluster name in Failover Cluster Manager and select "Add Roles and Resources". Choose the role you want to protect, such as "File Server", "SQL Server", or "IIS". Click "Next" and follow the wizard to add the role to the cluster.

For SQL Server, select "SQL Server" and enter the instance name and shared storage path. For IIS, select "IIS" and configure the web site. Click "Next" and then "Finish". The resource group will be created with the selected role.

Verify the resource group by running:

Get-ClusterResourceGroup | Select-Object Name, State

Verify the installation

Ensure the cluster is functioning correctly by running the following PowerShell commands. Check the cluster state, network status, and resource group status.

Get-Cluster | Select-Object Name, State
Get-ClusterNetwork | Select-Object Name, State, Type
Get-ClusterResourceGroup | Select-Object Name, State

Test failover by moving a resource to the other node. Right-click on the resource group in Failover Cluster Manager, select "Move", and choose the target node. Verify the resource is running on the new node by checking the status in the manager or using:

Get-ClusterResource | Where-Object { $_.Name -like "*SQL*" } | Select-Object Name, OwnerNode

Troubleshooting

If the cluster fails to start or resources do not move, check the Event Viewer for Cluster Service errors. Common issues include network misconfigurations, storage access problems, or mismatched node versions.

To reset the cluster network, run the following command in PowerShell:

Clear-ClusterNetwork -Name "Cluster Network"

Recreate the network using Failover Cluster Manager if the issue persists. For storage issues, ensure the shared storage is accessible from both nodes using the same credentials. If the cluster is in a degraded state, check the quorum configuration. Run the following command to view the quorum status:

Get-ClusterQuorum | Select-Object State, Type

If the quorum is lost, the cluster will not function. Restore the quorum by adding a witness file share or moving the quorum to a disk if necessary. Always ensure DNS records are correct and that the cluster network is not blocked by firewalls. For further assistance, refer to Microsoft documentation on Windows Server Failover Clustering.