3 ms·

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 it

by amenod 12y ago

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 point of that. Using Nginx for load balancing will probably be much different than using Nginx as a web server, so the learning curve is similar. Not that I don't welcome competition, I just don't see a real need in this space. EDIT: btw, the Lua thing was an April Fool's joke... EDIT 2: no it wasn't, my mistake. I was surprised by this so I checked the page and jumped a gun when I saw "April 1st" on http://www.haproxy.org/news.html http://www.haproxy.org/news.html. Sorry about that...

phildougherty 12y ago
Nginx has supported http loadbalancing basically forever using the upstream directive along with proxy_pass. It supports leastconn, round-robin, and ip-hash (sticky). It is far from unproven. I have personally used it successfully in some huge projects. This new announcement simply makes the existing functionality work with tcp backends.
shuzchen 12y ago
For anyone already using nginx in their stack, I don't think these things (being a newcomer, or needing credibility) are a very big concern. Some people are already used to using nginx as a load balancer for HTTP traffic (this new feature adds load balancing for any TCP traffic) so those users won't have much gap to cover. Also this feature was in the nginx+ version, which presumably means it has already been battle-tested by their enterprise customers.
- cbsmith 12y ago
  There is a world of difference between layer-3/4 style load balancers and layer-7 load balancers. If you want to do it right, you often employ both.
fasteo 12y ago
>>>>>> 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/hlua.c;hb=8747b6dbc88f1d9ba0a2b34c0fbe7cacdf4556f1 http://git.haproxy.org/?p=haproxy.git;a=blob_plain;f=src/hlu...
- gapchuboy 12y ago
  I think, the Lua rewrite was a joke. But support for lua in haproxy is not.
robusto 12y ago
I think the April Fool's joke was around HAProxy being completely rewritten in Lua: http://www.haproxy.org/news.html http://www.haproxy.org/news.html
- amenod 12y ago
  Oops, you are correct... the joke is on me. Thanks for correcting me.
rdtsc 12y ago
nginx is definitely not quite a newcomer. Someone already mentioned it but it already proxied http for many year. Moreover it proxies websockets, which are basically long lived TCP connections.
sparaker 12y ago
HAProxy offers a better DDos mitigation configurables in comparison to nginx. Thats it.
- phildougherty 12y ago
  CloudFlare is build on top of OpenResty which is basically stock nginx with ngx_lua and a bunch of other modules built in. I would argue that if you want it to be, nginx can be much better at DDoS mitigation. You can use the modules limit_conn and limit_req to control how many connection individual IPs can make to your server for basic control.
  - mkhpalm 12y ago
    You can add various things on top of nginx... but you can use stock haproxy to limit the number of connections by source IP.
    - jhgg 12y ago
      This can also be achieved in nginx fairly easy: http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html#limit_conn http://nginx.org/en/docs/http/ngx_http_limit_conn_module.htm...
derefr 12y ago
> As for supporting a single product, I don't see the point of that. It's not about configuration; it's about security. Fewer products in your stack means fewer things to patch. Rather than updating nginx some times and haproxy other times, you just update nginx across all your machines (both web servers and load balancers), and you're done. This also gives you more time with which to vet any given nginx update.
- cbsmith 12y ago
  > It's not about configuration; it's about security. Fewer products in your stack means fewer things to patch. Kind of the reverse of the defense-in-depth principle eh? ;-)
  - derefr 12y ago
    Defense-in-depth doesn't work very well for infrastructure software packages: many projects share the same libraries with the same vulnerabilities (e.g. OpenSSL) but still have to be updated with independent package updates. A shared-library vulnerability means both Nginx and HAProxy get broken in their own ways, which is worse, I think, than just having your whole stack rely on one or the other, and having that one break—it's more similar to having two independent vulnerabilities arise simultaneously.
    - cbsmith 12y ago
      You're only going to do TLS encrypt/decrypt in one place, so in that particular case... something is wrong. However, the scenario you describe is one where you would likely NOT be doing defense in depth, because you'd be using the same library to handle a vital piece of your security infrastructure. Regardless, when a shared library is updated for security, you don't need to apply updates to packages using the shared library. That's kind of the point. The only exception is when the flaw is in the interface to the library. The win entirely derives from the case of having the two independent vulnerabilities. Since they are broken in their own ways it isn't sufficient to find a way to exploit one system (which would work great for attacking a system with both). You have to find a way to exploit each, and you have to find a way to connect the two so you can get all the way through.

