Hi,
Thanks for you replies, please see comment below.
On 10/31/2011 10:45 PM, Baptiste wrote:
Hi,
If cookie insert is not an option,
Hmm ... in general when would a cookie insert be a bad/no option
compared to appsession or cookie persistence learning available in 1.5 ?
For me the obvious advantage of cookie insert is that haproxy does not
need to waste any memory for tracking sessions and using special peer
replication between different haproxy instances. But what is the
disadvantage of cookie insert?
then in 1.5-dev7, you can perform
cookie persistence learning the application cookie and store it in a
stick table.
Do you refer to this "stick store-response <pattern> ..." keyword?
It's like appsession, unless it will survive a reload and you can
share it between HAProxy boxes. :)
With "peers <peersect>" option of stick-table where peersect is as
described at " 3.5. Peers" section?
Thanks
Alex
cheers
On Mon, Oct 31, 2011 at 7:40 PM, Cyril Bonté<cyril.bo...@free.fr> wrote:
Hi,
Le Lundi 31 Octobre 2011 17:21:02 Piavlo a écrit :
I have been using *capture cookie* and *appsession *in one haproxy
configuration for sticky sessions.
The problem is that then haproxy restarted/reload or domain is migrated
to failover server the sticky data is lost.
Today I realised that I don't need to use sticky sessions at all in
haproxy - what I do is setup custom session name
different in each backend http server based on it's name and then using
acl match on *hdr_beg(Cookie)* to direct to the correct backend
and if Cookie is not set then send it to round robin backend that has
all the http servers listed.
Is there any reason to use a different cookie name per server instead of using
much standard behaviour of haproxy (using cookie insert and others) ?
Your configuration would be a lot more simple and maintainable (see at the
end).
Below is the relevant frontend& backend config.
It works great - but there is one problem. It's is very important that
the *maxconn* that is set in *server *will be set globally per real http
server
but since I now have same server http server listed twice.
For example for lb-srv1 web server there are *lb-srv1/lb-srv1* and
*testing_rr/lb-srv1* - it means the total maxconn for lb-srv1 is now x2
larger.
I could split split the maxconn between lb-srv1/lb-srv1 and
testing_rr/lb-srv1 - so that in total it's 900 - but this will not use
the possible 900 slots
since there is no way to know that ratio of lb-srv1/lb-srv1 vs
testing_rr/lb-srv1 and it's highly dynamic.
Is there some trick to share the same *maxconn* for lb-srv1/lb-srv1
testing_rr/lb-srv1
Or something similar to*track* - that would make *server* track other
*server*'s maxconn too? and not only health checks.
No, or not yet.
afaiu the haproxy backends lb-srv1& lb-srv1 cannot be load balanced
but only chosen based on acl or as default fallback?
No.
------------------------------------------------------------
frontend testing 0.0.0.0:88
mode http
maxconn 20000
option httplog
monitor-uri /up.html
option http-server-close
option forwardfor
reqadd X-Forwarded-Proto:\ http
acl acl-lb-srv1 hdr_beg(Cookie) lb-srv1=
acl acl-lb-srv1-up nbsrv(lb-srv1) 1
acl acl-lb-srv2 hdr_beg(Cookie) lb-srv2=
acl acl-lb-srv2-up nbsrv(lb-srv2) 1
use_backend lb-srv1 if acl-lb-srv1 acl-lb-srv1-up
use_backend lb-srv2 if acl-lb-srv2 acl-lb-srv2-up
default_backend testing_rr
monitor fail if !acl-lb-srv1-up !acl-lb-srv2-up
backend lb-srv1
mode http
option httpchk /up.html
option abortonclose
server lb-srv1 lb-srv1.private:82 maxconn 900 check
inter 2000 fall 3
backend lb-srv2
mode http
option httpchk /up.html
option abortonclose
server lb-srv2 lb-srv2.private:82 maxconn 900 check
inter 2000 fall 3
backend testing_rr
mode http
option httpchk /up.html
option abortonclose
balance roundrobin
server lb-srv1 lb-srv1.private:82 maxconn 900 track
lb-srv1/lb-srv1
server lb-srv2 lb-srv2.private:82 maxconn 900 track
lb-srv2/lb-srv2
-----------------------------------------------------------
Proposed version (untested) :
------------------------------------------------------------
listen testing 0.0.0.0:88
mode http
maxconn 20000
option httplog
monitor-uri /up.html
option abortonclose
option http-server-close
option forwardfor
reqadd X-Forwarded-Proto:\ http
acl acl-lb-down nbsrv 0
monitor fail if acl-lb-down
cookie lb insert
server lb-srv1 lb-srv1.private:82 maxconn 900 cookie srv1
check inter 2000 fall 3
server lb-srv2 lb-srv2.private:82 maxconn 900 cookie srv2
check inter 2000 fall 3
-----------------------------------------------------------
--
Cyril Bonté
