> Hi, Hi, and thanks for your reply!
> On Mon, Oct 06, Kari Mattsson wrote: > > (IP numbers are imaginary, not real.) > > When I go to http://200.200.200.111 and http://200.200.200.222, and > > press F5 (refresh) on Firefox for a few time, I end up with 4 > > cookies instead of 2. > > For example when you go to .111 and hit refresh few times do the > requests go the same (backend)server or to both servers ? Few times, max 10, traffic goes to the same backend server. Then is suddenly switches to the backend of the other frontend, which is clearly an error. When I repeat refreshing on browser, it usually comes back to the original correct backend... and then to wrong one again later... > Couple of things to check: > - what do you get in haproxy log (option httplog) when you do: > firefox refresh test ? > your logs should show when haproxy inserts the cookie: > http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#8.5 correct example log entry: Oct 11 20:19:10 localhost haproxy[5179]: 10.6.159.238:4153 [11/Oct/2014:20:19:10.671] service_1_outside_80 service_1_inside/App_101 0/0/0/1/+1 200 +237 SERVICE_1=app101 - --VN 1/1/1/1/0 0/0 {service1.example.com} {7|} "GET / HTTP/1.1" this got repeated for 50+ times when refreshing on Chrome browser. Then to Firefox.. Oct 11 20:25:17 localhost haproxy[5179]: 10.6.159.238:4248 [11/Oct/2014:20:25:14.300] service_1_outside_80 service_1_inside/App_101 3264/0/0/1/+3265 200 +275 - - --NI 1/1/1/1/0 0/0 {service1.example.com} {7|} "GET / HTTP/1.1" Oct 11 20:25:22 localhost haproxy[5179]: 10.6.159.238:4252 [11/Oct/2014:20:25:22.854] service_2_outside_80 service_2_inside/App_142 0/0/0/1/+1 200 +275 - - --NI 1/1/1/1/0 0/0 {service1.example.com} {5|} "GET / HTTP/1.1" Oct 11 20:25:27 localhost haproxy[5179]: 10.6.159.238:4254 [11/Oct/2014:20:25:27.914] service_2_outside_80 service_2_inside/App_142 0/0/0/1/+1 304 +120 SERVICE_2=app142 - --VN 1/1/1/1/0 0/0 {service1.example.com} {|} "GET / HTTP/1.1" Oct 11 20:27:31 localhost haproxy[5179]: 10.6.159.238:4283 [11/Oct/2014:20:27:31.947] service_1_outside_80 service_1_inside/App_101 0/0/0/1/+1 200 +237 SERVICE_1=app101 - --VN 1/1/1/1/0 0/0 {service1.example.com} {7|} "GET / HTTP/1.1" Looks like browser will not receive a cookie for the first 2 page loads. On third it received... but a wrong cookie. After 2 minutes fourth reload, and if will receive the right cookie. Reloading page from this on, keeps it on the browser right frontend/backend. Weird. Now back to Chrome again for one more page reload: Oct 11 20:29:28 localhost haproxy[5179]: 10.6.159.238:4311 [11/Oct/2014:20:29:28.561] service_2_outside_80 service_2_inside/App_141 0/0/1/0/+1 200 +237 SERVICE_2=app141 - --VN 1/1/1/1/0 0/0 {service1.example.com} {5|} "GET / HTTP/1.1" Damn. Chrome falls to wrong frontend/backend. One more. Fireforx, 2 page re-loads for service1.example.com: Oct 11 20:31:52 localhost haproxy[5179]: 10.6.159.238:4350 [11/Oct/2014:20:31:52.023] service_2_outside_80 service_2_inside/App_142 0/0/0/1/+1 200 +237 SERVICE_2=app142 - --VN 1/1/1/1/0 0/0 {service1.example.com} {5|} "GET / HTTP/1.1" Oct 11 20:31:55 localhost haproxy[5179]: 10.6.159.238:4352 [11/Oct/2014:20:31:55.419] service_1_outside_80 service_1_inside/App_101 0/0/0/1/+1 200 +237 SERVICE_1=app101 - --VN 1/1/1/1/0 0/0 {service1.example.com} {7|} "GET / HTTP/1.1" ...first wrong, then right. So, it is flip-floping. > - you could also use tcpdump to see what cookies firefox <-> haproxy > send/receive ? With 'tcpdump -n -i eth0 src 10.6.159.238 and dst 194.1.1.15' I got: 20:35:29.083506 IP 86.60.159.238.ds-mail > 194.100.100.150.http: Flags [S], seq 1217634156, win 8192, options [mss 1260,nop,wscale 2,nop,nop,sackOK], length 0 20:35:29.090671 IP 10.6.159.238.ds-mail > 194.1.1.15.http: Flags [.], ack 267776592, win 16695, length 0 20:35:29.090862 IP 10.6.159.238.ds-mail > 194.1.1.15.http: Flags [P.], seq 0:449, ack 1, win 16695, length 449 20:35:29.293289 IP 10.6.159.238.ds-mail > 194.1.1.15.http: Flags [.], ack 245, win 16634, length 0 20:35:32.102248 IP 10.6.159.238.ds-mail > 194.1.1.15.http: Flags [.], ack 246, win 16634, length 0 20:35:32.102338 IP 10.6.159.238.ds-mail > 194.1.1.15.http: Flags [F.], seq 449, ack 246, win 16634, length 0 > - have you tried testing w/out using stick table / stick on cookie ? > (For > debugging purposes?) I think just the cookie SERVICE_1 insert and > cookie app* on server lines should be enough to get session > persistence. Commenting out lines stick-table type string stick on cookie makes zero difference. When running with just 1 frontend service, SERVICE_1 or SERVICE_2 everything works as advertised, ie. perfectly. Changing from cookie stickiness to source ip... stick-table type ip stick on src ...also makes no difference. Same errorneous behaviour. > - what are you trying to store with the stick table ? I think you are > going to have only two entries in the stick table: > key=appl01 and key=appl02 ? There are 2 to N backend servers, as there are in some cases 10+ million mobile devices fetching settings from the service. The frontends are actually https. Devices come in to service few times. One "session" takes less than a minute normally, but may take up to 15 minutes on slow 2G networks. Devices should talk with same backend server during the setup session. I am experimenting with HAProxy. Current production systems uses F5 gear. Thanks for any more hints 'n' tips on this.. -kari > -Jarno > > > backend service_1_inside > > mode http > > balance roundrobin # source roundrobin leastconn ... > > > > stick-table type string len 32 size 100k expire 1h store > > conn_cur,conn_rate(60s) > > stick on cookie(SERVICE_1) > > cookie SERVICE_1 insert indirect maxlife 1h > > > > default-server maxconn 1000 weight 100 inter 2s fastinter 700ms > > downinter 10s fall 3 rise 2 > > server App_101 10.10.10.101:80 cookie app101 check > > server App_102 10.10.10.102:80 cookie app102 check > > -- > Jarno Huuskonen > -- Kari Mattsson | +358.5069000 | https://mysync.fi | https://mysync-dm.com Trivore Corp., Old Mill, Ruukinkatu 2-4, FI-20540 Turku, Finland
