What is Failover Clustering in Windows Server 2012?

Resilience is key to any network. It's not enough to deliver a network's files, resources, and applications to its users when times are good. A network has to be highly available despite a server failure or device outage. One approach to doing that is the failover cluster method. Starting with Server 2012, Microsoft unveiled failover clustering.

Like any advanced networking technique, failover clustering in Windows Server 2012 is complicated and nuanced. That's why so many people undergo advanced Windows Server training to understand it. But by the end of this blog post, you should have a sense of how to navigate the Failover Cluster Manager and what the technology is capable of.

What is High Availability?

Quick Definition: High availability is a term in the networking world that describes an agreed-upon level of performance in a network. It usually refers to a network's uptime or a guarantee that a network and its resources will be available for an explicitly high percentage (e.g., AWS promises its networks will be available 99.99% of the time).

High availability has become ubiquitous, but it is generally a characteristic of a network, so you might refer to a network as "highly available" or the technology that enables it to be so.

What are High Availability Clusters?

Quick Definition: High-availability clusters are an advanced networking technique for ensuring that networks can maintain service in spite of outages. A high availability cluster is a group of computers that coordinate to monitor when failures occur and shift responsibility for delivering network services seamlessly. High-availability clusters depend on redundant computers in groups or clusters to ensure network operations.

What is Failover Clustering in Microsoft Windows Server 2012?

Quick Definition: Failover clustering is Microsoft's implementation of the high-availability cluster method for providing high availability in applications and services. Clustered servers, called nodes, provide services in the event of a different node failing. In addition, the Windows Server software administers oversight of the roles of the clustered nodes and ensures they're operating properly.

An Overview of Failover Clustering in Microsoft Windows Server 2012 [VIDEO]

In this video, Tim Warner covers how the failover clustering method provides high availability in applications and services. Microsoft made several tremendous improvements to this process in Windows Server 2012, and Tim gives a brief overview of those here, along with a detailed description of the process

How Does Failover Clustering Work?

Failover clustering depends on setting up physical servers and kitting them as close to identically as possible. These are called nodes, and they all get attached to some form of shared disk storage, which could be anything from iSCSI to a fiber channel.

In addition to that connection to the shared disk storage, each node, in a traditional act of passive cluster, can host a particular workload. That could be an installation of SQL Server, it could be a highly available fileshare, it could be one or more hyper-V virtual machines. The key is that whatever highly available resource we're running for the network, we want to ensure that the loss of one or more nodes keeps at least one node up that can host it and provide services to our users.

Failover clustering works by abstracting the highly available service and presenting a virtual IP address and virtual DNS hostname to users and applications.

As an example, think about SQL Server. Imagine an arrangement in which your end-user application might have one connection string to a destination we'll call SQL1 at 10.0.99. But, in fact, all those queries and long-running processes with SQL Server are being handled by one single box. That box sits inside a cluster, and it's the box designated Active for that role.

In turn, the actual database and transaction log files are stored in the shared disk storage — that central shared location we talked about above. The reason the database and files are stored elsewhere is so that if we need to administratively take a node down or if it suffers a failure, we can have a seamless and transparent failover to another node.

If we ran SQL Server on Node2 and took it offline for maintenance, Node1 could failover. But then, when it came back online, we could Failback the role. Meanwhile, throughout all the transfers, the end-user application has no knowledge that any failure occurred because it's seamless to them.

What is Microsoft Failover Cluster Manager Console?

We can't exactly cover every part of Microsoft Windows Server failover clustering particularly how it's done in Windows Server 2012. That topic could fill an entire series of posts and videos. In fact, it did: CBT Nuggets has a complete training series for Microsoft's certifying exam 70-412 on Configuring Advanced Services in Server 2012. For our purposes here, we'll just cover the basics of navigating Microsoft's management console, Failover Cluster Manager.

Failover Cluster Manager is a versatile GUI, but also, in WS2012, we have incredible PowerShell support. For example, if you navigate to PowerShell and type:

get-command -module FailoverClusters

You'll see a table of results you can scroll through. We'll be focusing on the GUI, but this command will show you all the cmdlets that enable you to administer just about every conceivable option for creating, monitoring, and maintaining the failover cluster.

The Failover Cluster Manager in Windows Server 2012 is the main GUI tool for creating and administering clusters. Moving forward, we're assuming you have a virtualized or actual network with which you can follow along and use Failover Cluster Manager on your own.

