RE: Redundancy

Hi there

I've been watching the "redundancy" e-mails fly across the list. Here
is my $0.02.

Now, if you want REAL redundancy, then maybe an OpenVMS port of Squid
would be useful. The supplied TCP/IP stack on new AlphaServers is
Digital's UCX, which can support "cluster aliasing" of IP addresses.
i.e. many machines share one IP address. There are two modes, the first
is round-robin, kind of like DNS, but it's decided on purely by the
machines, so the clients remain blissfully unaware, and the second is a
load-balanced implementation, where the computed load metric determines
which machine is assigned the control of the cluster IP address.

If Squid could be ported to OpenVMS (hey, it does use pretty standard C
constructs, doesn't it), then it might be doable. Just make each
machine point to the other as a sibling, so that hit rate is maximised,
even with two different cache directories. Then give users the cluster
IP alias to point to.

This works great on my OSU-DECthreads VMS web server, across two
AlphaServers. We can bring it down at any time and no-one even has to
know. That's what I call redundancy indeed !!! It's also one of the
reasons that banks etc like OpenVMS for 24*365 mission critical
applications.

Anyone else interested in a VMS port perchance ? I've seen at least one
person who indicated some interest a while back. Please let me know .

Regards

Jason Armistead
armistej@oeca.otis.com

>----------
>From: Keith Heinemann[SMTP:khman@neptune.new-era.net]
>Sent: Friday, 7 November 1997 0:12
>To: Dancer
>Cc: Squid Users; ausproxy@fatboy.geog.unsw.edu.au
>Subject: Re: Redundancy
>
>> Lately, I've been encountering a loss-of-confidence in the proxying
>> system whenever it becomes unavailable for any reason. Such reasons
>> include: System maintenance, the short delay while doing a '-k
>> reconfigure', log rotation, and the periodic shutdown (to tidy up memory
>> usage)..not to mention the occasional fault that causes the box to
>> become unavailable (particularly infrequent, but such things _do_
>> happen).
>
>> These things cause all manner of griping, but more importantly, it
>> causes people to clear their proxy configurations, and bypass the
>> system. Now, we don't want to _force_ people to use them, because
>> occasionally you come across an object that just doesn't load properly
>> through a proxy (often these have some kind of security doodad that
>> looks back at the source-ip), and we don't want to unduly restrict the
>> users in this regard. However, any kind of interruption of service
>> causes the users to clear their browser's proxy settings, and they don't
>> remember to put them back later.
>
>Yup. I struggle with that same issue frequently. I try and do all my
>maintenance at weird times, but inevitably something still goes wrong...
>
>Idea: What if your program sat on the squid cache port (3128) and listened
>to requests- forwarding them to localhost or another parent if necessary.
>The connection shell, or whatever you'd call it, could run always, but if
>you had to take squid down for maintenance things would keep moving.
>
>As is, I would be interested in seing it.
>
> -keith
>
>>
>> I thought about that a _lot_ this afternoon, and sat down and wrote some
>> code. The end-result is 'sparent 1.1'. It accepts connections. It
>> doesn't fork. It uses less than 30K of memory, and can be configured as
>> a sole parent for squid (it only listens to localhost). When it gets a
>> connection, it tries to forward it to (in turn) each of (up to) five
>> parents. If a connection succeeds, sparent will forward the connection
>> traffic through it. If all of them fail, it returns a (somewhat)
>> customisable HTTP/1.0 error message, and sends an email to the
>> configured administrator, telling them that the link is down (I found it
>> a handy feature). Since it's dumb forwarding between connections, it
>> doesn't care if they're persistant or not. It's happy with either.
>>
>> It's evil. It's scummy. It's beta. It has no real documentation. Just a
>> small source file, and a sample config. It also works, within the limits
>> of my testing. If you're interested, let me know, and I'll bounce a copy
>> of it out to you.
>>
>> TODO:
>> Give connection failure some smarts so that it doesn't email you _every_
>> time someone tries to connect and everything's unreachable.
>> Find bugs.
>> Fix bugs.
>>
>> D
>>
>> --
>> Note to evil sorcerers and mad scientists: don't ever, ever summon
>> powerful
>> demons or rip holes in the fabric of space and time. It's never a good
>> idea.
>> ICQ UIN: 3225440
>>
>>
>
>
Received on Thu Nov 06 1997 - 13:15:56 MST