So for our game plan for the NSX Federation,
I already have implemented two sites.
We'll call them site one and site two.
They're all set up.
They have local NSX managers already in place.
They also have some tier zero and tier one gateways in place
and also some local segments already in place.
However, what's not in place is the global manager
in any of the stretched or shared gateway or segments
across those sites.
So as far as the game plan is concerned,
let's go ahead and do some prep work in our topologies WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's go ahead and do some prep work in our topologies
to make sure we are ready for success
with the global NSX manager.
And as part of that prep on each of the sites
with their local managers,
we need to set a default transport zone.
And the reason we need that is because the global manager
is going to look at for each of the sites,
what is your default overlay transport zone
and use that for any common stretch segments
that are implemented by the global manager.
So we want to make sure that site one
and the NSX manager there and that site two,
the NSX manager here that we have identified
our default overlay transport zone. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
our default overlay transport zone.
We also want to make sure that for our NSX management cluster
on each of the sites,
we also want to make sure that we have set up a virtual IP address
because that's what the global manager is going to be interacting
and working with.
And that's a good thing because if we lose one of our NSX managers
in the cluster,
we want the global manager to be able to continue working with that cluster.
So we're going to have the global manager point to the virtual IP address
instead of the actual address on any of the individual VMs
that are in the management cluster.
And we're also going to want to have a backup of our NSX management for site WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we're also going to want to have a backup of our NSX management for site
one
and site two.
In fact, before we can onboard completely with the sites
and the NSX managers in those sites,
it's going to require a backup.
So we're going to take a preemptive strike
and we're going to back up the local managers first
that way we have a backup ready to go.
So once we've done the prep,
we're then going to go ahead and deploy the global manager.
I'll put GM there for short and I'll label it here as well.
There's our global manager and that process for the initial deployment of that
global
manager is very much like it is for a local manager. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
manager is very much like it is for a local manager.
We're going to deploy from an OVF template,
specify the compute resource and the big difference here is when we're
deploying this
NSX manager,
we're going to choose the option of a global manager and not just an NSX
manager.
And that's what changes its role.
So it knows it's going to be a global manager.
So as part of our deployment,
we'll specify it's going to be a global manager.
We also have to specify that it's going to be active.
Now in a production environment,
very similar to what we want to do with our local managers,
we want to have a cluster,
you know,
we don't have at least three inside that cluster for fault tolerance. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we don't have at least three inside that cluster for fault tolerance.
Same thing to true here for the global manager.
So as part of that on this global manager,
it's going to be asking,
Hey,
what is the compute manager?
And the reason it needs a compute manager is for the deployment of the second
and third
NSX managers as part of that cluster.
So my lab environment here,
I'm just going to use a single global manager.
However, again,
if we wanted to create additional global managers,
that's the reason the global manager wants to know about the compute resource
for the second and third.
So once that global manager is deployed,
we're then going to go ahead and add sites. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we're then going to go ahead and add sites.
So in our topology,
we're going to add site one and site two.
And when we onboard these sites,
we're going to specify the virtual IP address for the management cluster at
site one
and put in the details for the authentication there
and a similar process for site two,
including specifying the IP address
or a fully qualified domain name that points to the virtual IP address for the
management cluster at site two,
put in the credentials and onboard that as well.
And then once we've added both sites,
we're then going to import the configurations from both sites.
Also,
just be aware that not every single feature is supported at the global manager. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just be aware that not every single feature is supported at the global manager.
So before you deploy this in production,
you want to take a look and see what features are supported.
And if there's some critical function that you need that's not supported by the
global manager,
you'd want to be aware of that before rolling it out.
So at this point, the global manager would have imported the configs from both
sites.
So our next step would be to go ahead and configure the remote tunnel endpoint
addresses for our edges.
So the edges,
they can still use the same uplink that they're using for their taps.
However, we want to use a separate VLAN. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However, we want to use a separate VLAN.
So for the two edges here at site one for edge one,
let's use VLAN 71 and for edge two, let's use VLAN 72 and over here at site two
for the existing two edges that are currently there for edge one.
Let's use VLAN 81 and for edge two, we'll use VLAN 82.
And as far as IP addressing goes for the VLAN 71, I'm going to use 71 71, et c
etera.
And for VLAN 72, will you 72 72 for the IP addressing for that VLAN and a
similar treatment for VLAN 81 and 82 that way. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
similar treatment for VLAN 81 and 82 that way.
Once it's configured, we can take a look at the IP addresses involved for those
remote taps and know exactly what they are.
Now, once we have that all set up, it'd be wise to go ahead and test it.
So to test it, let's create one single gateway, stretch gateway and let's go
ahead and create a tier one gateway and a shared segment that we can go ahead
and implement across both of our sites.
So this will represent our stretch segment right here and let's go ahead and
call that segment segment 50.
So over here at site one, I've got segment 10 and 20 over here at site two, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So over here at site one, I've got segment 10 and 20 over here at site two, we
've got segment 30 and 40.
So we'll create a new stretch segment called segment 50 that'll be available to
both sites.
And then we can connect a VM here and here to that common segment.
And for this VM here, let's use the IP address of 10.50.0.11 and over here on
this VM over at site two, let's use the address of 10.50.0.22.
So the traffic between those two VMs would go through their respective host
transport nodes who had forwarded to the local edges, who would then tunnel it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
transport nodes who had forwarded to the local edges, who would then tunnel it
over to the other site respectively using the R-type addresses.
And then just for good measure, let's also demonstrate how we can use the
distributed firewall and implement some rules using the global manager to
control the traffic and what's allowed to go between the two sites.
So with that game plan in mind, join me in the next video as we do our initial
prep work on the local managers here at site one and site two.