Share on Facebook0Share on Google+0Share on LinkedIn0Share on Reddit9Tweet about this on Twitter0

Looking back at the previous articles in our “How-to-Core basics”, we have managed to install the Core version of Windows Server 2016. As well, the required networks were set, and the storage for the virtual machines was created.

In the final part of the trilogy, I’ll cover the steps left to prepare the environment in order to make your production highly available and fault-tolerant.

Being short, last time, we were up to installing Windows Server Core version on a single server and adding the storage as an iSCSI target. Highly available and fault-tolerant storage requires another server to create the failover cluster. There’s not much difference between the required configuration and the steps we did previously.

Considering that the final solution must be redundant, you will need to use the local storage of both nodes and make the same steps we did to partition and initialize the storage, excluding the part of connecting the storage via iSCSI protocol.

One of the key aspects that will allow your production to migrate between the servers, is to place the data and virtual machines on a shared storage. For that purpose, we need to install Failover Clustering role on both servers and create a Cluster Shared Volume between them. This can be done in two ways.

The first one is to use Server Manager on your laptop, for example, and simply add both servers to the server list. The Failover Clustering role can be added with “Add Roles and Features” button located in Manage tab:

Adding the Failover Clustering role via Server Manager

The Failover Clustering feature

But we’re not going the GUI way, right? 😊 It can be added via PowerShell as well:

Install-WindowsFeature -Name-Failover-Clustering

Installing the Failover Clustering feature via PowerShell

Now, when we have the Failover Clustering role installed on both servers, it is recommended to join them into a domain. In order to do this, you will need a Domain Controller (DC) to be installed and configured. By the way, I’ve covered the general recommendations for creating a DC some time ago in one of my webinars, here it is: Useful tips for setting up Microsoft Active Directory Domain Controllers. In two words, you will need at least two DC set as virtual machines on the local storage of each server to achieve the DC redundancy. Setting one of them off-site will be even safer.

Another thing worth our attention is enabling Jumbo packets on the networks that will be used for the synchronization of data and iSCSI connections. You can do it using the next PowerShell command on each network:

Set-NetAdapterAdvancedProperty–Name“NAME”–RegistryKeyword“*JumboPacket”–Registryvalue9014

Where “NAME” must be the same as your networks are named.

Enabling Jumbo packets on networks

Finally, we can create a shared storage between two servers. Let’s use StarWind Virtual SAN, as a good option. I’m not going to describe the whole StarWind installation guide in here, so let’s stick with “as short, as it can be in this case”.

StarWind Virtual SAN eliminates any need for physical shared storage just by mirroring internal flash and storage resources between hypervisor servers. Furthermore, the solution can be run on the off-the-shelf hardware. Such design allows StarWind Virtual SAN to not only achieve high performance and efficient hardware utilization but also reduce operational and capital expenses.
Learn more about ➡ StarWind Virtual SAN.

After installing StarWind service on both servers, we need a laptop with StarWind Management Console installed on it. We created two devices, one of them will be used as a Quorum Witness drive in our Failover Cluster. Another one will be used as the Cluster Shared Volume for our production VMs. Both devices are replicated between the nodes.

Creating StarWind HA devices

Using the iSCSI initiator, we discovered the iSCSI IP addresses and connected the targets.

Connecting targets via iSCSI Initiator

With the commands listed in the first part (Windows Server 2016 Core configuration. Part 1) of this “trilogy”, we have managed to create partitions, initialize and format newly created devices. After that, we created a cluster with the functionality of Failover Cluster Manager, joined both nodes and added the storage device in the Failover Cluster Manager as a Cluster Shared Volume. Alongside, the Witness device was presented as a Quorum drive.

Adding StarWind HA device as Cluster Shared Volume

So, summarizing all that was written in this article and the previous parts of “How-to-Core basics”, we were successful in installing Microsoft Windows Server Core edition and adding all additional functionality that is required for creating a highly available and fault-tolerant shared storage.

Using the Core version of Windows Server helps you to decrease the overall license costs. Additionally, it will be a great choice for PowerShell gurus that don’t need that GUI in their servers.

 

Views All Time
9
Views Today
33
Appreciate how useful this article was to you?
No Ratings Yet
Loading...
Back to blog
The following two tabs change content below.
Alex Khorolets
Alex Khorolets
Starting as a hobbyist in virtualization and storage sphere, Alex works as a technical support engineer at StarWind. Has a broad knowledge in networking, storage technologies, and clustering.