So now that we have our virtual service set up here with
the virtual IP address of 10, 1, 0, 1, 0, 5,
and I have these three servers on the back end that are up and
ready to go on that segment,
we could test this by having a client connect to the virtual IP address of 10.1
, 0, 1.0,
0.5, which is associated with our virtual service,
and then the service engine should go ahead and be able to proxy those requests
down to one of the available servers.
So before we ask you to test, let's head over to the controller.
Just to confirm that those three back end servers in the pool are reachable and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Just to confirm that those three back end servers in the pool are reachable and
appear as available.
So back here at the controller interface for the load balancer,
the top left tab of applications is selected and the dashboard is selected by
default,
and here is showing us our web app.
Now the yellow is better than all red, so that means that our health score is
68.
And so those points off, for example, if my web servers have been up for a long
time,
in fact, this is showing the health score for the past six hours.
And as they continue to be up and available or time, that health score will WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as they continue to be up and available or time, that health score will
improve.
So we can either click right here on this virtual service,
and that would take us to the details of it, or we could click care in the
virtual services,
and it would list it, and then we could click on it here.
So let me move this little mini topology out of the way.
And let me remove a couple of columns so we can see it better.
I'll click on the gear here.
So let me remove a few of those and click on save.
And for a little more room, I'm going to go ahead and push the left-hand column
over.
So for this service, which is went up a little bit because those servers are
now up,
it has a health score of 71.
It's supporting a service port of 80 and check this out. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's supporting a service port of 80 and check this out.
Total service engines.
It has one service engine at the moment that's supporting that and doing the
actual data plan work.
So if we were to expand the left-hand side here, and if we went back to
infrastructure,
then the left here is our cloud.
And on the left below that, if we go to cloud resources and click on service
engine,
here's showing us all of our service engines, and that's for the default cloud.
So we use the dropdown.
Here's our NSX cloud.
And currently we have two service engines.
One of those is being used to support the load balancing for those servers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
One of those is being used to support the load balancing for those servers.
And the default method it uses for calculating how many actual service engines
to use is called N plus M.
So if each of these columns represents a service engine.
So each service engine can support one or more virtual services.
So let's imagine we configured our services engine so they can support one, two
, three, four, five virtual services
per service engine.
And furthermore, let's imagine that we had 15 virtual services configured and
running.
Also, if you notice in the background, our health score continues to improve. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Also, if you notice in the background, our health score continues to improve.
The longer those backend servers are up.
So if we have 15 virtual services that are set up, the calculation that the
load balancer does
is 15 divided by how many could be supported by a single SE.
So if each of our SEs can support five virtual services, that equals three,
which is the end part of the equation, and then for fault tolerance, we want to
add one more.
That's the M part of the equation.
So for the controller to calculate how many SEs are needed, the formula would
be for 15 virtual services
or each service engine can support five of those. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or each service engine can support five of those.
We'd need a total of four service engines to be deployed.
So let's go ahead and do 15.
There's one, two, three, four, five, six, seven, eight, nine, 10, 11, 12, 13,
14, 15.
And again, this calculation of four here is the number of virtual services
divided by how many virtual services each service engine will support plus one
more.
So with this formula, the load balancer would deploy four service engines
because that gives us fault tolerance. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because that gives us fault tolerance.
Because if we lost one of our virtual machines, one of our service engines,
and it was supporting four of the virtual services, those virtual services
could then be deployed here.
There's one, two, three, and four.
And one cool thing about the controller is that it will automatically deploy
additional SEs
to support the load and using the N plus M option is going to deploy enough.
So if it loses a single service engine, it can still have fault tolerance
when it moves those virtual services over to other service engines.
And if this service engine really did go down, it then also start the process WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if this service engine really did go down, it then also start the process
of bringing up another service engine.
So once again, we'd have fault tolerance.
And again, our score is getting better and better here.
So if we go back to applications and virtual services
and we click on our virtual service here, as the service engine
starts to begin doing load balancing and forwarding traffic on the data plane,
that'll show up right here.
So also we can hover over this virtual service right here.
And it'll show us in the pop up exactly who the current service engine is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it'll show us in the pop up exactly who the current service engine is.
Right here, showing us it's the our NSX lab, AVI, SE, IZ, V, S, G.
That's the primary service engine that's currently supporting this virtual
service.
Here's the service port.
Here's the virtual IP address associated with this virtual service.
Also right here, if we wanted to go ahead and scale out effectively,
use additional service engines to support this virtual service,
we can click scale out right here.
And then if you have multiple virtual IP addresses associated with the service,
you choose the one you want to scale out for.
And then you can specify where you want to scale out to. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then you can specify where you want to scale out to.
So that's our other service engine.
Or we could say, you know what?
I want to create a whole new service engine.
So here, if we check that box and said create service engine
and click on scale out a way it goes, the controller is in the process
of deploying a brand new service engine because we asked it to.
So if we go back to the vSphere client and look at running tasks,
here's in the process of deploying yet another service engine.
And it'll put in that same folder, AVI, SE folder right there.
So if we want to take a peek, we can open that up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we want to take a peek, we can open that up.
And sure enough, there's our third SE being deployed right there.
All right, before we send some traffic through,
let's go ahead and edit this virtual service.
So I'm clicking on the pencil for the virtual service.
And then here we have some sub tabs for analytics.
I want to go ahead and log all headers for the lab.
And also I want to do logging for non-significant logs.
And for the zero here for the duration,
it means it's going to do logging indefinitely
regarding non-significant logs.
So that's a lot of detail that we can tear into. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's a lot of detail that we can tear into.
So initially, if you're setting something up
or need to look at the details,
you can turn logging all the way up to get more information.
So with those logs enabled, let me go ahead and click on save.
And then I'll go ahead and say, please display for the past 30 minutes.
So let's generate some traffic that's going to go through the load balancer.
So my management computer is over here at .151 on the management network.
And I have a specific static route that says,
hey, dear Mr. Management Computer, if you need to get to 10 anything,
go ahead and use this interface right here on the tier one right gateway, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
go ahead and use this interface right here on the tier one right gateway,
which would then route it over to the T0 down the T1 left,
and down here to where our virtual address is.
So the address that we're going to hit is 10.101.0.5.
That's the virtual IP address being supported by the virtual service.
And then on the back end, we have three servers that are available.
And once we start sending some traffic through, if we go to logs,
we'll have a little bit more to look at right here.
So currently it says no logs available for this time frame and filters.
And currently I'm looking at the last 15 minutes.
So let's generate some traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's generate some traffic.
So what's happening is for my client,
I'm actually going to the IP address 10.101.0.5.
And then we have the load balancer right there,
who is then forwarding off to one of our three servers.
So at the moment, it's taking over 2.53.
So I intentionally made the web page a little bit different on each of the
servers,
just so it shows visually which server we're connected to.
So if I do a control shift R a few times,
it should take us eventually to one of the other servers.
So now we're at .52 and you're going to do, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now we're at .52 and you're going to do,
let me go ahead and change the policy and have it round Robin.
And that way we can go around the horn.
So here for our virtual service,
although I didn't select it and we'll edit and we'll scroll down.
So here's the name of the service.
Here's our virtual IP information.
If we scroll down, we could go down to the pool.
Here's our web app pool.
And let me go ahead and edit that.
And I'm going to change the default policy for how it's making a choice.
So here for the pool, if we click on servers,
here it's showing us the servers, if we get a health monitor.
So here for the health monitor, if we didn't want to do a system HTTP health WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here for the health monitor, if we didn't want to do a system HTTP health
check,
we have some others we could choose from,
including just doing a ping.
And that way we wouldn't be validating whether or not HTTP was running.
So I'll leave that in place.
But what I do want to change is how we're choosing which server we're being
spun off to.
So that is right here, the load balance algorithm.
So let me change that instead of saying lease connections,
then I go ahead and choose round Robin.
So what that should do every time we do a forced refresh,
that should send us off to get a different server.
And that way we can verify we're going to all three as a property of our pool WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that way we can verify we're going to all three as a property of our pool
of three servers.
So we'll click on save, click on save again, and let's go back to my browser.
So here at the browser, we're currently at server dot 52.
And then you go ahead and do a refresh.
So then we're at dot 53, I'll do a control shift R.
So I'm going to do a control shift R and just keep doing that.
And sure enough, the cycling is through round Robin through all three servers.
And if we were to take one of the servers out of the mix,
for example, this is the little web server at dot 53. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for example, this is the little web server at dot 53.
So if I just turned off the web service here and I'll do that with a quick
click right there.
So in the background, because the health monitor is actually checking for HTTP
services,
after just a very short period of time, the load balancer, the service engine,
should realize, hey, dot 53 is no longer available.
And that way we just round Robin for the remaining two, which should be dot 51
and dot 52.
So they move that out of the way.
Let's go back to my browser, let me do a control shift R and let me just cycle
through what's left.
So there's 51 fantastic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So there's 51 fantastic.
And there's 52.
And as we continue cycling, there's 51 again.
And there's 52.
And it's not even trying 53 anymore because that has failed to health check.
And as a result, the service engine is no longer proxying down to that third
server
because that server is not passing the HTTP based health check that it's doing
periodically with that server.
So now if we go to applications and virtual services, notice now we have two
services engines
that are supporting our virtual service.
And that's because we told it to. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's because we told it to.
And if we click on this virtual service here, it's showing us some end to end
timing by default.
But the real magic is in the logs.
So here with logs like that, and I opted in earlier to see the updated version
of how they're presenting logs.
I'm going to say I want to see the non-significant as well as the significant
logs.
And then here are all the entries.
So let's go ahead and grab one of these.
I'm going to collapse the right hand column.
And let me go ahead and click on the eyeball next to this one right here.
So here in the summary, if we just scroll down, it'll take us to the
application and headers respectively. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
application and headers respectively.
So here it's showing us who the client was.
The client was .151.
That's my management computer.
According to this virtual IP address, then the service engine did the proxying
from its IP address
over to the web server.
In this case, use .51.
And this is the specific service engine that did the work.
And it also has the latency for the round trip time between the client and the
load balance.
So here's the answer between the load balancer and the server.
And then we scroll down.
It'll take us to the application and headers.
It has a summary, including where the client came from.
So as running Windows, that's true. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So as running Windows, that's true.
I was using Chrome.
That's true.
Here's the user agent involved.
And if I scroll down, here's the application information.
It was a get request.
We'll scroll down.
Here's the header information.
This is the header as it came in from the client to the load balancer.
And this is from the load balancer over to the server.
And as we continue to scroll down, here's the response.
This came back from the server to the load balancer.
And then from the load balancer back to the client.
So we'll go ahead and close that.
And for this virtual service, if we click here on help, it'll give us details WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And for this virtual service, if we click here on help, it'll give us details
about
its help score and why it got that.
It can give us information based on the source of where those clients were
coming in from.
There's a tab for security and events and alerts.
So if we click here on pools, that can also give us an indicator regarding how
many servers
are available.
So this is showing two out of three on the back end are available.
So if we were to bring back in the third web server, which I turned off here a
moment ago,
and I turned it back on.
So now the web service is running the health check, which is verifying whether
HTTP services
are running or not on the system. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are running or not on the system.
That health check should come back with two thumbs up saying, you know what,
this server
is back up and running.
And this number, which it just did, should change back to three out of three
now being
available.
So if we went back to the browser and now we did a control shift R a few times.
Now it's including dot 53 in that mix because we set it up for round Robin.
So there's 52 with a control shift R, there's 51 and there is 53.
Also when you're working with a load balancer and you're testing it, just be
critically
aware that there's a lot of caching that can happen locally at the browser. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
aware that there's a lot of caching that can happen locally at the browser.
So one technique that you could also use is to use curl right here from the
command line.
So we could go ahead to the virtual IP address 10, 101, 0.5 press enter and we
're going to
get a response and although this test doesn't tell us exactly which back end
server we're
going to, it does verify that we're getting a response from one of the servers.
So as a quick wrap up here in the controller, if we go back now to
infrastructure here on
the dashboard is showing us three service engines that are currently out there
because
it deployed to automatically and then we told to bring up another one. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it deployed to automatically and then we told to bring up another one.
And as long as everything's working, including the servers on the back end are
available,
these health scores should continue to improve.
So if we opened up cloud resources here and clicked on service engine and then
we picked
our cloud, which is our NSX cloud right here.
There's our three service engines and then we want to see more details
regarding that
service engine.
We could go ahead and simply click on its name right here and then regarding
that specific
service engine, we have a whole bunch of tabs, including help and BDP peering
and events
and alerts and an option for traffic capture. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and alerts and an option for traffic capture.
And if we went back to applications and clicked on virtual services and then
selected our
virtual service.
Again, tons of great detail here regarding how that virtual service is doing,
including
options for the log health clients, et cetera.
And then regarding this graph right here, if you want to see details for
throughput,
you simply click there, it'll highlight that for us and in timing, it'll
highlight that
for us to give us that information.