Failover Clustering in Windows Server 2012 R2 (Part 1)

by [Published on 1 April 2014 / Last Updated on 1 April 2014]

This article provides a brief overview of the evolution of Microsoft clustering and then lists the features that are new to clustering in Windows Server 2012 and 2012 R2.

If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

Introduction

Microsoft made a large number of improvements to its failover clustering feature in Windows Server 2012, but they didn't stop there. Windows Server 2012 R2 brings us even more new features and functionalities. Some of the changes are small improvements that make the admin's life a little easier and others are significant improvements. In this article, we'll revisit the topic of failover clustering with an eye on what's new and different.

Evolution of Microsoft Failover Clustering

Clustering involves using two or more separate physical servers to create one logical server that is seen as the same to applications, with the members of the cluster (called nodes) able to monitor each and, if one of them goes down, its duties “fail over” to its partner without causing any disruption of service to users. It’s been used since the mainframe days, when IBM incorporated the idea in their “big iron” for fault tolerance. DEC’s VAXcluster came along in the 1980s and provided failover within a group of minicomputers.

If you’ve been around Microsoft server technologies as long as I have, you might remember Wolfpack back in 1995. That was the code name for Microsoft Cluster Server (MSCS) services in Windows NT 4.0 Enterprise Edition when it was in development. Microsoft added clustering abilities to their server OS to compete with UNIX, which already had that capability. Clustering increased Windows Server’s scalability and high availability by allowing applications to fail over to a second server if the primary server should go down. Interestingly, DEC (along with Tandem Computers) collaborated in the effort.

Windows 2000 Server (Advanced and Datacenter editions) included clustering support, and it was improved in Windows Server 2003. Still, early versions of Windows clustering were a bit “delicate.” Cluster chatter (nodes keeping in touch with one another’s “heartbeats”) could clog up a network, necessitating a separate network dedicated to just that traffic. Shared storage devices were required. Only a limited set of hardware that was on the HCL (Hardware Compatibility List) could be relied upon to work properly with clustering. Setting up and managing clustering was less than admin-friendly.

Things got quite a bit better with Windows Server 2008/2008 R2. The “Validate a Cluster” wizard made it much easier to tell whether particular hardware would work, and you no longer have to have identical hardware on each node. Nodes could use whatever network was available to keep in touch with one another, and it was possible to run some clustered programs without shared storage devices. PowerShell also made command-line management of clusters easier. With R2, shared cluster volumes made it easier to configure clustered virtual machines.

With Server 2012, it got easier to apply security updates and other fixes to cluster nodes, thanks to the cluster-aware updating feature. In addition, failover clustering and Hyper-V were thoroughly integrated and integration with Active Directory was also improved. Now, with the release of Windows Server 2012 R2 last September, we have the following new features:

  • Cluster dashboard
  • Shared virtual hard disk for guest clusters
  • Virtual machine drain on shutdown
  • Virtual machine network health detection
  • Ability to deploy a cluster that’s detached from Active Directory
  • Dynamic witness
  • Force quorum resiliency
  • Tie breaker for 50% node split
  • Configuration of Global Update Manager mode
  • Ability to disable IPsec encryption for communications between the nodes in a cluster

We’ll take a closer look at these new features in subsequent sections of this article.

Installing and configuring failover clustering

Failover clustering is available in both Standard and Datacenter editions of Server 2012 and 2012 R2. Before installing it, set up the public and private interfaces on the network adapters of the servers that will belong to the cluster. Best practice is to use two separate NICs. The public interface is configured with the IP address that will be used to communicate with clients over the network. The private interface is used for communicating with other cluster nodes. This is the interface used for the “heartbeat.”

If you are going to have only two servers (nodes) in the cluster, you can connect them directly with an Ethernet cable. If there will be more than two nodes in the cluster, you’ll need to set up a subnet or dedicated network for them, connecting them to a switch. You can use the 10.x.x.x private IP address range for the private network.

Note:
If you want to use NIC teaming, the teams need to be configured before you create the cluster because NICs can’t be changed after they’re added to a cluster.

Best practice is to make two disks on the server available to the cluster – one for the storage of data and one for the cluster quorum. The cluster quorum is the cluster configuration database and the cluster quorum drive is where it is stored. The quorum determines which node should be active at any particular time. You can also add additional disks to the cluster.

You’ll need Fibre Channel or iSCSI connectivity to shared storage and if you use iSCSI, you need a dedicated NIC to connect to the storage on a network that is not used for other network communication. The NICs used to connect to storage via iSCSI should be identical across all the cluster nodes.

Note:
You can’t use NIC teaming with iSCSI. You can use multipath I/O software instead.

You can use Windows Storage Spaces with failover clustering. To find out how to deploy clustered storage spaces, see the TechNet article titled Deploy Clustered Storage Spaces

Your servers that are going to be members of the cluster should be members of an Active Directory domain.

Failover clustering is installed through the Add Roles and Features wizard in Server Manager as a feature, as shown in Figure 1 below.

Image
Figure 1

After the feature has been installed, you create and manage clusters using the Failover Cluster Management MMC, which you will find in the Tools menu in Server Manager (shown in Figure 2).

Image
Figure 2

The following steps are involved in setting up failover clustering:

Validate the hardware configuration using the Validate a Configuration wizard

You can set up clusters without validating the hardware, but note that Microsoft requires validation to be performed if you want to get help from Premier Support. Microsoft does not provide support unless all the hardware passes all the tests in the validation wizard.

Create a cluster

To create a failover cluster, select Create Cluster under the Management section of the Failover Cluster Management console, and follow the steps in the wizard, which will ask you to provide the names of the servers that you want to include in the cluster, a name for the cluster and any IP address information that isn’t automatically provided by DHCP.

If you prefer the command line, you can create a new cluster by using the New-Cluster cmdlet.

When you add a new server to a cluster, Windows will need to be able to resolve the computer name with DNS.

Connect to the cluster

To connect to a cluster, simply select that option in the Management section of the Failover Cluster Management console and type the cluster name in the box or select it from the drop-down list, as shown in Figure 3.

Image
Figure 3

You can use the console to manage the cluster and its nodes, including starting and stopping the cluster service or a clustered role, pausing or resuming a node, configuring the quorum options, manage virtual machines, troubleshoot cluster problems and view reports.

Cluster Dashboard

The cluster dashboard is a new feature and it’s a small thing, but it’s one of those little things that can make a network admin’s life just a little easier in a large enterprise setup where you have multiple failover clusters. Now instead of being required to click the name of each cluster in turn in order to find out the status of each, and switch back and forth you can invoke the cluster dashboard to see the status of all of your clusters at a glance.

You get to the dashboard by opening the Failover Cluster Manager console from Windows Server 2012 R2’s Administrative Tools menu, and when you click Failover Cluster Manager in the left navigation pane, the cluster dashboard is displayed in the middle pane.

Summary

In Part 1 of this multi-part article on using failover clustering with Windows Server 2012 R2, we provided a brief overview of the evolution of Microsoft clustering and then listed the features that are new to clustering in Windows Server 2012 and 2012 R2. We next looked at some considerations in planning to deploy failover clustering and how to install the role feature, create a cluster and connect to it so that you can manage it. In Part 2, we’ll go into more detail about using failover clusters and how the new features make it easier.

If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

Advertisement

Featured Links