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

(38)

Attribute Ratings

Reviews

(1-11 of 11)
Companies can't remove reviews or game the system. Here's why
Edwin Labirua | TrustRadius Reviewer
Score 9 out of 10
Vetted Review
Verified User
Incentivized
We utilized Windows Server Failover Clustering as an integral part of a MS SQL cluster setup. We utilized it for almost zero downtime on our Microsoft SQL serving our on prem Sharepoint implementations, as well as several critical IT infrastructure systems that need a SQL database back end. This allows us to perform maintenance and patching without affecting the applications that use the SQL server. It's deployed on a active passive setup. We also set up a test Hyper-V high availability cluster.
  • It allows us to perform maintenance and patching on the passive node without having to shutdown the database and incurring downtime.
  • We are able to repair a failed server but failing the database over if there is a hardware failure on the active node. Minimizing downtime on the database.
  • It provides an automated recovery when there is failure without IT intervention when there is an issue.
  • The setup of the Windows Server Failover Clustering is complex, requiring different networks and multiple network cards.
  • Better integration between the Windows Failover clustering and Hyper-V. Unlike VMWare you have to make changes to two places instead of just one panel.
  • I wish there was a web portal to manage the cluster. Instead you have to remote desktop into the VIP address and go to the Cluster manager.
It works fantastic in conjuncture with the MS SQL cluster setup. When a SQL node had a hardware failure, it failed over to the passive node. No one was the wiser that anything happened to the system until our Operations department realized that node was down. We were able to repair the server and bring it back up without causing issues on the database. Which meant the application was also still up, which we were very happy with. I didn't like it when used with Hyper-V to setup a cluster, although it allowed us to set it up similar to a VMWare cluster, I did not like having to go between the Windows Failover Clustering manager then the Hyper-V manager to work on a VM. It also caused a small issue when one of my colleagues setup a VM, he forgot to add Windows Failover Cluster.
Score 9 out of 10
Vetted Review
Verified User
Incentivized
We are currently using Windows Server Failover Clustering to serve our Microsoft Hyper-V cluster. The cluster runs our production environment comprising of email services, file services, database services, remote access, and more. All Microsoft Hyper-V roles are clustered and their storage is also managed by the cluster. It is currently running in a two node environment.
  • Easy to use
  • Out of the box
  • Documentation is readily available
  • Include storage spaces as part of the same feature set along with storage tiering
Windows Server Failover Clustering is very well suited for any environment. From a one man IT shop to a business run by a large support team. It can provide easy failover between its nodes. Especially in the case of schedule maintenance on a Hyper-V node, all you need to do is ensure all roles are drained and moved to another node along with storage.
Score 8 out of 10
Vetted Review
Verified User
Incentivized
We have Hyper-V implemented as our primary hypervisor and we have also implemented failover clustering with cluster storage and multipath IO to mitigate node failure without impacting our work loads, in case of cluster node failure it seamlessly migrates workloads to other hypervisors without any downtime, the other benefit is that when we are updating hypervisors we live migrate virtual machines to different nodes in same cluster and restart one by one that results in no downtime and hassle free operation. it simply made management of virtual machines simpler and improved overall uptime of our infrastructure.
  • Seamless Live Migrations
  • Quick Migrations
  • Failover in case of Node Failure
  • Storage Migration
  • Shared nothing live migration need some improvements.
  • Cluster events are not very understandable.
  • Cluster validation.
I have observed while moving multiple virtual machines failover cluster starts slowing down, so we move a maximum of two live migrations at a time, but quick migration is far faster. We used it for replicas and noncritical workloads. Windows Server Failover Clustering is very well suited for small to medium-sized organizations, i.e. its good for a few hundred virtual machines. The features present in failover clustering are getting better with each iteration.
Score 9 out of 10
Vetted Review
Verified User
Incentivized
We have Setup Windows Server Failover Clustering for our SQL Server Always On so that our databases are configured on Failover mode. In case any of our servers failing to respond this service will move our databases from the primary server to the disaster recovery server. Our Information technology department uses it and the user across the organization is not aware of what we have deployed or what is our architecture.
  • Failover Priority setting , i.e. High, medium , low.
  • online services movement.
  • Online data movement across clusters.
  • No downtime,
  • Easy role movement
  • Quorum settings should be improved
  • San environment should be improved
  • Logging of Cluster events should be improved
SQL Server in always-on mode is the best suitable for Windows Server failover clustering rather than configuring the SQL Server in cluster mode having the same disk and the disk will be moved with all databases, alwaysOn is the best and suitable way to configure it on Failover Clustering as we have two separate disks and database files on the separate servers.
Score 10 out of 10
Vetted Review
Verified User
Incentivized
It is the backbone of our IT Infrastructure, It provides high availability of the servers to meet our business requirements, we are using it for failover solution of our exchange servers and database servers, Microsoft is working hard to making it better day by day and with the newer version 2019 we can failover to a cloud or on premises both.
  • It is reliable, its fast, it is the best you would not even know that you have been switched to other node.
  • Clustering based on geographic distribution
  • Multiple server multiple site deployment
  • Configuration could make easier
  • [I feel] pricing should be considered for middle size organizations to adapt it
  • Storage pool and VDM configuration is confusing [in my experience]
