[squid-users] setting up cache peering

[Amos Jeffries]

On 2/12/2015 6:50 p.m., Alex Samad wrote:
> Hi
> 
> I recently moved to squid-3.5.11-1.el6.x86_64 on centos 6.7.
> 
> from the centos 3.1 i think ?
> 
> This what I had originall
> #cache_peer gsdmz1.xy.com sibling 3128 3130 proxy-only
> #cache_peer alcdmz1.xy.com sibling 3128 3130 proxy-only
> 
> I had a shared config between the 2 server gsdmz1 and alcdmz1. I would
> uncomment 1 or the other depending.
> 
> during my upgrade I coped the gsdmz1 squid config over to alcdmz1 but
> forgot to uncomment the
> cache_peer alcdmz1.xy.com sibling 3128 3130 proxy-only
> 
> so alcdmz1 was talking to itself at times.
> 
> using this as my test
> wget -d   http://www.smh.com.au/business/markets-live/markets-live-investors-take-stock-20151201-gld1lu.html
> -O /dev/null
> 
> and setting http_proxy to either alc or gsdmz1 I would get a 504 error.
> 
> 
> wget -d  http://www.smh.com.au/business/markets-live/markets-live-investors-take-stock-20151201-gld1lu.html
> -O /dev/null
> Setting --output-document (outputdocument) to /dev/null
> DEBUG output created by Wget 1.12 on linux-gnu.
> 
> --2015-12-02 16:35:34--
> http://www.smh.com.au/business/markets-live/markets-live-investors-take-stock-20151201-gld1lu.html
> Resolving alcdmz1... 10.3.2.111
> Caching alcdmz1 => 10.3.2.111
> Connecting to alcdmz1|10.3.2.111|:3128... connected.
> Created socket 4.
> Releasing 0x0000000001ea5db0 (new refcount 1).
> 
> ---request begin---
> GET http://www.smh.com.au/business/markets-live/markets-live-investors-take-stock-20151201-gld1lu.html
> HTTP/1.0
> User-Agent: Wget/1.12 (linux-gnu)
> Accept: */*
> Host: www.smh.com.au
> 
> ---request end---
> Proxy request sent, awaiting response...
> ---response begin---
> HTTP/1.1 504 Gateway Timeout
> Server: squid
> Mime-Version: 1.0
> Date: Wed, 02 Dec 2015 05:35:34 GMT
> Content-Type: text/html;charset=utf-8
> Content-Length: 4063
> X-Squid-Error: ERR_ONLY_IF_CACHED_MISS 0
> Vary: Accept-Language
> Content-Language: en
> X-Cache: MISS from gsdmz1
> X-Cache-Lookup: MISS from gsdmz1:3128
> X-Cache: MISS from alcdmz1
> X-Cache-Lookup: MISS from alcdmz1:3128
> Via: 1.1 gsdmz1 (squid), 1.1 alcdmz1 (squid)
> Connection: close
> 
> ---response end---
> 504 Gateway Timeout
> Closed fd 4
> 2015-12-02 16:35:34 ERROR 504: Gateway Timeout.
> 

*timeout* is terribly bad. Turn the Via header back on. Its sole purpose
is to let the peers reject messages that are looping like that one.

> 
> I changed the line to be
> cache_peer gsdmz1.xy.com sibling 3128 3130 proxy-only standby=50
> on the alcdmz1 box
> and
> cache_peer alcdmz1.xy.com sibling 3128 3130 proxy-only standby=50
> on the gsdmz1 box
> 
> but this still gave me 504 errors ?

Notice how the difference in configurations is that you added
standby=50. It should not be having any effect that we know of, but does
mean that connections are pre-opened to the sibling and thus have a much
lower latency than any normal TCP connection. If your Squid is searching
for fastest-route using the netdb latency tables that could be the
opposite of what you need.

> I tried to force a new version through both proxies by using wget with
> no-cache option.  But that didn't help.

Sending "no-cache" from the client makes it worse, since that prevents
HIT from happening on either peer.

When combined with "cache_peer ... proxy-only" configuration it prevents
any traffic that goes through a peer from being cached.

> 
> So what went wrong, how can I flush out the stale 504.

It is not cached. There is nothing to flush (except perhapse the standby
connections, see above).

> What is the best way to setup the 2 proxies to talk to each other
> before going out to the internet.

That depends on the proxies, version, and what you want them to do.

> 
> the proxies run on a pacemaker cluster. I have 2 vip's setup as the
> proxy addresses, in normal conditions these address are setup 1 on
> each server. whilst working on a server I can move the vip and not
> affect any one.

What you have appears to be almost correct. Since you are dealing with
3.1 vs 3.5, you need to keep in mind the differences in behaviour
between HTTP/1.0 (3.1) and HTTP/1.1 (3.5).

One of the side effects is that the default peer query messaging is ICP
which does not work at all well with HTTP/1.1 Vary caching. HTCP was
designed to avoid those problems, but needs turning on explcicitly.

> 
> 
> But I would like to take benefit of each others cache, whats the best
> setup for cache_peer in this setup.
> 
> Neither server is closer to the internet.
> 


I suggest you:

1) add the "htcp" option to the cache_peer lines. So the peer selection
can use the full HTTP/1.1 headers to decide if the peer cached object is
actually usable.

2) Remove the "via off" from your config file.

3) remove the standby= parameter from cache_peer until you have at least
got the original setup working.


There might be other things involved, but we cant know that without the
details about those things existence or absence from your config.

Amos