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, ... We only need to do "best effort" here anyways. btw, if mtime of status file is older than $something, tickles should probably be skipped... > > Another important thing I think we should address is if the tickle > > feature should be added in IPaddr2 RA? When you deploy your HA > > solution, maybe sometimes you should configure the application service > > started after the IPaddr2 started, but sometimes you should configure > > IPaddr2 as the first-started resource then started the application. If > > it is the latter, if you tickle ACK when IPaddr2 started, but the real > > service application is not started at that time, the user may see the > > error like "Port is not reachable", this is not a good usability. > > > > So we may need to start the tickle when the application is ready. > > > > One simple implementation of this is to add the tickle feature in a > > seperated RA and add it to the last in the service group when you > > deploy it. Does this make sence? If yes, I'll implement it :) > > Yes, this is a good point. It may be that we actually want to do > something like this: > > start: > 1) add iptables rule to drop incoming packets to IP address > 2) bring up IP address > 3) bring up HA service (database, storage, web server, whatever) > 4) remove iptables blocking rule > 5) perform tickle ack > > stop (reverse of above, but fewer steps necessary): > 1) add iptables rule to drop incoming packets to IP address > 2) stop HA service > 3) bring down IP address > > > In the "start" case, I can imagine the IPaddr2 RA doing steps 1 and 2, > whatever existing RA(s) doing step 3, then a separate "tickle" RA doing > steps 4 and 5. Likewise in reverse for stop. Without something like > this, there's at least two windows of opportunity where clients are > either refused, or see the connection close (between steps 2 & 3 during > "start", and any time after step 2 in "stop" when doing a clean migrate > from one node to another). 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) on "probe" (monitor_0) do nothing! or you'd truncate the status file ;) -- : 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: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
