Re: Hot Standby

Gene Black writes:
> Since squid tends to become a single point of failure, what methods are
> commonly utilized to automatically deal with it if it crashes? I'm
> thinking of something along the lines of Cisco's Hot Standby Router
> Protocol or the such, though, to the best of my knowledge, there is no
> Linux support for such an item.
> I have sevral items that use the squid server as their default gateway
> (making it easy to do transparent proxying), and if/when the squid box
> crashes, I'd like for something else to step in to at least route the
> traffic, if not provide a backup proxy.

  Isn't it a much bigger problem that squid normally isn't going to
pass anything except port 80 traffic?

> I was wondering if there were
> any utilities that would monitor an IP address and then bring that IP
> address up on it's host machine if it couldn't reach the IP it was
> monitoring for X amount of time (and maybe even detect when the device
> comes back up and then drop the IP address on it's host).

  Yes there are such methods, and it's been around for a while as a
network engineering hack - but I'm not aware of any distributed
packages which do this. You can do something like this by having IP
addresses bound on the loopback address and then running internal
routing protocols (e.g. OSPF) on the boxes which have them, with
different route weights on the primary and secondary. In that case,
better forget all ideas of making it a default gateway. Firewalls -
server or router type - are inherently a failure point, but if you're
willing to pay, there are separate products which will handle the
fail-over or load-balancing of firewalls.

  It is possible to design a fully-redundant network, but you will have
to pay extra for it.

  In general, you'll do better to *avoid* designing your network so
that Squid becomes a single point of failure, rather than designing it
so that it is and then trying to work around it. This means putting
cache servers to the "side" of the main packet flow through your
network instead of central to it, and using routers or switches to
handle the main packet flow instead of using servers for it. I don't
have anything against UNIX servers - but decent switches and routers
will have at least an order of magnitude lower (1/10 or less) average
downtime than servers.

  -- Clifton

-- 
 Clifton Royston  --  LavaNet Systems Architect --  cliftonr@lava.net
        "An absolute monarch would be absolutely wise and good.  
           But no man is strong enough to have no interest.  
             Therefore the best king would be Pure Chance.  
              It is Pure Chance that rules the Universe; 
          therefore, and only therefore, life is good." - AC