Re: [squid-users] Managing clusters of siblings (squid2.7)

On Tue, 29 Sep 2009 12:59:52 -0700 (PDT), Chris Hostetter
<hossman_squid_at_fucit.org> wrote:
> : > What would be really nice is a command line option and a bit of code
> : > in the cache peer setup that recognizes own IP and ignores the entry,
> : > to make this problem just all go away...
>
> That would be awesome, but if i'm understanding you correctly it would
> only address the "talking to myself" problem so people could have one set
> of configs for every sibling -- we'd still need to regenerate the configs
> (and reconfigure every sibling) anytime a sibling was added.
>
> correct?

Aye. It would need to be paired with two other config options, one to set a
group for the cache_peer entries. And another to do cache_peer_access for a
group instead of a single peer.

>
> : part of the sibling cache query. That allows peers to respond 'not me'
or
> : something if they see their unique_hostname or visible_hostname in the
> Via:
> : header. Or their own IP in the X-Forwarded-For header. I'm not sure
what
>
> In this case though, the instance would still query itself -- it will
just
> be recognizing when the request came from itself and ignoring it.
>
> Couldn't the same thing be done with ACLs? (deny icp/htcp from
localhost)
> ... i'm not really familiar with ACLs so i haven't tested it yet, but
this
> is what i was thinking of before -- it just seemed less useful then
custom
> configs on every machine because it would prevent the overhead of a
> rejected ICP query on every sibling request.

The problem is multi-stage loops: proxyA->proxyB->proxyA which only shows
up in the two headers.

The first-degree example I list above can be solved by ACL in icp_access,
but when you go another level out into a mesh things get much more
complicated unless pulling the data from those headers. So for example
proxyC can test X-forwarded-For and see peer proxyA was asked for this 2-4
steps ago and don't bother trying there again.

Multicast-ICP with all the siblings NOT relaying tests at all might be the
best option for your current setup. Where peers simply get added to the
multicast group and first responder to a broadcast query gets used. You
might still need the explicit self detection to prevent

Or cache digest sharing, where all current peers indexes are already known
and no query at all is made.

Amos
Received on Tue Sep 29 2009 - 22:46:49 MDT