Dynamic Selection of Geographically Distributed Servers

Alec Peterson, Erol's
Avi Freedman, NetAccess

Table of Contents

• Slides from this Alec's Talk
• Stan Barber's Notes
• October 1997 NANOG Home Page

Stan Barber's Notes

Alec speaks

The problem is that web servers are frequently located in one place and everyone in the world is trying to get to it.

The solution is to replicate the data in serveral data center throughout the network. Then you somehow get the clients to find the "closest" servers. This is hard. How to do it?

Assumption:

• All providers are using closest exit routing.
• All providers know how to get to an address inside their network better than those outside their network.

Soltuion one:

• Select servers using a DNS-based approach
• BIND returns information ranked based on the querying address giving the "closest" information the lowest rank.
• There is a notion of shared IP address among the various DNSes as long as all these DNSes are in the same IGP.
• Research to deal with DNS detecting server failure is being done. See http://www.cnds.jhu.edu for more.

Solution two:

• Selects servers using policy-based routing

The Cisco DistributedDirector is another solution. It uses routing metrics to decide which server is closest.

Avi speaks:

Avi has a router-based solution.

Both solutions presented during this talk have a problem with established TCP sessions being reset when a problem occurs that interrupts connectivity between the endpoints of the TCP session.

Each web server tells the router via IGP its own public /32 into the web-border router.

Tunneling is used to connect up the various web sites over the same public IP address.

To handle the TCP redirects, the session redirects to a unique port on a per server basis.

Assumption: the internal network on which the web servers exists is more stable than the rest of the Internet.

Advantages:

• Notices when the web server dies (because routes are no longer advertised)
• Delivers better locality of traffic delivery
• When routing is stable, closest-exit give optimal routing. Otherwise, gives lower QoS but maintains connectivity.

Disadvantages

• Router configuation is required (tunnelling)
• Only works for HTTP

Question & Answer

It would be a good idea to have the DNS server monitor the http server. Why don't you do this?

There is a project at John Hopkins to study this.

The Cisco Product monitors port 80 and if it dies it will move it to the bottom of the list if it does not find it.

MCI has been doing the DNS hack for what it is, but trying to add to many other factors will make it overly complex. The Cisco approach or Hopscotch might be a better long-term approach.

Someone else thinks that DNS is the right place.

Paul Vixie notes that there is no guarantee that the order in which the responses are returned will be the order in which the client will choose addresses to try. He also notes that it is impossible to triangulate in the Internet because there are an infinte number of dimensions available.