Bacula-users

Re: [Bacula-users] Bacula backup Clusters

2014-05-23 11:33:02
Subject: Re: [Bacula-users] Bacula backup Clusters
From: Josh Fisher <jfisher AT pvct DOT com>
To: bacula-users AT lists.sourceforge DOT net
Date: Fri, 23 May 2014 11:30:45 -0400
On 5/23/2014 10:37 AM, Dmitri Maziuk wrote:
> On 5/23/2014 8:35 AM, Radosław Korzeniewski wrote:
>> My suggestion was a very simple. Do not install/configure another
>> bacula-fd but simply and clever use existing configuration. In my case
>> it is a change of 4 parameters and adding a new client definition - your
>> require a lot more.
> FWIW I failed to get that to work back when I was playing with it, don't
> remember why. I ended up with what Josh suggests: as 2nd bacula-fd
> started by pacemaker and *listening on another port* because fd won't
> bind to eth0.0:9102 when eth0:9102 is already taken.
>
> Other than that it's a straightforward setup, I've been backing up 2
> drbd clusters that way for years now.
>
> Dima

There are several ways the local virtual interface associated with the 
cluster IP can be handled. IPAddr2 used with pacemaker can either 
create/delete the virtual interface altogether or else it creates it as 
a virtual of lo when inactive or of ethN when active. Either way it uses 
ifconfig to create/delete/reconfigure the virtual interface. For the 
former method, bacula-fd cannot start on one of the nodes because the 
interface doesn't exist on that node. For the latter method, bacula-fd 
can start on both nodes, but it expects its listening socket to remain 
up and I don't believe the listening socket will survive the ifconfig 
reconfiguration at failover.

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.


------------------------------------------------------------------------------
"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