Date: Wed, 11 Aug 1999 10:56:53 -0400 (EDT) From: Barrett Richardson <barrett@phoenix.aye.net> To: Chris Shenton <cshenton@uucom.com> Cc: Steve Hovey <shovey@buffnet.net>, Mitch Vincent <cygone@zoomnet.net>, freebsd-isp@FreeBSD.ORG Subject: Re: Loadbalance webservers Message-ID: <Pine.BSF.4.01.9908110948040.16040-100000@phoenix.aye.net> In-Reply-To: <lfd7wul96w.fsf@Samizdat.uucom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.01.9908110948040.16040-100000>