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.
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)
The bud ( https://github.com/indutny/bud ) does support this kind of hot config reloads and process restarts. It's just starting new worker processes on SIGHUP, and let old workers wait until all their connections will be closed.
This is basically done by moving the balancing between workers into the master, instead of calling `accept()` concurrently from the workers.
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.
This is generally correct. In particular, when the HAProxy process is stopped/restarted there is a brief period during which the port is not bound by either process. (If the new process isn't able to get the socket when it boots it will sleep ~XXms, then try to bind/listen in a loop until it gets it or a retry threshold is hit.) During this time the kernel will reject incoming connections to the HAProxy port, so you are in danger of dropping incoming requests on the ground.
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.
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.
A bit of self-promotion, but you may want to take a look at bud ( https://github.com/indutny/bud ) too. It is basically a TLS terminating proxy, and does support some availability features (if you need them).
The bud is built on the top of the libuv, which empowers the node.js.
I was doing about 8GB/s sustained through 1.5 on a single box without issue.
However, you need to run it in multi-process - I found 16 to be a good number. The only drawback is that any monitoring you do is on whichever process you happen to connect to when you check, so you need to multiply by the number of total processes to get accurate numbers. Not sure why the monitoring is per-process, but it's a bit of a pain.
It's not very heavy. Usually between 1000-2000 concurrent sessions during the day. Connection and session rates peak around 200/s. Single process. CPU has remained under 15%.
Been using this in production for about six months now. Happy that the release version is finally out. The nicest feature of 1.5 is that you can easily do Redis failover using the new TCP check features.
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.
ELB has features that nginx does not (health checks for one), and does not take advantage of many features that nginx does have. On the other hand, the feature set of HAProxy (1.5 branch, now "released") matches remarkably closely.
Linode's NodeBalancers are clearly HAProxy. I just wish they exposed more config options (such as the PROXY protocol - it's useless for SMTP without that).
Heh... I do feel like I'm promoting bud a way too much here, but it seems that it could be better suited for PaaS than HAProxy, mostly because of it's async SNI feature.
Basically, bud can load the certificates and private keys for a domain name on the fly, without putting all of them into configuration.
I'm using HAProxy to load balance to an EC2 autoscaling group.
I have to list all ip in the configuration file. It's still not possibile to put A.B.C.0/24.
June, even. I'm still interested, though. Fitbit uses haproxy but I set up my development machine with nginx because of SSL. It probably doesn't make a difference, but I'll still feel better when I can easily make my dev setup more closely mirror production.
From what I recall, the SSL functionality was in haproxy for a while now. Some time ago, when I was doing research if I have other options for SSL enabled LB other than Nginx, I found the information that haproxy has such support included, but for some reason I decided to go with Nginx anyway.
I didn't investigate deeply; I'd never heard of haproxy prior to Fitbit. Someone from site ops told me they use nginx + haproxy but it would be easier for me to just set up nginx.
SSL support has been around for a while, but 1.5 has been considered beta for a few years now, though that hasn't stopped it from being deployed in a lot of production environments.
Before SSL was rolled into haproxy, nginx was often a good candidate to handle the SSL termination. Stunnel is also common, and stud was popular for a while, but seems it was abandoned once haproxy could handle the job.