So in this video, I'd like to walk
through two things, actually.
One is I'd like to set up the virtual IP address of .10
on my 192.168.1 management network.
And that way when we connect to .10,
it can associate that with one of our active NSX Managers.
So at the moment, we just have NSX Manager .11,
but if we had NSX Manager at .12 and another one at .13,
you and I could just connect to that virtual IP address
and then automatically in the background,
that IP address is being managed and responded to
by one of our existing NSX Managers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
by one of our existing NSX Managers.
And then the second thing I'd like to do,
after we set up a virtual IP address and verify that,
is I'd also like to walk you
through setting up anti-affinity rules
so that if we have three NSX Managers
as part of our cluster, they each are gonna be running
on a separate ESXI host to help make sure
they have the resources they need.
And then more importantly also,
to help with fault tolerance
in the event that we lose one of our ESXI hosts
or have a network connectivity problem
with one of our ESXI hosts.
So here we are back at the NSX Manager
and what we're gonna do is we are gonna go to System WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and what we're gonna do is we are gonna go to System
to specify the virtual IP address for the cluster.
So here at System, on the left,
we're gonna click down under Configuration
and click on Appliances.
So as a reminder, if we wanna add additional appliances,
we click here, follow the bouncing ball to deploy them.
But if we wanna set up a virtual IP address
for the cluster as a whole,
we simply click right here on SET VIRTUAL IP.
So based on our plan,
our virtual IP address is gonna be 192.168.1.10,
and then we'll go ahead and click on Save.
Also, if we're doing IPv6,
we'd wanna set up a virtual IPv6 address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we'd wanna set up a virtual IPv6 address
once again for the cluster.
But since we're just using IPv4,
I'll only specify one virtual IP address for that,
and that's the 192.168.1.10, and we'll click on Save.
So that's gonna take a few moments
to go ahead and crank through that.
So we'll give that a moment to complete
and then once it's done, we'll reconnect over to .10
and verify that we still have connectivity
to our NSX Mgmt Cluster.
So currently here, still under System, and Appliances,
it's showing in Virtual IP now
the virtual IP address of .10. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the virtual IP address of .10.
It's also showing us that the NSX Manager
that's currently responsible for that virtual IP address
and responding to queries on that address, is 192.168.1.11,
which is our one and only NSX Manager at the moment.
So let me dismiss the message about backups
and let's go ahead and reconnect,
but this time we'll connect
to the virtual IP address of 192.168.1.10.
Alright, so we are connecting initially
and we don't yet have certificates all dialed in
in our NSX environment.
So we can't verify the certificate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we can't verify the certificate
and that's why my browser is complaining
about a certificate that it can't validate.
So this is the IP address we're connected to, 192.168.1.10.
That's the virtual IP address.
So we're gonna click here in Advanced
and Proceed, and away we go.
So we'll log back in as admin,
we'll put in the password, and click LOG IN.
Alright, and here we go.
So if we went back to System once again,
up here on the top, it's giving us a nice system overview.
If we click here on the left on Appliances,
here under Appliances, it shows that the cluster is stable. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here under Appliances, it shows that the cluster is stable.
And once again, we could look at the details
for this specific NSX Manager,
which is our only one at the moment,
by clicking here on VIEW DETAILS just to confirm
that everything looks up and operational.
And even though I don't have three NSX Managers
as part of this cluster, I just have one,
I would like to demonstrate
how we could set up affinity rules
to make sure that our NSX Managers
within a cluster are not run on the same host.
So to do that, we're gonna go back to the vSphere client
to set up our affinity rules, or more accurately, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to set up our affinity rules, or more accurately,
we could call them our anti-affinity rules
because we wanna make sure that each
of the VMs does not run on the same exact host.
So I'm gonna go ahead and create
just a couple additional VMs as dummy VMs
so I can demonstrate the rules.
So I'm gonna take a tiny Linux template here
and create a new virtual machine from this template.
I'm gonna call this nsx-mgr-12
although it's not really an NSX Manager,
it'll give us the opportunity to work
with the affinity rules,
and I'm gonna place that in a folder called NSX Managers.
Click on NEXT, and as far as
where do you wanna process this, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
where do you wanna process this,
I'm gonna put this in the Mgmt Cluster,
but I'm gonna put it on host d.
So our original NSX Manager is on host c.
I'm gonna put this second NSX Manager on host d
and then click on NEXT, specify the data store.
I'll go ahead and use the same format as source,
click on NEXT, then I wanna customize
that VM and power it on.
Click on NEXT, and it's currently
on the MGMT port group, fantastic.
We'll click on NEXT and FINISH.
Alright, there it goes.
There's our little placeholder for nsx-mgr-12,
and we'll right click and create
another virtual machine from this template, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
another virtual machine from this template,
and we'll call this nsx-mgr-13,
again, just as a placeholder for a VM
so we can demonstrate the affinity rules,
and we'll put that in NSX Managers as well, NEXT.
So currently, I've got the real NSX Manager on esxi-c.
We just put the second one on d.
And because I don't have a third host,
let me just use a third host out of a different cluster.
Let me pick esxi-b, and click on NEXT.
Again, just for the demo of having each
of the NSX Managers on different ESXi hosts.
So we'll go ahead and start off with them on different hosts WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll go ahead and start off with them on different hosts
and we'll click on NEXT, and Customize and Power on, NEXT.
And it's also in the MGMT network port group.
Click on NEXT and FINISH.
So now if we look at this folder called NSX Managers
and we click on the VMs tab,
we currently have these three VMs, 11, 12, and 13,
running on three different hosts.
And to keep it that way, we go to our cluster
and I just realized those are in two different clusters.
So let me just choose the Mgmt Cluster as an example.
So we'd choose our Mgmt Cluster here and go to Configure, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'd choose our Mgmt Cluster here and go to Configure,
and in the middle column, we're gonna go down
to our VM/Host Rules, and then just create a new rule.
So we'll click on ADD,
and let's call it NO NSX VMs Together.
And for the type, we're gonna go ahead
and say Separate Virtual Machines
and then we'll specify the virtual machines
that we want to have run on separate hosts.
So we'll click on ADD.
nsx-mgr-13, because it's in a different cluster,
isn't even showing up here.
So I only have two hosts in this cluster.
So this will still work for the demonstration.
If we wanna influence DRS and have it
not place these two VMs on the same exact host,
we select those two VMs, click on OK, and click on OK. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we select those two VMs, click on OK, and click on OK.
So now with this rule in place for the Mgmt Cluster,
when DRS, Distributed Resource Scheduler,
is deciding where those VMs should be put,
or in the case of migration,
where they should be migrated to,
it's going to avoid placing those two VMs
on the exact same host.
And that's how we can help make sure
that we don't accidentally have two or more NSX Managers
that are both running on the same computing resource,
effectively meaning the same ESXi host.
All right, and because I'm not really WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, and because I'm not really
using nsx-mgr-12 or 13,
let me go ahead and delete that rule.
I'll say yes to that, and also, let me go
to the DataCenter level, go to VMs,
and let me select nsx-mgr-12 and 13,
those are the bogus ones that are not really NSX Managers.
They're just little temporary VMs that I put in place.
I'll right click on those, and let me go to Power,
and they are running VMware tools.
So I'll go ahead and shut down the guest operating system
and say yes to that.
So in recent tasks, that looks great.
Now those two VMs are shut down.
I'm also gonna right click for those two VMs
and say, please Delete From Disk, click on YES, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and say, please Delete From Disk, click on YES,
and that will remove them permanently
from our infrastructure.
So when we leave this, we now have a single NSX Manager
in my lab environment that is currently running
on esxi-c, as shown right here.
And if you go back to the interface,
if we look at the cluster by going to System > Appliances,
here is the representation of that NSX Manager.
And if we click on VIEW DETAILS,
we can confirm that it looks
like it's ready to rock and roll.
So now that we have an NSX Manager in place,
we've verified that it's functional, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we've verified that it's functional,
we also linked it with a vCenter server
so it could work with that vCenter,
what's our next logical step?
Well, the next logical step is give it
some transport nodes that it can work with.
and that's exactly what you and I get
to do in the very next skill.
So I'll see you over there when you're ready.
Until then, I hope this has been informative
and I'd like to thank you for viewing.