Windows Failover Clustering, one of the best features available in Windows Server OS!!
We utilized Windows Server Failover Clustering as an integral part of a MS SQL cluster setup. We utilized it for almost zero downtime on …
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.
Recent Reviews
Simple and out of the box
We are currently using Windows Server Failover Clustering to serve our Microsoft Hyper-V cluster. The cluster runs our production …
You want seamless virtual machine migration with fault tolerance? Try Windows Server Failover Clustering.
We have Hyper-V implemented as our primary hypervisor and we have also implemented failover clustering with cluster storage and multipath …
Clustering at its best
We have Setup Windows Server Failover Clustering for our SQL Server Always On so that our databases are configured on Failover mode. In …
The Best Failover For Anything That Failovers
It is the backbone of our IT Infrastructure, It provides high availability of the servers to meet our business requirements, we are using …
Windows Server Failover Clustering never fails to fail over.
At our organization, we use Windows Server Failover Clustering to keep our Azure DevOps Server environment in a high-availability state …
Simple to use
We use failover clustering to provide an active-passive failover for VMs hosted on 2 physical servers. The VMs server both are …
Great choice for Windows shops
We use Windows Server Failover Clustering for our Hyper-V environment to improve the availability of the VMs. The most important problem …
Keeping It Up - Windows Server Failover Clustering for HA Applications
We use Windows Server Failover Clustering for two primary reasons: high availability and simplification of performing systems maintenance. …
Not the most stable, but so useful
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 …
What to know before implementing Failover Cluster
Windows Server Failover Clustering is used on most of our production infrastructure. We use it for our General FS Storage, Scaleout FS …
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
Product Details
- About
- Tech Details
- FAQs
What is Windows Server Failover Clustering?
Windows Server Failover Clustering Technical Details
| Operating Systems | Unspecified |
|---|---|
| Mobile Application | No |
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).
Comparisons
Compare with
Reviews and Ratings
(37)Attribute Ratings
Reviews
(1-2 of 2)Companies can't remove reviews or game the system. Here's why
August 19, 2019
Great choice for Windows shops
Verified User
Professional in Information Technology
Primary/Secondary Education Company, 1001-5000 employees
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.
September 07, 2016
Keeping It Up - Windows Server Failover Clustering for HA Applications
Verified User
Administrator in Information Technology
Logistics and Supply Chain Company, 1001-5000 employees
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.
- Windows Server Failover Clustering has enabled us to provide better adherence to SLAs while still keeping company data resources properly protected. For example, patching the operating system, repairing corrupted antivirus definitions, and the like.
- Windows Server Failover Clustering also allows us to be more proactive in the area of system resources. If we see from our server monitoring that disk capacity is growing, we can take a node down, add resources to it (disk, CPU, memory) and then bring it back online -- all without the end users being aware that it was being done. In other words, no outage. SLAs remain high and IT management is happier.
- Using Windows Server Failover Clustering on Hyper-V hosts enabled us to SIGNIFICANTLY reduct the cost of licensing Microsoft SQL Server, and by that I mean over $100,000 annually.
Several years ago we began using DoubleTake to cover our highly critical application, Control-M/Enterprise and Control-M/Server. We configured it to perform an automatic failover in the event of a critical failure. In that scenario, the system that was mirrored and came online assume the full identify of the original server. It also resulted in a short outage window, but at least the application and its data were not lost, and service was restored quickly. The downside of this was that it did not scale well from a licensing perspective for using it on many servers. The major downside of this -- other than cost -- was that if a system failed and DoubleTake performed a full system failover, the old server had to be completely rebuilt from scratch.
- Business Intelligence
- Database Administration
- Production Control
- Product and Procurement
- PeopleSoft HR
- PeopleSoft Finance
- Core Services
5
Supporting Windows Server Failover Clustering requires the expertise of a trained Windows Administrator: preferably someone with certification as an MCSE or MCITP. Windows Server Failover Clustering will not be well or properly supported by someone who does know have a depth of knowledge of both Microsoft Windows Server and Windows Server Failover Clustering.
- Microsoft SQL Server - ALL of our important databases run on Windows Server Failover Clustering in order to provide HA.
- BMC Control-M/Enterprise and Control-M/Server. This enterprise class workload automation product is extremely critical to our business. Windows Server Failover Clustering provides us with the ability to meet SLAs for this application.
- We are investigating ways to eliminate the need to install individual instances of Control-M modules on client servers by having them linked back to clustered module servers.
It has proven its value to us both for maintaining SLAs and providing the ability to perform much needed and regular systems maintenance without taking applications offline for more than a few seconds.
- Until you have the knowledge of how clustering works, and particularly how Windows clustering works, you will only end up banging your head. It is critical that a neophyte to Windows Server Failover Clustering learn and understand how it all works before embarking on a project as complicated as this can be.
- Setting up the initial cluster can be very tricky. It isn't a case of just accepting the defaults and clicking on the "Next" button. You have to know what your doing. For example, you have to create a cluster resource with its own IP address separate from that of the nodes. IP for node 1. IP for node 2. IP for cluster. I would also suggest using a CNAME in DNS that points to the cluster name. That way, no matter which node is the active node you can still get to it.
With adequate knowledge, it is pretty easy to work with and manage a Windows Server Failover Cluster. It can, however, be very confusing in combination with Hyper-V to the neophyte. For example, learning when to use the Hyper-V Manager and when to use the Failover Cluster Manager.