[squid-users] Re: Loadbalancing multiple SQUID parents using a parent persistence selection per client connection

From: Alexandre CASSEN <alexandre.cassen@dont-contact.us>
Date: Tue, 19 Mar 2002 13:51:03 +0100

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
Received on Tue Mar 19 2002 - 05:51:14 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:06:59 MST