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.
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet