On Mon, Aug 02, 2010 at 09:05:02AM -0700, Rich Rauenzahn wrote:
> I'm using haproxy ("balance uri") inside an intranet to direct traffic
> to 4 squid servers in order to cache content normally served directly
> by our web server. This web server serves large files (ranging from
> 10's of MB to several GB)
>
> I'm worried that our haproxy server could be a network bottleneck (the
> NIC, not the software) and am wondering if there is a way to use an
> http redirect instead of passthrough -- then the actual traffic could
> come directly (and only) from the back end squid server and not have
> to also pass through the haproxy NIC.
Worse yet, every packet will pass not only NIC, but in setups
not involving tcp-splicing will also traverse processing level at
haproxy host (at least four extra context switches, not really
necessary in your setup).
> I have a feeling from browsing the docs that haproxy just isn't
> intended to be used in this kind of model.
You are right.
> Is it possible to do this? Should I be using a different load
> balancer? Or does this kind of redirection have a nasty side effect I
> haven't thought of yet?
Some years ago, at my previous work, when I had about the same setup
with the squid's caching heavy content from one server, I wrote
simple task-oriented load-balancer with the following algorithm:
- when request comes in, balancer sends out ICP (inter-squid cache
protocol) requests to all neighboring squids asking if anyone has this
file cached.
- if balancer gets positive reply (means cache already has this
file cached) then it generates redirect to this cache.
- if there were at least one negative reply during while timeout
not reached then balancer generates redirect to server replied
first.
- if there were no replies at all - 5xx error generated.
As a result:
- if file requested is already cached at some squid - request
redirected here and served from disk cache, not from the slow
backend server. (if file cached at more than one server - faster/less
loaded server gets preference in handling this request, response time
is used as load indicator here).
- if file requested is not cached yet - request redirected to
the least loaded squid cache.
- if no squid servers available - request is not served.
IIRC, I never published this code, but if you are interested -
drop me a letter and I will publish it at least as a reference
implementation (with hardcoded server names and freebsd specifics
like acceptfilter and kevent-based cycle inside).
PS: this code served us for about one year, but it is not in use anymore:
our bottleneck was badly designed windows-based web-server that was just
not able to serve files at >130Mbit/sec. After this service was reimplemented
using linux/nginx as server platform there is no real need in this code.
