By Andy Syrewicze and Richard Siddaway

In this article, we’ll also introduce you to Microsoft failover clustering. We’ll then explain the requirements for creating clustering with Hyper-V hosts.

Save 37% off Learn Hyper-V in a Month of Lunches with code learnhyperv.

 

 

Modern hardware – servers and storage – is extremely reliable. Yet, if you only have a single server, when it fails you’ve lost your virtual environment. More importantly, your users will have lost access to their applications and your organization could be losing revenue. Down time, due to rebooting a virtual host and its VMs (because of operating system patching), might also be unacceptable to your organization.

The answer is to configure the systems for high availability (HA). This involves configuring two, or more, machines to work together, so that if one fails the workload is automatically migrated to another machine in the group. In this article, we’re looking at configuring Hyper-V hosts (physical machines in your environment) to work together to provide a HA environment for your virtual machines.

The Microsoft Failover Cluster Service (MFCS) provides high availability in a Windows environment. A group of machines (known as a cluster) is configured and managed together using MFCS. Each machine in the cluster runs Hyper-V, and workloads – in this case virtual machines – can be moved between members (also referred to as nodes) of the cluster.

Note You can’t use Network Load Balancing (NLB) clusters to provide HA to Hyper-V machines.


Introducing Microsoft failover clustering

A cluster is two (or more) machines that work together to provide high availability to a workload. In this article, we’ll concentrate on clustering Hyper-V hosts, though other workloads can also be clustered – https://technet.microsoft.com/en-us/library/hh831579(v=ws.11).aspx.

 

 

Active Directory integration for clusters

Microsoft failover clustering depends on Active Directory (AD). The cluster nodes need to be members of an Active Directory domain, and the user creating the cluster needs permissions to create computer objects in AD. A number of AD objects are created during cluster creation. Communication between cluster nodes requires AD authentication.

With Windows Server 2012 R2 (and later) it’s possible to create a Hyper-V cluster outside of AD (an Active Directory detached cluster). This isn’t recommended for Hyper-V clusters, as moving active virtual machines between nodes (Live Migration) won’t work because it requires AD authentication.

More details on failover clustering and Active Directory are available at –

https://blogs.technet.microsoft.com/supportingwindows/2014/03/24/failover-clustering-and-active-directory-integration/

 

 

What does a cluster look like?

 

Figure 1 shows the major features of a Windows cluster. The cluster has two machines (known as nodes). A Windows cluster can contain up to 64 nodes (Windows Server 2012 (R2) and Windows Server 2016). The nodes can be split between different physical sites if required. A Hyper-V cluster can support up to 8000 virtual machines, with a maximum of 1024 on any one node.

Both machines are connected to the external network – this is used by users to access the workloads supported by the cluster. The heartbeat (or internal) network is used by the cluster members to communicate amongst themselves to confirm that nodes are still available to the network.


Figure 1 An outline of a Windows two node cluster. The heartbeat network is for communication between cluster nodes. The external network is for communication to the workloads on the cluster.


The nodes in the cluster have two types of storage. First, each node has one (or more) disks to support the operating system. Second, there’s the cluster storage, which is available to all nodes – this is shown as the external storage in figure 1. External storage is often used to store the cluster quorum.

Cluster Quorum

Numerous cluster-based operations are based on a quorum model. This model means that most of the cluster must agree that a given action can occur. Actions that’re controlled by the quorum include:

  • cluster start-up;
  • workload placement;
  • workload failover between nodes.

Each node in the cluster gets a single vote towards the quorum, but many clusters only contain two nodes. In such a case, a “witness” is needed to provide an odd number of total votes, meaning that a quorum can be established. The witness can be:

  • Disk – a specific volume is designated as the witness. The witness disk must be on external storage and can be small (512MB minimum) – 1GB is more than sufficient. This is most useful for clusters with non-replicated storage. Most clusters use a quorum disk.
  • File share – an SMB share (5MB minimum free space). The file server should be on a different site than the cluster nodes. The cluster information is held in a witness.log file, rather than a copy of the cluster database. This is most suitable for multisite clusters with storage replication.
  • Cloud –Azure Blob (Binary Large Object) storage is used to host a read/write file that acts as the witness. Only available in Windows Server 2016, and later. This option is best suited to multisite clusters.

 

Above and Beyond

More information on the witness and workings of the cluster quorum can be found at – https://technet.microsoft.com/en-us/library/jj612870(v=ws.11).aspx.

The use of a cloud-based witness for Windows Server 2016 based clusters is described here – https://technet.microsoft.com/en-us/windows-server-docs/compute/failover-clustering/deploy-a-cloud-witness-for-a-failover-cluster

 

 

If you have an odd number of nodes in the cluster, you can configure the cluster to work on a node majority basis. In this case, only the cluster nodes have a vote in the quorum and a witness isn’t required.

Cluster storage

