Explain load-balancing with Nginx like I'm five

Question

I've found plenty of DIY posts and tutorials on how to configure Nginx as a load-balancer using upstream server:

upstream backend  {
  ip_hash;
  server 1.2.3.4;
  server 1.2.3.5;
  server 1.2.3.6;
}

server {
  location / {
    proxy_pass  http://backend;
  }
}

But that's the extent to what I can find as far as configuring this architecture. Currently I have a rails application deployed to 3 backend VPS servers and I'm using Unicorn for my HTTP server. Do I need my ruby installed along with my rails application and unicorn on my load-balancing server as well? Do I need Nginx to be installed on each of the upstream servers? If so, how do I configure them? If I introduce something like Varnish to the architecture, where does that go? In front of the load-balancer or each of the backends?

Here's a visual of how I have everything organized:

                                       +---> backend1 <---+
                                       |                  |
[requests] <---> [Nginx load-balancer]-+---> backend2 <---+-[Database server]
                                       |                  |
                                       +---> backend3 <---+

score 4 · Accepted Answer · answered Dec 26 '13 at 21:24

Short answer:

Nginx really only has one job, and that job is to accept an incoming request and hand it off to a backend server.

Given that, your front end server(s) only need to run nginx and your backend server(s) only need to run rails. Make sense?

Now, if your backend and frontend are both running on the same server then, yes, of course, it would have to be installed there too, but from your diagram I do not believe that is the case.

If you introduce an HTTP caching software, such as Varnish, it would go between Nginx and Rails, most likely also running on the backend server. So requests would follow this path:

Nqinx -> Varnish -> Rails

score 3 · Answer 2 · answered Dec 27 '13 at 14:18

When working with Rails, nginx can be used to serve several roles, most often as an HTTP load balancer or as an app server front-end. Your setup is a common one that will work, but may impose scaling challenges as you grow to higher levels of traffic.

When you're working with a handful of VPS servers as you describe, one nginx instance can server as both the primary HTTP load balancer for incoming traffic and a front-end to off-load low-level responsibilities from the Rails app servers (serving static files, URL rewrites/redirects, etc).

nginx can handle many thousand concurrent connections without many resources, while Unicorn Rails app servers usually can only service a handful of concurrent connections. As you scale more, you will need more load balancer/front-end nginx instances (and a method of load balancing between them, like DNS round-robin or other mechanisms).

If you use Amazon AWS or other more mature hosting platforms, using a service like Elastic Load Balancing (ELB) as the primary web load balancer is often used. Each app server runs nginx/Unicorn, utilizing nginx as a front-end to off-load processing from each Unicorn. This is much easier to scale, due to the high-volume ELB in front of each server.

So from the sounds of it, it's not simply a matter of adding more backends as the need arises, but front-ends too? — Cyle, Dec 27 '13 at 14:42
The main problem with a single load balancer is that it's a single point of failure due to bugs, maintenance, and load. — Winfield, Dec 27 '13 at 17:08

Explain load-balancing with Nginx like I'm five

2 Answers2