Scheduling algorithms
Numerous
scheduling algorithms are used by load balancers to determine which back-end
server to send a request to. Simple algorithms include random choice or round
robin. More sophisticated load balancers may take additional factors into
account, such as a server's reported load, least response
times,
up/down status (determined by a monitoring poll of some kind), number of active
connections, geographic location, capabilities, or how much traffic it has
recently been assigned.
Persistence
An
important issue when operating a load-balanced service is how to handle
information that must be kept across the multiple requests in a user's session.
If this information is stored locally on one backend server, then subsequent
requests going to different backend servers would not be able to find it. This
might be cached information that can be recomputed, in which case
load-balancing a request to a different backend server just introduces a
performance issue.
Ideally
the cluster of servers behind the load balancer should be session-aware, so
that if a client connects to any backend server at any time the user experience
is unaffected. This is usually achieved with a shared database or an in-memory
session database, for example Memcached.
One basic
solution to the session data issue is to send all requests in a user session
consistently to the same backend server. This is known as persistence or
stickiness. A significant downside to this technique is its lack of automatic
failover: if a backend server goes down, its per-session information becomes
inaccessible, and any sessions depending on it are lost. The same problem is
usually relevant to central database servers; even if web servers are
"stateless" and not "sticky", the central database is (see
below).
Assignment
to a particular server might be based on a username, client IP address, or be
random. Because of changes of the client's perceived address resulting from
DHCP, network address translation, and web proxies this method may be
unreliable. Random assignments must be remembered by the load balancer, which
creates a burden on storage. If the load balancer is replaced or fails, this
information may be lost, and assignments may need to be deleted after a timeout
period or during periods of high load to avoid exceeding the space available
for the assignment table. The random assignment method also requires that
clients maintain some state, which can be a problem, for example when a web
browser has disabled storage of cookies. Sophisticated load balancers use
multiple persistence techniques to avoid some of the shortcomings of any one method.
Another
solution is to keep the per-session data in a database. Generally this is bad
for performance because it increases the load on the database: the database is
best used to store information less transient than per-session data. To prevent
a database from becoming a single point of failure, and to improve scalability,
the database is often replicated across multiple machines, and load balancing
is used to spread the query load across those replicas. Microsoft's ASP.net
State Server technology is an example of a session database. All servers in a
web farm store their session data on State Server and any server in the farm
can retrieve the data.
In the
very common case where the client is a web browser, a simple but efficient
approach is to store the per-session data in the browser itself. One way to
achieve this is to use a browser cookie, suitably time-stamped and encrypted.
Another isURL rewriting. Storing session data on the client is generally the
preferred solution: then the load balancer is free to pick any backend server
to handle a request. However, this method of state-data handling is poorly
suited to some complex business logic scenarios, where session state payload is
big and recomputing it with every request on a server is not feasible. URL
rewriting has major security issues, because the end-user can easily alter the
submitted URL and thus change session streams.
Yet
another solution to storing persistent data is to associate a name with each
block of data, and use a distributed hash table to pseudo-randomly assign that
name to one of the available servers, and then store that block of data in the
assigned server.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.