Hyper‑V high availability.
Let's start by defining our terms.
What exactly is meant by high availability?
High availability for our context,
and you can see the my citation in the lower part of the slide,
involves the implementation of controls that guarantee your workload is up
and running despite maintenance operations and outages.
All right?
Now, the words on this definition I think are very intentional.
We have guarantee.
You may very well be subject to service‑level agreements,
SLAs, with your employees, with your colleagues,
with your customers, whomever,
where you actually quantify the degree of availability your workload has.
And if your service is down over that SLA amount due
to a planned or unplanned event,
this could have big repercussions for your business,
and frankly, for your job security.
So we need to understand in Hyper‑V, and speaking as
Hyper‑V hybrid cloud administrators,
what are the main Microsoft‑provided options for doing high
availability workloads in Hyper‑V virtual machines?
Well, there's two kinds of clustering we'll learn a bit about.
There's host clustering and guest clustering, and we also have the
Windows Server Network Load Balancing service,
also called NLB. Now I'm not going to get deep into the weeds
in Windows Server failover clustering here because exam AZ‑801
goes much deeper into clustering.
So at this point, I just want to be able to differentiate, or I
want you to be able to differentiate, the two types of
clustering that we're talking about here.
Now,
first of all, to take a step back, clustering is generally speaking
where you have shared storage between N number of nodes
participating in the cluster. Now I say generally speaking because
there are technologies where you can do Windows Server failover
clustering without shared storage.
We'll get into that in the AZ‑801 skill set, but let's just kick
it old school and assume that we've got network accessible or
locally attached shared storage and we have N number of nodes
participating in the cluster.
Now,
the way that Windows Server failover clustering works is that
one node is going to be the active node for that clustered
role, and one of the most common,
if not the most common clustered role, is the Hyper‑V virtual machine.
So in this case, the right‑most node,
the one that's in the three o'clock position, is active for that
VM, and connectivity happens to that VM by coming into the
failover cluster's virtual IP address.
Now,
what makes failover clustering a high availability solution is
that if we need to take that node offline,
the one that's hosting the VM, we can manually move that VM to another node in
the cluster with minimal or preferably no service disruption.
Likewise,
if that node were to go down unexpectedly, the other nodes in the cluster
are aware via heartbeat messages who's up and who's down, and in that case,
another node will grab control over that VM.
How is the node able to grasp that control?
Well,
because the VM and its definitions are in that shared storage that's
accessible to all of the nodes in the cluster. You see the magic there? The
reason why we're calling this Hyper‑V host clustering is because, in this
case, your three nodes that are in this diagram are Hyper‑V hosts, as well
as members of a failover cluster, and the virtual machine is what's called
a clustered role.
Now, there is a more specialized version of Windows Server failover clustering.
What if you have a virtualized infrastructure where you have your
Hyper‑V hosts, in this case, NodeA1, A2, and A3, and they are, of
course, hosting virtual machines and highly available file shares and
SQL Server databases, etc., and offering those clustered roles under
virtual IPs as usual.
But what if you wanted to create an internal failover cluster within your
virtual machine infrastructure? A‑ha! In other words,
from within the guest VMs. Is it possible to set up a failover
cluster and advertise services under a virtual IP?
And, of course, the answer to that is yes. This is
called Hyper‑V guest clustering.
Now, there are quite a few implications in terms of how you'd want this to work.
Of course, one big one would be your cluster nodes really
should be on top‑level cluster nodes.
In other words,
notice that I've gotten NodeB1 virtual machine that's
being managed by the active node,
NodeA1, but NodeB2, another member of that guest cluster, is on NodeA2.
So what you have here is two levels of high availability to where you're
protecting the VMs that are forming the guest cluster, and then within
the guest cluster VM's operating system,
there's another failover cluster where you've got high
availability for services there. Yes, it's kind of complex and meta, but there you go.