Failover and Cluster Management.
Here let's take a look at what happens in your failover cluster,
depending upon whether the failure is repairable or reparable,
or irreparable.
Now,
what would be an example of a reparable failure would be
something transient maybe that takes down a node.
We could consider taking a node offline for scheduled
maintenance as a reparable failure.
Something where the node is expected to come back online as is,
is what we're talking about.
And the main workflow here is three steps.
One,
if a failure occurs that's reparable on that node and it becomes unavailable,
remember previously in this course,
we discussed a little bit about the heartbeat messages,
and this is how the nodes communicate with each
other to make sure that they are, in fact,
reachable.
We would let the failover occur so that the failed node,
all of its clustered roles would be shifted to another node.
Of course, then we would need to, through our alerting,
become aware of the problem, fix the problem on the failed node,
bring it back online,
and then depending upon how we configured those clustered roles,
we could either automatically let failback happen or we can manually intervene
to failback those clustered roles back to the original node.
Now an irreparable failure would be where a node is really
going to be permanently flat on its back.
And this one has five steps.
One, we allow failover clustering to do what it does best,
you know, taking care of the failover process.
Once that happens,
we would then notify the failover cluster that the failed node
is no longer going to be part of the cluster.
We would evict the fail node.
We then would replace the failed node with a new physical or virtual machine.
We would then need to use either the Failover Cluster MMC
Console or PowerShell to run cluster validation against the
new node and add it into the cluster.
And once it comes into the cluster,
we then can transfer roles manually to the new node
and configure preferred owners, etc., etc.
Now,
I guess something else that would be considered an
"irreparable failure" would be where you have a cluster node
that's just reached its natural end of life.
It hasn't crashed yet, but you're going to decommission it,
take it out of the cluster, and replace it with a new model.
That would be another instance where you would use this particular workload.
Now you'll see all this stuff in the demo upcoming,
but I want to prepare you here so in order to manually failover a workload,
as you can see here, we're right‑clicking a clustered role,
and this is, of course, graphically through the Failover Cluster Manager.
We can right‑click and, in this case, depending upon what the role is,
this looks like a Scale‑out File Server Share,
so we can move that workload either to let the cluster
determine the best possible node.
And how does the cluster know what the best possible node is?
Well the best way to do that is to configure preferred owners yourself
because the cluster is only as smart as you are,
the person who's programmed it.
Or you can manually select the node, as you can see from the flyout menu.
So speaking of preferred owner, let's just take a quick look.
If we look at the properties of a clustered node,
there's generally the two tabs here, General and Failover,
and on Failover, you can see down at the bottom,
this is where you instruct the cluster to automatically shift the
clustered role to the secondary host. That is,
when the failover occurs,
you go from the active to another node if you want to go back
automatically to the original role holder or prevent failback.
So you would just specify that according to your preferences.
And on the General tab, as you can see here,
this is where you can create a hierarchy of preferred owners.
You might have workloads that,
based on particular hardware features of a particular hardware node,
you may feel a bit more strongly about having that
particular node host that role most of the time.
Now, that's in a sense, kind of an edge scenario because ideally,
all of your cluster nodes are identical from a
hardware and software perspective, at least a hardware perspective.
Here we have a graphical screenshot of Failover Cluster Manager again,
and we start, in this case, this looks like using virtual machine failover.
It's, again, a different UI because it's a different clustered role.
Right‑click the VM.
We do a move, but with Hyper‑V virtual machines it's a little bit different.
We can migrate just the virtual machine storage or we can
migrate the storage and configuration.
And I tend to do live migration in order to minimize any downtime.
And when you go to Live Migration,
you see there's Best Possible Node or Select Nodes.
So it's a similar notion with preferred servers.
Now,
what I didn't mention in the previous screenshot that I'll mention
here, that also applies to Scale Out File Server, is remember that
you're using Cluster Shared Volumes.
This means this particular VM we're talking about on this slide,
nestvm, has as both it's VHDs as well as its
configuration available to all cluster nodes.
So especially when you choose the Live Migration option here,
you're minimizing that switchover time and thus improving the high
availability of your virtual machine and your other clustered
roles that use Cluster Shared Volumes.
Now I had mentioned that Hyper‑V highly available VMs have live and quick,
and you should use live wherever possible.
This is just me speculating a little bit,
but in my experience, I think that quick is just there for legacy environments.
Specifically, the idea is that live is truly a live
migration where the VM experiences no downtime.
When you do a quick migration, the failover cluster pauses the VM,
so there is going to be some negligible downtime.
And again, speculation alert,
I think the difference there lies in the hardware
capabilities of your cluster nodes.
Years ago, of course,
not everybody had current hardware that was fully aware with
CPU virtualization support and all of that.
Nowadays that's pretty much the standard,
which is why I recommend you always do live migration.
When cluster nodes may not have matching hardware,
particularly ones with older hardware,
you may want to go a more traditional copy route, and that would be quick migration.