[squid-users] Switch cache peer Parent server for every 30 minutes

Alex Rousskov rousskov at measurement-factory.com
Wed Jun 10 23:24:35 UTC 2020


On 6/10/20 12:20 PM, Antony Stone wrote:
> On Wednesday 10 June 2020 at 18:11:03, Prem Chand wrote:
> 
>> Hi Alex,
>>
>> Thanks for responding to my issue  . I didn't get how the math was done(why
>> it's multiplied by 2) to get 16 slots if possible could you please elaborate
>> with an example.
> 
> I believe what Alex meant was:
> 
> You want 30 minute timeslots for each of 3 peers, which is 48 half-hour 
> timeslots throughout the day.
> 
> However, you only need to define 48/3 of these for peer A, and 48/3 of them for 
> peer B, and then let peer C deal with anything not already handled (so it 
> doesn't need its own definitions).
> 
> 48/3 = 16, therefore you define 16 half-hour periods when you want peer A to do 
> the work, 16 half-hour periods for peer B, and then just say "peer C, handle 
> anything left over".

Thank you, Antony! Here is an untested sketch:

  acl usePeerA time 00:00-00:29
  acl usePeerA time 01:30-01:59
  ... a total of 16 ORed lines for the first peer ...
  ... each line matches a unique 30 minute period ...


  acl usePeerB time 00:30-00:59
  acl usePeerB time 02:00-02:29
  ... a total of 16 ORed lines for the second peer ...
  ... each line matches a unique 30 minute period ...

  # and now match peer to its time slots
  cache_peer_access peerA allow usePeerA
  cache_peer_access peerB allow usePeerB
  cache_peer_access peerC allow !usePeerA !userPeerB


The above may need further adjustments and polishing. For example, I am
not sure how Squid will round these time values. The above assumes that
00:29 limit includes all 60 seconds up to (but excluding) 00:30:00.


HTH,

Alex.


>> On Wed, Jun 10, 2020 at 7:12 PM Alex Rousskov wrote:
>>> On 6/10/20 6:09 AM, Prem Chand wrote:
>>>> My squid cache peer has 3 parent IP’s configured. I need to send HTTPS
>>>> requests to the first parent IP for 30 minutes and after to the 2nd
>>>> parent IP for 30 minutes and then to 3rd IP for 30 minutes and this
>>>> switching needs to happen continuously .Could you please let us know
>>>> how I can achieve this?
>>>
>>> If you are OK with hard-coded usage time slots for each peer, then I
>>> would use two[1] "time" ACLs and cache_peer_access rules. Look for
>>> "aclname time" in squid.conf.documented. You will have to generate a
>>> list of (24*2/3=16) staggered time slots for each of the two ACLs, but
>>> it should work. This may be the simplest solution.
>>>
>>> [1] You need two ACLs for three peers because the third peer should get
>>> the requests that the first two peers were not allowed to get.
>>>
>>> ----
>>>
>>> With a modern Squid, you could also implement this using a more flexible
>>> (and more expensive, on several layers!) architecture with two ACLs:
>>>
>>> 1. An external ACL that returns the right cache peer name to use via a
>>> keyword=value annotation API. This always-matching ACL should be
>>> attached to http_access or a similar directive that supports slow ACLs.
>>> Its goal is to annotate the request. You will need to write a
>>> script/program that will compute the right annotations based on time or
>>> some other factors. This is where the flexibility of this solution is
>>> coming from.
>>>
>>> 2. A "note" ACL attached to cache_peer_access directives, allowing
>>> access to peer X if the external ACL in item 1 returned
>>> use_cache_peer_=X. The "note" ACL is a fast ACL and, hence, can be
>>> reliably used with cache_peer_access.
>>>
>>> If you already have another external ACL, you may be able to piggyback
>>> annotations in item 1 to whatever that ACL is already doing.
>>>
>>> For more information, search for "keyword=value" and "acl aclname note"
>>> in your squid.conf.documented and see
>>> https://wiki.squid-cache.org/Features/AddonHelpers#Access_Control_.28ACL.
>>> 29
>>>
>>>
>>> HTH,
>>>
>>> Alex.
> 



More information about the squid-users mailing list