Many installations would go from haproxy->nginx to nginx->nginx. Having to support a single product will make many devops happy. In the same tense, haproxy is adding Lua support[1], which has been available in nginx - using openresty[2] - since 2011, and nginx core is doing the same with Javascript[2]. Interesting times aroung haproxy and nginx. [1] http://blog.haproxy.com/2015/03/12/haproxy-1-6-dev1-and-lua/ [2] htt…
Not sure about that... HAproxy is a proven technology (very reliable and a joy to use at that) in this field while Nginx is a newcomer and needs to establish its credibility first. I personally wouldn't use such technology for load balancer until it is properly battle-tested. Also, I can't see much of an advantage over (proven) HAproxy - am I missing something? As for supporting a single product, I don't see the poin…
NGINX open sources TCP load balancing
61–70 of 121 posts
Re: NGINX open sources TCP load balancing
#62Why would somebody need a TCP load balancer in a web server ? Is there a use-case where the TCP load balancer being with the web-server made a lot of sense ? Integrating too many features into a single software can be risky as it may compromise simplicity and the UNIX way, 1 tool for 1 job..
Re: NGINX open sources TCP load balancing
#63Re: NGINX open sources TCP load balancing
#64Earlier quoted context omitted.
Not sure about that... HAproxy is a proven technology (very reliable and a joy to use at that) in this field while Nginx is a newcomer and needs to establish its credibility first. I personally wouldn't use such technology for load balancer until it is properly battle-tested. Also, I can't see much of an advantage over (proven) HAproxy - am I missing something? As for supporting a single product, I don't see the poin…
I think the April Fool's joke was around HAProxy being completely rewritten in Lua: http://www.haproxy.org/news.html
Re: NGINX open sources TCP load balancing
#65Earlier quoted context omitted.
Because I would still need to run NGINX alongside it to handle HTTP proxying. By removing HAProxy from the stack, I have one less component to manage/maintain/upgrade. I've used HAProxy for a long time and been very happy with it. But, everything else being equal, a stack with n-1 components is better than a stack of n components.
Why not use HAProxy for HTTP proxying? If you want to drop one component from the stack it could just as well be NGINX.
Re: NGINX open sources TCP load balancing
#66Perfect timing, at least for my company.
Re: NGINX open sources TCP load balancing
#67Earlier quoted context omitted.
Because HAproxy's ability to work with URLs and headers is close to unusable.
Surely you must have misread the docs, it's pretty damn powerful.
First, doing anything intelligent with HTTP slaughters HAproxy's performance by an order of magnitude because of the way you must configure it. Second, sticking requests to a backend is easy if you have a header that you want to decide upon. If you want to elect a different backend based upon a path component, this is much harder and yields an unwieldy configuration.
HAproxy is not designed to operate extensively on HTTP. It is designed to balance quickly and efficiently, and grew HTTP intelligence because people started wanting the convenience of making HAproxy do far more than its core focus. Rather than HAproxy getting smarter about HTTP, I'd much rather have the protocols that service my applications handle themselves and use HAproxy for its bread and butter, TCP availability and balancing. I can then focus on optimizing that using HAproxy's really clever mechanisms, like keeping the entire TCP conversation in kernel memory without reading it out (which you must do to "be powerful," as you say). This also means if I want to support SPDY or HTTP/2 or Websockets, I'm not waiting for HAproxy to support them because I painted myself in a corner.
The stack I've deployed at the frontend of every startup I've ever consulted for or operated looks like this:
/- [haproxy AZ A] -- [openresty AZ A]
[ELB] -- [haproxy AZ B] -- [openresty AZ B]
\- [haproxy AZ C] -- [openresty AZ C]
This is my Standard Frontend Deployment A. My other Standard Frontend Deployment, B, is if I have the budget and comprises Netscalers because of my experience with them from Google and other companies. Startup/low budget, ELB/haproxy/openresty. High budget, Netscaler and done.We are speaking to years of my own operational experience. I apologize if it sounded like dismissal; I actually think Tarreau would agree with my observation and opinion, if I'm perfectly honest.
Re: NGINX open sources TCP load balancing
#68Anyone know if the nginx TCP load balancing supports the PROXY protocol? Doesn't appear to, which is unfortunate.
Re: NGINX open sources TCP load balancing
#69HAProxy has been able to do SSL termination OR pass-thru. It's ability to do TCP load balancing allows it to do ssl pass-thru, where SSL connections are "passed through" to other servers (so the web nodes would de-encrypt the SSL connection, rather than the load balancer). This is a good use case for some where they prefer or require data to be encrypted up to the last minute (although it's not the only way to do it).
TCP load balancing is neat for doing things like load balancing MySQL connections, which aren't HTTP (although that's not necessarily recommended according to some things I've read).
I believe, but can't find the sources, that Nginx can be as efficient a load balancer as HAProxy. I know I for one would prefer to use Nginx over HAProxy to keep my stack simpler (same technologies throughout), although HAProxy may have more advanced balancing algorithms and some more power around it's tcp socket "API" for adding/removing nodes dynamically. (I think Nginx Plus can already do some of that).
Would love to hear the opinions of those with more experience/knowledge on the differences between the two!
Re: NGINX open sources TCP load balancing
#70Earlier quoted context omitted.
Not sure about that... HAproxy is a proven technology (very reliable and a joy to use at that) in this field while Nginx is a newcomer and needs to establish its credibility first. I personally wouldn't use such technology for load balancer until it is properly battle-tested. Also, I can't see much of an advantage over (proven) HAproxy - am I missing something? As for supporting a single product, I don't see the poin…
>>>>>> EDIT: btw, the Lua thing was an April Fool's joke... Are you sure ? The 1.6 dev repo contains Lua related code [1] [1] http://git.haproxy.org/?p=haproxy.git;a=blob_plain;f=src/hlu...