Clustered systems provide reliability, scalability, and availability to critical production services. Using Red Hat Cluster Suite, the user can create a cluster to suit an organization's needs for performance, high availability, load balancing, scalability, file sharing, and economy.
N/A
Windows Server Failover Clustering
Score 8.9 out of 10
N/A
Windows Server Failover Clustering (WSFC) is a group of independent servers that work together to increase application and service 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.
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.
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 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.
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.
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.
Both VMware and Microsoft Failover do the job and they both do it extremely well. For many bussiness and environments though, they will have the existing investment in a Microsoft environment and Microsoft infrastructure. The introduction of VMware will or may achieve the end result however it introduces new dimensions like support, licensing, documentation and ensuring the support team are trained.
Failover Cluster gives us the power to do updates or hardware upgrade / change without having to create an outage. Which permit us not to work night shifts.
By creating one cluster with all Hyper-V servers, it enabled us to move VMs via live migration between host to balance RAM usage which was time consuming and took a lot of time over network before.
It created some problems that caused us to have to investigate quite some time before finding the cause. We encountered dll locking that caused the Failover Cluster to force-restart a host. Logs are really not the strong point of Failover Cluster Manager, and even Microsoft Support wasn't able to help much. We had to find the problem ourself.
