Re: Redundancy

Dancer wrote:
> [in response to my comments about why Squid should itself avoid the extended
> period with responses delayed or rejected while rotating logs, reconfiguring,
> etc.]
>
> Well, that's why I wrote this code. I've got three servers set up. The main one,
> where people normally connect, and two proxy-only squids on other machines. If
> people connect through a proxy that's using sparent, then if the main one goes out
> for any reason, it seamlessly connects to the next server in line. Users don't
> even notice.

Er, yes. I'd forgotten that it was your message which prompted the followup
to which I was responding. However, your approach with "sparent" wouldn't
help us - we have only one cache (or rather, the cache I'm responsible for
is the top-level one within our domain), which is used primarily by browsers
though potentially also by department-level siblings. While it has parents
(the UK academic network's national cache), using sparent to redirect
requests to there unconditionally would not be useful.

Or rather, it would give unpredictable and confusing results since users
wouldn't know when it had happened, and if they were accessing either local
or remote resources that allow access based on client address they would
find themselves blocked unexpectedly, leading to complaints and/or dropping
use of the cache.

Our cache routes direct to the target server any requests for remote servers
known to apply such access controls (e.g. electronic journals for which we
have site-wide subscriptions) and local servers which may have information
restricted to local users. In fact, the latter is taken a stage further and
requests to servers within the UK academic network are routed direct - which
also avoids the problem that there are additional shared resources within
that network which are limited to subscribers by source domain.

Browser configuration isn't a solution - we don't have any direct control
over the browsers or configuration, though we'd encourage people to bypass
the cache for local services. And we want the cache to be seen as reliable
enough that people will use it rather than reject it.

Hence my comments that it would be extremely helpful if Squid could itself
avoid most or all of the delays/disruption associated with log rotation,
reconfiguration, and shutdown/restart - if it's feasible to do so. With
smaller caches, the time taken may have been ignorable, but when the cache
freezes or rejects connections for up to 5 minutes with a reasonable size
cache (at least once daily, if you rotate logs daily, plus at random other
time for reconfiguration etc.), it's verging on unacceptable.

For us, sparent wouldn't be a solution unless it could be configured
flexibly (as flexibly as Squid) with regard to routing and could provide
full HTTP, FTP, and gopher proxying or those cases where routing via a
parent could not be allowed. Simplying passing on the connection to a
different parent wouldn't help. [I haven't looked at it closely, but it
sounded like it simply relays connections to the first configured parent
that accepts the connection...?]

Sudden thought: my tests seemed to show that during log rotation Squid
*would* accept new connections but would then do nothing for up to 5 minutes
while it finished writing out cache/log... Does sparent detect that delay
and try a different route instead? Or does it only handle outright rejection
of connections?

Since log rotation is probably the most common cause of disruption to the
users, unless you're busy trying a lot of variant Squid configurations, it's
probably the case which most needs to be avoided, though the period when
connections are actually rejected during reconfiguration is more "obvious"
to the user - the rotation delays could just be the remote server being
slow!

                                John Line

-- 
University of Cambridge WWW manager account (usually John Line)
Send general WWW-related enquiries to webmaster@ucs.cam.ac.uk