Skip to main content
TrustRadius
Windows Server Failover Clustering

Windows Server Failover Clustering

Overview

What is Windows Server Failover Clustering?

Windows Server Failover Clustering (WSFC) is a group of independent servers that work together to increase application and service availability.

Read more
Recent Reviews

Simple to use

9 out of 10
December 06, 2019
Incentivized
We use failover clustering to provide an active-passive failover for VMs hosted on 2 physical servers. The VMs server both are …
Continue reading
Read all reviews

Awards

Products that are considered exceptional by their customers based on a variety of criteria win TrustRadius awards. Learn more about the types of TrustRadius awards to make the best purchase decision. More about TrustRadius Awards

Return to navigation

Product Details

What is Windows Server Failover Clustering?

Windows Server Failover Clustering Technical Details

Operating SystemsUnspecified
Mobile ApplicationNo

Frequently Asked Questions

Windows Server Failover Clustering (WSFC) is a group of independent servers that work together to increase application and service availability.

Reviewers rate Support Rating highest, with a score of 8.2.

The most common users of Windows Server Failover Clustering are from Mid-sized Companies (51-1,000 employees).
Return to navigation

Comparisons

View all alternatives
Return to navigation

Reviews and Ratings

(37)

Attribute Ratings

Reviews

(1-3 of 3)
Companies can't remove reviews or game the system. Here's why
Score 8 out of 10
Vetted Review
Verified User
Incentivized
At our organization, we use Windows Server Failover Clustering to keep our Azure DevOps Server environment in a high-availability state for our end users. Both the application tier and the SQL tier are clustered so that if there is a network fault or outage, the system will fail-over to the other server node, and the user can continue to work without knowing the server was down.
  • Works great with SQL Server clustering
  • Highly configurable, but simple and intuitive
  • Cluster events are shown in the tool (No need to go to the Windows Event Logs)
  • Would be nice if the tool had built-in alerts for when a fail-over occurred
  • Only one network card on a node in the same network
Windows Server Failover Clustering is well suited for organizations that need to have systems running in a high-availability mode. If there are systems that would pose a high cost to the business if there is downtime due to unplanned events, then Windows Server Failover Clustering will help assure 24/7 uptime. Also, clustering can be helpful for planned events, such as server updates. You can install an upgrade on the inactive node and then fail-over manually, switching the active and inactive nodes, upgrade the other node, and then failback. Also, while I don't have direct experience with this aspect, my understanding is that Windows Server Failover Clustering is also well suited for load balancing VMs.
  • Failover clustering saves the business thousands of dollars when unplanned network outages occur thanks to 24/7 uptime of our critical systems.
  • Failover Clustering saves the business thousands of dollars for planned outages, not needing a blackout period for our users.
Windows Server Failover Clustering is the only clustering tool I've used. I am new to clustering and have nothing else to compare it to. That said, it does the job as needed. I never felt the need to investigate other options.
Online documentation is excellent. Everything I needed to know, I learned from the online documentation. I haven't used phone support as I haven't needed to but would presume it is similar to Microsoft Support for other products that I've used. Phone support from Microsoft is hit and miss. It depends on who you get. That said, my rating is based on the online documentation.
December 06, 2019

Simple to use

Score 9 out of 10
Vetted Review
Verified User
Incentivized
We use failover clustering to provide an active-passive failover for VMs hosted on 2 physical servers. The VMs server both are public-facing websites and our internal CRM so completely mission-critical to the entire business for continuity. This gives us the redundancy and the ability to keep things going when constantly updating windows! WFC has some very advanced features but our needs are fairly simple and this works really well for us.
  • Redundancy - We can spead the VMs that we use across 2 physical servers, but should one go down it all switches to the working one.
  • Spread the load - We can assign preferred servers for the VMs to run on so when they are available the VMs can be set to run on specific hardware.
  • Has a pretty steep learning curve.
  • Can be a lot of hoops to jump through to get up and running.
  • Easy to missing settings buried in the GUI.
