Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Jul 2000 09:52:37 -0700 (PDT)
From:      Jason Fesler <jfesler@gigo.com>
To:        Gabriel Ambuehl <gabriel_ambuehl@buz.ch>
Cc:        Luigi Rizzo <luigi@info.iet.unipi.it>, Chris Shenton <cshenton@uucom.com>, Alan Batie <batie@rdrop.com>, isp@FreeBSD.ORG
Subject:   Re: Re[2]: load balancing
Message-ID:  <Pine.BSF.4.21.0007070948320.69269-100000@heaven.gigo.com>
In-Reply-To: <13990135708.20000707183631@buz.ch>

next in thread | previous in thread | raw e-mail | index | archive | help
> I'm very interested in hearing such a solution. The point where we're
> failing here is the following one: one SERVICE (not the complete box)
> of the box goes down. IP itself stays up. Now the hotspare should jump
> in and take the IP over but how are you going to protect the network
> from being screwed up by two identical IP addresses? I'd really
> appreciate it if one could explain me how to solve this problem (IP
> takeover with completely failed boxes is easy).

Simple, don't advertise to the world the *real* IP addresses.
Use IP aliases.

If the box is faulty but still pingable with the IP alias, 
log into the box, shutdown the alias.  Next, turn the alias
on, on the other box.

This implies that there will be something that can
 1: babysit and monitor
 2: capable of logging in and running ifconfig 
 3: Advertise to your clients, the IP alias to connect to.
    this leaves you free to move that alias to any box
    on the same network.

I do it at work all the time.  Works great.  I've written scripts
to keep it automatic but am not allowed to distribute them (sorry).
The task itself wasn't that hard.  In our case, we don't bother with
having the administrive box (babysitter) redundant; if it fails, the
failover itself stops working.  Meanwhile, we get paged, and fix the admin
box in <15 minutes, leaving a small window where failover won't happen
where it should have.  Despite lacking failover, the IP alias will still
be taking client traffic on its own.

Note that this method is low tech, and doesn't cover geographical
diversity, etc.  It just helps make sure that at the location, you can
always make sure that the IP address given to customers, is on _a_ box
that can do the job.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007070948320.69269-100000>