[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