From owner-freebsd-hackers Fri May 8 23:28:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA02512 for freebsd-hackers-outgoing; Fri, 8 May 1998 23:28:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA02498 for ; Fri, 8 May 1998 23:28:02 -0700 (PDT) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id PAA26104; Sat, 9 May 1998 15:57:52 +0930 (CST) (envelope-from grog) Message-ID: <19980509155752.V12200@freebie.lemis.com> Date: Sat, 9 May 1998 15:57:52 +0930 From: Greg Lehey To: Hans Huebner Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD HA configuration / Ethernet address takeover References: <19980429111546.54200@papillon.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Hans Huebner on Wed, Apr 29, 1998 at 01:02:32PM +0200 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 29 April 1998 at 13:02:32 +0200, Hans Huebner wrote: > On Wed, 29 Apr 1998, Greg Lehey wrote: > >> A big difference between the environment you're considering and the >> Tandem environment is that the Tandem environments are logically a >> single system which doesn't fail, whereas you're looking at separate >> systems, one of which may fail. A significant problem is to determine >> when the primary machine fails (what, you don't get a reply from the >> machine? Maybe *your* Ethernet board has failed). This problem has >> caused Tandem headaches for decades, and I'm not going to discuss it >> in this message. > > I was suggesting this approach while I had the OpenVision Axxion HA > approach in mind. Axxion HA is a HA system for Solaris, and it works with > Ethernet address takeover and dual-ported FC/AL disks. Clients see a > Axxion HA pair as two seperate physical machines and one 'logical' machine > which is run on either hosts of the pair. Services are normally accessed > at the 'logical' machine, but clients are free to use the 'physical' > systems if they feel the need to do so. > > Axxion HA reserves one physical ethernet port for interconnection between > the two CPUs in a HA pair. This private ethernet is normally implemented > with a crossed TP cable, and the HA monitoring software sends > alive-messages through this interface. If one system detects that the > other does no longer send alive messages, it first checks whether the > public ethernet of the other still responds before taking over the > public services. > > The disks in an Axxion HA configuration are dual-ported, but each disk is > accessed only by one host at a time. The dual-porting is used solely to > minimize the time a failover from one machine to the other takes. > > There are situations, of course, where such an approach fails, but a HA > solution is not what Tandem offers (100% availability). In fact, this is very close to Tandem's approach. The original (T/16) architecture broadcast "I'm alive" messages across two separate busses every 1.2 seconds, and would consider another system down if it missed two consecutive messages over both busses. There were times, though, when this could happen, typically due to mechanical problems where the busses became inaccessible. The results for the shared disks were devastating. But yes, most of the time things work fine. > A HA configuration can help nevertheless when one needs to perform > system upgrades, reliable level 0 dumps or other work on a system > which runs services users depend on. >> 1. Reliable Ethernet > >> [...] > >> In the case of a board which can't change its MAC address, the >> alternative of assuming its IP address and sending a couple of >> pings to the broadcast address sounds like a good workaround. >> Certainly it will normalize things faster than waiting for the >> application layer to try an alternative IP. > > This does not work with an IP alias address unless special configuration > measures are met. In fact, this is our primary problem, since we run our > name service on a IP-adress which is an alias on the host our name server > runs on. Interesting problem. I will have to think about that one. >> What makes more sense is to replicate the data across multiple >> systems. Possibly a software layer like the vinum volume manager >> would be able to perform this function: put one copy of the data >> on the local machine, another on one or two other machines via NFS >> or some other protocol, and always read from the local machine. >> As long as the write rate is not too high, this should allow for >> higher availability. > > If there is such a thing for FreeBSD, i want it ;) I was thinking of addressing it if I ever get vinum finished :-( Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message