And it's also a good spot.
I've got a whole string of errors here.
Yikes!
Yeah, well, there are some reasons, frankly,
why I'm generating so many errors, but in fact,
it might wind up with that updating process failing because of it.
I'm a hurting unit here, okay?
Come on now, be gentle.
Okay, so let's take a look while we're waiting for that,
and we'll report on it back in the CAU application in a moment.
Let's take a look at failover and failback.
We recall that we've got the two main roles that I've seen
in business on failover clustering 3, really,
our highly available VMs, then we've got our file shares,
which you can do the traditional highly available,
active‑passive,
or you could do Scale‑Out File Server active‑active with cluster shared volumes,
and the SOFS,
the Scale‑Out File Server is used to store Hyper‑V VHDs and configurations,
and also,
SQL Server databases when you're doing high availability
in a failover cluster infrastructure.
All right, so far so good.
So let me select this vm1, and let's actually make a connection to it here,
and we can see that it looks like I haven't yet installed an operating system,
but we're going to go through that process here.
And watch this, we're going to, we see that the Owner Node for vm1 is mem2,
Well, I'm going to mosey on over to mem2,
and I'm not going to Pause and Drain.
This is what we would want to do if we were manually,
gracefully taking a cluster host out of commission.
Instead, I'm going to, well,
I don't want to evict or stop the cluster service either,
so actually, why don't I just do a Pause,
Do Not Drain Roles.
Let's just see.
We still have availability here on the virtual machine.
I am using cluster shared volumes, by the way,
on this virtual machine connection.
You know, the Pause really isn't giving us enough impact here,
but let me do a Resume, Do Not Fail Roles Back,
and let's just swing the heavier hammer here.
Let me go to PowerShell and do an Invoke‑Command where the ComputerName is mem2,
and the ScriptBlock I'm going to pass here is simply Stop‑Computer.
That's going to be the equivalent of the machine having a catastrophic
interruption where it's just going to go dark immediately.
And that's more of actually a real‑world case.
We can see Draining.
So almost immediately, the failover cluster is aware that mem2 is in trouble,
and we need to initiate a Role Drain.
So if we go over to Roles, we can see the two things,
actually, it looks like the VM already shifted,
and the SDDC Group, that's our Storage Spaces Direct subsystem,
that one is currently owned by mem2, and that's in a Pending state.
It's taking a little bit longer,
but that's going to come over to mem1 as the Owner Node as well,
and it looks like my installation here.
I've never actually tried a failover while I'm doing an OS installation.
This might be a little bit different than if the
machine were just started fresh.
Maybe if I force a reset.
I just wanted to get something on this VM up and running so we
could see it in process survive a failover event.
Yeah, well, we didn't even need to do the reset.
It looks like it was just waiting.
Oh, and then the reset kicked in.
Okay, there we go.
Well, that's fine.
It's bringing us back to where we need to be, as you can see.
I think the concept is proved though.
We're able to shift that very,
very easily because if we look at the C ClusterStorage mount point on each node,
that's where our virtual machine, our vm1,
both the VHD, as well as its configuration snapshots,
those are all available to all cluster nodes,
so it makes it a lot easier to perform that failover and failback.
Now, I had mentioned that if we look at the Properties of a clustered role,
this is where you can specify those Preferred Owners.
Now you can select which one, or ones, it's going to be.
You can adjust the priority.
I want mem1 to be at the top of the list High,
I want 1 and 2 to be my 2 preferred nodes.
Actually, there's just the two of them, but notice that if you select just one,
you can shift the Priority, High, Medium,
Low, No Auto Start, depending upon how important the workload is.
And then for failover, as I said, I'm going to do an Allow failback,
Immediately.
I probably should have had that set originally.
That would be if I want the machine to go back to mem2.
I actually don't, so I'm going to put that on preferred fallback.
Let's balance out the cluster a bit because it looks like we've got some
serious issues going on in terms of mem1 is hosting everything.
Well, in order to do that,
we're going to need to bring that machine back online,
so why don't I just adjust this?
Actually, I don't think I'll be able to hit the machine.
No, because of the Invoke‑Command, I've got the machine flat on its back.
But what I'm going to need to do actually is go to mem2 and start it.
Through the magic of video editing, I did that.
I can quickly verify, mstsc, mem2.
Oh, I'm not sure I have my firewall configured for Remote Desktop.
Oh, okay. Well, when all else fails,
we can try something like test‑NetConnection ‑ComputerName mem2.timw.info,
Port 6516, that's the Windows Admin Center port.
Test‑NetConnection is a great alternative to ping
because you can hit on any port.
Again,
this False is probably indicative more than anything else of a firewall block.
So, anyway, I think the best thing to do is to come back up here,
and we can see, very easily, that mem2 is back up.
So if we want to balance this out and shift SDDC Group back, we can do a Move, Select Node.