Having tried the solution described in my previous post, I'd like to report
that the local squid likes the squid at the backup site much much too much. :-)
Given that the link between ourselves and our other site is a relatively
thin long-distance link, while local Internet bandwidth is relatively
cheap (and I think this is a scenario that applies to a lot of people who
have more than one site), it would be nice to use this link ONLY when the
ISP serving either site falls over.
The solution I'm currently thinking of is to define a fallback_host in
squid.conf, such that if a direct connect fails for a reason related to a
broken network (TCP connection timeout or host-unreachable response from
a router somewhere), and if the request is not being done in response to
a request from the fallback host (to prevent loops), that squid would
then connect to the fallback host at the indicated port and request the
resource from it.
Comment, anyone?
Anthony DeBoer <adb@geac.com> writes:
> Gregory Borodiansky <aliceoy@isracom.co.il> writes:
> > > > Is there a way to have Squid fetch objects directly from the source,
> > > > unless Squid cannot connect to the source.
> > > > If Squid cannot fetch the
> > > > object directly from the source, then attempt to fetch it from
> > > > another Squid Cache?
> > >
> > There is a partial solution: use tag <source_ping on>.
> > So, if source host will provide better response time, it'll be
> > used directly. ...
>
> This is part of the solution, since there's otherwise no way to know that
> the direct network link is broken. Another part is to declare the other
> squid as a parent, so that a MISS can be resolved through it. The
> problem I've run into while actually trying this is that the ICP response
> from the other squid will usually come back ahead of the UDP echo
> response from the direct source, causing excessive traffic to be routed
> via the other squid. I can't give it a weight less than the default "1"
> value, and there's nowhere to assign a weight to the direct connection in
> order to favour it more.
-- Anthony DeBoer <adb@geac.com> #include <std.disclaimer>Received on Sat Feb 15 1997 - 12:21:15 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:34:28 MST