Each node in the cluster requires dedicated storage for its operating system. In addition, the nodes need access to external storage that supports the workloads hosted on the cluster. Many options are available for cluster storage:

  • iSCSI – connect to storage over network. Storage is usually a Storage Area Network (SAN) or Network Attached Storage (NAS);
  • Fiber Channel attached storage – usually a SAN;
  • Shared virtual disk (Hyper-V guest clusters only);
  • Cluster Shared Volumes (CSV) – enable multiple nodes to have read/write access to volume. This is a common configuration for clusters of Hyper-V hosts;
  • SMB 3.0 file shares.

The option you use will be based on other storage requirements in your organization. Fiber Channel or iSCSI connections to a SAN or NAS are common configurations for many enterprises.

 

Above and Beyond

More information on storage options for clusters can be found at – https://technet.microsoft.com/en-us/library/hh831579(v=ws.11).aspx

Windows Server 2016 clustering enhancements are described here – https://technet.microsoft.com/en-us/windows-server-docs/compute/failover-clustering/whats-new-failover-clustering-windows-server

 

 

 

Now that you have an understanding of the clustering basics, let’s look at specifically clustering Hyper-V.

Clustering Hyper-V hosts

Many administrators view clustering as very complicated, and as falling into the “too hard” category. There are complications, but it is actually rather straight forward.

Note When designing a cluster, think about the workloads you’ll be supporting. How many nodes do you need to support that number of virtual machines? Many organizations will design an extra node (called N+1 cluster) into the cluster to ensure that the cluster will function properly even with one node off-line, e.g. during patching.

 

Above and beyond

This article – https://technet.microsoft.com/library/jj612869 – discusses the hardware and storage requirements for clustering in great detail. It should be read before implementing a production cluster.

 

 

We’re going to make use of a new feature in Windows Server 2016 – nested virtualization – that enables us to create Hyper-V hosts on our Hyper-V host. This isn’t possible in earlier versions of Windows server and Hyper-V. If you can’t use Windows Server 2016 and nested virtualization, you’ll need two identical physical machines for cluster nodes. Windows Server 2012 (R2) Storage Server can be used as the iSCSI target.

Note Use the evaluation edition of Windows Server 2016 from https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview. Alternatively, you’ll have to use sufficient hardware to create the physical nodes for the cluster.

We will need three virtual machines as shown in table 1.

 

Table 1 Configuration details for virtual machines for our Hyper-V cluster

Virtual Machine Purpose Virtual CPU System Disk
W16HVC01 Hyper-V cluster node 2 80GB
W16HVC02 Hyper-V cluster node 2 80GB
W16IST01 iSCSI target (storage) 1 80GB

 

Each machine should have a single network adapter initially. Startup memory of 1024MB and enabled dynamic memory can be used to create the machines, though we’ll need to modify those settings for the cluster nodes later.

 

Try It Now

Create the virtual machines as shown in table 1. Configure each machine with a static IP address and join them to your domain.

 

 

Using iSCSI introduces additional networking issues, so the next step would be to work though those.


Networking for Hyper-V clusters

You are going to need at least three (ideally four) networks for your cluster nodes as shown in table 2.

 

Table 2 Networks used by the cluster nodes

Network Purpose
LAN General network connectivity for users to access virtual machines
Heartbeat Private communication between cluster nodes
STG Connectivity to storage
MGMT Management network. Used by administrators.

 

The management network is not often utilized, so we won’t install that one for now. The idea behind using different networks is to segregate network traffic. You can run all cluster traffic (public, private, and management) over a single network. It all depends on your server configuration. If you have 2 (or more) 10Gb NICs in your servers you can team them up and run all traffic over the team. If, on the other hand, you have 1Gb NICs in your servers you’ll need to segregate the traffic. When in doubt, segregate the cluster traffic from the workload traffic.

 

The best practice is to separate the traffic as shown in table 2. You should create additional virtual switches to facilitate the network traffic separation if you are creating your cluster on a Hyper-V host.

NOTE If you are creating the Hyper-V cluster with physical machines you should create
virtual networks (VLANs) to perform the traffic segregation. Have a talk with your network team about this.

To create a virtual switch for the storage network:

 
New-VMSwitch -Name Storage -SwitchType Internal
  

 

An internal switch enables network connectivity between the host and the virtual machines, as well as between virtual hosts. No traffic is sent outside of the Hyper-V host. The heartbeat traffic is purely between virtual machines, so you could utilize a private virtual switch:

 
New-VMSwitch -Name Heartbeat -SwitchType Private

 

Try it now

Create the virtual switches on your Hyper-V host to support the cluster. You should create switches for at least the heartbeat and storage networks.

 

 

Once you have the three machines created and the network configuration work done, you’re ready to configure the cluster itself – and that’s where we will stop for now.

 

For more on cluster configuration and other Hyper-V networking issues, download the first chapter of Learn Hyper-V in a Month of Lunches and see this Slideshare presentation. Don’t forget to save 37% with code learnhyperv.