[ClusterLabs] Problems putting DRBD under Pacemaker control
Darren Kinley
dkinley at mdacorporation.com
Fri Aug 5 20:08:30 UTC 2016
Hello,
Following the SUSE Linux Enterprise High Availability Extension 12 SP1 documentation I got
a Pacemaker cluster running having the Hawk GUI.
I use an LV as the DRDB backing store and put PV/VG/LVS on the drbd0 block device as
described in the DRBD 8.4 user guide chapter 10 Using LVM with DRBD.
DRBD is configured, tested and working and I can manually make one node the primary
and access the DRDB block device or switch it around and access the DRBD block device from the other node.
I'm having problems putting DRDB under Pacemaker control. "crm status" shows
crm(live)# status
Last updated: Fri Aug 5 04:59:57 2016 Last change: Fri Aug 5 04:59:45 2016 by hacluster via crmd on ars2
Stack: corosync
Current DC: ars1 (version 1.1.13-10.4-6f22ad7) - partition with quorum
2 nodes and 5 resources configured
Online: [ ars1 ars2 ]
Full list of resources:
Resource Group: cluster-mgmt
virtual-ip-mgmt (ocf::heartbeat:IPaddr2): Started ars1
mgmt (systemd:hawk): Started ars1
Resource Group: ars-services-1
virtual-ip (ocf::heartbeat:IPaddr2): Started ars2
myapache (systemd:apache2): Started ars2
drbd-data (ocf::linbit:drbd): FAILED (unmanaged)[ ars1 ars2 ]
Failed Actions:
* drbd-data_stop_0 on ars1 'not configured' (6): call=40, status=complete, exitreason='none',
last-rc-change='Fri Aug 5 04:59:46 2016', queued=0ms, exec=29ms
* drbd-data_stop_0 on ars2 'not configured' (6): call=31, status=complete, exitreason='none',
last-rc-change='Fri Aug 5 04:59:43 2016', queued=0ms, exec=23ms
This is the relevant error from the Pacemaker logfile.
Aug 05 06:46:39 [2526] ars1 pengine: warning: unpack_rsc_op_failure: Processing failed op stop for dbrd-data on ars1: not configured (6)
Aug 05 06:46:39 [2526] ars1 pengine: error: unpack_rsc_op: Preventing dbrd-data from re-starting anywhere: operation stop failed 'not configured' (6)
Aug 05 06:46:39 [2526] ars1 pengine: warning: unpack_rsc_op_failure: Processing failed op stop for dbrd-data on ars1: not configured (6)
Aug 05 06:46:39 [2526] ars1 pengine: error: unpack_rsc_op: Preventing dbrd-data from re-starting anywhere: operation stop failed 'not configured' (6)
Aug 05 06:46:39 [2526] ars1 pengine: warning: process_rsc_state: Cluster configured not to stop active orphans. dbrd-data must be stopped manually on ars1
Aug 05 06:46:39 [2526] ars1 pengine: info: native_add_running: resource dbrd-data isnt managed
Aug 05 06:46:39 [2526] ars1 pengine: warning: unpack_rsc_op_failure: Processing failed op stop for drbd-data on ars1: not configured (6)
Aug 05 06:46:39 [2526] ars1 pengine: error: unpack_rsc_op: Preventing drbd-data from re-starting anywhere: operation stop failed 'not configured' (6)
Aug 05 06:46:39 [2526] ars1 pengine: warning: unpack_rsc_op_failure: Processing failed op stop for drbd-data on ars1: not configured (6)
Aug 05 06:46:39 [2526] ars1 pengine: error: unpack_rsc_op: Preventing drbd-data from re-starting anywhere: operation stop failed 'not configured' (6)
Aug 05 06:46:39 [2526] ars1 pengine: info: native_add_running: resource drbd-data isnt managed
It sort of looks as though Pacemaker doesn't know how to stop/start DRBD on each node but I'm not sure what
commands/scripts I might have to tell it about.
Manually, I would start drbd.service on both nodes, make one the primary, rescan the PVs,
activate the VG and finally mount the file systems from now available LVs.
systemctl start drbd.service
drbdadm primary drbd0
pvscan -cache
vgchange -a y replicated
Can anyone tell me how to convince Pacemaker to control DRBD properly on each of the master and slave?
Thanks,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160805/418d4e75/attachment-0003.html>
More information about the Users
mailing list