3 ms·

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

• 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.
• aleem 12y ago
  Not to mention the vast ecosystem of some really great nginx plugins. The one thing I have found desperately wanting in both nginx and haproxy is the support for real-time stats and filtering found in Varnish (supports HTTP only). I am absolutely hooked! // Query Times varnishncsa -F '%t %{VCL_Log:Backend}x %Dμs %bB %s %{Varnish:hitmiss}x "%r"' // Slow Queries varnishncsa -F '%t %{VCL_Log:Backend}x %Dμs %bB %s %{Varnish:hitmiss}x "%r"' -m "VCL_Log:SlowQuery" // Top URLs varnishtop -i RxURL // Top Referer, User-Agent, etc. varnishtop -i RxHeader -I Referer varnishtop -i RxHeader -I User-Agent // Cache Misses varnishtop -i TxURL // awesome dashboard varnishstat
  • gmjosack 12y ago
    I've been able to get real-time stats in nginx by adding custom counters with the lua plugin and exporting a stats handler. http://wiki.nginx.org/HttpLuaModule#ngx.shared.DICT http://wiki.nginx.org/HttpLuaModule#ngx.shared.DICT
    • phildougherty 12y ago
      You can also use collectd nginx module along with nginx stub-status module to gather some useful metrics.
• mostafah 12y ago
  Awesome news for nginx users. But why should the first reaction should be about criticizing the other option? Some HAProxy users may or may not switch to this new product in the coming years. I probably won’t. Even today there is a big overlap between what HAProxy, nginx, and some other tools do and yet everybody works with what they prefer. Adding another feature that until now HAProxy had and nginx didn’t have doesn’t mean a dramatic time for this “competition” (even if such a thing exists).
• ibakirov 12y ago
  nginx lacks of many good improvements and fixes which does not accepted upstream devs, so nginx has so many 3rd party modules which most of them are invalid because of nginx version changes or requires old buggy nginx version to run openresty well it is standalone product, it is build on top nginx with many 3rd party modules and many improvements accepted/not accepted by upstream, and of course big Lua support