|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: bad idea?
| In the event of a route flap, or other instability, you could | potentially | have traffic shifted to another server without the | established TCP state, | which would prompt that server to generate an RST and end the | connection. If the route then comes back, you end up resetting your | connection for nothing. True, but in the world of what-would-we-use-this-practice-for, it mostly applies to web, which for most intents is a one shot connect-get-drop; I doubt a single TCP RST would really irk too many users. | Actually, DNS works very well for this kind of thing. Since its a | stateless protocol it isn't affected by this, and once your | client has its | answer it continues to use the same IP, which is routed normally. I | believe this is how's Akamai load balancer works (try looking up | www.yahoo.com from a name server on the left coast and on the right | coast). I see absolutily nothing wrong with using DNS in this manner. I've been a fan of advertising one globally-routed block for server farms in multiple locations for some time. Think in global terms: If you have a farm in the States (West, East), add one in AU, one in EU, one in JP, you don't have to worry about a smart DNS server. Just one server, one IP address, advertised at each data center (or site) you're at (or are). If a certain site goes down (in my argument, say, the AU site goes down), the AU clients that would normally hit the AU site would be seamlessly (as far as "seamless" goes) directed to the next closest site. If a smart DNS server gave a local AU address, AU clients with the AU IP address cached would fail.
|