All right, my friend, it is game plan time.
So let's use an NSX Topology look something like this.
So one of the first steps we want to take is to confirm our NSX Topology.
And then once we confirm that we have this topology in place,
our next step would be to go ahead and deploy the advanced load balancer.
Now, VMware bought this advanced load balancer from a company.
And so if you see AVI, that's simply the previous company's name.
So that still shows up a few times.
So we'll deploy the advanced load balancer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll deploy the advanced load balancer.
It is an OVA.
So we'll deploy that in vSphere.
We'll find a nice home for it for a compute resource.
And the actual file is an OVA file.
So now that I've mentioned that, we can go ahead and just as our tasks,
say deploy the advanced load balancer.
And for management for that advanced load balancer,
let's put it right here on the 10-10-30 network,
which is segment 103-ALB management.
That's the name of it, inside of NSX.
So that'll be the management network for the advanced load balancer.
So its IP address will be .15. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So its IP address will be .15.
Now also in the topology, I have this 192.1 state one network.
And that's my management network for all of the vCenter and NSX stuff.
So I have the NSX controller right there.
I've got the vCenter right there.
So the vCenter is at .35.
And my NSX manager is at .21.
In fact, let me just clean that up and write that a little bit better.
And so to facilitate communications between the advanced load balancer here
we're going to look down on segment 103 and these two devices,
instead of trying to train both of these devices on how to route back WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
instead of trying to train both of these devices on how to route back
through this tier one gateway, I'm going to go ahead and simply set up a little
reflexive NAT right here that says, "Hey, dear Mr. load balancer,
if you're ever going out to the 192.1 state one network,
I'm going to net you out to .15 on that network."
And that way as the vCenter and the NSX manager communicate and talk to the
load balancer,
those will think he's coming from 15.
So the load balancer here will be at .15 on the 10.1,
0, 3.0, 0 network.
And again, it'll be netted to 192.1 state one .15 for the benefit of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And again, it'll be netted to 192.1 state one .15 for the benefit of
communicating
with the vCenter and the NSX manager up here.
Now part of the job of the controller is to deploy the service engines
wherever they're needed based on the topology we end up creating.
And so to do that, there needs to be a content library up here on the vCenter
where the controller can actually place the image is going to use
to deploy the SEs.
And that way if it needs to deploy an SE over here or somewhere else,
it can leverage the content library in the vCenter.
So one of our steps here is to create the vCenter content library. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So one of our steps here is to create the vCenter content library.
And we don't actually have to put anything in that library.
The controller, once it's all set up,
will automatically place the images needed in the content library.
Then once the advanced load balancer is deployed and we can reach it at .15,
we need to take care of the licensing issue.
And with the current version, I'm using, I think there's like a 30 day window
for an actual trial once you deploy the controller.
So we'll make sure that that license is active and available for us. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll make sure that that license is active and available for us.
We can actually work with the controller down here.
Also, because this controller is going to need to log into the vCenter
and also to the NSX to interact with them,
we also need to create the credentials here on the controller
that it can use when we tell it to go ahead and start logging into the vCenter
and to the NSX respectively.
So here at the advanced load balancer controller,
we're going to go ahead and create what are referred to as credentials
that we can then use to log into the vCenter and the NSX manager.
That also means that we need to know what those logging credentials are. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That also means that we need to know what those logging credentials are.
So it can log on to the vCenter and to NSX.
And in a production environment,
instead of logging on with King Kong writes,
for example, like admin at the vCenter and NSX,
it'd be better to go ahead and carve out unique user accounts
with the correct roles associated with them.
And that way, when the advanced load balancer is interacting with vCenter
and NSX, the credentials it's using aren't the full admin writes,
but instead using just the rights that are needed.
So for the lab environment, though,
I'm going to go ahead and simply tell it to go ahead and log in with the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm going to go ahead and simply tell it to go ahead and log in with the
credentials
for admin on both those platforms.
With the warning that in a production environment,
you might want to scale that back and log in within the count.
That just has the rights that are needed.
And as far as what roles would be needed and so forth for the accounts
on the vCenter and on NSX, those are spelled out meticulously.
In the documentation for the advanced load balancer.
So in a production environment, you get that documentation,
walk through step by step and set up the user accounts that are needed
just for the access that's needed.
So then our next step would be to go ahead on the advanced load balancer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So then our next step would be to go ahead on the advanced load balancer
and create the connection to our NSX environment.
This is going to leverage the username and password so it can log in
and start interacting with the vCenter and the NSX manager.
So we'll create a cloud connector on the controller to our NSX environment
and as part of building and setting up that cloud connector to the NSX
environment,
it's going to ask us a lot of questions, including who is your vCenter?
How do we reach it?
Who is the NSX manager? How do we reach it?
It's at that point, by the way, we would use the credentials we'd set up
to go ahead and log on from the controller to those two platforms. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to go ahead and log on from the controller to those two platforms.
It's going to ask us what's the management network.
So we'll specify for the management network that we want to use the
THEG 103 for the management network.
There's currently DHCP services here.
So these little service engines, they can get an IP address automatically.
So that management would be part of the control plane.
And it's also going to ask us about the data plane, meaning where do we want to
implement the function of load balancing.
So as far as options here in our topology, we could use some servers here
out on VLAN 5 or we could use some servers here on segment 101. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
out on VLAN 5 or we could use some servers here on segment 101.
In either case, I'm going to have to put the servers there.
So it'd be easier, I think, to go ahead and use another overlay segment
that way I can just pop VMs in here, set them up for HTTP services
and the way we go.
So let's go ahead as far as our game plan goes and specify that this will be
the data plane off of tier one left.
And specifically off tier one left here, let's go ahead and specify segment
101 for the data plane.
So once that's all set up and once it's all fully deployed, our service
engine that's being used would have one connection here for the management WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
engine that's being used would have one connection here for the management
network.
And then the other interface here would be for the data plane.
So once the cloud connector is all set up, we all need to at the advanced load
balancer.
We need to specify the virtual service that we're going to use.
So let's create a virtual service for our web servers and for the virtual IP
address
associated with this web service.
Let's use 10.101.0.5.
So that IP address won't be used by any of our little VMs here.
There'll just be a virtual IP address associated with this service that the
service engine
as part of the data plane will be listening and waiting for requests to come in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as part of the data plane will be listening and waiting for requests to come in
at that address.
And then as part of our configuration, let's also configure a pool of servers.
And for our pool, let's use that same subnet.
Now these servers don't have to be on the same exact subnet.
They could actually be on a different subnet somewhere else.
But for the lab environment, let's go ahead and some of these the same segment
for our pool of servers.
So let's use for the servers.
Let's use .51 and 52.
And if we want, we can go ahead and bring in a 53 as well.
Those would be the real IP addresses of our three servers, but the customers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Those would be the real IP addresses of our three servers, but the customers
would come into the 10.1.0.1.0.5 address
and then the load balancer, specifically the service engine as part of our
advanced load balancer
would then proxy the request to one of the servers that is up and available.
Now, if we were talking about connectivity from the public internet, we could
also do
destination NAT right here that says, OK, traffic coming into, for example, 23.
1.2.90
or whatever addresses available to us from a service provider, we could go
ahead and do destination NAT WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ahead and do destination NAT
down to 10.1.0.5.
And then when that destination NAT happens, that would go down to the virtual
IP address
associated with our virtual service, at which point the service engine acting
as the load balancer
function on the data plane, we then proxy that request to one of the available
servers.
However, because I realized we want to keep this lab to somewhere in the 45
minutes to
hour and 15 minute range, instead of also dealing with that, let me go ahead
for testing.
We can just test it from my management computer over here or from some other
system by just
going to the IP address 10.1.0.5. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to the IP address 10.1.0.5.
And then the load balancer will spin us off to one of the back end servers.
[BLANK_AUDIO]