To really appreciate the concept of a load balancer or sometimes called an
application delivery controller,
I'd like to take you back in time to the good old days, maybe 20 or 25 years
ago.
Back in those early days, if we wanted to put a server on the internet, we'd go
ahead and get a physical server,
we'd install some software and connect that to a network.
So here's our server and here's our network segment and let's give the server
an address of 10.101.0.5.
And then for connectivity out to the internet, let's go ahead and put a simple WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then for connectivity out to the internet, let's go ahead and put a simple
firewall from a few decades ago,
providing stateful firewall services. It's also connected to this network and
let's imagine this is at .1.
And then that firewall is connected to a service provider who is allowing
further access into the internet.
So we have a connection there as well. So maybe this is 23.1.2.9 or whatever
its IP address is.
And then this device we're doing network address translation.
And specifically for customers out here on the internet, let's put a client out
here.
For this client right here, to get access to the server, we would use something WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
For this client right here, to get access to the server, we would use something
called destination NAT.
So perhaps for the server, we have a reachable address of 23.1.2.5 on the
public internet
and that maps through the firewall to this server right here.
So that way when the client does a DNS lookup and they go to this IP address,
that traffic goes through the firewall with the station NAT down to the server,
who can then go ahead and respond back.
Now, one of the problems with the situation like this is what if this server is
taken offline or crashes or simply goes down. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
taken offline or crashes or simply goes down.
The client who's trying to get to this address and as that address is going
through the firewall,
that server is no longer available to the client. We now have some downtime.
We have an out-of-service issue where this server and its contents are no
longer available to the clients.
So what can we do to help with the fault tolerance and resilience in the world
of having this server be available even in the event of a failure?
Well, I'm glad you asked. What we can do for our servers instead of just having
one server,
we can have two or three servers. So let's imagine we have these three servers
here connected WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here connected
and there's the 10.101.0.0 address space here in our private network.
And let's imagine this guy is at .51 and this guy is at .52 and this one is at
.53
and they all have the same exact content available on them.
Another way of saying that in current terms would be saying they all have the
same application running.
So no matter which server the client goes to, they're going to have the same
experience.
However, we don't just want to have the firewall do kind of a round-rod
approach to the servers because we also want to make sure
that the server that the firewall is forming the traffic to is really online. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that the server that the firewall is forming the traffic to is really online.
So here's what we're going to do. We're going to make this network segment a
little bit longer
and we're going to go ahead and draw the icon that can represent a load bal
ancer.
So let's imagine this load balancer appliance is at the IP address, say .5.
Then we have the firewall do the destination now so that 23.1.2.5 when
clients go to that IP address, that global IP address, the firewall can net it
over
to this address right here of the load balancer.
And then behind the scenes, this load balancer, it hasn't just been sitting
there,
it's also been checking on the health of these three servers to make sure they WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's also been checking on the health of these three servers to make sure they
are really up and ready for business.
So as the first client request comes in, this load balancer can then proxy that
and send the first one, for example, over to .53.
And then if another client comes in, the load balancer can say, you know what,
the next one is going to go to .52.
And then the third client comes in and that third request can go over to .51.
So the load balancer is acting as a proxy in between the clients and the actual
services.
So in the event that one of these services goes belly up, it's no longer
available,
it's not responding back to the load balancer for the health checks. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's not responding back to the load balancer for the health checks.
Let's go ahead and let's take this one out of commission.
For future requests that come in, the load balancer, knowing that .53 is no
longer up and available,
can simply use the remaining two servers as part of this pool of servers.
So if I clean this up a little bit, we could redraw it like this.
The clients would connect to the load balancer and then the load balancer could
go ahead and proxy
those requests from the clients down to the servers that are available.
And so there's actually two sessions in play.
There's a session between the clients and the load balancer and another session WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There's a session between the clients and the load balancer and another session
between the load balancer and the server that the client is being served from.
Now there's lots of benefits of having a load balancer, including the fact of
fault tolerance.
We have multiple application servers serving up the same content and if one of
those servers
becomes unavailable, it won't be a big deal because for future clients coming
in,
they can still get to the remaining servers because the load balancer is
intelligently
checking in the background to make sure the servers are up and running.
Another cool benefit of having a load balancer in the middle between the client
and the servers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is that because we are looking at all that traffic and in the path for all that
traffic,
there's a lot of opportunity to do things like web application firewall or to
do protocol inspection
to confirm that clients aren't trying to harm our systems or that their
protocols are using
are correct. We could at the load balancer decide on the method that we want to
go back and forth
between various servers, which could be based on least number of connections
for any of these
servers at the moment or we could do it on a round robin fashion or we could
have based on the type
of client and the browser type that's being used based on that directed to a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of client and the browser type that's being used based on that directed to a
specific server or a
specific pool of servers. So we can inspect that traffic and redirect that
traffic based on a set
of conditions. We can also do inspection and interception of SSL slash TLS. So
as clients are
coming in, for example, with HTTPS, we could go ahead on the back end and
simply use HTTP. Now,
there are pros and cons of using HTTP and our data paths because there's an
opportunity for
unencrypted traffic. And the cool thing is that because that load balancer is
here in the middle, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here in the middle,
depending on the licenses and the features that are supported, there's a lot of
opportunity for
analysis and control of the traffic as it goes from the clients to the servers.
And this concept
of a load balancer isn't just for clients to servers. We could also do it from,
for example,
web servers over to database servers or to some other application inside the
data center.
And as I mentioned on some vendors, they refer to it as an application delivery
controller. For
example, think of a web application or database application or DNS services
application and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
application and
having the load balancer intelligently forward or control the traffic between
the parties requesting
the information and the systems providing the service. Now, inside the world of
NSX, there is a
built-in load balancer functionality that we can use. However, that is being
phased out. And
instead of using the load balancer is built into NSX, VMware is moving towards
using the advanced
load balancer for virtually everything that needs load balancing. And one of
the reasons that they're
moving to that is because the advanced load balancer besides its features, it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
moving to that is because the advanced load balancer besides its features, it
supports, is also able
to do load balancing on lots of different environments, including NSX, Google
Cloud, AWS,
Microsoft Azure, and more. And it can do this with the concept of a cloud
connector.
And let me introduce you to a few of the pieces involved as part of the
advanced load balancer.
There's the brains of the operation, which is deployed as a VM. And that is the
icon right here.
And that is our controller for the advanced load balancer. And as the name
implies, we can think of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
implies, we can think of
the controller as the control plane for our load balancer. And then on the data
plane, the actual
component that takes the request from the clients and forwards it to the
appropriate server or to
the appropriate application, that's performed by another set of VMs. And those
are called SEs.
And SE is an acronym for service engine. And one of the benefits of having
these service engines
for the data plane for the actual taking the request from the clients, then
forward it to the
right server is that these little service engines running as VMs can be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
right server is that these little service engines running as VMs can be
deployed on demand wherever
they're needed. So if it's an NSX cloud environment, we can deploy them inside
of vSphere. If it's a
AWS or Google Cloud or Microsoft Azure, once again, we can deploy logical
service engines
wherever they're needed for the data plane. The key behind it is just use the
correct cloud
connector or cloud connectors plural to allow the controller where we have it
deployed to interact
with those various environments. Again, AWS Google Cloud, Microsoft Azure, or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with those various environments. Again, AWS Google Cloud, Microsoft Azure, or
here in an NSX
environment, there's also a cloud connector just for vSphere. So you can
actually have a load balancer
in vSphere that can interact with your standard industry, the switches inside
of vSphere,
even without NSX. So again, it's super flexible based on the concept of a cloud
connector.
So let's imagine one of these service engines is providing the data plane
between the clients
and these servers. Or another way of saying that is between these clients and
these applications.
Again, maybe it could be a web application or database application or DNS WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Again, maybe it could be a web application or database application or DNS
application, etc.
So a service engine would take the responsibility of that data plane. So one of
these service engines
or multiple service engines, depending on the load would be right here. So here
is our service engine
or SE for short. And what's exposed or available to the client is known as a
virtual service.
And associated with that virtual service would be an IP address, for example,
that's reachable by
the clients. And in combination with that IP address, there's going to be some
profiles and
details such as the ports involved. So that way when the client connects to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
details such as the ports involved. So that way when the client connects to
that IP address and to
that respective set of ports, the service engine as part of the data plane for
the advanced load
balancer can then make its decisions about who to hand it off to. So also here
in the service
engine, we're going to have a pool or pools of resources, for example, these
servers right here
that we're not only aware of, but we can also do health checks against them. So
if these three
servers represent web services, we could in our health checks do a check to
validate that the
HTTP services up and running, for example, make a quick HTTP request and look WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
HTTP services up and running, for example, make a quick HTTP request and look
for a specific
response in those requests to verify that they're up and able to serve up that
application. So in
the background, that's happening all the time. And that way the services engine
knows exactly which
of the servers in the pool are available when client requests come in so that
the service's
engine can proxy that request over to a server that is currently up and
available. So once again,
we have two sessions, one from the client to the virtual service, and then yet
a second session WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a second session
between the service engine and the server itself. So I put those in a slightly
different color. So
there is leg one of our journey. And here is leg two of our journey and the
return path would go
from the server back up to the services engine and then back out to the client.
So here's what you
and I get to do. This is super exciting. What we're going to do is put a plan
together regarding
what we want to implement regarding the advanced load balancer. And because
this is part of a
bigger NSX course, let's create the advanced load balancer will deploy the
controller,
and then we'll create a cloud connector that connects over to our NSX WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then we'll create a cloud connector that connects over to our NSX
environment. And that way
you and I can actually implement the advanced load balancer as part of our NSX
environment.
[BLANK_AUDIO]