[squid-users] Switch cache peer Parent server for every 30 minutes
Prem Chand
premchand142 at gmail.com
Wed Jun 17 06:20:59 UTC 2020
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 <
rousskov at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20200617/3ca84064/attachment-0001.html>
More information about the squid-users
mailing list