Hi Greg,
On Sat, Jan 22, 2011 at 09:49:03AM -0800, Gregory Scallan wrote:
> Hey all,
>
> I wanted to have an http balance algorithm whose logic is similiar
> to the following:
>
> 1) use the left most part of the uri before the ? up to depth N. If the
> value at the depth of N (meaning the characters between the slashes at
> that depth) is anything other than the number zero, use a hash of the
> value at that depth only to compute which server receives the request.
>
> 2) If the above is not met (meaning there was no value at that depth OR
> the value there was the number zero), then look for the url parameter Y
> and use it's value as the hash on where to send the request. If this
> url paramter does not exist, use a round robin algorithm.
>
> From my reading of the docs, one cannot do this today, correct?
You can't *easily* do this. You can do this using two backends, one for
each hashing method. In your frontend, you check for case #1. If it
matches, you send to backend #1 which applies balance algorithm #1.
Otherwise you send to backend #2 which applies algo #2. Note that when
doing a hash on a non-existing parameter, the algorithm automatically
switches to static-round-robin, so a single backend could perform the
two algos of #2.
> If true, I think the simplest way to implement this would be to support
> multiple balance statements where the second one is used if the first is
> not met (rather than RR after the first).
It's not that easy. Depending on the algorithm, some arrays or trees are
built and updated each time a connection is allocated or released. You
can't mix several of them. However, I think that we could possibly find
a way to make the hash parameter dynamically configurable. We could for
instance have something like this :
balance hash
hash-on src if XXX
hash-on dst if XXX
hash-on hdr(host) if XXX
hash-on url_param(user) if XXX
etc...
And just like now, when no hash parameter is found, the hash table falls back
to round robin (it's just a pointer in the table that's updated so it's easy
to maintain the round robin feature with a hash table).
In my opinion, it would probably fit your needs. I don't see a reason for
having the balance algorithm parametrable between different types of algos
(eg: leastconn vs roundrobin). You can use multiple backends for that. But
having it parametrable on the hash makes sense.
> I also think I'd need a
> change to use only the character at depth N for the first part (rather
> than everything before and including that depth).
I wish I had the time to implement the request parameter extraction I
want to implement since 1.4 :-/ The goal was exactly that : define
how to extract some data from the request, then use that data with
anything (header addition, hashing, sticking, ...).
Regards,
Willy
