Fair Proxy Balancer

Grzegorz Nosek grzegorz.nosek at gmail.com
Fri Feb 8 18:47:52 MSK 2008

On Fri, Feb 08, 2008 at 04:29:27PM +0100, Alexander Staubo wrote:
> On Feb 6, 2008 4:41 PM, Grzegorz Nosek <grzegorz.nosek at gmail.com> wrote:
> > No, I haven't compared haproxy or lvs (I assume that was what you
> > meant). However, haproxy is a TCP forwarder which makes it uncomfortable
> > at times. For example, even if your backends are down, connections to
> > haproxy will succeed and the only thing haproxy can do is to reset your
> > new connection (even though nginx has already happily sent the request).
> Could you explain what you mean by "if your backends are down,
> connections to haproxy will succeed"? By backend, do you mean Nginx
> or, say, a Mongrel server?

Say you have:

nginx --> haproxy --> (a bunch of backends)

When nginx connects to haproxy, the connection will succeed (as haproxy
is still alive) but when haproxy tries to connect to any backend (let's
say they're all dead or a switch failed etc.), the connection
(haproxy->backend) will eventually time out. However, from nginx's point
of view, the connection succeeded (haproxy replied), so it sends the
request which then times out or dies with a connection reset.

If you had several haproxy instances, each fronting its own set of
mongrels, you'd have just lost a request unneccessarily [sp?].

Note, I don't know whether haproxy is smart enough to shut down its
listening socket when all backends fail (it might be). I rather meant to
say that a TCP forwarder must explicitely support such situations to
handle them.

Best regards,
 Grzegorz Nosek

More information about the nginx mailing list