In this demonstration, we're going to deploy a Windows Server failover cluster.
You're looking at the desktop of one of my Windows
Server 2022 domain member servers.
Let me open up Edge here, and you can see I have Windows Admin
Center installed on this machine. And what I want to do, this
machine is configured as a gateway.
Let's just go ahead and add in connectivity here.
Note that in Admin Center, we have seamless connectivity to other servers
in our domain environment. We can add connections directly to server
clusters, as well as going up into Azure. Now,
I'm going to choose the first servers option, and I'm
going to bring in the other node here, mem2.timw.info.
I'm just going to do a two‑node cluster, and we're going to use an
Azure cloud witness to serve as a tie‑breaking vote.
So this would allow us to lose one node in the cluster
and still keep the cluster going.
Let me provide credentials here to authenticate to that
machine, and we'll add with credentials.
Great! So, let me do this installation with PowerShell.
Now you know that Windows Admin Center, actually, we could
do a lot of the work there.
We also could go to good old Server Manager. However,
because you're so likely to see quite a bit of PowerShell on your AZ‑801
and AZ‑800 exams, probably more 800, it's still important. And really, in
the name of infrastructure as code and automation, I feel most
comfortable doing it this way anyway. So what you're seeing now is my
Visual Studio Code instance. I have a script file called clustering‑final
that I include in the course files for your reference. And we're going to
start here by installing the appropriate server roles on mem1 and mem2.
You can see that in order to support failover clustering,
scale out file server, and Hyper‑V highly available VMs, I'm bringing in here
on my feature list variable, Hyper‑V, Failover‑Clustering,
Data‑Center‑Bridging. I want to install the Windows PowerShell clustering
module, Hyper‑V, PowerShell, and the file server tools as well.
And as you can see, I'm just creating variables that contain arrays of the
server names on line 4, the features on line 5. So let me right‑click and run
these in my integrated terminal below, and then I'm going to do an
Invoke‑Command against that ServerList, and I'm going to throw in that
Featurelist, so let me run that selection. Now I've put in the ‑Restart flag
here because Hyper‑V, I know for a fact, is going to require a reboot. I don't
remember about failover clustering, but either way, these machines are going
to go down for a reboot momentarily. While we're waiting though, let me walk
you through some of the other PowerShell code on the script. You can see on
line 12, we can validate the cluster by using the Test‑Cluster command.
Now that command is going to be part of the RSAT cluster in PowerShell
feature that we're installing up here on line 5.
Now there are a number of tests you can use to validate the cluster.
The ones that I'm including here, obviously I want Storage
Spaces Direct, but I'm also including Inventory,
Network, and System configuration. And if we have any errors,
we will need to resolve those before we can bring up the cluster.
Now surprisingly, I was expecting the machines to restart automatically.
So let me do an Invoke‑Command here against the ComputerName's mem1, mem2.
And then for my ScriptBlock,
I'm just going to do a Restart‑Computer ‑Force, and then I will
see you at the other side of this reboot.
Okay,
we're back from the reboot on mem1, so let me bring up VS Code
again, and let's pick up where we left off. We're going to run
Test‑Cluster, and it looks like it bombed out.
That's because ServerList dropped out of scope of my session here.
So let me rerun and repopulate the ServerList variable, and
then let me right‑click and run this test.
And while this is running, again,
let's proceed with the code, and I want to give you some
additional tips and learning suggestions as we go on.
The output of this test is going to be an HTML file, so that's
going to be a very useful reference for us as administrators.
Once we've resolved any errors,
warnings are okay, but errors are not, we're ready to create the cluster.
So as you can see on line 15, we'll run New‑Cluster, give
the cluster a hostname, and that will be a fully
qualified domain name, in my case, az801cluster.timw.info.
The nodes are going to be, again, the ServerList array.
I'm specifically doing no storage here because we're going to add in Storage
Spaces Direct later in the course, and I do want to reserve an IPv4 address
on my LAN for this cluster. And we will find that the cluster's name is
registered in our Active Directory DNS.
Then on line 18, notice that I'm setting a ClusterQuorum here.
I'll show you more about quorum configuration later in the course. But if
you've got access to a general purpose storage account,
it's pretty easy to create a cloud witness, as long as you have the
connectivity to it. You can see Set‑ClusterQuorum ‑CloudWitness, and then we
have the name of our Azure Storage account and then one of the two access keys
that are used to protect the storage account.
Now, be very careful about exposing an access key in plaintext like I'm
doing here. I would not, for instance, commit this ps1 file to source
control unless I did something about that access key.
I could just null it out by doing open and closed quotes, or I could do a call
to Azure Key Vault and fetch the key from there, for example,
we don't want to have anything secret accessible in
plaintext for any length of time, for sure.
And then going beyond that, once our cluster is stood up, we'll then do a
little bit of monitoring. And there, I just want you to remember that
Performance Monitor is our built‑in monitoring tool in Windows Server, and then
the Azure analog would be Log Analytics and Azure Monitor. And then as far as
programmatic monitoring and administration,
there is the old school Cluster.exe executable, but the Microsoft
engineers have done a pretty good job of mapping those old Cluster.exe
commands to PowerShell. And PowerShell being an object‑based automation
language is able to give us much more wide spectrum control and
visibility than these old compiled executables. So we'll finish by just
taking a look at a couple of the Get commands. Now like I've mentioned
before,
let me mention it again that the way the exams will test your PowerShell,
in all likelihood, is you will have code given to you in context like a
script file, and periodically through the code you'll have active
components like drop‑down list controls that you will then select and
choose from a series of options.
So this is a way for Microsoft to validate your skills.
Okay, so we can see here that my cluster was conditionally approved.
That must mean that there's some warnings.
So let me select the file path. Whoa! The highlight
colors are really messed up here.
Let me see if this will work. Paste that in.
Yeah, it looks like it will. Good.
So let me bring up that report, which as you can see gets stored
under your Users profile, AppData\Local\Temp.
So you want to save this file somewhere else if you want to keep it. Now
let me zoom in so you can have a better time reading it.
So it looks like we've got Success for Inventory, Warning for
Network, Success for Storage Spaces Direct.
That's what I was most concerned with, so I'm glad.
And then we have Warning for System Configuration.
Let's see, is there any other warning? Warning for Validate
Network. Storage Spaces is everything.
And then it looks like the warning for System Config was that not all of my
device drivers are digitally signed, which is a concern, but it's not a deal
breaker at this point. To come up to Network,
it looks like Validate Network Communication was a
problem, so what's this saying? Again, this is a best
practice, but it's not a showstopper.
It's basically saying that my nodes are reachable by each
other through only one network interface each.
So it's recommending this is bringing in issues like NIC teaming and multi‑path
I/O so that you have redundant connectivity between your cluster nodes and also
between each cluster node and your shared storage.
Now, that's not as big of an issue because, as I've mentioned several times,
we're going to be doing Storage Spaces Direct and not SAN, iSCSI or Fibre
Channel storage, all right? So as far as monitoring,
like I said,
well, we first have to create the cluster. So let me come down and clear
my terminal screen, and let's run line 15 here to create az801cluster
using the ServerList array. I'm going to give it a static address. To set
the stage, let me see if I've got the DNS management console on this
system. I don't think I do, no.
So I'm going to have to do a little bit of RSAT work to get that going.
And what we can also do is bring up Windows Admin Center. Let me
authenticate in as a domain administrator, and let's connect into my mem1
node. And just while we're waiting here, let me do a search in the Tools
list for Roles & features. And unfortunately,
there's not a search filter in here.
This is a long list too, unfortunately.
So we've got Remote Server Administration Tools, and we've got Role
Administration Tools, and I'm looking for AD DS tools like, okay,
so that should give the Active Directory Users and Computers and all that.
That's fine.
I also want to bring in my DNS Server Tools, and it looks
like I've got Hyper‑V already installed.
So, the reason I'm showing you this is because Windows Admin
Center features on both AZ‑801 and AZ‑800, so it's really not
optional that you get familiar with it.
We go over Windows Admin Center installation and maintenance in AZ‑800. In AZ‑801, it's just assumed that you're using it, okay?