Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 31 May 2004 16:40:02 -0400
From:      scion+freebsd-questions@webrelay.net
To:        questions@freebsd.org
Subject:   Re: NFS server fail-over - how do you do it? 
Message-ID:  <20040531204003.AA13538026@nimbus.webrelay.net>

next in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040531204003.AA13538026>