Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NGINX open sources TCP load balancing

hg.nginx.org

Post reply on HN
Print view View original

111–120 of 121 posts

Re: NGINX open sources TCP load balancing

#111

Post by dschiptsov »

IgorPartola wrote: post #109
dschiptsov wrote: post #107

Earlier quoted context omitted.

I would say that open source code base cannot be profitable in principle (and it should be completely open, like the Linux kernel, with all the new "hot" features development) but the services, you as a developer provide, could. Or let's say that one's knowledge and skills are profitable, not the code itself. The code should be open, so it could grow on the same pace as everything else grows, according to the real de…

Well, I think an OSS piece of software can be profitable if you can run it as a service. For example, WordPress (wordpress.com sells subscriptions), or Sentry (getsentry.com). Sure you can run your own, but why not pay someone to take care of that headache? However, I am looking specifically at nginx. The open version of it is too good and too complete, and by its nature it's not something you are going to run extern…

There is not a single complain about the quality of the nginx and its place as a "core service", on the contrary, it is a rare example of careful craftsmanship (Igor's code), a gold standard, if you wish.)

What I am trying to suggest is the simple idea that as long as the code become closed it cease to grow and become stagnant, but while it is open to everyone, like Linux kernel, and just grows and grows, it is not possible to monetize it, and the one possible working model is to develop new features sponsored by someone, like it is the case for the Linux kernel, or to sell your own services with open code, like so many do.

It seems like the model acquire, close and sell does not work with open source projects, because when it does not grow it dies (stagnates), just according to the laws of big numbers. Or rather it changes its status to being a commercial product, which is completely different story (paid developers, support, QA, etc) to which very few people would contribute - no one wants to grow other people's wealth.

Re: NGINX open sources TCP load balancing

#112

Post by MichaelGG »

CrLf wrote: post #102
MichaelGG wrote: post #28

Maybe they'll bring in the health checks for HTTP balancing, next :).

It already supports it: http://nginx.org/en/docs/http/ngx_http_upstream_module.html#... Or you're referring to something else?

" This directive is available as part of our commercial subscription. "

Re: NGINX open sources TCP load balancing

#113

Post by ibakirov »

haproxy is good enough with it's: - full stats rather os nginx stab_status (full stats only in nginx plus) - much load balancing mechanism support than os nginx (full support needs nginx plus, e.g: for sticky sessions)

for me, in the first place haproxy and then nginx

I good welcome opensourcing parts of nginx, take that way

Re: NGINX open sources TCP load balancing

#114

Post by ibakirov »

fasteo wrote: post #14

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…

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

Re: NGINX open sources TCP load balancing

#115

Post by cbsmith »

derefr wrote: post #97
cbsmith wrote: post #94

Earlier quoted context omitted.

> 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? ;-)

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…

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.

Re: NGINX open sources TCP load balancing

#116

Post by ibakirov »

fideloper wrote: post #69

That's neat! HAProxy 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…

Yes you right, both are good enough and everyone want to simplify his backend schemas...

I want to note big difference between haproxy and nginx, first of all "nginx is webserver" (nginx HTTP server) and then proxy/loadbalancer(may be used) whereas haproxy is pure loadbalancer. Enterprise bare metal and hardware appliances for proxy/loadbalance built on top of haproxy

nginx is wide spread because of usage as good minimalistic web server

Re: NGINX open sources TCP load balancing

#117

Post by jzelinskie »

cbsmith wrote: post #93
jzelinskie wrote: post #92

Earlier quoted context omitted.

I agree. nginx already supports forwarding from proxy protocol[0] via the http_realip module; time to go full circle. [0]: http://nginx.org/en/docs/http/ngx_http_realip_module.html

I've had problems getting that module to work properly with AWS ELB (though I'd kind of assumed the problem was with ELB), so I'm not sure how solid the support is even for that. It'd be nice to test it against nginx itself as a baseline.

We use proxy protocol ELB -> nginx in production at CoreOS for Quay.io, but we use the Tengine 2.1.0 fork of nginx for some other patches.

http://tengine.taobao.org/

Re: NGINX open sources TCP load balancing

#118

Post by wtarreau »

jsmthrowaway wrote: post #67
jvehent wrote: post #41

Earlier quoted context omitted.

Surely you must have misread the docs, it's pretty damn powerful.

I ran 1.4 in production at a 8,000+ QPS social network, have been on a team who submitted patches to Tarreau that are now in HAproxy, and very intentionally put Openresty behind it for HTTP after months of tweaking a very fragile HAproxy configuration with several applications hanging off our property's domain name. I also architected and built a LBaaS product at a well-known hosting provider using HAproxy. I didn't…

Well, I don't know what you refer to by "doing anything intelligent with HTTP slaughters HAproxy's performance by an order of magnitude". What particularly intelligent makes it slow ? I'd say it's supposed to be quite the opposite as we take great care of making it possible to write almost any configuration without having to use regex for example. We've added rules to rewrite parts of the request by combining other elements thanks to the format strings being used in all HTTP rules. You have sample fetch functions which extract various contents quite quickly and allow you to reinject them anywhere very quickly as well.

Some users reported more than 400k requests per second in HTTP mode, or 50 times more than what you experience. Sure, here any form of HTTP processing adds a few nanoseconds to the processing time and will slightly lower the numbers. But 8k is the level of performance you should expect from tens of thousands of HTTP rules which probably is not what you're doing.

So I'm interested in knowing what trouble you're experiencing. Feel free to bring that to the mailing list, a design is always better when more people are involved.

Re: NGINX open sources TCP load balancing

#119

Post by wtarreau »

dedward wrote: post #33
[deleted] wrote: post #24

Earlier quoted context omitted.

[deleted]

udp is trivial to load balance.... plenty support it.

Loadbalancing UDP is trivial but totally useless without protocol awareness. Loadbalancing UDP properly is much less trivial because most UDP-based protocols need to be handled properly and rewritten since they carry IP addresses, ports, and even expect reverse connections (eg: tftp). In fact the only two UDP-based protocols that you can load-balance without doing anything are syslog and DNS. Both of them are useless as they are properly dealt with by the sender.

Re: NGINX open sources TCP load balancing

#120

Post by wtarreau »

hbz wrote: post #60
adrenalinup wrote: post #56

Why 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..

http://en.wikipedia.org/wiki/WebSocket are a completely legitimate use.

WebSocket works over HTTP, not TCP. A properly implemented HTTP stack will have no problem passing WebSocket to the next server. Some non-compliant HTTP stack still experience trouble with it though.
Post reply on HN