Best for organizations that require 24 hours of enabled IT infrastructure to support business needs so incase of any updating activity or a disaster the user won't even know what had happened at the back and ensure smooth operations. Hot plug scalable storage is a good option for organizations using RDBMS and thin clients as well.
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.
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.
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.
Score 10 out of 10
Vetted Review
Verified User
Incentivized
We use Windows Server Failover Clustering for two primary reasons: high availability and simplification of performing systems maintenance. Our failover clustering allows critical applications to continue with only a minor interruption in service if a needed system resource fails. It also allows systems administrators to failover an application to a passive node in order to perform scheduled or un-scheduled maintenance on the other node, and then fail back if necessary, all with minimal interruption of critical business applications such as Microsoft SQL Server and BMC's Control-M Workload Automation.
  • Windows Failover Clustering is well suited to keeping critical applications online with only a brief outage in services during the actual failover. In some cases, it will disconnect user applications during the failover. That isn't a good thing, but better than taking the entire application down for a longer period of time to shutdown one server and bring another online.
  • Windows Failover Clustering can be easily configured to manage individual cluster resources. For example, we use BMC Control-M/Enterprise and Control-M Server. Our gateway resources for distributed systems and mainframe (z/Os), are managed well as individual resources within the cluster, allowing us to take a single resource offline when necessary, without having to take the entire cluster down.
  • When used in combination with Microsoft PowerShell (now also available to Linux systems), it provide tremendous ability to monitor, query, report, configure and deploy systems in high availability (HA) infrastructures.
  • The disconnection of services or users -- brief though it may be -- is a drawback to a seamless failover. The failover process is generally quick, and in many cases invisible to the business end user community, but with the variety of applications and how they interact with Windows Failover Clustering, sometime there is a brief outage (seconds) that does NOT go unnoticed.
  • Windows Server Failover Clustering in a Hyper-V environment can be a little tricky if the Hyper-V infrastructure is not properly configured at the cluster level for affinity. If you are considering using Windows Failover Clustering in combination with Hyper-V, be sure to set your affinity rules so that both nodes are never on the same host.
  • Error reporting is quite detailed, if you know where to look. What appears in the Critical Events list for a cluster, and even the Windows Event Logs can lead one to think that Microsoft overlooked that critical area. You have to dig deeper into the Windows logs -- not just the usual three of Application, System and Security -- to get meaningful and helpful detailed error data.
Windows ServerFailover Clustering works very well for applications that can sustain a short disconnect when failing over. It works, and works well, in providing single-node applications HA, meaning an active/passive setup. It is not a load balancing solution. Use NLB for that. Another area that it works well is when used in combination with Hyper-V. We set our Hyper-V hosts up as clusters, and those clusters also host clusters for SQL Server and other enterprise class applications like BMC's Control-M/Enterprise and Control-M/Server.
Tommy Boucher | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User
Incentivized
We started using Failover Clustering a while ago with Windows 2008 Hyper-V. We had a lot of issues (Cluster crash) and upgraded to 2008 R2, 2012 and 2012 R2, with the same issues. However, the cluster may not be a 100% stable, but it helps a lot regarding maintenance and upgrade. Instead of having to shutdown everything, we move the virtual machines from one host to another. When a VM job in the kernel, the full cluster goes down. We than started using Failover clustering for File Share and Scale-Out File-Share to host company files, and VMs (over SMB3). At some point we had one of the host that crashed, and when hard-rebooted, the other host when down because of the failover cluster. Also, when moving the FileShare roles from one host to the other, the disk 'time-out' for a while, that makes the file server very slow. It's not perfect, but it's very useful
  • Maintenance - You can move all the roles to the other host, and update/upgrade without interruption.
  • Integrated - Based for many roles in Windows Server
  • Easy to use - Not many options, but easy to figure out
  • Limited - Not much you can configure or tweak
  • Unstable - Sometimes dies for no reason
  • Cluster Validation - It never goes right. Always a lot of errors
This is very good to help your availability for your maintenance, but you should not based your full infrastructure on it. Make sure to backup, and monitor.
Marc-Olivier Turgeon-Ferland | TrustRadius Reviewer
Score 9 out of 10
Vetted Review
Verified User
Incentivized
Windows Server Failover Clustering is used on most of our production infrastructure. We use it for our General FS Storage, Scaleout FS Storage, and Hyper-V Clusters. Because it is used for our VM environment, it is used by the whole organization. It provide us High Availability on those services.
  • Live Migration of VMs between hosts. If you have sufficient network bandwidth, it is fast and I never had a failed live migration break the VM or kill it. Worst case is the live migration will fail (not enough RAM for example) but the VM always stayed up.
  • Windows Server Failover Clustering enables Scaleout Storage, which is probably the coolest feature Microsoft has to offer at this moment. It gives you Active-Active SMB file shares which can now be used by most Microsoft Services like MS SQL, Hyper-V, etc. and clients if Windows 8+
  • Cluster Validation is really complete and easy to understand. The validation gives you comprehensive error messages that help to diagnose and fix rapidly to get your Failover Cluster running in no time.
  • Storage Pool / Virtual Disk management via the Failover cluster is confusing. You sometime needs to initiate the task from the Failover Cluster Manager (to have the right permissions) but it just use the new Server Manager Console. It is also possible to see information like number of columns of VD from the Failover Cluster Manager console, but you can't see the deduplication stats. It would be nice to at least have all the information available on both console or eliminate one of them.
  • General FS switchover between nodes is slow and creates timeout when switching nodes. Failover Cluster doesn't seem to manage VD ownership that well. I even had a case where the VD was locked by a shutdowned node (bluescreen) which brought the whole cluster down.
  • DLL locking also doesn't seem to be well handled. We had multiple cases where the Hyper-V cluster crashed because some waiting for restart updates locked dll.
It is well suited for redundancy during Windows Updates, hardware maintenance, or any outage where you are present in case something goes wrong. It is not well suited for redundancy during, power outage, bluescreen, hardware failures, etc. because I have seen Failover Cluster bring the whole cluster down on all those cases. It even causes more chances to bring down the services sometimes (dll locking, VD locking)
Return to navigation