Network Dispatching with Squid

From: Lionel Bouton <Lionel.Bouton@dont-contact.us>
Date: Thu, 23 Dec 1999 13:09:21 +0000

I'm evaluating several Network Dispatching solutions for an intranet web

server farm.

For the time being, the client's intranet web server is a quad Xeon
which
will match its performance limit in the near future.
So Network Dispatching is the solution he wants us to provide.

The target is as follows :
~10000+ users, ~500+ simultaneous connexions on average, 4* this number
at peak.
The web servers' platform is NT+IIS4 (nothing I can do about it, sorry)

Here's the description of one solution I'm thinking of :
- one subdomain holding the server farm,
- one bind authoritative for the domain mentionned above, "round
robining" the farm with low TTLs,
- custom "spies" monitoring each machine of the farm, nsupate to handle
server crashes detected by the spies on the dns part of the solution,
- squid configured as a reverse proxy (web accelerator).

Squid won't give much in the caching area.
There is alreaqdy a hierarchy of caches, MS Proxy ones. The cachable
http
objects aren't numerous, not due to server configuration but
architecture choices (only to say there is nothing we can do in the
caching area).

I'm thinking of several advantages :
- nice handling of server crashes : squid dnsservers will ensure the
TTL aren't violated (I don't want to depend on TCP/IP client behaviour).

In case of a server crash, squid can timeout on a connexion and try the
following server if bind wasn't aware of the problem (eliminating
one argument against DNS round robin). With a timeout of 1 second or
hacking of squid to go below that (squid will be sitting next to the
servers...) this should handle things in a very nice way.
- easy architecture reconfiguration. Content based routing is trivial
with squid's redirector.
- cost : CISCO isn't on the cheap side...
- a little bit nicer than load sharing : if a server doesn't respond if
it's overloaded, squid will try another.
- stability (with appropriate OS, should be rock solid)

and disadvantages :
- fame (has anyone done this with squid on this scale ? how does it
scale ?),
- no GUI administration readily available (for the client it is a
problem),
- no dispatcher failover capabilities (buil-in with CISCO, and similar
solutions),
- not as good as load balancing (with use of individual server raw
performance, server load, number of opened connexions, ...).

What do you think of this ?
Is anything wrong with my assumptions, are there any advantages or
disadvantages I have overlooked ?

Lionel.
Received on Thu Dec 23 1999 - 06:18:17 MST

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