Re: NFS server fail-over - how do you do it?

scion+freebsd-questions_at_webrelay.net
Date: 05/31/04

  • Next message: Scott: "SOLVED: Re: FreeBSD 4.8R sluggish performance" 
    To: questions@freebsd.org
Date: Mon, 31 May 2004 16:40:02 -0400

    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
    _______________________________________________
    freebsd-questions@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"

  • Next message: Scott: "SOLVED: Re: FreeBSD 4.8R sluggish performance"