Windows Server 2019 – Setting up a failover cluster

How to configure nginx for wordpress

We are going to take a few minutes to set up a small cluster of servers, so that you can see the management tools and the places that have to be touched in order to accomplish this. I have now backed out all of the NLB config on my WEB1 and WEB2 servers that we set up earlier, so that they are just simple web servers at the moment, once again with no redundancy between them. Let’s set up our first failover cluster and add both of these servers into that cluster.

Building the servers

We have two servers already running with Windows Server 2019 installed. Nothing special has been configured on these servers, but I have added the File Server role to both of them, because eventually I will utilize these as a cluster of file servers. The key point here is that you should have the servers as identical as possible, with the roles already installed that you intend to make use of within the cluster.

One other note during the building phase: if possible, it is a best practice with clustering that member servers belonging to the same cluster reside within the same organizational unit (OU) in Active Directory (AD). The reason for this is twofold: first, it ensures that the same GPOs are being applied to the set of servers, in an effort to make their configurations as identical as possible.

Second, during cluster creation, some new objects will be auto-generated and created in AD, and when the member servers reside in the same OU, these new objects will be created in that OU as well. It is very common with a running cluster to see all of the relevant objects in AD be part of the same OU, and for that OU to be dedicated to this cluster:

Installing the feature

Now that our servers are online and running, we want to install the clustering capabilities on each of them. Failover Clustering is a feature inside Windows Server, so open up the Add roles and features wizard and add it to all of your cluster nodes:

Running the failover cluster manager

As is the case with most roles or features that can be installed on Windows Server 2019, once implemented, you will find a management console for it inside the Tools menu of Server Manager. If I look inside there on WEB1 now, I can see that a new listing for Failover Cluster Manager is available for me to click on. I am going to open that tool, and start working on the configuration of my first cluster from this management interface:

Running cluster validation

Now that we are inside Failover Cluster Manager, you will notice a list of tasks available to launch under the Management section of the console, near the middle of your screen:

Before we can configure the cluster itself or add any server nodes to it, we must first validate our hardware configuration. Failover clustering is a pretty complex set of technologies, and there are many places where misconfigurations or inconsistencies could set the whole cluster askew. Your intentions behind setting up a cluster are obviously for reliable redundancy, but even a simple mistake in the configuration of your member servers could cause problems large enough that a node failure would not result in automated recovery, which defeats the purpose of the cluster in the first place. In order to make sure that all of our T’s are crossed and I’s dotted, there are some comprehensive validation checks built into Failover Cluster Manager, sort of like a built-in best practices analyzer. These checks can be run at any time  before the cluster is built or after it has been running in production for years. In fact, if you ever have to open a support case with Microsoft, it is likely that the first thing they will ask you to do is run the Validate Configuration tools and allow them to look over the output.

In order to start the validation process, click on the  Validate Configuration… link. We are now launched into a wizard that allows us to select which pieces of the cluster technology we would like to validate. Once again, we must put on our Microsoft centralized management theology thinking caps, and realize that this wizard doesn’t know or care that it is running on one of the member servers that I intend to be part of the cluster. We must identify each of the server nodes that we want to scan for validation checks, so in my case I am going to tell it that I want to validate the WEB1 and WEB2 servers:

The Testing Options screen allows you to choose the Run only tests I select radio button and you will then be able to run only particular validation tests. Generally, when setting up a new cluster, you want to run all of the tests so that you can ensure everything measures up correctly. On a production system, however, you may choose to limit the number of tests that run. This is particularly true with respect to tests against Storage, as those can actually take the cluster offline temporarily while the tests are being run, and you wouldn’t want to interfere with your online production services if you are not working within a planned maintenance window:

Since I am setting up a brand new cluster, I am going to let all of the tests run. So I will leave the recommended option selected for Run all tests (recommended), and continue:

Once the tests have completed, you will see a summary output of their results. You can click on the View Report… button in order to see a lot of detail on everything that was run. Keep in mind that there are three tiers of pass/fail. Green is good and red is bad, but yellow is more like it’ll work, but you’re not running best practices. For example, I only have one NIC in each of my servers; the wizard recognizes that, for my setup to be truly redundant in all aspects, I should have at least two. It’ll let this slide and continue to work, but it is warning me that I could make this cluster even better by adding a second NIC to each of my nodes.

If you ever need to re-open this report, or grab a copy of it off the server for safekeeping, it is located on the server where you ran the tests, in C:\Windows\Cluster\Reports:

Remember, you can rerun the validation processes at any time to test your configuration using the Validate Configuration… task inside Failover Cluster Manager.

Running the Create Cluster wizard

The validation phase might take a while if you have multiple results that need fixing before you can proceed. But once your validation check comes back clean, you are ready to build out the cluster. For this, click on the next action that we have available in our Failover Cluster Manager console: Create Cluster….

Once again, we must first specify which servers we want to be part of this new cluster, so I am going to input my WEB1 and WEB2 servers. After this, we don’t have a whole lot of information to input about setting up the cluster, but one very key piece of information comes in the Access Point for Administering the Cluster screen. This is where you identify the unique name that will be used by the cluster, and shared among the member servers. This is known as a Cluster Name Object (CNO), and after completing your cluster configuration, you will see this name show up as an object inside AD:

After finishing the wizard, you can see the new cluster inside the Failover Cluster Manager interface, and are able to drill down into more particular functions within that cluster. There are additional actions for things, such as Configure Role…, which will be important for setting up the actual function that this cluster is going to perform, and Add Node…, which is your spot to include even more member servers into this cluster down the road:

Comments are closed.