Advice on Cache Peer ACLs

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Advice on Cache Peer ACLs

creditu
We use several squid servers in accelerator mode for load balancing to send public requests to backend servers.   The squids don't do any caching, they just forward requests to the backend.

We have cache_peer directives to send the incoming requests to the backend Apache servers.  What I need to do is send requests to a certain page to a specific backend server and all others to the  other backends.  The site has many pages, subpages etc.  

What I want to do is if someone requests:
https://www.example.com/anything/anything/script.php   or https://origin-www.example.com/anything/anything/etc/etc/script.php

Send the request to only .1, .2,.3.

If someone requests :
https://www.example.com/anything/tst/map2/script.php   or https://origin-www.example.com/anything/anything/tst/map1/etc/script.php

Send that request only to .4 and .5.

It seems to work most of the time, but tailing the access logs on the servers I sometimes see one of the requests for ../tst/map2/... or map1 show up on .1,.2, or .3.  

Is there something I'm missing?

Here is what I have so far.

acl all_requests dstdomain -n www.example.com origin-www.example.com
acl limited  url_regex -i /tst/map1|/tst/map2


cache_peer 192.168.1.1 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
cache_peer_access 192.168.1.1 deny limited
cache_peer_access 192.168.1.1 allow all_requests
cache_peer_access 192.168.1.1 deny all

cache_peer 192.168.1.2 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
cache_peer_access 192.168.1.2 deny limited
cache_peer_access 192.168.1.2 allow all_requests
cache_peer_access 192.168.1.2 deny all

cache_peer 192.168.1.3 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
cache_peer_access 192.168.1.3 deny limited
cache_peer_access 192.168.1.3 allow all_requests
cache_peer_access 192.168.1.3 deny all

cache_peer 192.168.1.4 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
cache_peer_access 192.168.1.4 allow limited
cache_peer_access 192.168.1.4 deny all

cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
cache_peer_access 192.168.1.5 allow limited
cache_peer_access 192.168.1.5 deny all

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Advice on Cache Peer ACLs

Alex Rousskov
On 8/30/19 11:44 AM, [hidden email] wrote:

> We use several squid servers in accelerator mode for load balancing to send public requests to backend servers.   The squids don't do any caching, they just forward requests to the backend.
>
> We have cache_peer directives to send the incoming requests to the backend Apache servers.  What I need to do is send requests to a certain page to a specific backend server and all others to the  other backends.  The site has many pages, subpages etc.  
>
> What I want to do is if someone requests:
> https://www.example.com/anything/anything/script.php   or https://origin-www.example.com/anything/anything/etc/etc/script.php
>
> Send the request to only .1, .2,.3.
>
> If someone requests :
> https://www.example.com/anything/tst/map2/script.php   or https://origin-www.example.com/anything/anything/tst/map1/etc/script.php
>
> Send that request only to .4 and .5.
>
> It seems to work most of the time, but tailing the access logs on the servers I sometimes see one of the requests for ../tst/map2/... or map1 show up on .1,.2, or .3.  


Do Squid access logs have the corresponding records as well? What cache
peer selection algorithm does Squid record for those misdirected
transactions?


> Is there something I'm missing?

Could Squid go direct to one of those origin servers (e.g., when all
eligible cache peers were down)?

BTW, please note that your cache_peer_access rules look inconsistent:
Your cache_peer_access .1-3 rules require certain domain names but .4-5
rules do not. This does not explain the discrepancy you are describing
above, but you may want to adjust your rules for consistency sake
(either to ignore dstdomain completely or to require correct domains for
all cache peers).


HTH,

Alex.


