Hello,

2014-05-28 14:21 GMT+02:00 Josh Fisher <jfisher AT pvct DOT com>:

On 5/24/2014 2:58 AM, Radosław Korzeniewski wrote:

Hello,

2014-05-23 17:30 GMT+02:00 Josh Fisher <jfisher AT pvct DOT com>:

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,

When you deploy bacula-fd on the cluster service then it will be a fully cluster friendly solution. I do not understand why do you suggest something different.

 

(which btw would also make it more robust with regards to handling
network problems),

It is the different problem. Yes, bacula could be a more robust regarding 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.

Yes.

In real world bacula-fd can successfully handle both cluster and non-cluster resources. I've deployed a lot of real clusters this way including Linux, Unix and Windows solutions. You can ignore that, no problem.

So you are running fd from init on both cluster nodes, yes?

Yes.

 

And listening on all interfaces?

Yes.

 

But only one of the nodes can be listening on the cluster IP.

It is how clusters are designed.

 

I can see that failover could work as long as fd on both nodes is listening on all interfaces. I don't see how this could work if fd must listen on specific interfaces

:)

 

and listening on all interfaces is not desired for other reasons.

You can limit access to other interfaces with host-based firewall