Tugger the SLUGger!SLUG Mailing List Archives

Re: [SLUG] Redundant Web Servers


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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 
past you!!

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 
decisions on.

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 
available.

Regards,

Luke.

- --
Luke Burton.
(PGP keys: http://www.hagus.net/pgp)

"Yes, questions. Morphology, longevity, incept dates."


-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBPtruzYCXGdaqw+o1EQKBLACgp4N+fmgkt4EhyZaSevhD+vQpeqEAnjO8
dcC3gDLmv7x7heUkK6XW4AY1
=vpDV
-----END PGP SIGNATURE-----