Re: Transperant HTTP Redundancy.

Recently, Lyndon Levesley talked about "Re: Transperant HTTP Redundancy.", and said
>
> >>>>> On Wed, 25 Mar 1998 at around 10:37:16,
> >>>>> "GV" == Goncalo Valverde penned:
>
> GV> Greetings!
>
> GV> On 25-Mar-98 Javier Puche. CSIC RedIRIS wrote:
>
> +> - Have both machines with IP addresses different than x.x.x.x but with
> +> the ability to listen to x.x.x.x with a virtual interface when needed.
> +> - When machine 1 attending x.x.x.x falls down, have the other machine
> +> (2) detect that situation and set up a virtual interface for attending
> +> x.x.x.x , do it also the other way around.
> +> - Make sure that if either machine goes up again doesn't listen to IP
> +> x.x.x.x before checking that the other machine is not doing that
> +> already.
>
> GV> Theres an url explaining that somewhere... but the problem is that this kind
> GV> of solution is not bulletproof.. imagine that for some reason the kernel panics
> GV> with an harddisk failure.. sometimes when this happens the machine still
> GV> replies to pings, squid is up and running, but obviously doesnt replies to
> GV> requests.. so you could grab the ip address because the other machine is still
> GV> using it... or is there any way around this problem?
>
> This is just me rambling, but couldn't you do :
>
> |CISCO|
> |
> | <- 10.10.10.1/29
> /'\
> / \
> / \
> 10.10.10.3/29 -> |SQUID-A| |SQUID-B| <- 10.10.10.2/29
> (10.22.22.1/32) (10.22.22.1/32)
>
> Where the squid boxes have virtual interfaces configured. Now run a
> routing protocol between the Cisco and the squid boxes (OSPF) and
> do a "set ip next-hop 10.22.22.1" on the cisco. Make sure the squid
> boxes don't peer with each other.
>
> Your next-hop doesn't need to be directly connected, providing you
> have an IGP route to reach it with.
>
> If you use OSPF and set equal costs to reach the next-hop/32 it will
> even load-balance for you, but you'll need to /not/ do per packet
> balancing (i.e. run a route cache).
>
> You may need to mess with gated a tad to get the correct look to the
> LSA it passes to the cisco.
>
> I haven't really thought about this - just written it down, but it
> looks OK to me. In fact, it probably works better with the boxes on
> different nets.

Oy. I had been keeping quiet thus far. :-)

This is actually coming very close to a structure
Avi Freedman outlined in Phoenix during a recent
NANOG meeting, for doing distributed web serving
in general. His structure explicitly did NOT
reside on the same network, and was in fact
being used to make sure an HTTP request was
passed to the closest possible server.

I.E., if we take your diagram, and expand it a bit...

                Internet Internet
                     | |
                     | |
    |SQUID-A| | | |SQUID-B|
  10.10.10.2/29 | | 10.10.10.3/29
 (10.22.22.1/32) | | (10.22.22.1/32)
       | | | |
       ------------|RtrA| |RtrB|---------------
                        ISP Internal
                           OSPF
                          CLOUD
        -----------|RtrC| |RtrD|----------------
        | | | |
    |SQUID-C| | | |SQUID-D|
  10.10.10.4/29 | | 10.10.10.5/29
 (10.22.22.1/32) | | (10.22.22.1/32)
                     | |
                 Internet Internet

And, costs are assigned to internal links appropriately
so that from any given entry point from the internet,
the cost to reach the "local" squid box is lower than
that to reach any of the other squid boxes, you end up
with a multiply-redunant, always-select-closest-box
topology. That is, if a request enters the network
from the Internet link attached to RtrC, it will see
the shortest path to 10.22.22.1/32 as being via its
local interface, with higher cost paths coming from
RtrA, RtrB, and RtrD. If SQUID-C dies, however, the
gated process on the box will stop announcing 10.22.22.1/32,
and any requests entering at RtrC will hear only the
paths to 10.22.22.1/32 from RtrA, RtrB, and RtrD,
and will chose the lowest cost (shortest path) to
take to the next Squid box.

I know this is overkill for what is being asked for,
but since people started getting into more and more
detail, I figured I'd toss it out as a way of building
a large-scale cache structure that provides fast,
hands-free failover, on a wide scale (this can even
scale to national or international levels, provided
the same eBGP announcements are being made at each
link to the external Internet.)

Again, my apologies for going so overboard with this,
it's only marginally related to squid, and I probably
shouldn't have bored everyone here with it. :(

> Cheers,
> Lyndon
> --
> Penis Envy is a total Phallusy.

Matt

-- 
InterNex/Concentric Network     |           Matthew Petach {MP59}
Senior Network Architect        |           mpetach@internex.net
2306 Walsh Avenue               |           Tel: (408) 327-2211
Santa Clara, CA  95051          |           Fax: (408) 496-5484