Or our discussion regarding an NSX Federation, let's imagine we have two sites.
Now these sites could represent, for example, two geographical locations with a
data center
in each or in a campus environment.
It could represent two different buildings with two separate data centers or it
could
even represent two different racks in the same data center.
And the question is, how do we go ahead and manage all that?
Now one option is we could use a single NSX manager and have that single NSX
manager
manage the NSX environment at both sites.
Now one caveat is that if we have an ESXI host over here, we'll call it ESXI WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now one caveat is that if we have an ESXI host over here, we'll call it ESXI
host A.
That's running this VM right there.
And we have another ESXI host, call it ESXI host Y that's supporting that VM
right there.
So if these two VMs needed to communicate with each other, maybe this is an
application
server here and it is the database server.
If they're communicating back and forth, these two ESXI hosts in the background
are going
to be using Genev tunneling and saying that traffic back and forth between them
.
And to support that, as we've talked about previously, we're going to use a
larger than
normal MTU that needs to be supported between those two ESXI host. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
normal MTU that needs to be supported between those two ESXI host.
So if we're going to have a single NSX manager manage this entire topology here
with both
sites, we need to make sure that we're supporting a larger than normal MTU for
ethernet, for
example, 1700 bytes at least on the transport network to forward that traffic.
We'd also make sure that our latency is less than or equal to the required
minimums between
the NSX manager and the transport nodes here and also the edge nodes that would
be in
both locations.
And if we had really low latency, like 10 milliseconds or less, we could also
spread
our NSX managers across these two sites. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
our NSX managers across these two sites.
So in our cluster of NSX managers, maybe we have one or two here at site one
and one
over here at site two.
So as long as we have the latency dialed in with what's needed for NSX between
the NSX
managers and a cluster and also the NSX manager and their transport and edge
nodes, along with
the larger than normal MTU, we could use one NSX manager to manage the entire
environment
here, both site one and site two.
And in a single data center, for example, with high speed top of rack switches,
that is absolutely
no problem.
However, what is a problem is if site one is in one part of the country and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However, what is a problem is if site one is in one part of the country and
site two is
in a different part of the country or in a different country and doesn't have
support
for a larger MTU and as a result of being in two separate locations with maybe
not the
optimal connectivity, perhaps our latency doesn't meet the requirements as well
.
So how do we get around that if we have site one, for example, on site two in
different
locations where the MTU and latency requirements aren't in place?
Well, the answer my friend is dah-da-da-da, setting up an NSX federation.
So let's clear up the screen just a little bit and let's take a look at how NSX WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's clear up the screen just a little bit and let's take a look at how NSX
federations
can help us with this scenario.
So with NSX federation, we'd implement NSX management individually or locally
at each
site.
So this is the local manager, but LM for short there here at site one and at
site two, we
have the local manager here at site two.
So part of the NSX federation is having local managers at each site and then on
top of that,
we are going to implement a global manager.
So I'll name this global manager NSX manager dash global and we kind of think
of the global
manager like an org chart. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
manager like an org chart.
So for example, right here, if this is the global manager right here and then
below that
global manager, we'd have the local manager for site one.
I'll draw that in here in blue to color code that little arrow there as well as
the NSX
manager over here at site two and I'll draw the little arrow there as well.
So we can think of this global NSX manager as a manager of manager.
So this global manager would be responsible for the local manager here at site
one and
also the local manager here at site two.
Now at this point in our story, you might think, well, how does that help us WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now at this point in our story, you might think, well, how does that help us
with connectivity,
for example, from this VM over to this VM?
So let's say this is VM one over here and over here, we have VM 21.
And if we want them to be on a common network segment, let's say segment 50
here and be
able to communicate back and forth logically on this one logical segment, how
do we pull
that off?
And the answer to that is we are going to implement gateways and also segments
that are
stretched or common across our multiple sites that are implemented by the
global NSX manager.
So from the global manager, once we create a gateway and a segment, that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So from the global manager, once we create a gateway and a segment, that
segment will
then be available to both of the sites.
So in vSphere and the vSphere client, the administrator can add VMs to segment
50 here
and segment 50 over here at site two and then logically they are on the same
segment.
Now to pull this off, we're once again going to be used tunneling and that
tunneling is
going to be done from the edges at each of the sites.
So for traffic from this VM one to VM 21 and back and forth, that tunneling
would happen
on the edge nodes from site one and the edge nodes here on site two. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on the edge nodes from site one and the edge nodes here on site two.
And for those intersite tunnels between site one and site two, they're not
going to use
their normal tunnel endpoint addresses.
They're going to go ahead and use something called R taps remote tunnel end
points.
So as part of our deployment of NSX Federation, we are going to add an
additional set of addresses
on these edge nodes for the benefit of tunneling traffic between sites.
So that's going to apply to two sites here or we could expand this to three or
four or
ten sites.
In either case, for more tunneling traffic between two sites, that's done using
the
R tap addresses on the edge nodes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R tap addresses on the edge nodes.
And let me clean this up just a little bit and let me show you another way of
looking at
this.
So here is our local management cluster here at site one.
Here's our local management cluster at site two.
Here's our global manager and then from the global manager, we can deploy, for
example,
a gateway.
It could be a tier zero or a tier zero and a tier one, along with segments that
those
gateways are connected to.
And those are stretched or logically available across both sites.
So if we create, for example, a tier zero gateway and specify that we want that
to be
available at site one and site two, those show up and are available at those WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
available at site one and site two, those show up and are available at those
sites in
combination with any segments that are connected to those gateways.
So effectively, we have gateways and segments that are stretched or available
across multiple
sites.
And then the administrator with vSphere Clank can go ahead and associate VMs
with that segment
as their network connection and then boom, these VMs, the one over here at site
one and
the one over here at site two, we'll call that VM 21.
They are now logically connected to the same segment.
And then for traffic between them, the edges would be using their remote tunnel
endpoints
to tell about traffic back and forth. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to tell about traffic back and forth.
And one of the big benefits of having an NSX federation set up like this is
that we don't
have to worry about supporting an excessively large MTU between site one and
site two because
with NSX federation, the actual remote tunnel endpoints can fragment the data.
So the edges don't have to support, for example, a 1700 byte MTU between them.
They can fragment and chop up those segments into smaller chunks and send them
over to
the other edge.
Another big benefit is that because we have site one with its own local manager
and site
two, the zone local manager, as they interact with their own edges, they can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
two, the zone local manager, as they interact with their own edges, they can
use their high
speed connectivity.
And we don't have that requirement of having a less than or equal to 10
millisecond latency
between the global manager and the edges because those edges are still being
managed
by their local manager.
So at the NSX federation, we've just removed that concern because we don't have
the 10
millisecond requirement between the global manager and the edges because those
edges
are being managed locally here by their local managers.
And we also don't need a really big MTU between the edges because of the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we also don't need a really big MTU between the edges because of the
fragmentation that
they're allowed to do with the remote tunnel endpoint addresses.
So that's also been addressed here with the NSX federation.
And I really appreciate the beauty of this.
Here's what you and I get to do.
In the next video, let's put a game plan in place to implement NSX federation
with two
sites and a global manager.
And then with that game plan in place, we can proceed to implement and verify
NSX federation
in this skill.
So I'll see you in the next video, as we put a specific game plan together.