Re: session stickyness with or without serverid
On Mon, Aug 01, 2011 at 12:14:48PM -0400, Julien Vehent wrote: > You're right, I do set the weight at zero first, and then after a > couple of hours, put the server in maintenance mode. OK. > What I'm trying to reduce is the time between setting a server's weight > to zero, and seeing no connections on it. > With maxlife 1h, I get a decent compromise. After one hour from setting > the server to zero, I would probably only disconnect 0.001% of obsessive > users, so it's "fine". Yes that's the right method. However, if you want to ensure that nobody will connect to your server during the operations, you can force the server to enter the maintenance mode (using the stats socket or stats web interface). > >Cookie insertion is more reliable and more determinist since there > >are > >no tables to learn and maintain. Also, with recent versions, we now > >have > >features such as "force-persist" and "ignore-persist" which make it a > >lot > >easier to perform maintenance on live service without the user > >noticing > >and with the ability for the admin to check what he's going to put > >online > >before doing so. All these are good reasons to use a SERVERID cookie > >instead of learning a JSESSIONID cookie. > > > > I fail to see how ignore-persist can help me in this case... As I > understand it, ignore-persist will force haproxy to ignore the > persistence cookie and load balance the request to any available > backend. In my case, it would mean redirect the user with an active > session to another backend, effectively disconnecting it. Am I correct ? Exactly. Different people proceed in different ways. For instance, there are some who would use ignore-persist to match a cookie value (that of the server you're putting offline). But with the maintenance mode, this is no longer necessary. Regards, Willy
Re: session stickyness with or without serverid
On Fri, 29 Jul 2011 09:11:38 +0200, Willy Tarreau wrote: Hi Julien, On Thu, Jul 28, 2011 at 07:16:32PM -0400, Julien Vehent wrote: Hey guys, We've been happy users of haproxy in front of our tomcat farm for some time now, except for one thing: when we want to put a backend in maintenance mode, via hatop, we have to deal with users coming back a few hours later with a SERVERID cookie and being routed to that backend. If it's in maintenance mode, it should not receive any traffic. I suspect you just changed its weight to zero, which means it's not elected for LB but will still serve persistent requests. Please double-check, because if you're certain that you're getting that, then you've spotted a bug. Hey Willy, You're right, I do set the weight at zero first, and then after a couple of hours, put the server in maintenance mode. What I'm trying to reduce is the time between setting a server's weight to zero, and seeing no connections on it. With maxlife 1h, I get a decent compromise. After one hour from setting the server to zero, I would probably only disconnect 0.001% of obsessive users, so it's "fine". I initially configured haproxy to balance based on a SERVERID cookie, essentially because I didn't know if the JSESSIONID would provide the appropriate persistence, but now I'm thinking that it might be a good idea to remove the SERVERID cookie and do all the work on the JSESSIONID. The goal would be to reduce the time between putting a server in maintenance and not seeing any traffic on it at all (ie. all sessions are expired). So my question is: what are the pros and cons of using a SERVERID cookie vs a JSESSIONID ? Cookie insertion is more reliable and more determinist since there are no tables to learn and maintain. Also, with recent versions, we now have features such as "force-persist" and "ignore-persist" which make it a lot easier to perform maintenance on live service without the user noticing and with the ability for the admin to check what he's going to put online before doing so. All these are good reasons to use a SERVERID cookie instead of learning a JSESSIONID cookie. I fail to see how ignore-persist can help me in this case... As I understand it, ignore-persist will force haproxy to ignore the persistence cookie and load balance the request to any available backend. In my case, it would mean redirect the user with an active session to another backend, effectively disconnecting it. Am I correct ? Maybe I'm not seeing the use case properly here. Thanks, Julien
Re: session stickyness with or without serverid
Hi Julien, On Thu, Jul 28, 2011 at 07:16:32PM -0400, Julien Vehent wrote: > Hey guys, > > We've been happy users of haproxy in front of our tomcat farm for some > time now, except for one thing: when we want to put a backend in > maintenance mode, via hatop, we have to deal with users coming back a > few hours later with a SERVERID cookie and being routed to that backend. If it's in maintenance mode, it should not receive any traffic. I suspect you just changed its weight to zero, which means it's not elected for LB but will still serve persistent requests. Please double-check, because if you're certain that you're getting that, then you've spotted a bug. > I initially configured haproxy to balance based on a SERVERID cookie, > essentially because I didn't know if the JSESSIONID would provide the > appropriate persistence, but now I'm thinking that it might be a good > idea to remove the SERVERID cookie and do all the work on the > JSESSIONID. The goal would be to reduce the time between putting a > server in maintenance and not seeing any traffic on it at all (ie. all > sessions are expired). > > So my question is: what are the pros and cons of using a SERVERID > cookie vs a JSESSIONID ? Cookie insertion is more reliable and more determinist since there are no tables to learn and maintain. Also, with recent versions, we now have features such as "force-persist" and "ignore-persist" which make it a lot easier to perform maintenance on live service without the user noticing and with the ability for the admin to check what he's going to put online before doing so. All these are good reasons to use a SERVERID cookie instead of learning a JSESSIONID cookie. Cheers, Willy
