Date: Sun, 16 May 1999 17:39:30 GMT From: Marty Cawthon <mrc@ChipChat.com> To: graeme@echidna.com Cc: andyf@speednet.com.au, freebsd-isp@FreeBSD.ORG, info@boatbooks.com Subject: Re: Redundant servers Message-ID: <19990516173930C.mrc@ChipChat.com> In-Reply-To: Your message of "Sun, 16 May 1999 12:52:52 -0700" <373F2214.6CE8@echidna.com> References: <373F2214.6CE8@echidna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting a message from 'graeme@echidna.com': > Andy Farkas wrote: >> How about: >> http://www.coyotepoint.com/freequalizer.shtml >> >> On Sat, 15 May 1999, Graeme Tait wrote: >>> I operate a colocated server (busy WWW, plus primary DNS and a small >>> amount of mail) for some clients, and we have been thinking about how to >>> assure (almost) uninterrupted service in the event of server failure. The >>> problem is that if physical access is required (e.g., because of hardware >>> failure), we may at times have difficulty achieving an acceptable repair >>> time. There is also the issue of minimizing downtime during major >>> upgrades. Since this machine takes online orders, downtime is directly >>> translatable into dollars of income lost. > > Thanks for the heads-up. I will be checking this out. > But my problem with such a solution is that it replaces one single-point failure > possibility by another (the equalizer box). > -- > Graeme Tait - Echidna We have servers in the USA and in Japan, which mirror each other. This provides redundancy and solves the problem of a server failure or a network failure. But how do clients know that a mirror exists? Today, they look at "www.ChipChat.com" or "www2.ChipChat.com", etc. They must know to request the URL of the mirror if the main server is not accessible. This is inconvenient for clients. A solution is possible, but not yet practical because client software (web browsers such as Netscape and MSIE) don't yet implement the experimental SRV DNS record. I quote from "DNS and BIND" 3rd Edition, by Paul Albitz & Cricket Liu O'Reilly Publishing ISBN 1-56592-512-2 page 408: --------------- "The experimental SRV record, introduced in RFC 2052, is a general mechanism for locating services. SRV also provides powerful features that allow domain administrators to distribute load and provide backup services, similar to the MX record." . . . "The SRV record has four resource record-specific fields: priority weight port target priority, weight, and port are unsigned 16-bit numbers (between 0 and 65535). target is a domain name. Priority works very similarly to the preference in an MX record: the lower the number in the priority field, the more desirable the associated target. When searching for the hosts offering a given service, clients should try targets at the same priority before trying those at a higher priority value. Weight allows domain administrators to distribute load to multiple tagets. Clients should query targets at the same priority in proportion to their weight. ..." (page 409) "Unfortunately, we don't know of any clients that support the SRV record yet." ----- This SRV DNS record sounds like it will help to provide transparent redundancy for Web, FTP, etc in a similar manner to the way that email is now handled. To make it practical, we need client software (browsers) that support SRV. Marty Cawthon ChipChat 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?19990516173930C.mrc>