Windows Management and Scripting

A wealth of tutorials Windows Operating Systems SQL Server and Azure

Posts Tagged ‘cluster’

Powershell CMDLET for managing Windows Server 2012 Cluster

Posted by Alin D on January 17, 2013

If you manage Windows Failover Clusters, you may notice the Cluster.exe CLI command is missing after you install the Windows Server 2012 Failover Clustering feature. For years, systems administrators have used Cluster.exe to script the creation of clusters, move failover groups, modify resource properties and troubleshoot cluster outages. Yes, the Cluster.exe command still exists in the Remote Server Administration Tools (RSAT), but it’s not installed by default and is considered a thing of the past.

Another thing you may soon notice in Windows Server 2012 is the PowerShell and Server Manager Icons pinned to your taskbar. What you may not notice is that the default installation of the Windows Server 2012 operating system is now Server Core and contains more than 2,300 PowerShell cmdlets. Microsoft is sending a clear message that Windows servers should be managed just like any other data center server, both remotely and through the use of scripting. With Windows, that means PowerShell.

Fortunately, Windows Server Failover Clustering is no stranger to PowerShell. With Windows Server 2008 R2, 69 cluster-related PowerShell cmdlets assist with configuring clusters, groups and resources. This tip explores the new PowerShell cmdlets in Windows Server 2012 failover clusters.

With Windows Server 2012, a total of 81 failover cluster cmdlets can be used to manage components from PowerShell. New cluster cmdlets can perform cluster registry checkpoints for resources (Add-ClusterCheckpoint), monitor virtual machines for events or service failure (Add-ClusterVMMonitoredItem) and configure two new roles: Scale-Out File Servers (Add-ClusterScaleOutFileServerRole) and iSCSI Target Server (Add-ClusteriSCSITargetServerRole).
Windows PowerShell ISE

Windows PowerShell ISE

To list all the failover cluster cmdlets, use the PowerShell cmdlet “Get-command –module FailoverClusters” (Figure 1). I am using the built-in Windows PowerShell Integrated Scripting Environment (ISE) editor, which helps admins get familiar with all the failover clustering cmdlets.

In addition to the FailoverCluster cmdlets, Microsoft has several new modules of PowerShell cmdlets, including ClusterAwareUpdating with 17 new cmdlets, ClusterAware ScheduledTasks with 19 new cmdlets and iSCSITarget with 23 new cmdlets. There are many Cluster Aware Updating cmdlets, such as adding the CAU role (Add-CauClusterRole), getting an update report (Get-CauReport) or invoking a run to scan and install any new updates (Invoke-CauRun).

Cluster-Aware scheduled tasks are new to Windows Server 2012 and the Task Scheduler now integrates with failover clusters. A scheduled task can run in one of three ways:

ClusterWide on all cluster nodes
AnyNode on a random node in the cluster
ResourceSpecific on a node that owns a specific cluster resource

The new ScheduledTasks cmdlets create a cluster-aware scheduled task. In the table, you can see the cmdlets that register, get and set Clustered Scheduled task properties.
PowerShell Cmdlet     Description
Register-ClusteredScheduledTask     Creates a new clustered scheduled task
Unregister-ClusteredScheduledTask     Deletes a clustered scheduled task
Set-ClusteredScheduledTask     Updates existing cluster task
Get-ClusteredScheduleTask     Enumerates existing clustered tasks

To get an idea of how to use these PowerShell cmdlets, you first assign an action and trigger variable. The action variable specifies the program that is to be executed, such as the Windows calculator in the example below. The trigger variable sets up when the task is to be executed. The resulting cmdlets to schedule the task to run cluster-wide daily at 14:00 would look like this:

PS C:\> $action = New-ScheduledTaskAction –Execute C:\Windows\System32\Calc.exe

PS C:\> $trigger = New-ScheduledTaskTrigger -At 14:00 –Daily

PS C:\> Register-ClusteredScheduledTask -Action $action -TaskName ClusterWideCalculator -Description “Runs Calculator cluster wide” -TaskType ClusterWide -Trigger $trigger

TaskName         TaskType
——–         ——–
ClusterWideCa… ClusterWide

PS C:\>
Windows PowerShell Task Scheduler

While only PowerShell can be used to register, get/set and unregister Cluster-Aware scheduled tasks, you can use the Task Scheduler in Computer Management to view the cluster jobs (Figure 2).
iSCSI Target cmdlets
Cmdlets Failover Clusters3

Finally, failover clusters can now be configured with a highly available iSCSI Target Server. This role allows you to create and serve iSCSI LUNs in a highly available fashion to clients across your enterprise. To add this new cluster role, use the Cmdlet Install-WindowsFeature –name FS-iSCSITarget-Server (or use Server Manager) to install the iSCSI Target Server role. Then, use the new cmdlet Add-ClusteriSCSITargetServerRole to create the iSCSI Target resource and associate it with shared storage. You can then leverage the new iSCSI Target cmdlets to configure iSCSI LUNs (Figure 3).