by amenod 12y ago

phildougherty 12y ago

Nginx has supported http loadbalancing basically forever using the upstream directive along with proxy_pass. It supports leastconn, round-robin, and ip-hash (sticky). It is far from unproven. I have personally used it successfully in some huge projects. This new announcement simply makes the existing functionality work with tcp backends.

shuzchen 12y ago

For anyone already using nginx in their stack, I don't think these things (being a newcomer, or needing credibility) are a very big concern. Some people are already used to using nginx as a load balancer for HTTP traffic (this new feature adds load balancing for any TCP traffic) so those users won't have much gap to cover. Also this feature was in the nginx+ version, which presumably means it has already been battle-tested by their enterprise customers.

cbsmith 12y ago
There is a world of difference between layer-3/4 style load balancers and layer-7 load balancers. If you want to do it right, you often employ both.

fasteo 12y ago

>>>>>> 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/hlua.c;hb=8747b6dbc88f1d9ba0a2b34c0fbe7cacdf4556f1 http://git.haproxy.org/?p=haproxy.git;a=blob_plain;f=src/hlu...

gapchuboy 12y ago
I think, the Lua rewrite was a joke. But support for lua in haproxy is not.

robusto 12y ago

I think the April Fool's joke was around HAProxy being completely rewritten in Lua: http://www.haproxy.org/news.html http://www.haproxy.org/news.html

amenod 12y ago
Oops, you are correct... the joke is on me. Thanks for correcting me.

rdtsc 12y ago

nginx is definitely not quite a newcomer. Someone already mentioned it but it already proxied http for many year. Moreover it proxies websockets, which are basically long lived TCP connections.

sparaker 12y ago

HAProxy offers a better DDos mitigation configurables in comparison to nginx. Thats it.

phildougherty 12y ago
CloudFlare is build on top of OpenResty which is basically stock nginx with ngx_lua and a bunch of other modules built in. I would argue that if you want it to be, nginx can be much better at DDoS mitigation. You can use the modules limit_conn and limit_req to control how many connection individual IPs can make to your server for basic control.
- mkhpalm 12y ago
  You can add various things on top of nginx... but you can use stock haproxy to limit the number of connections by source IP.
  - jhgg 12y ago
    This can also be achieved in nginx fairly easy: http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html#limit_conn http://nginx.org/en/docs/http/ngx_http_limit_conn_module.htm...

derefr 12y ago

> As for supporting a single product, I don't see the point of that. It's not about configuration; it's about security. Fewer products in your stack means fewer things to patch. Rather than updating nginx some times and haproxy other times, you just update nginx across all your machines (both web servers and load balancers), and you're done. This also gives you more time with which to vet any given nginx update.

cbsmith 12y ago
> It's not about configuration; it's about security. Fewer products in your stack means fewer things to patch. Kind of the reverse of the defense-in-depth principle eh? ;-)
- derefr 12y ago
  Defense-in-depth doesn't work very well for infrastructure software packages: many projects share the same libraries with the same vulnerabilities (e.g. OpenSSL) but still have to be updated with independent package updates. A shared-library vulnerability means both Nginx and HAProxy get broken in their own ways, which is worse, I think, than just having your whole stack rely on one or the other, and having that one break—it's more similar to having two independent vulnerabilities arise simultaneously.
  - cbsmith 12y ago
    You're only going to do TLS encrypt/decrypt in one place, so in that particular case... something is wrong. However, the scenario you describe is one where you would likely NOT be doing defense in depth, because you'd be using the same library to handle a vital piece of your security infrastructure. Regardless, when a shared library is updated for security, you don't need to apply updates to packages using the shared library. That's kind of the point. The only exception is when the flaw is in the interface to the library. The win entirely derives from the case of having the two independent vulnerabilities. Since they are broken in their own ways it isn't sufficient to find a way to exploit one system (which would work great for attacking a system with both). You have to find a way to exploit each, and you have to find a way to connect the two so you can get all the way through.