[Pacemaker] Nodes will not promote DRBD resources to master on failover

Andrew Martin amartin at xes-inc.com
Sat Mar 24 15:15:31 EDT 2012

Hi Andreas, 

My complete cluster configuration is as follows: 

Last updated: Sat Mar 24 13:51:55 2012 
Last change: Sat Mar 24 13:41:55 2012 
Stack: Heartbeat 
Current DC: node2 (9100538b-7a1f-41fd-9c1a-c6b4b1c32b18) - partition with quorum 
Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c 
3 Nodes configured, unknown expected votes 
19 Resources configured. 

Node quorumnode (c4bf25d7-a6b7-4863-984d-aafd937c0da4): OFFLINE (standby) 
Online: [ node2 node1 ] 

Master/Slave Set: ms_drbd_vmstore [p_drbd_vmstore] 
Masters: [ node2 ] 
Slaves: [ node1 ] 
Master/Slave Set: ms_drbd_mount1 [p_drbd_mount1] 
Masters: [ node2 ] 
Slaves: [ node1 ] 
Master/Slave Set: ms_drbd_mount2 [p_drbd_mount2] 
Masters: [ node2 ] 
Slaves: [ node1 ] 
Resource Group: g_vm 
p_fs_vmstore (ocf::heartbeat:Filesystem): Started node2 
p_vm (ocf::heartbeat:VirtualDomain): Started node2 
Clone Set: cl_daemons [g_daemons] 
Started: [ node2 node1 ] 
Stopped: [ g_daemons:2 ] 
Clone Set: cl_sysadmin_notify [p_sysadmin_notify] 
Started: [ node2 node1 ] 
Stopped: [ p_sysadmin_notify:2 ] 
stonith-node1 (stonith:external/tripplitepdu): Started node2 
stonith-node2 (stonith:external/tripplitepdu): Started node1 
Clone Set: cl_ping [p_ping] 
Started: [ node2 node1 ] 
Stopped: [ p_ping:2 ] 

node $id="6553a515-273e-42fe-ab9e-00f74bd582c3" node1 \ 
attributes standby="off" 
node $id="9100538b-7a1f-41fd-9c1a-c6b4b1c32b18" node2 \ 
attributes standby="off" 
node $id="c4bf25d7-a6b7-4863-984d-aafd937c0da4" quorumnode \ 
attributes standby="on" 
primitive p_drbd_mount2 ocf:linbit:drbd \ 
params drbd_resource="mount2" \ 
op monitor interval="15" role="Master" \ 
op monitor interval="30" role="Slave" 
primitive p_drbd_mount1 ocf:linbit:drbd \ 
params drbd_resource="mount1" \ 
op monitor interval="15" role="Master" \ 
op monitor interval="30" role="Slave" 
primitive p_drbd_vmstore ocf:linbit:drbd \ 
params drbd_resource="vmstore" \ 
op monitor interval="15" role="Master" \ 
op monitor interval="30" role="Slave" 
primitive p_fs_vmstore ocf:heartbeat:Filesystem \ 
params device="/dev/drbd0" directory="/vmstore" fstype="ext4" \ 
op start interval="0" timeout="60s" \ 
op stop interval="0" timeout="60s" \ 
op monitor interval="20s" timeout="40s" 
primitive p_libvirt-bin upstart:libvirt-bin \ 
op monitor interval="30" 
primitive p_ping ocf:pacemaker:ping \ 
params name="p_ping" host_list="" multiplier="1000" \ 
op monitor interval="20s" 
primitive p_sysadmin_notify ocf:heartbeat:MailTo \ 
params email="me at example.com" \ 
params subject="Pacemaker Change" \ 
op start interval="0" timeout="10" \ 
op stop interval="0" timeout="10" \ 
op monitor interval="10" timeout="10" 
primitive p_vm ocf:heartbeat:VirtualDomain \ 
params config="/vmstore/config/vm.xml" \ 
meta allow-migrate="false" \ 
op start interval="0" timeout="120s" \ 
op stop interval="0" timeout="120s" \ 
op monitor interval="10" timeout="30" 
primitive stonith-node1 stonith:external/tripplitepdu \ 
params pdu_ipaddr="" pdu_port="1" pdu_username="xxx" pdu_password="xxx" hostname_to_stonith="node1" 
primitive stonith-node2 stonith:external/tripplitepdu \ 
params pdu_ipaddr="" pdu_port="2" pdu_username="xxx" pdu_password="xxx" hostname_to_stonith="node2" 
group g_daemons p_libvirt-bin 
group g_vm p_fs_vmstore p_vm 
ms ms_drbd_mount2 p_drbd_mount2 \ 
meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true" 
ms ms_drbd_mount1 p_drbd_mount1 \ 
meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true" 
ms ms_drbd_vmstore p_drbd_vmstore \ 
meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true" 
clone cl_daemons g_daemons 
clone cl_ping p_ping \ 
meta interleave="true" 
clone cl_sysadmin_notify p_sysadmin_notify 
location l-st-node1 stonith-node1 -inf: node1 
location l-st-node2 stonith-node2 -inf: node2 
location l_run_on_most_connected p_vm \ 
rule $id="l_run_on_most_connected-rule" p_ping: defined p_ping 
colocation c_drbd_libvirt_vm inf: ms_drbd_vmstore:Master ms_drbd_mount1:Master ms_drbd_mount2:Master g_vm 
order o_drbd-fs-vm inf: ms_drbd_vmstore:promote ms_drbd_mount1:promote ms_drbd_mount2:promote cl_daemons:start g_vm:start 
property $id="cib-bootstrap-options" \ 
dc-version="1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c" \ 
cluster-infrastructure="Heartbeat" \ 
stonith-enabled="false" \ 
no-quorum-policy="stop" \ 
last-lrm-refresh="1332539900" \ 
cluster-recheck-interval="5m" \ 
crmd-integration-timeout="3m" \ 

