Windows Server 2019 – Failover clustering

How to find files and file listing on ubuntu

We have established that NLB is a great solution for stateless applications, with a prime example being websites that you want to make highly available. What about other server roles or functions that you want to make redundant? Well, the opposite of stateless is stateful, so how about giving high availability to stateful pieces of technology?

Failover clustering provides this level of capability, and can be used in cases where the nodes within the cluster are accessing shared data. This is a key factor in the way failover clustering is designed, the storage used by the cluster nodes must be shared and accessible by each node that needs it. There are many different roles and services that can take advantage of failover clustering, but there are four specific technologies that seem to make up the majority of clusters running in data centers today: Hyper-V, file services, Exchange, and SQL. If you are working with any of these technologies  and chances are that you work with all of them  you need to look into the high-availability capabilities that can be provided for your infrastructure by use of failover clustering.

While failover clustering provided by Windows Server is Microsoft-built and has the capacity to work very well out of the box with many Microsoft roles and services, it is important to note that you can establish failover clustering for non-Microsoft applications as well. Third-party applications that run on Windows Servers in your environment, or even homegrown applications that have been built in-house, can also take advantage of failover clustering. As long as that application uses shared storage and you can specify the tasks that it needs to be able to perform against those applications for the clustering administration tools  how to start the service, how to stop the service, how to monitor the service health, and so on  you can interface these custom services and applications with failover clustering and provide some major redundancy for just about any type of application.

Clustering Hyper-V hosts

One of the most powerful examples of failover clustering is displayed when combining clustering with Hyper-V. It is possible to build out two or more Hyper-V servers, cluster them together, and give them the capability to each host all of the virtual machines that are stored in that virtual environment. By giving all of the Hyper-V host servers access to the same shared storage where the virtual hard disks are stored, and configuring failover clustering between the nodes, you can create an incredibly powerful and redundant virtualization solution for your company. When a Hyper-V server goes down, the VMs that were running on that Hyper-V host will fail over to another Hyper-V host server and spin themselves up there instead.

After minimal service interruption while the VMs spin up, everything is back online automatically, without any administrative input. Even better, how about when you need to patch or otherwise take a Hyper-V host server offline for maintenance? You can easily force the VMs to run on a different member server in the cluster; they are live-migrated over to that server so there is zero downtime, and then you are free to remove the node for maintenance and finish working on it before reintroducing it to the cluster. We use virtual machines and servers for all kinds of workloads, so wouldn’t it be great if you could get rid of any single points of failure within that virtualization environment? That is exactly what failover clustering can provide.

Virtual machine load balancing

In fact, not only does a Hyper-V cluster have the ability to quickly self-recover in the event of a Hyper-V server node going offline, but we now have some smart load-balancing logic working along with these clustered services. If your Hyper-V cluster is becoming overloaded with virtual machines, it makes sense that you would add another node to that cluster, giving the cluster more capability and computing power. But once the node is added, how much work is involved in sliding some of the VMs over to this new cluster node?

None! As long as you have VM load-balancing enabled, the cluster’s weights will be evaluated automatically, and VM workloads will be live-migrated, without downtime, on the fly, in order to better distribute the work among all cluster nodes, including the new server. VM load-balancing can be run and evaluated on demand, whenever you deem fit, or can be configured to run automatically, taking a look at the environment every 30 minutes, automatically deciding whether any workloads should be moved around.

Clustering for file services

Clustering for file servers has been available for quite a while; this was one of the original intentions behind the release of clustering. Originally, file-server clustering was only useful for document and traditional file utilization, in other words, when knowledge-worker types of users need to access files and folders on a daily basis, and you want those files to be highly available. To this day, this general-purpose file-server clustering works in an active-passive scenario. When multiple file servers are clustered together for general-purpose file access, only one of those file-server nodes is active and presented to the users at a time. Only in the event of downtime on that node does the role gets flipped over to one of the other cluster members.

Scale-out file server

While general file-server clustering is great for ad hoc access of files and folders, it wasn’t comprehensive enough to handle files that were continuously open or being changed. A prime example of these files are virtual hard disk files used by Hyper-V virtual machines.

Obviously, there was a need for virtual hard disk files to be redundant; losing these files would be detrimental to our businesses. Thankfully, hosting application-data workloads such as this is exactly what Scale-Out File Server (SOFS) was designed to do. If you plan to host virtual machines using Hyper-V, you will definitely want to check out the failover clustering capabilities that are available to use with Hyper-V services. Furthermore, if you intend to use clustered Hyper-V hosts, you should check out SOFS as an infrastructure technology to support that highly-available Hyper-V environment. SOFS helps support failover clustering by providing file servers with the capability to have multiple nodes online (active-active) that remain persistent between each other constantly. This way, if one storage server goes down, the others are immediately available to pick up the slack, without a cutover process that involves downtime. This is important when looking at the difference between storing static data, such as documents, and storing virtual hard disk files being accessed by VMs. The VMs are able to stay online during a file-server outage with SOFS, which is pretty incredible!

Comments are closed.