Hi,
We're currently designing our web hosting architecture and have some
difficulty figuring out the best way to use Squid as reverse proxy.
Our first design looked like this:
INTERNET
|
+--------------+
|Load Balancer |
+--------------+
| |
+-------+ +-------+
|Squid_1| |Squid_2|
+-------+ +-------+
| |
+--------+ +--------+
|Apache_1| |Apache_2|
+--------+ +--------+
Both Squid and Apache servers are located on different physical locations
with different uplinks. When, for some reason, one of the locations goes
offline, the Load Balancer ensures the availability of the application.
In case of failure of the web server the problem is that the load balancer
is only aware if the reverse proxy on each location is available or not.
Whether the web server behind either of the reverse proxies is down is
unknown to it. Hence it will keep sending requests to the reverse proxy
behind which no active web server is available.
In order to exclude this risk we're looking at a couple of options of which
the first is to implement the load balancing function with Squid:
INTERNET
|
+--------------+
| Squid_0 |
+--------------+
| |
+-------+ +-------+
|Squid_1| |Squid_2|
+-------+ +-------+
| |
+--------+ +--------+
|Apache_1| |Apache_2|
+--------+ +--------+
As was explained on this list, in the case of single reverse proxy with two
cache_peer entries with different origin servers, “Squid detects [when] the
server is down and stops using it until it becomes alive again”[1]
My question is if this would be the case as well when, for example Apache_2
goes down? Is it possible to configure the Squid servers in such a way that
Squid_0 stops sending requests to Squid_2 that are normally handled by
Apache_2?
Thanks, David
[1]
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-reverse-proxy-load-balancing-td1028119.html
-- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Behavior-multiple-reverse-proxies-when-origin-server-down-tp4663464.html Sent from the Squid - Users mailing list archive at Nabble.com.Received on Fri Nov 22 2013 - 15:00:16 MST
This archive was generated by hypermail 2.2.0 : Mon Nov 25 2013 - 12:00:05 MST