From owner-freebsd-hackers Sat Apr 25 13:41:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13978 for freebsd-hackers-outgoing; Sat, 25 Apr 1998 13:41:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.artcom.de ([192.76.129.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13936 for ; Sat, 25 Apr 1998 13:41:22 -0700 (PDT) (envelope-from hans@artcom.de) Received: by mail.artcom.de id m0yTBkb-00000nC; Sat, 25 Apr 1998 22:40:45 +0200 (MEST) Message-Id: Date: Sat, 25 Apr 1998 22:40:45 +0200 (MEST) From: hans@artcom.de (Hans Huebner) To: mike@smith.net.au Subject: Re: FreeBSD HA configuration / Ethernet address takeover Newsgroups: artcom.mailing-list.freebsd.hackers In-Reply-To: <199804251913.MAA00572@antipodes.cdrom.com> Organization: Art+Com GmbH, Berlin, Germany Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Mike, In article <199804251913.MAA00572@antipodes.cdrom.com> you write: >None of the filesystems supported by FreeBSD are suited to multiple >consumers, so I'm not sure what you would hope to gain from such a >thing. If your intention was to be able to swap the disk set to the >replacement server, you'd be better off with a SCSI switch. A common bus would minimize the downtime of a HA pair. Also, such a mechanism could allow for easy sharing of removeable media drives. > FreeBSD >systems don't tend to take very long to come up when suitably configured, ... and orderly shut down. >so you could well just shut the primary server down, flip the SCSI >switch and then hit enter at the boot: prompt on your warm spare. This is fine as long as an operator is present. Also, the downtime will be considerably longer than the time a ethernet address failover would require, since the latter involves no manual switching of SCSI busses and booting of servers. >As others have suggested, though, all of the services that you've >described already support redundant servers. I'm aware of that. I'd prefer failing over the ethernet address because it would also simplify the implementation of redundant servers. This is because the server processes themselves only need to support orderly shutdown. Designing a high availabilty mechanism at the application level is bound to be more problematic than failing over the server processes at the operating system level. For example, DNS client libraries usually allow for multiple name servers be specified in client libraries. The order in which the servers are used for queries is often not specified and system dependant. Many implementations just query the first server listed, and try the second if the first one does not respond in a few seconds. Bad (existing) implementations do not share the information about name servers which are down among applications on the client system. This usually leads to intolerable delays at the clients if the first listed name server goes down. Failing over the ethernet address is completely transparent to the clients (at least with stateless server protocols), which is a big plus given the stupidity of commonly used clients. Another plus for the ethernet address failover approach is the fact that the machine can have real identity on another network interface and perform useful work while being prepared for a failover. The cold standby solution costs rack space and requires careful maintenance of the standby system to ensure that it is actually ready to perform the failover. Regards, Hans P.S.: Sorry for the improperly set Cc: in my last message. Stupid me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message