From owner-freebsd-questions@FreeBSD.ORG Mon May 31 13:40:22 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7278916A4CE for ; Mon, 31 May 2004 13:40:22 -0700 (PDT) Received: from nimbus.webrelay.net (nimbus.webrelay.net [66.243.72.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 452AF43D41 for ; Mon, 31 May 2004 13:40:22 -0700 (PDT) (envelope-from scion@webrelay.net) Received: from webrelay.net (localhost [127.0.0.1]) by nimbus.webrelay.net (Postfix) with ESMTP id AA13538026 for ; Mon, 31 May 2004 16:40:03 -0400 (EDT) To: questions@freebsd.org From: scion+freebsd-questions@webrelay.net Date: Mon, 31 May 2004 16:40:02 -0400 Sender: scion@webrelay.net Message-Id: <20040531204003.AA13538026@nimbus.webrelay.net> Subject: Re: NFS server fail-over - how do you do it? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 20:40:22 -0000 Couple of issues regarding failover. 1) If system B is going to take over system a's IP, it also needs to take it's MAC address. Else you have to wait for an ARP timeout. Some systems (all?) perform a gratuitous arp-reply when an if comes up. But some other systems ignore this if they already have an arp entry, or if they weren't asking for the arp in the first place. 2) The failed system must be made to stay failed, else there is hell to pay when it comes back and finds another system in the bed, er, server room! In a main/standby scenario, this is doable with some simple scripting. Any more than that and you will need some dynamic voting algortihm support. A nice thing about *real* computers is that they have an RS-232 console port and can be made to stay down with a BRK. I believe the PC weasel will allow that, as well. A remote power controller can also serve this need. 3) One argument for run-levels in init was to keep a system at rl 2 monitoring the primary, then go to rl 3 if the primary failes. This, of course, can be done with flat rc.d, and entirely without it, as well. But it made the primary/hotstandby scheme trivial to set-up. Regardless of where you put it and what all it calls, make a single script that can be run from your monitor app once it decides the master is gone. It ensures the primary is dead, starts the server processes, and screams like the dickens for help. 4) NFS may be stateless, but NFS over TCP is common nowadays, and it isn't. Though, I believe the automounter can help with that. 5) NAS serving SAN is nice if you can afford all that fiber term gear. But you can do the same with a scsi raid array that has two host ports. You don't even need the second host port if you can change the scsi initiator ID of one of the hosts. Just keep your cable lengths as short as you can. 6) It is generally cheaper to buy than build, unless you have done it before. The devil is in the details. I've done it before, and I'll buy every time. Given that, a plug for some friends of mine that have made this work in the pri/hs mode. www.nssolutions.com Cheers! -sam