running but the guest OS is still functioning, and therefore no action is needed at the
host level. If instead guest clustering was leveraged, which means a cluster is created
within the guest operating systems running in the virtual machines, the full cluster-
aware application capabilities will be available—for example, detecting that the
application service is not responding on one guest OS, allowing another instance of
the application to take over. Guest clustering is fully supported in Hyper-V virtual
machines, and as covered in Chapter 4, “Storage Configurations,” numerous options
provide shared storage to guest clusters, such as iSCSI, virtual Fibre Channel, and
shared VHDX.
The guidance I give is as follows:
If the application running inside the virtual machine is cluster aware, then create
multiple virtual machines, each with the application installed, and create a guest
cluster between them. This will likely mean enabling some kind of shared storage
for those virtual machines.
If the application is not cluster aware but works with technologies such as Network
Load Balancing (NLB)—for example, IIS—then deploy multiple virtual machines,
each running the service, and then use NLB to load-balance between the instances.
If the application running inside the virtual machine is not cluster aware or NLB
supported, but multiple instances of the application are supported and the
application has its own methods of distributing load and HA (for example, Active
Directory Domain Services), then deploy multiple instances over multiple virtual
machines.
Finally, if there is no application-native high-availability option, rely on the Hyper-
V cluster, which is better than nothing.It is important to check whether applications support not only running inside a virtual
machine (nearly all applications do today) but also running on a Hyper-V cluster, and
extending that, whether they support being live-migrated between hosts. Some
applications initially did not support being live-migrated for technical reasons, or they
were licensed by physical processors, which meant that moving the virtual machine
between hosts was expensive because all processors on all possible hosts would have
to be licensed. Most applications have now moved beyond restrictions of physical
processor instance licensing, but still check!
You should perform another configuration on your Hyper-V cluster for virtual
machines that contain multiple instances of an application (for example, multiple SQL
Server VMs, multiple IIS VMs, multiple domain controllers, and so on). The goal of
using multiple instances of applications is to provide protection from the VM failing
or the host that is running the virtual machines from failing. Having multiple
instances of an application across multiple virtual machines is not useful if all of the
virtual machines are running on the same host. Fortunately, Failover Clustering has
an anti-affinity capability, which ensures where possible that virtual machines in the
same anti-affinity group are not placed on the same Hyper-V host. To set the anti-