Windows Server Failover Clustering (WSFC), the successor to Microsoft Cluster Server (MSCS), is a group of independent servers that work together to increase the availability of applications and services. Individual servers, which are called nodes, are connected by cluster software that allows the group of nodes to be managed as a single system. The use of a common namespace within a virtual server gives the cluster the appearance of a single Windows server to the user.
Failover clusters provide redundancy in case one or more servers fail. In such an event, the cluster software moves resources between nodes so that users on the failed server can seamlessly be directed to another server. This is usually done so quickly that the user doesn't even perceive the redirection. (For more information about failover clusters, see "Windows Server 2012: Building a Two-Node Failover Cluster.")
I'll show you the basics of WSFC management using Windows PowerShell's command-line interface and the PowerShell FailoverClusters module. In doing so, you'll become better acquainted with numerous cmdlets in that module.
Preparing to Use the FailoverClusters Cmdlets
The PowerShell FailoverClusters module is available when the WSFC feature is installed. You can install WSFC on many OSs and some hypervisors, including:
- Windows Server 2012
- Windows Server 2008 R2 SP1
- Windows 7 SP1 with Remote Server Administration Tools (RSAT) installed
- Microsoft Hyper-V Server 2008 R2 SP1
To use PowerShell to manage your failover clusters, you will first need to install the Failover Clustering feature on each server that you want to include in the cluster. Note that you'll need administrator privileges on each server that you want to add to your cluster. To install the Failover Clustering feature, start PowerShell as an administrator by right-clicking the PowerShell icon and selecting the Run as administrator option. Then, at the PowerShell command line, run the command:
Install-WindowsFeature -Name Failover-Clustering ` -IncludeManagementTools
To use the PowerShell FailoverClusters module, you need to import it using the command:
Import-Module FailoverClusters
You can then run the following command to confirm that the FailoverClusters module was imported successfully:
Get-Module -ListAvailable
In Windows Server 2012 and Windows Server 2008 R2, there's a Windows PowerShell Modules link under Administrative Tools, as Figure 1 shows. Enabling that feature will cause PowerShell to automatically import all the modules for features or roles you've installed so that you don't have to run the Import-Module cmdlet every time.
Setting Up and Configuring Failover Clustering
After you have all the hardware (i.e., servers, networks, and storage) in place and connected, you're ready to create the failover cluster. The first order of business is to use the Test-Cluster cmdlet to conduct preliminary validation tests to confirm that your hardware and settings are compatible with failover clustering. The tests are broken into categories, such as Inventory, System Configuration, Network, and Storage. Running the Test-Cluster cmdlet with the -List parameter lists all available tests without actually running them:
Test-Cluster -List
After you know which tests you want to run, you can include or exclude tests (or even categories of tests) using the -Include and -Ignore parameters, respectively. For example, if you want to run only two tests—List System Drivers and List Unsigned Drivers—you'd run the command:
Test-Cluster -Include ` "List System Drivers","List Unsigned Drivers"
If you want to save the results in a file, you can include the -ReportName parameter followed by the desired pathname. For example, the following command tells PowerShell to perform the Validate Active Directory Configuration test and save the results in C:\Clusters Reports\Report_2013-07-10:
Test-Cluster ` -Include "Validate Active Directory Configuration" ` -ReportName "C:\Clusters Reports\Report_2013-07-10"
The report will have the .mht file extension, which is Microsoft's archive file format for web pages. In other words, the report will be written in MIME HTML (MHTLM), which saves the web page content and incorporates external resources, such as images, applets, animations, and so on. You can view the report in your default browser using the Invoke-Item cmdlet:
Invoke-Item "C:\Clusters Reports\Report_2013-07-10.mht"
Unlike the previous command, this command requires that you include the file extension (.mht). Figure 2 shows a sample Validate Active Directory Configuration test report.
After you confirmed that your hardware and settings are compatible with failover clustering, you can create the clusters. For example, if you want to create a two-node cluster named AcmeFailConfig1, you'd run a command like this:
New-Cluster -Name AcmeFailConfig1 ` -Node AcmeServer1, AcmeServer2
This command assumes that a DHCP address can be assigned. All available storage is automatically added to the cluster.
If you want the cluster to use a static IP address for its management connection, without adding any storage to the cluster, you'd use a command such as:
New-Cluster -Name AcmeFailConfig1 ` -Node AcmeServer1, AcmeServer2 ` -StaticAddress 10.0.0.12 -NoStorage
If you want to put the cluster account into an existing Active Directory (AD) organizational unit (OU) named AcmeClusters that resides on the Acme.local domain, you'd run the command:
New-Cluster ` -Name CN=AcmeFailConfig1,OU=AcmeClusters,DC=Acme,DC=local ` -Node AcmeServer1, AcmeServer2
Notice that there are no spaces in the -Name parameter's value.
Getting Information About a Failover Cluster
Once you have your failover clusters in place, it's helpful to obtain information about them. At the highest level, you can use the Get-Cluster cmdlet, which retrieves configuration and state information about a failover cluster. For example, to list the names of all the clusters in the acme.com domain, you'd run the command:
Get-Cluster -Domain acme.com
You can also use the Get-Cluster cmdlet to obtain a reference to a given cluster because cmdlets always return an object. For example, to enable the Cluster Shared Volumes feature on Cluster01, you'd run the commands:
$cluster01 = Get-Cluster -Name Cluster01 $cluster01.EnableSharedVolumes = "Enable/NoticeRead"
At a slightly more fine-grained level, you can use the Get-ClusterGroup cmdlet, which obtains information about cluster groups. A cluster group (which is sometimes called a resource group) is a collection of related cluster resources that define actions to be taken during a switchover or failover operation. Because these resources include applications, data, and devices, you can consider them to be the core of your cluster. Hence, if your cluster group goes down, basically your entire cluster (all the applications, resources, and so on) go down with the ship.
Used without any parameters, the Get-ClusterGroup cmdlet lists the state and owner node of each cluster group in the local cluster. Figure 3 shows sample results.
More fine-grained still, the Get-ClusterNode cmdlet retrieves information about one or more nodes (i.e., servers) in a failover cluster. Used without any parameters, this cmdlet lists the name and state of each node in the cluster, as Figure 4 shows.
To get a list of all clustered resources, you can use the Get-ClusterResource cmdlet without any parameters. Figure 5 shows sample results.
The Get-ClusterResource cmdlet can accept piped input from other cmdlets, which lets you obtain different types of information. For example, to see the resources currently owned by a particular node, you can pass that node to the Get-ClusterNode cmdlet, then pipe the results to Get-ClusterResource:
Get-ClusterNode node1 | Get-ClusterResource
Figure 6 shows sample results.
To get a list of all clustered resources in a cluster group, you can issue a command like this:
Get-ClusterGroup "Cluster Group" | Get-ClusterResource
Figure 7 shows sample results.
The output of the Get-ClusterResource cmdlet can be piped to other cmdlets to get more information about the resources. For example, you can pipe the results to the Get-ClusterParameter cmdlet:
Get-ClusterResource | Get-ClusterParameter
In this case, you're obtaining more information about the various objects in the failover cluster, as seen in Figure 8.
Adding Cluster Groups and Other Items to a Cluster
There are cmdlets for adding nodes, cluster groups, resources, and just about any other item that you might want to add to an existing failover cluster. All these cmdlets conveniently start with the "Add-" verb.
The Add-ClusterGroup cmdlet adds an empty cluster group to the failover cluster configuration. To illustrate, here's a command that adds an empty cluster group named Group1 to the AcmeCluster1 failover cluster:
Add-ClusterGroup -Name Group1 -Cluster AcmeCluster1
To add a specific disk to the cluster, you can use the Add-ClusterDisk cmdlet. For instance, the following command adds the ClusterBP01 disk to the cluster:
Get-Disk -FriendlyName "ClusterBP01"| Add-ClusterDisk
Keep in mind that the ClusterBP01 disk must be visible to all the nodes in the cluster and must be available to be added (i.e., not already part of the cluster). When in doubt, you can use the Get-ClusterAvailableDisk cmdlet to check for available servers. You can even combine the Get-ClusterAvailableDisk and Add-ClusterDisk cmdlets to identify available disks and add them to the cluster group:
Get-ClusterAvailableDisk | Add-ClusterDisk
Figure 9 shows sample results.
To add a resource to a clustered server or cluster group, you can use the Add-ClusterResource cmdlet. For example, to create a new IP Address resource named resource1 as part of the AcmeSrv1 server, you'd use a command such as:
Add-ClusterResource -Name resource1 ` -ResourceType "IP Address" -Group AcmeSrv1
As you can see in Figure 10, the created resource is offline by default.
In true PowerShell fashion, you have the ability to not only create the resource but also set some of its properties and bring the resource online in one operation:
Add-ClusterResource -Name "Disk P:" ` -ResourceType "Physical Disk" ` -Group "Available Storage" | Set-ClusterParameter DiskPath "P:" ; Start-ClusterResource "Disk P:"
As the last line in the code shows, the Start-ClusterResource cmdlet is used to bring the resource online, the results of which are shown in Figure 11.
Removing Cluster Groups and Other Items from a Cluster
The PowerShell FailoverClusters module includes "Remove-" cmdlets to remove cluster groups and other items from a cluster. There are two parameters that you need to know about:
- -Force. By default, many of the Remove- cmdlets ask for confirmation before deleting the specified item. If you include the -Force parameter, the cmdlet won't prompt you for confirmation.
- -RemoveResources. The Remove-ClusterGroup cmdlet includes the -RemoveResources parameter. If you include this parameter, the cmdlet will delete all the resources in the clustered server or cluster group before removing that server or group.
Let's look at a couple of examples. The following Remove-ClusterGroup command prompts the user for confirmation to remove the AcmeFileServer server:
Remove-ClusterGroup -Name AcmeFileServer
After the confirmation is given, the command removes the server, provided the resources have already been removed from it.
The following call to Remove-ClusterGroup will first remove the resources from the AcmeFileServer server before removing it from the cluster:
Remove-ClusterGroup -Name AcmeFileServer ` -RemoveResources -Force
No confirmation prompt is presented to the user.
Configuring Quorums in a Failover Cluster
The quorum configuration in a failover cluster determines the number of failures that the cluster can sustain. If an additional failure occurs, the cluster will stop running. The relevant failures in this context are node failures and, in some cases, the failure of a disk witness (which contains a copy of the cluster configuration) or a file share witness.
You can choose from four possible quorum configurations:
- Node Majority. This configuration is recommended for clusters with an odd number of nodes. A Node Majority cluster can sustain failures of half the nodes (rounding up) minus one before failing. For example, a seven-node cluster can withstand three node failures before going down.
- Node and Disk Majority. This configuration is recommended for clusters with an even number of nodes. A Node and Disk Majority cluster can sustain failures of half the nodes (rounding up), as long as the disk witness remains online. For example, an eight-node cluster in which the disk witness is still online can withstand up to four node failures.
- Node and File Share Majority. This configuration is best for clusters with special configurations. It works in a way similar to the Node and Disk Majority configuration, but instead of a disk witness, this cluster uses a file share witness. It requires that at least one of the available cluster nodes contains a current copy of the cluster configuration before starting the cluster. Otherwise, you'll have to start the cluster through an individual node.
- No Majority - Disk Only. Although a cluster using this type of configuration can sustain failures of all nodes except one, this configuration isn't recommended because the disk might be a single point of failure.
PowerShell provides two cmdlets for managing quorum configurations: Get-ClusterQuorum and Set-ClusterQuorum. You use the Get-ClusterQuorum cmdlet to find out a cluster's current quorum configuration. For example, to display the quorum configuration for the cluster named AcmeCluster1, you'd run the command:
Get-ClusterQuorum -Cluster AcmeCluster1
You use the Set-ClusterQuorum cmdlet to change a cluster's quorum configuration. For instance, if you want to change the quorum configuration to Node and Disk Majority on the local cluster, using the disk resource named ACME Cluster Disk 4 for the disk witness, you'd use the command:
Set-ClusterQuorum -NodeAndDiskMajority "ACME Cluster Disk 4"
Maintaining Failover Clusters
There are several cmdlets for performing maintenance tasks such as moving, stopping, starting, and suspending nodes and cluster groups. Let's look at a few examples.
To balance the workloads in a cluster, you can use the Move-ClusterGroup to move a cluster group to a different node. For example, to move the cluster group named clusterAcme01 to the node named Acme2112-node2, you'd run the command:
Move-ClusterGroup clusterAcme01 -Node Acme2112-node2
The Suspend-ClusterResource cmdlet turns on the maintenance mode for a disk resource or Cluster Shared Volume so that you can run a disk maintenance tool without triggering a failover. For instance, if you want to perform maintenance on the cluster resource named ACME Disk 2, you'd use the command:
Suspend-ClusterResource -Name "ACME Disk 2"
As you can see in Figure 12, the resource's status will read Online/Maintenance. Note that if you're unsure of your cluster resources' names, you can run the Get-ClusterResource cmdlet to get a list of them.
The Suspend-ClusterNode cmdlet pauses the activity on a cluster node. If you're running Windows Server 2012 or later, you can take advantage of the cmdlet's -Drain parameter. Draining a node refers to transferring its workload to other nodes in the cluster. If you include the -Drain parameter when calling Suspend-ClusterNode, the clustered roles currently running on the node will be drained before the node is paused:
Suspend-ClusterNode -Name node1 -Target node2 -Drain
After you complete the maintenance, you can resume the activity on the resource or node using the Resume-ClusterResource cmdlet or Resume-ClusterNode cmdlet, respectively. For example, to resume the activity on the ACME Disk 2 cluster resource, you'd use the Resume-ClusterResource cmdlet, like so:
Resume-ClusterResource -Name "ACME Disk 2"
Suspending a resource or node is usually done when applying software updates. When you need to perform extensive maintenance or diagnostics on a cluster, cluster node, cluster group, or cluster resource, it's often best to stop the Cluster service on it altogether using the Stop-Cluster, Stop-ClusterNode, Stop-ClusterGroup, or Stop-ClusterResource cmdlet, respectively. When you're done, you can restart the Cluster service by running the Start- counterpart (i.e., Start-Cluster, Start-ClusterNode, Start-ClusterGroup, or Start-ClusterResource).
For example, if you need to stop node2 on cluster2, you'd use the Stop-ClusterNode cmdlet:
Stop-ClusterNode node2 -Cluster cluster2
When you want to restart it, you'd use the Start-ClusterNode cmdlet:
Start-ClusterNode node2 -Cluster cluster2
Running Repair Utilities on a Cluster Shared Volume
The Repair-ClusterSharedVolume cmdlet runs repair tools on a Cluster Shared Volume on a local cluster node. Under the covers, it runs chkdsk.exe or defrag.exe. It puts the volume into maintenance mode, moves the cluster resource to the node running the cmdlet, runs the tool, then switches the maintenance mode off for the volume. For example, the following command runs defrag.exe on the Cluster Shared Volume named Volume2:
Repair-ClusterSharedVolume ` -VolumeName C:\AcmeStorage\Volume2 -Defrag
Here's a command that runs chkdsk.exe on a Cluster Shared Volume, passing in the /F parameter to chkdsk.exe:
Repair-ClusterSharedVolume ` -VolumeName C:\AcmeStorage\Volume4 ` -ChkDsk -Parameters "/F"
The /F parameter tells chkdsk.exe to fix any errors it finds on the disk.
Registering Existing Network Name Resources with a DNS Server
The Update-ClusterNetworkNameResource cmdlet can be used to register existing Network Name resources with a DNS server, without interrupting cluster availability. The following example shows how to register the Network Name resources of the local cluster with a DNS server:
Get-ClusterResource AcmeCluster1 | Update-ClusterNetworkNameResource
Refreshing the Configuration of a Clustered VM in a Failover Cluster
The Update-ClusterVirtualMachineConfiguration cmdlet refreshes the configuration of a clustered virtual machine (VM). It's useful in the event that a hardware device (e.g., a network adapter) needs to be added or removed or the hardware configuration settings (e.g., virtual memory settings) need to be modified. For instance, if you need to refresh the configuration of the VM named VM1, you'd run the command:
Update-ClusterVirtualMachineConfiguration -Name VM1
You can also designate a specific cluster. For example, if you need to refresh the configuration of the VM named VM2 on the cluster named AcmeCluster1, you'd run the command:
Update-ClusterVirtualMachineConfiguration -Name VM2 ` -Cluster AcmeCluster1
Take Advantage of the Failover Cmdlets
With PowerShell's numerous failover cmdlets, you can accomplish all the same management tasks that are achievable using the Failover Cluster Management console in Windows Server. If you're comfortable with the concept of failover clustering, the biggest challenge is remembering all the cmdlets that are available. Luckily, if you forget, here's a command to list them all:
Get-Command |
Where-Object {$_.ModuleName -eq 'FailoverClusters'} |
Format-List *
To learn more about each cmdlet, you can use the Get-Help cmdlet or visit the Failover Clusters Cmdlets in Windows PowerShell web page.