There is no shortage of PowerShell cmdlets in Windows Server 2012 to help you manage your failover clusters. In addition to creating, configuring and troubleshooting your cluster, you can use PowerShell cmdlets to add new scale-out file server, iSCSI Target Server roles, clustered scheduled tasks and Cluster-Aware Updating.

Posted in Windows 2012 | Tagged: , , | Leave a Comment »

When to use Windows server failover clustering

Posted by Alin D on December 21, 2010

Confused about the benefits of adding Windows Server 2008 failover clustering to your environment? You’re not alone. There’s a lot of confusion in IT today about when and where clustering fits as a solution for improving service reliability. Server clusters are implemented all the time in IT organizations, but sometimes they’re not added to the environment for the right reasons.

First and foremost, adding Microsoft clustering to an existing service can significantly increase the cost of supporting that solution. This is obvious when you consider factors such as clustering’s shared storage requirements, added cabling and networks and more expensive editions of Microsoft Windows. Above all, the extra switches, dials and knobs that clustering adds to managing a hosted service at the same time creates a more complex environment.

Yet there are still some specific situations in which clustering can assist your uptime. In making any clustering decision, consider what the right reasons are to take advantage of its improved availability features. Remember, the added complexity won’t necessarily outweigh the benefits.

Reason #1: Clustering reduces the impact of hardware outages

When a server motherboard fails, that server usually goes down hard. Such hardware failures often result in a long-term outage of the hosted service due to the time delay in acquiring and replacing the failed part. If maintenance agreements are in place with traditional server-class vendors, it could mean a half to full day of downtime. If no agreements are in place, that time could be significantly longer. For highly-critical services, long delays like these are unacceptable.

Failover clustering provides a location for a service to automatically re-host itself when a failure occurs, which takes away the urgency of obtaining and installing the failed part. A clustered service incurs an outage of only a few seconds or minutes rather than hours or days.

Still, there’s reason for caution when implementing server clustering for this purpose alone. These days, server-class hardware comes equipped with multiple levels of redundancy. Hard drives are RAIDed, network cards are teamed; some servers even incorporate redundancy within the internal components as well. All of these reasons reduce the likelihood that a component failure will lead to the catastrophic loss of an entire system, which means you may already have the redundancy you need built into your server hardware.

Reason #2: Clustering takes the pain out of software problems

Using Microsoft Windows to host a service involves more than just processing the needs of the service. Windows alone has all kinds of moving parts, and most environments add more software to servers for things like backups, systems management, monitoring and remote control. All of these software packages at some point can conflict in a way that causes the server to stop processing your critical service.

When this occurs, server clustering can relocate the service to another node where problems do not exist. Relocation gives the administrator precious time to fix that software conflict without the added strain of a critical service failure. The result leads to better fixes and fewer “band-aids.”

And yet this reason only holds true for situations where “other” software is causing the problem. In situations where your critical service is the problem, clustering’s added machinery can in some cases make the troubleshooting and resolution process more difficult.

Reason #3: Clustering makes OS patching less painful

Every month Microsoft releases yet another round of patches for its products. Ranging from low priority to exceptionally critical, these patches need to be installed to host machines as soon as operationally possible. The problem with patches is that many require a reboot of the system to be fully installed. That reboot impacts the uptime of the hosted service.

Adding clustering to the mix enables an IT environment to relocate the service to another cluster node prior to patching, allowing the patch install and subsequent reboot to occur without affecting the service. Once you’re complete with the first node, you can then relocate the service and continue patching without impact.

However, once again this reason may not be enough. One of Microsoft’s improvements with the release of Windows Server 2008 is a reconfiguration of patches themselves; fewer of them actually require a reboot to complete. Also, at times the hosted service itself requires patching, and patching a hosted service often requires a reboot, which means downtime anyway. Your mileage will vary.

Reason #4: Clustering can be a form of disaster recovery

Using traditional failover clustering, cluster nodes must be directly attached to some form of shared storage. This storage is used for quorum information as well as the storage of data that is processed by nodes of the cluster. As such, the physical positioning of each cluster node is limited by the length of the cabling that separates the node from its storage.

Traditional clusters require this direct connection to centralized shared storage for all cluster hosts, which means a disaster that impacts one node is likely to impact others. As an alternative, Windows Server 2008 includes enhanced support for geographically-dispersed clusters, also called stretch clusters or geo-clusters.

These special clusters enable the “stretching” of cluster nodes across great distances. However, they also involve extra cost in network connectivity, added storage and usually third-party data replication between sites. In addition, they can add a significant level of complexity to existing services, which means they’re best reserved for only the most critical of services.

So the moral of today’s story is to be conscious of both pros and cons when considering whether to add failover clustering to an existing Windows service. While often (and incorrectly) failover clustering is assigned “magic bullet” status for preventing large swaths of possible outages, its design is tailored to protect against only a specific few.

Posted in Windows 2008 | Tagged: , , , | Leave a Comment »


Get every new post delivered to your Inbox.

Join 682 other followers

%d bloggers like this: