2

While creating a load balanced and reverse proxy based architecture, how would the two be placed?

Is this the correct architecture? First LB server, then proxy: - When client hits a URL, it is basically a load balancer, which has multiple reverse proxy servers sitting behind it. It calls a reverse proxy server, which in turn gathers data from multiple servers and afulfills the request

Is there a possibility of First proxy server then LB server?

Or am I totally missing the plot?

3 Answers 3

4

As Jesper mentioned, you need more details.

What is the role of the reverse proxy in this situation? Is the goal performance, high availability or both?

Some load balancers do URL filtering, so if the proxy is just routing traffic (not caching), then you may not need a proxy at all.

How much of the traffic can be cached? Where are your bottlenecks?

Lately, I've been using this stack with good results for a PHP based application:

HAProxy --> Varnish --> Nginx --> PHP-FPM --> MySQL/NFS server

What we found is about 70% of all requests can be served from the Varnish cache. We considered putting Varnish out front but a single Varnish server cannot handle the load. So we would need to load balance anyway.

This creates a single point of failure at the LB level, but our client is fine with it as we can spin up a new instance in about 5 minutes. They are willing to risk 5-10 minute outage rather than have a more complicated infrastructure with dual HA-Proxy servers.

Each usage case varies and only through testing can you find the best solution that fits the budget.

2
  • +1 As mentioned I do not have enough points to vote you up, thanks for the tips..you guys rock! May 3, 2013 at 14:37
  • 1
    What is the role of Nginx is this case? Ssl? And what can it do that haproxy that is in the front cant do? Thank you! Oct 5, 2017 at 12:13
1

Here's what I generally do.

Have 2 varnish servers out front with a shared IP via keepalive in case one dies. as my reverse proxy.

Behind it (or on the same server) sit haproxy doing the load balancing.

Varnish also supports load balancing to backends but you don't get the nice stats or control as you do with haproxy. If you go with a hardware load balancer.. chances are that would be up front first since that might also be your firewall.

In the end.. it really depends on how you want to lay it out.

1
  • +1 I cannot vote you up since I dont have enough rep, but thanks for the tips! I will take a look at haproxy May 3, 2013 at 14:36
1

It depends on your more detailed and specific needs, so it's not really possible to answer based on the info you have given. Both your suggestions are valid and good solutions in certain cases.

As always ... profile your live production load, and benchmark the appliances/the software you're working with for proxying and load balancing.

In general:

  • If you need SSL, then much will depend on whether the LB or proxy handles SSL best. Generally, you'd want to handle SSL on the edge of your network, i.e. on the first server(s).

  • If you need multiple proxy servers to handle the load, that would push towards LB --> proxie(s) --> LB --> App Servers (or using crude DNS Round Robin to coarsely distribute load to multiple proxies).

  • If you need consistent hashing in front of your proxies, then that would push towards LB --> proxie(s) --> LB --> App Servers and a load balancer which supports consistent hashing.

  • If a single proxy can handle your load, then proxy --> LB --> App Servers is simplest. Some proxies, like Varnish, even have a basic load balancer built in.

Willy Tarreau, author of the excellent HAProxy, has written a nice article about common front end load balancing / SSL offload / proxying architectures.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .