For the deployment, configuration,
and management of our NSX environments, we are going
to use an entity called the NSX Manager
and think of the NSX Manager, very similar to the function
of a vCenter Server Appliance.
So we're using vCenter to manage our ESXI hosts.
We're gonna use the NSX Manager to manage all
of our NSX components.
What we're gonna first do is deploy the NSX Manager as a VM.
So we'll choose one of our ESXI hosts to deploy that on
and then once we deploy it, it's gonna encourage us WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then once we deploy it, it's gonna encourage us
to go ahead and create a cluster.
And a cluster is three VMs,
specifically three NSX Manager VMs that we can use
to help manage our entire NSX environment.
So let's say we have three VMs that we've deployed.
Now the first one we're gonna deploy as an OVF.
So you deploy it, install it,
you let it get up and initialized
and then once it's running, it encourages you
to add additional managers.
So right from the interface of the NSX one, for example,
you can go ahead and deploy NSX two and NSX three.
It'd also be wise to have each of those WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It'd also be wise to have each of those
on a separate ESXI host.
So this could be on host X, and this could be on host Y,
and this could be on host Z.
So we may wanna set up some affinity rules to make sure
that if we're using DRS that our NSX VMs are being deployed
and not on the same exact host.
That way we can share the love and the resources that each
of those NSX appliances is gonna get.
So let's imagine this is our management network right here,
and I'm gonna use 192, 168.1.0 with a 24 bit mask.
So maybe this guy's at .11, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So maybe this guy's at .11,
and we put the second one in at .12,
and we put the third one in at .13.
And what we can also do is set up a virtual address,
a virtual IP, to manage them as a cluster.
So let's go ahead and pick, for example, .10
as the virtual IP so you and I, we connect to the IP address
of .10 with https, and this is gonna associate that with one
of our NSX managers, and that's where we can go ahead
and start working.
Now, behind the scenes, let's say we have 50 objects
inside of NSX, including hosts and other VMs
that we'll be talking about here in just a moment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we'll be talking about here in just a moment.
Even though when we connect to the virtual IP address,
we're only connected to one of the NSX appliances
or one of the NSX managers, behind the scenes,
it's gonna divvy up some of the loads.
So perhaps this NSX Manager is gonna be managing
15 of our objects, and this device is gonna be managing
15 of our objects, and this one may be 20,
so hopefully that adds up to 50.
So that division on the backend is done automatically.
Also, in addition to using a virtual IP address,
we could also set up a load balancing service
on the front end and if we did implement a load balancer, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on the front end and if we did implement a load balancer,
we would connect them to the load balancer virtual
IP address, and then it could spin us off to the least busy
or based on the load balancer rules, the NSX Manager
that it believed was the least busy,
but even without a load balancer,
we can set up a virtual IP address,
have multiple NSX managers,
and behind the scenes, they'll divvy up the responsibility
of interacting with and working with our NSX devices.
And these NSX managers working together are referred to
as an NSX Cluster.
So to give you a visual idea of what that looks like,
this is the interface for the NSX manager. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this is the interface for the NSX manager.
So I've gone here to the appliances section,
and I currently have one NSX manager in place.
So it's begging me, please add more.
So I simply click here and I could go through the process
of yet adding a second, and then repeat that
to add a third NSX manager that would become
part of this cluster.
So on this first NSX Manager, there's its management address
right there of 192 168, 1.11 and then here's the version
of NSX that I'm currently running.
So the NSX Manager is the brains of the operation.
So let's imagine this is our NSX Manager right here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's imagine this is our NSX Manager right here.
As part of the deployment, once we deploy it,
we'll also tell it where our vCenter is.
Let's mention we also have here on our management network,
the vCenter Server Appliance
and the reason the NSX manager needs to know
about the vCenter Server is because the vCenter Server
is in charge of the distributed switch,
which in the current flavor of NSX,
we're gonna be leveraging the virtual distributed switch
and adding our logical segments from NSX to our VDS.
So as part of that integration, in addition
to identifying the virtual distributed switch in vSphere
that we're gonna use and enhance, we're also gonna leverage WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we're gonna use and enhance, we're also gonna leverage
that relationship with the vCenter to identify the ESXI host
that we are going to include as part of NSX.
So that way right here from the NSX manager, we can specify,
oh, for this host or that host, we want
to add the NSX software to those hosts
so they can participate as part of NSX.
And the NSX Manager is gonna become the centralized control
plane for the NSX environment.
So any of the details regarding segments or routers,
virtual routers in the NSX environment, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
virtual routers in the NSX environment,
or which segments should be included on which hosts,
that's all controlled by the NSX Manager,
and it's gonna be the Centralized Control Plane.
And then on each of the ESXI hosts
and other objects that we'll soon talk about here
in a moment, they'll receive a copy of what they're supposed
to do and that's called the Local Control Plane.
So the Centralized Control Plane is managed
by the NSX Manager cluster.
And for individual hosts that are participating in NSX,
they'll have a Local Control Plane.
Effectively what they need to know to do their jobs
as part of NSX. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as part of NSX.
Let's imagine that you and I are sitting here
at this management PC, we've logged onto the NSX Manager
and we've identified these two hosts, we'll call it host A
and B, that we want them to participate as part of NSX.
So from the NSX Manager, we install and add the software
to those hosts.
And the moment that we add that NSX software
and they're up and running and happy, happy,
those are now referred to as transport nodes.
And think of a transport node as an ESXI host
with the additional software regarding NSX that allows it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with the additional software regarding NSX that allows it
to do the tunneling that we took a look at
a couple videos ago where traffic coming in, for example,
from one VM on a segment is encapsulated and tunneled
and shipped off to a remote destination
where the receiving site is de-encapsulated.
Effectively, that's the function of a transport node
in the world of NSX.