On Tue, 25 Jul 2000, Webmaster wrote:
> To all,
> Please apply some of your gray matter to my problem :)
>
> Scenario, different locations, different companies managing a T1 into each
> location. Main web server sits at one location, back-up at another. No
> connection between each machine other than the T1 to the internet.
>
> Round Robin makes 50% of hits go to each web server. But if one is
> unavailable, 50% of folks get can't reach the host. Not acceptable.
>
> Question: How do I have packets go to main web server, then if main web
> server is un-reachable (for any reason) the packets are automatically routed
> to the back-up machine? (Which is up 24/7 waiting)
>
> This is pretty urgent, and help/guidance/flames would be appreciated
> greatly!
Well, Paul's DNS failover trick is free and slightly ugly, but tends to
work:
Make each Web server authoritative for the domain they sit in. Add an A
record for the appropriate name that points to the public interface, then
add each as an authoritative NS for the domain/subdomain.
It's difficult to get NS records to round-robin, so you may lose some
distribution unless you go to lbnamed and subdomain the Web servers to
force round-robining. You'll probably want to drop the TTL on the 'NS'
and 'A' Resource Recodes (RRs) down fairly low for failover.
In other words:
Each server participating is an authoritative NS, with the same *named* A
RR but it's own IP address for that name. Machine failure means that DNS
is no longer available and you get automatic failover to the next DNS.
BIND caches NS records internally, so round robin on NS RRs isn't the same
as NS records on A RRs.
If you used somethign like lbnamed and added service checks, you'd be able
to do service level failover if you alter the zone based on availability.
Distribution still wouldn't be optimal, but that may not be as important
as failover to you. Note that if you're doing SSL, you're going to have
problems no matter what unless you have a secure backchannel and some
clustering solution (probably along with failover routing and overloading
IP addresses on the target box, but I haven't had to dig through the SSL
stuff to see what it takes yet...)
HTH,
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
