: Another solution could be to use a multi-level CARP config, which incidentally
: scales far better horizontally than ICP/HTCP, as it eliminates the iterative
: "sideways" queries altogether by hashing URLs to parent cache_peers. In this
...
: different IP or TCP port that actually does the caching. This solves your
: issue by giving every edge instance the same list of parent cache_peers - it
I briefly considered an idea very similar to this (using a hashing
feature of the load balancers designed for session affinity in
place of any peering in squid) but ruled it out fairly early on because it
would mean that any modifications to the cluster (adding or removing a
machine) would immediately drop the cache hit rate of the entire cluster
-- the only hits would be where the hashcode for a URL resulted in the
same number for N as it did for N +/- 1.
Is there a feature of CARP that can be used to mitigate this problem?
I see that a load-factor can be set per parent, so it seems like it might
be possible to mitigate the removal of a machie in the short term by
doubling the load factor on another peer (the one before it in the config
i would assume?) so that the hash function still picked the same machines
for all existing cached URLs -- but that seem's like it could only
be used as a short term workarround to an urgent outage, I'm not sure how
you would apply the same idea to adding/removing machines periodicly based
on need.
-Hoss
