From owner-freebsd-isp Wed Aug 11 8: 3:27 1999 Delivered-To: freebsd-isp@freebsd.org Received: from phoenix.aye.net (phoenix.aye.net [206.185.8.134]) by hub.freebsd.org (Postfix) with SMTP id 83E0315527 for ; Wed, 11 Aug 1999 08:03:22 -0700 (PDT) (envelope-from barrett@phoenix.aye.net) Received: (qmail 4623 invoked by uid 1000); 11 Aug 1999 14:56:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Aug 1999 14:56:53 -0000 Date: Wed, 11 Aug 1999 10:56:53 -0400 (EDT) From: Barrett Richardson To: Chris Shenton Cc: Steve Hovey , Mitch Vincent , freebsd-isp@FreeBSD.ORG Subject: Re: Loadbalance webservers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 11 Aug 1999, Chris Shenton wrote: > Barrett wrote: > >> You can just have multiple address records >> >> www IN A x.x.x.3 >> IN A x.x.x.4 >> . >> . >> . >> IN A x.x.x.n > > > Found some solid info on ISC's BIND documentation about trying to do > load balancing with DNS. The "SRV" record is designed for this but I > haven't found software that uses it (tho BIND8 implements it). So the > multiple records are a bit of a hack and will hose you if one of the > servers dies. > 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. Say you have two machines - www.whatever.com that DNS assigns via round robin to these addresses. x.x.x.2 x.x.x.3 On machine A assign these addresses to lo1 x.x.x.2 and x.x.x.3 as an alias On machine B assign the same addresses (again on lo1) x.x.x.3 and x.x.x.2 as an alias On machine A cost the IP address like this (as stub hosts in OSPF) x.x.x.2 cost 1 x.x.x.3 cost 99 On machine B cost the IP addresses like this (again as stub hosts) x.x.x.2 cost 99 x.x.x.3 cost 1 If machine A goes down, the traffic headed for it goes to machine B. The same for machine B (except the other way around in reverse). If you can run OSPF on the routers on the exit/entry points of the segment you can accomplish the necessary costing of routes on the servers via the public version of gated. For machine A you could have (in the simplest form) in your gated.conf ospf yes { backbone { stubhosts { x.x.x.2 cost 1; x.x.x.3 cost 99; }; } }; And for machine B ospf yes { backbone { stubhosts { x.x.x.3 cost 1; x.x.x.2 cost 99; }; }; }; > There's a pointer to "lbnamed" from Stanford which looks worth > trying. It puts a little load-monitor daemon on each server which the > balancing named queries; presumably it hands out records for the > least-loaded server and won't hand out records for servers that don't > respond. 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. What *was* your most lightly loaded server days ago may be getting hammered (or down) when the remote browser does a lookup for www.whatever.com. 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. 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. One reason why is that the benefits of having a fairly long TTL on A records in DNS (say a week) are tough to compete against for any scheme that would favor the TTL being very small. > > It would be way cool to modify the server-based daemon to have it > determine the network distance/cost to the *client* then feed that to > the lbnamed so it could return a record corresponding to the server > fastest/closest to the actual client. This would implement WAN load > balancing much like F5 Lab's $27K (each) 3DNS. 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). - Barrett > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message