Hi Alex, Could you please share with me a rough sketch example for the below statement. "but I suspect that a clever combination of annotate_transaction and "note" ACLs in cache_peer_access rules can be used to force a particular cache peer selection order."
On Mon, Jun 15, 2020 at 7:14 PM Alex Rousskov < rouss...@measurement-factory.com> wrote: > On 6/15/20 3:26 AM, Prem Chand wrote: > > > I stopped the peerA(purposefully) and noticed that requests are failing > > for the time slots that are going through peerA. I used > > "connect-fail-limit" in cache_peer but it's not working. Is there any > > way we can address this issue using the same solution considering how to > > handle the requests if any of the parent peer goes down? > > I am not sure, but I think it should be possible to always give Squid > three peers to use, in the right order. There is no peer selection > algorithm that will do that automatically, but I suspect that a clever > combination of annotate_transaction and "note" ACLs in cache_peer_access > rules can be used to force a particular cache peer selection order. > > https://wiki.squid-cache.org/Features/LoadBalance#Go_through_a_peer > > The trick is to place one "best" peer into the first group (your rules > already do that!), but then stop banning peers so that the other two > peers are added to the "All Alive Parents" group (your rules currently > deny those two peers from being considered). It may be possible to stop > banning peers while the peer selection code is running its second pass > by changing request annotation. > > I am sorry that I do not have enough time to sketch an example. > > Alex. > > > > > On Fri, Jun 12, 2020 at 6:47 PM Alex Rousskov wrote: > > > > On 6/11/20 11:52 PM, Prem Chand wrote: > > > > > It's working as expected. I tried to allow only specific domains > > during > > > the time by adding below acl but I'm getting HTTP status code 503 > > > > > acl usePeerB time 00:30-00:59 > > > acl usePeerB time 02:00-02:29 > > > acl alloweddomains dstdomain google.com <http://google.com> > > facebook.com <http://facebook.com> > > > > > cache_peer_access peerA allow usePeerA allowedomains > > > cache_peer_access peerB allow usePeerB allowedomains > > > cache_peer_access peerC allow !usePeerA !userPeerB alloweddomains > > > > Assuming there are no other cache peers, the above rules leave no > > forwarding path for a request to a banned domain. If you want to ban > > such requests, http_access instead of cache_peer_access. > > > > > > HTH, > > > > Alex. > > > > > > > On Thu, Jun 11, 2020 at 4:54 AM Alex Rousskov wrote: > > > > > > 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. > > > > > > > > > > > > > > > > -- > > > prem > > > > > > > > -- > > prem > > -- prem
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
