Live data from Hacker News

HAProxy 1.5

haproxy.org

31–40 of 51 posts

Re: HAProxy 1.5

#31
post #7
post #5

Earlier quoted context omitted.

I have the sneaking suspicion that Amazon's Elastic Load Balancer is based on HAProxy (and has been tracking the 1.5 series in development for some time). Nothing particularly evidentiary, but it's a glass slipper that fits very snugly.

I believe they use nginx. Traditionally ELB has been the most featureless LB's you'd ever encounter. That's in direct contrast with HAProxy. Truly a pain point with AWS IMO.

The AWS approach to things has been to launch things that are very basic and then add complexity only gradually and when they see steady demand for something. The flipside of that is that a) when they release something it, it's generally very solid, and b) what they support generally stays supported.

That does mean that there are a lot of people who want AWS to support some particular feature. But having seen how featuritis can really ruin a code base, I'm glad they're conservative; I want my infrastructure to be very reliable.

Re: HAProxy 1.5

#32
post #10

This release contains a neat feature: you can now bind HAProxy to a specific FD opened by its parent process. This means that you can babysit your HAProxy processes underneath a parent process that opens ports and get hitless HAProxy restarts, which I've long desired.

This is great for systemd integration! http://0pointer.de/blog/projects/socket-activation.html

Re: HAProxy 1.5

#33
post #10

This release contains a neat feature: you can now bind HAProxy to a specific FD opened by its parent process. This means that you can babysit your HAProxy processes underneath a parent process that opens ports and get hitless HAProxy restarts, which I've long desired.

Have you looked at einhorn? We've been running HAProxy under einhorn for a while now, using something like https://gist.github.com/ebroder/36b2f4f3aa210b9d9f3d to translate between HAProxy's signalling mechanisms and einhorn's signalling mechanisms.

Re: HAProxy 1.5

#34
We've been using HAProxy 1.5dev in production for a few month, including SSL. It's been one of the most simplest and stable parts of our infrastructure.

Re: HAProxy 1.5

#35
post #33
post #10

This release contains a neat feature: you can now bind HAProxy to a specific FD opened by its parent process. This means that you can babysit your HAProxy processes underneath a parent process that opens ports and get hitless HAProxy restarts, which I've long desired.

Have you looked at einhorn? We've been running HAProxy under einhorn for a while now, using something like https://gist.github.com/ebroder/36b2f4f3aa210b9d9f3d to translate between HAProxy's signalling mechanisms and einhorn's signalling mechanisms.

Er, yes, hi Evan! Cooper here. I believe either you or Andy originally pointed this interesting HAProxy restart behavior out to me, in the context of explaining why you wrote Einhorn.

Re: HAProxy 1.5

#37
post #10

This release contains a neat feature: you can now bind HAProxy to a specific FD opened by its parent process. This means that you can babysit your HAProxy processes underneath a parent process that opens ports and get hitless HAProxy restarts, which I've long desired.

This will also allow HAProxy to be brought into the fold if you're using Circus (http://circus.readthedocs.org/en/0.11.1/) for process monitoring. Probably not a big win in reliability, but I bet there are plenty of other things you can do with that (like parent mentioned)

Re: HAProxy 1.5

#38
post #30

Earlier quoted context omitted.

No, not really, for short period of time you've got state where previously configured instance is not working already and future one is not working yet.

Oh, you are right, after searching a little on the subject it looks like some people are doing things like this: iptables -I INPUT -p tcp -m multiport —dports 80,443 —syn -j DROP && sleep 0.5 && \ /etc/init.d/haproxy reload; iptables -D INPUT -p -tcp -m multiport —dports 80,443 —syn -j DROP Source: https://medium.com/@Drew_Stokes/actual-zero-downtime-with-ha...

I feel I must point out that this relies on your clients to retry packets that iptables drops, so at the least they'll have a slower experience than they otherwise would. I believe that this will also break requests that are in flight when the reload happens, if they have sent partial data.

Re: HAProxy 1.5

#39

We've been using HAProxy 1.5dev in production for a few month, including SSL. It's been one of the most simplest and stable parts of our infrastructure.

how much traffic are you passing in this environment?

we're still using stunnel for ssl, have been waiting for positive reports to let haproxy do it, but are optimistic.

Re: HAProxy 1.5

#40
post #38
post #30

Earlier quoted context omitted.

Oh, you are right, after searching a little on the subject it looks like some people are doing things like this: iptables -I INPUT -p tcp -m multiport —dports 80,443 —syn -j DROP && sleep 0.5 && \ /etc/init.d/haproxy reload; iptables -D INPUT -p -tcp -m multiport —dports 80,443 —syn -j DROP Source: https://medium.com/@Drew_Stokes/actual-zero-downtime-with-ha...

I feel I must point out that this relies on your clients to retry packets that iptables drops, so at the least they'll have a slower experience than they otherwise would. I believe that this will also break requests that are in flight when the reload happens, if they have sent partial data.

Yeah, it feels like a dirty, dirty hack. The way I understood it is that the requests in flight would retry the same way as the new connections when the first iptables rule is applied.
Post reply on HN