|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
In-Reply-To: <00a701c7d8fb$f5a9b800$e4e471c3@w2lan.cesnet.cz> Cc: "Patrick W. Gilmore" <patrick@ianai.net> From: "Patrick W.Gilmore" <patrick@ianai.net> Date: Tue, 7 Aug 2007 14:13:11 -0400 To: nanog@merit.edu Errors-To: owner-nanog@merit.edu On Aug 7, 2007, at 10:05 AM, Michal Krsek wrote: >>> 5) User redirection >>> - You have to implement a scalable mechanisms that redirects >>> users to the closes POP. You can use application redirect (fast, >>> but not so much scalable), DNS redirect (scalable, but not so >>> fast) or anycasting (this needs cooperation with ISP). >> >> What is slow about handing back different answers to the same >> query via DNS, especially when they are pre-calculated? Seems >> very fast to me. > > Yes DNS-based redirection scales very pretty. > > But there are two problems: > 1) Client may not be in same network as DNS server (I'm using my > home DNS server even if I'm at IETF or I2 meeting on other side of > globe) This has been discussed. Operational experience posted here by Owen shows < 10% of users are "far" from their recursive NS. You are the tiny minority. (Don't feel bad, so am I. :) Most "users" either use the NS handed out by their local DHCP server, or they are VPN'ing anyway. > 2) DNS TTL makes realtime traffic management inpossible. Remember > you may not distribute network traffic, but sometimes also server > load. If one server/POP fails or is overloaded, you need to > redirect users to another one in realtime. Define "real time"? To do it in 1 second or less is nigh impossible. But I challenge you to fail anything over in 1 second when IP communication with end users not on your LAN is involved. I've seen TTLs as low as 20s, giving you a mean fail-over time of 10 seconds. That's more than fast enough for most applications these days. -- TTFN, patrick
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |