|
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.
> +----------------------------+
> | Internet |
> +----------------------------+
> | | |
> +----------------+ | +-----------+
> | | |
> +----------------+ +----------------+ +----------------+
> | PROXY-PARENT-1 | | PROXY-PARENT-2 | | PROXY-PARENT-3 |
> +----------------+ +----------------+ +----------------+
> | | |
> +---------------+ +---------------+ +---------------+
> | SQUID-PROXY-1 | | SQUID-PROXY-2 | | SQUID-PROXY-3 |
> +---------------+ +---------------+ +---------------+
> | | |
> +--------------+ | +---------+
> | | |
> +----------------------------+
> | LoadBalancer |
> +----------[ VIP ]-----------+
If you're using a cache scheduler (one that guarantees client persistence
for any given destination IP) this should lead to a constant
client->proxy->parent->server persistence. This is probably what you
really want, isn't it?
Yes exactly my needs : I want to preserve the client->proxy->parent->server
path. What do you mean with cache scheduler please ?
This will lead to occasional 'hot spots' on one cache and proxy or another
(this is kind of unavoidable with a destination hash based scheduler), but
should generally lead to a pretty good balance most of the time.
=> yes yes :) this is my needs :)
if you have some kind of sample squid conf part on this I will be very
interrested
Best regards,
Alexandre
|
