Windows Server Failover Clustering

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.

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

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.

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

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]

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

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.

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 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.

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

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.