What is "anycast" and how is it helpful?
Solution 1:
Anycast is networking technique where the same IP prefix is advertised from multiple locations. The network then decides which location to route a user request to, based on routing protocol costs and possibly the 'health' of the advertising servers.
There are several benefits to anycast. First, in steady state, users of an anycast service (DNS is an excellent example) will always connect to the 'closest' (from a routing protocol perspective) DNS server. This reduces latency, as well as providing a level of load-balancing (assuming that your consumers are evenly distributed around your network).
Another advantage is ease of configuration management. Rather than having to configure different DNS servers depending on where a server/workstation is deployed (Asia, America, Europe), you have one IP address that is configured in every location.
Depending on how anycast is implemented, it can also provide a level of high availability. If the advertisement of the anycast route is conditional on some sort of health check (e.g. a DNS query for a well known domain, in this example), then as soon as a server fails its route can be removed. Once the network reconverges, user requests will be seamlessly forwarded to the next closest instance of DNS, without the need for any manual intervention or reconfiguration.
A final advantage is that of horizontal scaling; if you find that one server is being overly loaded, simply deploy another one in a location that would allow it to take some proportion of the overloaded server's requests. Again, as no client configuration is required, this can be done very quickly.
Solution 2:
One of the things that often confused me in understanding "anycast" is that, while it's a high level term, in practical implementation it usually boils down to two examples:
Routers using BGP to advertise the same IP block via multiple AS paths as a rough way of directing users to a "closer" site. At the same time it provides for nearly transparent failover to the other sites by just retracting the routes from a troubled site. This can be useful for nearly any protocol, though obviously it raises lots of backend data synchronization concerns.
Advertising the same service IP from multiple points within your own network (via static routing, OSPF, EIGRP, or whatever). If the routes are weighted differently it acts as a failover mechanism. If the routes are weighted evenly it can take advantage of the per-packet or per-flow load-balancing capabilities of most name-brand-vendor routers. You have to be careful that the application layer protocol is comfortable with this, that's why you almost always hear of it used with DNS where a request is always one packet and everything is stateless. Personally, I view this as a hacky intrusion of application layer concerns into the network layer when a combination of DNS and proper load-balancers will almost always be a better solution.
Solution 3:
Mainly used for UDP based services like DNS. Basically, you announce the same route out of multiple datacenters across the world. This way, your clients will be sent to the "best" and "closest" datacenter based on BGP routes. I put "best" and "closest" in quotes because network providers can play games and route traffic from certain networks differently. Generally, things work out for the best with anycast, but it's not a guarantee.
An example of this would be to list your DNS servers as 1.2.3.4 and 1.2.3.5. Your routers would announce a route for 1.2.3/24 out of multiple datacenters. If you're in Japan and have a datacenter there, chances are you'd end up there. If you're in the US, you'd be sent to your US datacenter. Again, it's based on BGP routing and not actual geographic routing, but that's usually how things break down.
Solution 4:
Pursuant to my original response, I have just posted two more articles on my blog entitled: Anycast DNS - Part 3, Using RIP and Anycast DNS - Part 3, Using RIP (continued). The latter goes into more details, but at www.netlinxinc.com/netlinx-blog.html you will find actual recipes on how to configure Cisco routers and Open Source Quagga host-based routing software for Anycast DNS using RIP.
I am currently working on writing the fourth article in the series. This will provide recipies on how to deploy Anycast DNS using OSPF. Last in the series, I'll show recipes for deploying Anycast DNS using BGP.
Anycast DNS - Part 1, Overview
Anycast DNS - Part 2, Using Static Routes
Anycast DNS - Part 3, Using RIP
Anycast DNS - Part 3, Using RIP (continued)
Solution 5:
Given this is mainly DNS at the moment...
Informally it makes your service more resilient and with better network access/latency/speed by allowing you to setup the same service in multiple locations across the world all using the same address. When someone queries for that address they are given the closest/best route.
From a server perspective:
If unicast is you going to a single person, and multicast is you going to several, and broadcast is you going to all people, then anycast is being schitzophrenic and having multiple personalities where the personality best suited to each person connects with them. Hmm. Not the best analogy.