On Mon, Mar 13, 2000 at 09:48:45AM -0500, Patrick McManus wrote:
> I've run squid arrays, but put them behind l4 (foundry) switches that
> take care of the HA aspects themsevles.. (i.e. it balances between 1
> and 2 normally and should 1 disappear 2 takes all the burden.. as
> opposed to 2 answering for 1 and 2)
>
> -P
This is basically what I'm planning to do. Actually, my plan is to
have one big disk cache which users do *not* connect to but which acts
as the parent for the user caches, and then load-balance on the user
caches.
For a more limited solution, you can also use failover in the proxy.pac
autoconfigure script.
See below for some off-the-cuff comments on your scripted failover idea.
> In a previous episode Carpenter, Dean said...
> ::
> :: Hey all -
> ::
> :: I sent this in last week, and haven't heard a peep. Is there no one out
> :: there using (or trying to) squid in a failover/HA environment ?
...
> :: -----Original Message-----
> :: From: Carpenter, Dean
> :: Sent: Thursday, March 09, 2000 4:55 PM
> :: To: squid-users@ircache.net
> :: Subject: Multiple cache servers with failover ?
> ::
> ::
> :: Has anyone tried an implementation with two or more squids and IP failover ?
> :: (Linux-HA)
> ::
> :: That is, I want the user community to be split between two servers acting as
> :: siblings, 10.1.0.1 and 10.1.0.2. If one or the other fails, have the other
> :: take over the failed IP address. Since they're siblings, their caches
> :: should be fairly consistent.
> ::
> :: The only hassle I can see is when 10.1.0.1 takes over for 10.1.0.2, thus
> :: answering for both addresses - this may screw up the squid sibling cache
> :: workings ... That is, 10.1.0.1 is configured to talk to 10.1.0.2 as a
> :: sibling, but now it IS 10.1.0.2. Forwarding loop ?
> ::
> :: If not like this, how can we setup a redundant pair of caches ?
You probably need to add two things in this case, to make it work
right, for fail-over via scripts with no specialized hardware support.
1) Make sure each server has a unique primary address, and use that
address for the inter-cache peering; use secondary addresses for the
"buddy-system" address failover you're talking about.
2) Add some other scripts that take care of looking for the power-up
ARP, so that your alternate server for a given address (e.g. 10.1.0.2
above) will *surrender* the address when it sees the ARP from the
second server coming back up. Otherwise you have a mess with both of
them attempting to answer for it.
I've never tried this, but I know this kind of solution has been
around for at least a few years.
-- Clifton
-- Clifton Royston -- LavaNet Systems Architect -- cliftonr@lava.net The named which can be named is not the Eternal named.Received on Mon Mar 13 2000 - 12:38:05 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:52:05 MST