> acl all_requests dstdomain -n www.example.com origin-www.example.com
> acl limited  url_regex -i /tst/map1|/tst/map2
>
>
> cache_peer 192.168.1.1 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> cache_peer_access 192.168.1.1 deny limited
> cache_peer_access 192.168.1.1 allow all_requests
> cache_peer_access 192.168.1.1 deny all
>
> cache_peer 192.168.1.2 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> cache_peer_access 192.168.1.2 deny limited
> cache_peer_access 192.168.1.2 allow all_requests
> cache_peer_access 192.168.1.2 deny all
>
> cache_peer 192.168.1.3 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> cache_peer_access 192.168.1.3 deny limited
> cache_peer_access 192.168.1.3 allow all_requests
> cache_peer_access 192.168.1.3 deny all
>
> cache_peer 192.168.1.4 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> cache_peer_access 192.168.1.4 allow limited
> cache_peer_access 192.168.1.4 deny all
>
> cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> cache_peer_access 192.168.1.5 allow limited
> cache_peer_access 192.168.1.5 deny all
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Advice on Cache Peer ACLs

squid-5
Thank you for the reply.  It appears that I had a IP address typo in one of the cache_peer lines that allowed the requests with /tst/map1 or map2 to slip bye.  It appears to be working.  I think you confirmed what I'm trying to do should work.

One question about your last statement concerning inconsistent  domain names.  All requests will always start with www.example.com /.... or origin-www.example.com/.....  even the ones what I'm trying to send to specific backends using the "limited" acl.

Are you saying I should have the following for .4 and .5 instead of what I'm currently using?  

 cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
 cache_peer_access 192.168.1.5 allow limited
cache_peer_access 192.168.1.5 allow all_requests
 cache_peer_access 192.168.1.5 deny all

I was trying to limit the requests to .4 and .5 to only those that contained /tst/map1 or map2.  I thought if I included the "allow all_requests" line in .4 and .5 it would send requests that also did not include /tst/map2 or map2.  For example "origin-www.example.com/hello/test/etc"  could possibly be sent to .4 and .5 as well.  

How do I ensure that www.example.com/tst/map1/..... and map2 only go to .4 and .5 while still correctly being consistent with the domain was you suggested.  Thanks.  

On Fri, Aug 30, 2019, at 11:41 AM, Alex Rousskov wrote:

> On 8/30/19 11:44 AM, [hidden email] wrote:
> > We use several squid servers in accelerator mode for load balancing to send public requests to backend servers.   The squids don't do any caching, they just forward requests to the backend.
> >
> > We have cache_peer directives to send the incoming requests to the backend Apache servers.  What I need to do is send requests to a certain page to a specific backend server and all others to the  other backends.  The site has many pages, subpages etc.  
> >
> > What I want to do is if someone requests:
> > https://www.example.com/anything/anything/script.php   or https://origin-www.example.com/anything/anything/etc/etc/script.php
> >
> > Send the request to only .1, .2,.3.
> >
> > If someone requests :
> > https://www.example.com/anything/tst/map2/script.php   or https://origin-www.example.com/anything/anything/tst/map1/etc/script.php
> >
> > Send that request only to .4 and .5.
> >
> > It seems to work most of the time, but tailing the access logs on the servers I sometimes see one of the requests for ../tst/map2/... or map1 show up on .1,.2, or .3.  
>
>
> Do Squid access logs have the corresponding records as well? What cache
> peer selection algorithm does Squid record for those misdirected
> transactions?
>
>
> > Is there something I'm missing?
>
> Could Squid go direct to one of those origin servers (e.g., when all
> eligible cache peers were down)?
>
> BTW, please note that your cache_peer_access rules look inconsistent:
> Your cache_peer_access .1-3 rules require certain domain names but .4-5
> rules do not. This does not explain the discrepancy you are describing
> above, but you may want to adjust your rules for consistency sake
> (either to ignore dstdomain completely or to require correct domains for
> all cache peers).
>
>
> HTH,
>
> Alex.
>
>
> > acl all_requests dstdomain -n www.example.com origin-www.example.com
> > acl limited  url_regex -i /tst/map1|/tst/map2
> >
> >
> > cache_peer 192.168.1.1 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> > cache_peer_access 192.168.1.1 deny limited
> > cache_peer_access 192.168.1.1 allow all_requests
> > cache_peer_access 192.168.1.1 deny all
> >
> > cache_peer 192.168.1.2 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> > cache_peer_access 192.168.1.2 deny limited
> > cache_peer_access 192.168.1.2 allow all_requests
> > cache_peer_access 192.168.1.2 deny all
> >
> > cache_peer 192.168.1.3 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> > cache_peer_access 192.168.1.3 deny limited
> > cache_peer_access 192.168.1.3 allow all_requests
> > cache_peer_access 192.168.1.3 deny all
> >
> > cache_peer 192.168.1.4 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> > cache_peer_access 192.168.1.4 allow limited
> > cache_peer_access 192.168.1.4 deny all
> >
> > cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> > cache_peer_access 192.168.1.5 allow limited
> > cache_peer_access 192.168.1.5 deny all
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Advice on Cache Peer ACLs

