Windows Server 2016 features workgroup cluster support. In Part 4, I’ll give an overview of putting the actual cluster together. If you’ve never build a Windows cluster, the most important thing is ensuring you keep all nodes in lock-step with each other, so pay close attention and be consistent.
Hyper-V Core 2016: Workgroup Cluster Series
These are general best practices when building any cluster, so be sure you run down these items, or you’re going to fail cluster validation.
- Windows Updates – make sure your nodes are patched up with the SAME patches
- Windows Updates – make sure you’ve got ALL the updates. Patch, then patch again.
- Drivers – make sure you’ve installed any required hardware drivers on BOTH nodes. I had some Intel chipset drivers from Dell I was able to install (despite being a Core install, some apps can still throw up GUIs to step you through their installations)
- BIOS and firmware – double check that all nodes are running the same BIOS revision; you may have procured lab gear at different times, take this opportunity to give them a little TLC and bring them up-to-date
Setting Up Network & Storage
My setup leveraged the multiple NICs present in my host to create a NIC Team within Windows, which was then passed to a Windows Virtual Switch, which had VLANs carved out, IP addresses set, and QoS-type “minimum bandwidth” guarantees set. These need to be established on each node.
Additionally, you should enable the iSCSI service and enable MPIO (Multi-Pathing).
Finally, you need to connect to your LUNs for Cluster Quorum and VM Storage via iSCSI.
For these steps, there’s a ton of Powershell you can use. I’m going to hand you off to this post by TechThoughts, this guy did great work on the Powershell and documentation. Just complete Step 6, 7, 9, 10, 12, and 13 (don’t perform 12 and 13 until after creating the cluster using my steps below).
Installing the Cluster Role
- This one is easy. From the Command Prompt window of BOTH NODES, type ‘powershell’ then:
Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools
- Depending on the Powershell output, a reboot may not be required, but we just added a big feature, so I reboot anyway
Create the Cluster
Here’s the meat of what we’re doing. Check out the parameters we’re defining in the new-cluster command below. Observe –AdministrativeAccessPoint DNS. This is a key difference of a Workgroup cluster, instead of being created in Active Directory. This is why we created a DNS suffix, and HOSTfiled until we lost track of time.
- First, test your cluster to make sure everything checks out and your nodes are accessible.
test-cluster -node "HYPERV1.fugelnet.local","HYPERV2.fugelnet.local"
- At this stage, I first was receiving an error because I wasn’t using my fake FQDN, just node names. This article pointed me in the right direction, suggesting the DNS-Suffix might infact be required for this command to work.
- Pull out that CLUSTER NAME and IP I mentioned earlier, which you’ve been including in your WSMAN and HOSTS entries, and create the cluster with this command:
new-cluster -name HyperVCluster -node "HYPERV1.fugelnet.local","HYPERV2.fugelnet.local" -AdministrativeAccessPoint DNS -staticAddress 192.168.1.11
- At this stage, you should be able to run get-cluster and get-clusterresource and see your cluster components. Start-cluster should bring everything online.
Connect to the Cluster
- On your management computer, open Failover Cluster Manager, which was installed as part of the RSAT package.
- Select “Connect to cluster”. You might have to play with this. If you can’t connect by the fully qualified cluster name, try the name of each node individually. If you can’t connect, you might need to fix TRUSTEDHOSTS (this is when I needed to replace my explicit entries with ” * ” to get connecting).
- Once you’re connected, explore the Networks, Storage, and Nodes sections and make sure everything is healthy and online.
- Configure your Quorum disk.
At this point, you should have a fully functional Hyper-V Core 2016 cluster with Quick Migration capability built atop a Windows Workgroup, with no dependency on Active Directory. To configure Hyper-V Settings, connect to each node individually using Hyper-V Manager. Then use Failover Cluster Manager’s Roles menu to create new Virtual Machines inside the cluster.
As expected, Live Migration doesn’t work. I get a failure message that complains something about authentication. Otherwise it’s a mostly-functional virtualization cluster running off a home network, awesome!
As I said up front, use cases for this might be questionable, but clearly there are enough people asking for this, for Microsoft to roll it into 2016.
This cluster setup does support Cloud Witness as a quorum master, so there’s some more cool toys to play with. (Microsoft says it costs pennies a year to run).