On 10/24/2016 3:28 PM, Dimitri Maziuk wrote:
> Hi all,
>
> is anyone backing up clusters w/ shared filesystems?
>
> Specifically, I have a number of active-passive pairs where shared
> storage is on drbd, mounted on active node only. There is the third
> ("cluster" aka "floating") ip that is up on active node. So the setup is
>
> - on node A @ 1.2.3.4 : back up /etc, crontabs, etc.
> - on node B @ 1.2.3.5 : back up /etc, crontabs, etc.
> - on active node @ 1.2.3.1 : back up /drbd
>
> So far I had a 2nd FD on another port started by the cluster software on
> the active node for #3. It works but I wonder if there is a simpler way
> -- all I need's a cluster-fd that's tied to ip address but the ip may be
> up on one node or the other.
>
> Any better ideas? (I'm on 7.05. ATM)
If you are using Pacemaker, then use the ocf:heartbeat:IPaddr2 ocf
resource to manage the floating IP address as a cluster resource. You
will then configure a LSB resource for the clustered bacula-fd. This
will require:
1. A config file for the clustered bacula-fd, say
/etc/bacula/bacula-cluster-fd.conf, and in that config you will specify
a listen address of the floating IP so that it listens only on the
floating ip. You will also want to edit the standard (first instance?)
of the bacula-fd.conf so that the host node's bacula-fd does NOT listen
on the floating IP.
2. Make a copy of the bacula-fd init script and name it
bacula-cluster-fd or something. Edit the bacula-cluster-fd init script
so that it gets its config from /etc/bacula/bacula-cluster-fd.conf.
3. Add the bacula-cluster-fd as a LSB resource, something like
'primitive ClusterFD lsb:bacula-cluster-fd'.
You will then need colocation constraints so that the
ocf:heartbeat:Filesystem, ocf:heartbeat:IPaddr2, and
lsb:bacula-cluster-fd resources always run on the same node where the
ocf:linbit:drbd resource makes the drbd device primary (ie. the node
where the master/slave resource is master). And you will need
constraints such that the ocf:heartbeat:Filesystem resource is started
after the ocf:linbit:drbd resource, the ocf:heartbeat:IPaddr2 resource
is started after the ocf:heartbeat:Filesystem resource, and the
lsb:bacula-cluster-fd resource is started after the
ocf:heartbeat:IPaddr2 resource.
This will cause a second instance of bacula-fd, listening only on the
floating IP, to run on whichever node is primary for the drbd device. If
the drbd resource is migrated (ie. made primary on another node), then
the bacula-cluster-fd service will be stopped on the original node and
then started on the new node.
Note that this is quite safe, but any backup job that is running at the
time of the migration/failover will fail, as bacula expects a TCP
connection to remain up throughout the backup job and does not survive
the TCP disconnect that occurs when the floating IP resource is
migrated. This makes bacula less than ideal in a cluster environment,
but still, under normal circumstances, it works great to backup the drbd
device regardless of the node it is mounted on.
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
