<div dir="ltr">Hi guys!<div><br></div><div>I've configured two nodes with the stack pacemaker + corosync, with only one resource ( just for test purposes ), and I'm having a strange result.</div><div><br></div><div>First a little bit of information:</div><div><br></div><div>pacemaker version: 1.1.12-1</div><div>corosync version: 2.3.4-1</div><div><br></div><div><br></div><div># crm configure show<br></div><div><div>node 1053402612: server1 \</div><div>node 1053402613: server2<br></div><div>primitive IP-rsc_apache IPaddr2 \</div><div><span class="" style="white-space:pre">        </span>params ip=xx.xx.xx.xy nic=eth0 cidr_netmask=255.255.255.192 \</div><div><span class="" style="white-space:pre">      </span>meta migration-threshold=2 \</div><div><span class="" style="white-space:pre">       </span>op monitor interval=20 timeout=60 on-fail=standby</div><div>property cib-bootstrap-options: \</div><div><span class="" style="white-space:pre">  </span>last-lrm-refresh=1433763004 \</div><div><span class="" style="white-space:pre">      </span>stonith-enabled=false \</div><div><span class="" style="white-space:pre">    </span>no-quorum-policy=ignore</div></div><div><br></div><div><br></div><div># cat corosync.conf<br></div><div><div>totem {</div><div><span class="" style="white-space:pre"> </span>version: 2</div><div><span class="" style="white-space:pre"> </span>token: 3000<br></div><div><span class="" style="white-space:pre">      </span>token_retransmits_before_loss_const: 10<br></div><div><span class="" style="white-space:pre">  </span>clear_node_high_bit: yes<br></div><div><span class="" style="white-space:pre"> </span>crypto_cipher: none<br></div><div><span class="" style="white-space:pre">      </span>crypto_hash: none</div><div><span class="" style="white-space:pre">  </span>transport: udpu</div><div><span class="" style="white-space:pre">    </span>interface {</div><div><span class="" style="white-space:pre">                </span>ringnumber: 0</div><div><span class="" style="white-space:pre">              </span>bindnetaddr: xx.xx.xx.xx</div><div><span class="" style="white-space:pre">           </span>ttl: 1</div><div><span class="" style="white-space:pre">     </span>}</div><div>}</div><div><br></div><div>logging {</div><div><span class="" style="white-space:pre"> </span>to_logfile: yes<br></div><div><span class="" style="white-space:pre">  </span>logfile: /var/log/corosync/corosync.log</div><div><span class="" style="white-space:pre">    </span>debug: on<br></div><div><span class="" style="white-space:pre">        </span>timestamp: on</div><div><span class="" style="white-space:pre">      </span>logger_subsys {</div><div><span class="" style="white-space:pre">            </span>subsys: QUORUM</div><div><span class="" style="white-space:pre">             </span>debug: on</div><div><span class="" style="white-space:pre">  </span>}</div><div>}</div><div><br></div><div>quorum {</div><div><span class="" style="white-space:pre">  </span>provider: corosync_votequorum</div><div><span class="" style="white-space:pre">      </span>two_node: 1</div><div><span class="" style="white-space:pre">        </span>wait_for_all: 1</div><div>}</div><div><br></div><div>nodelist {</div><div>        node {</div><div><span class="" style="white-space:pre"> </span>        ring0_addr: server1</div><div>        }</div><div>        node {</div><div><span class="" style="white-space:pre">       </span>        ring0_addr: server2</div><div>        }</div><div>}</div></div><div><br></div><div><br></div><div>It's easy, I configured only one resource.</div><div>This resource can fail two times till it will get migrated to the ther node, and if the monitoring operation for this resource causes a timeout for more than 60s, the node will be marked as a standby, and the resource will be automatically migrated to the other node.</div><div><br></div><div>At least, that would be the expected behaviour, but for some reason it isn't.</div><div><br></div><div>Let's say that the resource IP-rsc_apache starts on server1, and we keep it running there for some minutes.</div><div>Then we simulate that something goes wrong with:</div><div><br></div><div># ip addr del xx.xx.xx.xx/26 dev eth0<br></div><div><br></div><div>As far as I know, pacemaker should notice that this resource is not running anymore, and should increase the failcount for the pair resource-node. So now should be "1", and since we specified "2", the resource should run again in server1.</div><div>But this doesn't happen, because the resource jumps directly to server2:</div><div><br></div><div>Jun 08 13:47:54 [5856] server1       crmd:    debug: do_state_transition:       All 2 cluster nodes are eligible to run resources.<br></div><div><div>Jun 08 13:47:54 [5855] server1    pengine:    debug: determine_op_status:       IP-rsc_apache_monitor_20000 on server1 returned 'not running' (7) instead of the expected value: 'ok' (0) </div><div>Jun 08 13:47:54 [5855] server1    pengine:  warning: unpack_rsc_op_failure:     Processing failed op monitor for IP-rsc_apache on server1: not running (7) </div><div>Jun 08 13:47:54 [5855] server1    pengine:     info: native_print:      IP-rsc_apache   (ocf::heartbeat:IPaddr2):       Started server2 </div><div>Jun 08 13:47:54 [5855] server1    pengine:     info: get_failcount_full:        IP-rsc_apache has failed 1 times on server1 </div><div>Jun 08 13:47:54 [5855] server1    pengine:     info: common_apply_stickiness:   IP-rsc_apache can fail 1 more times on server1 before being forced off</div><div>Jun 08 13:47:54 [5855] server1    pengine:    debug: native_assign_node:        Assigning server2 to IP-rsc_apache</div><div>Jun 08 13:47:54 [5855] server1    pengine:     info: LogActions:        Leave   IP-rsc_apache   (Started server2)</div></div><div><br></div><div><br></div><div>As you can see here, IP-rsc_apache can fail one more time, but when pengine computes, it says that the resource is assigned to the other server.</div><div>I'm not understand so much this, because I was testing this with and old-stack ( pacemaker 1.1.7 + heartbeat ) and it worked as I expected, but not here.</div><div><br></div><div>crm_mon shows me:</div><div><br></div><div># crm_mon -f </div><div><br></div><div><div>Migration summary:</div><div>* Node server1: </div><div>   IP-rsc_apache: migration-threshold=2 fail-count=1 last-failure='Mon Jun  8 13:32:54 2015'</div><div>* Node server2: </div><div><br></div><div>Failed actions:</div><div>    IP-rsc_apache_monitor_20000 on server1 'not running' (7): call=24, status=complete, last-rc-change='Mon Jun  8 13:32:54 2015', queued=0ms, exec=0ms</div></div><div><br></div><div><div><br></div></div><div># crm_mon -o</div><div><div>Last updated: Mon Jun  8 13:58:54 2015</div><div>Last change: Mon Jun  8 13:31:13 2015</div><div>Current DC: server1 (1053402612) - partition with quorum</div><div>2 Nodes configured</div><div>1 Resources configured</div><div><br></div><div><br></div><div>Node server1 (1053402612): standby (on-fail)</div><div>Online: [ server2 ]</div><div><br></div><div>IP-rsc_apache   (ocf::heartbeat:IPaddr2):       Started server2</div><div><br></div><div>Operations:</div><div>* Node server1: </div><div>   IP-rsc_apache: migration-threshold=2 fail-count=1 last-failure='Mon Jun  8 13:32:54 2015'</div><div>    + (24) monitor: interval=20000ms rc=0 (ok)</div><div>    + (24) monitor: interval=20000ms rc=7 (not running)</div><div>    + (26) stop: rc=0 (ok)</div><div>* Node server2: </div><div>   IP-rsc_apache: migration-threshold=2</div><div>    + (19) start: rc=0 (ok)</div><div>    + (20) monitor: interval=20000ms rc=0 (ok)</div><div><br></div><div>Failed actions:</div><div>    IP-rsc_apache_monitor_20000 on server1 'not running' (7): call=24, status=complete, last-rc-change='Mon Jun  8 13:32:54 2015', queued=0ms, exec=0ms</div></div><div><br></div><div><br></div><div><br></div><div>It seems like pacemaker is assuming that the monitor-operation failed, and because of this, decides to mark the node as a standby. But should not be, no?</div><div><br></div><div>Somebody has some hint about that?</div><div><br></div><div>Thank you very much</div><div>Oscar Salvador</div><div><br></div></div>