[squid-users] Sibling cache_peer inside docker containers

[Amos Jeffries]

On 26/04/19 12:00 pm, interwebbot wrote:
> I have 2 squid instances running inside docker containers on the same host. I
> am trying to set these two instances as cache_peer siblings for storage
> optimization. Here is the config I am using:
> 
> 
> 
> http_port 3128
> 
> acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
> acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
> acl localnet src fc00::/7       # RFC 4193 local private network range
> acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged)
> machines
> acl squid-(1/2)  src 172.17.0.(2/3)


Is this above what you actually have in the config file?
 or a (x/y) syntax you made up to represent each of the config files
having similar but not identical entries:

 acl squid-1  src 172.17.0.2
 acl squid-2  src 172.17.0.3

There are places where you should have different values but do not use
this syntax. So it is not clear if those were mistakes in the config or
mistakes in the email. Please show exactly what is in each config file
respective to these lines and the cache_peer lines.


Notice that these 172.17.0.* are matched by the localnet 172.16.0.0/12
CIR range. That means the "allow localnet" rule will be allowing traffic
and your "allow squid-2" rule is never reached.

...
> #
> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> #
> 
> http_access allow localnet
> http_access allow localhost
> http_access allow squid-2
> http_access deny all
> 
> coredump_dir /squid/var/cache/squid
> 
> icp_port 3130
> cache_peer 172.17.0.(2/3) sibling 3128 3130 default #proxy-only

"default" is only relevant when there are multiple peers to choose from
and the first is not the preferred default, or a second selection
algorithms is being used.


> prefer_direct off
> icp_access allow all
> icp_query_timeout 500
> debug_options ALL,1 12,5 42,3
> 
> refresh_pattern ^ftp:           1440    20%     10080
> refresh_pattern ^gopher:        1440    0%      1440
> refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
> refresh_pattern .               0       20%     4320
> 
> cache_store_log /var/log/squid/store.log
> 
> 
> To test if this is working, I am trying the following test:
>  > curl -x http://127.0.0.1:3131 -L http://example.com (this results in a
> MISS from squid-1 as expected)
>  > curl -x http://127.0.0.1:3131 -L http://example.com (this results in a
> HIT from squid-1 as expected)
> 
>  > curl -x http://127.0.0.1:3132 -L http://example.com (this results in a
> MISS from squid-2. NOT EXPECTED)
> 


The Squid.conf you presented does not contain any http_port 3131 or
3132. How is the traffic getting from these to the 3128 Squid is opening?
 Also are both logging that their 3128 listening attempt was successful?


The details you are presenting are not clear and definitive about what
is going on.


> Am I correct in assuming that last curl should result in a HIT instead of
> MISS? 

Unknown. Which proxy is receiving the traffic from curl?

Which peer is receiving the 3130 UDP traffic?
 Is that a different port on each peer which you forgot to mention?

Is the "proxy-only" flag disabled in both configs?
 Best erase it entirely than rely on the "#" handling. The # behaviour
is not consistent with all directives.


Please be aware that both caches start off is a "cold" state with no
content including knowledge about other caches/peer contents or RTT
network properties. The first request(s) through them trigger a probe to
get better info and log as MISS - but waiting for that probe to produce
data can mean DIRECT connection is more efficient for that request.

The *second* request through is what should be expected to choose
best-path with details to optimize the choice of "best". In this case
the local cache produces a HIT - which is better than any network path
and can hide the RTT sibling lookup behaviours.


(Details like these are why its often best to show both configs, even if
they have a lot of overlap).


> If yes, what is wrong with my config?
> 

Any answer would have to be based more on assumptions about what you
mean than the details provided so far.

Amos