Information Technology Reference
In-Depth Information
Load Balancer Resiliency
Load balancers themselves can become a single point of failure (SPOF). Redundant pairs
of load balancers are often used to remedy this shortcoming.
One strategy is a simple failover. One load balancer (the primary) receives all traffic,
and the other load balancer (the secondary) monitors the health of the primary by sending
heartbeat messages to it. If a loss of heartbeat is detected, the secondary takes over and
becomes the active load balancer. Any TCP connections that were “in flight” are discon-
nected since the primary is unaware of them.
Another strategy is stateful failover. It resembles simple failover except that the two
load balancers exchange enough information, or state, so that both know all existing TCP
connections. As a consequence, those connections are not lost in case of failover.
Asinglepairofloadbalancersareoftenusedformanydifferentservices—forexample,
many different web sites. All the web sites are homed at one load balancer and the other is
used for failover. When using non-stateful load balancers, a common trick is to home half
the web sites on one load balancer and half the web sites on the other load balancer. In this
case, in the event of a failover half as many connections are lost.
Hardware or Software Load Balancers
Load balancers may be hardware appliances that are purpose-built for the task. They may
also be software-based programs that run on standard computers. The hardware appliances
are usually highly tuned and feature-rich. The software-based ones are more flexible.
For smaller services, the load balancer software might run on the machines providing
the services. Pushing the load balancing function to the machines themselves reduces the
amount of hardware to be managed. However, now the processing of the load balancing
software competes for CPU and other resources with the services running on the box. This
approach is not recommended for high-volume load balancing but is fine for many situ-
ations.
Software load balancing can also be pushed even further down the stack to the clients
themselves.Client-sideloadbalancingrequiresthattheclientsoftwareknowwhichservers
are available and do its own health checking, server selection, and so on. This is frequently
done for internal services since they are usually more tightly controlled. The client library
can load the configuration from a central place, load balance requests, and detect and route
around failures. The downside is that to change algorithms or fix bugs, the client library
must be changed, which requires updating the software anywhere it is used.
Search WWH ::




Custom Search