|
Alexandre Cassen wrote:
Hi Joe,
Is there a reason you can't simply tie each Squid to one parent? i.e.
to redraw your diagram, something like this:
Yes because how SQUID-PROXY-i handle PROXY-PARENT-j failover if they do
not know the whole parent topology ? (my parents doesn t support ICP)
if SP-1 directly linked to PP-1 => if PP-1 fails all clients directed on
SP-1 will be stalled because SP-1 will not be removed from LVS ipvs
table since all looks great on SP-1.
Ah... Therein lies the rub. Squid can't handle a failed parent if it
doesn't
know of alternatives.
So, the choices here get a little stickier. Of course, I'm not really
familiar with how Squid handles the failure of a non-ICP parent, anyway,
so I may not be the best person to offer up solutions. What you could
do is use your failure detection on the director to detect a failure of
/either/ the Squid or the parent proxy in each of the three traffic
paths. If either part fails, take that path out of the circuit, and
rely on just the two still-working proxy chains until you are able to
bring the failed chain back to life.
This might not be ideal, but it would work. There probably is a way to
use the weight= option for your cache_peer. If you used an extremely
high weight for the primary and an extremely low weight for the backups,
it would probably work the vast majority of the time? I'm not sure if
it is possible to weight a single parent to near-infinity and have the
backups not used except in the event of failure. This question might be
worth rephrasing in this light on the Squid list. I bet Henrik can make
a more informed statement about cache_peer behavior (he was just poking
at that area of the code when he did the rproxy enhancements to Squid).
--
Joe Cooper <joe@xxxxxxxxxxxxx>
http://www.swelltech.com
Web Caching Appliances and Support
|