For us it's a no brainer, we're a Microsoft tech house so to have a couple of physical boxes to spread the load and provide redundancy it the only way to go. Included in the OS so it makes sense to make use of it.
  • Minimized loss of access to mission critical applications.
  • Has been the cause of 1 though where the failover didn't happen, had to force the active VM to off to make the fail over happen.
Only ever used WFC so cannot speak of other technologies or alternatives. As mentioned we're a Microsoft tech house and its included int he server OS so it just makes sense to use it.
It's so widely used you are going to find plenty of resources online and forums on which to ask should you not. I'm pretty sure that the "issues" that we have come up against all have been solved via a quick Google!
Score 8 out of 10
Vetted Review
Verified User
Incentivized
We use Windows Server Failover Clustering for our Hyper-V environment to improve the availability of the VMs. The most important problem addressed by Failover Clustering is the reduction of the downtime for server maintenance. Standalone Hyper-V hypervisors tend to need a lot of downtime for Windows updates. The entire organization uses VMs running on top of the Failover Cluster. We use a hyper-converged solution with Failover Clustering to avoid the need to purchase expensive SANs, so the cost of improved uptime is relatively low.
  • Reduced outages for server maintenance. VMs can be live migrated from the node being taken down for maintenance to avoid outages. With Cluster-Aware Updating (CAU) it is possible to run Windows Update on cluster nodes automatically.
  • Very fast live migration and failover. With hyper-converged DAS, live migration is so fast, it is hard to see the VM outage in the RDP session.
  • Inexpensive. Failover Clustering is included in Windows Server. For educational organization, Windows Server licenses are extremely cheap.
  • iSCSI configuration can be confusing. To achieve redundancy, each node in the cluster must have redundant (multi-path) access to storage (iSCSI, FiberChannel, etc.). Configuring iSCSI multi-path correctly can take several tries.
  • The configuration is time-consuming. Cluster Validation Wizard is verbose - takes a while to read through and check all the issues. It is still very important to go through all of the information though. It is easy to configure a cluster that seems fine but does not failover when needed.
  • Not really a drawback but the effort must be made to understand quorum configuration if a cluster has even number of nodes. I would suggest doing multiple failover tests before using the cluster for production, including pulling power cables from nodes and disconnecting network cables to simulate switch failure.
Windows Failover Clustering is a good fit for a medium to a large organization with a predominantly Windows Server environment. VMware and Linux shops have their own clustering options. A cost-benefit analysis should be used before deploying a cluster, as extra capacity for failover is an additional expense. As servers are quite reliable, stand-alone hypervisors can be a better fit for a small business, which can tolerate outages for maintenance. While Failover Clustering feature itself is included in the Windows Server license, cost of extra servers and especially SANs (if used) is significant. The organization must calculate whether reduced downtime is worth the expense, especially considering that clustering by itself does not guarantee high availability.
  • Maintenance windows were dramatically reduced as a result of Failover Clustering implementation, reducing overtime.
  • Hypervisor failure is not expected to result in the outage of critical services anymore. I suggest doing realistic testing of failover by pulling power cable from one of the nodes.
  • It is much faster to migrate VMs between the nodes than stand-alone Hypervisors, so less time is spent on VM provisioning.
Usability of Failover Clustering on Windows Server is generally good. Failover Clustering console is not hard to understand if the complexity of the product is taken into account. Most of the task on the Cluster can be done via PowerShell, so automation is possible and not hard (PowerShell is very intuitive). Configuring storage is the hardest and most confusing task during cluster configuration, so storage configuration should be planned in advance. Cluster Validation Wizard is verbose but most of the errors are easy to understand.
We never contacted Microsoft regarding Failover Clustering. Documentation is mostly good and readily available. Not much can be said here.
Obvious competitors are VMware ESXi clustering and Linux KVM clustering. Windows Server Clustering was selected instead as most of our server environment is Windows Server based. Windows Server licenses were readily available, so Windows Clustering was an inexpensive option. ESXi would have been out of our budget. KVM was not used to keep the environment simple and unified on the Windows platform. Various pre-built hyper-converged appliances from vendors like Scale Computing were ruled out as we wanted to re-use existing servers.
Return to navigation