41–50 of 51 posts
If you're a curious Ubuntu (14.04) user, it looks like the PPA to get version 1.5 is ppa:vbernat/haproxy-1.5. Based on this: http://haproxy.debian.net/
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.
The bud is built on the top of the libuv, which empowers the node.js.
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 basically done by moving the balancing between workers into the master, instead of calling `accept()` concurrently from the workers.
Impressive list of features. Does anyone know if HAProxy is used by any IAAS/PAAS providers?
Basically, bud can load the certificates and private keys for a domain name on the fly, without putting all of them into configuration.
- [MINOR] checks: add PostgreSQL health check
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.
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.
If you're a curious Ubuntu (14.04) user, it looks like the PPA to get version 1.5 is ppa:vbernat/haproxy-1.5. Based on this: http://haproxy.debian.net/
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.
- [MINOR] check: add redis check supportEarlier quoted context omitted.
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.
- partial data received by old HAProxy is lost as old HAProxy exits
- new HAProxy comes online, binds to port, receives fd
- iptables rule removed. new HAProxy starts receiving new requests
- in-flight requests from the old HAProxy are timed out by the kernel (TCP RST) as nothing is there to read request data from the old fd or send response data.
So I think this is actually "worse" in some sense than the other retry behavior since it's not recovered inside the same TCP session but instead forces the client to open a new TCP session.
Earlier quoted context omitted.
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 think the Redis checks are now native built in when looking at the changelog: - [MINOR] check: add redis check support
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.