<div dir="ltr"><div>Hi Alex, <br></div><div><br></div><div>Could you please share with me a rough sketch example for the below statement.<br></div><div> "but I suspect that a clever<br>
combination of annotate_transaction and "note" ACLs in cache_peer_access<br>
rules can be used to force a particular cache peer selection order."</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 15, 2020 at 7:14 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/15/20 3:26 AM, Prem Chand wrote:<br>
<br>
> I stopped the peerA(purposefully) and noticed that requests are failing<br>
> for the time slots that are going through peerA. I used<br>
> "connect-fail-limit" in cache_peer but it's not working. Is there any<br>
> way we can address this issue using the same solution considering how to<br>
> handle the requests if any of the parent peer goes down?<br>
<br>
I am not sure, but I think it should be possible to always give Squid<br>
three peers to use, in the right order. There is no peer selection<br>
algorithm that will do that automatically, but I suspect that a clever<br>
combination of annotate_transaction and "note" ACLs in cache_peer_access<br>
rules can be used to force a particular cache peer selection order.<br>
<br>
<a href="https://wiki.squid-cache.org/Features/LoadBalance#Go_through_a_peer" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/LoadBalance#Go_through_a_peer</a><br>
<br>
The trick is to place one "best" peer into the first group (your rules<br>
already do that!), but then stop banning peers so that the other two<br>
peers are added to the "All Alive Parents" group (your rules currently<br>
deny those two peers from being considered). It may be possible to stop<br>
banning peers while the peer selection code is running its second pass<br>
by changing request annotation.<br>
<br>
I am sorry that I do not have enough time to sketch an example.<br>
<br>
Alex.<br>
<br>
<br>
<br>
> On Fri, Jun 12, 2020 at 6:47 PM Alex Rousskov wrote:<br>
> <br>
> On 6/11/20 11:52 PM, Prem Chand wrote:<br>
> <br>
> > It's working as expected. I tried to allow only specific domains<br>
> during<br>
> > the time by adding below acl but I'm getting HTTP status code 503<br>
> <br>
> > acl usePeerB time 00:30-00:59<br>
> > acl usePeerB time 02:00-02:29<br>
> > acl alloweddomains dstdomain <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a> <<a href="http://google.com" rel="noreferrer" target="_blank">http://google.com</a>><br>
> <a href="http://facebook.com" rel="noreferrer" target="_blank">facebook.com</a> <<a href="http://facebook.com" rel="noreferrer" target="_blank">http://facebook.com</a>><br>
> <br>
> > cache_peer_access peerA allow usePeerA allowedomains<br>
> > cache_peer_access peerB allow usePeerB allowedomains<br>
> > cache_peer_access peerC allow !usePeerA !userPeerB alloweddomains<br>
> <br>
> Assuming there are no other cache peers, the above rules leave no<br>
> forwarding path for a request to a banned domain. If you want to ban<br>
> such requests, http_access instead of cache_peer_access.<br>
> <br>
> <br>
> HTH,<br>
> <br>
> Alex.<br>
> <br>
> <br>
> > On Thu, Jun 11, 2020 at 4:54 AM Alex Rousskov wrote:<br>
> ><br>
> > On 6/10/20 12:20 PM, Antony Stone wrote:<br>
> > > On Wednesday 10 June 2020 at 18:11:03, Prem Chand wrote:<br>
> > ><br>
> > >> Hi Alex,<br>
> > >><br>
> > >> Thanks for responding to my issue . I didn't get how the math<br>
> > was done(why<br>
> > >> it's multiplied by 2) to get 16 slots if possible could you<br>
> > please elaborate<br>
> > >> with an example.<br>
> > ><br>
> > > I believe what Alex meant was:<br>
> > ><br>
> > > You want 30 minute timeslots for each of 3 peers, which is 48<br>
> > half-hour<br>
> > > timeslots throughout the day.<br>
> > ><br>
> > > However, you only need to define 48/3 of these for peer A, and<br>
> > 48/3 of them for<br>
> > > peer B, and then let peer C deal with anything not already<br>
> handled<br>
> > (so it<br>
> > > doesn't need its own definitions).<br>
> > ><br>
> > > 48/3 = 16, therefore you define 16 half-hour periods when<br>
> you want<br>
> > peer A to do<br>
> > > the work, 16 half-hour periods for peer B, and then just say<br>
> "peer<br>
> > C, handle<br>
> > > anything left over".<br>
> ><br>
> > Thank you, Antony! Here is an untested sketch:<br>
> ><br>
> > acl usePeerA time 00:00-00:29<br>
> > acl usePeerA time 01:30-01:59<br>
> > ... a total of 16 ORed lines for the first peer ...<br>
> > ... each line matches a unique 30 minute period ...<br>
> ><br>
> ><br>
> > acl usePeerB time 00:30-00:59<br>
> > acl usePeerB time 02:00-02:29<br>
> > ... a total of 16 ORed lines for the second peer ...<br>
> > ... each line matches a unique 30 minute period ...<br>
> ><br>
> > # and now match peer to its time slots<br>
> > cache_peer_access peerA allow usePeerA<br>
> > cache_peer_access peerB allow usePeerB<br>
> > cache_peer_access peerC allow !usePeerA !userPeerB<br>
> ><br>
> ><br>
> > The above may need further adjustments and polishing. For<br>
> example, I am<br>
> > not sure how Squid will round these time values. The above<br>
> assumes that<br>
> > 00:29 limit includes all 60 seconds up to (but excluding)<br>
> 00:30:00.<br>
> ><br>
> ><br>
> > HTH,<br>
> ><br>
> > Alex.<br>
> ><br>
> ><br>
> > >> On Wed, Jun 10, 2020 at 7:12 PM Alex Rousskov wrote:<br>
> > >>> On 6/10/20 6:09 AM, Prem Chand wrote:<br>
> > >>>> My squid cache peer has 3 parent IP’s configured. I need to<br>
> > send HTTPS<br>
> > >>>> requests to the first parent IP for 30 minutes and after<br>
> to the 2nd<br>
> > >>>> parent IP for 30 minutes and then to 3rd IP for 30<br>
> minutes and this<br>
> > >>>> switching needs to happen continuously .Could you please<br>
> let us<br>
> > know<br>
> > >>>> how I can achieve this?<br>
> > >>><br>
> > >>> If you are OK with hard-coded usage time slots for each<br>
> peer, then I<br>
> > >>> would use two[1] "time" ACLs and cache_peer_access rules.<br>
> Look for<br>
> > >>> "aclname time" in squid.conf.documented. You will have to<br>
> generate a<br>
> > >>> list of (24*2/3=16) staggered time slots for each of the two<br>
> > ACLs, but<br>
> > >>> it should work. This may be the simplest solution.<br>
> > >>><br>
> > >>> [1] You need two ACLs for three peers because the third peer<br>
> > should get<br>
> > >>> the requests that the first two peers were not allowed to get.<br>
> > >>><br>
> > >>> ----<br>
> > >>><br>
> > >>> With a modern Squid, you could also implement this using a<br>
> more<br>
> > flexible<br>
> > >>> (and more expensive, on several layers!) architecture with<br>
> two ACLs:<br>
> > >>><br>
> > >>> 1. An external ACL that returns the right cache peer name<br>
> to use<br>
> > via a<br>
> > >>> keyword=value annotation API. This always-matching ACL<br>
> should be<br>
> > >>> attached to http_access or a similar directive that supports<br>
> > slow ACLs.<br>
> > >>> Its goal is to annotate the request. You will need to write a<br>
> > >>> script/program that will compute the right annotations<br>
> based on<br>
> > time or<br>
> > >>> some other factors. This is where the flexibility of this<br>
> > solution is<br>
> > >>> coming from.<br>
> > >>><br>
> > >>> 2. A "note" ACL attached to cache_peer_access directives,<br>
> allowing<br>
> > >>> access to peer X if the external ACL in item 1 returned<br>
> > >>> use_cache_peer_=X. The "note" ACL is a fast ACL and,<br>
> hence, can be<br>
> > >>> reliably used with cache_peer_access.<br>
> > >>><br>
> > >>> If you already have another external ACL, you may be able to<br>
> > piggyback<br>
> > >>> annotations in item 1 to whatever that ACL is already doing.<br>
> > >>><br>
> > >>> For more information, search for "keyword=value" and "acl<br>
> > aclname note"<br>
> > >>> in your squid.conf.documented and see<br>
> > >>><br>
> > <br>
> <a href="https://wiki.squid-cache.org/Features/AddonHelpers#Access_Control_.28ACL" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/AddonHelpers#Access_Control_.28ACL</a>.<br>
> > >>> 29<br>
> > >>><br>
> > >>><br>
> > >>> HTH,<br>
> > >>><br>
> > >>> Alex.<br>
> > ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > prem<br>
> <br>
> <br>
> <br>
> -- <br>
> prem<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">prem</div>