Alex Rousskov
On 8/30/19 2:41 PM, [hidden email] wrote:

> All requests will always start with www.example.com /.... or origin-www.example.com/

If that is true, why check domain names at all? When you write an ACL
that checks for X, it is reasonable to assume that X may not happen. My
evaluation of your rules made that assumption.

> Are you saying I should have the following for .4 and .5 instead of what I'm currently using?  
>
>  cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
>  cache_peer_access 192.168.1.5 allow limited
>  cache_peer_access 192.168.1.5 allow all_requests
>  cache_peer_access 192.168.1.5 deny all

No, the above does not match what you want to achieve AFAICT. If domain
names matter, then you should have something like this:

>  cache_peer_access 192.168.1.5 allow limited all_requests
>  cache_peer_access 192.168.1.5 deny all


Needless to say, the name "all_requests" is very misleading, pointing to
the same inconsistency/problem we are discussing. I will use "myDomains"
below but you may find a better name based on your business logic.

The "limited" name also looks like a poor choice because all ACLs
(except "all") limit matching. I will use mapOneOrTwo below instead.

If you fix the names, the rules become simpler/readable. For example:

cache_peer_access 192.168.1.1 deny mapOneOrTwo
cache_peer_access 192.168.1.1 allow myDomains
cache_peer_access 192.168.1.1 deny all

...

cache_peer_access 192.168.1.5 allow mapOneOrTwo myDomains
cache_peer_access 192.168.1.5 deny all


You can achieve even better clarity if you use negation, but I usually
recommend against negating ACLs:

cache_peer_access 192.168.1.1 allow !mapOneOrTwo myDomains
cache_peer_access 192.168.1.1 deny all

...

cache_peer_access 192.168.1.5 allow mapOneOrTwo myDomains
cache_peer_access 192.168.1.5 deny all



Finally, if domain names do _not_ matter, then you will just have:

cache_peer_access 192.168.1.1 deny mapOneOrTwo
cache_peer_access 192.168.1.1 allow all

...

cache_peer_access 192.168.1.5 allow mapOneOrTwo
cache_peer_access 192.168.1.5 deny all


HTH,

Alex.
P.S. If possible, mapOneOrTwo should be replaced with something more
meaningful according to your business logic.


