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:
But we’re not going the GUI way, right? 😊 It can be added via PowerShell as well:
Install-WindowsFeature -Name-Failover-Clustering
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.
Finally, we can create a shared storage between two servers. Let’s use VSAN from StarWind, 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”.
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.
Using the iSCSI initiator, we discovered the iSCSI IP addresses and connected the targets.
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.
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.
