Anyone considered this potential feature?

From: Michael Sparks <Michael.Sparks@dont-contact.us>
Date: Fri, 23 Oct 1998 13:04:32 +0000

Hi,

I'm working helping to manage a large cluster of squid machines (22 -
with a mixture of OS's, & hardware) all currently running Squid 1.NOVM.20.

We were recently investigating the Alteon box to see if it could provide
what we need to load balance better and perhaps drive up hit rates, since
however we need a non-transparent solution this has turned out to be a
non-starter. (For a transparent solution it looks ideal, but we can't use
that)

One possible solution is to have a single machine act as an FEP taking
all requests, hashing the URL requested and forwarding the request to a
particular machine based on the result of the hash.

Our problem with this idea is that it introduces a single point of
failure.

The alternative which strikes us as a neater solution overall is this:

Squid 2 already hashes the URL when it gets the request to check its
digest. It would be useful if Squid could be patched to send a request to
a particular sibling based on the result of that hash. ie

First ensure Squid2 is running on all the machines, then for each request:

X = result of Squid URL hash for it's digest.
Y = X mapped over N machines, selecting 1. (ala hash value mod N)
IF Y=0 then go direct
ELSE get page from sibling Y (unless sibling fails, then go direct)

This removes the need to transmit digests between the hosts since host X
is always responsible for getting the same page. Obviously a configuration
file for the machines in the cluster in service would be required. (With
perhaps a backup host for each result of the hash in case of failure)

So... My question is simple:

Firstly, can anyone see any fundamental flaws in this approach, and if
not, has anyone done any patches along these lines? If not where would
those who have been developing squid suggest I start in order to create
the patch myself... (Unless there exists some kind soul out there who is
willing to write it? :)

Thanks to all respondents in advance.

Michael Sparks.

--
National & Local Web Cache Support        R: G95c
Manchester Computing                      E: Michael.Sparks@mcc.ac.uk
University of Manchester                  T: 0161 275 7195
Manchester UK M13 9PL                     F: 0161 275 6040
Received on Fri Oct 23 1998 - 05:21:42 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:42:45 MST