[j-nsp] Anycast

[David Reader]

On Tue, 18 Jan 2011 22:25:08 +0100
Johan Borch <johan.borch at gmail.com> wrote:

> Thanks for all replies.
> 
> My IGP is not very large and changes are small.Load balancers are expensive
> and the commercial products don't really fit in the budget. The idea is that
> the sites should be active-active and take over for each other if one of
> them fail, but this sound like a challenging task :)

Can you run an additional process on these servers?

Have the server use BGP to inject into your network a /32 route to the
shared address which the webserver process is bound to. Consider using
a loopback or equivalent (eg, for a Linux host, 'dummy').

If both servers are on the same broadcast domain, make sure that they
do not respond to ARP for the additional addresses. You need the BGP
NEXT_HOP attrribute to be the hosts unique address.

You can use Perl with Net::BGP, Zebra, Quagga, or similar to do the BGP
announcement. If scripting you could build some kind of periodic
liveness test in and make the route announcement conditional upon it.

If the server dies, or becomes disconnected, the BGP session also fails
and the route goes away.

Use different metrics on the (otherwise identical) routes from
different servers to force selection in the priority order you wish.

That will give you active->standby.

If you need active<->active, you can to do similar but have 2 IP
addresses bound on each webserver process, and make one server primary
for one and the other primary for the other. Your DNS server should
then serve up both addresses to your clients.

eg, ..

DNS for www.foo.bar returns A records for 10.1.0.1 and 10.2.0.1

Server 1 has address 10.0.0.10 on it's main network interface, but also
has 10.1.0.1 and 10.2.0.1 configured for the webserver process to bind
to.

Server 2 has address 10.0.0.20 on it's main network interface, but also
has 10.1.0.1 and 10.2.0.1 configured for the webserver process to bind
to. 

Server 1 announces 10.1.0.1 into BGP with a high metric, and 10.2.0.1
with a low metric. Server 2 announces 10.1.0.1 into BGP with a low
metric, and 10.2.0.1 with a low metric.

If either server fails, the remaining server becomes the preferred
route for both addresses and all requests can be served.

Using this arrangement you can site the servers in different physical
locations on the same network.

Be careful to ensure in any active<->active arrangement that your
application does not require that consecutive requests from a single
client all go to the same server.

Active->Standby might be the safer, or only, option depending upon your
application.

Note that you can use this mechanism to take either server out of
service from your clients' perspective whilst the server continues to
be reachable for maintenance/testing/etc on it's main (unique) network
address.

Remember to apply no-export or other policy to prevent these
internal-use routes being passed onto other networks.

d.