Hi there, and thanks so much for
stopping by today.
My name is Bradley Knapp with IBM
Cloud. And the question that I
wanted to go over with you guys
today is what is a network
load balancer?
And so I want you to imagine
a scenario, right?
You have decided that you are going
to run a website and this website
is going to be immensely popular.
You need to build it to scale to
serve millions of users,
all of whom are accessing it at the
same time. So imagine
that single user and what
is his experience going to be?
Right.
So you've get your guy, he's
out here and he's got
a laptop.
Right. And so on his laptop, he
wants to open your awesome
new website. So he's going to send
that traffic out into the
Internet, which we're going to
put a little cloud in there for the
Internet.
And then is it transmits through
the Internet to the actual servers
where the data is hosted, it's
going to get down here, and it's
going to get to an application
server. And that application server
is going to be what actually serves
all of the data back
via the Internet to his laptop
so that he can view what's going on
on your website.
Now, that's fine.
If you've just got one person who
accesses your website at a time,
what if you have ten people at once?
Well, that app server is probably
going to be fine to do that.
What if you have 10000 people
who are accessing it at once?
And so that's when you get into
these interesting scenario
where you can saturate
out this application server.
And so if you think about an
infrastructure level definition of
an app server, you can scale them up
to a certain size, but
you've got limits in how big these
application servers can be.
So what do you do?
All right. Well, you need to scale
them out, right?
Instead of having one app server,
you might have three or you might
have four, or you might have five,
or you might have 10 or you might
have 10000.
You were going to horizontally scale
those application servers
so that you have enough to
satisfy your customer load.
But how do you know how much
scaling you need?
And more importantly, how does this
guy with his laptop get
to the application server that he
needs in order to be successful?
And the answer to that is in between
your
customer and all of your
app servers, you are going
to put a load balancer.
What is a load balancer?
It's a hardware device, or it could
be a software defined device, and
that load balancer is going to
intercept all of the
traffic that's coming in from the
Internet. And it's going to decide
what goes to this server, what goes
to this server, what goes to this
server, and so on, and so
forth.
It's also going to provide and
collect information.
So your application servers down
here, they can be talking to this
load balancer. They can be saying,
hey, I'm only being used
20 percent of the time.
Maybe you don't need me right now.
And that load balancer can then
dynamically scale, or auto
scale, and turn that application
server off if you don't need it -
helps drive down costs.
Likewise, if all of your app servers
are checking in and they're saying,
hey, I'm super busy, I'm running at
85, 90 percent utilization,
it's time to bring in help.
Then that load balancer can hit that
auto scale service again and can
say, hey, look, I need another one.
I need another app server to try and
decrease my load.
And so when folks talk about cloud
native architectures, this is a
key component. The load balancer is
a key component because that load
balancers going to assign out that
traffic to all of the different
application servers, and
then the app servers, they're all
going to go down here and they're
going to talk to a common database
tier because you don't want to get
into a goofy split brain scenario
with your database.
But they're going to get
the data that they need and they're
going to serve that back up to the
end customer directly.
So that's how you split up
the data.
That's how you serve it up.
But so now that we're in load
balancers, we said it's going to
decide which application server
gets the traffic, right.
How does it decide what to
do? And so let's get our three
most common scenarios right.
So we're going to go over here and
we're going to have scenario one,
scenario two,
and then scenario three.
So scenario one:
our load balancer right here,
right, it's got all its app
servers and
we're going to call this one a
relatively dumb load
balancer, right?
We don't need a lot of complexity in
it. It's serving a fairly basic
purpose.
And so it's going to use an
algorithm called Round Robin
in order to assign
the traffic.
And so what does Round-Robin mean?
It means that for the first user
that connects, it's going to send
that person to App Server 1.
For the second person who connects,
it's going to send them to
App Server 2, the third person
who connects is going to go to
App Server 3.
And then when the fourth one comes
in, it's just going to start back
over again.
Round-Robin literally means just
going sequentially through it.
Now, Round-Robin is not a perfect
scenario.
If you have user sessions that last
a long time, some people log
in and run for five
minutes. Some people log in and run
for two hours.
Your app servers can get out of
balance with one another when
you're using that round robin
scenario.
And so then you need to think
about things like smart load
balancing. Smart load balancing is
going to be our second piece here.
Right. And this is an application
server load-aware
load balancer.
So again, just like before, we've
got our load balancer here and
we've got our app servers.
But this
scenario, this smart load balancing
scenario, rather than the
load balancer just acting as
king and directing what all happens,
the load balancer works in
cooperation with the application
servers. So the app servers are
constantly transmitting data
back and forth to that load
balancer, letting them know how
busy it is and
that load balancer's then going to
make the decisions to send the
incoming connections.
So your guy over here, if
he comes in and he starts
a user session, that load balancer
is going to say, look, server three
has the least load on it right now.
I'm going to sign him over here.
And it's constantly monitoring that.
Now, obviously, you're going to look
at that and you're going to say, well,
why wouldn't you always use this
kind of setup?
Well, it is more complex
to get set up initially, right?
It takes more configuration.
Also, the load balancer software
or the hardware device that you use
to set this kind of a scenario up,
it is more expensive.
And so while technologically
it's probably always the best choice
for your specific scenario,
it might not be.
And then the third scenario
that we've got down here.
Right. So we've got our load
balancer and all of our app servers.
This is a scenario where you want
a little bit more control
than you do in just a straight round
robin, but you don't want to go all
the way through the set up and
config and everything like that that
you need with a smart load balancing
scenario.
And so there are actually like
nine different algorithms that you
can pick from that split the
difference between these two.
The one that I'm going to use
right now as an example is a
random select, right.
So the load balancer, rather
than sequentially working through an
application server.
One, two, three, one, two, three,
one, two, three, over and over
again. It's just going to run a
randomizing function and it's
going to decide that may be the
first to go to one.
And the third connection goes to two
and connections four through six are
going to go to three and so on and
so forth.
Again, it's just it's different
kinds of algorithms to decide
where you need to go, where you need
to send that traffic.
And if you want to get into
specifics, there's tons of
information out there.
I'd be happy to share that with you.
Let us know in the comments.
If you want to know specific advice,
please feel free to reach out to
anybody in the channel or anybody at
IBM. We'll be glad to help you
design an architect, a load
balancing solution that is going to
work to help you solve
the needs of your customer.