I'm using HAProxy in two use cases.
The first is as an internal load balancer for OpenStack services, in private cloud solutions. So HAProxy is used in front of Galera (MySQL cluster), Nova API, and also in front of exposed docker services.
The second use case is as a load balancer for a Web hosting solution. HAProxy is load balancing external traffic.
Configuration of HAProxy includes brute force sandboxing (including stick tables and hardcoded ACL for defined paths), splitting traffic by dynamic and static content to redirect it to the proper back-end, SSL, and HTTP headers management.
I can simplify configurations of many internal services (e.g. Web server configs) by moving some elements (like SSL) to HAProxy. I can also disable additional applications, like Varnish, by moving traffic shaping configurations to HAProxy.
Advanced traffic rules, including stick tables and ACLs, which allow me to shape traffic while it's load balanced.
Performance configuration options with threads, processes, and core stickiness are also very valuable.
In my opinion, there are three main areas to improve:
- Make remote management more modern by adding API.
- Propose a general HA solution for HAProxy (no I'm using keepalived for this).
- Thread option should be a bit more stable.
One to three years.
No issues with stability.
No issues with scalability, but multiprocess config for HAProxy is more efficient than multi-thread.
I used NGINX in my Web environment. HAProxy has more traffic shaping options and it's a dedicated VNF load-balancer.
Initial setup was straightforward. The documentation is pretty thorough and up to date, and it is also easy to search.
During the implementation, you have to plan ACLs and back-ends first. That allows you to prepare a cleaner config.
I rate HAProxy a 10 out of 10. It is fast, flexible, and rock solid.
We use haproxy and I feel the same as the reviewer. Works great, easy to setup and change. Just works! We have open source version running on Centos.