In this demonstration,
I'm going to teach you how to set up and configure
Quorum for our Windows Server cluster.
We'll also cover Cluster‑Aware Updating,
and by the end of this demo, we will have set up also,
but wait, there's more, we'll also have set up Storage Spaces Direct,
as well as a highly available VM.
Yeah, a lot to do for sure, so let's get right to it.
I am still on my cluster node MEM1,
and hopefully you've got your screen set at a
resolution to where this isn't too small.
Unfortunately, we record at 1080 resolution,
which can make things a bit small for old
non‑responsive applications like MMC consoles.
But I created a custom console where I've brought in a whole bunch of
snap‑ins that I think are relevant to our interests.
So first of all, let's open up my Failover Cluster Manager,
and let's take a look at my az801cluster cluster.
And specifically, I'm going to right‑click that cluster node,
and notice that you can always validate your cluster,
view the most recent validation report, add a node.
But what I want to do is go to More Actions,
Configure Cluster Quorum Settings, and this launches yet another wizard.
And what I'm going to do here is not let the cluster decide what the majority
should be or just jump directly to configuring a witness.
I'm going to go to Advanced quorum configuration so we can have the
most flexibility over the entire Quorum setup process.
So let me click Next.
First, we're asked nodewise who is going to have a vote.
In this case, I just have two nodes, mem1 and mem2.
That's fine.
They're both up.
The big question here is what kind of witness do I want?
I think I already told you I want to do a cloud witness,
but notice that we've got disk and file share and do not
configure as other possible options.
Now when we configure a cloud witness, we need to connect to a storage account.
So that presumes, let me jump over to the Azure portal,
that you have a general purpose v2 storage account created,
and you also need to use the access key authorization method.
Now the good news about access keys is that they're
convenient and that you can rotate them,
as you can see.
This would invalidate any leaked keys that may be out there in the world.
And you can also, oh well, I noticed this for the first time,
set a rotation reminder.
I've never seen that before.
Cool.
But I was looking up here because there's normally a bit of verbiage
that you can also store your access keys in Key Vault.
But anyway, those are some points.
Good news is convenience.
Bad news is that if the plain text of an access key leaks,
you really want to remediate that immediately.
Doesn't matter whether you use key1 or key2 here,
but we'll need one of those values.
So we need the name of the storage account,
the key, and then the service endpoint is core.windows.net.
That's the public DNS that Microsoft uses in Azure for Azure Storage.
So if I go over to my PowerShell script file,
I can verify here because this is doing the same thing in PowerShell,
Set‑ClusterQuorum‑‑CloudWitness.
Timstorage001 is the name of my storage account.
I'm going to copy out the key, and yes,
I'm regenerating the key after I'm finished here because I certainly
don't want a real‑live key in my Pluralsight course.
So my storage account name, timstorage001.
Let me Ctrl+V that key in there and click Next, Next, and here we go.
So now we've got node majority plus witness as our forum type.
Good.
Now we're not going to really be able to do much of anything
on this cluster until we've got storage,
so we might as well take care of that next actually.
So, I'm going to do Storage Spaces Direct.
And I know that we haven't gotten to that module yet,
so I'm kind of letting the cat out of the bag,
but that's good because I found that when I first learned Storage Spaces Direct,
it was kind of difficult to wrap my mind around it.
So I'm just going to have us jump into the pool,
and then when we circle back and formally cover the subject,
you'll already have some familiarity with it.
Now, what I've got here,
notice I've got my Disk Management console set up for both mem1,
the local box, as well as mem2, the other member of this cluster.
With Storage Spaces Direct,
the value prop is that you can use the server's own disks as shared storage.
You see what I mean?
The catch to that though is that the disks need to be unallocated,
in other words, there can be no partition or volume structure on those disks.
And number two, they need to be online and initialized.
So as you can see, I've got two disks, 127 GB each.
And when I connected them, of course, they were offline,
so I right‑clicked in here and went Online.
Then I right‑clicked, and I did initialize.
And you can use either Master Boot Record or GUID
Partition Table for your disk layout.
I'm using MBR here.
I'm kicking it old school.
And I've got that same configuration from mem2.
As a good best practice,
you want to do everything you can to make sure that the storage topology,
that is the disk geometry and topology,
whatever term you want to use for your cluster nodes,
matches.
It's easiest that way.
All right,
so we've got a total of four disks that we're going to
give over entirely to the cluster.
And we can do that with one simple line of PowerShell.
Let me show you right here, Enable‑ClusterStorageSpacesDirect.
And then for CimSession, it's 801cluster.
And the command does a lot of heavy lifting,
and it's got a high impact here because by answering yes here,
I'm actually going to do A, whoops, not in here,
down in the output, I'm going to type A,
meaning Yes to all.
This is not only enabling Storage Spaces Direct on the cluster,
but the cmdlet now is going to go out to each node and try
to grab hold of every eligible disk and bring those disks
in for use as a shared pool.
And this means that going forward, if you add more storage to your servers,
those disks are going to be snapped up by Storage Spaces Direct as well.
So again, it's a pretty high‑impact operation here, as you can see.
So that didn't take long to do.
I know that in future lessons,
I'll show you how to report on Storage Spaces Direct,
but we don't need to worry about that right now.
I just wanted that operation to complete.
And you'll notice that if we go back to Failover
Cluster Manager and if I go to Storage, we now have Cluster Pool 1 defined.
It has the logical name S2D on az801cluster.
And if I go to Physical Disks,
you can see that it's enlisted both disks from each server.
Now then from here,
we can then start to create virtual disks that have
different types of redundancy, like a mirror or a stripe set with parity.
But again, that's all for the future.
One thing at a time.
I just wanted to make sure to have that here.
Now about Cluster‑Aware Updating, let's go back to the cluster node here,
right‑click, More Actions, and go to Cluster‑Aware Updating.
This invokes a separate graphical user interface, as you can see here.
And the idea here is that we can connect to our cluster, and you
might have more than one cluster available,
so you can use the single GUI to manage a multi‑cluster
infrastructure like a cluster set,
for example, and we can preview updates for this cluster.
Now the plugin is either going to be WindowsUpdate,
which is really Microsoft Update, just Microsoft hotfixes,
or there's RollingUpgradePlugin.
And depending upon whether you want to use the internet,
that is Microsoft Update online,
or if you want to use Windows Server Update Services,
you also could do that as well.
Now I'm just going to run an Update preview against the
standard internet‑based Microsoft Update,
and this is going to show any outstanding updates that those nodes don't have.
And it looks like they're pretty well patched.
It looks like we just have a Security Intelligence Update for
Microsoft Defender on each of those nodes.
Not too bad.
Now we can apply updates to this cluster.
We can configure cluster self‑updating options,
but the catch with that is in order to configure
your cluster to do self‑updating,
you need to have the Cluster‑Aware Updating role running in your cluster.
And I've found that works better with PowerShell.
So here on line 23, we could do Add‑CauClusterRole,
providing the name of the cluster, and then you define the auto‑update schedule.
This example says that every Tuesday and Saturday for every three weeks,
the cluster will do an automatic cluster run,
and this highly available role is that Engine of Creation,
if that makes sense.
So let me right‑click.
And this is going to create our first highly available role on the cluster.
And it's going to take care of self‑updating this
cluster on two days every three weeks. Well that was pretty easy, wasn't it?