Hi Willy, Thanks a lot for your response! It sounds really logic to maintain the servers' IDs between reloads. I will add the id argument to each server and see what it happens. Regarding the servers order, the config generator is always sorting the hostnames. This is not a problem in my scenario (adding a server on top won't affect anything) because servers in farm are complete stateless (no DB access, no caching, no nothing:) )
One more question: is there any suggested procedure for adding backend servers into a peers frontend? I see the problem of timing between adding a backend server into one peer and later adding into the others. Shoud I first add the server disabled into all peers and then enable? Will the stickyness be "honored" even in disabled servers? Thanks again Jose El oct 20, 2013 3:18 a.m., "Willy Tarreau" <[email protected]> escribió: > Hello Jose, > > On Fri, Oct 18, 2013 at 06:49:47PM +0000, Olcese, Jose wrote: > > Hello, > > > > I'm facing the following problem: > > > > I use stickiness table on a peers cluster. If I reload the configuration > > without changing any backend server, everything works fine. > > > > Reload command: > > /usr/local/sbin/haproxy -f /usr/local/etc/haproxy.cfg -p > /var/run/haproxy.pid -D -sf $(cat /var/run/haproxy.pid) > > > > > > The problem happens if I add or remove backend servers to the config > file. > > The stickiness table will maintain the index to the original servers' > order > > so the "reloaded" table will point to wrong servers. > > This is normal and expected : the servers' IDs are the only stable > information across reloads and the only one that can reliably be > shared between multiple peers. If you need to insert or remove servers > in the middle, then you need to force the servers' IDs using the "id" > argument. > > The ID is per-backend, so there is no problem if your IDs overlap between > some backends. IDs are 32-bit, so you can easily have your config generator > produce them incrementally I think. > > BTW, I'm seeing below that it seems to name them with a 32-bit ID as well. > I'm even thinking that your config generator is *really* dumb in that it > does > not respect *at all* the servers order and just dumps them in the numeric > order of their IDs : > > server vm--i-37a49303 172.18.80.106 check port 80 inter 30s fastinter > 5s rise 2 fall 3 > server vm--i-43279674 172.18.80.60 check port 80 inter 30s fastinter 5s > rise 2 fall 3 > server vm--i-76afe142 172.18.81.100 check port 80 inter 30s fastinter > 5s rise 2 fall 3 > server vm--i-b2f3a386 172.18.80.103 check port 80 inter 30s fastinter > 5s rise 2 fall 3 > server vm--i-b40a3a80 172.18.81.165 check port 80 inter 30s fastinter > 5s rise 2 fall 3 > server vm--i-bcc96e8b 172.18.81.29 check port 80 inter 30s fastinter 5s > rise 2 fall 3 > server vm--i-cfa3b8fb 172.18.81.80 check port 80 inter 30s fastinter 5s > rise 2 fall 3 > > That would be terrible for a farm working with a hash-based algorithm. > Think about a cache, you would shuffle all the data on each > addition/removal! > > But if that's OK for your usage, then you could probably make it pass the > ID in integer as the "id" parameter : > > server vm--i-37a49303 172.18.80.106 id 933532419 check port 80 inter > 30s fastinter 5s rise 2 fall 3 > server vm--i-43279674 172.18.80.60 id 1126667892 check port 80 inter > 30s fastinter 5s rise 2 fall 3 > > If your config generator cannot do that, a simple awk or even perl script > will easily do it for you. > > Hoping this helps, > Willy > > >
