We use the iptables syn drop method, works fine; the additional 1 sec in response time for the tiny number of new connections doesn't bother us as we are not restarting multiple time per hour.
On Fri, Jan 22, 2016 at 11:01 AM, CJ Ess <[email protected]> wrote: > The yelp solution I can't do because it requires a newer kernel then I have > access to, but the unbounce solution is interesting, I may be able to work > up something around that. > > > > On Fri, Jan 22, 2016 at 4:07 AM, Pedro Mata-Mouros > <[email protected]> wrote: >> >> Hi, >> >> Haven’t had the chance to implement this yet, but maybe these links can >> get you started: >> >> >> http://engineeringblog.yelp.com/2015/04/true-zero-downtime-haproxy-reloads.html >> http://inside.unbounce.com/product-dev/haproxy-reloads/ >> >> It’d be cool to have a sort of “officially endorsed” way of achieving >> this. >> >> Best, >> >> Pedro. >> >> >> >> On 22 Jan 2016, at 00:38, CJ Ess <[email protected]> wrote: >> >> One of our sore points with HAProxy has been that when we do a reload >> there is a ~100ms gap where neither the old or new HAproxy processes accept >> any requests. See attached graphs. I assume that during this time any >> connections received to the port are dropped. Is there anything we can do so >> that the old process keeps accepting requests until the new process is >> completely initialized and starts accepting connections on its own? >> >> I've looked into fencing the restart with iptable commands to blackhole >> TCP SYNs, and I've looked into the huptime utility though I'm not sure >> overloading libc functions is the best approach long term. Any other >> solutions? >> >> >> <hist_restart_1.png> >> <hist_restart2.png> >> >> >> >
