Re: Algorithms and Hashing

From: Willy Tarreau <>
Date: Mon, 17 Mar 2008 22:37:01 +0100

Hi guys,

On Thu, Mar 13, 2008 at 02:32:32PM +0100, Patrick Viet wrote:
> On Thu, Mar 13, 2008 at 1:22 PM, Guillaume Bourque
> <> wrote:
> > I was asking this because we are using tcp mode which don't use cookie
> > for persistency so the only thing that is important, I think, is to
> > define the backend server in the same order on my 2 haproxy. That way a
> > particular client with is hash will always end up on them same backend
> > server.
> >
> > I will do more testing but in tcp mode the important thing in a ha setup
> > is to define alle the server in the same order.
> Indeed it is important.

yes, and I confirm this is something wich is commonly found when people are playing with multiple protocols.

> Then again, also adding consistent hashing would be even better.

Krzysztof has implemented the good old server tracking feature we've been talking about a while ago. With it, you can say that server XXX is not checked, but instead reflects the same state as server YYY from backend ZZZ. This is very convenient for such uses as it ensures that your servers are *always* in the same state.

> I'll discuss it with Willy soon ; it could be used in a very
> interesting way to load balance cache servers.

I did not know this mechanism, the idea is very clever. From what I understood, however, if one server disappears, the next server in the list will get its traffic. If so, this means that some servers will get twice their acceptable load (even more if weights are not equal).

A solution I had pending for quite a moment now was to replace the hash with two consecutive hashes:

That way, users of good servers are not redistributed, and the weights are correctly redistributed across the remaining servers.

Also I think it is easier to implement based on what we currently have. The one annoying thing is, as always, the case of the backup servers which almost doubles the number of situations to handle.

Willy Received on 2008/03/17 22:37

This archive was generated by hypermail 2.2.0 : 2008/03/17 22:45 CET