How Does Microsoft Failover Cluster Manager Work?

When you start the application, you should see a tree view in the left sidebar. This displays any clusters that have already been built. Whether you're trying to deploy a failover cluster of two nodes or 64, there are many prerequisite steps to follow. For this post, we'll assume that a cluster has already been built so that we can navigate the various features of cluster management.

The Failover Cluster Manager tree view displays several sections and selections. First, we have Roles. Clicking "Roles" shows a representation of the highly available apps and services that can be put in a cluster.

In the left sidebar, right-clicking "Roles" and going to "Configure Role" brings up the High Availability Wizard. If you play around with it, you'll see that out of the box, the High Availability Wizard enables you to configure several options: Highly Available DHCP, File Services, Hyper-V, Message Queuing, and even the option to make another non-listed service or application highly available.

In the left sidebar, under "Nodes," we find all the nodes in our cluster. A node, as we said, is a server resource in the cluster that can host one or more highly available roles.

Another option in the left sidebar is "Storage." Failover Cluster Manager for Windows Server 2012 provides a lot of flexibility with disks, and this section is where you can configure them. Server 2012 makes particularly good use of the expanded use of the Cluster-Shared Volume (CSV). Some versatile, high-availability file-share tools rely on CSV.

CSVs are also helpful when you're doing highly available virtual machines. You can migrate virtual machines independently. All of them can reside on the same Logical Unit Number (LUN), and you can move them around or migrate them independently.

Also under the Storage button is "Pools." That section is where we would find support for storage pools and SASS disks. One of failover clustering's great strengths is the flexibility you get in terms of what you can do with disks.

If you and your organization depend on Hyper-V or virtual machines, there's a tremendous interplay between failover clustering and Hyper-V for apparent reasons. If you were to lose a Hyper-V server, you're not only losing that server. But if you're hosting a dozen virtual servers on that Hyper-V host, you could have a catastrophic outage in one fell swoop.

"Networks" is another option in the left sidebar. You typically have more than one Network Interface Card on each failover cluster node. One is for internal heartbeat messages, another is for your storage LAN, and a third is for your user LAN, to which your users are connected. Using this tab, you can drill in and look at those connections and their statuses.

The last button on the left sidebar is "Cluster Events." This section retrieves from our event log only those events pertinent to a cluster configuration. Future posts will discuss making sense of those events and translating them into action for your network.

How to Force a Failover and Then a Failback in Server 2012

To wrap up our discussion of Failover Clustering in Windows Server 2012, let's talk briefly about how to cause a failover and then a Failback to normal operations.

In our case, we have a box called "HVNUGGET2." It's hosting a highly available file share. When we set it up, we chose a new feature for Server 2012 called Scale-Out File Server.

In our example network, we have another node in our Node section. It's titled "HVNUGGET3," and it's not hosting any roles at the moment. What do you imagine would happen if we were to stop HVNUGGET2?

To do this, we right-click the node in question—in this case, HVNUGGET2—and go to More Actions -> Stop Cluster Service. We click "Confirm" on the dialogue that appears, and in seconds, HVNUGGET2 is down. In a real-world setting, this could be for administration or maintenance.

After doing this, we'll see that the Scale-Out File Server, our highly available file share, is running on HVNUGGET3 just fine—with no interruptions at all. That simple example illustrates what failover is all about. Using Failover Clustering in Windows Server 2012, we can take a server down and have its highly available resources remain active thanks to another node in the cluster.

If we want to move the resource back to HVNUGGET2, the first step is to bring it back online. We do that by right-clicking the node in the left menu and navigating to More Actions > Start Cluster Service.

Once the node itself is online, we navigate back to HVNUGGET3, right-click the resource itself (SOFS as an actual role being performed by HVNUGGET3), select Move > Select Node, and make sure we have the target node chosen. Click confirm, and it's moved. Don't forget, all of this is live movement with virtual machines, it's called Live Migration. You can have your VMs up, running, and in use when you shift them to a node. That works administratively or in the event of an actual failover.

Wrapping Up

Admittedly, this is only a surface-level familiarization with Failover Cluster Manager and how it makes Failover Clustering with Windows Server 2012 easier than it's ever been.

The bottom line is simply this: between Failover Cluster Manager and iSCSI, setting up failover clustering has never been more affordable than it is with Microsoft Windows Server.