Failover Cluster cmdlets
To use the Failover Cluster cmdlets and their features, you will need to install them. They are not installed by default. To install the Failover Cluster cmdlets, you need to do the following tasks:
- Start Server Manager
- Click on Features, this will bring up the Features Wizard
- Click on Add Features in the right Features panel
- Check the Failover Clustering checkbox
- Click Install
You have now installed the Failover Clustering feature. The next step is to make all the cmdlets available to you in PowerShell. To do this, you follow these steps:
- Click Start
- Click Administrative Tools
- Click on PowerShell Modules, making sure you run it as an Administrator.
A PowerShell window will then open and start importing the modules you will need. To verify that it worked, you can type Get-Command -Module FailOverClusters and hit enter. If you did everything properly, you will see the cmdlet list for FailOverClusters.
When you work with Failover Clusters, there are a lot of different things that can happen or need to be done. You will try to illustrate how PowerShell can be used in performing some of the more important tasks as an alternative to using the Failover Manager Snapin for Server Manager.
Let us say that as an administrator it is your job to configure a new Failover Cluster. The first thing you would need to do is to test the cluster to make sure it is a valid candidate for a Failover Cluster. First, you need to connect all the hardware and then test it. You would type Test-Cluster (see Table-9) at the PowerShell Prompt and hit enter. This cmdlet will run all the validation tests on the cluster. Since you do not specify a cluster by name, it will run them on the local cluster. This cmdlet will not test an online disk that is being used as part of a Failover Cluster already. If you need to test one, then you need to offline it and then test it. Once the cluster has been tested, then you know it is ok to use for a Failover Cluster and can move on to the next step of actually creating the cluster. You create the cluster with the New-Cluster cmdlet. At the PowerShell prompt, you type New-Cluster -Name NewCluster -Node node1, node2, and hit enter to create a cluster named NewCluster with two nodes and default values for IP addressing. Next, you need to create the clustered file folder and specify the storage volume that it will use much in the same way as if you were using the High-Availability Wizard in Server Manager. You use the Add-ClusteredFileServerRole cmdlet to accomplish this. You can type Add-ClusteredFileServerRole -Storage "Cluster Disk 2" and hit enter where the -Storage flag corresponds to the cluster disk resource you want to use. You are almost done configuring your new Failover Cluster. The last part is to decide if you want to add more disks to the cluster. If you want to add more disks to the cluster, you first check to see which disks are available with the Get-ClusterAvailableDisk cmdlet by typing Get-ClusterAvailableDisk and then enter. This will then give you a list of the disks available to be added. If you decide you want to add them, you then type Get-ClusterAvailableDisk j Add-ClusterDisk and hit enter. This will look for available disks and then add them to the cluster. You now have a basic Failover Cluster.
Table-9 cmdlets Used in Creating a New Failover Cluster| cmdlet | Description |
|---|---|
| Test-Cluster | This cmdlet runs validation tests for Failover Cluster setup |
| New-Cluster | This cmdlet creates a new Failover Cluster |
| Add-ClusteredFileServerRole | This cmdlet creates a clustered file server |
| Get-ClusteredAvailableDisk | This cmdlet shows the available disks valid for failover not yet being used |
| Add-ClusteredDisk | This cmdlet adds a disk to the Failover Cluster |
Another task that might be required of you is the administration of the nodes on the Failover Cluster. PowerShell has some handy cmdlets to make this job easy as well (see Table-10). You are busy working and someone high up wants you to know if all the nodes are up. You simply need to check if all the nodes that are supposed to be running are actually online. The Get-ClusterNode cmdlet is what you would use for this task. Typing Get-ClusterNode -Cluster NameOfTheCluster will give you a list of all the nodes in the cluster you specify along with their status allowing you to easily see if they are online or not. After you finish checking the nodes and assure the party concerned that all the nodes are up, you get another request. You are asked to add a new node, node4 to an existing cluster named MainClusterA. Using PowerShell, you would type Add- ClusterNode -Cluster MainClusterA -Name node4. The -Cluster flag specifies which cluster to add the node to and the -Name flag corresponds to the name of the node to add. You finish that request and start to check e-mail. Another request has hit your inbox. Once you start administering nodes, you might find yourself having to stop and start the cluster service on some nodes or even just pausing it for some time and then resuming it. PowerShell can help you do these things as well. For stopping and starting the cluster service, you will need to use the Stop-ClusterNode and Start- ClusterNode cmdlets, respectively. The new request you just received is asking you to stop the cluster service in node3 so that some routine inspection or troubleshooting can be performed on it. You type Stop-ClusterNode node3 -Cluster MainClusterA and hit enter. When the cmdlet runs, you will get a confirmation that the node is offline. When you stop a node, you do have to keep in mind that the number of nodes cannot drop below quorum or the system will not let you do it since this would jeopardize everything. You reply to the request that node3 is offline and that they can start their maintenance. The maintenance is performed on node3 and tests are run and everything checks out. You are now tasked with starting up the Cluster service back on it. No reason to worry at all. You type Start-ClusterNode node3 -Cluster MainClusterA and hit enter. You reply that node3 is backup and ready to go. Before you have even finished sending the message, another request comes in. You are asked to pause node4 because software updates need to be applied to it. They do not want you to stop the node since they guarantee the updates will be fast and they do not want to bring the node offline. Everything that needs to be stopped or moved has been done. They just need you to pause the node for them, so they can continue. You type Suspend-ClusterNode node4 -Cluster MainClusterA and hit enter. When the cmdlet runs, you see that the node status is "paused." After you pause the node, you inform them and wait for them to give you the green light to unpause the node. Eventually, you are given the green light to resume activity on the node and you type Resume-ClusterNode node4 -Cluster MainClusterA in PowerShell and hit enter. Check whether the status has the node back to "Up" and move on to your next task. You have handled yourself well and touched upon the basics on node management at the same time. You decide to take lunch and pat yourself on the back for doing so well.
Table-10 Some Useful ClusterNode cmdlets| cmdlet | Description |
|---|---|
| Get-ClusterNode | This cmdlet gets information about the nodes in a Failover Cluster |
| Add-ClusterNode | This cmdlet adds a node to a Failover Cluster |
| Stop-ClusterNode | This cmdlet stops service for a node of a Failover Cluster |
| Start-ClusterNode | This cmdlet starts failover service in a Failover Cluster for a node |
| Suspend-ClusterNode | This cmdlet Pauses a node in a Failover Cluster |
| Resume-ClusterNode | This cmdlet Resumes a paused node in the Failover Cluster |
You come back from lunch feeling energized and ready for the rest of the day. Just after you have sat down, you notice requests in your inbox. You are being asked to check on a disk in the cluster and make sure it is in maintenance mode, Disk 4. (The cmdlets for this task are described in Table-11.) A maintenance tool will be run on it later today and they need it to be in maintenance mode or it could trigger failover, which would be bad. You sit down and type Get-ClusterResource and hit enter. A list comes up with all the cluster resources and you see that the name of the disk is actually Cluster Disk 4. You notice that Cluster Disk 4 is shown online, but that is not enough for you, you need to see if it is in maintenance mode, if it has been suspended from active duty. To see if it is in maintenance mode, you have a choice and can use either the Get- ClusterResource cmdlet on Cluster Disk 4 or Get-ClusterResource, together with Get-ClusterParameter, for a more detailed overview of the disk. You decide to try both for kicks. After typing Get-ClusterResource "Cluster Disk 4" -Cluster MainClusterA and hitting enter, you are able to see in the list that the disk is not in maintenance mode since it says false. You double-check and type Get-ClusterResource "Cluster Disk 4" -Cluster MainClusterA j Get-ClusterParameter and hit enter. You notice that maintenance mode is not on since it has a value of 0. You need to suspend the disk yourself, so you type Suspend-ClusterResource "Cluster Disk 4" -Cluster MainClusterA and hit enter. After the cmdlet executes, you notice that the display shows that the disk is still online, but it is in maintenance mode. You reply to the request and confirm that the disk is now in maintenance mode and ready for the necessary programs to be run. Once the programs are run, someone will need to take the disk out of maintenance mode, so it can go back to being fully productive. This someone will most likely be you and you will gladly type Resume- ClusterResource "Cluster Disk 4" -Cluster MainClusterA hit enter and be done with this request. You will notice that after the cmdlet is run, the disk will still show as being online but no longer in maintenance mode.
Table-11 Useful Cluster Resource cmdlets| cmdlet | Description |
|---|---|
| Get-ClusterResource | This cmdlet gets information about one or more resources on a Failover Cluster |
| Suspend-ClusterResource | This cmdlet turns on maintenance for a disk or cluster-shared volume |
| Resume-ClusterResource | This cmdlet turns off maintenance for a disk or cluster-shared volume |
Just when you thought you were done, in comes a very different request. Your next task is to move a group of applications and services known as a Resource Group from one node, node3 to a different node, node6, so that node3 can be readied for maintenance. The first thing you do is type Get- ClusterNode node3 -Cluster MainClusterA j Get-ClusterGroup and hit enter. This brings up all the services and applications that are owned by node3. You notice that the display shows a resource group called "KittenCaboodle." You realize that you will need to stop this resource group first if you are to move it to node6. You type Stop-ClusterGroup Kitten Caboodle -Cluster MainClusterA and hit enter. Once the cmdlet runs, you can see that the resource group will show up as offline. Now that the Kitten Caboodle is offline, you need to move it. Next, you type Move- ClusterGroup KittenCaboodle -Cluster MainClusterA -Node node6 and hit enter. The -Node flag specifies the destination node to move the resource group to. Now, all you need to do is bring it back online. You type Start-ClusterGroup KittenCaboodle -Cluster MainClusterA hit enter and watch the display. Once the cmdlet executes, you will notice that the Kitten Caboodle resource group will be back online and in node6, which means you are done. All you have to do now is wonder if they are going to make you move it back after the maintenance in node3 is done.
As you can see, using cmdlets to accomplish the same jobs as some of the Server Manager wizards for Failover Clusters is not difficult once you familiarize yourself with the capabilities of the PowerShell Failover cmdlets. You dabbled in configuring a Failover Cluster, performing some cluster node operations, monitoring some cluster disks, and moving a resource group from one node to another. The advantage of PowerShell is that once you become comfortable with it, you will find that your administrative job will become easier as you write scripts once and then have them there for the next time you need. You are also able to run them on multiple machines instead of going through the wizard on each individual machine.