The load manager may be operating at the
network level, that is, at the network layer
level of the seven layer OSI reference model.
In this case, the load manager is simply a
round robin domain name server. What it does
is, when client request comes in, they all
have the same domain name, in order to
come to this particular server. If you say gmail.com,
then depending on how the server is architected, the
gmail request coming from particular client may go to a
particular site. And when it goes to that site,
the domain name server, which is acting as a load
manager, what it is going to do is, it is
going to direct the incoming client request to one of
the servers. So it is giving different IP addresses.
Even though the domain name a client is coming in
is exactly the same, the round robin DNS
server assigns different IP addresses corresponding to different
servers to the incoming client request. And that
way these clients are being redirected to different
servers, and because the load manager is doing
it at the level of individual server addresses,
you get very good load balance. And the
the inherent assumption in this model, is that all
the servers are identical, so an incoming request can
be sent to any one of these servers, and perhaps
the model is also that the data is fully replicated.
So that if an incoming request goes to this server,
it has access to all the data. If it
goes to this server, it has access to all the
data to satisfy the incoming client request. So the pro
is good load balance because the Round Robin DNS scheduler
can choose the least loaded server to
redirect an incoming client to that particular server.
But the con is, it cannot hide down
server nodes, because it is assigning IP addresses
of the server to the incoming request, the load manager is not able to hide down
server nodes from the external world. So now we move the load manager up in the
OSI reference model. Up to the transport
level or even higher. The load manager could
be layer four switches. That is transport level
switches or even higher level switches. And, in
fact, the layer four switches may be
architected as switch pairs so that there is
hot fail over from one fail switch to
another fail switch at the load balancer lever.
When you do this architectecting the load
balancer at the transport or higher levels.
It give you the opportunity to dynamically
isolate down server nodes from the external world,
and it is also possible, with this
architecture of load manager, to have service specific
front end nodes. For example, instead of
dealing with arbitrary client requests, we're actually dealing
with requests based on the kind of requests
coming in from a particular client. For instance,
this could be a Gmail client. This could
be a Google search client. This could be for
a photo server like Picasa. So those are
different functionalities that can be implemented at the
front end of this load manager to look
at the service, the particular program, that is actually
triggering a client request coming in to this
particular site, and make decisions as to who
should serve that particular request. So in other
words, we're building more intelligence into the load manager.
So that it can know the semantics of
the client server communication that is going to happen based
on the type of request that is coming
in. And it is also possible, with this structure
of having the load management at higher levels
of the OSI reference model, to co-opt the
client devices in the load management. For example,
it's possible that the load manager may even
know the device characteristics that the client is
using, in order to come into the site.
For example, if it's a smart phone, it
might take certain actions commensurate with the device
that is coming in, in terms of structuring the
client-server interactions. Now, the data itself may be partitioned
among all the servers. For example, let's say that
you are doing a web search and it is a
web search that came in as a clients request.
And, if it is redirected to a particular server, this
server may not have access to all the data
that it needs. In order to do that, Google search
that you came in with. In that case,
the server may communicate using the back plane
with other servers to get the data that
it needs to serve the queries that is coming
in, so that there is complete coverage of
whatever the intended query needs to get as
a result. Of course, if the data is
partitioned, if a server that is holding a portion
of the data is down, then there'll be data
loss for the query. So for your specific search, the
server that is handling your search may not be able
to give you complete result for the search, because a
portion of the data is down due to the partitioning
of the data among the different servers at this site.
Now, this is where replicating the servers for redundancy helps.
So even though you may partition it, you may replicate
partitions so that it is possible that even if one
server is down, another server that has a replica of
the same partition may be able to provide the data
that is needed in order to satisfy a particular query.