Windows failover clustering.
Now AZ‑801 has a lot of failover clustering,
so this is a Windows feature that you really need to be sharp on.
I dare say if you go into AZ‑801 not very clear on failover clustering,
you probably won't clear the exam, it's that big of a topic.
A cluster, in general, is a group of independent hosts, basically computers.
These can be physical computers or virtual machines that provide high
availability and scalability to clustered roles, though the bottom
line is you have a SQL Server database, you could have file shares,
you could have Hyper‑V virtual machines that are running services and
offering data for which you may have service‑level agreements,
so it's really important that you keep those services available,
that's high availability.
And normally when it comes to high availability,
we're talking about redundancy,
and that again is a core principle of a failover cluster.
The more nodes you have in the cluster, the more redundancy you have.
Now there's some Microsoft‑specific twists to the
subject of failover clustering.
One is the Clustered Shared Volume,
which you'll know a lot about by the end of this course and
certainly by the end of the skill path.
A Cluster Shared Volume is a way to support two
specific types of clustered roles.
There's the Scale‑Out File Server,
which from the name you might think this is highly available file shares,
and that's true.
And then there's highly available Hyper‑V VMs,
these are definitely the marquis clustered roles that most
Microsoft customers use with failover clustering.
I would add SQL Server actually,
but you're not going to see SQL Server on your AZ‑801 exams.
But these all function excellently, if that's a legitimate term,
when you're using commodity storage, Storage Spaces Direct,
and Cluster Shared Volumes.
The idea is that you can do your clustering end‑to‑end with
your commodity physical servers or VMs,
and the Windows Server Failover Clustering and Storage Spaces Direct features.
You don't necessarily have to have a dedicated SAN,
or storage area network for your shared storage layer.
We also learn in this course about Cluster‑Aware Updating,
which picks up the question,
how do we maintain the integrity and availability of our failover cluster
when we have to patch the servers from time to time,
particularly with Microsoft provided updates? Guest
clustering is a vocab term that refers to setting up a
failover cluster virtually using Hyper‑V VMs.
That's absolutely possible.
And stretch clustering is another vocab term that refers to taking a
failover cluster and stretching it across multiple sites,
so this gives your cluster potentially multi‑region high availability.
Let's take a look at a couple of conceptual diagrams
I've put together with Lucidchart, my favorite drawing tool.
This shows a topology of Windows Server Failover Clustering.
What is something that all failover clusters,
whether it's Microsoft or non‑Microsoft,
has in common is the idea of shared storage,
and hopefully it makes sense that you need that shared access
to the storage layer because this is your data that you're
providing high availability for.
Think of a file share with files.
Think of SQL Server databases.
Think of virtual machines.
In this case, we have a number of nodes as they're called,
these are Windows Server machines.
I'm dealing with Active Directory in this course,
so I'm going to assume that all of these nodes are domain members.
That's assumed here, not even implied, it's assumed.
And the idea is that you can do active‑passive high availability.
So in this example,
Node2 is active for a particular virtual machine, that highly
available VM is called a clustered role.
The idea of failover is if Node2 goes down either expectedly or unexpectedly,
we can either manually or have Windows Server take care of
shifting or moving that role to another node.
Node3 would have been passive for that VM,
but after the failover completes it will become the active node for VM.
And the idea is when Node2 comes back online,
you can shift the clustered role, that's called failback,
back to the original node,
or you might keep it at Node3 and keep that as an active node.
The idea of quorum, which we'll get into later in this course,
deals with what happens when one or more cluster nodes becomes unavailable.
See,
they communicate, these Windows Servers communicate with each other
using what are called cluster heartbeat messages.
TCP/UDP port 3343 is standard.
And the idea is if a node stops issuing heartbeats,
then the quorum needs to each vote to determine do we have majority,
do we have a majority of our nodes here?
And depending upon whether you start with an even or odd number of nodes,
you may need to bring in a witness.
And there's a few different types of witness that we'll talk about,
and they can serve as a tie‑breaking vote.
So,
bottom line is quorum determines how aggressive your
cluster is in terms of deciding majority and whether it
should shut down or stay available.
Now VMs are kind of an exception for clustered roles
because you'll continue to access highly available or
clustered VMs on their own IP addresses.
But normally,
as you can see with a Scale‑Out File Server, we've got a shared
folder that's accessible on a DNS name and IP address.
So we have what's called a client access point or a virtual IP address,
and this is convenient because then we have a single DNS IP
address that anchors to that shared role.
And the idea is the cluster is responsible for resolving
which node is active for those requests,
but the requests themselves will always go to the client access points.
So your application and your connection string or wherever
your incoming request for service is just has to worry about getting to the client access point.