We use the most basic features of the product.
Windows Server Failover Clustering is renowned for enhancing server availability and redundancy, offering features like CSVs and cluster role failover, supporting virtual machines and enabling high availability with seamless switchover.
| Product | Mindshare (%) |
|---|---|
| Windows Server Failover Clustering | 15.9% |
| InfoScale | 20.5% |
| DRBD | 13.4% |
| Other | 50.2% |
| Title | Rating | Mindshare | Recommending | |
|---|---|---|---|---|
| InfoScale | 4.2 | 20.5% | 100% | 8 interviewsAdd to research |
| DxEnterprise | 4.3 | 9.2% | 100% | 3 interviewsAdd to research |
Failover Clustering provides stable, scalable, and highly available systems by allowing users to form clusters using identical servers, ensuring seamless handling of requests. It supports virtualization and can automate master election within a cluster, with geo-redundancy features. While known for its robust functionality, there is room for improvement in technical support and network configuration dependencies. Desired enhancements include better pricing, a simplified hyper-convergence system, and intuitive settings for selecting cluster preferences. Users often integrate it with SQL servers and storage solutions, deploying it for applications requiring high availability.
What are the key features of Windows Server Failover Clustering?In industries like IT and data management, Windows Server Failover Clustering is vital for maintaining uptime and ensuring data integrity. It plays a crucial role in financial services, healthcare, and telecommunications, where continuous access to critical applications like SQL databases and MySQL is essential. Organizations deploy it to achieve optimal operational continuity and reliability.
| Author info | Rating | Review Summary |
|---|---|---|
| Engineer at Magal Solutions | 4.5 | We primarily use Windows Server Failover Clustering for its basic features like virtualization and failover. The system is stable but requires less dependency on network configuration. Exploring standard alternatives was considered as our network setup can become costly. |
| System Administrator at Confidential | 4.0 | I use Windows Server Failover Clustering for high availability and automated failover. It's stable, but unexpected shutdowns can complicate master election recovery. Initial setup requires extreme caution regarding disk configuration to prevent data loss on existing servers. |
| Manager at Stark International | 4.0 | I've used Windows Server Failover Clustering for seven years; it's stable and scalable with valuable features. However, inconvenient restarts for updates cause downtime, making me seek alternatives despite my 8/10 rating. |
| Project Manager at IDPoints Ltd. | 3.5 | I use Windows Server Failover Clustering for warehouse SQL servers due to its valuable hot-swap feature, allowing seamless server transitions during failures. However, setting it up is challenging as it relies on external storage instead of integrated solutions. |
| Solution Specialist at a consultancy with 51-200 employees | 4.0 | In my experience, Windows Server Failover Clustering effectively ensures server continuity by switching to another server if one goes down. However, the pricing is high. I deployed it using Microsoft Azure and didn't consider other solutions. |
| Systems Network Engineer at a computer software company with 11-50 employees | 3.5 | I primarily use this reliable solution for redundancy and failover. While it's stable, I find its licensing complex and expensive, particularly for hyper-converged. Microsoft's remote support also needs improvement due to language barriers and a lack of local presence. |
| Consultant at Unisys Corporation | 4.5 | I find this solution essential for server availability, offering geo-redundancy and improved business continuity. It's stable, though standard support could improve. Setup is straightforward, and the technology has evolved impressively over my twenty years of use. |
| Technical Specialist at a comms service provider with 10,001+ employees | 4.5 | I've found it stable, scalable, and highly available, with useful features. My main concern is the responsiveness of technical support. |
We use the most basic features of the product.
We use the operation system itself. We also use it for virtualization and failover. The product is stable.
The product should be less dependent on network configuration. Our technicians usually require other tools along with Failover Clustering. It makes our network implementation more expensive.
I have been using the solution for two to three years.
I rate the solution’s stability a nine out of ten.
I rate the tool’s scalability an eight out of ten. In our organization, at least 15 different systems have the product. Around eight people use the solution.
I rate the ease of setup an eight out of ten.
The deployment takes two to three weeks. We needed two technicians to deploy the solution.
I rate the pricing a two out of ten.
We have considered other options. Eventually, we needed something standard off the shelf.
We are using the latest version of the solution. The buyers of the product must pay attention to the watchdog hardware. Overall, I rate the product a nine out of ten.
Windows Server Failover Clustering is mainly used for what the name is, meaning that you can create a cluster, bunch, for example, a bunch of servers that are identical and perform the same way, one like the other, to handle the same task or connection or request. And it allows you to create a virtual unit that contains multiple identical units. For example, if you want to use virtualization with Hyper-V and you want to deploy, five notes or five servers each one of them hosts the Hyper-V service for virtualization, and you want a virtual machine to run on every node of the cluster, then you will need to deploy or to use Windows Server Failover Clustering that you will create a virtual unit from, or that is based on physical units. This is for servers. And also you can create clusters of applications. For example, if you want to use a cluster of IAS services, you need to also use the Windows Server Failover Clustering. For example, to have a cluster of my MySQL database, you also need to use this service. If you want to use or deploy storage or file server servers, a cluster of file servers, you also need this service, meaning that each time you want to use high availability and failover Clustering, you need to deploy Windows Server Failover Clustering.
The solution has many good features. Some of the advantages, are it can give you the ability to choose... To just explain something. When you have a bunch of servers, for example, that are part of cluster configuration, each server will perform identically like the others. In this type of configuration, you need to elect one master that will handle directly the request. Meaning that all the other servers will not handle anything but they will stay in a listening mode or like a slave. And they will communicate each time they will do a hard bit on the master to see if it's still running or accessible. If they detect that the master is not responding, then they will elect another master that will handle the communications. So this feature is done automatically within the server, this service, meaning Failover Cluster service. And also you can choose which one you want to elect as a master. You can do that manually and you also can do it automatically and you can configure it so that you can have a preferred one. Meaning that each time there is a revolt of the servers or revolt of this cluster, they will communicate with them. And depending on the preferred one, this one will be chosen as the master instead of doing an election within the server.
The solution has some downsides related to the election mechanism, meaning that if the servers or the cluster services or cluster server elect one server, they will attribute to that server an object that is called a quorum. This quorum does the server or the service that has that quorum, it is taken as the master. So when you have, for example, something happens in your data centers like a power outage or an unexpected shutdown, and you can't start the master server what sometimes will happen, is since the shutdown was unexpected, the cluster didn't have time to do some post configurations before the extension of the shutdown of the servers, sometimes that quorum can't be removed from the crashed master and the cluster wants stuff. This is part of the architecture of this service, the Failover service. So sometimes we face this type of problem. In the past, we had a lot of power outages and when we started after, our server, we faced this problem. Meaning that the cluster won't stop because one of the servers, the master crashed, and they didn't want to start. So we need to access and do some line configurations so that we will force the cluster to elect a new master and ignore the crashed one.
I have been using the solution for seven years.
The stability is good, except for when something crashes or shuts down unexpectedly, then it can be a bit difficult to reestablish the service in a stable state. You need to do a lot of work.
The solution is scalable. If you want to create a cluster of servers, you need to install and deploy the Windows Server Failover Clustering service in each one of them. When you join one server to a cluster, it'll be a switch forward for the other server to join the cluster. You only need to configure the new servers you want to add to your cluster.
The technical support is great. It depends if the incident is critical or minor.
Since we have a contract with Microsoft, we are mainly using their products. I think it's the only product that is available on the Windows server. It's better to use it rather than another clustering service.
The initial setup is straightforward. It's easy to deploy the service, to activate the service. Once you understand how it works, it'll be easy to configure any type of service that you want to create a cluster from. Some scenarios require a lot of work in order to create a cluster with assistance from Microsoft, meaning software or installation or configuration assistant, which makes things easy. Sometimes you need some steps that are not well explained. Meaning that sometimes you need to check or uncheck some option boxes, and you need to know what will happen if you check or uncheck these options and this type of misconfiguration or lack of documentation in the configuration process. Sometimes you lose all your data. This is just a technical thing, you will get it easily. This solution was designed first to create a file server for storage, to store files. So when you want to create a cluster and you need to choose or assign the servers you want to join or create clusters from them, you choose server one, server two, and server three. These three servers will be a part of the cluster. In one step, there is a check box. If you leave it checked, it will take all the disc space available on the servers and format direct. Meaning that if there is something that is hosted on these servers, they will be wiped out. Why? Because by default it'll configure these servers like file servers. It is important to know that if you have databases on these servers, everything will be lost. And this step is not well explained in the configuration process in the assistant. If you want to create a cluster, you need to start with freshly installed servers and not existing ones. The setup process is a bit confusing and on some steps, there is not much information about the next steps, and what will happen. Sometimes, normally and logically, you don't need to execute anything unless you click on the Finish button, not the Next button. With the configuration assistance of this solution, some action will be applied when you click on Next, even if it's not the last step.
The deployment is completed in-house by either myself or my colleagues.
It's like IAF, it's a part of the Windows server license. So if you acquire the Windows server license, you will also get all of the Windows services licenses. It's not a product that you can download and install. It is the feature that you activate in the Windows server.
I give the solution an eight out of ten.
The solution is like IAS, the version depends on the version of the window server. So it's part of the server. So you don't use or specify the version except with which Windows server you are using.
The solution has some downside frankly, that it needs a lot of configuration and steps in order to create your cluster. This means that deploying this service is not that hard. It is easier than IAS, but if you want to configure the cluster service to create a cluster of an application, then it'll depend on the application you want to create a cluster with. But once it is done, it'll perform very well.
Sometimes you have to manually assign a master, especially when there is an unexpected shutdown caused by another problem. Sometimes you will face these types of problems. You need to manually assign a master. If you reboot the servers one by one, you don't need to reboot them at the same time. When you reboot them one by one, for example, if you reboot the master, before the master restart, it will communicate and handle the quorum to another one. It's like, "Okay, I'm not the master anymore. Choose another master that will handle the communications and requests." And when it starts, it will no longer be the new master. It will be another slave that will wait for the master to fail so they will also do an election to set the new master and give it to the quorum.
The deployment time depends on what you want to create on the cluster. Meaning if it's a Microsoft SQL server, it needs a lot of steps or a lot of configuration because you need to create a cluster, you need to create the listener because you have a bunch of servers. Meaning you have a lot of IP addresses that the master will need since the master can change. As an example, for server one that has an IP address, one is master, it will handle the communications, but once it fails there will be another master with another IP address. We don't each time teach the IP address to communicate with the cluster and that's why the Failover service will create a visual IP address that is called a listener so that it will communicate with the clients and other applications and it will handle the back of it. This means if something fails, the switching from one master to another, will be transparent to users. Since you are communicating with the virtual IP risk address, that will not change. Behind this listener, a lot of things can happen. Master fails, unless the new master changes IP addresses, et cetera. So it'll be transparent for the users. These configurations can take time depending on the application, the architecture, or the scenario you want to use this service with. If it's servers, it'll take some time. It depends on how many servers you want to create, and what type of cluster you want to create with the service or database, file system, servers, et cetera. So it can take time but not many days. You can do it within the day to have your clustered application or servers fully working.
The solution requires two System administrators to maintain.
I suggest if you want to use the product, start with a freshly installed server. Meaning that the server doesn't need to host any data from the start. Once it is configured you can put your data onto the server. Otherwise, you need to be careful in the cluster configuration process, because once you add your servers at one step, I don't recall, when you click on Next, it will configure the cluster as file servers. Meaning that it will take all remaining storage capacity on each server and create the pool of storage with the capacity of some of these remaining stores. There is a checkbox. I don't remember if you need to check it or uncheck it. Either way, you need to do the contrary of what you found. If it's checked, you need to uncheck it. If it's unchecked, you need to check. I don't recall at which step you will find it, but you need to be careful and you need to read about the service before starting to create one. And also you need to read each document so that you will know what are all the requirements to create a cluster.
The most valuable features of Windows Server Failover Clustering are the ISS, failover cluster, and DC.
There are times when we do the system security updates and have to restart the server which is difficult because we need to wait until the end of the day or when working hours are finished. There are service updates that have a requirement to restart the system and it is not convenient.
In a feature release, there should be a feature to allow applications to be developed on the web portal and better databases that we can run.
I have been using Windows Server Failover Clustering for approximately seven years.
The solution's stability has been great.
Windows Server Failover Clustering is a scalable solution.
We have approximately 100 users using this solution in my organization. Some of their roles are IT integration manager, system administrator, and security teams.
I have never used the support. However, one of my colleagues has and their experience was good.
The initial setup was easy for our first configuration but our second configuration made it more complex.
We are on an annual license to use this solution.
We are currently looking for another solution because, in many industries, such as eCommerce, they operate 24 hours a day seven days a week and this solution has some downtime which our customers do not like.
I would recommend this solution to others, we have used it for a long time and it has been reliable.
I rate Windows Server Failover Clustering an eight out of ten.
We use the solution for warehouse purposes. We built an SQL server on the solution.
The solution has a hot-swap feature. If one of the servers fails, we’ll still have a running system. It takes a few seconds to swap to the other server. The system has no interruption and is highly available.
The solution uses external storage, while third-party solutions don't use external storage. They're using a mirror to create a partition on each server and synchronize the data in the background. It's not easy to set up or monitor its status.
I have been using Windows Server Failover Clustering as a partner for five years. We are using the latest version of the solution.
I rate the solution’s stability a seven out of ten.
More than 100 users are using the solution. We cater the solution to medium to large businesses.
I rate the solution’s scalability a six out of ten.
Technical support is fine.
Positive
The initial setup takes a few hours and needs some knowledge to complete. You had to prepare hardware, do the prerequisites on the operation system, and install it.
I rate the initial setup a five out of ten, where one is difficult, and ten is easy.
There is no extra charge except a service fee for some professional work.
I rate the product’s pricing a five out of ten, where one is cheap, and ten is expensive.
If you have a budget, keeping the solution for data safety is better.
Overall, I rate the solution a seven out of ten.
The solution switches over to another server in case the server goes down.
The tool's pricing is high.
I would rate the tool's stability a nine out of ten.
I would rate Windows Server Failover Clustering's scalability a nine out of ten. We use the solution three to four days a month.
I would rate Windows Server Failover Clustering's setup an eight out of ten. The whole deployment takes 10-20 minutes to complete. You need to monitor the solution and do a backup as part of its maintenance. This can be done by one person.
We did the tool's deployment in-house.
I would rate the solution's pricing an eight out of ten.
I would rate the product an eight out of ten.
We primarily use the solution for redundancy, our virtual machines, and for automatic failover.
The failover is the solution's most valuable aspect.
The reliability is pretty good.
The Dell side of the technical support that is on offer is quite good.
The solution can scale.
The solution, especially the latest version, has pretty good stability.
The solution has failed me maybe twice since I've had it over the course of ten years. The failure was a long time ago, however, and it happened on a different version. RIght now, the current version seems to work properly.
I'd like to see the reliability continue to improve. I don't ever want the solution to go down on me. It's too important.
They could drop the price or improve the cost of the hyper-converged component of it all. Right now, licensing is expensive and complex.
I've been using the solution for about 10 years now. It's been a decade or so. It's been a long time.
I would say the solution is very stable. It's working for me. I don't experience bugs or glitches on this version. It hasn't failed. It's reliable.
The scalability of the solution is good. If an organization needs to scale up, it shouldn't have any issue doing so.
Technical support comes from two sources: from Microsoft and also through Dell. I would say Dell probably supports it better, however, usually, you have to get their pro support to access that level of service.
Microsoft's support always seems to be from a foreign source. In my opinion, it seems to be lacking. Occasionally, due to the accents, there is a bit of a language barrier. The support can be difficult to understand. I'd prefer it if I knew that the support was more local and that those assisting me were in my time zone or within my region.
The initial setup is very straightforward. It's not complex.
The licensing is kind of convoluted. We have to pay licensing costs twice. Once because we're a software as a service (SaaS) company where people access our servers. I have to get the service provider license purchased. I purchased that from Dell, but it's a Microsoft license subscription and it's about $150 a month.
The second licensing we have to worry about is surrounding our other licenses as a Microsoft partner, which is actually mostly free for us. That's not bad, however, that's only because we're a Microsoft partner. Otherwise, for our internal business servers, we'd have to purchase another license. The clustering itself is free with Windows.
Therefore, if I buy the Windows licenses it has it on the VMware. However, if I buy that license and a licensed server, then the license comes with a server as far as the clustering. It's confusing.
On top of that, if we wanted to go with the Microsoft hyper-converged environment, then our costs go through the roof. It just gets crazy expensive due to the fact that the data center version is so expensive and that's their hyper-converged solution. A hyper-converged solution comes with the Windows Server, however, it's a set data center version, so the price escalates quickly.
We're a Microsoft silver partner. We're on Windows Server 2016.
I would warn potential new users that they need to pay attention to the licensing due to the fact that it's complex, and, depending on what you need, can get expensive. The newer stuff seems to be more reliable than the older systems. I'm not using it yet, but I'd advise new users to get Windows 2019.
Overall, I'd rate the solution seven out of ten.
Business continuity is much better, due to the possibility of patching/upgrading systems without interruption of services.
The most valuable feature is the ability to easily create clusters supporting geo-redundancy.
The standard, non-enterprise technical support could be improved.
I have been using this solution for twenty years.
It is a majored solution. If it is setup correctly, it runs problem free. Most of the issues we had were due to wrong administration tasks.
Failover clustering can scale up and scale-out, depending on the exact solution. In a typical use case, which is a two-node RDBMS with shared disks, the scalability of each node (CPU, RAM) and the used storage system sets the limit.
As it is a majored Microsoft product, there is MS support and many third-party sources. MS support is much better if you have an enterprise support agreement, which is not free.
Before Windows Failover Clustering, Digital Equipment VMS Clusters did the same job. The platform died (also because it was quite expensive), the developers changed to Microsoft and released a failover clustering solution along with Windows NT 4.0, which would run on X86 servers.
Setup is straightforward. It is worth to plan it according to the product documentation. We do all installations in an automated way to gain reproducibility and speed up disaster recovery, which adds some complexity.
Traditionally, we setup failover-clustering solutions using an in-house team.
Failover clustering serves the goal of high availability. High availability is a nonfunctional requirement for many systems, but it is difficult to transform its benefits into ROI. HA is a kind of insurance: It pays only if you have an incident. The shorter the downtime, the lesser the loss of productivity.
Unlike twenty years ago, the setup of a failover cluster is a straightforward process which can be automated easily. The functionality is included in Windows Server licences.
We looked at some third-party solutions, which are no longer of importance today. Some of them had better features at the time, but we decided to go with the MS solution to not be hooked in version upgrading problems.
As MSCS was improved with every new version of Windows Server, we never regretted that decision. Some of the RDBMS systems we deployed twenty years back are still running, albeit with new hardware and the latest software of course, but the entities remained the same.
I am happy with the current features.
The technology has evolved impressively. With Windows 2019, it is possible, to “failover cluster” both on-premises and cloud resources.
The most valuable features for us are:
It's scalable, highly available, and is agile to handle workloads.
Technical support isn't as responsive as I'd like.
I've used it for two years.
I haven't encountered any deployment issues.
It's been stable for us.
It scales without issue.
4.5/5
Technical Support:4/5