> In this page

Introduction
What is load balancing
Techniques
Persistence
Limitations
How to choose
Application tuning

> Quick links

Home
Articles
Linksys NSLU2
Load Balancing
A cheap UPS for ALIX
RTC on Capacitor for ALIX
GuruPlug Server Plus
Elastic Binary Trees
Traffic around Paris

> Software News

Inject CD-2.6 20071218
Inject CD 20070808
Rescue CD 20070808
HAProxy 1.4.18 (stable)
HAProxy 1.3.26 (stable)
Linux 2.4.37.11 (stable)
HTTPTerm 1.6.2
Inject 32

> Site search

 
Web 1wt.eu

> Advertisements

> How to choose between hardware and software load balancer

Although all solutions tend to look like they can do everything, this is not the case. Basically, there are three aspects to consider to choose a load balancer :

  • performance
  • reliability
  • features

Performance is critical, because when the load balancer becomes the bottleneck, nothing can be done. Reliability is very important because the load balancer takes all the traffic, so its reliability must be orders of magnitude above the servers's, in terms of availability as well as in terms of processing quality. Features are determinant to choose a solution, but not critical. It depends on what tradeoffs are acceptable regarding changes to the application server.

1. Session count

One of the most common questions when comparing hardware-based to proxy-based load balancers is why is there such a gap between their session count. While proxies generally announce thousands of concurrent sessions, hardware speaks in millions. Obviously, few people have 20000 Apache servers to drain 4 millions of concurrent sessions ! In fact, it depends whether the load balancer has to manage TCP or not. TCP requires that once a session terminates, it stays in the table in TIME_WAIT state long enough to catch late retransmits, which can be seen several minutes after the session has been closed. After that delay, the session is automatically removed. In practise, delays between 15 and 60 seconds are encountered depending on implementations. This causes a real problem on systems supporting high session rates, because all terminated sessions have to be kept in the table. A 60 seconds delay would consume 1.5 million entries at 25000 sessions per second. Fortunately, sessions in this state do not carry any data and are very cheap. Since they are transparently handled by the OS, a proxy never sees them and only announces how many active sessions it supports. But when the load balancer has to manage TCP, it must support very large session tables to store those sessions, and announces the global limit.

Fig.3 : How session tables fill up with traffic

<<< [ 6/10 ] >>>