When we talk about Windows Clustering, we are always talking about the need for High Availability. Clustering is the way we achieve High Availability in the event of a hardware failure of one of your servers. Clustering ensures that your roles or workloads fail over to another node so users can continue to work.
What is a Failover Cluster?
A failover cluster is a group of independent computers that work together to increase the availability and scalability of clustered roles (formerly called clustered applications and services). The clustered servers (called nodes) are connected by physical cables and by software. If one or more of the cluster nodes fail, other nodes begin to provide service (a process known as failover). In addition, the clustered roles are proactively monitored to verify that they are working properly. If they are not working, they are restarted or moved to another node. Failover clusters also provide Cluster Shared Volume (CSV) functionality that provides a consistent, distributed namespace that clustered roles can use to access shared storage from all nodes. With the Failover Clustering feature, users experience a minimum of disruptions in service.
That definition came directly from our Failover Clustering Overview document located here and it also talks in detail, about the practical applications of clustering and the requirements of a clustered environment. Another thing I want to clarify; Clustering does not require System Center. Windows Server has a lot of clustering capabilities included in the product. System Center is beneficial when you have a large number of servers to manage, but in the SMB space, System Center is not needed.
What can I use a Windows Cluster for?
At this point, you may be asking, What can I use a Windows Cluster for? As I mentioned, you’ll use a Windows Cluster, when High Availability is needed. I use my Windows Cluster primarily for virtual machines. I also have a Highly Available share setup. Highly Available shares are another benefit of Clustering and provide the ability for a share to exist even through a hardware failure. Earlier, Steve talked about DFS and its ability to persist even through a hardware failure. Clustering is another way to achieve this same objective, but for more than just file shares.
What’s new in 2012 R2?
If you are familiar with Clustering from prior versions of Windows Server, we have a great document that calls out the new capabilities in Windows Server 2012 R2 Clustering.
How do I know it really works?
One of the items I really like about our clustering capability is the validation of the actual cluster before you put your cluster in production. As an implementer, how do you verify that you implemented a solution properly? You test it, how long can that take? and what if you forgot something? With Windows Server Clustering, we have the Validate a Configuration Wizard to ensure your cluster is setup and working properly, before you bet your product environment on it. You can find the details on validation here.
What type of hardware is Available?
Of course, by the definition above, clustering requires more than one server and some type of shared storage. Shared storage means that both servers can simultaneous access the storage. Shared storage, like a SAN, can be expensive, but there are other options; options like a Cluster in a Box (CiB). I blogged about the cluster in a box a couple years ago here, and this unit is still running like a champ. If you want to go down the path of a CiB, we even have a CiB validation kit here. While I honestly don’t think you’ll want to build your own CiB, you will want to check out some of the validated solutions on the right hand side of the page.
When you think about delivering on-premises workloads for your customers, remember that a Windows Cluster can deliver a resilient solution at an economical cost.
Please check out our whole series on Windows Server 2012 R2 at https://aka.ms/ts2windowsserver2012r2
Until next time,