> On Fri, Aug 30, 2019, at 11:41 AM, Alex Rousskov wrote:
>> On 8/30/19 11:44 AM, [hidden email] wrote:
>>> We use several squid servers in accelerator mode for load balancing to send public requests to backend servers.   The squids don't do any caching, they just forward requests to the backend.
>>>
>>> We have cache_peer directives to send the incoming requests to the backend Apache servers.  What I need to do is send requests to a certain page to a specific backend server and all others to the  other backends.  The site has many pages, subpages etc.  
>>>
>>> What I want to do is if someone requests:
>>> https://www.example.com/anything/anything/script.php   or https://origin-www.example.com/anything/anything/etc/etc/script.php
>>>
>>> Send the request to only .1, .2,.3.
>>>
>>> If someone requests :
>>> https://www.example.com/anything/tst/map2/script.php   or https://origin-www.example.com/anything/anything/tst/map1/etc/script.php
>>>
>>> Send that request only to .4 and .5.
>>>
>>> It seems to work most of the time, but tailing the access logs on the servers I sometimes see one of the requests for ../tst/map2/... or map1 show up on .1,.2, or .3.  
>>
>>
>> Do Squid access logs have the corresponding records as well? What cache
>> peer selection algorithm does Squid record for those misdirected
>> transactions?
>>
>>
>>> Is there something I'm missing?
>>
>> Could Squid go direct to one of those origin servers (e.g., when all
>> eligible cache peers were down)?
>>
>> BTW, please note that your cache_peer_access rules look inconsistent:
>> Your cache_peer_access .1-3 rules require certain domain names but .4-5
>> rules do not. This does not explain the discrepancy you are describing
>> above, but you may want to adjust your rules for consistency sake
>> (either to ignore dstdomain completely or to require correct domains for
>> all cache peers).
>>
>>
>> HTH,
>>
>> Alex.
>>
>>
>>> acl all_requests dstdomain -n www.example.com origin-www.example.com
>>> acl limited  url_regex -i /tst/map1|/tst/map2
>>>
>>>
>>> cache_peer 192.168.1.1 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
>>> cache_peer_access 192.168.1.1 deny limited
>>> cache_peer_access 192.168.1.1 allow all_requests
>>> cache_peer_access 192.168.1.1 deny all
>>>
>>> cache_peer 192.168.1.2 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
>>> cache_peer_access 192.168.1.2 deny limited
>>> cache_peer_access 192.168.1.2 allow all_requests
>>> cache_peer_access 192.168.1.2 deny all
>>>
>>> cache_peer 192.168.1.3 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
>>> cache_peer_access 192.168.1.3 deny limited
>>> cache_peer_access 192.168.1.3 allow all_requests
>>> cache_peer_access 192.168.1.3 deny all
>>>
>>> cache_peer 192.168.1.4 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
>>> cache_peer_access 192.168.1.4 allow limited
>>> cache_peer_access 192.168.1.4 deny all
>>>
>>> cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
>>> cache_peer_access 192.168.1.5 allow limited
>>> cache_peer_access 192.168.1.5 deny all

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Advice on Cache Peer ACLs

creditu
Thanks for the great explanation.  Much appreciated.  

On Fri, Aug 30, 2019, at 2:10 PM, Alex Rousskov wrote:

