I gave a pretty broad answer because the question was about hosting mail servers using anycast. I don't think what I was getting at in regards to stateful vs. stateless was incorrect, but I was talking about the application level not the nature of the protocol and throwing TCP in there confused the issue (I wasn't talking about TCP itself as a stateful protocol; notice I said "most things"). You can certainly do anycast with TCP, and for small stateless services it can be effective. You can't do anycast for a stateful application without taking the split-brain problem into account. The entire CDN model was developed with anycast in mind, so yes, I'm sure it does work quite well. It generally fits the description of a stateless service, and if it does implement a stateful service it's designed such that nodes have a method of sharing information (perhaps using an eventually consistent model). Taking a normal application, like mail or a dynamic website, and just using anycast for load balancing without designing the service with the anycast model in mind is probably not a good idea. You need to expect that the same user could access different systems, and design for that. The real point here is the problem OP is describing should be easily handled by having proper MX records, and getting into anycast for mail is likely not the right choice (unless maybe your goal is to be really efficient at SPAM). I'd like to know more on what problems he's seeing. On Thu, Jun 18, 2015 at 4:13 AM, Kurt Kraut <listas@kurtkraut.net> wrote:
Ray,
"Anycast is generally not well-suited for stateful connectivity (e.g. most things TCP)."
I don't know anything that would support that claim. I have been using for years BGP anycast for audio and video streaming, always in TCP (RTMP, HLS, WMS, and even the good and old ShoutCast) and works like a charm. And this is the 'secret sauce' of the company I work for, the thing we do better than our competitors that make our users happy and never wanting to leave us: anycast.
We have customers that are TV stations and stream 24x7x365 their content and they have watchers getting their streaming also 24x7x365 (like waiting rooms, airports) with no complaints or instability.
Best regards,
Kurt Kraut
2015-06-17 16:13 GMT-03:00 Ray Soucy <rps@maine.edu>:
Anycast is generally not well-suited for stateful connectivity (e.g. most things TCP). The use case for anycast is restricted to simple challenge-response protocol design.
As such, you typically only see it leveraged for simple services (e.g. DNS, NTP).
The reason for this, as you suspect, is you can never guarantee that the path and thus the server will remain consistent across client connections.
Ideally you can leverage DNS to provide a response to a unicast resource rather than trying to make the service itself anycast. DNS can be anycast, and DNS can provide different responses based on geographical location, but these can happen independently or together.
As you still want failover, you might opt to announce the MX record with the priorities reversed but still pointing to each server. For example MX 10 server1, MX 20 server2 on one side, and MX 10 server2, MX 20 server1 on the other.
Typically you would use a DNS load balancer rather than simple anycast DNS to achieve this though.
On Mon, Jun 15, 2015 at 1:50 PM, Joe Hamelin <joe@nethead.com> wrote:
I have a mail system where there are two MX hosts, one in the US and one in Europe. Both have a DNS MX record metric of 10 so a bastardized round-robin takes place. This does not work so well when one site goes down. My solution will be to place a load balancer in a hosting site (virtual, of course) and have it provide HA. But what about HA for the LB? At first glance anycasting would seem to be a great idea but there is a problem of broken sessions when routes change.
Have any of you seen something like this work in the wild?
-- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
-- Ray Patrick Soucy Network Engineer University of Maine System
T: 207-561-3526 F: 207-561-3531
MaineREN, Maine's Research and Education Network www.maineren.net
-- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net