SLUG Mailing List Archives
Re: [SLUG] Redundant Web Servers
- To: jon@xxxxxxxxx
- Subject: Re: [SLUG] Redundant Web Servers
- From: Luke Burton <luke@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 2 Jun 2003 16:29:29 +1000
- Cc: slug@xxxxxxxxxxx
-----BEGIN PGP SIGNED MESSAGE-----
On Monday, June 2, 2003, at 09:16 AM, Jon Biddell wrote:
> 3. There must be NO DISCERNABLE INTERRUPTION TO SERVICE when one
> fails. Doing a "shift-reload" in the browser is NOT an option. It
> must be TOTALLY TRANSPARENT.
The "marketing types" have to understand that nothing is perfect, for
starters. HTTP and browsers aren't intelligent enough to go "oh, this
feed stopped midway through. Let's see whether there are any secondary
sites for this". Ultimately, you may end up with broken portions of the
page, should something halt midway through serving a client.
That being said, they are probably not thinking of it in such a finely
grained manner. That's worth clarifying though. Don't let them slip one
On to some technical stuff. I'm not really up to speed with exactly how
squid works, but couldn't a round robin DNS present issues for clients
accessing through a proxy? If squid has cached a DNS reply, it might
query a stale IP address. Any squid boffins got comments on that one?
I'm thinking of say, Telstra's proxy farm that all bigpond people go
through for instance.
A good compromise might be to have a 'forwarder' machine hosted on a
highly available, redundant network of your choosing. You make sure
that the logic in this thing is as simple as possible, so that there is
a minimised risk of it going wrong. You pay a few $$ to make sure that
it's on failover hardware, redundant net connections, etc.
Its job is to forward requests to your bulkier, more failure prone IIS
installations at your two campuses. It will know whether either of them
have gone down or had performance unacceptably degraded, and start
forwarding to your other box. There will be two processes - one will be
a little httpd that executes a simple loop to decide where to forward
the request; the other will something that polls your servers to
determine health (maybe even via SNMP + ping + HTTP GET). The second
process feeds a small table that the first process uses to make
Yes, this is technically a single point of failure system - but you are
mitigating that by 1. keep its job very, very simple; 2. putting it on
a dedicated, simple Linux machine; 3. hosting it somewhere very highly
(PGP keys: http://www.hagus.net/pgp)
"Yes, questions. Morphology, longevity, incept dates."
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2
-----END PGP SIGNATURE-----