hast exec vs devd for handling CARP events

Josh Paetzel josh at tcbug.org
Fri Nov 6 06:24:24 UTC 2015


Both hast and carp have an amazing propensity to go split brain. This has devastating affects.

Hundreds of years ago sailing vessels could determine their latitude by shooting the sun with an astrolabe and knowing the precise time. (You can also calculate the time if you know your latitude and have an astrolabe)

The wisdom of that time was go to sea with one clock or three. If you have one clock you have no choice but to believe it. If you have three you believe the two that agree. If you have two clocks and they disagree you are in a world of hurt.

Such is it with computers too. You really need three systems to do HA.  The best you can do with two systems is require a positive ACK from both nodes before one node will take over, otherwise you are forced to go passive-passive and require administrative action to proceed. Any other strategy will eventually hit a situation where it goes split brain.

If you are in a directly connected universe you can use SPC-3 SCSI reservations to lock the disks and prevent the nodes from destroying the storage. In a hast universe you really need quorum.

Thanks,

Josh Paetzel

> On Nov 3, 2015, at 11:35 AM, Michael W. Lucas <mwlucas at michaelwlucas.com> wrote:
> 
> Hi,
> 
> There's lots of recipes out there for HAST failover based on devd.
> 
> HAST also has the ability to run scripts on events, with the exec
> function in hast.conf.
> 
> It *seems* it make more sense to have HAST mount filesystems and start
> processes when it claims the master role for a resource, as opposed to
> triggering that mount via a devd event and waiting for HAST to perform
> the switch.
> 
> Thanks for any insight. I'm researching the "specialty filesystems"
> book, and want to give the best advice.
> 
> ==ml
> 
> -- 
> Michael W. Lucas  -  mwlucas at michaelwlucas.com, Twitter @mwlauthor 
> http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"


More information about the freebsd-fs mailing list