|
Hi Joe,
First of all thanks all your inputs.
>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.
In fact th the "pb" is this 2 level loadbalancing topology (LVS and SQUID).
LVS as layer3/4 operating, can handle sticky on IP address, but the
question is : Does SQUID support stickyness parent selection for non ICP
PROXY parent based on incoming client IP address ?
>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).
Yes it would be nice if I could have some SQUID hackers point of
view/advices on that point.
Best regards,
Alexandre
|
