On 5/29/2014 1:43 AM, Radosław Korzeniewski wrote:
Hello,

2014-05-28 14:21 GMT+02:00 Josh Fisher <jfis...@pvct.com>:
On 5/24/2014 2:58 AM, Radosław Korzeniewski wrote:
Hello,

2014-05-23 17:30 GMT+02:00 Josh Fisher <jfis...@pvct.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

Yes. That seems very reasonable. Thank you for explaining. I have a different approach to using clusters. Little or no services run on the cluster nodes themselves. Rather all services run in VMs and it is the VMs that are started/stopped by the CRM. The VMs run on DRBD devices, but the cluster nodes do not themselves use (or backup) anything but local disk. VMs run bacula-fd and are backed up as if they were real servers.

------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to