3. 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:
1. | Start Server Manager
|
2. | Click on Features, this will bring up the Features Wizard
|
3. | Click on Add Features in the right Features panel
|
4. | Check the Failover Clustering checkbox
|
5. | 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:
1. | Click Start
|
2. | Click Administrative Tools
|
3. | 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 8) 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 | 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 8. 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 9).
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 9. 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 10.)
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 | 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 10. 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 | 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.