Alternatives to GSLB ?
Greetings, my company has application servers in several strategic locations throughout the globe. We're currently doing GSLB with a handful of BIND DNS servers, that return the A records of the closest server(s), based off of the IP address of the resolver doing the lookup for the client. GSLB obviously has caveats in this regard, and we are looking for ideas on how to 1) ensure clients are routed to the closest geographical server 2) ensure the client hits the server(s) with the shortest path. Any feedback would be appreciated. Thanks! Jeff
Anycast works. [...] we are looking for ideas on
how to 1) ensure clients are routed to the closest geographical server 2) ensure the client hits the server(s) with the shortest path.
No need to deal with that yourself when BGP eats that problem for breakfast lunch and dinner. -Jack Carrozzo
On Tue, Apr 5, 2011 at 12:17 PM, Jack Carrozzo <jack@crepinc.com> wrote:
Anycast works.
...with some caveats.
[...] we are looking for ideas on
how to 1) ensure clients are routed to the closest geographical server 2) ensure the client hits the server(s) with the shortest path.
No need to deal with that yourself when BGP eats that problem for breakfast lunch and dinner.
-Jack Carrozzo
Note that anycast can and will bite you in the ass repeatedly as you deploy it over wider and wider scopes, unless you take careful steps to overcome the differences in policies and coverage areas with different networks. Classic problem: You peer with network X in the US. You buy transit from network Y in Asia. Network Y buys transit from network X in the US. Network X localprefers customer routes over peer routes. Your anycast traffic from network X in the US is suddenly being served from your Asia nodes behind network Y, because network X prefers the path to your anycast subnet heard through their customer instead of the peer-learned path directly from you. Not saying it won't work; it just takes careful planning, judicious use of BGP communities to limit route propagation, and constant monitoring and adjusting as networks change who they purchase connectivity from over time. Matt
On Tue, Apr 5, 2011 at 1:01 PM, Matthew Petach <mpetach@netflight.com> wrote:
On Tue, Apr 5, 2011 at 12:17 PM, Jack Carrozzo <jack@crepinc.com> wrote:
Anycast works.
...with some caveats.
[...] we are looking for ideas on
how to 1) ensure clients are routed to the closest geographical server 2) ensure the client hits the server(s) with the shortest path.
No need to deal with that yourself when BGP eats that problem for breakfast lunch and dinner.
-Jack Carrozzo
Note that anycast can and will bite you in the ass repeatedly as you deploy it over wider and wider scopes, unless you take careful steps to overcome the differences in policies and coverage areas with different networks.
Classic problem:
You peer with network X in the US. You buy transit from network Y in Asia. Network Y buys transit from network X in the US.
Network X localprefers customer routes over peer routes.
Your anycast traffic from network X in the US is suddenly being served from your Asia nodes behind network Y, because network X prefers the path to your anycast subnet heard through their customer instead of the peer-learned path directly from you.
Not saying it won't work; it just takes careful planning, judicious use of BGP communities to limit route propagation, and constant monitoring and adjusting as networks change who they purchase connectivity from over time.
Matt
I've seen that with clients. It seems like there's a promised anycast land, out where Akamai is (where you really do have "local" nearly everywhere globally, so even strange routing foo doesn't mismatch the path too badly). Between small GSLB optimal solutions and the promised land, there be dragons, due to the actual one-way routing dynamics. I noodled for a while on a mixed anycast-local solution for a particularly insane client website requirement (never got built, thank god), with each installation answering both a local GSLB-like address and the anycast. Had a layer of smart in front of the anycast load balancer ports to see if routing had done something insane, and to generate a redirect to the local address closest to the point of origin. Never got code working, and talked the client out of the business requirement, but it might be more practical than moderately complex anycast's actual practical management problems. -- -george william herbert george.herbert@gmail.com
On Apr 5, 2011, at 4:12 PM, George Herbert wrote:
I've seen that with clients. It seems like there's a promised anycast land, out where Akamai is (where you really do have "local" nearly everywhere globally, so even strange routing foo doesn't mismatch the path too badly).
No Akamai traffic is directed via anycast. Some of the name server IP addresses are anycasted, but that is for redundancy / capacity / name resolution performance, not to direct end users to web servers. -- TTFN, patrick
On Tue, Apr 5, 2011 at 2:54 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Apr 5, 2011, at 4:12 PM, George Herbert wrote:
I've seen that with clients. It seems like there's a promised anycast land, out where Akamai is (where you really do have "local" nearly everywhere globally, so even strange routing foo doesn't mismatch the path too badly).
No Akamai traffic is directed via anycast.
Some of the name server IP addresses are anycasted, but that is for redundancy / capacity / name resolution performance, not to direct end users to web servers.
Sorry, didn't mean to imply that. It was suggested in the dark past that Akamai could or should do that; they didn't. It was tangental to the point I was making and I simplified wrongly. -- -george william herbert george.herbert@gmail.com
participants (5)
-
George Herbert -
Jack Carrozzo -
Jeff Blaum -
Matthew Petach -
Patrick W. Gilmore