Community Pick: Many members of our community have endorsed this article.
Editor's Choice: This article has been selected by our editors as an exceptional contribution.

Shedding some light on Windows clustering terminology

Ryan McCauleySenior Data Architect
I'm a lover of data - management, querying, and presentation. I'm happy to help make things reliable, quick, and arranged to tell a story.
I wanted to clear up some terminology around Windows Clusters that seems to cause a bit of confusion. I've stumbled across a few questions on this site, as well as others (like StackOverflow) where the concept of Windows cluster seems to be surrounded with some confusion, and there are a number of questions like "clustering servers" and "how to install an application to a cluster", and I'm hoping this helps clear things up a bit.

At least in the Windows world, there's really no such thing as a clustered server. Servers can have clustering enabled and configured, but the servers themselves aren't really clustered - they're just set up to enable clustered applications. When servers are part of a cluster, they still do all their thinking on their own, including running their own applications, services, and tasks, without the other servers in the cluster even being aware.
You don't cluster servers, you cluster applications and resources on those servers. Once servers have had clustering installed and are configured, you can cluster an application or a resource. This clustering is really just telling the cluster manager that you want it to control which server clients talk to when they want to access the resource. The cluster manager ensures that the application (or service or resource) is running on only one node at any given time, and to the extent it's able, it ensures that it's always running (watching for a failure and bringing the resource online on another node and then directing clients to that node instead).
Clustering doesn't involve any kind of load balancing. Clustering ensures that one (and only one) server in a cluster is running a service at any given time. However, only one server is responding to client requests - if you want to balance the load across multiple different servers, clustering isn't the way to do that. You'd need to run the application simultaneously on each node in your load balance, and then have a way for clients to pick a node based on some criteria (this is typically load-balancing hardware or a VM, but can even be Windows Network Load Balancing). People new to clustering tend to think that "Active/Active" clusters are load balanced, but they're not - that just refers to a situation where different clustered components are active on each node, as opposed to all on one node (with the second acting as a standby). For more information, check out "The Misconception of Active/Active Clustering"
Applications don't have to be "cluster-aware" to be clustered. I work mostly with SQL Server, which is cluster-aware, but applications you cluster don't need to be. You can cluster any service, or resource on a server by just adding it to the cluster manager - the cluster manager will ensure it only runs on one server at a time, not allowing it to start on other nodes, and the Windows Cluster service is responsible for coordinating a single point of client access. For example, we use a monitoring tool that runs as a service - we installed the service on each cluster node and then added to the cluster manager - it now can be failed back and forth between nodes as a clustered resource, so it's always online, is failure-resistant, and shares a segment of the HKLM in the registry between nodes - all without being explicitly cluster-aware.
SQL Server doesn't need to be clustered when it's installed on a cluster. While you can install a clustered instance of SQL Server (which automatically registers everything with the cluster manager), you can also install stand-alone instances of SQL Server (or any other application) on a cluster. That's actually how a new feature in SQL 2012 -AlwaysOn - works: You install a non-clustered instance of SQL Server on different cluster nodes, and then you let the cluster manager coordinate client connections to the SQL Servers, but they still operate independently and replicate their data between each other.

Hopefully this clears things up and doesn't lead to more confusion. When I first started working with clustering, I had the impression that setting up a cluster caused the servers to act as one and share all their resources, but that understanding led to a lot of confusion when it came time to set something up or troubleshoot an issue. With the understanding that "clustered servers" are really just servers with clustered resources, and not actually clustered themselves, hopefully it will simply things!

This Article was originally posted on my blog at
Ryan McCauleySenior Data Architect
I'm a lover of data - management, querying, and presentation. I'm happy to help make things reliable, quick, and arranged to tell a story.

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.