Windows Server Failover Clustering

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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)