Date: 11 Aug 1999 16:44:59 -0400 From: Chris Shenton <chris@shenton.org> To: Barrett Richardson <barrett@phoenix.aye.net> Cc: Steve Hovey <shovey@buffnet.net>, Mitch Vincent <cygone@zoomnet.net>, freebsd-isp@FreeBSD.ORG Subject: Re: Loadbalance webservers Message-ID: <874si63v3o.fsf@Thanatos.Shenton.Org> In-Reply-To: Barrett Richardson's message of "Wed, 11 Aug 1999 10:56:53 -0400 (EDT)" References: <Pine.BSF.4.01.9908110948040.16040-100000@phoenix.aye.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Barrett Richardson <barrett@phoenix.aye.net> writes: > Use OSPF. Assign the IP address that it answers to a loopback interface. > Have the ethernet (or other) interface on a different network than > the IP address that answers requests. > [geek-speak elided :-] Who, it'll take me a while to digest that, but I think I understand what you're going for. I like it. > In internet land, other name servers are cacheing info your nameserver > doles out to them about your domain. When a client browser hits > www.whatever.com the information returned by the nameserver _it_ > is using may be days old. [...] The only way you can control > that is decrease the TTL significantly on your DNS records, which > introduces additional delay as your DNS constantly has to > repropagate to be in sync with the real-time loads on your server. Yeah, I think worse is that the clients (IE, NS) cache the record forever, regardless of the TTL. If the server at the address dies you have to stop and restart the browser. Yech. > If the load is primarily random accesses from internet land the > end result is that (realistically) you don't have any more finer > grained load balancing that with the simple hack of round robin > DNS. Understood. And I think it would be hard to craft a metric which doesn't swing wildly from under- to over-used; have to have the right "damping" but also respond quickly to increased loading. > I could see such a scheme working for client softwares that are directly > using this nameserver (should be great on your own networks). The > model becomes less feasible if the accesses are coming from random > locations not directly using your nameserver (for example the internet). All the ones I've read about employ a hacked/proxy DNS which changes responses based on <something>, at best by trying to triangulate on the client's network. But you're right: increasing accuracy depends on decreasing TTL and therefore you increase DNS traffic. A big win would be if you could triangulate back to the client's local DNS; if the DNS were one used by a large site (e.g. an ISP, AoL, etc) then the DNS refresh load would be insignificant compared to the user population being served. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?874si63v3o.fsf>