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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
