Configuring a Hyper-V Cluster
Creating a Hyper-V cluster is essentially the same process as creating any cluster
running on Windows Server 2012 or above. You need to follow some general
guidelines:
Ensure that the nodes in the cluster are running the same hardware, especially for
the processor. If different generations of processor are used, it may be required to
configure the processor compatibility attribute on virtual machines to enable
migration between hosts without downtime.
Ensure access to shared storage to enable virtual machines to be stored on Cluster
Shared Volumes.
Network connectivity is required, such as for virtual machines and management
but also for cluster communications and Live Migration. I went over the network
requirements in detail in Chapter 3, but I review them in the next section. It is
important that all nodes in the cluster have connectivity to the same networks to
avoid loss of connectivity if VMs move between different servers.
Each node must be running the same version of Windows and should be at the
same patch/service pack level.
The good news is that the process to create a cluster actually checks your potential
environment through a validation process, and then only if everything passes
validation do you proceed and create the cluster. The validation process gives a lot of
information and performs in-depth checks and should be used anytime you wish to
make a change to the cluster, such as when adding another node. It’s also possible to
run the validation without any changes because it can be a great troubleshooting tool.
If you experience problems or errors, run the cluster validation, which may give you
some ideas of the problems. The validation process also has some checks specific to
Hyper-V.
Cluster Network Requirements and Configurations
Before I go into detail on validating and creating a cluster, this section touches on the
networking requirements for a Hyper-V cluster and, specifically, requirements related
to the cluster network.
The cluster network is critical to enable hosts in a cluster to communicate with each
other. This is important for health monitoring, to ensure that hosts are still running
and responsive. If a server becomes unresponsive, the cluster takes remedial actions.
This is done via a heartbeat that is sent by default every second over port 3343 (both
UDP and TCP). This heartbeat is not a basic “ping” but rather a request-reply type of
process for the highest level of reliability and security that is implemented as part of
the cluster NetFT kernel driver, which I talk more about in the next section “Cluster
Virtual Network Adapter.” By default, if a node does not respond to five consecutive