From owner-freebsd-hackers Wed Mar 4 10:40:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20549 for freebsd-hackers-outgoing; Wed, 4 Mar 1998 10:40:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20510 for ; Wed, 4 Mar 1998 10:40:37 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id NAA22553; Wed, 4 Mar 1998 13:38:07 -0500 (EST) Date: Wed, 4 Mar 1998 13:38:44 -0500 (EST) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Niall Smart cc: Tom , "Ron G. Minnich" , Alex Povolotsky , hackers@FreeBSD.ORG Subject: Re: Cluster? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 4 Mar 1998, Niall Smart wrote: > For my final year project I'm working on a shared memory implementation > for the Fujitsu AP3000 using entry consistency, when I graduate (if :)) > I'd be more than interested in adding some DSM support to FreeBSD > to support transparent fall-over clustering. Thats going to be a couple > of months from now though. One particular thing that could benefit > easily from this are DNS servers, other servers like mail and news wouldn't > be so easy, because of the need for a reliable shared filesystem. Plus > there is the problem of how to get clients of these servers to contact > the redundant one in the event of a failure, I think someone has done > something in this area using proxy arp... Niall, It is not clear to me how DNS servers would benefit from this type of replication and migration -- DNS provides inherrent replication of data, as well as load distribution. I can see how this might be useful for dynamic DNS where only the primary can perform updating activity, but a better approach might be to fix DNS. :) What might benefit from what you describe, however, are distributed file system servers, where the server processes themselves could be replicated and migrated as needed to retain transparency to current clients. I'm still not sure I like this primary-backup approach to replication, however, as you lose the advantages of replication in the area of performance, for network services? For clustered computational work, however, there are no debates about performance :). Hiding clustering of network services as well as retaining reliability is a very interesting problem -- perhaps use of a NAT to do magic would help here? Robert N Watson Carnegie Mellon University http://www.cmu.edu/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message