[j-nsp] Anycast

[Allen Smith]

We used anycasting extensively at a previous employer where we were
something like an ad network, impacting the load performance our customers
web pages for their end user browsers.

It worked like a champ, with the following caveats:

* We advertised our nets to the same set of peers at all of our locations
within the same geographic region (Americas, EMEA, Pacific).

* The requests to our site were maybe 1000 bytes max, responses from our
servers were smaller.

* Requests to our site came from javascript running in the client browser.
The javascript gracefully handled RST and timeouts.

When I left a few years back we were seeing 10K connections/sec at the front
of some of clusters, and although we could not directly track torn
connections, we could track browsers moving from one cluster to another. It
was hundreds of users per day (out of millions). Since many of our clients
had multiple calls to us on a page and we rarely saw the same
{user_id,page_id} across clusters, it wasn't a big problem for us. Generally
if we looked, it was browsers moving to different parts of the world
(travelling laptops most likely).


On Wed, Jan 19, 2011 at 5:19 AM, David Reader <
david.reader at zeninternet.co.uk> wrote:

> 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.
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>