The STONITH plugin is a custom plugin I wrote for the Tripp-Lite PDUMH20ATNET that I'm using as the STONITH device: 

As you can see, I left the DRBD service to be started by the operating system (as an lsb script at boot time) however Pacemaker controls actually bringing up/taking down the individual DRBD devices. The behavior I observe is as follows: I issue "crm resource migrate p_vm" on node1 and failover successfully to node2. During this time, node2 fences node1's DRBD devices (using dopd) and marks them as Outdated. Meanwhile node2's DRBD devices are UpToDate. I then shutdown both nodes and then bring them back up. They reconnect to the cluster (with quorum), and node1's DRBD devices are still Outdated as expected and node2's DRBD devices are still UpToDate, as expected. At this point, DRBD starts on both nodes, however node2 will not set DRBD as master: 

Node quorumnode (c4bf25d7-a6b7-4863-984d-aafd937c0da4): OFFLINE (standby) 
Online: [ node2 node1 ] 

Master/Slave Set: ms_drbd_vmstore [p_drbd_vmstore] 
Slaves: [ node1 node2 ] 
Master/Slave Set: ms_drbd_mount1 [p_drbd_mount1] 
Slaves: [ node1 node 2 ] 
Master/Slave Set: ms_drbd_mount2 [p_drbd_mount2] 
Slaves: [ node1 node2 ] 

I am having trouble sorting through the logging information because there is so much of it in /var/log/daemon.log, but I can't find an error message printed about why it will not promote node2. At this point the DRBD devices are as follows: 
node2: cstate = WFConnection dstate=UpToDate 
node1: cstate = StandAlone dstate=Outdated 

I don't see any reason why node2 can't become DRBD master, or am I missing something? If I do "drbdadm connect all" on node1, then the cstate on both nodes changes to "Connected" and node2 immediately promotes the DRBD resources to master. Any ideas on why I'm observing this incorrect behavior? 

Any tips on how I can better filter through the pacemaker/heartbeat logs or how to get additional useful debug information? 


----- Original Message -----

From: "Andreas Kurz" <andreas at hastexo.com> 
To: pacemaker at oss.clusterlabs.org 
Sent: Wednesday, 1 February, 2012 4:19:25 PM 
Subject: Re: [Pacemaker] Nodes will not promote DRBD resources to master on failover 

