On 05/23/2014 10:30 AM, Josh Fisher wrote:

> At failover, there simply is no way for the node taking over the primary 
> role to determine the state of the interface on the failing node. It is 
> up to software to handle errors caused by the interface going up and 
> down and reopen sockets. Bacula could be made more cluster friendly, 
> (which btw would also make it more robust with regards to handling 
> network problems), but as it is, the only safe way I see to do this is 
> to let the CRM start/stop bacula-fd dependent on the cluster IP 
> resource. Another instance of bacula-fd can separately handle backing up 
> any non-cluster resources on the node if needed.

Right. I'm not using crm/pacemaker, I'm using heartbeat and with
heartbeat it's pretty much the only way:
- bacula-fd:9102 is started from init.d on both nodes and is handling
/etc, crontabs, and other such,
- drbd, cluster ip, ..., and bacula-fd with

  Name = cluster-fd
  FDAddresses = {
    ip = { addr = clus.ter.ip; port = 9105; }
  }

are started when the node goes active.

Obviously, if failover happens during backup, the backup will fail, but
I doubt there's a feasible way around that.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs

_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users