-----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----- -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