> On 8/30/19 2:41 PM, [hidden email] wrote:
>
> > All requests will always start with www.example.com /.... or origin-www.example.com/
>
> If that is true, why check domain names at all? When you write an ACL
> that checks for X, it is reasonable to assume that X may not happen. My
> evaluation of your rules made that assumption.
>
> > Are you saying I should have the following for .4 and .5 instead of what I'm currently using?  
> >
> >  cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >  cache_peer_access 192.168.1.5 allow limited
> >  cache_peer_access 192.168.1.5 allow all_requests
> >  cache_peer_access 192.168.1.5 deny all
>
> No, the above does not match what you want to achieve AFAICT. If domain
> names matter, then you should have something like this:
>
> >  cache_peer_access 192.168.1.5 allow limited all_requests
> >  cache_peer_access 192.168.1.5 deny all
>
>
> Needless to say, the name "all_requests" is very misleading, pointing to
> the same inconsistency/problem we are discussing. I will use "myDomains"
> below but you may find a better name based on your business logic.
>
> The "limited" name also looks like a poor choice because all ACLs
> (except "all") limit matching. I will use mapOneOrTwo below instead.
>
> If you fix the names, the rules become simpler/readable. For example:
>
> cache_peer_access 192.168.1.1 deny mapOneOrTwo
> cache_peer_access 192.168.1.1 allow myDomains
> cache_peer_access 192.168.1.1 deny all
>
> ...
>
> cache_peer_access 192.168.1.5 allow mapOneOrTwo myDomains
> cache_peer_access 192.168.1.5 deny all
>
>
> You can achieve even better clarity if you use negation, but I usually
> recommend against negating ACLs:
>
> cache_peer_access 192.168.1.1 allow !mapOneOrTwo myDomains
> cache_peer_access 192.168.1.1 deny all
>
> ...
>
> cache_peer_access 192.168.1.5 allow mapOneOrTwo myDomains
> cache_peer_access 192.168.1.5 deny all
>
>
>
> Finally, if domain names do _not_ matter, then you will just have:
>
> cache_peer_access 192.168.1.1 deny mapOneOrTwo
> cache_peer_access 192.168.1.1 allow all
>
> ...
>
> cache_peer_access 192.168.1.5 allow mapOneOrTwo
> cache_peer_access 192.168.1.5 deny all
>
>
> HTH,
>
> Alex.
> P.S. If possible, mapOneOrTwo should be replaced with something more
> meaningful according to your business logic.
>
>
> > On Fri, Aug 30, 2019, at 11:41 AM, Alex Rousskov wrote:
> >> On 8/30/19 11:44 AM, [hidden email] wrote:
> >>> We use several squid servers in accelerator mode for load balancing to send public requests to backend servers.   The squids don't do any caching, they just forward requests to the backend.
> >>>
> >>> We have cache_peer directives to send the incoming requests to the backend Apache servers.  What I need to do is send requests to a certain page to a specific backend server and all others to the  other backends.  The site has many pages, subpages etc.  
> >>>
> >>> What I want to do is if someone requests:
> >>> https://www.example.com/anything/anything/script.php   or https://origin-www.example.com/anything/anything/etc/etc/script.php
> >>>
> >>> Send the request to only .1, .2,.3.
> >>>
> >>> If someone requests :
> >>> https://www.example.com/anything/tst/map2/script.php   or https://origin-www.example.com/anything/anything/tst/map1/etc/script.php
> >>>
> >>> Send that request only to .4 and .5.
> >>>
> >>> It seems to work most of the time, but tailing the access logs on the servers I sometimes see one of the requests for ../tst/map2/... or map1 show up on .1,.2, or .3.  
> >>
> >>
> >> Do Squid access logs have the corresponding records as well? What cache
> >> peer selection algorithm does Squid record for those misdirected
> >> transactions?
> >>
> >>
> >>> Is there something I'm missing?
> >>
> >> Could Squid go direct to one of those origin servers (e.g., when all
> >> eligible cache peers were down)?
> >>
> >> BTW, please note that your cache_peer_access rules look inconsistent:
> >> Your cache_peer_access .1-3 rules require certain domain names but .4-5
> >> rules do not. This does not explain the discrepancy you are describing
> >> above, but you may want to adjust your rules for consistency sake
> >> (either to ignore dstdomain completely or to require correct domains for
> >> all cache peers).
> >>
> >>
> >> HTH,
> >>
> >> Alex.
> >>
> >>
> >>> acl all_requests dstdomain -n www.example.com origin-www.example.com
> >>> acl limited  url_regex -i /tst/map1|/tst/map2
> >>>
> >>>
> >>> cache_peer 192.168.1.1 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >>> cache_peer_access 192.168.1.1 deny limited
> >>> cache_peer_access 192.168.1.1 allow all_requests
> >>> cache_peer_access 192.168.1.1 deny all
> >>>
> >>> cache_peer 192.168.1.2 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >>> cache_peer_access 192.168.1.2 deny limited
> >>> cache_peer_access 192.168.1.2 allow all_requests
> >>> cache_peer_access 192.168.1.2 deny all
> >>>
> >>> cache_peer 192.168.1.3 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >>> cache_peer_access 192.168.1.3 deny limited
> >>> cache_peer_access 192.168.1.3 allow all_requests
> >>> cache_peer_access 192.168.1.3 deny all
> >>>
> >>> cache_peer 192.168.1.4 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >>> cache_peer_access 192.168.1.4 allow limited
> >>> cache_peer_access 192.168.1.4 deny all
> >>>
> >>> cache_peer 192.168.1.5 parent 80 0 no-query no-digest connect-fail-limit=10 weight=1 originserver round-robin
> >>> cache_peer_access 192.168.1.5 allow limited
> >>> cache_peer_access 192.168.1.5 deny all
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users