On 01/25/2012 08:58 PM, Andrew Martin wrote: 
> Hello, 
> Recently I finished configuring a two-node cluster with pacemaker 1.1.6 
> and heartbeat 3.0.5 on nodes running Ubuntu 10.04. This cluster includes 
> the following resources: 
> - primitives for DRBD storage devices 
> - primitives for mounting the filesystem on the DRBD storage 
> - primitives for some mount binds 
> - primitive for starting apache 
> - primitives for starting samba and nfs servers (following instructions 
> here <http://www.linbit.com/fileadmin/tech-guides/ha-nfs.pdf>) 
> - primitives for exporting nfs shares (ocf:heartbeat:exportfs) 

not enough information ... please share at least your complete cluster 


Need help with Pacemaker? 

> Perhaps this is best described through the output of crm_mon: 
> Online: [ node1 node2 ] 
> Master/Slave Set: ms_drbd_mount1 [p_drbd_mount1] (unmanaged) 
> p_drbd_mount1:0 (ocf::linbit:drbd): Started node2 (unmanaged) 
> p_drbd_mount1:1 (ocf::linbit:drbd): Started node1 
> (unmanaged) FAILED 
> Master/Slave Set: ms_drbd_mount2 [p_drbd_mount2] 
> p_drbd_mount2:0 (ocf::linbit:drbd): Master node1 
> (unmanaged) FAILED 
> Slaves: [ node2 ] 
> Resource Group: g_core 
> p_fs_mount1 (ocf::heartbeat:Filesystem): Started node1 
> p_fs_mount2 (ocf::heartbeat:Filesystem): Started node1 
> p_ip_nfs (ocf::heartbeat:IPaddr2): Started node1 
> Resource Group: g_apache 
> p_fs_mountbind1 (ocf::heartbeat:Filesystem): Started node1 
> p_fs_mountbind2 (ocf::heartbeat:Filesystem): Started node1 
> p_fs_mountbind3 (ocf::heartbeat:Filesystem): Started node1 
> p_fs_varwww (ocf::heartbeat:Filesystem): Started node1 
> p_apache (ocf::heartbeat:apache): Started node1 
> Resource Group: g_fileservers 
> p_lsb_smb (lsb:smbd): Started node1 
> p_lsb_nmb (lsb:nmbd): Started node1 
> p_lsb_nfsserver (lsb:nfs-kernel-server): Started node1 
> p_exportfs_mount1 (ocf::heartbeat:exportfs): Started node1 
> p_exportfs_mount2 (ocf::heartbeat:exportfs): Started node1 
> I have read through the Pacemaker Explained 
> <http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained> 
> documentation, however could not find a way to further debug these 
> problems. First, I put node1 into standby mode to attempt failover to 
> the other node (node2). Node2 appeared to start the transition to 
> master, however it failed to promote the DRBD resources to master (the 
> first step). I have attached a copy of this session in commands.log and 
> additional excerpts from /var/log/syslog during important steps. I have 
> attempted everything I can think of to try and start the DRBD resource 
> (e.g. start/stop/promote/manage/cleanup under crm resource, restarting 
> heartbeat) but cannot bring it out of the slave state. However, if I set 
> it to unmanaged and then run drbdadm primary all in the terminal, 
> pacemaker is satisfied and continues starting the rest of the resources. 
> It then failed when attempting to mount the filesystem for mount2, the 
> p_fs_mount2 resource. I attempted to mount the filesystem myself and was 
> successful. I then unmounted it and ran cleanup on p_fs_mount2 and then 
> it mounted. The rest of the resources started as expected until the 
> p_exportfs_mount2 resource, which failed as follows: 
> p_exportfs_mount2 (ocf::heartbeat:exportfs): started node2 
> (unmanaged) FAILED 
> I ran cleanup on this and it started, however when running this test 
> earlier today no command could successfully start this exportfs resource. 
> How can I configure pacemaker to better resolve these problems and be 
> able to bring the node up successfully on its own? What can I check to 
> determine why these failures are occuring? /var/log/syslog did not seem 
> to contain very much useful information regarding why the failures occurred. 
> Thanks, 
> Andrew 
> This body part will be downloaded on demand. 

Pacemaker mailing list: Pacemaker at oss.clusterlabs.org 

Project Home: http://www.clusterlabs.org 
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf 
Bugs: http://bugs.clusterlabs.org 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/pacemaker/attachments/20120324/be6838b9/attachment-0002.html>

More information about the Pacemaker mailing list