On Wed, Dec 30, 2009 at 05:40:34AM -0700, Tim Serong wrote: > On 12/30/2009 at 05:30 AM, Lars Ellenberg <[email protected]> wrote: > > On Mon, Dec 28, 2009 at 08:00:24PM -0700, Tim Serong wrote: > > > IMO a solution that doesn't rely on shared storage is preferable. > > > > how about: > > lsof | sed > outfile && csync2 -xv outfile ? > > > > that is, generate a local status file, > > then "rsync" it to the rest of the cluster nodes? > > > > maybe add a "invoke_sync_script" parameter, > > which, if present, will be invoked with a single argument, > > the status file, after it has been updated. > > that script can then do csync2, rsync, scp, whatever. > > should of course have appropriate timeouts, possibly > > background itself, ... > > That's not bad... Means the status file(s) can live somewhere "normal", > like under /var, and removes any dependency on shared storage. Also > not reliant on any particular messaging layer (although does require > setup & configuration of csync2 [or whatever], which may or may not > otherwise be necessary, depending on the deployment). > > What's the worst case load a regular sync of this nature could result > in? (I'm thinking monitoring every few seconds, multiple IPs on > multiple nodes, resultant multiple syncs...)
put it on ramdisks ;) if you take a hit that no node survives, you have other things to worry about than tickle acks... should be quite manageable. but, every few seconds.. that again would mean you expect frequent changes to the connection lists, which again suggest that maybe the connections are short lived, anyways and would not benefit that much from tickle acks either. in any case, there are a few tradeoffs that could be made here. > > So better integrate it into the portblock RA? > > on "action=unblock start", send tickles. > > on "action=unblock stop", save status one last time. > > (so it will be available after a clean switchover, > > in case connections have not been cleanly shutdown) > > That'd do it :) > > > on "probe" (monitor_0) do nothing! > > or you'd truncate the status file ;) > > Hang on, what then becomes responsible for performing the monitor that > periodically updates the status file? (sorry, my brain seems to have > decided to shut itself down for the evening). monitoring of the portblock. monitor != probe, probe being the special case "monitor" operation with intervall = 0, occasionally executed even on nodes where the resource is supposed to _not_ run. may be executed prior to failover/switchover. sometimes needs to be special cased, to do something different than a "regular" monitor operation. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
