On Thu, Feb 25, 2010 at 11:31:15PM +0800, Martin Aspeli wrote:
> I could think of more complex rules if you'd like. ;-)
No thanks, other people already do that for you :-)
> >The idea would then be to have a default backend which gets requests
> >without cookies, and one backend per other group. I don't know if you
> >consider that all 8 instances of one host are always in the same state
> >(up/down) or if they can be independant. Let's consider them independant
> >for now.
>
> They would be independent, i.e. we may take one down for maintenance or
> a rolling release (or it could crash).
OK so let them all be checked then.
> >Also you must be very careful with your cookie in prefix mode : we have
> >to remove it in the two other backends before passing the request to the
> >server. However we don't want to stick on it otherwise the first server
> >of each farm would always get the connections. Thus, the idea is to set
> >the cookie in prefix mode but not assign any cookie to the servers. That
> >way no server will be found with that cookie value and the load balancing
> >will happen. However you must ensure that your servers will not set the
> >cookie again later, otherwise it will be sent without any prefix to the
> >client and the stickiness will be lost.
>
> That's clever.
>
> When is the prefix applied and stripped in this case?
The prefix is :
- always stripped from any request by a backend which declares
"cookie XXX prefix"
- always applied to any response by a backend which declares
"cookie XXX prefix" when a server returns such a cookie AND
has a cookie value assigned.
The issue can come from servers receiving an expired session and
who wants to reinitialise a new one. They will then emit a new
set-cookie with a new cookie value which will not be prefixed,
and the stickiness will be lost.
> >Another solution would be to simply use cookie insertion mode.
>
> Which option are you illustrating in the sample config below? I'm not
> sure I fully understand the implications of using prefix vs. insertion
> mode here.
Below is the prefix mode. If you want to work in insertion mode,
remove all "cookie XXX prefix" lines and uncomment the
"cookie XXX insert" line.
> > That way
> >you don't have to worry whether your application will set the cookie
> >again or not.
>
> So, in fact most users will be anonymous (no session) and don't strictly
> need to be sticky to a server, even. When they log in, a cookie
> (beaker.session) is set by the application. The application won't trip
> up on other cookie values.
I see, but given that you already want to stick on a farm anyway, you
have to set that. It should not be a big trouble because the anonymous
users will just stick to a farm, no to a server. You could even improve
by using "cookie XXX insert indirect postonly". It will only add a cookie
on responses to POST requests, which most often are the first login
request.
Regards,
willy
